14
JUIN

SYmfony Live - Compte rendu de la deuxième journée

Publié le 14/06/09 à 16h46 par DJo

Ca y'est, la Symfony Live 2009, c'est terminé !

Et je ne suis pas déçu d'avoir fait le voyage: Les conférences étaient toutes très intéressantes et enrichissantes.

Symfony Live - Deuxième jour

(Crédits photo: Nicolas Perriault)

 

Voici sans plus attendre mon compte rendu de cette deuxième journée.

Tests unitaires et fonctionnels


Dans cette session, nous en avons plus appris sur les tests unitaires et fonctionnels.
Il est vrai que je n'en ai utilisé que très peu dans mes développement, mais j'ai maintenant compris tout leur intérêt, et je ne manquerai pas d'en utiliser plus régulièrement tout au long de mes développements.

Pour commencer, qu'est ce que ces tests ?

Tests unitaires:

Ils permettent de tester uniquement une méthode: Ses entrées et sorties, ses comportements attendus.
Les tests unitaires sont écrits une seule fois dans Symfony et peuvent être executés de manière infinie.

Les avantages des tests unitaires:

  • Eviter les régressions fonctionnelles
  • Découvrir des bugs
  • Documenter l'utilisation du code
  • Permettre le refactoring de l'application sans crainte
  • Garantir la qualité et la pérennité du code
  • Développer le strict minimum prévu par les specs
  • Gagner du temps et de l'argent sur le long terme
  • faciliter les migrations
  • Avoir confiance en son code


Mais attention, il faut maintenir ses tests tout au long du développement. Exemple: Changements de noms de variables etc.

Une question à se poser aussi, que et quand faut-il tester ?

  • Méthodes de classe
  • Les fonctions utilisateur
  • Les inclusions de fichiers

-> Inutile de tester l'API du langage et les lib externes !

Mieux vaut tester les méthodes ou fonctions critiques
Écrire des tests à la découverte de bugs par exemple
Peu de tests valent mieux que rien du tout !

Comment faire ses tests ?

  • PHPUnit
  • Simple Test
  • Ou bien sûr Lime de Symfony (Développé par F. Potencier)


Plus d'infos sur le framework Lime:

  • Adaptation du projet Test::More de Perl
  • Tout tiens dans 1 fichier
  • API Simple et lisible
  • Colorisation des résultats sur les systèmes *nix


Organisation des tests:

  • Arbo identique aux modèles
  • 1 fichier de test par classe
  • Une sélection par méthode que l'on souhaite tester


Piège a eviter:
sfContext: ne fonctionne pas avec les tests unitaire

Tests fonctionnels

Le principe est différent des tests unitaires.
Les tests fonctionnels utilisent un objet qui s'appelle sfBrowser, qui simule un navigateur.
Cet objet permet donc de simuler clics sur des liens, retour, etc...

Il existe d'autres objets utilisés par les tests fonctionnels:

sfTesterResponse pour tester tout le HTML.
Avec symfony 1.3, on pourra faire du Xpath pour tester plus rapidement.

sfTesterUser pour tester les propriétés d'un utilisateur, sa session, ses droits etc.

sfTesterDoctrine pour voir si tout s'est bien déroulé en base de données, si les requêtes ont bien fonctionné etc.

Mais il est possible de créer ses propres objets testeurs !

Et pour finir la session, il a été abordé le principe de l'intégration continue. J'avoue que j'ai un peu laché sur cette partie...

Symfony 2

Nouveautés de Symfony 2

(Crédits photos: Mirmoziband)


On enchaîne sur la deuxième session de la matinée, animée par le grand gourou en personne: Fabien Potencier.

