Ruby / JRuby - Ruby On Rails
ruby on rails                ruby


 

Contexte

Kantena a mené de nombreux projets de modernisation (patrimoines logiciels vers les environnements Objet et Web). Notre société a dû assumer des choix avec ses clients afin de « reskiller » ses consultants afin de répondre aux problématiques suivantes :

  • comment résorber une dette technique,
  • comment allier la simplicité d’un L4G avec les apports des architectures Web,
  • comment améliorer nos pratiques de développement ?

 

Pourquoi RUBY

Langage Ruby :

  • Est un langage de script / dynamique orienté objet,
  • L’environnement Java avec Jruby permet un accès simplifié à l’écosystème Java, mais aussi à l’environnement .Net (avec Iron-Ruby) et à SAP et ABAP avec Blue Ruby,
  • Regroupe le meilleur d’autres langages de script (Perl Python, ..) qui ne sont pas forcement objet,
  • Est moins foisonnant et complexe, donc plus simple à utiliser et plus facile à apprendre que Java,
  • Est très apprécié des équipes de développement,
  • Permet de respecter les principes KISS et DRY,
  • Est un langage libre développé en Open Source,
  • Est utilisable de l’iPhone (JRuby) au Mainframe.
 

Framework Rails :

  • Est très bien adapté aux développements de gestion,
  • Propose un découpage MVC, logique de client léger à interface dans un navigateur avec http simple ou Ajax ; cela peut aller jusqu’au client lourd type RDA (Ruby),
  • Utilise des conventions, et non des configurations.

 

Analyse stratégique de KANTENA

force & faiblesse

Exemples d’application

  • Projets et prototypes prévus en phases (versions),
  • Projets nouveaux à périmètre non stabilisé,
  • Développements moins coûteux qu’en Java (à qualité égal, gain significatif en temps de programmation),
  • Adapté à la DSI lorsqu’elle veut se rapprocher de la MOA,
  • Idéal dans le cas de migration / portage d’applications sur le Web,
  • Développement d’Add-on autour des applications Java existantes (c’est du « Java » sans Java),
  • Lorsque différentes applications doivent être implémentées sur une même JVM,
  • Lorsqu’il est stratégique de prévoir une maintenance évolutive (langage « expressif » : reprise des codes plus facile pour un tiers),
  • Alternative à coût maîtrisé à une externalisation (sous-traitance ou Offshore) de développement Java décidée pour cause de coûts trop élevés en interne ...