•    No Really, It’s Okay to Be Unavailable 

    We live in an uber-connected world. I can’t tell you how many times I’ve complained about shoddy Wi-Fi or the fact that Twitter is down. As much as I love the connection provided by the web and various technologies, somewhere along the way we became terrified of being unavailable. We have to check email maniacally, so we don’t keep our senders waiting. Our cell phone alerts and Slack notifications practically dictate our schedules.

    Do a quick Google search of “being unavailable, ” and you’ll get a slew of articles on emotional availability and tips on how to be more attractive in relationships. These articles bemoan to women how men don’t like their partners to be around all the time; they find their better halves more attractive when they are invested in their own lives and not constantly dependent on their man’s company.

    As a woman, I find many of these articles completely ridiculous. I believe one should live their lives on their own terms and things will just work themselves out. There is, however, a positive correlation between being somewhat unavailable, especially in business. People fear that by putting away their electronics, the unavailability will reflect poorly on who they are as a worker.

    Here’s a truth: being unavailable is good for both you and your company. Somewhere along the way—and I’ve spoken with disdain about this inane practice before—working a million hours a week became a status symbol. Being available all the time meant you worked hard and smart. Although it has been vehemently debunked time and time again, there are those out there that still believe they have to respond to emails while they’re showering to keep a leg up.

    You don’t need to unplug completely to be unavailable. Many of the articles written about disconnecting are coming from people who don’t work closely with technology. They aren’t active on social media, and they don’t depend on Slack and other ChatOps to get their jobs done. Aside from the business aspect of being connected, a lot of us derive joy from hanging out on Twitter and consuming content.

    In my personal experience, my iPhone is an extension of my day, not a complete productivity assassin. With that said, it has been proven that using a phone while performing another task leads to poorer performance. Studies have shown even just hearing alerts in the background is comparable to actively using the device. Is the solution to turn off the phone once you get into the house? Not for me.

    We can all have our own definition of unplugging. For me, it’s turning off alerts now and then to focus on other things. In the case of my computer, it’s occasionally not bringing it with me to the couch when I’m watching TV. Unplugging is different for everybody. Remember you don’t have to go completely “off the grid” to glean the benefits of time away from the internet.

    It’s great to unplug while still engaging in some tech. Don’t forget, however, to take some time away from the grind. Unplugging could just be not answering work emails or going on airplane mode. Whatever you choose, remember it is indeed okay to occasionally be unavailable.

  •    Cloudflare has been leaking custom HTTPS sessions 

    Cloudflare has reported that under certain circumstances their edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

    Tavis Ormandy from Google’s Project Zero first spotted the problem and reported this in the Chromium tracker:

    It looked like that if an html page hosted behind cloudflare had a specific combination of unbalanced tags, the proxy would intersperse pages of uninitialized memory into the output (kinda like heartbleed, but cloudflare specific and worse for reasons I’ll explain later). My working theory was that this was related to their “ScrapeShield” feature which parses and obfuscates html – but because reverse proxies are shared between customers, it would affect all Cloudflare customers.

    We fetched a few live samples, and we observed encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests for other major cloudflare-hosted sites from other users. Once we understood what we were seeing and the implications, we immediately stopped and contacted cloudflare security.

    Once Cloudflare was contacted they immediately jumped on the problem and reduced it down to their HTML parser that was used in email obfuscation, Server-side Excludes, and Automatic HTTPS Rewrites.

    The issue is now fixed and rolled out to all customers and Cloudflare has a very detailed report on the background, the timeline of the fix, and how they fixed it. They also, worked with Google and other search engines directly to get to remove any cached HTTP responses.

    If you’d like to see a list of sites running Cloudflare here is a list of some of the most popular domains.

    UPDATE: Laravel News runs on Cloudflare and we received an email this morning saying this site was not affected. Here is a copy of the relevant information from that report:

    In our review of these third party caches, we discovered exposed data on approximately 150 of Cloudflare’s customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

    Your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

  •    Tips For Building Your First Laravel Package 

    Laravel is a powerful and modern framework. It has tons of different features, which make our work faster and easier. But you can’t push everything into the single box. At one time or another, we’ve all been in need of something not implemented in the framework out of the box. So, you’re writing code by yourself; it works, and you are happy. Yep?

    But what if you need the same functionality in another project? Will you write it again? Copy-paste it? Both solutions are bad because you’re solving the same problem again and again. And what about bugs? Imagine finding a bug in that code a few days later. Now you have to fix it in N places. Ufff, not fun!

    A package can be a solution. Write your code once and use it in any number of projects. Maybe you found a bug, or want to make some changes? Do it just once in your package code and then pull required changes in all of your projects. Sounds good?

    The First Step

    Before diving into the work with your head, check Packagist first. It is possible someone has already solved your problem. If you can’t find an existing package, try to explore the question a little bit deeper. Maybe you’re not using the most accurate keywords in your search. Don’t be afraid to spend another 30 minutes; it could save you 30 days eventually.


    You’ve searched, but no luck and now you’re willing to create a new Laravel package. What are the next steps?

    First of all, take a look at the Laravel documentation. The Package Development page is a great starting point. You’ll find out in most cases, the heart of your package would be a service provider. Here you can register event listeners, middleware, routes, translations, views, etc. Maybe your package has its own config file, maybe even its own database migrations. You have to describe all of that in your service provider. It is the connection point between your package and Laravel.

    Your head is full of knowledge; you are creating new GitHub repo and starting to write code. Great! What tips can I give to you?

    I think one of the most important things, when you’re writing a framework package is to make the package close to the framework. In everything: architecture, naming, code style, documentation, every aspect of it. It will be much easier for people to understand and use your package if it looks like the part of the framework. But, it’s not always easy to choose those best names for classes, methods, variables, etc. I really like Jeffrey Way’s method, which I learned at Laracasts. When you’re feeling a name isn’t very good, delete it and write it as you’d want it to be in a perfect world, then use it. Simple enough, but it works. Naming is not the easiest thing in programming, and there are a lot of good books about it.

    I’ve received the following feedback from someone using my package: “Nice readme file! It’s really easy to read it, it feels like I’m reading one of the Laravel docs!” That was my victory!

    If people feel your package is a natural part of the framework — you’re on the right path.


    Package testing can be really tricky. And the first question I had, before even starting to write tests was this: how should I test it? Should I create a new instance of my Laravel project, install my package there, and write my tests? These were the real usage conditions of my package, but my tests would be located outside of the package, which is really bad.

    Luckily, there is Testbench Component to solve that problem. It provides a way to test your package without a standalone Laravel install. You can easily register your package service provider, aliases, set up the database, load migrations, etc.

    The great thing about open source is you can use cool GitHub integrations for free. They can help you in different ways.
    My favorites are:


    Your code is ready and, your tests are green. You think you’re done at this point? Nope.

    Don’t be lazy; create a nice readme file. It can be really useful for you because you’re taking another look at your package in general. There have been so many times while writing a readme file that new ideas have come to me. And having a good readme allows others to be able to use your package as well. Isn’t it great to know your code is useful for someone?

    I think a readme file is really important, and it should be as simple as possible. Use images, where possible. They are easier to understand. Write your documentation as close to Laravel Documentation as you can.

    There is a really great article “How to write a readme that rocks“, take a look!
    There are a lot of cool tips and tools described there. For example, Michael Dyrynda’s Readme Generator, Grammarly, Hemingway App, etc.


    Don’t forget to add your package to Packagist, so it will be available through Composer. That will make your package installation really easy, and make it searchable through Composer. Use keywords in your composer.json file. You can also set up GitHub Topics to make your package even more searchable.

    Use GitHub Releases for your package. Read and follow Semantic Versioning rules.

    It doesn’t matter how cool is your package if people don’t know about it. Tell them!

    Write short notes on community forums, for example, Laracasts Forum, Larachat, etc. Add a link to your package on Laravel News. Don’t be afraid to tell!


    Creating your own packages can make your code cleaner, preventing you from repeating yourself over and over in different projects. I’m not saying you have to extract everything into the packages, no. It’s all about the balance, like in coding. Should I extract that code into the separate method? Or, maybe even into the separate class? Remember those questions? I think “Should I extract that code into the separate package?” is something similar to these questions. It depends. Feel it, and make a decision according to your context and experience.

    There are a lot of aspects, which are not covered in this short article, but I really hope it will be useful for someone. Please, contact me if you have any thoughts or questions.

    Wish you tons of stars on your own packages!

  •    Laracon Online – Last Day For Early Bird Tickets 

    Today is the last chance for you to join over 3,000 developers and get an early bird ticket to Laracon Online for just $10. Each ticket purchase includes access to the live event video, conference swag, and a special Slack channel for hanging out and mingling during the event. With your ticket, you can sit on your couch and watch it all live!

    Laracon Online will be held on March 8th, 2017 with opening remarks at 8:45 AM EST. If you can’t attend that day, all the talks will be recorded and available online for viewing at your convenience shortly after the conference ends.

    Conference Swag

    To bring you the true conference experience we are proud to be partnering with some of the biggest companies in the industry to offer you some awesome digital swag. Here is everything that is already confirmed:


    Linode is offering a $20 discount to everyone on their cloud hosting.


    Nexmo is offering 10EUR or $10.55 off their cloud-based communication APIs. Everything from SMS messaging, to voice, to authentication.


    Deploy Bugsnag to your production application and get a free, limited edition, ultrasoft Bugsnag t-shirt.


    Get a free .co domain registration with email and whois privacy for one year. A $20 value!


    Blackfire is offering 30% off their Profiler and Premium editions. This is for first year of annual subscriptions and valid through March 31st.


    If you make a purchase of Postmark credits within three months of Laracon Online, they’ll double your credits. It doesn’t matter how many credits you purchase. Buy $10,000 in credits, get $10,000 in credits free!

    With early bird tickets at only $10, it’s an awesome deal and the digital goodies more than pay for the price of admission. Get your ticket today before the price goes up to $20 tomorrow.

  •    Laravel 5.5 Will Be The Next LTS Release 

    Version 5.1 was Laravel’s first LTS release and its two-year window of bug fixes are coming to an end this year. There have been a few people questioning if another LTS would be released and version 5.5 would be the next in line if it did happen.

    Just today Laravel announced on Twitter that Laravel 5.5 will, in fact, continue the LTS line:

    Just as the previous LTS this will include two years of bug fixes and three years of security updates.

    For those not familiar with long-term support, these are special versions that are feature locked at the date of release. They do not get any new features but keep getting bug fixes and security updates throughout the maintenance window.



  Solution / 2014年11月29日 23:46


  DB / 2014年11月03日 16:31


  Paginator / 2014年09月27日 22:09


  DB / 2014年09月27日 22:09


  DB / 2014年09月27日 22:09

   Bladeで @while を使用する

  Blade / 2014年09月27日 22:09


  DB / 2014年09月10日 10:56


  Core Extension / 2014年09月10日 10:56


  Testing / 2014年09月09日 00:49


  Testing / 2014年09月09日 00:49


  Service Provider / 2014年09月09日 00:49

   LaravelプロジェクトでTravis CIを使った継続的インテグレーション

  Solution / 2014年09月09日 00:49


  Route / 2014年09月09日 00:49


  Middleware / 2014年09月09日 00:49


  Middleware / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Lang / 2014年09月09日 00:49


  Installation / 2014年09月09日 00:49


  Installation / 2014年09月09日 00:49


  Installation / 2014年09月09日 00:49


  Installation / 2014年09月09日 00:49

このサイトはLaravel Recipesのレシピを日本語訳にしたものと、

View all Packages for your Laravel projects