I started working a few months ago on MetaModel, a language that enables to traverse and operate your PHP model.
Today I’m going to show you how you can use MetaModel through the MetaConsole to debug your application.
When working with Composer and git branches, you will end up either:
because composer.json may have changed between branches.
To have composer automatically re-install dependencies when you switch to a branch, simply create a .git/hooks/post-checkout file in your project repository:
Hi, I'm Matthieu Napoli!
#!/bin/sh
cd $GIT_DIR/..
composer install
This is a git post-checkout hook (as the name suggest)
So you chose to test your application using unit/functional tests.
How do you ensure your tests do indeed test what you expect?
Fear not! Here comes TestsTester!
This blog was running on Wordpress. And I hated it.
Writing an article was really not funny, especially when I needed to include some code!
In 2013, what’s the best way to write down text and code? Markdown!
Using the Domain Driven Design methodology, I sometimes end up on such a situation: a behavior in a model class is complex and involving other classes. It’s time to put that behavior in a service (or a factory if the situation applies to a constructor).
The problem is that in my service, I am not in the context of the domain class. If I move Foo::something() into FooService::something($foo), then I can’t access private properties of Foo, thus limiting me to the public API of Foo.
Now I end up adding accessors, thus breaking encapsulation and complexifying everything where all I wanted was improving the code.
VB.Net has a concept of “Friend” visibility, i.e. if A is friend with B, then A can access private properties of B (or something like that it’s been a long time :p). PHP doesn’t have such a concept natively, but here is a tryout to apply it with workarounds.
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:
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).
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.
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.
You have a PHP project hosted on GitHub with continuous integration using Travis-CI?
How about setting up code coverage reports?
For example, here is the code coverage report of PHP-DI: 
(click on the link to see the details).
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:
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.
Every developer knows this joke:
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
I can’t help but share the great series that I read on twitter tonight: