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

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 !

Et bien ça tombe bien car Vince et moi même avons la chance d’y être également !

Se rendre au Symfony Live

Bon ce fut tout un marathon pour moi, levé 5h30 (et ceux qui me connaissent savent que c’est déjà un exploit :D), tram puis métro pour attraper mon TGV Marseille-Paris de 6h30.
Arrivé à la gare de Lyon à 9h30, on repart pour une session métro, pour enchainer sur à nouveau un peu de tram avant d’arriver devant la Cité Internationale, endroit de Paris que je ne connaissais pas !

C’est déjà une belle surprise, l’endroit est fort sympathique, très joli, mais très graaand. Et j’ai pas trouvé les grandes affiches que j’attendais « Symfony C’est par là ». Bon finalement je débarque sur les coups de 10h30, badge, tour de cou et petit sac de goodies pour m’accueillir et me voilà dans l’arène.

Heureusement, il restait quelques croissants, parce que forcément j’avais fait l’impasse sur le petit déjeuner et je vais pas vous rappeler les tarifs prohibitifs de la SNCF. Juste de quoi me réveiller un peu et commencer à mettre en route mon cerveau qui jusque là ne voulait qu’une chose, se coucher.

la matinée

Internationalisation

On commence la journée par la présentation de Thomas Rabaix concernant l’internationalisation et Symfony.

Quelques rappels sur ce qu’est l’internationalisation, des astuces sympa comme comment traduire vos routes, mais aussi et surtout la présentation du plugin qu’il a réalisé pour Menu Gourmet : mgI18nPlugin. Il permet de traduire à la volée toutes les chaînes statiques de votre page en utilisant une petit interface qui se place au dessus du site, à essayer d’urgence !
Bref très bonne première présentation.

Vous pourrez trouver les slides de sa présentation sur son site.

Admin generator en détail

John Cleveley nous a fait une petite piqure de rappel des nouveautés de l’admin generator depuis la version 1.0. Il a aussi été l’auteur du slide le plus classe de la journée concernant l’administration « backend » : un éléphant se soulageant le derrière dans un seau … ;-)

Il a rappelé que l’admin generator c’était bien, mais pas forcément pour tout. Qu’il fallait réfléchir au besoin avant de l’utiliser, plutôt que de partir avec tête baissée et se rendre compte plus tard qu’on passe plus de temps à galérer avec par rapport à ce qu’on veut faire qu’autre chose (sa remarque est d’ailleurs valable pour tout développement : c’est généralement une bonne idée de réfléchir avant de se lancer ! ).

Si vous voulez créer votre propre thème, vous pouvez vous inspirer de sfAdminDashPlugin et de sfAdminThemejRollerPlugin.

Il a aussi re-précisé que sfContext::getInstance c’était le mal (même si lui l’utilisait dans ses slides) et a fini par parler de la facilité de modifier/étendre les filtres grâce au form framework. En ce qui concerne les form, il est préférable d’en créer un nouveau pour chaque form du backend, histoire de pas confondre les forms front et back.

Il a conseillé d’utiliser le moins possible le generator pour les label, help etc des forms, mais de tout laisser dans le form : beaucoup plus facile à maintenir.

Windows plaide coupable

Surement parce qu’ils sont sponsor, on a retrouvé une équipe de Microsoft qui a plaidé pendant 50 longues minutes que Microsoft c’était aussi (et presque surtout) de l’open source et que développer dessus, c’était bien. Apparemment pas assez pour donner envie de poser des questions à l’auditoire.

Bon, ok sur windows, tu peux développer sur Visual Studio 2010 Ultimate, what else?

Du coup un petit sondage a été lancé sur la répartition des OS pour les devs symfony

L’aprèm

Symfony Internals

Pas de nouveautés pour tous les développeurs qui ont pu travailler un peu en profondeur sur ce framework. Une belle revue de tout le fonctionnement interne de Symfony par Geoffrey Bachelet, et avec un accent so french ;)

Voir les slides

