Alexandre Salomé

Test your commands in Symfony2

Mon, 26 Dec 2011 00:00:00 +0100

Console application is very useful when dealing with a web application. For example, in a personal project I'm currently working on, I created a bunch of commands to setup some parts:

$ php app/console myproject:user-create "Alexandre Salomé" alex 'alex@example.org'
User created
$ php app/console myproject:user-role-add alex admin
User role created

The problem is that we don't really know how to test them. If you inject dependencies into it, you can test dependencies and rely on a thin-enough command class.

But if you have more logic in it, you should better test it.

Unit or functional?

To unit-test it, you have to know which dependencies are required. In Symfony2, to execute a Command, you need to have a kernel and a container in it. If your command relies on services, each service need to be mocked, too.

In my opinion, it's too much services to be unit tested. So let's go ahead for a functional test.

Functional tests will launch the application in the "test" environment, like WebTestCase. Also, we will extend this class for the CLI tests.

Code, please

<?php

namespace Acme\Bundle\DemoBundle\Test;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
use Symfony\Bundle\FrameworkBundle\Console\Application;
use Symfony\Component\Console\Input\StringInput;
use Symfony\Component\Console\Output\StreamOutput;
use Symfony\Bundle\FrameworkBundle\Client;

/**
 * Base class for testing the CLI tools.
 *
 * @author Alexandre Salomé <alexandre.salome@gmail.com>
 */
abstract class CommandTestCase extends WebTestCase
{
    /**
     * Runs a command and returns it output
     */
    public function runCommand(Client $client, $command)
    {
        $application = new Application($client->getKernel());
        $application->setAutoExit(false);

        $fp = tmpfile();
        $input = new StringInput($command);
        $output = new StreamOutput($fp);

        $application->run($input, $output);

        fseek($fp, 0);
        $output = '';
        while (!feof($fp)) {
            $output = fread($fp, 4096);
        }
        fclose($fp);

        return $output;
    }
}

Sample, please

<?php

 use MyProject\MyProjectBundle\Test\CommandTestCase;

 class MyTest extends CommandTestCase
 {
     public function testDefaultDoesNotInstall()
     {
         $client = self::createClient();
         $output = $this->runCommand($client, "myproject:user-create alex 'Alexandre Salomé' 'alex@example.org'");

         $em = $client->getKernel()->getContainer()->get('doctrine')->getEntityManager();

         $user = $em->getRepository('MyProjectBundle:User')->findOneBy(array(
             'username' => 'alex'
         ));

         $this->assertContains('User created', $output);
         $this->assertEquals('Alexandre Salomé', $user->getFullname());
         $this->assertEquals('alex@example.org', $user->getEmail());
         $this->assertEquals(true, $user->getIsActive());
     }
 }

Here we are, we can now test our CLI edge cases and make the CLI command tools part of the test coverage.

PHP Tour Lille 2011

Sun, 27 Nov 2011 00:00:00 +0100

On november 24th, it was PHP Tour in Lille. It was the first time I was speaker in a conference.

I had a great moment during those 2 days and met a lot of friendly people during the event. I hope to have other opportunities of speaking at conferences.

Magento - Intégration continue, tests et automatisation

And finally, a presentation talking about Magento and best practices in a Magento project.

In first part, presentation is about developing in Magento, how to approach the critical question of resources. It talks about great resources in Magento, and being critical about informations we find.

The second part is a technical part with concrete examples available on Github. It explains how to automatically install the project, setup fixtures and automated tests in the project.

During the conference, every sample code was live demonstrated.

Like one guy said at the end of the presentation: all informations in this presentation is not only appliable to Magento, but also to any project.

Slides are available on speakerdeck (french slides) and code is on Github (see branches).

Mocks, Stubs, Tests

The other presentation was mainly prepared by Marc Weistroff who could not attend the conference. So I replaced him for the presentation.

Tests: why we create tests, meaning of tests
Code coverage: bad indicator, how to interpret
Design: how to create clean code
Mocks, Stubs: the PHPUnit API

Slides are on speakerdeck

Last News From October 2011

Sun, 06 Nov 2011 00:00:00 +0100

During the last weeks, a lot of things happened on my side.

Article in MISC magazine

It took me some weeks to tell it, but I've written an article for MISC Magazine. This article appears in the edition of October/November.

MISC Magazine is specialized in security and very reputated in France for his advanced articles about security. This special edition "A l'assaut du Web" is about security for the Web.

I thank Fabien Potencier for giving me the opportunity to write this article and his support for it.

