ParisOnRails du 1er décembre 2008 : ce qu’il s’y est dit ! (matinée)

Publié le 1/12/2008, par Anthony Dahanne dans Agile | Ajouter un commentaire

Ce Lundi 1er Décembre 2008 avait lieu pour la 3ème fois la conférence annuelle des développeurs Ruby On Rails, j’ai nommé ParisOnRails, qui avait lieu à la Cité de la Science, dans le quartier de la Villette à Paris.

La journée a commencé vers 9h30 par une présentation de la journée par les 2 organisateurs Richard Piacentini & Laurent Julliard.

La première présentation était celle de Ruby 1.9, par Guillaume Desrat

Guillaume a tout d’abord commencé par présenter brièvement l’association ruby france, puis est rentré dans le vif du sujet.

Ruby 1.9 prépare la 2.0, en celà beaucoup d’incompatibilités apparaissent, notament au niveau de la syntaxe (en particulier les tableaux et hash).

Du coup, au chapitre des nouveautés, on a des hashes plus simpes à écrire , les paramètres ne sont plus obligatoires dans les appels de méthodes, enumération plus simple à utiliser, multilingualization (m17n) pour un support utf8 simplifié, les f ibers : thread controlables, que l’on arrête et reprend où et quand l’on veut, et enfin pour les regexp : on a désormais un nommage des matches avec un tag <mon_match> à insérer dans son expression.

De plus, il est à noter que ruby 1.9 est plus rapide (les exemples de Guillaume le donne presque 5 fois plus rapides sur des algos type suite de fibonnaci)

Reste que sa non compatibilité avec les versions précédentes représenteront peut être un frein à son adoption massive…

Présentation de moo tools(librairie javascript) par Matthieu Fosse

Cette librairie JavaScript est encore peu populaire (utilisé par 8% des utilisateurs de librairis JS), en même temps, elle n’est pas utilisée par défaut dans Rails…

Pour l’historique, Moo Tools basé sur protoype à l’origine, et est aujourd’hui plus modulaire que ses concurrents, on peut utiliser la délégation d’événements MooTools pour séparer le code HTML du code Javascript.

Après cette présentation, et avant la pause de milieu de matinée, un débat s’est improvisé sur “doit on ou pas écrire du JavaScript ?” cette question est assez répandue car il existe, même parmi la communauté RoR, 2 clans : ceux qui aiment écrire du JavaScript, et ceux qui … n’aiment pas , pour rester politiquement correct… Pas mal d’avis convergeaient pour dire que finalement JavaScript dans un site de contneu, ou communautaire, doit être utilisé avec parcimonie et contrôle, pour garantir l’accessibilité et le référencement, et que le sgéénrateurs de JavaScript type GWT doivent être réservés pour des applications riches (RIA, remplacement d’application lourdes, etc..); en tout cas, je ne vous cache pas que c’est aussi mon avis .

Après la pause, a eu lieu la présentation

Design pattern en Ruby par Russ Olsen

en conf call de New York.(5heures du matin pour lui!)

Russ a 30 ans d’expérience en programmation et a découvert Ruby quand il a voulu apprendre la programmation à l’un de ses enfants; aujourd’hui il est l’auteur d’un livre sur les design pattern en Ruby.

Il nous a tout d’abord présenté 2 éléments de l’histoire de la civilisation :

• au début de la civilisation, les gens utilisaient des paniers pour transporter des biens, la poterie est arrivée, mais a repris la forme des paniers pour ne pas gêner les gens lors de la migration technologique (!)
• au debut de sa carriere, domino etait utilisé partout, avec son langage Fortran, les gens savaient que c’était nul, mais restaient coincé avec, et ne pensait pas que les choses changeraient

Les gens ont du mal à quitter une technologie pour une autre.

Aujourd’hui, en Ruby, le concept le plus utilisé est convention over configuration; pour expliquer ceci à ses pairss (plutot habitué à Java), il a utilisé les design patterns.

Pour exemple, Adapter , pour faire communiqer des interfaces différentes, on utilise en Ruby active record qui permet de faire communiquer son appli avec des bdd différentes.

Iterator, en Java c’était une classe à part entière, une mécanique à mettre en place, en Ruby, on appelle juste .each sur son tableau, c’est déjà tout intégré.

Pour le pattern Factory, en Java, la classe représente tout, c’est figé; en Ruby, on peut on la changer en cours de route on peut rajouter des comportements à la volée. (il y a bien Spring qui facilite les choses en Java, mais c’est une autre histoire..)

Il a rencontré beaucoup de résistance à démontrer l’intérêt d’un nouveau livre sur les design pattern au début, car tout le monde pensait : “Les design pattern sont écrits une fois pour toutes pour tous les langages”.

Ce qui lui rappelle que les gens qui pensaient que les paniers étaient le dernière trouvaille pour transporter des biens, ou les gens qui pensaient que Fortran était le dernier langage de progammation , ont finalement eu tort !

Pour chaque nouvelle techno, les développeurs doivent comprendre les avantages de cette dernière : les premiers programmes en C++ utilisaient énormément l’héritage, un peu trop d’ailleurs; c’est la même chose en Ruby aujourd’hui, en Ruby doit on utiliser le changement de la classe dynamique ? si oui dans quelles proportions ?

En Ruby il y a encore des progrès à apporter, on peut améliorer l’utilisation de Ruby, en facilitant le passage de plusieurs blocs à une méthode, l’utilisation des closures, ou encore la programmation multi threads : il y a encore du travail pour faciliter l’utilisation de ces concepts.

Aussi, si Russ fait toujours sauter au plafond ses clients en leur parlant de Ruby On Rails, il les rassure en utilisant JRuby, où il peut toujours livrer l’application avec un fichier war (je pense aussi que JRuby est un des meileurs leviers d’adoption de Rails en entreprise)

En conclusion, il appelle les participants à ne pas être “des programmeurs Ruby” ni des “programmeurs Rails”, mais simplement des programmeurs ouverts à la nouveauté et l’évolution !

La suite dans un prochain épisode, après la pause déjeuner !