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

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.

Voici donc le code, résultat de cette réflexion, ou un clic avec ctrl (ou cmd pour les mac) ou le bouton du milieu de la souris devrait ouvrir le lien dans un nouvel onglet, comme le ferait un lien normal :

$('.line-click').live('click', function(e){
  e.stopPropagation();
  href = $(this).children('a:first').attr('href');
  if (e.ctrlKey || e.metaKey || e.which == 2) {
    window.open(href);
  } else {
    window.location = href;
  }
}).css('cursor', 'pointer');

A utiliser avec le code html suivant par exemple:

<ul>
  <li class="line-click"><img src="monimage.jpg" alt="youpi" /> 10/02/11 <a href="monlien.html">Titre de mon billet</a></li>
  <li class="line-click"><img src="monimage2.jpg" alt="youpi" /> 07/02/11 <a href="monlien2.html">Titre de mon 2e billet</a></li>
  <li class="line-click"><img src="monimage3.jpg" alt="youpi" /> 21/01/11 <a href="monlien3.html">Titre de mon 3e billet</a></li>
</ul>

A adapter selon vos envies. Ici c’est le premier lien trouvé dans l’élément avec la class line-click qui sera déclenché. Voilà, en attendant que j’arrive à finir un billet plus consistent!

Crédit photo : http://www.flickr.com/photos/flyingturtle/837938254

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 !