Lors de son excellente keynote à la RailsConf 09 "What killed Smalltalk could kill Ruby too", Robert Martin a souligné que Rails devait s'ouvrir à l'entreprise.
Il y a de nombreuses bonnes pratiques et conventions dans la communauté Ruby on Rails et je pense sincèrement qu'il s'agit du meilleur framework pour le développement web.
Mais peut-être est-il maintenant temps de s'ouvrir au monde extérieur. Nos pratiques ne sont pas respectées partout. D'autres personnes ont des besoins et visions différentes mais ce n'est pas pour cela que Ruby on Rails ne doit pas leur convenir.

Un exemple simple est lié aux clés primaires dans une base de données. Par défaut, les tables d'une application Rails possèdent un champ ID auto incrémenté agissant comme une clé primaire.
Dans sa version de base, Rails n'inclut aucun support pour les clés primaires composées. Un plugin permet d'ajouter cette fonctionnalité mais elle ne fait pas partie intégrante de Rails.
Si vous demandez pourquoi, il y a de fortes chances qu'on vous réponde que créer des clés primaires composées n'est pas une bonne pratique.
Ces clés primaires sont pourtant omni-présentes dans le milieu professionnel. Milieu peuplé par des bases de données Oracle qui ne respectent aucune de nos conventions. Et celles-ci ne vont certainement pas changer pour s'adapter à un nouveau framework.

C'est à Ruby on Rails à s'adapter à ce type de besoins si il souhaite s'imposer en entreprise.
Et heureusement, Rails est de plus en plus "enterprise ready" version après version.

Je suis récemment parvenu à intégrer Rails dans une grosse entreprise qui n'utilisait jusqu'alors que le Java. L'objectif de cet article est de partager les difficultés que j'ai rencontrées. Peut-être vous aideront-elles à faire de même et au final, à utiliser Rails au quotidien. Quel bonheur!

Le devéloppement d'une application Rails sur un schéma Oracle existant était ma principale crainte. J'avais toujours développé avec Rails des applications où le schéma évoluait au fur et à mesure et respectait donc les conventions d'ActiveRecord.
Après quelques recherches je me suis cependant très vite rendu compte qu'il était très facile de configurer votre modèle. Vous pouvez découvrir comment procéder en lisant un de mes articles consacrés à ce sujet. Il est également très facile d'invoquer des procédures stockées et autre joyeusetés de ce genre.

Le terme "langage de script" fait peur, principalement l'idée de lenteur qui leur est automatiquement associée.
N'hésitez pas à rassurer vos clients en leur montrant que de nombreux sites utilisent Rails, qu'ils ont un traffic important et qu'ils n'ont pas de problème de performances! Voici une liste pour vous aider.
Un autre argument à mettre en évidence est JRuby on Rails qui me semble être une excellente solution pour faciliter l'intégration de Rails en entreprise (voir ci-dessous). Les clients sont rassurés par le fait de savoir que Rails tourne sur la JVM et qu'ils ne vont donc pas totalement quitter le monde J2EE.

Autre problème majeur, les connaissances en Ruby et en Rails. Si vous proposez un nouveau framework Java, il y a de fortes chances qu'il soit accepté facilement. Tous les développeurs de l'entreprise connaissent Java.
Ruby en revanche ne leur dit rien et cela signifie donc qu'ils vont perdre plus de temps en apprentissage. Il ne faut également pas perdre de vue que beaucoup de développeurs ne sont pas passionnés par leur travail et n'ont pas envie d'apprendre une nouvelle technologie.
S'ajoute à cela le problème du recrutement. Il n'est déjà pas facile de trouver un bon développeur Java alors que dire d'un développeur Ruby!

J'ai personnellement pu contrecarrer ces craintes en signalant que Ruby et Rails sont très faciles à apprendre. Préparez une formation attrayante pendant laquelle vous partagerez votre engouement et votre passion pour ce framework. J'ai donné de telles formations à mes collègues qui ont pu très rapidement se rendre compte des avantages de Rails et surtout, que c'est un framework facile à prendre en main. J'ai alors très rapidement trouvé des alliés et je n'étais plus le seul à venter les mérites de Rails!
J'ai très souvent entendu des "c'est génial!", lorsque mes collègues développaient leurs premières applications de test et ils y ont visiblement pris beaucoup de plaisir.
Il m'est également arrivé de comparer des extraits de code Java et Ruby devant un client afin qu'il s'aperçoive par lui-même que la syntaxe de Ruby est claire et facile et que donc, l'application résultante sera plus facile à maintenir.

Un autre problème est le développement Ruby sur Windows. Je travaille personnellement sur Mac mais tous les autres développeurs sont sur Windows.
J'ai bien essayé Aptana et Netbeans mais ce n'est vraiment pas agréable à utiliser. Heureusement, RubyMine a désormais pointé le bout de son nez. C'est une excellente solution tout à fait abordable pour une entreprise.

Un gros problème est que Windows est même utilisé sur les serveurs de production. Et nous savons tous que le déploiement d'applications Rails sur Windows est douloureux.
Les outils pour gérer et monitorer les applications sont également peu nombreux et considérés comme des jouets comparés aux nombreux outils disponibles dans le monde Java.
Raison pour laquelle je suis actuellement en train d'investiger sur JRuby. L'utilitaire warbler permet de créer un war depuis une application Rails et donc de la déployer très facilement sur un serveur d'application Java EE. Je parlerai de ce sujet dans un de mes prochains articles.

Qui dit entreprise et Java dit également très souvent portal. Et une question qui se pose naturellement est la suivante : "Est-il possible d'intégrer une application Rails dans une portlet?". Je n'ai pas encore essayé personnellement mais j'ai lu que c'était réalisable.

Le framework Java utilisé jusqu'à maintenant par notre client (Oracle ADF) était basé sur les JSF et les utilisateurs étaient donc habitués à utiliser des composants riches, par exemple une table avec le tri et la pagination.
J'ai pour cela développé un plugin Rails permettant de générer très simplement des datagrids jQuery possédant toutes les fonctionnalités requises (ajax, tri, pagination, filtres, insertion, suppression, ...).

Enfin, je vais terminer en donnant quelques arguments qui ont bien fonctionné pour moi.

RSpec a été très apprécié! J'ai simulé en live un développeur qui faisait échouer un test et la combinaison autotest-growl a alors eu tout son effet!
La génération des specs au format "documentation" a également eu le don de charmer l'audience.
Je n'utilisais pas encore Cucumber à l'époque mais je suis certain que lui aussi peut faire une forte impression.

J'ai également créé un template de construction pour les nouveaux projets. Celui-ci contient le layout par défaut utilisé par la société ainsi que d'autres fonctionnalités communes. Le fait de pouvoir générer une application déjà évoluée en une seule commande a fait bonne impression.

N'hésitez pas à partager vos expériences... je serai heureux de les lire!