Doctrine migration

Un bon rappel sur l’enjeu des migrations et que maintenant (depuis sf 1.3) cela consiste en 3 opérations :

• Modifier son schema.yml pour inclure nos modifications
• Lancer la task de diff:
  symfony doctrine:generate-migrations-diff
• Regénérer ces classes model/form/filter et lancer la migration:
  symfony doctrine:build --all-classes --and-migrate

Alors pourquoi s’en priver?

Voir les slides

Doctrine 2

Est arrivé le tour de chauffe des gros sujets de la conférence. En l’occurrence Doctrine 2. Les grandes idées que Jonathan nous a montré:

• 100% réécrit, donc plus de compatibilité descendante
• ~ 3 fois plus rapide que Doctrine 1.2
• Principalement concentré sur la perf, et donc adieu la magie des findByMaColonne et consor. A l’image de Propel, les getteur et setteur seront générés dans la class model vu que les modèles justement n’hériteront plus d’une class de type Record, permettant ainsi d’alléger la charge mémoire
• Intégration d’une classe qui s’occupera, à l’image du monde java, de gérer les flush et clear. Ca ne sera plus l’objet en lui même qu’il faudra « save » mais demander à cette nouvelle classe de le faire.

Forcément, ca fait un peu peur, car au delà, d’une réécriture, ce sont des gros changements. Mais dans un souci de performance (aussi bien en terme de temps d’exécution que de charge mémoire), on prend le bon chemin. Même si la magie va disparaître…

Voir les slides

Offline admin generator

Sur cette partie, on a retrouvé Thomat Parizot, de chez clever-age (vous savez ceux qui ont annoncé un plugin de gestion de media au dernier symfony live, mais qu’on attend toujours :p).
On découvre un concept plutôt innovant dans le monde symfony, l’idée de permettre l’accès et le travail sur un backoffice sans connexion Internet semble une bonne idée. Il suffit de synchroniser, après coup, son travail.

Bon ok la démo n’a pas été parfaite – ahh l’effet démo – mais ya quand même un gros boulot derrière même si malheureusement c’est un concept très (trop?) dépendant de la technologie, vu qu’après Gears, il se base maintenant sur HTML5 et toutes ces nouvelles fonctionnalités. Donc très limité, mais à garder sous le coude.

Help the community

Skoop a redonner toutes les clés pour aider la communauté. Et que même les petites actions, comme les ouvertures de bug, sont très appréciées.

Voir les slides

Table ronde avec la core team

Pas mal de questions sur les sujets classiques, hello world application, et consor. Voici un petit recap des questions que j’ai comprises et trouvées intéressantes:

Q: Compatibilité descendante avec la fin du support de la 1.0

R: Gros effort sur la facilité de passer à une version supérieure

Q: Documentation du système de form un peu en retrait?

R: Ne pas hésiter à aider!

Q: Symfony enseigné à l’école? Support de cours disponibles?

R: PHP déjà peut enseigné de base. Pas plus d’info à ce sujet mais ne pas hésiter à les contacter sur ce sujet

Q: Développement ne va pas trop vite?

R: La 1.4 aura bien 3 ans de support, ce qui est en soi, très long. Et puis le web évolue vite, donc il faut suivre

Q: Performance? Quid?

R: Le problème vient rarement du framework… :D

Q: Difficulté à faire adopter Symfony par leur client

R: C’est ensemble et en fournissant des cas d’utilisation précis de Symfony, qu’on pourra faire évoluer les mentalités

Q: Sismo? Bientôt dans les bacs?

R: Fabien n’a plus le temps pour l’instant. Projet en standby et clairement pas prioritaire. Et de toute façon Sismo ne fera jamais tout ce que fait Hudson et consor. Il n’a pas écarté la possibilité de ne jamais le release…

Q: Quid de la construction d’un vrai CMS Symfony une bonne foi pour toute?

R: Déjà 3 CMS existant très solides, avec 3 approches différentes. Il faut en débattre.

Q: Pourquoi reprendre plein de projets, comme Swift?

R: Une volonté de ne pas réinventer la roue et de récupérer et adapter les meilleurs pratiques et idées en PHP

Q: Et Propel dans tout ça?

R: Gros boulot de François, mais peut-être un peu trop tard? Jamais dire jamais, mais pour l’instant après le gros switch vers Doctrine, difficile de faire machine arrière. Surtout que le futur de Propel avec sa 2.0 n’est pas du tout assuré pour l’instant

Et du coup, quelques annonces sont sorties:

• phpbb4 sera codé en Symfony 2, ce qui en ferait le premier gros projet open source php entièrement en Symfony si je ne m’abuse
• Symfony2 n’a plus de plugin mais des bundles…
• Symfony2 n’utilisera plus que le meilleur des autres framework, comme le logger et le cache de Zend, au lieu de le recoder de leur côté.

Voilà un petit compte rendu, les slides des différentes interventions sont disponible sur le blog de Symfony.

Vos envoyés spéciaux pour l’évènement: Vince et Tim

crédit photo: http://www.flickr.com/photos/iph4n70m/4338366087/

• Créer des panorama 360 en jQuery (via clementj)
  Un plugin qui va vite trouver ses utilisateurs, je pense. Le rendu est plutôt bon.
• Publiez vos stats Analytics
  Oui vous pouvez avoir envie de le faire, pourquoi pas. Ce site, grâce à la récente api de google, permet de rendre publique une partie de ses stats à ses visiteurs ou autres
• Testeur de startup
  Apparemment le site est ancien, mais je ne connaissais pas! Une équipe qui s’occupe de faire des revues de startups pour dénicher les futurs twitter et consort
• Doctrine behavior sur mysql workbench
  Quand il s’agit de faire des MCD, Mysql Workbench est plutôt cool! Et voilà que maintenant, on peut directement lui ajouter les behavior doctrine. Que demande le peuple!
• Dernière faille PHP
  Si vous suivez l’actu PHP, vous savez sans doute que les versions antérieures à la version 5.3.1 ont une faille. Voici un petit récap des modifications à faire sur ces versions, si vous ne pouvez pas mettre à jour vos version
• Servir de gros fichiers en PHP
  Un petit snippet qui permet d’optimiser la lecteur de gros fichiers par PHP
• Des icones!
  Quelques sets que je n’avais jamais vu passer, donc je fais tourner<./li>

• 8 règles de base dans un design
  Toujours dans la rubrique, je suis un dev et je veux faire mon site sans un graphiste, voici un très bon récap sur les choses à garder en tête avant de vouloir mettre plein de bling bling et autre effet jquery à son site

Problématique

Il me fallait stocker le résultat d’une question à choix multiple sans pour autant avoir à manipuler ensuite ses résultats autrement que par simple visualisation. Du coup, je voulais éviter d’avoir à créer une table pour stocker ces réponses et une table d’association avec ma table miroir de mon formulaire.

C’est là où le type array intervient. Rien de compliqué en fait, il ne fait que simplifier un traitement tout bête qui consiste à stocker un tableau php en base après sérialisation. Et qui le désérialise quand on le récupère depuis un enregistrement de la base.
Une chose de moins à faire en fait et c’est bien là ce qu’on recherche nous autres développeurs, en faire le moins possible ;)

La solution codée

Niveau code, c’est très simple. On défini notre champ dans notre schema.yml comme n’importe quel autre champ

meschoix: { type: array(1000) }

Qui donnera un champ text en mysql.

Ensuite, il suffit de modifier le formulaire obtenu pour transformer notre champ en liste de checkbox de manière très classique:

$this->widgetSchema['meschoix'] = new sfWidgetFormChoice(array(
      'choices' => array(
        '0' => 'Choix1',
        '1' => 'Choix2',
        '2' => 'Choix3',
        '3' => 'Choix4'
      ),
      'multiple' => true,
      'expanded' => true
    ));

