Hi, I'm Matthieu Napoli!

These are thoughts and experiments about web development and programming.

01 July 2013

Controllers as services?

This post is sort-of a response to the blog post of Benjamin Eberlei about Controllers in Symfony 2.

The subject is about Controllers and their dependencies:

Controllers as a service are a heated topic in the Symfony world. Developers mainly choose to extend the base class, because its much simpler to use and less to write.

With Symfony 2, you can write controllers 2 ways:

  1. extend the base Controller class. This is simpler and more practical but it ties up your controller to Symfony. Also, to fetch dependencies, you have to get them from the container, which is known as the Service Locator anti-pattern (= bad).

  2. create a “normal” class, and use it as a service. That means you can use dependency injection through the constructor to get your dependencies. This is clean, this looks good, but you end up with managing a lot of dependencies :/

To ease up solution n°2, Benjamin proposes to create a “ControllerUtility” class which would group the most used controller services. That way, you dramatically reduce the dependencies, and still hide the container.

I use a different solution.


09 June 2013

Should you really write ugly code? Spoiler: no

I recently stumbled upon François Zaninotto’s blog post: You should write ugly code. While he makes several good points, I strongly disagree with him and I feel the urge to give my opinion on the matter (what did you expect, this is a blog).

The point that he makes is that he encourages developers to write “ugly code”, i.e. code that works and that doesn’t follow best practices or anything related to code quality.

[..] developers shouldn’t care about code beauty, because that’s not their job. Instead, they should focus on creating great products, which is infinitely more satisfying.

Later, he insists that by writing ugly code, we ship faster than if we had to worry and handle code quality. And shipping faster is good for the business.

Well that’s true. That’s called Technical Debt. And like any debt, you’ll have to repay later.



16 April 2013

Overriding dependencies with Composer

At my company, My C-Sense, we use Doctrine amongst other PHP frameworks and libraries. When we find bugs (or need new features), we contribute to the project through our open source initiative.

The problem is when we submit a pull request on Github, several months usually happen until our fix appears in a stable release.

To be able to enjoy our bugfixes immediately, here is our workflow:

  • We fork the repository of the project to our organization account
  • We commit and publish the bugfix in a branch of our repository
  • We submit a Pull Request
  • We override the dependency to the project with our version in Composer

Overriding a dependency is quite simple: just add your git repository in your composer.json and require you branch.

But when we want to override, for example, doctrine/common which is used by doctrine/orm, then we have a problem: doctrine/orm wants a stable version of doctrine/common, it will conflict with your requirement to a dev branch.

The solution is to alias your dev branch to a stable release, and that is possible through the awesome “inline alias” functionality in Composer.



22 March 2013

The “Optional Singleton” pattern

The singleton is a practical design pattern, that’s the reason it is so popular amongst beginners. It is also an anti-pattern because of the problems it introduces (global state, difficult to test, …).

While I agree with that, and the fact that Singletons should be used with (a lot of) moderation, I also like an alternative pattern which comes with the advantage of the singleton and balances out its disadvantages. This can be useful if you have to work on a codebase that has singletons.

I’m calling this pattern the Optional Singleton for lack of a better name.

Simply put, this is a class which you can use as a singleton, or not (it’s optional ;):

  • you can still use the handy MySingleton::getInstance()
  • you can however create new instances of the class, for example for tests

05 March 2013

jQuery plugin: Confirm dialogs for HTML links and buttons

This is the first open source project created at my company, so I am quite proud of it even though it is not much.

The name is jquery.confirm, which is pretty explicit. It lets you have confirmation dialogs for links or buttons. For example, “Are you sure you want to delete that comment?” kind of things.

I am going to present its basic usage and options here.

The idea is to write unobtrusive Javascript by letting the user write clean HTML:

<a href="home" class="confirm">Go to home</a>

To enable confirmation on this link, simply:

$(".confirm").confirm();

04 February 2013

Be a better programmer: take a step back

Replace [client] by [boss] or anything of the kind if you prefer.

A day at work

Bug #3890 from Client

There is an application crash, it says “division by zero error in SpeedCalculator::compute()”.

Please fix ASAP!



06 December 2012

Introduction to Dependency Injection with a real life example

This example is an introduction to the Dependency Injection concept. It is based on the PHP library PHP-DI.

Classic implementation

Given you have:

class GoogleMapsService {
    public function getCoordinatesFromAddress($address) {
        // calls Google Maps webservice
    }
}

class OpenStreetMapService {
    public function getCoordinatesFromAddress($address) {
        // calls OpenStreetMap webservice
    }
}

The classic way of doing things is:

class StoreService {
    public function getStoreCoordinates($store) {
        $geolocationService = new GoogleMapsService();
        // or $geolocationService = GoogleMapsService::getInstance() if you use singletons
        return $geolocationService->getCoordinatesFromAddress($store->getAddress());
    }
}

Now we want to use the OpenStreetMapService instead of GoogleMapsService, how do we do? We have to change the code of StoreService, and all the other classes that use GoogleMapsService.

Without dependency injection, your classes are tightly coupled with their dependencies.