Ceux qui me suivent sur twitter sont au courant : j’ai depuis peu basculé enfin sur atoum comme framework de tests unitaires. Je n’ai jamais eu d’affinité particulière avec PHPUnit et j’avais la « chance » d’avoir entre les mains un projets avec très peu de tests… encore.

Quand il a fallu s’y mettre pour rattraper le retard, je devais au moins tester ne serait-ce que pour voir ce que steph lui trouvait de si magique.

Atoum, la découverte

Quand j’ai écrit mon premier test j’ai eu 2 réactions. « Plus logique tiens. » et surtout « AH MAIS CA VA VIIIIITE ». Le premier retient maintenant toute mon attention, mais c’est bien le 2e qui aura fait que je n’ai pas passé que 10min dessus.

Me voilà lancé dans la réécritures de mes quelques tests sous PHPUnit, histoire de me faire la main. Le verdict tombe, j’adopte !

Depuis donc quelques temps, j’ère de nouveau sur irc histoire d’avoir réponse à mes questions. (Même si j’ai la chance maintenant de bosser avec marmotz « Mr Documentation d’atoum »). Et je dois dire que si bug il y a, correctif il y a encore plus vite.

Voici donc un préambule un peu long, mais je pense que ça valait le coup de vanter un peu un projet sympa, qui vient s’attaquer au dinosaure PHPUnit et qui aura su me convaincre très rapidement.

Suivre l’avancement : la couverture de code

Nous voilà donc parti fièrement dans la quête du Test Unitaire. Et la question de savoir comment on allait pouvoir juger de l’avancement de nos tests s’est posée.

Après avoir eu tour à tour des idées à la con, on s’est tourné vers la « couverture de code » tout simplement.

Le principe est simple et pour ceux qui sont dans la même problématique, clairement utile : Le but du jeu est tout simplement d’avoir un listing le plus exhaustif possible de notre code métier confronté à ce qui est réellement testé et de suivre le rapprochement entre les deux.

Évidemment, atoum (tout comme PHPUnit) permet de faire ça (grâce à xdebug d’ailleurs). Mais ce ne fut pas si simple, d’où le billet !

Première chose, j’ai créé un deuxième fichier de conf (.atoum.cc.php pour ma part) comme conseillé dans la doc qui me permettra de ne pas générer la couverture de code (en html) à chaque lancement d’atoum. Ce nouveau fichier de conf contient alors:

<?php
$coverageField = new atoum\report\fields\runner\coverage\html(
    'Couverture de code',
    TEST_ROOT.'/code-coverage'
);
 
$coverageField->addSrcDirectory(__DIR__.'/src/Atipik/');
 
$script
    ->addDefaultReport()
    ->addField($coverageField)
;

Si on lance alors atoum avec l’option bin/atoum -c .atoum.cc.php on obtient donc dans notre dossier tests, un nouveau dossier code-coverage qui contient alors un index.html avec le listing de toutes nos classes :

Et pour chaque classe, une page plus détaillée qui indique clairement les parties du code testées et celles qui ne le sont pas.

Application à un projet Symfony2

Le problème (forcément il y en un :p) c’est que atoum, il cherche pas à comprendre et balance toutes nos classes php dans ce code-coverage. Or, on on utilise Symfony2 et il y a donc forcément des classes qui n’auront pas de tests unitaires dans le lot.

Le cas a été pensé car la méthode addSrcDirectory utilisée plus haut accepte un 2e argument : Une closure qui permet de filtrer les dossiers/fichiers ajoutés. Parfait !

On rajoute donc une petite condition rapide et le tour est joué :

<?php
$coverageField = new atoum\report\fields\runner\coverage\html(
    'Couverture de code de CzbV2',
    TEST_ROOT.'/code-coverage'
);
 
$coverageField->addSrcDirectory(__DIR__.'/src/Atipik/', function($file, $key, $iterator) {
    // Pour continuer à descendre dans l'arborescence
    if ($file->isDir()) {
        return true;
    }
 
    if ($file->getExtension() === 'php') {
        return preg_match("/(Extension|Bundle|CompilerPass|Configuration|Controller|Command|FeatureContext|Admin|Exception|ControllerTest)\.php/", $file->getFilename()) < 1;
    }
 
    return false;
});
 
$script
    ->addDefaultReport()
    ->addField($coverageField)
;

Pas besoin de détails, on exclut :

• les fichiers de conf d’un bundle
• les controllers
• les contexte de Behat
• les admin de Sonata
• les command CLI

On a un maintenant un chiffre de couverture « globale » assez proche de la réalité. L’objectif étant de suivre l’avancement de ce chiffre pour se donner une idée du chemin parcouru.

Attention quand même, le chiffre est à prendre avec des pincettes bien-sûr. Il vérifie juste que les tests passent dans toutes les parties de votre code, mais la « qualité » du test est bien à votre charge, évident mais bon à rappeler ;)

Aujourd’hui, je ne vous apprends rien, le développement web s’est considérablement professionnalisé et on ne fait plus de sites web comme on les faisait il y a 10 ans. Mais pourtant il y a bien des sites web qui ont encore 10 ans et n’ont jamais été refondu.

Pourquoi refondre quelque chose qui fonctionne me direz-vous ? Oui bonne question ! La principale me semble la maintenance et l’évolution du site qui devient au fil des années, compliquée voir quasi impossible.

Mais refondre un site from scratch n’est pas de tout repos et finalement peut-être pas la meilleur idée. Du coup, nous allons voir un cas pratique de migration en douceur d’un site « old scool ».

Le contexte

Nous parlons d’un site ici où chaque page web est représentée par une page php. Pas de rewrite. Chacune faisant un nombre incalculable de require, include, echo. Où beaucoup de développeurs sont passés par là, chacun sur le temps perso, pour la plupart le développement étant un loisir.
Pas la peine de vous faire un dessin, vous voyez le tableau.

L’objectif

Mettre en place une pseudo v2 progressive :
Recréer chacune des pages sur un nouveau socle applicatif plus actuel puis optimiser l’ensemble une fois toutes les pages crées. Les anciennes pages, doivent fonctionner avec les nouvelles sans changement dans les premières. En gros, tout le monde ne doit y voir que du feu.

Fonctionnement

Pour réaliser ça, je me suis pas foulé, je me suis tout simplement inspiré de ce que Fabien avait pris le temps de mettre par écrit dans sa série : « Create your own Framework ».

Du coup c’est plus la mise en pratique que je vais détailler. Nous allons donc migrer une page qui s’appelle : rechercheJoueur.php

Première étape, configurer notre nouvelle app en créant un fichier v2.php à la racine de notre serveur (vu que le vhost pointe ici) et contenant le code de l’étape 5 de fabien.
A partir de là, on a déjà quelque chose de sympa et quasi prêt à emploi. Faisons le test.