Il commence par nous faire un petit historique sur les versions:

  • 1.2 Novembre 2009
  • 2.0 ?? (pas encore de date officielle,
  • 1.4 Dernière version de la branche 1.*: Version 1.3sans les fonctionnalités inutiles
  • La dernière version de la branche 1.* sera plus performante et propre.

Les nouveautés de Symfony 2 en vrac:


Nouveau système de templates:
Différent de smarty, plus un framework de templating qu'un système comme smarty.
Le format des templates peut être sous n'importe quelle forme: Smarrty,PHP, son propre système de templating etc.

Conteneur d'injection de dépendances

Le core de Symfony 2 sera très petit (tiens sur un slide)
Il sera 7 fois plus rapide que Symfony 1 au niveau du core sur un hello world.

En fonction de ce que l'on voudra faire, on pourra désactiver certains modules etc pour gagner en perf.
On pourra faire le choix entre confort et rapidité de développement ou performances en développant plus "à la main".

Symfony 2 Kernel: The request Handler
Notifie des evenements (6 events:
application.response: Modifier l'objet response avant l'envoi au navig)
application.request: Déclenché au tout début de l'app: utile pour le système de cache.
application.load_controller: Le seul event a écouter, il faut passer un callable + les params
application.view: Si le contrôleur ne retourne pas un objet response, alors on fait appel à un objet vue
application.exception: Permet la gestion des erreurs


Une session intéressante, Symfony est en perpétuel évolution et a encore un bel avenir derrière lui !

 

Migration d'une application microsoft sous Symfony

 Migration d'une application microsoft sous Symfony

(Crédits photo: Nicolas Perriault)


Après une petite pause, nous passons à une session totalement différente.
Retours sur expérience sur la migration d'une application développée avec les technologies microsoft en une application Symfony.

Les objectifs de leur migration:

  • Avoir un ORM
  • Implémenter un modèle MVC
  • Avoir un bon niveau de sécurité
  • Accompagnement du développement (Utilisation d'un framework)
  • Séparation du backend et frontend


Après plusieurs comparatifs, ils ont finalement choisi le framework Symfony, qui répond à tous ces besoins.

Aspects techniques / environnement:

Voilà l'évolution suite à la migration vers Symfony:

  • Windows Serv => Linux
  • IIS => Apache
  • Subversion
  • Eclipse PDT


A terme: Intégration continue

Leur retour sur expérience montre concrètement qu'une application Windows peut parfaitement migrer pour une solution Open Source avec Symfony.

 

Building a plateform opensource with Symfony

Building a plateform opensource with Symfony

(Crédits photos: Mirmoziband)


On continue dans la série des retours sur expérience, mais cette fois-ci avec Dustin .... de Yahoo!

Chose que j'ignorais, Yahoo! semble friand du Framework.
En effet, ils s'en servent très régulièrement dans leurs applications.
Apparemment, ils l'ont un peu modifier pour leurs besoins spécifiques.

On trouve par exemple:

  • Yahoo bookmarks
  • Yahoo answers
  • Yahoo widgets
  • Et bien d'autres sites développés par Yahoo! que je n'ai pas eu le temps de noter.


Dustin nous a aussi donné pas mal de tips concernant les optimisations/performance:

Utilisation du cache important pour les applications à fort trafic:

  • opcode cache (APC, Xcache ...): A utiliser pour le routing et le cache I18N
  • Memcache: Pour le cache des templates.


D'autres astuces en vrac:

  • utiliser core_compile
  • supprimer les debug  -> sfOptimizerPlugin
  • Ne pas utiliser de .htaccess, previlégier une config apache réelle
  • Mettre un minimum d'include path
  • Augmenter realpath_cache_size + realpath_cache_ttl
  • Utiliser apc.stat = 0
  • Utiliser @routeName dans Symfony
  • Ne pas utiliser de composants dans les boucles

 

Symfony pour gérer les medias

Symfony pour gérer les medias

(Crédits photo: Nicolas Perriault)


Une des sessions que j'ai préféré car j'ai longtemps cherché un plugin complet permettant de gérer facilement tous les médias d'un site sous Symfony 1.2 ... sans succès !

Actuellement, il existe quelques plugins à cet effet comme:

  • sfMediaLibraryPlugin: Symfony 1.1 only / Propel
  • sfAssetsLibraryPlugin:
  • pkMediaPlugin
  • sfGallery2Plugin


Mais elles ne sont pas portées en 1.2 ou ne sont pas complètes.

Il nous a été présenté un plugin en cours de finalisation de développement, tout simplement énorme !

cleverMediaLibraryPlugin: Le plugin reprend le même concept que les derniers plugins cités mais en bien mieux et complet.

  • Solution d'entreprise pour gérer les médias
  • Grand nombre de fichiers supportés: Images, vidéos, documents (doc, pdf ...)
  • Abstraction du stockage: Medias stockés sur la machine du site ou distant. Accéder a des systèmes de fichiers virtualisés.
  • API de gestion programmatique des médias
  • Support de métadonnées: Recherche sur le tag X, phoos prises par tel appareil photo.
  • Recherche, classement, droits d'accès


Upload d'un PDF: Miniatures de toutes les pages -> création d'un handler PDF -> générer miniatures

Le plugin sera basé sur un autre plugin développé pour l'occasion: cleverFileSytemPlugin
Permet l'écriture de fichiers / dossiers sur 3 types de filesystems: Disk, FTP ou S3...
Tout simplement génial, vous ne trouvez pas ?

Nous avons eu le droit à une petite démonstration live de son utilisation.
Tout semble très intuitif et efficace.
A noter qu'il utilise du jQuery pour son interface: Cropping, multi upload ...

Il faudra donc surveiller de près sa sortie.

Bonnes pratiques du développement Symfony en 30 points clés

Gilles Taupenas, Marc Hugon

(Crédits photo: Nicolas Perriault)


Nouvelle session présentée par deux développeurs de Sensio.
Une revue nécessaire des bonnes pratiques de développement:

MVC

1) Respecter le MVC:
* Emplacement des parties du code
* Contrôle du code régulier

2) Pas plus de 10 lignes de code dans les methodes du controlleur: actions executeXXX

