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 ».

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/

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.

Une conférence bi-lingue

Tout d’abord il est important de préciser que la conférence sera bi-lingue. La toute première conférence symfony en 2009 était francophone, l’an dernier elle était uniquement anglophone (everything is a Bundle) et cette année nous auront des conférences anglophones et francophones en parallèle. Le russe pour l’an prochain ?

Des sessions multi-threadées

Qui a dit que PHP n’était pas fait pour faire de la programmation concurrentielle ?! La conf sera forkée dès le début en deux et se déroulera en parallèle dans deux salles différentes (savamment nommées salle A et B). Il faudra donc faire des choix, on ne pourra pas tout vous raconter ! De plus tout cela mélangera allègrement du symfony 1, du Symfony2, du javascript (?), du cache HTTP, du français et de l’anglais.

Les confs que je ne manquerai pas

sauf guet-apens de dernière minute indépendant de ma volonté

• Sate of the Symfony2 CMF (par Lukas Kahwe Smith) : car même en faisant partie du projet, j’aimerais vraiment savoir où on en est ;-)
• RESTful avec symfony et Symfony2 (par Xavier Lacot et Damien Alexandre) : parce que là où Rails l’intègre par défaut, c’est une pratique que je trouve assez peu répandue dans le monde symfony (et en plus Xavier est sympa)
• Contributing with Git (par Scott Chacon) : parce que c’est Monsieur Github, que c’est une bête de scène et qu’on aura peut être des stickers Github comme l’an dernier :’) (oui oh ça va hein)
• Symfony2, 30 astuces et bonnes pratiques (par Noël Guibert) : parce que la même conf pour symfony 1 avait été très sympa la première fois, gageons que cela sera de bonne qualité aussi.
• Leveraging Symfony2 Forms (par Bernhard Schussek) : j’ai besoin d’une thérapie après trop d’embedForm symfony 1
• Symfony2 from the trenches (par Lukas Kahwe Smith et Jonathan Wage) : le truc de barbu par excellence, chouette !
• Quid de mes applications symfony 1 (par Marc Hugon) : bah oui, Quid ?
• Symfony2 en pièces détachées (par Hugo Hamon) : c’est quand même un peu pour Symfony2 qu’on vient, ça peut toujours être sympa
• Behavior Driven Development for Symfony2 (par Konstantin Kudryashov) : outre le fait que Konstantin est un type génial, le BDD est un domaine auquel vous devriez vous intéresser.

Et bien sur pour finir, j’assisterai aux keynotes de Steve Jo^W^W^WFabien Potencier.

Le mot de la fin

Si vous ne savez pas quoi faire en cette fin de semaine et que vous avez 300 euros (HT) à dépenser, venez nous faire un petit coucou à la conférence. Pour les plus fauchés (ou les plus raisonnables) d’entre vous, le HackDay de samedi est gratuit, ça devrait vous permettre de rencontrer des gens bien (TM) et de faire connaissance avec la communauté (je n’y serai pas, mais je penserai fort à vous). Quoiqu’il en soit, j’essaierai de couvrir la conf dans la mesure du possible sur mon compte Twitter.

Modèle et persistance

La première chose que l’on m’a apprise lorsqu’on m’a parlé de MVC, c’était que le M (pour model) devait contenir la logique « métier » de notre application. Quand on parle de métier, c’est bien ce qui est spécifique à l’application développée. La partie Modèle d’une calculatrice doit savoir calculer (Lapalisse si tu m’entends, elle est pour toi celle là), la partie Modèle d’une gestion de facturation doit savoir gérer les relances, les impayés, les factures … Bon bah très bien tout ça.

Et là c’est le drame, vous vous mettez à utiliser symfony et un des deux principaux ORM du monde PHP : Propel ou Doctrine. Tout d’abord vous trouvez ça chouette, vous pouvez faire un ->save() ou un ->delete() directement sur votre objet, la classe. Mais qu’est-ce que ça veut dire ça ? Ca veut dire que votre objet connait la façon dont il doit persister. Il est fortement couplé à la façon dont vous voulez l’enregistrer, dans notre cas dans une base de données.