Et puis c’est tout! Maintenant, lors de l’enregistrement, Doctrine va sérialiser le résultat de votre sélection et le stocker en base. Et quand vous peuplerez votre formulaire avec des données en base, il le désérialisera et donnera les bonnes valeurs à notre liste de checkbox.

Bien sûr, ca nous oblige à ne pas changer l’ordre des questions et les rend difficilement modifiables. Mais c’est une décision qui doit être prise en connaissance de cette limitation.

Crédit photo: http://www.flickr.com/photos/40491122@N03/3738306829/

• jQuery pour interagir avec les form
  Un bon billet pour débutant pour apprivoiser jquery dans le contexte des formulaires. Ca permet de faire rapidement certaines choses élémentaires qu’on utiliser plus tard dans des scripts plus complexes.
• Class PHP5 pour merger et compresser vos CSS
  Simple et efficace, cela reste une bonne pratique pour réduire les appels HTTP souvent pointé du doigt dans les performances d’un site.
• Styler vos boutons
  Encore un, mais bien fait. Et quand on est développeurs, on est content d’avoir ce genre de ressource ;)
• 20 moyens de réduire notre empreinte carbone en tant que développeur
  Et oui, c’est pas parce qu’on est bien au chaud derrière notre machine qu’on ne peut pas faire de petits gestes pour la planète.
• jQuery plugin d’approche
  Pour faire réagir un lien en fonction de la proximité de la souris. L’effet est très sympa!
• Doctrine plugin pour schema mysql workbench
  Dans le monde de la conception de modèle de données, mysql workbench commence à s’imposer grâce à un vrai look n feel. Voici donc un plugin qui permet de passer facilement d’un schema workbench à un schéma doctrine!
• Outils pour développeurs javascript
  Parce que le javascript a bien évolué, voici une liste d’outils très pratiques pour tout ce qui touche de près ou de loin à ce langage.
• Un robot twitter en PHP
  Pas vraiment d’utilisation précise mais le principe est sympa.

Je me suis donc dis que j’allais tout simplement le benchmarker grosso modo, afin d’avoir une idée du gain qu’on peut avoir à passer par des tableaux. Car en fait, on sait très bien que le 2e est plus rapide, mais la question, c’est de combien.

J’ai donc pris un modèle assez classique. Un couple de Departement/Region de France.

Dans mon fichier Table de mes départements, je rajoute la méthode suivante pour faire ma jointure sur régions

public function getAll()
  {
    return $this->createQuery('d')
      ->leftJoin('d.Regions r');
  }

Hydratation en objet

Parfait, maintenant, je crée une action qui récupère seulement tous les items de ma table, soit environ 100 départements, en relation avec une région chacun.

public function executeIndex(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute();
  }

Ca reste un cas tout a fait commun. J’ai donc lancé un ab, un programme livré avec apache qui permet de lancer l’exécution d’une page web, n fois avec n requêtes concurrentielles. j’ai décidé de le lancer 100 fois avec 10 requêtes à la fois. Et voici le résultat:

Document Path:          /hydrate/index
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:  16.862 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    5.93 [#/sec] (mean)
Time per request:       1686.205 [ms] (mean)
Time per request:       168.621 [ms] (mean, across all concurrent requests)
Transfer rate:          15.60 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       4
Processing:  1172 1665 167.3   1662    2337
Waiting:     1172 1663 166.5   1661    2337
Total:       1172 1665 167.4   1662    2338
 
Percentage of the requests served within a certain time (ms)
  50%   1662
  66%   1709
  75%   1750
  80%   1783
  90%   1860
  95%   1928
  98%   2102
  99%   2338
 100%   2338 (longest request)

Hydratation en tableau

2e action, le même code, le même résultat HTML souhaité, mais on passe dans le execute le fameux paramètre. Notre résultat ne sera donc plus une Doctrine_Collection, mais un tableau associatif avec en clé, les noms des champs.

  public function executeIndex2(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute(array(),Doctrine::HYDRATE_ARRAY);
  }

Et voici le résultat

Document Path:          /hydrate/index2
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:   10.086 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    9.92 [#/sec] (mean)
Time per request:       1008.569 [ms] (mean)
Time per request:       100.857 [ms] (mean, across all concurrent requests)
Transfer rate:          26.09 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.4      0       6
Processing:   598  992 112.9   1003    1239
Waiting:      598  991 113.0   1002    1239
Total:        599  993 113.0   1003    1239
 
Percentage of the requests served within a certain time (ms)
  50%   1003
  66%   1051
  75%   1081
  80%   1085
  90%   1104
  95%   1128
  98%   1149
  99%   1239
 100%   1239 (longest request)

Bilan

Alors évidemment, il faut prendre en compte la différence de temps de réponse qu’on peut avoir entre 2 lancement de ab. Mais l’objectif est surtout de montrer que le gain est non négligeable et vraiment réel.

On constate que le HTML reçu est bien le même. On a donc le même rendu!
Et côté performance, le 1er cas nous donne une requête en 1,7sec quand le 2e nous donne 1s soit près de 60% de mieux.

Conclusion, quand on souhaite réaliser seulement de l’affichage de données, il faut hydrater en tableau! Même si dans le cas présent, on parle de 0,7sec, il faut voir que c’est un projet vierge avec rien d’autre autour. Le gain est donc bien réel et pas seulement gadget.

Crédit photo: http://www.flickr.com/photos/don3rdse/3208161023/

Et forcément, chez les développeurs Symfony, ca frétille d’impatience car chaque jour nous rapproche de la sortie de la version 1.3 de notre framework PHP préféré, dernière release majeure avant le passage en 2.0 (oué pour le coup, ils sont pas encore à la mode).

Je me suis dis que ca valait le coup de faire un petit tour d’horizon des nouveautés attendues (au moins par moi) que se soit Symfony, Doctrine et même Propel:

Propel

On commence avec le feuilleton de l’été. Propel, mourra, mourra pas?

L’info a très vite circulé, et Propel a été enterré très vite après l’annonce de son créateur Hans Lellelid d’arrêter là les frais.

Mais dans son message, il y avait bien un appel au passage de relai, appel auquel François Zaninotto (himself, ex de la core team Symfony) et Sven Teitje ont répondu. Le premier prenant en charge l’évolution de la branche 1.x et le second le développement de la nouvelle branche 2.x.

D’ailleurs ils n’ont pas trainé car on parle déjà de Propel 1.4! On suivra bien sûr ça de très près.

Doctrine

Avec la mode 2.0, Mister Wage prépare lui aussi une version 2.0 de son ORM Doctrine. Peu d’infos encore si ce n’est qu’il sera plus beau, plus fort et surtout plus rapide! Grâce à PHP 5.3 en particulier.
Mais on pourra également retrouver des messages d’erreurs localisés! Et ça c’est la classe.

Mais ceci reste du futur pas proche. Et on va s’intéresser plutôt à la version 1.2, celle qui accompagnera la version 1.3 de Symfony (oui j’avoue, ils auraient pu se mettre d’accord sur les numéros de version, ça aurait été plus simple).

Et la nouveauté majeure pour moi, c’est la possibilité d’étendre les classe de Doctrine facilement et en particulier Doctrine_Query et Doctrine_Collection. On pourra alors généraliser certains comportements et ajouter de nouvelles fonctionnalités comme des tri personnalisés dans les collections ou adapter l’idée de NiKo pour les query.

On notera également, l’ajout d’un système d’extension directement via doctrine qui sont en fait des behaviors. Vous retrouverez la liste sur le site lui même. J’ai d’ailleurs de mon côté, une petite idée d’extension, mais on en reparlera le moment voulu ;)

Symfony

Gros programme pour cette dernière release (comme annoncée, la 1.4 ne sera qu’une 1.3 débarrassé des méthodes/classes dépréciées). Beaucoup de choses, mais voici un résumé de celles que j’attends vraiment:

• La vrai nouveauté, un Mailer de série! Basé sur Swift, très bonne librairie, cela fera toujours un plugin de moins à utiliser
• Le système de formulaire pluggué sur le système d’évènement avec 4 nouveaux évènements qui va permettre enfin de généraliser des comportements pour certains formulaires très facilement.
• Pouvoir ne pas générer les formulaires ou filtres d’un modèle lors de sa définition dans le schema.yml (seulement doctrine). Nan parce que, c’est vrai que des fois, on en a vraiment pas besoin.
• Petit détail enfin corrigé, les pager intègrent enfin les interfaces Countable et Iterator.
• Autre détail, à la génération automatique d’un label d’un champ de formulaire, les _id seront supprimés! Ca permettra d’avoir quelque chose de présentable plus facilement, pcq les _id nous on les voit pas, mais les clients, ca leur saute toujours aux yeux ;)
• Petite révolution dans les définitions de formulaire. Actuellement, il faut retirer du formulaire les champs qu’on ne souhaite pas voir s’afficher. Mais le coup classique du « je rajoute un champ et il apparait automatiquement alors que je voulais pas » ça agace. Dans la 1.3, ca sera donc l’inverse, il faudra spécifier les champs qu’on voudra afficher grâce à la nouvelle méthode useFields
• Niveau CLI aussi beaucoup de nouveautés, dont une assez formidable, la possibilité de rejouer seulement les tests qui auront échoué! Il suffira de rajouter l’option –only-failed.
• Pour Doctrine aussi, beaucoup de rajouts bien pratiques, comme la possibilité de regénérer/supprimer les fichiers liés à un model donné. Et même de resynchroniser tous les modèles avec le schema.yml (entendre par là qu’il supprimera ceux qui n’existe plus). Des petits gains de temps qui ne sont pas de refus, surtout dans les débuts d’un nouveau projet.
• Et bien sûr, la plus attendue pour la fin. Fabien en avait déjà parlé sur le blog, la possibilité de créer un installer pour la génération de nouveau projet qui fera automatiquement toutes les tâches de personnalisation que vous faisiez avant à la main ou en maintenant votre skeleton de projet.

En tout cas, ça fait envie, et ca va dans le bon sens selon moi. Pour tous les détails:

• Slides de Jonathan Wage sur Symfony 1.3 et Doctrine 1.2
• Page officielle des nouveautés de la v1.3

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

Et c’est parti:

• Retirer les bordures autour des liens cliqués sous Firefox.
  Il y a pas mal de temps, un ami graphiste m’avait demandé « C’est vraiment moche ces bordures quand on clic » (oui vous savez ces graphistes et le souci du détail ;)). Et je ne pensais pas (et encore aujourd’hui) qu’on pouvait les retirer. Et pourtant c’est tout simple. (Oui oui Gi, je parle de toi, souvenir :)
• Plugin jquery pour revenir en haut de la page
  Il sait se faire discret et rempli parfaitement son rôle. Une fois qu’on scroll un peu dans la page, un charmant petit module vient apparaître permettant de remonter en haut de la page.
• Slides Symfony 1.3 et Doctrine 1.2
  Pour ceux qui auraient loupé le lien! Je suis d’ailleurs ravi des nouveautés, en particulier pour doctrine, qui nous permettra enfin d’étendre Doctrine, facilement.
• Jquery Plugin Avant/Après
  Le genre de plugin qui m’emballe. Ceux dont on ne sait pas trop à quoi il pourrait servir, jusqu’à l’illumination!
• PHP 5.3, les appels dynamiques
  Et oui, c’est une des principales nouveautés de la 5.3 et ca méritait bien un petit tuto très bien ficelé comparé à ceux que j’ai pu croiser jusque là
• Créer simplement des animations avec jquery (via dator)
  En voilà une idée quelle est bonne. Une interface permettant de créer rapidement et simplement des animations et des interactions avec jquery. Un bel outil.
• Effet pour légende d’image avec jQuery
  La semaine dernière, je vous présentais un petit effect « ouverture de porte », voilà son petit frère avec un effet encore plus recherché (et réussi à mon goût)
• Contrôler votre base de donnée avec un seul fichier PHP
  Sans être exceptionnel, il mérite de remplir parfaitement son rôle. Un seul fichier PHP à uploader (ou à poser en local) et vous pouvez alors contrôler vos bases de données. Un phpmyadmin light, mais efficace.
• Créer un twitter like tout simplement
  Certes, le code est très basique, mais c’était surtout pour montrer qu’une bonne idée, ca reste une idée menée au bout (et je parle pour moi le premier ;p). Et que le concept de twitter se résume en ces quelques lignes.
• Petites astuces CSS pour améliorer le rendu typographique
  C’est simple, mais ce sont les règles élémentaires à toujours garder à l’esprit à mon goût

On essaye de diversifier mais je me rend compte qu’un peu de structure dans cette liste des fois, ça ferait pas de mal! Ou alors, je pourrais faire des compils best-of! Vous en pensez-quoi?

crédit photo: http://www.flickr.com/photos/lilit/

On se rappelle tous (enfin je parle au passé, mais Propel n’est pas mort hein :p) qu’on avait tout à disposition dans le BasePeer de notre modèle, les accesseurs, les modificateurs et quasi toutes les méthodes dont on pouvait avoir besoin. Avec Doctrine, la donne a changé, tant cet ORM est codé différemment.

On se retrouve du coup un peu perdu parfois, sans trop savoir ce qu’on peut utiliser. Et là, il faut bien sûr jeter un œil à l’API Doctrine. Mais on le sait tous, on a pas toujours le temps! Du coup, au travers de mes recherches, j’ai trouvé quelques petites méthodes que j’utilise régulièrement et dont je vais vous parler.

Le modèle d’exemple

Afin d’illustrer au mieux les différentes fonctions, je vais prendre en exemple un modèle basique, une liste de lien:

MyLink:
  columns:
    name: { type: string(100), notnull: true }
    link: { type: string(255), notnull: true }
    description: { type: string(4000) }

Un save qui retourne un booléen

Parfois, lors de petites modifications, on a pas toujours le courage de faire un try/catch sur notre transaction. TrySave répond à cette problématique, en incluant directement le try catch sur le save et en retournant un booléen, true si l’enregistrement a bien été commité, false si une exception a été levée. Bien pratique!

• Documentation trySave
• Exemple:

  public function saveMyLink()
  {
    $link = new MyLink();
    $link->name = 'Amicalement-web';
    $link->url = 'http://www.amicalement-web.net';
   
    return $link->trySave(); // Retournera true si la sauvegarde a été effectuée, false sinon
  }

Le nom de la clé primaire

Oui des fois, quand on veut généraliser une méthode, on a besoin du nom de la clé primaire de notre model. (Dans le cas d’un unset en vue d’un embedForm par exemple).

• Documentation getIdentifier
• Exemple:

  $link = new MyLink();
  $link->getTable()->getIdentifier();

Exporter votre modèle en différents formats

Que se soit pour générer des XML destinés à une application tiers, ou du json pour votre module javascript, on a souvent besoin de nos modèles dans un format d’échange. Et bien Doctrine intègre cette fonctionnalité de base, en permettant des export en tableau php, xml, yml et json.

• Documentation exportTo
• Exemple

  $link = new MyLink();
  $link->name = 'Symfony Project';
  $link->link = 'http://www.symfony-project.org';
  $link->save();
   
  echo $link->exportTo('xml'); // Attention par défaut exporte aussi les relations de l'objets. Il faut mettre à false, le 2e argument si on veut conserver seulement notre objet en question

• Rendu:

  <?xml version="1.0" encoding="utf-8"?>
  <data>
    <id>1</id>
    <name>Symfony Project</name>
    <url>http://www.symfony-project.org</url>
    <description></description>
  </data>