3) Composants: Pas automatique, utiliser plutôt un partial si pas besoin de code

4) Helpers: Utiliser mais pas trop !

5) Templates: Le moins de code PHP possible !

Concernant les BDD

6) Utiliser un ORM: Propel ou Doctrine. Affranchir BDD cible / Permettre de changer la structure de la BDD facilement

7) Ne pas utiliser d'ORM Propriétaire ! Car: Réinventer la roue / Maintenir l'ORM / Documentation à créer, Transferts de compétences ...

8) Limiter au maximum les requêtes SQL ! Mais surtout pas dans les controlleurs et encore moins dans la vue !

9) ORM: Fonctions comportementales: Donner un comportement / hors système d'héritage)

10) ORM: Gestion unifiée du schéma: 1 schéma unique: YML ou XML ou Schéma de la base modelisé

11) ORM: Maintenance des bases: Fonctionnalités de migration / Versionning

Maintenance:

12) Lisibilité du code: Se (re) trouver facilement dans un projet: Rendre lisible => homogéniser / Standards de codage...

13) Code HTML situé uniquement dans les templates !
Norme unique: Règles d'écriture (indentation, syntaxe des variables, langue utilisée) / Documentation / Règles de retour à la ligne
Dans les templates, préconiser les syntaxes alternatives: endif; endforeach; etc.

14) Standards de code: Répertoires
Librairies project utiliser le répertoire "/lib"
Mettre les librairies externes dans le rep "/lib/vendor"

15) Ecrire des tests ! Pendant la phase de prod, écrire en priorité les tests unitaires
Ecricre les tests le plus tot possible
Mais ca ne sert a rien de faire la couverture complète des tests
A la fin de phase de développement, écrire des tests fonctionnels.
Maintenir les tests !

16) Utiliser Symfony! Ne pas utiliser $_SESSION mais sfUser
Ne pas utiliser $_SERVER, $_POST ou $_GET mais sfRequest
Pas de variables globales

17) Code symfony: Ne jamais modifier le code du framework, il doit être surchargé.

18) Fixtures: Uniquement pour avoir un jeu de données pour démarrer, pour les jeux de test.

19) Le routing: Faire des routes nommées / Ne jamais utiliser des URLs internes en dur !

20) Environnements: Utiliser les environnements de devs / prod et tests

21) Déploiement: Utiliser les outils de déploiement proposés par Symfony. Rsync, pas de FTP. Supprimer les contrôles de développement § Utiliser la ligne de commande.

22) De l'explicite: Mode explicite dans les actions et

Performances

23) Le parsing de fichiers PHP est coûteux: Installer un accélérateur PHP: Xcache ou APC

24) Debug tools: Vérifier les perfs sur la barre de debug Symfony:

25) Cache: Cache d'objet / cache HTML /Taille du cache

26: UTF-8 conseillé ! Plus rapide, internationnal

27) Sécu, ne pas utiliser $_GET / $_POST

28) Utiliser les plugins existants: Lire le code, si clair, alors il doit être bien.

29) Faire du versionning

30) (Pris par le temps, ils ont accéléré sur la fin, je n'ai pas eu le temps de voir quel était le dernier point :( )

A appliquer !

 

Migration de Dailymotion sous symfony

Migration de Dailymotion sous symfony


Olivier Roux, Core lead développeur chez dailymotion, a présenté cette session, encore une fois très enrichissante.

A la base, dailymotion utilisait un Framework codé maison: aucune doc,
Très peu de documentation, difficile de se retrouver dans les quelques 670000 lignes de codes dans 1600 classes et 16000 méthodes...


Pourquoi utiliser Symfony ?

  • Passer moins de temps à inventer la roue
  • Une base de code saine, documentée et cohérente
  • Cadrer les développeurs en leur imposants certaines bonnes pratiques
  • S'équiper de meilleurs outils (Tests unitaires)
  • Profiter de l'aide d'une vaste communauté et d'une équipe francophone
  • Contribuer à un projet opensource


Migration:
3 mois de travail pour 3 personnes
Migration par partie grâce au découplage total des différents éléments.
Extensions des objets Symfony pour répondre à des besoins specifiques: DM_Request / DM_Routing

Résultat de la migration, après avoir perdu 10% en performances, ils en ont regagné 10% de plus par rapport au code d'origine.

Conclusion

La conférence s'achève avec une démonstration de refactorisation live de Fabien Potencier.

En conclusion, une conférence que j'ai beaucoup apprécié et referai volontiers l'année prochaine!
J'ai aussi pu rencontrer un lecteur de la Ferme du Web bien sympa du Mans ! (vjousse)

Je n'ai plus qu'a trouver quelque chose à démonter avec mon super tournevis multi fonction Yahoo! :D

Baraguiné par ipatate le 14/06/09 à 21h24
ipatate sur La Ferme du Web
super merci pour le résumé, j'ai l'impression que ça t'as encore plus motivé pour symfony...
Baraguiné par Six le 15/06/09 à 10h41
Six sur La Ferme du Web
Vraiment sympa, à vrai dire ce sont tes billets sur cette conférence qui m'ont fait franchir le pas depuis la semaine dernière, et ben je ne regrette vraiment pas !

J'ai une question cependant, penses-tu qu'avec les sorties de nouvelles branches (1.*) la migration depuis la 1.2 sera simple ? Et même question concernant la sortie de la version 2.0 ? En ont-ils parlés ?
Baraguiné par DJo le 15/06/09 à 13h17
DJo sur La Ferme du Web
Passer de la version 1.2 à la version 1.3 ne devrait pas poser de soucis, de toute façon, la branche 1.2 sera toujours maintenue.
Mieux vaut partir sur Doctrine comme ORM justement pour faciliter les migrations de version.

Concernant la version 2, aucune idée.

Ajouter un Commentaire

Pour poster un commentaire, vous devez être identifié. Vous pouvez choisir parmi ces trois méthodes d'identification:

Compte la Ferme du Web

Identifiez-vous
Inscrivez-vous

Compte Facebook

Connexion avec Facebook

Compte Twitter

Connexion avec votre compte twitter
Rechercher sur la Ferme du web