C’est assez facile à voir, regardez le graphe d’héritage de votre objet, pour Doctrine tous les objets de votre modèle héritent de la classe Doctrine_Record. Et si, par le plus grand des hasards, vous voulez réutiliser votre logique métier dans une autre application PHP qui n’a rien à voir avec celle que vous développez avec symfony/Doctrine ? Vous êtes bons pour de jolis copier/coller.

DataMapper à la rescousse

L’idéal pour réaliser des M qui ne font que du M, c’est de n’avoir que des PPO (Plain PHP Object), c’est à dire des objets PHP standards (qui n’héritent pas d’une classe comme Doctrine_Record par exemple). Ces PPO doivent réaliser la logique métier de notre application (le M), et une autre partie de l’application doit pouvoir prendre ce PPO et le faire persister quelque part (système de fichier, base de données, …). C’est là qu’intervient le design pattern DataMapper. Il va permettre de faire le lien entre l’objet (l’Entity dans le jargon Doctrine2) et la façon dont il devra persister. Dans Doctrine2, c’est l’Entity Manager qui va réaliser le rôle de DataMapper avec sa méthode flush() qui sauvegarde les changements dans la base de données.

Unit of Work, le copain du DataMapper

La méthode ->flush() de l’EntityManager va permettre d’enregistrer les changements effectués sur les PPO dans la base de données. Ces changements auront été notifiés au préalable à l’Entity Manager par la méthode persist(). Cette méthode permet de dire à l’Entity Manager que l’on veut faire persister notre PPO passé en paramètre de la méthode. Ça se résume comme ça :

<?php
$user = new User;
$user->setName('Mr.Right');
$em->persist($user);
$em->flush();

Ici on informe l’Entity Manager (em), que l’on voudra faire persister les changements apportés à l’objet user via la méthode $em->persist($user). Les changements ne seront effectués dans la base de données qu’une fois la méthode ->flush() invoquée. Si nous avions fait plusieurs ->persist() différents avant de faire notre ->flush(), rien n’aurait encore été écrit dans la base. Mais alors, comment Doctrine fait pour garder trace de ces changements jusqu’au flush ? Il utilise le design pattern Unit of Work. Ce design pattern permet de garder trace de toutes les modifications apportées entre 2 flush(). Il met en place une sorte de transaction, mais au niveau des objets. C’est en partie son utilisation qui permet d’avoir un beau Data Mapper comme l’EM.

Conclusion

L’utilisation d’un DataMapper n’est pas vraiment nouveau dans le monde de la programmation : Hibernate l’implémente déjà pour Java et SQLAlchemy pour Python. En revanche, c’est une petite révolution dans le monde PHP. Si des fois vous préférez garder votre bon vieux Active Record, il existe aussi des solution en PHP : vous pouvez utiliser l’ORM Propel qui est toujours activement maintenu par François Zaninotto ou utiliser des implémentations du pattern Active Record réalisées avec Doctrine2 comme Doctractor ou ActiveEntity codé par l’équipe de Doctrine2. C’est deux derniers exemples montrent bien toute la flexibilité et la puissance de cette nouvelle version de Doctrine !

Vim : et la lumière fut

S’il y a bien un outil qui a changé la façon dont j’utilisais mon ordinateur, c’est bien Vim. Il s’inscrit tout à fait dans la façon dont je vois les choses : prendre du temps pour apprendre les choses, de manière à gagner du temps pour en réaliser. Tout argument consistant à dire que « du temps vous n’en n’avez pas » est nul et non avenu : le temps vous l’avez, il faut juste le prendre.
Tout d’abord avec Vim, la souris devient inutile. Et c’est beaucoup plus confortable qu’on ne le croit : passer constamment de la souris au clavier est plus fatiguant qu’on ne le pense. Ensuite Vim est certes un éditeur de texte, mais c’est aussi un Framework à part entière: on peut le programmer pour en faire ce que l’on veut.