This article is called "Prise en compte de la sécurité dans un framework PHP : le cas Symfony2", which means "Handling security in a PHP framework: the Symfony2 case".

It details common security problems when dealing with Web applications (SQL Injection, CSRF attack, XSS...). For each one, it explains the problem, the raw PHP solution and finally the Symfony2 approach.

So if you are french, run to your library and buy it! If you're not in France, Buy it online.

Conference about Magento in some weeks

I also practice Magento on my lost hours, and I prepare a conference for PHP Tour Lille 2011. The conference is on November 25th, 2011.

This conference is in french and is called "Magento - Tests, automatisation et intégration continue". It means "Magento - Tests, automatisation and continuous integration".

It will talk about how to automate a Magento project and how to create some clean code. It will provide some samples for clearly coding with Magento. Code and slides will be published after the presentation.

PHP Selenium Library integrated in Mink

Some weeks ago, I introduced a PHP Selenium Library, in a clean PHP 5.3 code. It is now part of Mink, a library used by Behat.

For the moment it's still in the development branch, but next release of Behat will integrate the library for Selenium automation.

Website: A new section and a new theme!

If it's the first time you come to this website, you won't notice it, but before those new fresh colors, it was a monotone with big texts.

Thanks to people for being polite, but I admit that the previous theme was not very fun, and little bit boring.

I refreshed it with some new colors, and I created a new sections called Books containing the list of books I've read. For the moment it's only a short description. Progressively, I will integrate a quick review for each one. I hope you will find some great books to read in it!

PHP Selenium Library

Sat, 08 Oct 2011 00:00:00 +0200

I've just created a PHP library for Selenium! It provides some basic features :

Fluid interface
IDE code-completion
Independant library

For the moment, it's very basic (but it works).

I plan to add some extra features later like context management, integrations into Symfony2, maybe Mink too.

Sample code

<?php
require_once __DIR__.'/autoload.php';

$client  = new Selenium\Client();
$browser = $client->getBrowser('http://alexandre-salome.fr');

// Starts the browser
$browser->start();

$browser
    ->open('/')
    ->click(Selenium\Locator::linkContaining('Blog'))
    ->waitForPageToLoad(10000)
;

echo "Page title: ".$browser->getTitle()."\n";

Available on Github : https://github.com/alexandresalome/PHP-Selenium

Generate mails with Twig

Wed, 28 Sep 2011 00:00:00 +0200

Yesterday, I discovered a new way for generating mails with Twig, in a very powerful way.

The problem

It started because of someone explaining me he was using something similar to this:

<?php
// Subject was loaded from a yaml file
$subject = 'Welcome to newsletter, %%customer_name%%';

$values = array(
    '%%customer_name%%' => $customer->getName(),
    '%%customer_mail%%' => $customer->getMail()
    // ...
);

foreach ($values as $name => $value) {
    $subject = str_replace($name, $value, $subject);
}

For generating the content of the mail, it was something like this:

<?php
$twig = $this->get('twig'); // a Twig_Environment instance
$bodyHtml = $twig->render('mail_newsletter.html.twig');
$bodyText = $twig->render('mail_newsletter.text.twig');

The problem with this solution is that you have two different types of templating engine. The first one is a PHP str_replace templating engine and the second one is Twig.

After some searches, I finally discovered a powerful way for generating mails:

The solution

First, you need to create a template, let's assume mail.twig:

{% block subject 'Welcome to newsletter, ' ~ customer.getName() %}

{% block body_html %}
    This is the <strong>HTML body</strong>.
{% endblock %}

{% block body_text %}
    This is the text body.
{% endblock %}

This is perfect: in one file, we have every informations for generating the mail content.

Let's see now how to fetch it from Twig:

<?php
$twig = $this->get('twig'); // Twig_Environment

$template = $twig->loadTemplate('mail.twig');
$parameters  = array(
    'customer' => $customer
);

$subject  = $template->renderBlock('subject',   $parameters);
$bodyHtml = $template->renderBlock('body_html', $parameters);
$bodyText = $template->renderBlock('body_text', $parameters);

And now, you have everything for creating your mail message, created from one file only.

This also means you can use in your template every Twig possibilities, like the translation extension, or the inheritance mechanism of templates.

Integration in your application

Now, we have a raw PHP implementation, let's see how it's possible to integrate it in your application.

The idea is to create a class for preparing the Swift message, so in the end we only need to set the receiver, and that's all!

A mail generator :

<?php
class TwigMailGenerator
{
    protected $twig;

    public function __construct(Twig_Environment $twig)
    {
        $this->twig = $twig;
    }

    public function getMessage($identifier, $parameters = array())
    {
        $template = $this->twig->loadTemplate('mail/'.$identifier.'.twig'); // Define your own schema

        $subject  = $template->renderBlock('subject',   $parameters);
        $bodyHtml = $template->renderBlock('body_html', $parameters);
        $bodyText = $template->renderBlock('body_text', $parameters);

        return Swift_Message::newInstance()
            ->setSubject($subject)
            ->setBody($bodyText, 'text/plain')
            ->addPart($bodyHtml, 'text/html')
        ;
    }
}

For using it, very simple: suppose you have organized your mails according to the schema mail/<identifier>.twig, the code to use it would be:

<?php
$twig = $this->get('twig');     // Twig_Environment
$mailer = $this->get('mailer'); // Swift_Mailer

$generator = new TwigMailGenerator($twig); // Can be in a DIC

$message = $generator->getMessage('newsletter', array(
    'customer' => $customer
));

$message->setTo($customer->getMail());
$mailer->send($message);

That's all for the suggested implementation! No need to create a dedicated bundle for it, or some kind of reusable code. There are 20 lines of code, just integrate it in your application to fit your needs, and it's enough.

Enjoy Twig!

Sass, Compass, and Assetic in 10 minutes

Sun, 31 Jul 2011 00:00:00 +0200

CSS are boring for most of the developers. They don't like it. They prefer development, because they hate supporting Internet Explorer, they find no pleasure in writing CSS and they are right : CSS is boring. Writing CSS means most of the time repeating code, supporting browsers and creating static code.

There are also the frontend required optimizations, who prevent the developer from generating beautiful and DRY CSS : sprite generation, put all CSS in one file, compress assets, and so on.

Most of the time, they prefer to have a "ready-to-use" HTML production. This approach is not the most optimal, because you need to adapt CSS, to add new rules, to refactor some parts. CSS are part of the application, as the PHP, as the HTML. When a separation like this occurs, lot of time is spent fixing CSS issues, and going through the CSS sounds like a headache.

Once upon a time, some people created some concepts for the development : Don't Repeat Yourself, Keep It Simple Stupid. Those concepts looks like forgotten when developers create CSS.

Let's see how to bring them back to the scene, let's power the CSS production.

1. Small files, please

First, whatever the context is, when you produce some code : create small and separated files.

For example, the CSS on this website, the files are separated by purpose, as isolated as possible :

reset.css
main.css
banner.css
header.css
footer.css
etc.

When I search something, I know the file to open, The feature is isolated. The refactoring of a feature would be fast, easy and isolated enough.

2. Sass : it's f#~king awesome

Sass is an extension of CSS adding new features to the language : mixins, variables, inheritance and more.

A Sass file looks like this :

@mixin message-color($color, $bg)
    color:            $color
    border:           1px solid $color
    background-color: $bg

#messages

    .error, .success
        margin:           1em
        padding:          1em

    .error
        @include message-color(red, #ffaaaa)

    .success
        @include message-color(green, #aaffaa)

Sass allows to produce meaningful stylesheet code. Here we see different concepts in Sass. But to be fully impressed by Sass, you should visit the website and see examples.

The main idea is avoid repeating or computing values. Each time you are about to repeat something (a selector, a CSS ruleset), there is a method for it in Sass.

For example, to avoid computing :

$headerHeight: 50px
$menuHeight:   20px

#header
    position: relative
    height:   $headerHeight
#menu
    position: absolute
    top:      $headerHeight - $menuHeight
    right:    0
    height:   $menuHeight

Here you can modify later the $menuHeight or $headerHeight, there is no need to modify 20 different lines, no need to search where the value is used, and no meaningless value in your CSS (height: 42px, what's this value ?).

Another useful command, when you already have existing CSS is sass-convert. This command will convert to CSS to Sass files :

sass-convert my-file.css my-file.sass

This command has no magic inside, and cannot guess computed values, but it's a good start for Sass.

I already had many small CSS files for this website, converting them to Sass was a 30-seconds task.

3. Compass, a framework over Sass

Sass provides the language. Compass provides the tools ! Compass is a CSS authoring framework. It provides you helpers and utilities like image-width, and sprite-* methods. A reference guide is available with every methods.

A quick-example of features available with it :

@include "compass/reset" // Reset CSS
$logoUrl: "/logo.png"
$bgColor: blue

#header
    color: $bgColor
    background-color: lighten($bgColor, 40%)
#logo
    width:      image-width($logoUrl)
    height:     image-height($logoUrl)
    background: url($logoUrl)
    span
        display: none

Sprite-generation also become very easy with Compass. Here's a small sample of sprite-generation used for the menu of this website :

$menu: sprite-map("sprites/menu-*.png");
#menu
    li
        background-image: sprite-url($menu)
    li.blog
        background-position: sprite-position($menu, "blog")
    li.cv
        background-position: sprite-position($menu, "cv")
    li.contact
        background-position: sprite-position($menu, "contact")

Awesome, heh ?

The sprite-image is generated automatically, so no need to refactor the CSS and the sprite-image when you modify an image.

4. Assetic : the magic key

Kris Wallsmith created an awesome tool for asset management : Assetic. For a brief introduction on "how it works" and "what's in it", please see his presentation on Symfony Live (slides here).

First of all, separate two things : Assetic and AsseticBundle.

Assetic is the library providing the filters, the asset manager, the formula loader, and so on. It comes with many pre-configured filters for Sass, Compass and others. It also provides the tools for combining assets.

AsseticBundle is the integration in Symfony2 providing iteration of templates to find formula, automatic generation of them in development, CLI tools, and so on.

Sample with Symfony2, Sass & Compass

Let's see how to create a Symfony2 project with some Sass files.

First, install Sass & Compass (cf Sass website and Compass install guide).

Then, enable filters in your application in app/config/config.yml. Here, I indicate to Compass where all my images are located. So when I say url('/images/logo.png'), he knows it means /my/project/web/images/logo.png.

parameters:
    # Assetic
    assetic.filter.compass.images_dir: %kernel.root_dir%/../web/images
    assetic.filter.compass.http_path:  /images

assetic:
    debug:          %kernel.debug%
    use_controller: false
    filters:
        sass:    ~
        compass: ~

Then, create a stylesheets.html.twig containing your assets definition :

{% stylesheets filters="compass"
    "@AlomMainBundle/Resources/assets/css/main.sass"
    "@AlomMainBundle/Resources/assets/css/header.sass"
    "@AlomMainBundle/Resources/assets/css/footer.sass"
%}
    <link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}

And I include it in my layout :

<!- ... -->
<head>
    {% include "::stylesheets.html.twig" %}
</head>

And that's all.

For the development environment, stylesheets are generated automatically. For the production environment, you need to generate assets before, by running :

./app/console assetic:dump --env=prod --no-debug

And that's all.

Conclusion

Mastering CSS is important for a project. Develop them the same way you develop the rest of the application is very important if you want to make the code evolve and want something reusable. This article shows you how to take benefit from modern technologies : Sass, Compass, Assetic, and Symfony2.

Even if you are not using Assetic and Symfony2, Sass & Compass are too awesome to be unused : you can use them for generating HTML templates by using Compass CLI tools.

How To Save Power Battery

Sun, 17 Jul 2011 00:00:00 +0200

Batteries are present in every device : laptop, mobile phone, MP3 player. But after a time (depending of the quality of the battery and the usage), the battery goes down, and you can only use it for 5 minutes. At this moment, you go to Google to find some advices on "how to restore my battery", but... it's to late.

Keep in mind that your battery is a consumable : you will not be able to keep it for ever. Knowing this, you can get some good practises to maximize the lifetime.

This article will teach you how to preserve your battery and how to keep it as long as possible.

Ventilate it

The battery hates heat, so when you are using your laptop at home, do not put it on a pillow or in the bed. Place something flat and rigid below it, to keep a good airing in it.

Also, get used to blow your computer regularly (1 time per year). You can go to a computer store, or buy a dry air bomb and do it yourself.

Avoid extreme temperatures

A good-temperature for a battery is between 10°C and 20°C. Below 10°C and above 20°C can damage your battery.

If you let your computer in a car, you can damage it : if the weather is sunny, your car will become a oven : high-temperatures damage your computer. At the opposite, if it's winter, your car will become a freezer, and low-temperatures damage your computer, too.

Do not use it below 10%

When you go below 10%, you are consuming a lot your battery. The whole battery is exhausted of the previous 90%, and now she has to concentrate a lot to find the rest of energy contained in it.

Take the habit to stop using the machine when it says "hey, my battery is low". At this moment, find a power supply and fill your battery.

Recharge it when it is low, because keeping the battery at a low level is bad.

Do not keep it full-charged

Keeping the battery full-charged for a long time is a bad factor. This fact is meaningful for people who always plug their computer to the power supply : if you don't remove the power supply, remove the battery with 80% in it.

As demonstrated above, there are some factors :

Intensive usage

An intensive usage of your battery is also painful for your battery, especially when the level is low.

When you are on battery, try to minimize activity : minimize the light of the screen, do not do 3D-processing, avoid video games, and so on.

Conclusion

Your battery is a consumable, you will not keep it for ever. But keep in mind those factors (temperatures, intensity, low/high levels), and you can maximize the lifetime of it.

Isolation of tests in Symfony2

Sun, 10 Jul 2011 00:00:00 +0200

For achieving good tests in your project, you will need to have a correct isolation of them. When a test executes, it should leave the application in the same state as when he entered it.

In Symfony2, the most common-case is the database isolation : when we are testing, we expect from our application to isolate the test with a transaction and to rollback it at the end.

Functional tests in Symfony2

In Symfony2, functional testing is achieved with the test client. The test client is responsible of requesting the kernel, and fetching a response from a request.

The test client allows to easily request the kernel and crawl the response.

For example, we can achieve :

<?php
class MyTest extends PHPUnit_Framework_TestCase
{
    public function testSomething()
    {
        $client = $this->createClient();
        $crawler = $client->request('GET', '/test');

        $this->assertEquals(200, $client->getResponse()->getStatusCode());
        $this->assertEquals('Hello', $crawler->filter('h1')->text());
    }
}

The test client handles requests to the kernel and returns crawler, for easing navigation through the returned response.

In Symfony2, the test client is a service of the container. Its service name is test.client.

It is possible to override your test client in your container, to add some custom methods and behaviors, as we will see in the following chapters.

Basic overriding of test client

To simply override the Test client, redefine in your configuration :

<parameters>
    <parameter name="test.client.class">Alom\Website\MainBundle\Test\Client</parameter>
</parameters>

Then, just redefine the test client class, like this :

<?php
namespace Alom\Website\MainBundle\Test;
use Symfony\Bundle\FrameworkBundle\Client as BaseClient;

class Client extends BaseClient
{
}

This way, we can override the test client with our custom methods. For example, we can create a connect method to automatically connect the user to the website.

<?php
// ...
    public function connect($username, $password)
    {
        $crawler = $this->request('GET', '/login');
        // ....
    }

With this method, you can create anything that you need for easing tests of your application.

Isolation of Doctrine

Each time you make a request, Symfony2 creates a new container for it. This means that the Doctrine objects (for DBAL and ORM) are different for each request.

And here is the problem : we have a different connection for each request, so it's not possible to have the same connection for every request of the client.

The solution is to pass the service through different requests, and isolate them in a transaction.

To achieve this, we override the doRequest method of the test client, which is responsible of passing requests to the kernel.

<?php
// ...
    static protected $connection;
    protected $requested;

    protected function doRequest($request)
    {
        if ($this->requested) {
            $this->kernel->shutdown();
            $this->kernel->boot();
        }

        $this->injectConnection();
        $this->requested = true;

        return $this->kernel->handle($request);
    }

    protected function injectConnection()
    {
        if (null === self::$connection) {
            self::$connection = $this->getContainer()->get('doctrine.dbal.default_connection');
        } else {
            if (! $this->requested) {
                self::$connection->rollback();
            }
            $this->getContainer()->set('doctrine.dbal.default_connection', self::$connection);
        }

        if (! $this->requested) {
            self::$connection->beginTransaction();
        }
    }

Isn't it integrated in Symfony2 ?

The answer is no. This code, here is quite simple, 20 lines for achieving what we want, in our project. Integrating it in Symfony2 would mean 100-200 lines for :

Disabling it when Doctrine is not bundled
Add a support of multiple connections
Override the test client when the Doctrine bundle is activated
Add some options for edge-cases : no isolation needed, ODM, etc.

There is also the question of isolation for other services of your application : SolR engine, Web Services, and so on.

The better place for it (in my humble opinion) is in your project. Because even if it's a common case, the implementation is not trivial.

Versioning A Project

Sat, 09 Jul 2011 00:00:00 +0200

Project versioning provides many confort when developing a project : managing concurent developments, keeping an history, easing the release process, isolation of some features, version tagging, unified version for all developers, and so on.

Many systems exist : Subversion, Git, Bazaar, Mercurial... but both systems share some common philosophy, and every informations of this article are true for every versioning system.

Only keep your brain-generated code

The first important rule is to keep only the created code. There is no place for generated code, for example the API documentation : it is generated from your code.

The most dummy reason is to keep the source repository as small as possible. The other reason is the consistency : if you modify your source code without re-generating the API documentation, you will have a difference between the sourcecode and its documentation.

Removing generated code from the repository will also prevent users from modifying them. For example, in symfony 1.4, Doctrine generates base entities. It was very confusing, because they were placed with the sourcecode, and many developers versionned them. Then, someone else started modifying it. At the end, you cannot regenerate entities without breaking the application.

All generated files should be ignored with svn:ignore or .gitignore, or whatever, depending of your versioning system.

This rule is also true when dealing with external softwares. For example, you shouldn't version third libraries, because this is not your code. This will be discussed later in this article.

To conclude, just remember : only version what you created, with your brain.

Environment and security

It's important to identify what's specific to your local environment and what's in the project scope. For example, a folder path is specific to your local environment. The database configuration is also dependent of your environment. Maybe you are using project:project@localhost, and say "Ok, it's the way it should be", but I will tell you : "I don't use a specific MySQL access for each project, because it's boring to create an access for each project".

So, each time you put some code or configuration, the question you must ask to yourself is : "Is this value specific to my instance, or every instance of the project will have this value ?". There will be different instances : development, staging, testing, production, etc. The source code shouldn't be aware of physical environment specificities. And also, never ever-ever-never version something like this :

serverA:
  host: myhostA
  user: userA
  pass: passA
serverB:
  host: myHostB
  user: userB
  pass: passB

This is a also a security problem : it means that any developer of the project will have the production passwords. It also means that on server A, you will have access informations of server B.

The "Security-In-Depth" (future article ?) concept applies here, and you have no valable reason for keeping on server A informations about server B. It's a security lack.

Still concerning the security, no password should be stored in version system : CSRF token, third-service key, etc. All those informations should be configured per-instance, and secured somewhere else.

The main idea is : If a hacker gets access to your sourcecode repository, he shouldn't be able to connect to your services. He should only be able to do a a code-review.

Good practices

Atomic commits

Every commit should be as small as possible (until it makes sense). For example, if you are developing the feature "User account", a correct commit-stream could be :

Modelization of user
Fixtures for user
Register page
Login page
Logout page
User profile page
Tests for the user account

Acting like this, you will be able to review quickly your code and find a given information, when needed.

Review before committing

With git, it's very easy, you just have to type git diff --staged. With Subversion : svn diff <files you will commit>. A global review often show you some small mistakes, and will prevent you from committing passwords, useless code and typo mistakes.

Tagging the releases

Before putting to your production server, you should always tag it, to keep a trace of the release history. It will allow you to revert to a previous known state, in case of mistake.

Branching the unstable developments

Branching is very useful when you are developing new features. For example, if you are developing the comments feature, you will have to make many commits before stabilizing the feature. But the master/trunk should always be as stable as possible.

So to keep the application stable, create branch for developing feature and merge it to the master/trunk when finished.

External dependencies

When dealing with external dependencies, you shouldn't put in your sourcecode repository the code coming from other sources. Each versioning system provides tools for linking to external repositories : svn:externals or .gitmodules.

If you have to deal with Git from SVN of SVN from Git, you should consider creating a small script (Bash?) that will checkout the external source in an ignored folder.

It is also very important to fix the revision of the external library, because it occurs very often that the external is changing, and this could insert bugs into your application. With Git modules, you are constrainted to it. With Subversion, just set the svn:externals property to myvendor -r445 http://....

You should always rely on stable versions, with a version number.

To conclude

Just version code generated with your brain
Small commits
Tag to keep a trace
Branch when unstable working
Fix externals

Blog Opening

Fri, 08 Jul 2011 00:00:00 +0200

After 1 year of development, after 15 versions of Symfony2, the site is ready !

A new website

This blog is part of the new version of the site and contains 2 new categories : Blog & CV.

All the website sourcecode is available on Github, so if you want to change something, make a pull-request !

The old version is still available on http://alexandre-salome.fr/archives/2009-2011.

A new blog

This blog will be mostly technical. It won't be dedicated to Symfony2/PHP, it will also talk of versioning a project, general concepts, IT stuff, etc.

For the opening, 2 fresh articles are available :

I still have 10 posts in my pool, I have no precise idea of the rythm for the posts. If you want to keep in touch, you have 2 solutions :

Subscribe to RSS : http://feeds.feedburner.com/AlexandreSalome
Follow me on twitter : http://twitter.com/alexandresalome

Enjoy !