Paris on Rails 10/12/2007

Nous avons été accueillis par Richard Piacentini, organisateur de Paris On Rails 2007.

Vous pouvez retrouver les slides des présentations sur le site de Paris on Rails.


Introduction à Ruby par Laurent Julliard

Ruby : Yukihiro "Matz" Matsumoto, le créateur de Ruby, ce langage de script objet
utilise des messages (comme méthodes : dérivé de SmallTalk ). 

 

Spécificités du langage Ruby :

  • permet de modifier le code de l’api direct dans votre développement,
  • Héritage simple de classe
  • Simplification de l’écriture via des raccourcis symbolique
  • Les modules sont en comparaison du Java des interfaces et structure
    l’espace de nommage
  • Block et itération permettent la suppression de l’utilisation de boucles …
  • Les symboles : (pointeur) étiquette.

 






Les Gems sont des Api pour Ruby

Présentation du Gem Rails sur Ruby :

Principes très fort :

  • Dry
  • Convention + que configuration
  • Dis ce que tu veux et fait se que t’as dis
  • Développez vos applications web seulement en Ruby (un peu extrémiste à mon avis)
  • Utilisation de MVC : le Framework est utilisable directement (pas de conf à la Struts ou JSF)
  • Arborescence des projets  réglementée comme pour un projet Maven

 

La persistance des objets

Un ORM simple directement lié au schéma de la base. Donc nous devons disposer d’une base de données objets, oubliez l’utilisation du base relationnel de type fonctionnelle comme nous les aimons « beurk !».

L’API de validation vous permet d'enregistrer les objets en toute sécurité.

L’ORM de Rails gère très bien les relations entre objets n-n 1-n …

Dans les vues :

Rails génère automatiquement des scripts, nativement ERB et via des plugins (ou est la différence entre les plugins Rails ou les Gems de Ruby et les Frameworks Java voir les TagLibs ?). Ainsi l’utilisation d’Ajax via des modules permet de faire du Web 2.0 de facons très transparente.

Les tests :

Intégration d’un Framework de test unitaire et d’un générateur de rapports de couverture.

 

Tout cela fait de Ruby On Rails le Framework de développement web le plus complet à ce jour, le plus sexy pour les développeurs mais aussi et surtout pour nous les Agilistes de Valtech un langage de développement Agile.

 

Aurélien Géron, Fondateur de WIFirst

Retour d'expérience sur le développement d'une suite
d'applications web communautaires avec Rails

Questions du choix du langage pour la réalisation du projet (Webmail):

  • Mise en production et charge ?
  • Disponibilité des développeurs ?
  • Quel sont les risques ?

WIFirst a trouvé sa clientèle dans les cités U.

Motivation du choix de Rails / Java ou Django(Python) 

  • Le choix de Rails vs. autres frameworks (Java et Django notamment)
    • Java à trop de configuration, trop lourd, trop de Framework (Quoi !!!??? Trop de choix tue Java … Bas sa alors)
    • Ruby is very simple, la communauté trop forte, un framework très complet (Haaa it’s so gooooood !o)
  • Monter une équipe projet Rails: dimensionnement, organisation et montée en compétence
    • Trouver les développeurs : sur le marché, ils sont très peu visibles
    • Le choix est des développeurs en interne + des sous traitants
  • Mise en production et optimisation, le cas concret d'un Webmail entièrement développé en Rails.
    • Présentation de l’architecture du projet : Une seule application avec 3 services
    • La première version présentable et fonctionnelle a été développée en trois mois

Bilan :

Lors de cette réalisation, des problèmes d’ergonomie entre les prestataires d’où la nécessité de rester Agile et d’imposer le regroupement des prestataires, le partage des tâches entre les différents prestataire doit faire l’objet d’un suivi et surtout de responsabiliser les prestataires sur les interactions, le développement au forfait (donc contractualisé par un cahier des charge) à posé aussi des problèmes de réalisation et de responsabilité, l’application des méthodes agiles n’a pu être appliqué sous la pression des délais.

Bénéfice de Rails :

Code maintenable et structuré, MVC, ActiveRecord vraiment bien fait, RestFull, vues avec prototype vraiment facile à utiliser.

Limitation de Rails : la maitrise des autres langages : Mysql bien comprendre l’utilisation du requêteur, maitrise du JavaScript : retaper le code généré, et maitriser le CSS, DRY et vraiment trop poussé, les retouches sont plus dur à faire. Test sur l’Ajax ? (J’ai déjà entendu cela quelque part)

 

