PHP Developers Who Have Inspired Me

Standard

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!

On Laravel’s Future

Standard

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!

Interop & Common Names

Standard

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.

Crazy?

Full IoC & Unit Testing With Laravel

Standard

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!

 

Response: Don’t Use Facades

Standard

This afternoon an article was posted to Reddit that cautioned users of Laravel to stop using “Facades”.

In the context of Laravel, Facades are what you are using when you make what appears to be a static call to a class. For example:

Route::get('/', 'HomeController@showWelcome');

However, as many of you are already aware, this call may be rewritten like so:

$app['router']->get('/', 'HomeController@showWelcome');

The code may be written easier way because, at their core, facades are syntactic sugar for service location. When you make a call to a Facade, the Facade resolves the underlying class out of the Laravel IoC container and calls the intended method on the instance. They provide a very terse, expressive syntax, while still maintaining the ability to test your code.

However, service location can lead developers into some bad architectural habits. For instance, since service location is very “easy”, it can lead to responsibility bloat in your classes. Generally, classes with small, focused responsibilities are to be desired since they are easier to understand, test, debug, etc. However, if you are using Facades to push to the queue, send an e-mail, and validate some data all within a single class, that class’ core responsibilities are obscured. It is concerned about way too many things.

It is possible to use Facades responsibly and keep your class responsibilities narrowly focused. However, some prefer the discipline that constructor injection provides. Constructor injection means that a class’ dependencies are injected via the constructor when that class is created. It is an explicit declaration of what that class needs, and therefore gives an idea as to what that class does.

Before today, injecting the underlying class behind a facade required some explicit bindings to be registered in the IoC container; however, starting today, it is now just as easy to inject your dependencies as it is to use a Facade. By simply type-hinting the class underlying the Facade, it will automatically be injected by the container when it is needed as a dependency.

For example, need an instance of the Session injected into a controller? Just do this:

<?php

class HomeController extends BaseController {

	public function __construct(Illuminate\Session\Store $session)
	{
		$this->session = $session;
	}

}

There is no longer any need to do any extra configuration. Since all controllers are automatically resolved by the Laravel IoC container, the session instance will automatically be injected. Injecting the class underlying the Facade is just as easy as using the Facade itself! If you love using Facades, keep on using them, just keep an eye on those class responsibilities! If you prefer constructor injection, it just got a heck of a lot easier!

If you’re not sure what class to type-hint, check out the Facade To Class Reference from the Laravel documentation.

Enjoy!