DI container and IDE integration

Say we use a DI container directly, i.e. via functions like get() or make(), how do we achieve proper IDE support? For example I create a class instance the usual way

$server = $this->container->get(Server::class);

and I want to know what methods my Server class provides

$server-> ???

I could use docblocks

/** @var Server $server */ 
$server = $this->container->get(Server::class);

This works fine in many IDE like PhpStorm:


however the docblock is somehow annoying to me. The IDE *should* really know what class instance the variable $server is, since everything it needs to know is in the class name constant I provided as parameter for the get() function.

There might be a way using the hardly known .phpstorm.meta.php file for PhpStorm, but that one is currently some sort of under construction – at least I couldn’t get it working properly. Hopefully the PhpStorm guys will extend the documentation soon!

Once again, the PHP community provides the solution: the small but pretty cool PhpStorm PHP-DI plugin does exactly what we need! Now PhpStorm knows that $server is an instance of the Server class without me needing to do any further work:


Class name constants should be used wherever possible nowadays, however it also works with the Fully-qualified class name as string:

$server = $this

But really, you shouldn’t do that. Please. Better just forget what I said. Forget it. Begone!

Awesome! Although actually written for the PHP-DI container, it also supports container-interop and even that crapp… I mean lovely but omnipresent Laravel App Facade sort of jun… container… thing.

I’d recommend to use DI containers directly only in very few places like Application bootstrapping or factories. But imagine you have to deal with a legacy Laravel 4.2 application which uses that awful App::make() basically EVERYWHERE, you are happy about any help.

npm & Windows

Again, Windows can cause problems you would not have expected. In npm versions prior to 3, npm stores dependencies in deeply nested folder structures, causing errors on running ‘npm install’ such as

npm ERR! Error: EPERM: operation not permitted,
open '/var/www/my_longnamed_app/node_modules/

Obviously, this is a ridiculously long path and exceeds 260 characters – and Windows can’t handle that. Not sure why “they” (you know … MS…) came up with that idea, and why this is still not fixed in a modern OS like Windows 7 (I did not try versions above that). I guess it is just the pure essence of evil, the same diabolic power which brought the Internet Explorer amongst us. Let them burn, let them suffer, and let even pay money for it!

Even when you run npm on Linux in a VM on Windows with a Shared folder, you will still suffer from that. Oh, you beasts from the abyss, how … ok I’ll stop.

Luckily, npm3 supports flat dependencies, i.e. all dependencies are written into the top level of the node_modules folder. So if you run into the above problem, try

npm --version

If this still says 2.x, consider updating to npm3:

npm install -g npm

Delete your node_modules folder (not sure if this is really needed, but better go sure), then run

npm install

and all dependencies get installed without errors. Yay!

If you dare, you can have a look into the node_modules folder now. You’ll find loads of folders – the beauty of flat dependencies.

Debug shell scripts (well, kind of)

I have to look up this one frequently, because it is really helpful.

If you want to see what lines of a shell script are actually executed, place this line in your code:

set -x 

I usually do that after the funny thing called Shebang (#!/bin/bash – I can also never remember this one correctly), but surely you can place it right before the section where you expect the problem. If you have an idea where the problem might be, that is. If not, just start from the beginning.

Cool thing: the variables are replaced in the output, or as the man page puts it:

Print a trace of simple commands and their arguments after they are expanded and before they are executed

Microformats – control what Google shows on the Search Results page

Yesterday I learned about “Microformats“. Microwhat? Sounds suspicious!

Well, at least that was my reaction. I’ve to admit that I don’t care much about SEO and Google and so on (I’m a PHP backend developer, Goddamit!), but this is really interesting topic one should at least have heard of. In short, it allows you to have influence on what is displayed on the Google results page. Worth its weight in Gold, I guess. Some of the ancients amongst us might remember the good old Metatags. It’s not the same, though.

So here’s a link that explains Microformats pretty well: