La planète Ruby et Rails: Le discours de l'état de l'oignon

Le titre du post est directement inspiré d'une présentation réalisée par Larry Wall sur l'état de l'art du langage Perl: "State of the Onion 2000".
J'ai téléchargé un livre blanc sur l'écosystème de Ruby et Rails sur le site infoether(gratuit).









Cette brochure aborde tous les composants de Ruby on Rails avec tout d'abord 'Ruby'.

1) Ruby.
Sa communauté de développeur est en hausse (1 million) et devrait atteindre le chiffre de 4 millions en 2013 . Ce langage est qualifié comme 'l'ami' du développeur. Il est vrai que les pratiquants sont souvent enthousiasmés par ce langage.

Il existe maintenant plusieurs machines virtuelles pour Ruby:



Tout d'abord celle du maitre : MRI : Matz's Ruby Interpreter (version 1.9 ) , elle est utilisée par défaut sur machine Linux.


Jruby: sponsorisée par SUN : elle permet d'utiliser du Ruby sur une JVM java.


IronRuby:sponsorisée par Microsoft :elle permet d'inclure du Ruby dans une architecture .NET


MacRuby : C'est un portage de Ruby sur Max OS X qui permet aux programmes ruby de tirer parti au maximun des architectures Mac.

Et encore deux autres : MaGLev et Rubinius.

La liste des grandes compagnies informatiques actives dans le domaine Ruby est :

• Sun
• Microsoft
• Apple
• IBM (driver ruby pour ses bases de données)
• SAP : les produits de SAP sont des progiciels paramétrables , mais de plus en plus ses clients désirent des adaptations fines . Ces modifications sont lourdes et complexes à réaliser. Ici l'idée du laboratoire de SAP est de faire de Ruby le langage de développement embarqué dans leurs solutions.

Ainsi pour beaucoup d'acteur, Ruby, Ruby on Rails représente un contrepoids , une alternative utilisable face à Google et Python.


2) Rails.

Ruby on Rails en perçu par le marché comme le complément indispensable des gros frameworks J2EE . La répartition au sein d'une entreprise de 20% Rails et 80 % J2EE est une bonne estimation. Les dernières manifestations Ruby on Rails ont montrées une grosse percée de ces technologies dans le monde de l'entreprise.
'Better,faster,cheaper' (Meilleur,plus rapide, moins cher) est la phrase qui revient le plus souvent lors de ces conférences.

Une rumeur tenace concernant la tenue du framework à la montée en charge collait à la peau de Rails. Les mésaventures de Twitter en étaient à l'origine. C'était surtout un problème global d'architecture applicative. De fait Twitter a abandonné en partie Rails pour développer son propre langage et sa propre base de données. Twitter explose les échelles de références en termes de message,de connexion ou d'utilisateur.
Ruby on Rails couplé au serveur Mongrel et nginX forment un attelage solide pour supporter la charge. Mais il faut pour cela se faire assister par un expert en architecture Rails.

3) Le Cloud computing.

Le segment de prédilection de Ruby on Rails est le cloud computing. Des sociétés naissent tous les jours dans se domaine (Engine Yard , Heroku, amazon S3 ,rackspace) . Rails a un avantage certain sur ses concurrents: l'industrialisation du déploiement des applications. Le framework a été pensé dans ce sens dès sa conception.
Le cloud computing sera Ruby on Rails ou ne sera pas (eg)

4) Le reste de l'écosystème.

Il existe plusieurs framework avec Ruby l'un d'eux est destiné à la VoIP et ToIP (voix /téléphone sur IP) : Adhearsion

Adhearsion is a new way to write voice-enabled applications. It's not just an API or library — it's a fully-featured framework

Adhearsion est une nouvelle manière d'écrire des applications de voix sur IP. Ce n'est pas une simple API mais une infrastructure complète(compatible avec Asterix).


Enfin , il existe un portage de Ruby sur smartphone de type:
Symbian et ........... android de Google.

Ruby , Ruby on Rails deux hommes et un même combat.

J'ai lu sur un blog un article humoristique sur : la brève histoire 'bidon' des langages informatiques. Sur ruby l'auteur écrit :

1995 - Yukihiro "Mad Matz" Matsumoto creates Ruby to avert some vaguely unspecified apocalypse that will leave Australia a desert run by mohawked warriors and Tina Turner. The language is later renamed Ruby on Rails by its real inventor, David Heinemeier Hansson. [The bit about Matsumoto inventing a language called Ruby never happened and better be removed in the next revision of this article - DHH].

Ce qui donne en résumé :

1995 - Yukihiro "Mad Matz" Matsumoto crée Ruby pour éviter une apocalypse .... La langue est rebaptisée Ruby on Rails par son véritable inventeur, David Heinemeier Hansson. [La mention sur Matsumoto inventeur d'une langage appelé Ruby n'a jamais eu lieu et il sera préférable de la supprimer dans la prochaine révision de cet article ].

Ce trait d'humour met l'accent sur une grosse injustice. Tout le mode parle de Rails en oubliant de préciser 'Ruby on Rails' . Certains décideurs pensent même que Rails est un langage.

Sans Ruby, il n'y aurait pas le Rails actuel, et sans Rails il n'y aura pas de Ruby actuel ni cette prévision 4 Millions de développeurs Ruby en 2013. C'est un peu la quadrature du cercle. Mais au lieu que cela soit un problème, c'est au contraire une force supplémentaire.

Matz est quelqu'un de très simple qui ne comprend toujours pas pourquoi certains le considèrent comme un gourou. David,lui, est souvent sollicité pour poser pour des couverture de magazine, mais il n'a pas pris la grosse tête pour autant. Ils forment une sorte de couple équilibré où chacun a trouvé son espace. Tous les deux ont démontré qu'il y avait autre chose de plus important que l'informatique où que leurs travaux.

Il existe des programmeurs qui font du Ruby sans faire de Rails. Qui passent du temps pris sur leur vie de famille à évangéliser, organiser des rencontres ou des apéros Ruby. Alors s'il vous plait, en guise de marque de respect ne dite plus Rails mais Ruby on Rails.

Un autre couple célèbre est celui formé par cette fois des frères ennemis (dans le bon sens du terme) Larry Wall le père du langage Perl et Guido van Rossum 'dictateur bienveillant à vie' du langage Python (il travaille chez Google) . Leur rivalité existe et reste très bienveillante. Ils ont été tous les deux chahutés par le vent du sillage de Ruby on Rails. Larry s'est mis à apprendre le japonais pour essayer de comprendre la manière de penser de Matz. Et je n'ai pas encore entendu Guido promouvoir Ruby comme 3 eme langage pour les API Google.

Et n'oublions pas notre objectif : La domination du monde:

Dimanche .. golf

Le matin au golf de la poudrerie avec Seb:

Un birdie pour Seb ... Enorme
mais pas sur ce trou

Décisionnel vs gestion : définir une application décisionnelle.

Où est la frontière entre une application décisionnelle et une application de gestion? . Qu'est ce qui peut définir une application décisionnelle ?. Voici les questions posées, place aux réponses.

Dans le cadre de mon travail, je suis confronté à ces deux familles d'application et je note une confusion dans leur classification. La question n'est pas anodine car elle conditionne souvent le choix des technologies à utiliser : soit une plateforme décisionnelle, soit un simple framework. Les conséquences ne sont pas neutres.

Les concepts qualifiant le plus souvent le décisionnel sont:

• La source des données
• Le caractère multidimensionnel
• Les restitutions
• Les simulations
  

La source des données.

La présence d'une multitude de source de données, hétérogènes n'est pas à lui seul un critère discriminant. Par contre la collecte de type aspiration ('pumping') des données qui seront contrôlées puis injectées dans un entrepôt de données est un élément fondateur d'un système décisionnel. La donnée sera intégrée puis historisée dans un processus qui fournira de la 'traçabilité' sur la donnée. Un vrai entrepôt doit permettre de suivre tout le cycle de vie de la donnée.
Cette notion de 'pumping' s'oppose à la notion de 'mashup' qui elle, n'intègre pas la fonction de prise en charge de la donnée. Dans le décisionnel, la granularité n'est pas la même que dans une application de gestion. Souvent le directeur financier va manipuler des agrégats en Keuros. Dans le même ordre d'idée, le processus d'intégration dans l'entrepôt sera tolérant sur la présence ou le format d'une donnée, alors que pour une application de gestion, la donnée doit etre exactement calibrée et présente.


Le caractère multidimensionnel.
Le cube avec un système OLAP est l'élément clé du décisionnel. Un tel système offre la possibilité de définir des axes d'analyse, à commencer par l'axe temporel
A partir de là, l'analyste pourra explorer son cube dans les dimensions souhaitées.
Un requêteur 'universel' viendra compléter la boite à outil mise à disposition.
C'est l'utilisateur final qui choisit la requête et son domaine et non plus le concepteur de l'application. Tel un peintre qui mélange ses couleurs à partir d'un nuancier: l'entrepôt de données.

Les restitutions.

L'utilisateur final doit pouvoir choisir son format de restitution à partir d'une liste de composant . Cela peut aller du radar en passant par l'histogramme en 3D jusqu'au simple fichier csv.

Un tableau de bord aussi sophistiqué qu'il soit n'est pas le propre d'une application décisionnelle. L'utilisateur doit pouvoir choisir ses indicateurs KPI, le format d'affichage etc.
Une application de statistiques ne relève pas non plus forcement du décisionnel, elle peut etre 'immunable' sans interaction possible.

Les simulations.
Enfin, la simulation est une fonction importante demandée par les décideurs. Comment va évoluer le marché ? , quelles seront les projections dans un an ou deux ?. Il faut pour répondre à ces questions, embarquer dans le système toutes une panoplie d'outil de modélisation mathématiques.


Ainsi le critère de classification repose en grande partie sur le type de l'utilisateur final. Dans le cas du décisionnel ,c'est l'utilisateur qui compose son application, il y aura autant de forme d'application que d'utilisateur. Le nombre d'utilisateur ayant les compétences pour tirer parti d'un système décisionnel est forcement limité.