Dans notre app.php on va donc déclarer en route la première page qu’on va migrer. Genre ça:

<?php
use Symfony\Component\Routing;
 
$routes = new Routing\RouteCollection();
 
$routes->add('search', new Routing\Route('rechercheJoueur.php', array(
    '_controller' => 'render_template',
)));
 
return $routes;

On va c/c le contenu de notre ancienne page dans le dossier src/pages définies dans la fonction render_template en prenant soin de la renommer par search.php (nom de la route).

A ce niveau bien sûr, si vous accédez à l’ancienne url, vous tombez toujours sur l’ancienne page.
Nous allons donc créer un .htaccess à la racine avec tout simplement :

    RewriteEngine On
    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ v2.php [QSA,L]

Pas besoin de grand discours, en gros, tout les urls qui ne pointent pas sur une ressource existante, iront maintenant sur notre nouvelle application.

Renommons maintenant notre ancienne page. Et tentons d’y accéder (par son ancien nom) et magie, on pointe désormais sur la nouvelle page qui doit se comporter exactement comme l’ancienne vu que finalement, on a pas changé grand chose pour l’instant.

Mais le principal avantage c’est que toutes nos pages passent par le même endroit désormais.

Du coup la prochaine étape, est celle décrite dans la partie 6, utiliser HttpKernel et son ControllerResolver pour utiliser des controller en lieu et place de notre function render_template.

On pourra alors sortir tout le code php de notre page à migrer, et le mettre dans le controller en 1ere étape de séparation du code php / html.

Je me suis ensuite arrêté là niveau applicatif. J’ai trouvé que j’avais tous les éléments à ma disposition. Mais n’hésitez pas à continuer la suite de la série de Fabien.

Du coup, au lieu du DIC de Symfony2 dont Fabien parle dans l’étape 12, j’ai personnellement opté pour Pimple vu que le site n’est vraiment pas compliqué niveau technique et que je n’avais pas besoin de l’artillerie lourde de ce côté.

Du coup, j’ai injecté dans Pimple, une connexion DBAL de doctrine et twig comme moteur de template et j’ai décidé d’injecter directement tout ce container dans tous mes controllers (même si on est d’accord que c’est le mal) mais en l’état c’est pas vraiment problématique j’ai juste 2 services.

Du coup j’ai un peu modifié la partie concernant l’appel au controller dans mon v2.php pour reproduire le setContainer propre au ContainerAwareInterface mais qui attend un ContainerInterface du DIC. Pour utiliser Pimple dans nos containier, il faut donc reproduire ce setContainer.

try {
    $request->attributes->add($matcher->match($request->getPathInfo()));
 
    $controllers = $resolver->getController($request);
    // on instancie notre controller 
    $controller = new $controllers[0];
    // on récupère l'action
    $action = $controllers[1];
    // On injecte Pimple
    $controller->setContainer($container);
    // On récupère les arguments
    $arguments = $resolver->getArguments($request, $controllers);
 
    $response = call_user_func(array($controller, $action), $arguments);
} catch (Routing\Exception\ResourceNotFoundException $e) {
    $response = new Response('Not Found', 404);
} catch (Exception $e) {
    $response = new Response('An error occurred', 500);
}

Voilà, un peu brut, mais ca fait son job rapidement. Il suffira de créer un controller qui contiendra cette méthode setContainer et dont tous nos controllers hériteront. Et nous pourrons alors utiliser notre dbal et notre twig dans nos actions !

La suite n’est que du refactoring du code existant. Faites déjà fonctionner une page, essayant de découper les traitements dans des classes adéquates. Chaque nouvelle page, apportera son lot de cas particulier, mais plus ça ira et plus ce sera simple de migrer les pages.

Et ensuite ?

Je n’y suis pas encore, mais j’imagine qu’une fois qu’on s’est affranchi des contraintes de l’ancien système, on peut commencer à optimiser un peu, créer une couche modèle, peut-être envisager un ORM ? Ou tout simplement se dire, que c’est bien suffisant et que maintenant, n’importe quel dev avec une connaissance du MVC devrait pouvoir utiliser et maintenir le code ! Et c’était quand même l’objectif ;)

Pour ceux qui auraient loupé un épisode, j’ai changé en début d’année de boulot pour retrouver le monde du PHP à 100%. Nouvelles têtes, nouveaux locaux, nouveau projet et forcément nouvelle plateforme… en Zend.

Il y a 5 ans, c’était un choix qui se discutait, mais aujourd’hui la plateforme a force d’évolution mérite sincèrement une grosse remise à plat, dans tous les sens du terme. C’est donc l’occasion pour repartir sur … du Symfony2 of course : )

Même si on me fait confiance sur cette décision, forcément on va pas arrêter de mettre à jour la plateforme actuelle sous prétexte qu’il faut passer sur Symfony.

Me voici en piste pour trouver la meilleur solution pour faire ça en douceur. L’idée des component Symfony arrive forcément très vite dans mon esprit. Je test avec le composant « Command », une formalité effectivement. Mais, autant, je vois bien le principe de migrer une appli PHP classique vers les components Symfony, autant, partir de Zend me semble pas si trivial.

Je me suis alors rappelé une présentation lors du symfony live 2011 de Marc Weistroff (aka futurecat) qui avait utiliser Symfony2 pour intégrer la possibilité d’utiliser des ESI dans une app symfony.

Me voici parti avec l’idée d’embarquer mon application Zend actuelle, dans une nouvelle appli Symfony2. L’appli Symfony2 serait donc l’application « master » qui lancerait l’appli Zend quand elle ne saurait pas répondre à une requête. Dans un premier temps d’ailleurs, l’appli Zend sera lancé dans tous les cas et l’appli Symfony2 ne prendra le relai que sur les pages ne répondant pas un code http 200.

Voici le principe grosso modo que j’ai utilisé:
On place un listener sur kernel.request avec une priorité suffisante pour prendre le dessus sur le routing Symfony.

parameters:
    atipik_zend_wrapper.class: Atipik\ZendWrapperBundle\HttpKernel\ZendListener
 
services:
    atipik_zend_wrapper.listener.request:
        class: %atipik_zend_wrapper.class%
        arguments: [%kernel.root_dir%]
        tags:
            - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest, priority: 254 }

Le listener en question qui finalement ne fait qu’instancier mon wrapper, lance la requête et retourne une Response si on a un code HTTP 200.

<?php
 
namespace Atipik\ZendWrapperBundle\HttpKernel;
 
use Symfony\Component\HttpKernel\HttpKernelInterface;
use Symfony\Component\HttpKernel\Event\GetResponseEvent;
use Symfony\Component\HttpFoundation\Response;
 
class ZendListener
{
    public $root_dir;
 
    public function __construct($root_dir)
    {
        $this->root_dir = $root_dir;
    }
 