Pour finir, Vim (et ses raccourcis clavier) s’utilisent partout : vous pouvez l’utiliser pour naviguer dans vos lignes de commande shell, pour administrer votre serveur sans interface graphique, pour vous déplacer dans les applis Google (essayez de jouer avec hjkl vous verrez) ou pour naviguer dans votre Window Manager (personnellement j’utilise Awesome qui fournit par défaut des raccourcis similaires à Vim). En résumé : One Vim to rule them all.
Je vous recommande chaudemment ces deux tutoriaux vidéo de chez PeepCode (en anglais) : Smash into Vim I et Smash into Vim II

Git : un gestionnaire de versions décentralisé

La chose qui a changé la façon dont je travaillais c’est Git. Vous voyez SVN, ce truc qui essayait de faire bien ce que CVS n’aurait pas du faire ? Eh bien Git c’est tout sauf ça. Leur seul point commun, c’est que ce sont tous les deux des gestionnaires de versions de code source. Git est décentralisé, vous pouvez donc avoir un repo Git en local, sans avoir besoin d’avoir un serveur sur lequel commiter quelque part. À vous les commit dans le train ! ll permet aussi de contribuer de manière beaucoup plus facile à des projets OpenSource, notamment grâce à Github (que je décris dans cet article).

Je ne vais pas vous décrire de façon exhaustive pourquoi Git est bien, si vous voulez en savoir d’avantage vous avez le livre OpenSource Pro Git ou cette suite d’articles Git pour les nuls. Vous pouvez aussi vous référer à cet article très bien réalisé A successful Git branching model. Quoiqu’il en soit, si vous utilisez encore SVN, passez à un gestionnaire décentralisé (DCVS) style Git ou Mercurial, ça urge les gens. D’autant plus que migrer un repo SVN existant sur Github est un jeu d’enfant.

De Mac OS X à ArchLinux

Cela faisait maintenant 8 ans que j’étais exclusivement sous Mac, et j’en étais plutôt content. J’étais passé par divers BSD et autre linux avant, pour m’arrêter sur l’Unix que je trouvais le plus convivial : Mac OS X. Car en effet dans mon utilisation quotidienne je voyais plutôt Mac OS X comme un Unix avec lequel je pouvais ouvrir des fichiers Photoshop (je caricature mais l’idée est là). Étant un barbu stallmanien refoulé, mon subconscient vivait de plus en plus mal les orientations prises par Apple : c’était le moment de changer d’OS.

Depuis je suis passé sous ArchLinux, et là ça a été la révélation : toujours la dernière version des logiciels et un wiki d’installation très bien fait qui en plus de vous guider vous permet d’apprendre ce que les autres vous cachent par des interfaces graphiques. Photoshop n’est plus un problème, puisque virtualiser un autre OS sous Linux s’effectue maintenant sans souci (pour le peu de fois que je m’en sers …). Si vous voulez apprendre linux par vous même, essayez ArchLinux, ça vaut le coup. Vous pourrez en plus utiliser des logiciels comme Terminator (gestion de plusieurs terminaux), Synapse/Gnome Do (lanceurs d’applications), Hotot (client Twitter) ou Awesome Window Manager (gestionnaire de fenêtres) dont il est difficile de se passer ensuite.

Firefox4

J’étais sous Firefox depuis un bon nombre d’années, et en fin d’année dernière c’est le drame : je l’abandonne pour Google Chrome. À contre coeur, mais il fallait se rendre à l’évidence, sur mon mac, Firefox devenait inutilisable quand on avait goûté à Chrome. Et puis en milieu d’année, j’ai fait le switch inverse de Chromium/Google Chrome à Firefox4 par idéologie : c’est Firefox qui a permis d’améliorer mes conditions de travail journalières (j’ai assez mal vécu la guerre IE 5 /Netscape 4 ;-) ), et il est maintenant très rapide (en tout cas comparable à Chromium). Je n’irai pas jusqu’à dire qu’il bat Chromium sur tous les fronts, mais il lui tient la dragée haute. Si comme moi vous préférez les actions de la fondation Mozilla à celle de Google, vous devriez essayer une béta de Firefox4 (avec Firebug 1.7), vous pourriez être surpris.

Conclusion

N’hésitez pas à essayer, échouer, réessayer, échouer de nouveau pour réussir de belle manière ensuite. Vous pensez que Vim est trop compliqué pour vous ? Qu’avec Linux on a l’air de pouvoir faire des choses bien, mais que clicker sur un .exe ça vous rassure ? Que neni ! Jetez vous à l’eau, et quoiqu’il en soit, faites tout pour améliorer votre quotidien avec des outils adaptés. Si vous n’essayez pas, vous ne risquez pas d’échouer, mais si vous n’échouez pas, vous ne risquez pas d’apprendre ;)

Et vous, quels outils vont ont fait évoluer dans votre métier ?

Crédit photo : http://www.flickr.com/photos/kinregerp/4457001909/

[s|S]ymfony : un homme

[s|S]ymfony c’est un homme, une vision : Fabien Potencier. Il y a certes une belle communauté autour, Kris qui s’occupe des release de la 1.4 notamment, Jon qui était embauché par Sensio pour Doctrine, mais c’est Fabien qui a toujours dirigé le développement du Framework. Depuis quelques temps déjà, Fabien est passé sur le développement de Symfony2, et a donc arrêté tout nouveau développement sur symfony 1. La conséquence immédiate est l’absence de quelconque nouveauté depuis plus d’un an sur symfony 1, et ce encore pour plusieurs mois.
Alors oui on nous explique que symfony 1.4 marche, certes, mais il continuera donc de se trainer ses défauts jusqu’à la fin de sa vie : Admin generator qui est là pour faire bien, forms imbriqués qui sont le cauchemard de tout développeur symfony, … On va aussi vous dire : mais t’as qu’à contribuer (oui vous savez, la réponse ultime de toute discussion open source non constructive) ! Le souci c’est que généralement quand on utilise un Framework, c’est pour gagner du temps, pas pour passer son temps à le développer (je me place du point de vue utilisateur, le cas spécial du contributeur core n’est pas traité ici). On peut contribuer avec des plugins certes (je suis le premier à le faire dès que je peux), mais pour moi la gestion des forms imbriqués devrait relever du Framework, pas de plugins.

Ma vision des choses

Donc si on dresse le tableau après plus d’un an de stagnation de symfony 1 :

• symfony 1 va stagner pendant toute la durée de sa future vie (officiellement novembre 2012)
• pour avoir des nouveautés Symfony, il faudra attendre Symfony2 qui est prévu, au plus tôt, Mars 2011
• Symfony2 en mars ne sera qu’une première version, donc loin de toutes les subtilités et fonctionnalités que peut avoir symfony 1

Vous allez me dire que ce tableau n’est pas très réjouissant, j’en conviens. Ça n’empêche nullement de démarrer des projets sur symfony 1.4, je le fais encore moi même, mais je pense que ça encourage à se poser les bonnes questions. Tiens, peut être qu’il existerait quelquechose qui pourrait combler mon manque, ma frustration en attendant Symfony2 ? Peut être que je pourrais avoir tout ce que symfony 1 m’apporte autre part, tout en utilisant quelquechose qui n’est pas voué à stagner ? Et si en plus je pouvais apprendre de nouvelles choses, ça serait top !

Django, une ouverture d’esprit ?

On aime tous évoluer, apprendre (enfin j’espère), se remettre en question … Mais beaucoup d’entre vous ont aussi des objectifs de rentabilité, de sureté vis-à-vis du client. C’est pourquoi utiliser votre client comme « même-pas-alpha-testeur » de Symfony2, ça reste encore très risqué et difficile à faire passer à votre direction.
Il existe d’autres Frameworks, d’autres langages que le PHP, c’est peut être l’occasion, en attendant Symfony2, de les tester sur des projets à faible risque ? En voici quelques un que j’aimerais tester personnellement : Play Framework en Java, Django en Python et Rails en Ruby. Si vous voulez vraiment avoir un avant goût de Symfony2 et que vous êtes prêts à vous attaquer à la bête, allez voir du côté de Spring en Java. Même si vous ne les testez que sur un projet, prenez le temps de le faire. Croyez moi, ça vous permettra de prendre du recul, et ça c’est toujours bon !

Pour ma part, je l’ai fait pour Django, et j’en suis très content. On retrouve vite ses petits par rapport à symfony et ça permet de faire un contrastif très intéressant avec symfony. C’est là qu’on se rend compte qu’il arrive, des fois, que l’herbe soit aussi verte ailleurs (mais pour ça, il faut aller voir).

Crédit photo : http://www.flickr.com/photos/clementlivolsi/4566165441/

Matériel et connectivité

Au moment où j’écris ces lignes, les caractéristiques principales de la dedibox sont :

• Serveur : Dell XS11-VX8
• CPU : Nano U2250 1,6Ghz
• Disque dur : 160Go SATA2
• RAM : 2 Go DDR2
• Réseau : 1 Gbit/s

En ce qui concerne le kimsufi voilà ce à quoi on a le droit :

• Serveur : certainement un assemblage maison, aucune info
• CPU : Celeron D/215/220 1,2 Ghz
• Disque dur : 250 Go (non précisé)
• RAM : 2 Go (non précisé)
• Réseau : 100 Mbit/s

Pour le côté matériel, j’aurais un petit faible pour la Dedibox. Même si le disque dur est moins important, le processeur Nano est au dessus du Celeron. De plus, les serveurs étant fournis par Dell, on peut espérer une relative qualité du produit. Idem pour la connectivité, la Dedibox dispose d’un débit 10 fois supérieur au Kimsufi.

Les services

Les deux sont plutôt bien fournies en services. Elles disposent chacune d’une console d’administration riche en fonctionnalités où vous pourrez réinstaller le serveur, le monitorer, configurer vos options (reverse DNS notamment), démarrer sur un système de secours, j’en passe et des meilleurs. À vrai dire, il y a tellement de trucs dans l’une et dans l’autre qu’il est bien difficile de les départager sur ce terrain là. L’essentiel y est.

En revanche, Kimsufi propose un espace de sauvegarde FTP de 100 Go, contre 5 Go (extensible à 200 Go via un abonnement) pour la Dedibox. De plus Kimsufi propose une connectivité IPv6 alors que Dedibox ne le précise pas (si vous avez des infos je suis preneur).

La fiabilité

Ça va faire plus d’un an et demi que j’ai ma Kimsufi, je n’ai jamais eu une coupure dessus. Donc niveau fiabilité rien à redire.
Pour la Dedibox, j’ai eu la V2 pendant plusieurs années aussi sans avoir à m’en plaindre. Pour la V3, j’ai du malheureusement la remplacer au bout de quelques semaines (alors qu’elle ne servait même pas) car il m’était impossible d’y accéder, et impossible de démarrer avec le système de secours. Le remplacement est d’ailleurs automatique via la console d’administration. Un défaut de jeunesse ou un coup de pas de chance ? Toujours est-il que je n’ai pas eu d’autres soucis depuis.

Les frais et conditions

Alors certes il faut lire entre les petites lignes, mais vous avez des frais d’installation pour les deux. Ils sont de 49,99 € HT (59.79€ TTC) pour Kimsufi et de 39.99€ HT (soit 47.83€ TTC) pour la Dedibox. À noter qu’ils sont offerts chez OVH si vous vous abonnez à l’année.
Car c’est aussi une des caractéristiques de ces offres, vous pouvez résilier votre serveur quand vous le souhaitez, c’est « sans engagement ». Pour les deux, cela se fait relativement facilement via la console d’administration.

Bon bah et alors ?

Malgré ce que pourraient laisser penser les caractéristiques techniques de la Dedibox, je pense que si j’avais un autre serveur dédié à prendre, je prendrai le Kimsufi. Je n’ai pas besoin de grosses performances, mais plutôt d’un espace disque conséquent. J’aime aussi la sauvegarde 100 Go par défaut. Et je crois que mon problème avec la Dedibox m’a plutôt refroidi.
Pour finir, avec Kimsufi vous pouvez payer par CB tous les mois (et non par virement comme avec la Dedibox), et arrêter quand vous voulez sans ne faire aucune démarche : vous avez juste à arrêter de payer, et la résiliation se fera automatiquement.

Crédit photo : http://www.flickr.com/photos/johnseb/3425464/

SVN vs Git

Tout d’abord, Sourceforge utilise un système de gestion de code source appelé SVN (j’espère ne rien vous apprendre ici) alors que Github utilise un système de gestion de code source décentralisé appelé Git.

Vous voyez la préhistoire ? Vous voyez les temps modernes ? Vous voyez donc la différence entre SVN et Git. Je ne vais pas vous faire un cours sur Git ici, ce n’est pas le propos (et d’autres le font très bien dans le Pro Git book). Mais une fois que vous aurez goûté à Git, vous trouverez SVN « so 2 thousand ».

Si vous utilisez encore SVN, ça ne peut être que parce que vous n’avez pas encore pris le temps d’apprendre à utiliser un système de gestion de code source décentralisé (Git ou Mercurial par exemple). Un conseil : prenez ce temps, ça vous rendra bien des services.

Github : mes amis les codeurs

Comme je le laissais entrevoir habilement dans le titre de cet article, Github c’est un peu le Facebook des codeurs. Vous ne pouvez pas vraiment demander aux personnes d’être vos amis, mais vous pouvez suivre leur activité (un peu à la Twitter). Vous avez donc une page récapitulative qui vous permet de suivre l’activité des personnes ou des projets que vous souhaitez.

Vous aurez aussi la possibilité de voir les projets que vos « amis » se mettent à suivre. Je n’ai jamais autant découvert de projets que depuis que j’utilise Github. Si vous souhaitez être au courant des dernières évolutions, des projets en vogue, Github est fait pour vous.

La collaboration c’est bon, mangez en

Puisque vous êtes sages et disciplinés, vous avez été lire le livre « Pro Git » et vous savez maintenant tout sur Git.

Github utilise pleinement les capacités de Git et va permettre de « forker » un projet via le site. En gros ça va vous créer une branche du projet dans votre compte. Vous pourrez faire des modifications dans votre branche et ensuite demander un « pull request » au responsable du projet : il verra vos modifications et pourra en un click les intégrer au projet principal. C’est du jamais vu ma bonne dame !

Tout le monde peut forker tous les projets et essayer de contribuer à la hauteur de ses compétences. Vous pouvez même commenter les lignes du code source directement sur le site, de manière à échanger avec les autres codeurs.

La cerise sur le gâteau

Je viens de vous dire que Git c’était l’avenir, que Github vous permettait de suivre et de découvrir plein de projets intéressants et qu’en plus il facilitait la collaboration entre les codeurs. Pour finir de vous convaincre, voici en vrac quelques petits « plus Periglioni » :

• Import automatique d’un projet sous SVN avec conservation de l’historique des commits
• Lecture et écriture possible via un client SVN sur les repos Github (alors si même avec ça vous passez pas à Git, je peux plus rien pour vous)
• Possibilité de créer des projets privés (moyennant une modique somme)

Alors, hop hop hop, on s’y met et plus vite que ça !

Maintenant que c’est fait, nous allons parler ici d’un des aspects de symfony les plus intéressant, mais aussi d’un des moins bien documenté. Pas que les forms « basiques » ne soient pas documentés, mais dès que vous voulez faire autre chose qu’un form qui représente tel quel (ou presque) un objet de la base de données, ça se complique un peu.

Je vais essayer de vous faire un petit tour d’horizon de ce qu’on peut faire avec les embedded forms.

Les forms, c’est de la POO

Vous allez me dire que tout symfony est de la POO (Programmation Orientée Objet), et vous avez raison. Mais on peut utiliser symfony sans être un expert de la POO (voire sans vraiment savoir ce que c’est), en suivant Jobeet et en comprenant que executeIndex inclut le template indexSuccess.php en cas de succès. À partir de là, on est le roi du monde.

Enfin, du monde, moins les forms. Car les forms sont – à mon sens – la partie de symfony qui est à la fois utilisée par tous les utilisateurs de symfony, et à la fois très orientée objet (les factories sont par exemple beaucoup moins utilisées …). Du coup, ça mérite quelques explications.

Tout le monde n’est pas doué en POO

Certes tout le monde n’est pas doué en POO, professionnel ou pas d’ailleurs ;) À l’inverse de JAVA où les programmeurs n’ont pas vraiment le choix, la POO est récente dans PHP et certains l’ont découvert comme un cheveu sur la soupe.