Mise en production :

Optimisations : communication des 3 applis : gestion de la base, Imap : limitation des requêtes, driver de communication en C , mise en place du cache. Pour la partie photo, l’utilisation de l’xml est lourd et verbeux.

Leur projet est de mettre à disposition leur webMail Rails en OpenSource

 



 

Nicolas Mérouze présente :

Gestion des formulaires via les vue,
gagner du temps sur la génération des formulaires

.

Chez Rails, ERB est utilisé pour générer le code Html, mais il y a d’autres solutions, d’autres plugins :

  • DRYML : apprentissage d’un nouveau langage …,
  • MasterView : Long et fastidieux,
  • Markaby tout en ruby plutôt simple mais avec des problémes de perf,

La solution que Nicolas préconise est HAML inspiré du CSS : utilisation de #content et « .entry » pour la génération des Div. %h2 pour la balise h2 en html
Pour les attributs : utilisation de raccourci simple et rapide dans l’esprit Ruby (ex : !!! pour générer le Doctype) et mixage des syntaxes.

En bref :

  • ré écriture du code ERB en plus simple et plus rapide à interpréter
  • L’indentation et comme avec Python.
  • Utilisation du plugin Headliner pour gérer l’affichage texte.

Résultat : écrire du code rapidement avec HAML

Utilisation de SASS pour le CSS :

  • utilisation de variables, plus d’{ et de ; 
  • gestion du fichier en indentation comme en python.
  • On peut aussi utiliser un Framework CSS ex : Blueprint

Les bonnes pratiques pour Rails :

  • rester DRY
  • utiliser les Helpers,
  • les vues doivent être lisible … même problème qu’avec les Jsp et le code embarqué.
  • Voir en 1er si Rails permet de simplifier le codes (Allez lire la documentation !!!) ensuite réaliser un Helper donc sortir le code (ex en java les TagLib). Puis faire du refactoring.
  • Utilisation du pattern Presenters pour la mise en forme des données métier.

Rails soulève les mêmes problèmes sur les Best Practice du développement web et force donc à l’utilisation des patterns comme en Java, le chemin reste le même, que va devenir la simplicité de Rails dans l’avenir ? Des réponses dans Paris On Rails 2008. !o)

 

Christophe Porteneuve présente :

Utilisation de Prototype dans rails 

La présentation prend rapidement la forme des bests Practices de Prototype et JavaScript :

 
L’utilisation du bind pour supprimer les « this. » dans les scripts. Permet l’application partiel (remplir directement une partie des args). Attachement d’objet et utilisation du premier argument pour la gestion de l’évènement. Gérer le bind intelligemment, seulement si la fonction utilise this !  ou sinon sauvegarder this pour ne pas le perdre.

 
Utilisation d’Enumerable :

ne pas utiliser each (itérateur générique) , utilisez pluck / invoke :

  • Pluck  recupe une propriete dans ta liste
  • Invoke appel la même méthode des object dans la list
  • Map/collect : transformation générique et autres …

Ajax response : onXxx remplacé par un ajaxResonse

Utiliser correctement les événements :

Element ou findElement : Event.element

This a plus de sens depuis la version 1.6 de prototype

Utilisation des gestions d’événements.

Utilisation du chargement DOM

Les événements Perso.

… trop à la bourre le TDD ….

 

Ok ok il parle beaucoup, mais il a de très bonnes excuses : il est passionné et pas mauvais !o) allez voir sa présentation sur le site.

 

les Tests par Jean-Michel Garnier

TestUnit pour Rail comme Framework de test, Présentation RSpec(Fitness)

Présentation de TDD test et des XUnit

De Refactoring par Martin Fowler,

Et RSpec :

Fait pour écrire du code naturel donc pas de test mais des exemples, pour chaque classe on a une spécification (un test) utilisation comme JUnit.

Utilisation dans NetBeans pour avoir son rapport.

Configuration de RSpec : et utilisation des mockObjects. Attention à la maintenabilité des mockObjects (Faire du refactoring !!)

RSpec produit un rapport des tests. Les tests sont des documentations

Utilisation de Autotest pour exécuter les tests juste sur les grappes d'objets liées aux modifications via introspection.

Rcov permet de vérifier la couverture du code.

 

Specification  / models et via les méthodes métier, par les finders et sur les contrôleurs : utilisation des fixtures et des mockObject.

Merci le plantage du Mac … (la revanche du Bill !o) )

 

Voila pour Paris On Rails 2007