5 raisons qui font de Ruby un bon choix en 2020

Introduction

Chaque tendance, chaque technologie et même chaque langage de programmation a son pic de popularité qui, un jour ou l’autre, diminuera un peu ou beaucoup (pour ceux qui se souviennent de Google+ ). Si l’on fait des recherches concernant « l’état du langage Ruby » sur Google, nous obtiendrons très probablement de nombreux résultats concernant la baisse de popularité de Ruby ou sa mort présumée.

Selon moi, la vérité est que Ruby se porte bien et reste une bonne technologie à choisir en 2020. Voici 5 raisons qui me font penser ça.

1. Dans le top GitHub !

Il est très peu probable que la santé de notre Ruby soit en danger : il figure toujours parmi les langages de programmation principaux de GitHub en 2019. De plus, de grandes entreprises comme GitHub ou Airbnb utilisent continuellement Ruby (on Rails).

Depuis quelques mois, le géant du cloud computing Amazon a ajouté Ruby à son service de serverless computing (AWS Lambda) au même titre que Java, C#, Python et Node.js, ce qui montre la stabilité du langage. Ruby a peut-être ralenti, mais il est encore en grande forme ! Et ce, notamment grâce à la grande quantité de projets existants qui doivent être maintenus et étendus.

2. La communauté

À l’heure où j’écris ces lignes, Ruby on Rails ne compte pas loin de 4’000 contributeurs sur GitHub. Les mises à jour fréquentes et les nouvelles gems (librairie Ruby) créées par les développeurs de la communauté garantissent que les applications basées sur le framework puissent être développées et livrées plus facilement et plus rapidement. La communauté très active partage régulièrement ses problèmes, bugs et expériences. Avec plus de 300’000 posts sur Stackoverflow, il est peu probable que vous ayez du mal à trouver une solution à un problème que vous rencontrez.

De plus, Ruby est comme un bon vin : il a mûri avec le temps et sa documentation est devenue très complète et lisible tant par les novices que par les développeurs confirmés – un excellent point de départ pour les nouveaux arrivants.

Ruby, ce n’est pas seulement Rails. Il existe d’autres frameworks qui sont très adaptés à d’autres besoins. Des solutions plus légères comme Sinatra ou Hanami et même des frameworks pour des applications basées sur la gestion d’événements gagnent en popularité et améliorent ce que Ruby a à nous offrir.

3. Une évolution constante

Avec des mises à jour en moyenne deux fois par an, les créateurs de Ruby s’assurent que la langue ne meure pas et qu’elle soit en constante évolution. Malgré les problématiques de performance connues, qui ne disparaîtront probablement pas de sitôt en raison de l’architecture de base de Ruby (en particulier sa nature dynamique), la sortie de Ruby 3 en 2020 devrait introduire plusieurs améliorations significatives qui rendront Ruby beaucoup, beaucoup plus performant.

4. Efficace pour les start-ups et le prototypage

Grâce à sa syntaxe simple et intuitive, qui se traduit par une productivité beaucoup plus élevée que d’autres langages, Ruby convient parfaitement aux start-ups ou à toute entreprise qui souhaite fournir (et étendre) des produits logiciels rapidement. Un développement plus rapide se traduit par une mise sur le marché plus rapide et donc un impact économique positif ! Avec cette approche, plus d’argent pourra être investi dans le développement de fonctionnalités supplémentaires, le marketing, etc.

D’autre part, les projets d’envergure peuvent bénéficier de RoR (Ruby on Rails) en l’utilisant comme un outil de prototypage ou un moyen efficace de fournir des solutions de validation de concept. Comme il est relativement facile et bon marché de construire et d’étendre des applications avec Ruby, c’est aussi une excellente option pour construire des outils internes/back-end, où la performance n’est pas une priorité absolue.

Il est également courant d’utiliser Ruby pour des applications de grande ampleur et de haute performance. Cependant, cela nécessite généralement des ingénieurs qui savent comment créer des applications performantes en Ruby, car la vitesse n’est pas intrinsèquement liée à ce langage. De plus, cela peut nécessiter une certaine mise à l’échelle horizontale.

5. Des normes bien en place

Ruby est un langage de programmation mature et une technologie stable qui ne se contente pas d’être « à la mode ». La flexibilité du langage permet aux développeurs d’écrire du mauvais code, et c’est même assez facile ! Il est possible d’obtenir le même résultat de plusieurs façons (on peut même être très créatif ). D’autre part, le langage lui-même permet d’écrire un code beau et très lisible — ce qui est très encouragé par un ensemble de normes et de bonnes pratiques bien établies.

Un tel code, s’il est écrit correctement, peut être facilement compris et maintenu par des développeurs qui ne sont pas à l’origine du code : ce qui améliore encore la stabilité et la maintenabilité de l’ensemble de la solution.

Bonus : Le bonheur des développeurs

Car un top 5 sans un point bonus n’est pas un vrai top 5 !

La vaste quantité de librairies et de ressources, une communauté active et bienveillante, des bonnes pratiques bien établies, une belle syntaxe lisible… Tout cela fait de Ruby un langage de programmation avec lequel il est agréable de travailler : un langage orienté sur le bonheur des développeurs !