L’impression que l’on a quand on essaye de changer le comportement des embed form c’est : mais où est-ce que je peux bien faire ce que j’ai envie de faire? doBind, doUpdateObject, saveEmbeddedForms, … les choix sont multiples.

Et pour cause, les forms utilisent énormément l’héritage, et disposent donc de moultes méthodes que l’on peut surcharger, sans que ce ne soit vraiment documenté autre part que dans l’API. Si on ne comprend pas les principes de base de la POO, les forms sont une vraie galère (déjà que quand on les comprend …).

Petit rappel sur la POO sur developpez.com : Consultez au moins la partie sur l’héritage pour ceux qui sont largués.

Principales étapes de gestion des formulaires

Il faut quand même que vous ayez quelque chose à l’esprit, il y a pour moi deux principales étapes quand vous souhaitez traiter un formulaire qui vient d’être soumis :

• 1 ère étape : lier les valeurs qui sont récupérées dans la requête à l’objet Form (c’est à dire les recopier en s’assurant qu’elles sont valides et nettoyées)
• 2 ème étape : Une fois les valeurs recopiés dans le $values du formulaire (qui n’est en fait qu’un tableau de valeurs nettoyées), réaliser un traitement dessus ou sur l’objet qui en découlera (nous verrons cela par la suite)

Il est toujours bon de se demander ce que l’on veut faire exactement : agir sur les valeurs qui seront recopiées et validées dans notre form, ou alors agir sur les valeurs nettoyées et recopiées, avant qu’elles ne soient sauvegardées en base.

Première étape

Lors de la première étape de liaison/validation/recopie des valeurs de la requête dans votre formulaire (votre objet Form), vous pourrez agir sur les données avant qu’elles ne soient passées dans les validateurs, ou alors une fois qu’elles sont passées dans les validateurs.

Vous pourrez faire votre bourrin : enlever des parties de votre formulaire de la requête en vous basant sur certaines valeurs soumises.
Par exemple enlever tout un formulaire embarqué, si certaines valeurs ne sont pas saisies (c’est l’exemple qu’on trouve pas mal sur le web d’ailleurs).
Petit souci : les valeurs de la requête n’auront pas été validées/nettoyées par les validateurs, vous vous exposez donc à quelques soucis (dans le style le gars qui n’aura rempli que des espaces dans un champ texte, faudra penser à faire vous même le trim avant de vérifier la valeur …).

Deuxième étape

Lors de la deuxième étape, c’est ici que vous devrez effectuer les traitements concernant votre logique métier à proprement parler. La première étape s’est occupée de vous donner accès aux valeurs dans votre formulaire (via le tableau $values), maintenant que c’est fait vous pouvez jouer avec.

Vous voulez mettre à jour un objet qui dépend de celui que vous allez sauvegarder automatiquement, vous souhaitez insérer votre objet dans un nested set, etc etc … C’est dans cette étape que vous ferez ça.

Je sépare sciemment le processus en deux étapes, après vous pouvez le voir autrement. Les étapes étant chaînées, vous pouvez les mélanger et faire un peu de business logic à la fin de l’étape 1 par exemple, mais essayez de rester constant partout dans votre code, où vous ne saurez plus où aller voir quand il y a un souci.

Étude de cas

On va prendre ici un cas tout simple, celui d’un formulaire auto-généré par doctrine à partir d’une table de votre modèle.

Appelons notre modèle PetitSuisse. On aura donc une classe nommée PetitSuisseForm.class.php dans lib/form/doctrine/

On va vite fait faire le parcours d’héritage de cette classe :
PetitSuisseForm => BasePetitSuisseForm => BaseFormDoctrine => sfFormDoctrine => sfFormObject => BaseForm => sfFormSymfony => sfForm (ouf)

Même si quelques unes de ces classes sont vides, on comprend que ça puisse devenir un peu dur de savoir où chercher. Alors oui l’abstraction c’est bon mangez en, mais ça engendre une complexité de lecture du code non négligeable.

Les classes qui sont « à vous » et donc dans lesquelles vous pourrez surcharger des méthodes sont PetitSuisseForm et BaseFormDoctrine.