    public function onKernelRequest(GetResponseEvent $event)
    {        
        $applicationZend = new ZendWrapper(realpath($this->root_dir.'/../vendor/cityzen/www/application'));
        $response = $applicationZend->dispatch();
 
        if ($response->getHttpResponseCode() == 200) {
            $event->setResponse(new Response($response));
        }
    }
}

Et le wrapper, qui reprend en fait le index.php de mon appli zend (pas écrit par moi, me demander à quoi ça sert :D). Au préalable j’ai bien sur mis dans vendor le code de mon app Zend, et autoloadé le prefixe Zend:

<?php
 
namespace Atipik\ZendWrapperBundle\HttpKernel;
 
class ZendWrapper
{
    public 
        $application,
        $bootstrap,
        $response;
 
    public function __construct($application_path)
    {
        if (!defined('APPLICATION_PATH')) {
            define('APPLICATION_PATH', $application_path);
        }
 
        if (!defined('APPLICATION_ENV')) {
            define('APPLICATION_ENV', 'development');
        }
 
        if (!defined('APPLICATION_PARTNER')) {
            define('APPLICATION_PARTNER', 'cityzenbox');
        }
 
        if (!defined('DISPLAY_ERRORS')) {
            define('DISPLAY_ERRORS', false);
        }
 
        set_include_path(implode(PATH_SEPARATOR, array(
            dirname(APPLICATION_PATH) . '/library',
            get_include_path()
        )));
 
        $this->init();
    }
 
    public function init()
    {
        $this->application = new \Zend_Application(
            APPLICATION_ENV,
            APPLICATION_PATH . '/config/config.php'
        );
 
        $this->bootstrap = $this->application->bootstrap()->getBootstrap();
        $this->front = $this->bootstrap->getResource('FrontController');
        $default = $this->front->getDefaultModule();
 
        if (null === $this->front->getControllerDirectory($default)) {
            throw new Zend_Application_Bootstrap_Exception(
                'No default controller directory registered with front controller'
            );
        }
 
        $this->front->setParam('bootstrap', $this->bootstrap);
    }
 
    public function dispatch()
    {
        $this->front->returnResponse(true);
 
        return $this->front->dispatch();
    }
}

Et là, on peut désormais voir notre site, avec la débug bar Symfony !

Au final, cela un reste un Proof of Concept, et ce n’est pas la solution retenue. Du coup, on peut envisager de pousser plus loin, en alimentant la débug bar avec les infos de Zend.

Mais c’est toujours intéressant (de mon point de vue) de voir avec quelle facilité Symfony2 peut-être utilisé avec n’importe quelle type d’application désormais. La souplesse c’est sans doute ça qui fait aujourd’hui le succès de Symfony, nan ?

Note : Le code date de Avril et donc de Symfony 2.0.12

Vous avez déjà dû entendre parler de langages comme Haskell, Erlang, Clojure ou encore Scala (si ce n’est pas le cas, vous devez lire l’article encore plus que les autres). Twitter a refait son moteur de recherche en Scala et Facebook utilise Erlang pour son système de chat par exemple. Tous ces langages partagent un même paradigme (certains plus que d’autres, mais passons), et c’est en partie ce qui fait leur succès : le paradigme de programmation fonctionnelle. Je vais essayer de vous expliquer ici en quoi c’est plus qu’une mode ou une lubie d’universitaire barbu (ou non), et pourquoi donc vous devriez vous y intéresser.

Disclaimer : Je ne suis pas un expert en programmation fonctionnelle, je vous donne juste ici quelques raisons de s’y intéresser. Si les puristes y voient quelques absurdités, n’hésitez pas à me taper dessus.

Le bannissement des variables

Ça fait 10 ans que vous codez en impératif (vous avez bien fait un peu de prolog ou de OCaml à la fac mais ça ne compte pas vraiment), vous avez toujours fait des trucs dans le style i++ ou x = x + 1 et ça ne vous empêche pas de dormir, bien. C’est une honte (je fais style mais ça ne m’empêche toujours pas de dormir hein). Une des choses qui m’a le plus surpris quand j’ai appris le « pur » fonctionnel, c’est qu’on vous dit que vous ne pouvez ré-assigner une variable (qui n’est plus vraiment variable dans le coup).

Vous faites x = 1 et si vous essayez ensuite de faire x = 2 vous aurez une erreur, diantre. Et là vous vous dites : « Pourrrrrrrrquuuuuuuuuoooooooooooiiiiiiiiii est-il si méchant ? ». « Et mon for, je vais le faire comment moi ? ». Pas de panique, ça fait toujours ça la première fois.

Avant de vous dire pourquoi, juste une petite apartée vocabularistique. Vous entendrez parler de cette chose sous le terme de « données immutables ».

Pourquoi ?

Pourquoi est-ce que cette « restriction » est en fait une des clés du succès des langages fonctionnels ? Elle va permettre de faire des programmes concurrents (vous connaissez ça sous le terme multi-thread, mais il n’est pas adapté ici, car on n’utilise pas de thread dans le language) facilement, et donc de faire des programmes qui passent bien à l’échelle (scalable).

Si vous avez déjà essayé de faire joujou avec les threads, vous savez que l’accès aux données est problématique. Quand plusieurs threads veulent lire la même donnée en mémoire pas de soucis. Mais c’est quand plusieurs threads veulent modifier que ça pose problème. Qui doit avoir la priorité ? Comment fait-on quand une valeur a été modifiée par le thread 2 après que le thread 1 l’ait lue mais avant qu’il ait eu le temps de la ré-écrire ? Vos amis les sémaphores ne sont pas loin, et là c’est le drame de la complexité et des « dead locks ».

Et si on interdisait aux programmes de modifier une variable déjà affectée ? Nous y voilà. Avec cette restriction, les langages fonctionnels facilitent énormément le travail des développeurs.

Le gros mot du jour : transparence référentielle

Un des autres aspects qui différencie la programmation impérative de la programmation fonctionnelle est la transparence référentielle. En gros ça veut dire que si vous appelez 2 fois la même fonction avec les mêmes paramètres, elle doit toujours retourner la même valeur (et elle ne doit pas produire d’effets de bord, lisez le lien wikipédia).

C’est rarement le cas en programmation objet. Vous avez toujours des fonctions qui dépendent de l’état de l’objet. Si vous avez une fonction isEmpty() sur un objet et que vous l’appelez à plusieurs reprises sur un objet qui peut être plein ou vide, elle retournera un résultat différent en fonction de son état, à 2 moments différents du même programme. Elle n’est pas référentiellement transparente. Le fait de ne pas pouvoir modifier les variables aide clairement à avoir des fonctions transparentes référentiellement.

Pourquoi je vous parle de ça ? Imaginez vous avez des fonctions qui sont indépendantes les unes des autres, qui n’ont pas d’effets de bord, et qui ne partagent pas d’endroits en mémoire. Ça serait pas top de répartir tout ce petit monde sur des cœurs différents de votre processeur avec des systèmes tous prêts ? C’est notamment faisable par des modèles d’acteurs (en anglais dans le texte, la page française est un peu vide), disponibles directement en Scala ou Erlang.

Et mon for(i=0, …) alors ?

Certes vous allez devoir l’oublier (i est modifié à chaque itération). Mais vous apprendrez d’autres manières d’itérer sur vos collections (map et autres joyeusetés) qui vous semblerons finalement tout aussi naturelles. Ne prenez pas peur à la vue ces fonctions, elles vont vous permettre d’exprimer ce que vous souhaitez faire, au lieu de le décrire ligne par ligne ce que l’ordinateur doit faire en style impératif.

Voilà par exemple comment afficher les paroles de la chanson « Happy Birthday to You » en Scala sans boucle for.

(1 to 4).map { i => « Happy Birthday  » + (if (i == 3) « dear Vince » else « to You ») }.foreach { println }

Conclusion

Je cherchais depuis un bout de temps ce qui pourrait me redonner le goût d’apprendre, et la programmation fonctionnelle a été un déclic pour moi. Passer de PHP à Ruby, à Python c’est sympa, mais ça reste le même paradigme de programmation, ça ne me faisait plus rêver. Avec la programmation fonctionnelle vous trouverez au mieux un nouvel eldorado, au pire vous verrez votre façon de coder en impératif différemment. Aller hop, au boulot !

Pour aller plus loin

Je vous ai mis l’eau à la bouche et vous avez vous aussi envie de découvir ce fabuleux monde. Voilà ce que je vous conseille (en anglais par contre, je vais pas pouvoir faire autrement) :

Haskell

C’est LE language purement fonctionnel. Si vous voulez vous y mettre pour de vrai (et souffrir pour de vrai), allez y pour celui-là. Pas sûr que vous ferez de vrais projets avec, mais c’est le langage vers lequel vous devriez tendre.
Il existe en plus un très bon livre, consultable sur internet (que je vous conseille d’acheter) : Learn You a Haskell For Great Good.

Erlang

Erlang est un langage fonctionel aussi, mais moins extrémiste qu’Haskell. Son système d’acteurs et sa philosophie « let it crash » sont très intéressants. Je ne l’ai pas encore assez approfondi pour pouvoir en dire plus pour l’instant.
Un petit livre accessible en ligne : Learn You Some Erlang For Great Good

Scala

C’est le moins fonctionnel de ma séléction. Et pour cause, vous pouvez utiliser des variables mutables (même si vous pouvez utiliser des immutables aussi) et de la programmation objet. C’est une sorte de langage hybride qui vous permet de faire du fonctionnel, tout en restant dans ce que vous connaissez (la POO). Il tourne en plus sur une JVM et est compatible avec les librairies Java déjà existantes … C’est à mon avis le plus pragmatique pour une utilisation en entreprise (compatibilité Java, possiblité de faire de l’OOP), mais le moins efficace pour apprendre le fonctionnel pour de vrai. C’est ce que nous utilisons dans ma boîte actuelle.
Des ressources sont disponibles sur le site, la référence restant le livre du fondateur du langage M. Odersky Programming in Scala, Second Edition ».

Depuis quelques temps, je développe pas mal en python et durant mes différents projets, j’ai rencontré tout un tas de petits problèmes ou besoins.

Je me suis donc dis que cela pourrait être intéressant de regrouper en vrac dans un article quelques unes des solutions trouvées. Non seulement cela vous servira peut être un jour, mais en plus, vous aurez peut être des solutions plus simples/adaptées à me proposer ;)

Opérateur ternaire

J’utilise souvent en php l’opérateur ternaire (x ? a : b) et je voulais trouver une équivalence en python.
Ma première réaction a été de faire simplement un :

bool(x) and a or b

Mais si « a » est un booléen à false, cela ne fonctionne pas comme le montre le petit test ci-dessous :

J’ai donc cherché plus en profondeur et j’ai trouvé une solution des plus simple en utilisant une liste avec 2 valeurs :

[a, b][bool(x)]

Suivant la valeur de « x », la valeur retournée sera la 0 ou la 1.

Récupérer son adresse IP publique

En python, pas possible de faire comme en PHP en utilisant $_SERVER['REMOTE_ADDR'] pour afficher l’IP. Il fallait donc trouver une solution, et après plusieurs minutes de recherche, la seule solution vraiment valable que j’ai trouvé, est toute simple.

from urllib2 import urlopen
public_ip = urlopen('http://whatismyip.org').read()

N.B: l’idéal serait d’utiliser un try … except pour faire propre mais bon, ca c’est à vous de le faire

Si vous connaissez une autre solution, je suis preneur ;)

Un serveur web instantané

Envie de partager un ou plusieurs fichiers avec quelqu’un sans devoir le mettre sur une url publique (ex: www.mondomaine.com/fichier_pour_toi.png) ou créer un compte FTP ? Envie d’analyser vos requêtes http ? Autre envie ?

Python vous permet en une ligne de commande de réaliser un serveur web :

python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"

Il vous suffit ensuite de vous connecter sur l’ip de votre serveur sur le port 8000 et naviguer dans l’arborescence du répertoire ou la commande à été lancée :

Pour arrêter le serveur, un petit « CTRL+C » dans votre shell et c’est fini ;)

N.B: il est tout a fait possible en une dizaine de lignes de faire un serveur un peu plus abouti avec notamment une gestion du port.

Envoyer un fichier par sftp

Envoyer un fichier (backup, sources …) d’un serveur à un autre est possible de différente façon (FTP, webdav …) mais une des manière les plus sécurisées et sans installation supplémentaire (quand le serveur autorise les accès ssh) reste pour moi le sftp.

Et j’ai trouvé « paramiko » qui existe en paquet debian, donc un simple « apt-get install python-paramiko » et hop.

Le code :

import paramiko
 
host = '127.0.0.1'
port = 22
transport = paramiko.Transport((host, port))
 
user = 'mon_user'
pass = 'mon_pass'
transport.connect(username = user, password = pass)
 
sftp = paramiko.SFTPClient.from_transport(transport)
 
import sys
path = sys.argv[2]
localpath = sys.argv[1]
sftp.put(localpath, path)
 
sftp.close()
transport.close()
print 'Upload done.'

Ensuite il suffit de lancer le script :

python send_over_sftp.py /chemin/local/fichier.txt /chemin/distant/fichier.txt

Et c’est tout :)

N.B: A noter qu’il est préférable de configurer ses serveurs pour fonctionner avec des clefs plutot que de mettre le password en clair dans le script python et de sécuriser les paramètres envoyés au script si vous donnez l’utilisation à d’autres utilisateurs.

PHP to PYTHON

Pour finir, un petit lien très pratique qui vous permet de voir l’équivalence python des fonctions php (quand elle existe) : http://www.php2python.com/

On pourra remercier Vince au passage qui lui trouve du temps à consacrer à ce modeste blog !

Mais je viens de réaliser que cela allait faire quasi un an que j’avais attaqué Ruby / Rails de manière plutôt intensive et qu’un petit bilan s’imposait donc ! Alors je me lance !

Contexte

Un petit coup de contexte, notre startup Autrement édite 2 sites web, Chambres à part et HotelHotel. Le premier est en symfony1.4 et le 2e est en Rails3 suite à une décision prise fin 2009. Pour ceux que ça intéresse, Jérémy avait écrit un billet à l’époque sur ce choix.

A l’époque je m’étais retrouvé un peu seul à tenter vainement de défendre symfony mais j’avais du me résoudre à me lancer dans le grand bain pour la conception d’HotelHotel à laquelle il fallait bien que je participe (bah oué on est un peu que 3 côté techos :p), c’était il y a quasi 1 an !

Je vous préviens, ceux qui me côtoient un peu s’y attendent surement ;), je n’ai pas vraiment changé d’avis : Ruby / Rails j’accroche pas, et de depuis quasi les premières lignes écrites. Et je vais essayer de retranscrire un peu mon ressenti et retour d’expérience.

No révolution

Déjà, aucune révolution, il faut le savoir. Les différences fondamentales sont assez « mineures » dans le sens où ca n’a pas changé grand chose dans ma manière de bosser. En fait, si vous avez fait du PHP et du symfony, vous saurez faire du Ruby et du Rails, mais vous (re)passerez par la case documentation les 6 premiers mois pour trouver les équivalents à vos connaissances PHP/symfony.

Et ça commence du coup mal. Apprendre un langage et un outil en essayant de tenir des « cadences » de production honorables pour son égo, c’est pas simple. C’est même assez compliqué et ça frustre !

Côté bilan, le langage il n’y a pas grand chose à redire si ce n’est ce côté implicite avec lequel j’ai encore maintenant beaucoup de mal, question de goût j’imagine. J’ai croisé un jour un gist avec 2 « versions » d’un même code, l’un en version totalement implicite, l’autre en version totalement explicite (je remets pas la main sur le lien) : pas photo pour moi, le 2e était clairement plus compréhensible sans même connaître Ruby !
Mais les Rubyistes ont choisi le premier… ;)

Après, il est plutôt bien construit, l’api est clairement plus aboutie que PHP, et permet de faire tout autant de chose, et plutôt vite et bien une fois qu’on s’est habitué à sa syntaxe. Il faut être honnête Ruby n’a rien a envier à PHP en tant que langage pur. Mais la réciproque est pas loin d’être vrai. PHP se traine beaucoup de boulet, mais personne nous oblige à les utiliser.

Pas de switch en vue

Du coup pas vraiment de changement suffisant pour me dire que cela vaut le coup de « switcher ». Au contraire même, le problème (oui c’est un problème pour moi) de l’implicite rend toute lecture de code un vrai cauchemar ce qui m’a certainement ralenti et un peu découragé de me plonger à 110% dans le code comme j’aime tant faire. Parcourir des lignes de code que j’ai encore du mal à déchiffrer me décourage un peu. (Et oui désolé, mais moi, j’aime voir mes fins de lignes avec des points virgules !!!)

Pour le framework c’est une autre histoire. A vrai dire, je ne lui trouve pas grand chose pour lui. Attention, il vaut bien symfony 1 qui était ma référence lors de mon lancement dans Rails. Il permet de faire (quasi) tout autant de chose.
Je précise quasi, parce que moi j’ai toujours la vague impression que je suis bridé, certainement parce que je suis encore loin de maitriser les rouages que j’avais pris le temps de décortiquer sur symfony.
Et pourtant c’est déjà sa version3 (qui va avoir un an aussi d’ailleurs). Quand on voit le gap franchi avec symfony1 et Symfony2, la comparaison avec le second ne serait certainement pas à son avantage :p (:troll:)

Et c’est sans doute là que le bas blesse, je me suis retrouvé à repartir de zéro, en me disant que ça je saurais le faire de suite sur symfony, que Rails doit le faire aussi, mais qu’il fallait repasser par la case google. Et au final il le fait mais il ne fait guère plus. Donc peu de vrai « découvertes » et forcément, une petite déception…
Je me retrouve avec 2 couteaux, pas la même forme/couleur, mais le rendu est bien le même, j’arrive à couper mon saucisson sans problème (j’étais à l’apéro au moment d’écrire ces lignes…).
J’aurais préféré me retrouver avec un nouvel outil un peu différent, genre des ciseaux.

Bien sûr, je peux sans doute m’en prendre en grande partie à moi même, je n’ai jamais remis la même énergie que pendant mes 3 années passées sur symfony. Peut-être que je passe à côté de quelque chose ! Jémémy me dirait (et me dira ;)) certainement que oui…

Et puis la communauté me manque ! Je suivais (suit encore en fait ;)) l’actualité, blog, twitter qui tournent autour de symfony. Celle de Rails et même de Ruby est beaucoup plus petite en France et j’ai finalement très vite lâché l’affaire une fois de plus, un peu découragé.

Rajouter à cela, les gems, qui sont très sexy sur le papier mais qui compliquent un peu le côté, je vais mater dans le code comment c’est foutu de ce petit plugin qui rox, bien sûr le fameux RVM qui ne m’aime définitivement pas. On ne parlera pas de Passenger qui a lui aussi ses petits caprices de temps en temps, ou bien le fait qu’il faille redémarrer l’appli pour qu’un changement dans une lib soit pris en compte (mais apparemment que sur ma machine :( )

Des détails me direz vous ! Oui c’est clair, des broutilles auquel on est confronté tous les jours dans notre métier de développeur. Et le changement forcé de mes petites habitudes de bidouilleur PHP n’a pas du arranger les choses.

Je ne rentre volontairement pas dans le côté technique à comparer deux outils qui font leur job. Parce que pour le coup, la différence ne se fait pas là pour moi à mon avis.

Bilan

Au final on peut dire que c’est plus un mauvais feeling et le fait que je sois ravi de symfony et PHP qui font que j’accroche pas. J’ai passé et donné beaucoup de mon temps sur symfony et PHP et je n’ai pas été déçu, finalement je me dis que quelque part, je les trompe un peu … ;)

Et puis Symfony2 est arrivé… J’ai décortiqué les bétas, testé et retesté, lu le code. Et l’excitation de m’en servir grandit chaque jour ! Définitivement, une question de feeling donc. Et aussi parce que j’ai eu l’impression de progresser dans mon métier avec symfony1, et cette même sensation m’envahit quand je vois Symfony2. Ruby / Rails ne m’ont permis que de me diversifier…

Attention, je reste quand même ravi d’avoir pu goûter à ce changement. Ça aura au moins eu le mérite me confronter à autre chose justement, un environnement quasi entier qui diffère ! Je rajoute aussi une corde à mon arc, sait-on jamais hein…

Et ça m’aura permis aussi de me conforter, malgré toute la mauvaise presse qu’il se traine, dans l’idée que moi je l’aime bien mon PHP :p

PHP : un langage web

Comme je l’ai dit, PHP est un langage web. Il propose donc de base un ensemble de choses utiles pour interagir avec un environnement HTTP (entre autres). Vous n’avez pas pu passer à côté de nos chers amis $_GET et $_POST par exemple (sauf si vous avez appris PHP avec symfony mais bon, pas sur que ce soit le meilleur moyen). Ensuite PHP est un langage de template à lui tout seul. Vous mélangez du PHP au sein d’un fichier HTML et vous obtenez ce que vous souhaitez, sans effort particulier. Prenons le fichier index.php suivant :

<h1>Hello world</h1>
<p>
  Hello <?php echo $_GET['name']; ?>
</p>

Vous utilisez ensuite Apache et mod_php pour l’afficher (avec MAMP, WAMP, ou ce que vous voulez) en appelant index.php?name=Karamazof et vous êtes les rois du monde. Admettons. Attaquons les choses sérieuses.

Ruby : un langage tout court

C’est là que ça se gâte. Tout d’abord je tiens à dire que je n’ai pas beaucoup d’expérience en Ruby, il y a de ça un mois je n’en avais encore jamais fait, soyez indulgents ;-). Mais j’ai tout de suite été confronté à l’évidence : Ruby (comme Python d’ailleurs) n’est pas un langage web. Pas qu’on ne peut pas faire de web avec (ça se saurait), mais il n’a pas été initialement prévu pour cela. Qu’est-ce que cela implique ? Vous n’avez pas de raccourcis/fonctions pour accéder à l’environnement HTTP comme vous pouvez avoir avec PHP et ses $_GET et $_POST.

Il faut donc en Ruby utiliser une couche standardisée (ou presque) entre votre code et le serveur web, couche qui vous donnera la possibilité d’accéder aux éléments d’une requête HTTP et de renvoyer une réponse à afficher. En Ruby le « standard de facto » est maintenant Rack (rien à voir avec Rake). Rack est une couche d’abstraction entre le serveur web (peu importe lequel) et votre code. Vous devrez bien sûr adapter votre code pour qu’il soit compatible Rack et puisse être exécuté sur n’importe quel serveur web qui propose une interface Rack (à peu prêt tous maintenant). C’est ce que je vous montre ci-dessous.

À noter que le problème est le même pour Pyhon et que Rack a d’ailleurs été inspiré de la solution trouvée pour Python qui s’appelle WSGI.

Une application Rack

Une application Rack qu’est-ce que c’est ? C’est une application qui a comme point d’entrée une méthode call qui prend un tableau en paramètre (souvent nommé env) et qui renvoie un tableau contenant le statut HTTP, les headers HTTP, et le contenu. Vous pouvez aller consulter le post de blog d’origine ou l’article Wikipedia.

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end

Heureusement vous pouvez inclure des modules rack pour vous faciliter la vie, et notamment pour construire un object Request à partir de cet environnement et un objet Response pour faciliter la création de la réponse à envoyer au navigateur. À noter que vous pouvez très bien utiliser env et retourner un tableau de contenu vous même comme l’exemple ci dessus, mais c’est je trouve pas le plus pratique. Voici un exemple de code ci-dessous :

#hello_world.rb
 
require 'rack/request'
require 'rack/response'
 
class HelloWorld
  def call(env)
      request = Rack::Request.new(env)
 
      response = Rack::Response.new
 
      response.write "<h1>Hello world</h1>"
      response.write "<p>"
      response.write "  Hello " + request.GET['name']
      response.write "</p>"
      response.finish
  end
end

Pour tester votre application vous avez plusieurs choix (dont Apache si vous le souhaitez) mais je vous conseille pour commencer d’utiliser rackup qui vous permettra d’avoir un serveur de test assez facilement. Pour ce faire créez un fichier config.ru avec le contenu suivant dedans :

#config.ru
 
require 'hello_world'
 
run HelloWorld.new

Rien de bien compliqué ici, on inclut le fichier hello_word.rb précédemment créé et on dit à rackup de lancer notre application.

Installez ensuite les gem nécessaires :

sudo gem install webrick rackup

Puis pour lancez le serveur web (webrick par défaut) avec rackup, placez vous dans le répertoire contenant vos fichiers puis exécutez la commande suivante :

rackup -I.

Vous devriez pouvoir vous rendre sur http://127.0.0.1:9292/?name=Vincent et voir votre première page web en Ruby !

Petite précision, si vous souhaitez modifier votre code et voir les modifications sans relancer le serveur web, utilisez shotgun à la place de rackup (à n’utiliser qu’en développement) :

sudo gem install shotgun
shotgun -I.

Conclusion

Ruby est un langage fort sympathique avec beaucoup de possibilités que PHP ne permet même pas d’entrevoir. En revanche en ce qui concerne le web on comprend un peu mieux pourquoi PHP est beaucoup plus populaire que Ruby pour faire du web : PHP a été prévu pour, pas Ruby. Mais je ne saurais vous conseiller d’essayer le Ruby, on y prend vite goût.

Crédit photo : http://www.flickr.com/photos/pswansen/41832591/

Suite à un problème lors de l’impression des séries limitées Bugdroid, Akibag connait quelques difficultés et fait appel à la communauté pour redresser la barre.

Chez AW, puisque nous sommes clients et qu’on aime, nous allons essayer de contribuer un peu avec ce petit message ! Alors si comme nous vous aimez les produits de qualité, made in france et fait par un petit entrepreneur, faites un petit (ou même un gros) geste !

Récupérer la documentation sur git

La documentation officielle de Symfony2 est bien sur hébergée sur Git. Rendez-vous sur le dépôt Git officiel et clonez la documentation en local.

git clone git://github.com/symfony/symfony-docs.git

Installer Sphinx

Tout d’abord la documentation Symfony2 est générée grâce à Sphinx, un projet écrit en Python. Il serait donc de bon aloi de l’installer ;-)

Si comme tout gens bien vous utilisez ArchLinux, il vous suffit d’un petit

sudo pacman -S python-sphinx

Pour les autres utilisez easy_install directement :

easy_install -U Sphinx

SI vous n’avez pas easy_install (hey les gens, faut vraiment vous mettre au Python !), c’est par ici.

Créez un Makefile

Pour l’instant, le repo Git officiel ne fournit pas de Makefile pour générer la documentation. Il va donc falloir en créer un. Pour ce faire utilisez la commande suivante dans votre répertoire symfony-docs :

sphinx-quickstart

Cette commande va vous poser tout plein de questions, acceptez toujours les choix par défaut (appuyez sur entrée pour ce faire). Vous aurez juste trois choses à saisir, le nom du projet (mettez Symfony2), le nom de l’auteur (Fabien Potencier serait fair play ;-) ) et la version (est-ce un piège ?).
Lorsque cette question va arriver > Name of your master document (without suffix) mettez n’importe quoi d’autre que index, on s’en fiche un peu, mais si vous mettez index il va pas être content le mÔssieur.

Installez l’extension configuration

Fabien a du créer une extension pour gérer plusieurs formats (YAML/XML/PHP dans notre cas) pour les fichiers de configuration. Pour l’installer, créez un répertoire _exts dans votre répertoire symfony-docs et placez-y le fichier se trouvant sur le repo Git sphinx-php de Fabien.

Éditez le fichier conf.py qui se trouve dans symfony-docs, et ajoutez-y cette ligne en haut après la ligne d’import :

sys.path.append(os.path.abspath('_exts'))

Trouvez ensuite la ligne des extensions et rajoutez-y celle que l’on a téléchargée plus haut :

extensions = ['configurationblock']

Vous être prêt à générer votre première documentation Symfony2.

make html

Et voilà ! Le fichier index.html généré se trouve dans _build/html/index.html

Amusez-vous bien, et n’hésitez pas à contribuer dès que vous le pouvez.

La conf tombait bien vu que la première Release Candidate de Symfony2 approche à très grand pas, c’était l’occasion d’aborder abondamment ce nouveau framework pour ceux qui n’avaient pas eu encore l’occasion (ou le courage ^^) de se jeter dedans. Les différentes interventions étaient donc principalement orientées autour de 2 axes, Symfony2 en tant que tel, et le passage de symfony 1 à Symfony2 forcément.

Première journée

The lost art of Simplicity

Josh Holmes, un employé de Microsoft, est venu nous parler de la simplicité dans le développement. C’est un bon orateur, la conf n’était pas technique du tout, « juste » de l’ouverture d’esprit. Même si je n’ai globalement pas appris grand chose de nouveau, cette conf Microsoft était bien mieux que celle de l’an dernier, et pas cruciale pour ceux qui sont arrivés en retard (suivez mon regard :D). Un bon début donc.
Voir les slides

Application Security

Un gros morceau du code Symfony2 et une partie toujours très critique d’un framework. C’est Johannes Schmitt qui a reprit le flambeau après la première version du composant par Fabien. On a vu voir un très gros refactoring depuis les premières versions, ca a l’air bien fichu mais mon dieu que c’est devenu énorme comme brique!

Malheureusement on ne peut pas vraiment dire que Johannes est un grand showman comme on a pu en croiser, et il s’est « contenté » consciencieusement de faire une revue des différents mécanismes du composant. Un peu de regrets donc, sur ce gros morceau, peu d’exclu pour ceux qui ont déjà parcouru la doc et le code source.

State of the CMF Project

Lukas, le « lead » du projet est venu nous présenter quels étaient les buts du projet, quelles entreprises étaient impliqués et ce qui avait déjà été fait. L’idée est bonne : axer le développement sur la résolution des problèmes des développeurs (d’où le CMF : Content Management Framework) et réaliser ensuite un CMS complet avec les briques du CMF. Un petit hic : le moteur de stockage des données est basé sur une spec et un soft Java (Jackrabbit), et un backend PHP ne verra probablement pas le jour. Voir mon post sur ce sujet.

Il y aura à mon avis une place pour une alternative plus « conventionnelle », ie. que les gens normaux et les petites entreprises pourront utiliser.
Vous trouverez les slides sur GitHub.

Apostrophe: a Symfony Powered CMS

Aucun de nous n’était présent, je vous laisse jeter un œil aux slides du coup.

RESTful avec symfony et Symfony

Xavier Lacot et Damien Alexandre de chez Cleverage ont débarqué avec leur Poney pour nous présenter l’implémentation à faire dans les 2 versions de symfony pour faire du vrai bon REST. Présentation complète vu qu’ils sont allés jusqu’à faire quelques benchmarks et nous ont gratinés de quelques slides bien fun ;)
Toute leur présentation sur : http://symfpony-project.org/

Contributing with GIT

GIT était encore là, et c’était encore Scott Chacon qui s’est collé à la lourde tâche de le présenter. Et encore une fois, ce fut avec classe! Scott est vraiment un très bon conférencier (ca se dit? :x) et il est, cette fois, allé plus loin que la simple présentation du SCM, la présentation a également englobé les modes de contributions à GIT. Très complet là dessus et introduisant également le workflow de contribution de github!

Speedy App

Encore un choix à faire, on y était pas. Les slides

Embed sf1 in SF2

Explication d’un cas réel, l’express.fr. Présentation du pourquoi ce choix technique. Le code source reste le plus parlant pour voir l’intérêt. Au final peu de lignes de code à rajouter dans l’appli sf1 pour transformer les réponses en object Response pour sf2 et ainsi bénéficier de la couche Cache de Symfony2.

Un moindre mal pour les applis encore en symfony mais qui voudrait tirer parti de quelques avantages de Sf2.
Voir les slides

Symfony2 : 30 astuces

Noël s’est attaqué à passer en revue, les bonnes pratiques et astuces à garder en mémoire pour les futurs dev Symfony2.
Voir les slides

phpBB4

Sympathique présentation par le lead développeur de phpbb, il y a 10ans déjà. Rétrospective de l’évolution du système de plugins pour aboutir finalement au choix de baser la prochaine version sur Symfony2:
Voir les slides

Forms in sf2

Bernhard qui est à l’origine du composent Form, a pris un peu tout le monde a contre pied en présentant la dernière mouture du composant, qui n’est pas encore mergé dans le master. L’optique ici est de passer les configurations de formulaire via le DIC pour pouvoir tester les contrôleurs sans les forms.
Autre avantage, la partie render est maintenant séparée également. Pour avoir plus de détails sur le pourquoi du comment, hésitez pas à jeter un oeil sur la discussion qu’il a lancé sur la mailing list.

Bon il assure que tout le process d’embed form est plus au point que dans symfony 1, comme beaucoup, tellement traumatisé, je vais attendre de le voir pour le croire :D

Voir les slides

Keynote

Voilà Fabien sur la scène, sans slides prêt à présenter en live Symfony2. Quelques modifications de son installation un peu tardives ont provoquées 15min de debug en live! Quelques sueurs froides, on a même cru qu’il allait renoncer! Mais finalement, c’était tout simplement un vhost mal configuré :)
Sur le contenu, il a voulu montrer que Symfony2 était vraiment simple à appréhender et que le système d’annotation présent via le FrameworkExtraBundle était vraiment « cool ». Donc rien de nouveau en soit, pour tout ceux qui ont déjà eu l’occasion de manipuler la bête.

Perso, j’avoue avoir quelques réticences avec tout ces systèmes d’annotations, très à la mode en ce moment. Peut-être parce que c’est pas natif, ou peut-être parce que j’aime bien avoir les choses à leur place, et pas tout au même endroit. Différente vision certainement!

Deuxième jour

Adopt devops philosophy

Les croissants ont été les plus forts, on y était donc pas:
Voir les slides

Symfony2 from the trenches

Du coup celle là non plus:
Voir les slides

Assetic

L’occasion de découvrir le dernière né des bundles intégré de base dans Symfony2. J’ai suivi de loin la conf pour commencer à mettre au propre ce billet. Mais les slides parlent d’elles mêmes! Assetic, c’est vraiment orienté pour faciliter la vie des developpeurs.
Voir les slides

Application Gruyere

Une nouvelle conf qu’on a pas pu suivre.

HTTP Cache

Fabien revient pour nous parler certainement d’une des features vraiment « militante » (entendre par là, que peu de framework l’utilisent actuellement). Pour lui, le meilleur système de cache est donc de passer par la spécification HTTP qui définit tout un tas de convention pour faire du cache.

Il a donc passé en revue les différents mécanismes de cache via HTTP mais trop de choses à dire donc pas assez de temps pour rentrer dans le code plus en profondeur. Ça promet en tout cas pas mal de prise de tête car du coup la méthode de cache à utiliser revient au développeur! Et même si je reste convaincu déjà depuis pas mal de temps que le cache HTTP c’est bien, être au pied du mur, ça fait un peu peur :p

Solr

J’aurais bien aimé voir la conf, mais finalement faut faire des choix encore et toujours! Une présentation que vous pouvez retrouver ici

Varnish

Un bon tour du propriétaire, fait par un orateur très fun, très blagueur qui m’a donné envie d’aller plus loin! En tout cas Varnish ca a l’air cool, mais surtout si on en a l’utilité en fait…

Quid de mes applications sf1

Marc Hugon a du se contenter de la petite salle pour parler pourtant d’un sujet qui intéressait à mon avis beaucoup de monde. La migrations des applis sf1 vers Sf2. J’ai pas pu rentrer donc faut matter les slides.

Twig

Voir les slides

Symfony2 en pièces détachés

Une grande revue des différents composants présent dans le core de Symfony2 et qui sont utilisables de façon indépendante. Rien de neuf en soit, mais un bon rappel qu’avant de faire son propre composant, ça vaut le coup de jeter un œil à ces composants là!
Voir les slides

Doctrine

Voir les slides

Javascript, Event and Scopes

Une présentation très sympa qui met en lumière les bonnes pratiques à utiliser pour développer à base d’event. Comme l’utilisation du preventDefault() ou encore la différence entre le bubbling et la capture. Suivi ensuite d’un gros rappel sur la portée des variables et les pièges à éviter dans leur nommage.

Sachant que pour de développeurs web, le javascript a toujours été de la « bidouille » c’est toujours bon d’avoir des rappels de bonne pratique, même si encore une fois, rien de neuf sous le soleil.
Voir les slides

BDD : Behavior Driven Development

Voilà une des confs qui a vraiment abordé un sujet trop souvent mis de côté et de très belle façon. Konstantin (plus connu sous le pseudo everzet) a expliquer très simplement en quoi consistait la méthodologie BDD qui n’est finalement qu’une extension du célèbre TDD. Puis a mis en lumières les outils qu’il a développé pour faciliter le travail de chacun.
Clairement une très bonne surprise et une nouvelle étape pour faciliter cette partie du métier de développeur.
Voir les slides

Jeux sociaux et Cloud

Weka qu’on a vu pas mal en tant que sponsor de l’évènement a pu exposer un peu son domaine de prédilection. On attend les slides!

Don’t use a screw when you need a nail

Derrière ce titre, se cachait en fait, Stefan (Skoop) qui a parfaitement résumé ce que tout développeur devrait faire : Chercher les solutions les plus pertinentes en fonction de vos besoins. En faisant un rapide tour des technos non PHP qui répondent à des besoins communs, comme le search, un bug tracker, etc … il a montré que le développement c’est une grande famille et qu’il y a parfois la solution à votre problème pas si loin que ça ;)
Voir les slides

Iscool Story

On attend les slides!

Keynote : one more thing

Musique, effet de lumière, vidéo, Fabien a le mérite de jouer l’auto dérision parfaitement en commençant la keynote par l’annonce de la … Symfony Tablet! Finalement, pour ceux qui ont pas vu la conf retransmise en live apparemment, 3 grandes annonces:

• Symfony2 aura un système d’installer à la wordpress. Il semble aussi simple d’utilisation!
• Symfony2 aura un système de distributions qui embarquera une conf par défaut différente en fonction des cas d’utilisation
• Nouvelle marque! Symfony se dote d’un nouveau ndd, un nouveau site et un nouveau logo : Voir le nouveau site

Rien de révolutionnaire, mais on peut noter l’effort sur le site web, beaucoup plus clair, simple et actuel niveau graphique. Et surtout l’accent mis sur la simplification de Symfony2 auprès des débutants. Fabien a semble-t-il l’intention de « banaliser » au maximum Symfony2 pour montrer qu’on peut faire beaucoup de choses assez simplement avec. Et si c’est pour faire reculer des choses comme joomla, on ne peut qu’espérer que ca fonctionne un peu ;)

Unconférence

Vendredi, Skoop a également mis en place un partie « unconférence », entendre par là, une conférence un peu informelle. L’idée est super, mais encore une fois, ce ne faisait que compliquer les choix :p

Vous pouvez retrouver le détails des présentations sur le récap de Jonathan

Bilan

Bah c’était cool! Forcément ;)

• Toujours un peu déçu quand on tombe sur une conf qui finalement ne pas plus loin de ce qu’on est déjà allé. Mais fallait bien que les gens qui n’ont pas encore touché le nouveau joujou puissent suivre j’imagine!
• Assez bluffé par l’équipe de traduction en langage de signes. Deux dames pour 4 malentendants (je crois). J’imagine pas le bagage technique qu’il faut pour réussir à traduire ce genre de conférence, chapeau!
• Un peu déçu de pas avoir eu un badge avec un joli tour de cou :x Réduction de coût pour les invités?
• Toujours aussi charmé par l’endroit, si j’avais pu faire mes études dans le coin!
• Merci pour le soleil!
• Le gros point noir, reste finalement le wifi. Une vrai galère pour arriver à la page de login. D’où la publication tardive de ce billet et un niveau de tweet en dessous de ce qui était prévu!

Ravi d’avoir pu rencontrer (ou revu) pas mal de gens, et surtout l’équipe knplabs qui m’a gentiment permis de squatter avec eux :p Bon ya pas mal de tête que j’ai même pas vu voir de loin! Mais ce n’est que partie remise!

Crédit photo : http://www.flickr.com/photos/xavierbriand/5494245376