Importer votre modèle en différents formats

Et oui parce que Doctrine fait les choses biens, la réciproque existe aussi et est toute aussi utile. Vous pouvez ainsi hydrater  un objet à partir d’un xml, json, ou yml grâce à la méthode importFrom

• Documentation importFrom
• Exemple:

  $json = '{"id":"5","name":"Doctrine Project","url":"http:\/\/www.doctrine-project.org","description":"Orm PHP"}';
  $link = new MyLink();
  $link->importFrom('json',$json);
  echo $link->name; // Affiche "Doctrine Project"

Pour ce qui est d’hydrater à partir d’un tableau php, il y a 2 méthodes pour ça: fromArray et hydrate. Leurs différences, c’est la façon de faire. La première utilise les modificateurs de notre modèle (permettant ainsi de passer par des modifications qu’on aurait pu apporter à ces méthodes « set ») alors que la seconde remplie directement les attributs de notre modèle.

• Documentation fromArray
• Documentation hydrate
• Exemple:

  // On surcharge le modificateur de la propriété $url pour rajouter 'http://' devant
  class MyLink extends BaseMyLink
  {
    public function setUrl($url)
    {
      parent::_set('url','http://'.$url);
    }
  }

  Puis maintenant nos 2 appels:

  $data = array('name' => 'Amicalement Web', 'url' => 'www.amicalement-web.net');
  $link1 = new MyLink();
  $link1->fromArray($data);
  echo 'link1='.$link1->url; // Affiche http://www.amicalement-web.net
   
  $link2 = new MyLink();
  $link2->hydrate($data);
  echo 'link2='.$link2->url; // Affiche www.amicalement-web.net

Post/Pre methodes

Comme je l’avais utilisé dans l’exemple du behavior Geographical, Doctrine met à disposition toute une série de méthodes en post et pré traitement de nombreuses fonctionnalités comme

• Sérialisation
• Désérialisation
• Sauvegarde
• Suppression
• Mise à jour
• Insertion
• Validation
• Hydratation

Leur documentation à la suite les unes des autre.

Libérer de la mémoire

La performance, sans être un axe principal a mon goût, doit rester dans la tête de chacun. Pour ça, Doctrine propose une méthode pour effacer un objet ainsi que toutes ses références de la mémoire de l’ORM. A utiliser principalement dans des boucles quand on veut juste faire un traitement sur un ensemble d’objets dont on ne voudra pas se resservir ensuite.

• Documentation free
• Exemple:

  // Exemple tiré de la documentation doctrine
  for ($i = 0; $i < 1000; $i++)
  {
      $object = createBigObject();
      $object->save();
      $object->free(true); // true pour libérer même les relations
  }

Hydrater plus efficacement

Et oui, on le crie pas sur tous les toits, mais on est pas obligé de récupérer des objets complets quand on fait une requête avec doctrine même si c’est le comportement par défaut.
Quand on veut simplement faire de l’affichage, parfois seules les données nous intéresse et donc dans un gain de mémoire, on peut changer le mode d’hydratation:

• Doctrine::HYDRATE_RECORD
• Doctrine::HYDRATE_ARRAY
• Doctrine::HYDRATE_NONE
• Exemple:

  $q = Doctrine_Query::create()->from('MyLink');
   
  // Comportement par défaut, retourne un tableau d'objet
  $results = $q->execute(array(),Doctrine::HYDRATE_RECORD);
   
  // Retourne un tableau associatif où les clés sont les noms des champs
  $results = $q->execute(array(),Doctrine::HYDRATE_ARRAY);
   
  // Retourne un simple tableau où les champs sont dans l'ordre qu'ils ont été appelés
  $results = $q->execute(array(),Doctrine::HYDRATE_NONE);

Cela reste le fruit de mes tests et études, si vous avez des remarques ou des corrections n’hésitez pas!

Et vous, vous avez quelque chose à partager sur les méandres de Doctrine?