Paris on Rails 2007
Par Yannick AMEUR le lundi 10 décembre 2007, 22:46 - Conférences - Lien permanent
Ruby on Rails fait son show à La Villette
le 10/12/2007
Développeurs, chefs de projets, décideurs
Venez découvrir Ruby on Rails, un framework open-source qui révolutionne le développement d’applications Web. Rails maximise la productivité du développeur et le retour sur investissement de l’entreprise en permettant la création d’applications robustes et évolutives.
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 objetutilise 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,
- la convention de nommage CamelCase comme en java
- 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
- Utilisation de Duck Typing, chaque objet à un type
- 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