In the past, fishermen have used the color of the morning sky to predict if the day’s weather will be suitable for sailing. Like the fishermen, I’ve found that the day’s beginnings paint a preview of its course. Start positive, and it’s easier to ride the good vibes for the rest of the day.
I asked the Twitterverse how they start the day. Here are a few common responses:
- Reading A Religious Text.
- A Good Breakfast.
- Watching Funny YouTube Videos With Co-Workers.
- Listening To Relaxing Music.
For me, I’ve found meditation / silence helpful. It’s a time to gather my thoughts and take some deep breaths. Once my mind is clear, it’s easier to approach the day with a positive attitude!
Tonight I want to write a quick post and mention a few PHP developers who have inspired me lately. I’ll name them and share a few reflections on how they have inspired me over the past few months.
- Fabien Potencier (@fabpot) – Fabien is the project leader for Symfony. He manages a very large PHP project, and he does it very well. He’s humble and professional. I want to better imitate those characteristics.
Ross Tuck (@rosstuck) – Ross spoke at the recent Laracon in Amsterdam. Watch the video at http://laracon.eu. I’ve thought about his talk many times since. He’s incredibly intelligent, thoughtful, and one of the best speakers in the PHP community.
Yitzchok Willroth (@coderabbi) – Yitzchok has become somewhat of a personal advisor to me. He gives thoughtful advice, challenges me, and encourages me with his wisdom.
Michelle Sanver (@michellesanver) – Michelle showed Dayle and I around Zurich for a few hours, and recently spoke at Laracon EU. She’s quiet, but ridiculously smart. She’s building a really cool project called OmNomHub – it’s like GitHub for recipes.
Kayla Daniels & Ed Finkler (@kayladnls – @funkatron) – Both of these talented developers are raising awareness of mental illness, and encouraging those suffering to seek the treatment they need for healing. Mental illness is one of the most debilitating diseases on the planet, and I really appreciate the work these developers are doing to combat it.
Igor Wiedler (@igorwhiletrue) – Igor is always doing something cool things that twist my brain. He’s very humble, and an all around nice guy. I always enjoy reading over his latest code.
Mior Muhammad Zaki (@crynobone) – Mior and I talk about Laravel a lot. He listens to a lot of ideas and helps me sharpen them. He lives on the bleeding edge of Laravel quietly making sure everything is up to snuff – and never complains about anything.
Matt Stauffer (@stauffermat) – Matt is a great friend. He gives great technical advice about Laravel. But, more than that, he gives me great life advice.
Konstantin Kudryashov (@everzet) – Konstantin is way smarter than me. He recently spoke at Laracon EU and gave me great feedback for improving areas of Laravel 5. One day I want to write code like Konstantin!
Of course, there are so many other awesome PHP developers out there, and so many of you have impacted me in a positive way. Maybe I’ll do one of these posts every month to keep spreading the love!
This summer marks the third anniversary of Laravel’s release. It has grown very quickly, and I think its future is very bright. In many ways I feel like “the best is yet to come”!
However, as Laravel has grown, it has become more difficult to maintain. With the launch of other “products” such as Forge, Cashier, Envoy, and Homestead, the time commitment required to maintain Laravel has grown substantially. Because of this, most of my time spent on Laravel has simply been managing issues and pull requests on the main Laravel repository. However, a key part of my vision for Laravel is to continue innovating and making it more enjoyable than ever to write robust, powerful, and maintainable applications.
As many of you know, I have spent the last several years working full-time at UserScape, primarily working on building Snappy. For about the past year, UserScape has also graciously allowed me to devote Fridays to Laravel, which has allowed me time to catch up on Github issues and pull requests.
However, I will now be moving to a part-time role at UserScape, and will divide my time evenly between UserScape and Laravel.
This transition means that I will spend every other week fully focused on Laravel, drastically increasing the amount of time I am able to devote to the framework and the surrounding ecosystem. With this change, I will be able to devote more time to Laravel than I ever have in the past, which is incredibly exciting!
In closing, I’m very thankful to Ian Landsman and the UserScape family for their investment in Laravel thus far (both financially and as a friend), and am thankful for this opportunity to continue working on two products I deeply care about!
I’ve noticed a trend in various interop projects. Often, the proponents of the proposal will “poll” or observe various frameworks and try to pick the most common name in existence for the various interface methods. For example, in a Container interop proposal, the “get” method name might be chosen to retrieve a service from the container.
However, within the context of PHP, this approach couldn’t be more flawed. In my opinion, it’s the exact opposite of what they should be doing. A more verbose, less common name should be chosen. Here’s why.
In languages like C# which support method overloading, the same function may be defined multiple times with a different signature. For example:
public function get(String service);
public function get(String service, Boolean fresh);
So, in a language with overloading, it doesn’t matter as much what method names an interop interface chooses. If I already have that method with a different signature, it doesn’t matter. The same method can be defined multiple times as long as they have different signatures.
This is not possible in PHP. I can only define the method once with a single signature. Since most containers use a “get” method, using that name in an interop interface greatly limits the actual implementation that can ever be achieved by that container without choosing another method name (which might break backwards compatibility). Even if the two signatures do not conflit now, what if they do later? It is better if the interop interface selects a more verbose, less common name like “resolveService”, while the implementations use the more common “get” method to provide their own unique signatures and implementations. Most likely, the “resolveService” method would simply call “get” with a standard set of parameters.
Over the past few weeks, there has been some discussion about dependency injection, service location, and Laravel facades. So, I thought I would put together a quick video to demonstrate how Laravel supports both service locating facades and full-on, thorough dependency injection. In fact, not only does it support it, Laravel is one of the only full-stack frameworks that offers thorough IoC (even for controllers) out of the box. I also included basic unit tests. No facade calls in the entire application.
Enjoy and be sure to watch in 1080p HD!