Dans la plupart des cas, les développeurs heureux offrent un meilleur rapport qualité-prix à leurs clients. S’il existe d’autres langages qui tentent d’imiter les meilleurs aspects de Ruby (par exemple Crystal), ce sont des technologies encore immatures qui doivent faire leurs preuves dans les environnements de production. Croisons les doigts pour leur succès !

Conclusion

Même en 2020, Ruby reste un excellent choix pour vos besoins de développement ! Il ne fait aucun doute que c’est un langage toujours pertinent et qu’il attire toujours de nouveaux adeptes et développeurs. Par ailleurs, il existe des écoles de code comme Le Wagon qui se base sur la simplicité et la lisibilité de Ruby pour former des développeurs web en un temps record de 9 semaines !

Enfin, il faut garder à l’esprit qu’il n’y a pas de « mauvais » langage de programmation en soi, il n’y a que des langages mal choisis pour des cas d’utilisation particuliers. Donc, si vous pensez que Ruby vous convient, n’hésitez pas, il est toujours parmi les technologies les plus populaires.

Vous souhaitez utiliser Ruby on Rails en 2020 ? Contactez-nous !

Gestion de projets dans une petite équipe

Avant de rentrer dans le vif du sujet, commençons par poser le contexte dans lequel cet article a été rédigé. Vous gérez l’attribution de tâches dans une équipe informatique de 5 personnes. Votre équipe réalise des projets de développement de site web, d’application métier ou mobile, de création de contenu multimédia ou encore de réalisation graphique. Les projets sont de taille variable, ils varient entre quelques semaines jusqu’à plusieurs mois, voire des années.

Ce postulat étant défini la question qui se pose est : comment aborder efficacement le planning de chacun, autrement dit, comment gérer les ressources afin que les projets soient livrés en temps et en heures, veiller à ce que les ressources ne soient pas en surmenage ou en manque de travail. En bref que le projet se déroule bien et que les membres de l’équipe soient satisfaits de leurs conditions de travail.

Si l’on attribue des tâches aux personnes sans vraiment définir une stratégie au préalable, il y a de fortes chances de se retrouver avec un cas tel que décrit dans le schéma ci-dessous.

Figure 1 Exemple d’une mauvaise répartition de projet au sein d’une petite équipe

Voici quelques observations sur le schéma présenté :

  • Certaines personnes sont clairement à la tête de certains projets alors que d’autres errent entre différents projets.
  • Certaines personnes ne participent pas du tout à certains projets, ce qui limite les connaissances métier à un nombre limité de personne.
  • On constate que la mise en route tardive du projet 3 a provoqué l’arrêt de tous les autres projets afin de tenir les délais.
  • L’exemple montré est simple, mais nous constatons déjà que cela peut rapidement être ingérable si le nombre de ressources et/ou de projet venait à augmenter.
  • On constate que le projet 1 a essentiellement concerné une seule personne, si cette dernière venait à être malade ou à quitter l’équipe, aucune autre ressource ne serait à même de reprendre le travail.
  • Ce genre de planification encourage les membres de l’équipe à travailler de manière individuelle et non pas en équipe.

Sur la base de ces observations, voici les principaux problèmes qui surgissent :

  • Égalité de traitement entre les membres de l’équipe certains membres ont le « luxe » de travailler sur un seul projet alors que certains changent régulièrement de contexte.
  • Pas ou peu d’esprit d’équipe, éventuellement la création de binômes.
  • La connaissance des produits est limitée à une ou deux personnes et non pas à l’ensemble de l’équipe.
  • Certaines personnes sont surmenées alors que d’autres sont en manque de travail.
  • Il est difficile de savoir qui travaille sur quoi et d’avoir une vision globale de chaque projet.

Passons en revue les différentes solutions qui s’offrent à vous

1. Chaque personne travaille sur un projet spécifique

Dans cette option, tous les projets avancent parallèlement avec une ressource attribuée à chaque projet. Il sera possible de présenter régulièrement une avancée au client, en contrepartie la date de livraison sera longue pour chaque projet. Ce qui implique que pour chaque projet il faut gérer en parallèle les éléments suivants :

  • La livraison de produits intermédiaires
  • Facturation
  • Séance client
  • La mise en production finale

D’autre part, les ressources travaillent de manière individuelle, il n’y a donc pas d’esprit d’équipe ni de critiques/propositions d’améliorations sur le travail des autres. Finalement, la personne qui aura réalisé le projet sera experte dans son projet, elle sera donc plus productive et décèlera rapidement les causes des bugs, en revanche si cette même personne tombait malade ou venait à quitter votre équipe, il faudra qu’une autre personne acquière toutes ses connaissances.

  • Délais de livraison maximums pour chaque projet
  • Pas de travail collaboratif, pas d’esprit d’équipe
  • Une seule personne possède tout le savoir du projet
  • + Pas de perte de temps pour les changements de contexte
  • + Avancée régulière sur le projet, planification de versions simplifiée

2. Un sprint par projet, alternance de projet

