There is no such thing as a perfect employee match in programming. If you write a list of technologies in the job description and expect to find a candidate with the all right experiences, you will be strongly disappointed. You could spend months or years searching, while overlooking very good candidates just because they lack one or two skills.

New technologies are coming out each hour and it’s impossible to keep up with absolutely everything. Developers make choices based on what they think will become a trend in the near future or based on what seems most useful. They are also exposed to some technologies regardless of whether it’s a good or a bad choice, because they are often not the ones making these decisions in a project. Since each person’s journey is different, the permutations of skills are incalculable.

IT projects require a multitude of technologies. A project can require experience in a specific framework, ORM, CMS, caching tool, automated testing tool, database, continuous integration, deployment, messaging protocol, etc. Also, multiple programming languages are sometimes required. Now multiply languages by the number of language-specific tools. A developer is often expected to have over 20 skills. The possibility of a perfect match is virtually inexistant.

I’ll give you some examples from my own journey. I was once hired to work with the Flex framework. I worked with ActionScript once, language on which the framework was built. I had no direct experience with Flex, the main skill required. I was hired regardless, because there were simply no developers experienced with Flex in the entire province at the time. I read the documentation in two days, I built the software and my employer was happy with his investment.

A scenario like this happened to me over and over again. I did not need direct experience with any technology, because all programming languages are pretty much the same except for syntax and minor philosophical differences. All frameworks and tools follow pretty much the same principles. At the end of the day, you just need logic and willingness to work with new tools.

So what is the solution? Don’t try to hire developers based on a keyword match. That’s just silly. Humans are much more flexible and adaptable than this. Hire them based on their logic, which you can evaluate by discussing anything technical or even non-technical. Hire them based on feedback from past clients or employers. Hire them based on enthusiasm and attitude in general. Hire them because they can think.

I'm still ready & willing to hire a #PHP internals coder to work on PHP fulltime. Amazing place to work: http://t.co/GX4wtPSc
— Don MacAskill (@DonMacAskill) January 18, 2013

This article is part of a series of articles that explains how to pack a Symfony full-stack application in one file. The first article explains why this might actually be useful: 1) Introduction, 2) Bootstrapping, ...

The most common way to create a Symfony project is to start with the Symfony Standard Edition: it defines a sensible directory structure for your project and it make things a lot easier when someone want to take over an existing project as he knows where the templates, the controllers, or the configuration are stored. So, let's start our journey with the Symfony Standard Edition:

$ composer.phar create-project -n symfony/framework-standard-edition se/ 2.3.0

From there, let's remove a bunch of code to get the bare minimum of code needed to keep it working:

rm -rf LICENSE README.md UPGRADE* bin/ app/SymfonyRequirements.php \
       app/autoload.php app/bootstrap.php.cache app/AppCache.php app/check.php \
       app/console app/phpunit.xml.dist app/Resources src/ web/config.php \
       web/favicon.ico web/robots.txt web/apple-touch-icon.png web/app.php web/bundles/ \
       app/cache/* app/log/* .travis.yml app/.htaccess web/.htaccess
 

I've removed all those files and directories because there are not needed for the purpose of our challenge.

Next, let's simplify the configuration and move everything into just one file:

# app/config/config_dev.yml
framework:
    secret:          $ecret
    router:
        resource: "%kernel.root_dir%/config/routing_dev.yml"
    form:            ~
    csrf_protection: ~
    validation:      { enable_annotations: true }
    templating:
        engines: ['twig']
    session:         ~
    fragments:       ~
 

The routing_dev.yml file has been emptied for now, and all other configuration files have been removed.

We can also remove most of the bundles from the application kernel class:

use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Config\Loader\LoaderInterface;
 
class AppKernel extends Kernel
{
    public function registerBundles()
    {
        return array(
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new Symfony\Bundle\TwigBundle\TwigBundle(),
        );
    }
 
    public function registerContainerConfiguration(LoaderInterface $loader)
    {
        $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
    }
}
 

We can also simplify the web/app_dev.php code:

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Debug\Debug;
 
require_once __DIR__.'/../vendor/autoload.php';
Debug::enable();
 
require_once __DIR__.'/../app/AppKernel.php';
 
$kernel = new AppKernel('dev', true);
$request = Request::

Truncated by Planet PHP, read more at the original (another 2876 bytes)

So… I didn’t write much since April.  I took a bit of time off and went to Russia (some pics here - more to come later), and have been finishing up some contracts in May/June, and am now looking for the next thing to sink my teeth in to, so to speak (ping me if you’ve got an interesting project you think I might be a fit for).

We’ve got an interesting talk on PHP’s Composer project slated for our next PHP user group in Raleigh with our very own Jason Grimes - definitely looking forward to this one (come on out if you’re anywhere near the area!)  If you don’t follow Jason already, get to it – he’s got a lot of useful stuff on his blog.

The indieconf conference for web freelancers is coming again this year – still nailing down a date – but the call for presenters is open right now – submit your proposal to present if you’re interested in joining us this year!

It’s hard to believe 2013 is almost half over already!!!

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Get notified when the book is available!

This article is part of a series of articles that explains how to pack a Symfony full-stack application in one file. The first article explains why this might actually be useful: 1) Introduction, 2) Bootstrapping, ...

Sometimes, I'm wondering if I'm not just completely crazy. I like small things, but I'm the author of Symfony, a not-so-small framework (about eighty thousand lines of code excluding comments as of today). And that's probably because I like to push the limits of what's possible when coding.

In 1985, my first useful piece of code was about managing a portfolio of stocks for my parents. I was twelve years old at that time. I won a contest. It was an interesting challenge: coding a full game in less than 10 lines of code. And my code was published in a French magazine.

In 2009, I tweeted an implementation of a dependency injection container in less than 140 characters (I did the same with a web framework).

And most of the time, those experiments helped me get to the next level. Twittee, my service container that fits in a Tweet, was an experiment, but then, it became Pimple, a small dependency injection container that is used today in Silex, a micro-framework based on the Symfony components.

So, that's not about just trying to push the limits, or trying to have fun. It's also about experimenting different approaches to known problems and see if they can have practical usage.

So, 2013... time for another challenge, right? What about packing a Symfony full-stack application in a single file. No Silex, no phar allowed, no compilation phase, just everything in a single readable file: from assets to controllers, from templates to Composer configuration.

Why?

This is yet another step toward my Quest of the PHP Holy Grail. But besides being a though challenge, there are many other reasons that makes it interesting for everyone.

First, that's a good way to learn more about the Symfony internals and especially about the Kernel class. Nowadays, thanks to all the talks about HttpKernel given by various speakers at various conferences, and thanks to my series of articles about it on my blog, a lot of developers understand how Symfony handles requests and how it manages the conversion to responses. There is even a full chapter about it in the official documentation.

But the Symfony Kernel is less well-known. This is a shame as it is also a very interesting piece of software. I hope that this challenge will give you more information about the Symfony Kernel and that, as a result, more Open-Source projects will adopt it instead of just using the components.

Then, I want to showcase once more the flexibility of the Symfony core framework and the decoupling between all aspects of the framework. If you are just a Symfony developer, you might not realize how the low level architecture of Symfony works, and I'm going to give you some insights about it.

Also, there is a more practical usage: bug reporting. When you report a Symfony bug, sometimes, it is not that easy to reproduce it. Probably because it involves third-party bundles, a specific configuration, or a chain of controller calls. For such bugs, it is almost impossible to make a patch without a way to reproduce it. As a matter of fact, we often ask reporters to fork the Symfony Standard Edition and modify it in a way that exhibits the issue. But doing so is tedious for both the reporter and the developer that will try to fix the bug. Doing the same with Silex is more easier as most of the time, the reporter is able to package everything is a single file. So, being able to do the same with the full-stack framework would be a huge step forward.

Reporting bugs is fine, but being able to experiment things in a small environment also helps. A few weeks ago, Jordi submitted a new API layer to simplify the configuration of Symfony's Security. To better understand how to use it and to get a feeling for the new API, I decided to create

Truncated by Planet PHP, read more at the original (another 2550 bytes)