Simplifier le processus

Dans Publication économique d’un projet en démarrage, il a été question d’optimiser la quantité des ressources sur le serveur à moindre coût. Pour y arriver, ActivityMapper, un projet en ASP.NET MVC a été déployé sur un serveur Rackspace Cloud pour y être exécuté avec le runtime de Mono.

Environnement de travail et d’exécution hybrides

Le processus de prendre un projet existant et de l’amener en production avec Mono implique de faire attention à ce qu’on utilise. Jusqu’à récemment, le projet était développé dans Visual Studio 2010. Ça fonctionnait bien, si on tient bien compte du fait que les ressources sur une machine Windows en développement sont différentes d’un Ubuntu en production.

La base du logiciel en développement étant de faire des accès SQL et utiliser du Javascript pour afficher les résultat ne posait pas de problème. Les déploiements, l’envoi de courriels ainsi que l’authentification avec OpenID par contre, des processus qui semblent anodin, ont été des sources de maux de tête qui ont relancé l’idée de faire un pas en arrière pour en faire deux en avant.

La suite logique du mouvement vers l’open source déjà établi était donc de tester MonoDevelop. C’est un outil de développement qui s’inspire beaucoup de Visual Studio, excepté qu’il est bâti avec Mono et est fait pour compiler du Mono. Tout ça semblait bien prometteur. On voit que c’est un bon outil pour des nouveaux projets, ce qui n’était pas le cas ici. La migration du code existant fait dans Visual Studio contenait de éléments incompatibles avec MonoDevelop, notemment au niveau du web.config, qui était encore en .NET 3.5 un monstre que personne ne semble maîtriser totalement.

Découverte de Ruby on Rails

Après de nombreuses heures investies ayant laissé derrière plus de frustration que de succès, il fallait au moins considérer autre chose avant de désespérer. Certains amis programmeurs que je respecte beaucoup, notemment Pierre-Luc Simard et Daniel Lepage m’ont fréquemment vanté les mérites de Ruby on Rails, donnant ainsi de la crédibilité à ce framework. J’ai longtemps repoussé du revers de la main tout ce qui était différent de .NET, dans l’objectif d’être excellent avec un framework plutôt que d’être simplement bon dans plusieurs. Le moment où l’ouverture d’esprit étant désormais devenue l’alternative évidente, j’ai entrepris de mettre le développement de côté un instant, le temps d’évaluer cet outil.

À ma grande surprise, faire du Ruby on Rails n’est pas très différent de du ASP.NET MVC puisque Rails est aussi du MVC. La différence la plus marquante est l’usage du langage Ruby plutôt que C#, bien évidemment. Ensuite, l’archictecture du framework web, au lieu d’être laissé au loisir de l’architecte en ASP.NET est très rigide. Beaucoup de fichiers ont leur place bien spécifique. Le résultat est qu’après une petite lecture des guides et un exemple plutôt simpliste, je me suis retrouvé à faire un mandat rémunéré basé là-dessus. Ce projet est actuellement en production et a été livré dans les temps malgré le peu de connaissances que j’avais au moment de l’entreprendre.

L’adaptation à un projet existant est vraiment facile à cause de la rigidité de l’architecture. J’ai toujours été un fervent défenseur des règles de programmation strictes à l’intérieur d’une entreprise pour aider un programmer à passer d’un projet à l’autre. On réalise vite quand on apprend Ruby on Rails qu’il est basé sur ce principe, mais au niveau mondial. C’est donc très facile de comprendre la base de n’importe quel site.

Composantes faciles d’accès et gratuites

Un autre point fort de Ruby on Rails sont les gems. Ils sont en fait une série de librairies emballées de telle manière qu’on peut les intégrer au projet avec une seule ligne de commande, incluant le téléchargement et l’installation. Il en existe justement pour OpenID et pour les courriels, ce qui met un terme définitif aux irritants vécus en Mono.

Les déploiements sont aussi d’une simplicité notoire grâce à Capistrano. C’est très facile à configurer, la plupart du temps en moins d’une heure par un débutant. Ensuite, s’agit d’une ligne de commande à taper pour mettre la nouvelle version du site web en ligne.

Libérer le programmeur de son poste de travail

En ce qui concerne l’édition du texte, nul n’est besoin d’avoir un environnement complexe de développement d’installé. La plupart des aides au développement sont disponibles en mode ligne de commande. J’ai donc personnellement opté pour vim comme éditeur de texte. Il est un peu complexe à maîtriser au début, mais son apprentissage peut être très payant en terme de productivité à long terme. De plus, comme il fonctionne entèrement en mode texte dans un environnement de ligne de commande, il est utilisable en SSH avec syntaxe colorée.

Ce nouveau mode de développement supprime le lien entre l’ordinateur de programmeur. Il est possible d’être pratiquement aussi productif avec un ordinateur public dans un café internet qu’à la maison. S’agit de télécharger PuTTY qui ne demande aucune installation avant usage et c’est parti. Le travail se fait en deux canaux… le premier pour l’édition du texte et le second via le web directement pour voir le résultat. Du moment que le site web de développement est accessible de l’extérieur sur la machine de développement toutes les conditions sont réunies pour pouvoir faire du développement à distance. L’édition d’une ligne de code en ruby applique la modification directement sur le site web parce que ruby est un langage interprété et non compilé.

Conclusion

La version actuelle de ActivityMapper manque beaucoup de fini en production et le restera pour quelques temps. La prochaine version ne contiendra plus aucune composante de Microsoft. Elle sera basée sur Ruby on Rails, avec une base de données PostgreSQL et roulera sous Apache ou peut-être Lighttpd. Le résultat donne du code 100% natif et portable. Il sera produit avec outils gratuits et distribués. Son exécution se fera dans le cloud sous Linux.