En conclusion: Les éditeurs du décisionnel cherchent à prendre des parts de marché aux éditeurs traditionnels et réciproquement : voir l'exemple de SAP qui propose du décisionnel dans son ERP. Le parc d'application décisionnelle doit normalement être marginal par rapport à celui des applications de gestion.

Rails: contourner un problème par l'utilisation de la méthode send.

Dans le cadre d'utilisation d'association de type 'belongs_to' avec clés étrangères absentes.


Comment par simple baquette magique remplacer une dizaine de blocs identiques par un petit bloc de 4 lignes ?














Voici l'exposé du problème :j'ai une table principale Projet qui utilise plusieurs clés étrangères pour afficher des libellés .

class Projet < ActiveRecord::Base
belongs_to :moe
belongs_to :moa
belongs_to :domaine
belongs_to :techno
belongs_to :filiere
belongs_to :didev
belongs_to :diprod

Parfois, la clé étrangère n'est pas renseignée et cela provoque une erreur dans l'affichage de l'objet principal. Ce cas arrive pour ma part, principalement dans deux situations:

• En phase de développement: je n'ai pas encore finalisé les écrans permettant de rattacher la table principale avec ses tables associées (à faire sous forme de liste déroulantes)

• Par choix fonctionnel, la valeur ne doit etre servie. Dans ce cas, il est toujours possible d'ajouter une entrée factice dans la table (non satisfaisant)

La solution 'brute' consiste à tester avant d'afficher la validité de la clé étrangère , et de répéter ce test tout le long de la vue.
Dans l'illustration suivante, je montre comment factoriser son code :
(cliquez sur l'image pour agrandir)


L'astuce consiste à remplacer l'appel d'une méthode par l'envoi d'un message à la methode 'send' de l'objet.

Dans cet exemple, j'appelle une fonction avec trois paramètres:
L'objet (projet)
Le nom de la classe decrivant les libellés (nom de la table au singulier)
L'attribut à afficher
Je procède à un appel imbriqué de méthode.





Ces trois formes d'appel produisent le même résultat :

• mon_projet.methode
• mon_projet.send('methode')
• mon_projet.send(:methode)

Dans le cas présent, en raison de l'utilisation d'une clé étrangère je suis obligé de passer par une syntaxe imbriquée:
mon_projet.send('objet_libelle').send('attribut_a_afficher')

Et en bonus, comment afficher une liste déroulante à partir d'un table libellé ?

Par une simple ligne :
<%= select(:projet, "domaine_id", Domaine.find(:all).collect {|p| [ p.libelle, p.id ] }, :include_blank => true) %>

Good hacking!

une bonne idée pour une table de jardin

Les modèles gros contre les maigres

Le titre est racoleur comme cette illustration que j'ai volontairement floutée.
(L'originale est disponible sur google image)

Rails est un framework MVC : modele/view/controleur

La philosophie de Rails est aussi dans la re-factorisation du code, de manière à éviter d'avoir des gros contrôleurs. Ce défaut est source de toutes les difficultés : maintenance , réutilisation du code et évolution de l'application.

J'illustre mon propos par un exemple de projet qui gère un portefeuille applicatif. Ces applications sont de différentes technologies ,et on doit pouvoir filtre les applications sur leur type de technologie :

Dans une première version , jamais mis en dur dans le contrôleur les options de filtre possible.

Après modifications , j'arrive à :
Un modèle plus 'gros':


Ce modèle contient toute la logique de sélection (Select SQL)
Il ne faut pas hésiter à faire des méthodes 'find' taillées sur mesure.

Le contrôleur:


Le contrôleur est allégé pour ne contenir que la partie 'métier' du traitement. Dans cette solution , non seulement les tests 'en dur' ont disparus mais en plus l'ajout d'une nouvelle catégorie ne nécessitera aucune modification de code.

La vue est elle aussi simplifiée:

D'une manière générale, il faut éviter de mettre trop de traitement dans les vues. Cela rend l'application, très difficile à maintenir et le code inséré dans les vues est assez contraignant à écrire.

Où se trouve alors tout le traitement qui génère l'affichage de la console de bouton radio ? . Car malheureusement, il faut bien qu'a un moment donné une méthode prenne en charge :
a) Afficher toutes les options
b) Pré-selection de l'option 'cochée'.
Cette méthode va etre placée dans les 'helpers' de l'application qui prendra cette forme:


Je n'ai pas forcement le bon style d'écriture du code. Ici on fabrique le HTML utile pour les boutons radio.
Cette méthode n'est possible que parce ma liste des options était contenue dans une table.

En résumé : toujours re-factoriser son code : DRY : don't Repeat Yourself ou Duplication is Evil . Dans mon exemple la logique de la gestion des options est dans le helper et que dans lui. Le resultat donne un système qui evoluera sans modification à apporter au code.
En conclusion je me pose la question suivante : Pourquoi doit on re-factoriser dans les langages proceduraux et ne pas le faire dans les langages fonctionnels ?.