La première vous permettra de surcharger une méthode relative au formulaire du modèle PetitSuisse, la deuxième vous permettra de surcharger de manière plus globale (chacun des forms auto-générés par doctrine héritant de BaseFormDoctrine). Je parle ici de symfony 1.3+, vous n’aurez pas toutes ces classes dans les versions précédentes.

On va maintenant parler des principales méthodes que vous aurez (peut être) à surcharger. Il en existe d’autres, si celles ci ne vous vont pas, lisez le code de symfony ;-)

1 ère étape (liaison)

doBind(array $values)

C’est la méthode qui va faire appel aux validateurs pour nettoyer les valeurs de la requête avant de les placer dans le tableau des valeurs. Ce sont ensuite sur ces valeurs nettoyées que nous travaillerons. Vous pouvez ici toucher aux données brut de pomme qui sortent directement du formulaire envoyé, sans traitement préalable.

2 ème étape (sauvegarde)

doSave($con = null)

C’est cette méthode qui sera appelée (par save() ) lorsque vous demandez la sauvegarde de votre formulaire. Elle se charge de mettre à jour votre objet avec les valeurs du form en appelant updateObject (qui appelera doUpdateObject que nous verrons par la suite).
Si vous souhaitez changer le processus de sauvegarde, ajouter par exemple l’appel d’une vos méthodes à chaque sauvegarde du formulaire (pourquoi pas garder trace dans un fichier de toutes les sauvegardes de vos formulaires), c’est ici que vous devez le faire.

processValues($values)

C’est ici que vous pouvez toucher les valeurs qui ont été nettoyées par les validateurs, avant qu’elles ne soient passées à la méthode updateObject (que nous verrons par la suite). Je n’ai pas de traitement particulier en tête, mais l’idée est là : modifier des valeurs avant qu’elles ne soient utilisées pour mettre votre objet à jour.

doUpdateObject($values)

C’est cette méthode que vous devrez surcharger si vous voulez réaliser une opération spéciale sur votre objet avant qu’il ne soit enregistré dans la base.
Par exemple, si vous voulez insérer cet objet à la fin d’un NestedSet, vous ferez ça ici. Le $values passé en paramètre est un tableau contenant les valeurs du formulaire, une fois qu’elles ont été nettoyées/vérifiées par les validateurs.

updateObjectEmbeddedForm($values)

Je pense qu’elle veut bien dire ce qu’elle veut dire. Elle va se charger d’appeler la fonction updateObject de chaque formulaire embarqué. Vous voulez agir sur le traitement des données par vos forms embarqués ? C’est par ici !

saveEmbeddedForms($con = null, $forms = null)

Allez la petite dernière pour la route : elle se charge de la sauvegarde de chacun des objets de vos forms embarqués. Fabien Potencier en donne un exemple de surcharge dans le livre « More with symfony »

Exemple d’utilisation

C’est bien beau de parler, mais un peu de concret ne fait pas de mal.

Vous trouverez un bon exemple pour comprendre le comportement des forms sur le blog de n1k0 dans son article Embedding Relations in Forms with Symfony 1.3 and Doctrine. Certes c’est en anglais, mais le code est universel ! Si vous avez des bons articles en français je suis preneur aussi.

Il existe maintenant la méthode embedRelation() et le plugin de Daniel Lohse ahDoctrineEasyEmbeddedRelationsPlugin qui font ça tout seul. Mais c’est toujours bien de comprendre ce que l’on fait ;-)

Conclusion

Je vous ai fait un petit tour d’horizon des principales méthodes que vous pouvez surcharger dans votre formulaire. Comme je l’ai dit plus haut, ce n’est pas une liste exhaustive, mais vous devriez avoir de quoi vous amuser.

J’ai juste essayé de voir tout cela d’une manière un peu plus globale et de ne pas proposer un n-ième exemple de code pour les formulaires embarqués.

Mais avec tout cet attirail, gardez à l’esprit que votre code d’action ne doit pas dépasser le classique Bind > Save! Ce qui est au traitement de votre formulaire, reste dans votre formulaire! Enjoy!

Crédit photo: http://www.flickr.com/photos/fromeyetopixel/2470999873/