Cette seconde alternative propose de traiter un projet différent dans chaque sprint. Le point fort de cette méthode est que la connaissance du projet est répartie sur l’ensemble de l’équipe. Vous ne dépendrez pas d’une seule personne pour la réalisation d’un projet, n’importe quel membre de l’équipe aura les connaissances sur le fonctionnement de vos produits. De plus, cette stratégie demande une bonne cohésion d’équipe et donc une ambiance de travail agréable. Le fait que tout le monde soit concentré sur un même produit permet d’obtenir plus d’idées, d’avis, de points de vue sur le produit, ce qui résulte sur un résultat de meilleure qualité.

Cependant, le temps entre chaque sprint peut être trop long et donc il y aura toujours un temps de mise en route pour se replonger dans le projet, c’est donc du temps qui est perdu. Ensuite avec une forte charge de travail de manière ponctuelle il est difficile de définir un plan de délivrables intermédiaires. Finalement, au même titre que l’option numéro 1 tous les projets avanceront en parallèle et auront des dates de livraison qui seront temporellement proches, ce qui implique toutes les problématiques décrites précédemment.

  • Temps entre 2 sprints sur le même projet trop long, perte de temps pour se remettre dans le contexte
  • Difficile de planifier les versions de produit
  • Livraison retardée pour tous les produits
  • + La connaissance du projet est répartie sur toute l’équipe
  • + Esprit d’équipe

3. Tous les projets dans un sprint

Cette troisième possibilité est à l’opposé de ce qui est présenté dans la 1ère option. C’est-à-dire qu’au sein du même sprint on va avancer sur tous les projets. Un peu comme si chaque fois qu’une personne termine une tâche elle en piochait une autre aléatoirement dans le backlog. Le bon point de cette méthode est que tous les projets avancent en même temps il est donc possible de régulièrement présenter les avancées aux clients, malheureusement si la quantité de projets devient trop importante le travail accompli chaque semaine sur chaque projet est minime.

D’un point de vue de la spécification, vous devrez être irréprochable, étant donné qu’il faudra fractionner les projets de sorte qu’ils s’adaptent à la taille des sprints, les tâches seront beaucoup plus courtes et donc plus précises. Cela demande donc du travail en amont pour planifier le travail des ressources. Comme au point précédent, dans ce cas de figure la connaissance des projets sera répartie sur l’ensemble des membres de l’équipe. Pour clôturer ce chapitre, selon moi le plus grand défaut que vous allez rencontrer avec cette méthode est que les membres de votre équipe vont devoir alterner d’un projet à l’autre plusieurs fois durant le sprint et donc à chaque nouvelle tâche, il y aura un temps de mise en contexte qui peut faire diminuer la productivité du groupe.

  • Nécessite beaucoup de détails dans la spécification des tâches
  • Risque de confusion entre les projets
  • Avancée dans les différents projets minimes
  • + Avancée régulière sur tous les projets
  • + Esprit d’équipe
  • + L’ensemble de l’équipe a les connaissances sur les différents projets

4. Sérialiser les projets, un projet à la fois

La dernière approche est selon moi la plus efficace, d’un point de vue de la gestion de ressources, il s’agit de traiter les projets les uns après les autres. Votre équipe s’investit entièrement dans un projet jusqu’à ce qu’il soit terminé, puis passe au projet suivant. On n’en retrouve pas les différents défauts mentionnés dans les alternatives précédentes, c’est-à-dire la perte de temps due au changement de contexte, la connaissance du produit limité à une partie de l’équipe, temps de livraison total long, etc. Une des conditions pour que le développement de vos solutions se déroule sans accroc est une bonne cohésion au sein de l’équipe, les conflits peuvent parasiter la productivité.

Malheureusement, cette solution n’est pas toujours aisée à mettre en place dans un environnement concret. En effet, dans la réalité il se peut que vous attendiez des informations d’un chef de produit externe qui pourrait bloquer votre équipe.

  • Requiert une bonne cohésion d’équipe
  • Difficilement applicable concrètement
  • + Pas de perte de temps dû au changement de contexte
  • + Connaissance répartie sur l’ensemble de l’équipe
  • + Les projets sont livrés rapidement

Conclusion

Chacune des solutions citées a ses avantages et ses inconvénients, c’est à vous de définir laquelle est la plus adaptée à votre domaine d’activité et aux compétences de votre équipe. Évidemment dans la réalité rien n’est jamais soit blanc soit noir, il faut savoir trouver le juste milieu. En plus de ça, il y a toujours des évènements externes qui viendront perturber le déroulement de vos journées. Dans le cas où vous auriez des approches différentes, ou si vous avez tenté d’appliquer une des méthodes présentées c’est avec plaisir que nous accueillerons vos expériences dans les commentaires.

Le Régional – Ils créent une appli pour gérer vos locations immobilières

L’immobilier, c’est sont truc. Julian Bruno a travaillé plusieurs années en gérance dans différents secteurs, ce qui lui a donné une vision claire des difficultés que rencontrent les petits propriétaires lorsqu’ils louent un bien. Un tour sur Internet lui a permis de..