Confessions d’un Javaiste repenti

Cela fait maintenant 6 ans que je fais du Java de manière professionnelle, que je collectionne les jars et empile les frameworks tel un jeu de légo. Mais voilà c’est terminé ! Depuis 6 mois je fais du Ruby on Rails (aka Rails), aussi bien sur mes projets persos que professionnels … laissez-moi vous expliquer pourquoi.

Ruby On Rails, un framework web

Lorsque l’on parle de Rails, on pense le plus souvent à ses caractéristiques totalement orientées vers la productivité du développeur :

  • un paradigme convention over configuration, reléguant les longs fichiers de configuration XML à la préhistoire
  • un langage interprété facilitant le rechargement de code à chaud et permettant ainsi de tester les modifications de son code au plus vite
  • l’utilisation d’un langage dynamique avec toutes les fonctionnalités modernes permettant (entre autre) de très facilement créer des méthodes à la volée ou permettant de manipuler les collections avec beaucoup de facilité
#Exemple de manipulation de collection avec une closure
print ["google", "yahoo", "bing"].map{|host| "http://www.#{host}.com" }
> ["http://www.google.com", "http://www.yahoo.com", "http://www.bing.com"]

Ces caractéristiques ont sans aucun doute marqué le monde du développement, mais elles ont désormais été intégrées par de nombreux langages. Ainsi, Spring ou JEE sont profondément emprunts de convention over configuration et de don’t repeat yourself permettant d’alléger les fastidieux fichiers de configuration XML. Les langages JVM de nouvelle génération (dynamiques ou non) comme Groovy ou Scala sont désormais matures. Et pour finir, l’outil JRebel propose une solution efficace au problème de « hot deploy » en Java.  Ces 3 points ne justifient donc pas en eux même de privilégier Rails à une stack Java.

Mais ne nous méprenons pas, la principale force de Rails est d’être un framework web ; en effet, point d’embarqué ou de client lourd en Rails. Mais cette spécialisation, qui correspond malgré tout à 95% de mon utilisation de Java en entreprise, est réellement un atout. En parlant de Java j’ai maintenant l’image d’un tank : ça fait tout, ça finit par passer partout, mais pas forcément de la plus efficace et la plus élégante des manières.

Le reste de cet article sera donc consacré à opposer Rails à Java en tant que frameworks web.

Mais au fait, Java peut il concourir dans la catégorie framework web ? Oui et non : Java n’est pas un framework web en tant que tel et l’on considérera en fait Java comme une pile de frameworks. On peut aussi bien utiliser la pile Java officielle (JEE), une pile alternative (comme Spring ou JBoss Seam) ou encore un assemblage à façon des nombreux frameworks existants.

Et en fin de compte, cette variété de frameworks nuit à Java : elle apporte beaucoup de complexité, aussi bien dans le choix des briques que dans leur assemblage. Ainsi la communauté Java s’est longtemps consacré à simplifier l’intégration entre les frameworks et entre les couches d’une application (l’IOC n’a jamais été aussi simple et peu verbeux). Cet objectif est aujourd’hui atteint et la pile standard Java est enfin devenue aussi légère à utiliser qu’elle devrait l’être.

Mais ceci s’est fait au détriment de ses fonctionnalités ! On s’estime aujourd’hui heureux en Java lorsque le framework que l’on utilise nous permet de mettre en oeuvre simplement le pattern MVC, de binder des objets sur des composants graphiques, de faire de la validation et éventuellement de faire un peu d’Ajax. C’est bien, mais c’est le b.a.-ba du web.

Si j’utilise aujourd’hui Rails, c’est parce que ce framework est définitivement plus abouti et plus riche en terme de fonctionnalités web. Rails (contrairement à Java) est le fruit de centaines de contributeurs oeuvrant tous dans le même sens : faire de ce framework le plus productif pour réaliser des applications web. Voici quelques exemples de fonctionnalités natives en Rails, et à mon sens vitales pour faire une application web en 2010 :

  • Mapping REST et contrôle fin des URLS générées
  • Exposition de services web en JSON ou XML
  • #controlleur MVC pour retourner un objet sérialisé en JSON
    class BooksController < ApplicationController   def show     render :json => Book.find_by_id(params[:id])
      end
    end
  • Gestion intégrée d’un memcache ou encore gestion du cache pour des fragments de page
  • Compression automatique des ressources web
  • Accès transparent à la base de donnée (ie. pas besoin d’écrire de code SQL ou apparenté pour une bête recherche en base)
  • class User < ActiveRecord::Base
      #la classe est vide, les attributs de la classe sont induits depuis le schema de la base : schema.rb
    end
     #exemple de méthode dynamique : Rails interprète dynamiquement le nom de la méthode pour exécuter le code SQL correspondant
    User.find_by_name

Il y a aussi une gem pour ça !

Et ce n’est pas parce que Rails bénéficie d’une direction claire et contrôlée qu’il n’existe pas de communauté. La contribution externe est très riche, et les frameworks pululent sur github. Voici quelques exemples de gem (i.e. librairie Ruby) absolument bluffantes :

  • devise vous aide à gérer tous les aspects sécurité. Pas seulement le processus d’authentification, mais aussi toute l’ihm nécessaire à enregistrer un nouvel utilisateur, changer son mot de passe ou encore confirmer la création de son compte. Devise est extensible et s’intègre particulièrement bien à openid ou oauth (pour utiliser Facebook ou Twitter en SSO par exemple)
  • formtastic simplifie drastiquement l’écriture de vos formulaires en poussant au plus loin le paradigme « convention over configuration ».
  • si vous trouvez que le HTML est verbeux, pas vraiment DRY et finalement peu maintenable, la gem HAML est faite pour vous. Elle a pour vocations à faire de vos pages web de véritables Haïku ;-)
  • pour finir typus ou admin_data vous aident à générer un back-office d’administration en deux coups de cuillère à pot.

Il y a bien entendu le risque de retomber dans une situation similaire à Java ou l’on se retrouve à assembler des stacks de gems totalement hétérogènes d’un projet à l’autre avec un surcoût d’intégration important. Mais Rails s’en sort mieux sur ce point car d’une part la « colonne vertébrale » d’un projet Rails est standard alors que ce n’est pas le cas en Java (où l’on peut être basiquement en  JEE, Spring ou Seam), et d’autre part les meilleurs innovations sont régulièrement injectées dans le coeur de Rails (tandis que la standardisation d’un Hibernate en JPA reste une situation exceptionnelle)

La communauté Rails est extrêmement importante et les contributions sont variées :

  • des foisons de gems et plugins sur github
  • d’excellents guides sur les concepts clés de Rails
  • quelques blogs majeurs ou encore quelques screencasts
  • de nombreux services sur le cloud
  • des milliers de questions et réponses sur stackoverflow

Un framework fait par des agilistes, pour des agilistes

Un critère devenu extrêmement important ces dernières années lors de l’évaluation d’un framework est sa testabilité. Qu’en est-il avec Rails ?

Et bien soyez rassurés, il n’y a aucun doute à avoir : Rails est le framework le plus testable que j’ai pu utiliser ces dernières années. La première raison est que par défaut un projet Rails embarque toute la mécanique permettant de mettre en oeuvre 3 stratégies de test différentes, toutes complémentaires, pour tester votre application :

  • la plus importante, le test unitaire, peut être utilisée pour tester n’importe quel objet de votre application : principalement les modèles mais aussi n’importe quelle librairie.
  • les tests fonctionnels permettent de tester unitairement un controlleur et fournissent le nécessaire pour injecter simplement des requêtes HTTP et vérifier le rendu HTML (ou autre)
  • pour finir les tests d’intégrations sont des sortes de super tests fonctionnels, permettant de tester un enchainement de pages et de controlleurs.
  • #exemple de test d'intégration
    class UserFlowsTest < ActionController::IntegrationTest
       fixtures :users
       test "login and browse site" do
         https!
         get "/login"
         assert_response :success
         post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
        assert_equal '/welcome', path
        assert_equal 'Welcome avs!', flash[:notice]
    
        https!(false)
        get "/posts/all"
        assert_response :success
        assert assigns(:products)
      end
    end

Et pas la peine de vous demander comment est géré l’état de la base de donnée pour ces tests : Rails gère pour nous toute cette configuration fastidieuse. Souvenez-vous donc ce que l’on doit faire en Java : configuration d’une base de données mémoire, génération automatique du schéma avec JPA, gestion des jeux de données DBUnit …

La seconde raison est que la communauté Rails propose des outils de tests bluffants (et pour le coup, bien loin de ce qui existe en Java). Les deux que j’ai envie de retenir sont:

  • factory_girl, qui permet de définir des modèles d’objet et de les réutiliser facilement dans tous ses tests. Chaque test peut rester « ciblé » sur ce qui doit être testé.
  • cucumber, pour sa part est un outil de « spécifications exécutables » sur lequel nous avons déjà rédigé quelques articles. Il s’agit tout simplement de l’outil le plus expressif qui existe pour rédiger des tests (et en français dans le texte !)

Sans aucun doute, Ruby on Rails peut donc être utilisé en contexte agile. Et comme l’agilité ne s’arrête pas aux tests, Rails va plus loin :

  • le déploiement automatisé est extrêment aisé avec Capistrano. Et même encore plus simple si vous utilisez un hébergeur comme heroku (git push heroku et ça tourne sur le cloud !)
  • la gestion incrémentale des bases de données, longuement décrite dans cet article, existe nativement dans Rails. Et par exemple, si l’un de vos coéquipiers livre du code altérant la base de données il vous suffira de lancer la commande « rake db:migrate » pour appliquer ces modifications (bien entendu pas besoin de redémarrer le serveur, même si c’est un réflexe bien ancré chez les Javaistes ;-) )

Je peux le faire aussi en Java !

Alors vous pourriez me rétorquer que des frameworks similaires à Rails ont vu le jour en Java (ils sont nommés « frameworks productifs » en Java, le sous-entendu pour le reste de l’écosystème Java est on ne peut plus clair !) :

  • Play Framework fait beaucoup parler de lui ces derniers temps. Il s’agit d’un clone de Rails très élégant dont la caractéristique première est d’utiliser Java, langage maitrisé par de très nombreux développeurs. Play séduit mais émerge encore.
  • Grails (pour Groovy On Rails) s’inspire en directe ligne de Rails, mais utilise le langage Groovy et met en oeuvre les frameworks standards de Java comme Spring ou Hibernate. Après déjà quelques années, Grails est loin de bénéficier d’une communauté aussi large que Rails.
  • Pour finir Spring a récemment créé Roo, son framework de productivité. Mais ce dernier peine à séduire et laisse perplexe quant à la stratégie de Spring sur le sujet (car rappelons que Grails est aussi un projet SpringSource).

Ces frameworks productifs sont certes intéressants, mais  vous vous mettriez clairement en retard de quelques années en utilisant un framework qui court derrière Rails. Et d’autre part vous vous priveriez d’une communauté extrêmement importante …  Rails est pour sa part un projet toujours extrêmement actif et la version 3.0.0 du framework vient tout juste de sortir. Un prochain article sera consacré à l’utilisation de Ruby on Rails en entreprise.

Quelques mots pour conclure

Cet article aura pu vous sembler partisan, mais il est difficile de contenir son enthousiasme lorsque l’on écrit sur une technologie aussi séduisante. Sachez tout de même que les principaux manques que j’ai pu constater tournent autour de l’industrialisation (qui pour le coup est un sujet très mature en Java) :

  • le release management (gestion de releases avec dépendances multi-projets) n’est pas aussi carré qu’aven Maven. L’arrivée récente de Bundler est bénéfique, mais Rails demeure en retard sur ce sujet.
  • Metric-Fu est une solution de qualimétrie sympathique, mais de même ce n’est pas aussi agréable à utiliser qu’un Sonar.
  • Une autre partie de l’industrialisation concerne le poste de développement : si l’installation d’un poste de développeur Rails se déroule sans problème sur Mac, et de manière correcte sous Linux, le processus peut devenir extrêmement laborieux sous Windows !

J’espère que j’aurai su vous éveiller votre curiosité au sujet de Ruby on Rails. Pour ma part, je n’ai pas autant pris plaisir à développer que depuis que j’ai découvert cet outil !

Alors, vous vous y mettez quand ?

29 commentaires sur “Confessions d’un Javaiste repenti”

  • Je suis aussi un ancien java-iste converti a Rails, c'est que du bonheur. J'ai retrouvé le plaisir de programmer :)
  • Cela fait plusieurs années maintenant que l'on entend parler de Rails. J'ai moi même effectué pas mal de tests mais en réalité, à l'ouest rien de nouveau. Tout ce que fait Rails peut être fait en Java (comme il a été dit) et pas forcément de manière moins productive. Car en terme de productivité, il ne s'agit pas de peser le nombre de lignes de code (ou de configuration) comme les "Railseux" aiment à le penser. Il faut aussi tenir compte de la maintenabilité et de la pérennité, deux points à mon avis au désavantage de Rails. J'ajoute qu'aujourd'hui, le recrutement n'est pas aisé dans le monde du dévelopement, mais alors en Rails, c'est quasiment mission impossible (c'est le vécu qui parle, et ça fait un an qu'on galère). Par ailleurs, je vois encore pas mal de points à l'avantage de Java : - performance (si quelqu'un prononce le mot JRuby, je rigole) - reporting projet et outils de qualité - construction et déploiement de livrable - immaturité de pas mal de briques - manque éventuel de certaines librairies qui peuvent être nécessaires (si on reprononce JRuby, je re-rigole) - grande base de dévelopeurs alors que Ruby demande un effort important ne serait-ce qu'en termes de syntaxe - plusieurs grands éditeurs et fondations travaillant à toute sorte de produits (CMS, GED, ECM, Portails, etc.) Et j'en oublie surement. C'est clairement une technologie à suivre, le problème, c'est que ça fait des années que ça dure.
  • Ce n'est pas la première fois que je vois ces arguments, et à chaque fois c'est par des gens qui se révèlent ne pas bien connaitre le framework... Et vu les points avancés c'est le cas : Productivité ?! SI, Rails EST plus productif que Java : on peux créer un moteur de blog en 10min en Rails. En Java, on n'aurais toujours pas commencé car Maven n'aurais pas encore fini de télécharger la moitié de l'univers... Performance ? Avec Passenger+Ngnix/Apache et tout se passe très bien... De plus on fait du web... cloud computing, tout ça..hein ;) J'utilise Rails en production tout les jours et c'est souvent plus rapide qu'un site en JEE/JSP... Reporting ? Les outils qualité fourmillent de partout !! scout, getexceptionnal, bluepill, etc... il suffit de chercher un peu ! Déploiement ? Capistrano. Immaturité ? Rails3 est la fusion de 2 frameworks(Rails+Merb), que Wicket/Struts/Faces & co fusionnent et on en reparle ;) manque des librairies ?? RubyGem - Dur à apprendre ?? Non, mais sérieusement ??? la blague... En 2 semaines à peine on peut maitriser la syntaxe du language ... J'ai le sentiment que les Java-istes se comporte exactement comme les C/C++ d'il y à 20 ans, ne veulent même pas se donner la peine d'apprendre, et lancent des arguments sans fondements parce qu'ils ne voient plus au delà de leur périmètre de compétence... Java est un très bon language industriel, mais faire du web avec l'un de ses frameworks c'est incomparablement plus compliqué et lourd qu'avec un vrai framework Web tel que Rails... De plus la majorité des devs Java utilisent encore SVN, il est tellement dur de leur faire comprendre qu'il faut se mettre à Git, que tenter de leur faire comprendre le reste est décourageant...
  • arf, je répondrais qu'une seule fois parce que "don't feed the troll". Mais bon, c'est toujours pareil avec les "fan" (euphémisme inside) de Rails : - pas besoin de créér un moteur de blog en Java, ça a déjà été fait en open source depuis des années...Quant à Maven, on télécharge pas la moitié de la terre quand on développe depuis plus d'un an... - je maintiens pour la perf, Ruby est très loin derrière, et comme le PHP par exemple, essaye de trouver des paliatifs qui ne font que masquer le problème à grand coup de caches en tout genre. Le cloud ne change rien aux performances, ça n'a juste rien à voir. Je n'ai pas dit qu'on ne pouvait pas supporter les même charges, juste que le coût n'est pas le même. - pk Struts/wicket/JSF & co fusionneraient-ils ? Ils ne sont pas du tout destinés aux même types d'application. D'ailleurs, je ne voit pas comment ils pourraient le faire, puisqu'ils n'ont rien à voir les uns avec les autres ! Le choix est une bénédiction. Celui qui dira le contraire, celui là n'a rien compris à l'open source et est de plus un chercheur de marteau en or. - je suis souvent des formations PHP, .NET et tout un tas d'autres technos utilisant des langages dont je n'ai pas l'habitude et Ruby me semble clairement le plus difficile. Quant à l'argument C++, Java c'est des vieux, youpi faut faire du Rails. Non seulement cet argument a un côté Kevin, qu'il ressemble à une sorte de point Godwin des discussions avec les Ruby boys. Pour finir : Git. Encore une fois, I won't feed the Troll. Mais force est de constater que 98% de ce qui fait recommander Git est un manque de bonne pratiques sous SVN, écouté et vérifier dans la bouche des experts du Paris JUG
  • Il faut arrêter le dev, ça rapporte pas assez.
  • Merci pour ces retours Waddle, je souhaite réagir à mon tour : - perf : c'est un constat, Ruby est plus lent que Java. Rappelons tout de même que lorsque l'on parle de performances web, la responsabilité du code serveur est en générale minime. Les vrais gisements d'amélioration concernent le cache HTTP, l'optimisation des assets, du JS, des DNS ... Et à ce sujet Ruby me semble mieux armé que Java. Côté serveur, Ruby évolue vite (Ruby 1.9.2 par exemple) et les archis Nginx/Passenger - reporting projet et construction de livrable : ok je partage le meme constat. Mais on est pas à poil pour autant en Rails - immaturité. Pas factuel, je ne réponds pas - manque de librairies. Idem - trouver des développeurs. Oui je rejoins ce constat aussi, mais la communauté n'est pas si réduite que ça. Et passer d'un langage/framework a un autre n'est absolument pas insurmontable pour un passionné - concernant la pérennité. Rails en est à sa 3eme version, des contributions très importantes et n'a plus rien à prouver sur ce point - maintenabilité. Ces dernières années nous ont appris que l'un des facteurs les plus importants de maintenabilité d'une application est le test. Je crois m'être suffisamment étendu sur ce sujet dans l'article pour montrer que Rails est mieux armé que la plupart des stacks Java pour mettre en place un harnais automatisé Tu sembles avoir des retours sur JRuby (que je n'ai pas), ça m'intéresse ! Peux tu nous en faire part ? Merci :)
  • Effectivement, il est très difficile de trouver des développeurs ou des boulots Rails en France. Par contre, je vous invite à regarder de l'autre côté de l'atlantique ou de l'autre côté de la Manche. Il y a de nombreuses offres d'emploi et en plus très bien payé. Et non, je ne dirais pas que l'on est à la traine en France ;)
  • "Pour finir : Git. Encore une fois, I won’t feed the Troll. Mais force est de constater que 98% de ce qui fait recommander Git est un manque de bonne pratiques sous SVN, écouter et vérifier dans la bouche des experts du Paris JUG" Ca troll dure !!! Trop fun de pondre un bouquin sur la bonne ou mauvaise utilisation de SVN, voila un bon outil... Merci de suivre les bonnes recommandations si vous voulez survivre avec SVN. Sous Git, à part l'aspect au secours il y a trop de commande, la seule bonne pratique et de l'utiliser sans en avoir peur. Grande différence... pas besoin de passer par un expert SOS SVN. GIT fonctionne sans avoir à réfléchir ou à déposer un dossier d'archi avant de commiter!
  • @Yannick : pour le coup je ne suis pas d'accord :) J'adore Git, le merge de branches fonctionne merveilleusement bien, mais je trouve la montée en compétence rude ! Alors non je ne reviendrai pas à SVN, mais Git (de part sa nature distribuée) est beaucoup plus complexe à appréhender. Mais recentrons le débat sur Ruby On Rails, Git est un sujet à part entière
  • Dans les commentaires: des javaistes qui refusent de se rendre compte qu'il va leur falloir évoluer et ne pas s'enfermer dans des techno qui commencent à se faire vieilles. Après on cherche les justifications que l'on veut pour valider sa frilosité technique et éviter ne pas apprendre de nouvelles choses. C'est quand même plus simple de refuser en bloc le Rails sur des arguments non justifiés basés sur des préjugés d'il y a 3 ans.
  • Bonjour, merci Christian pour ce témoignage. Je fais parti de ceux qui n'ont pas à être convaincu par la présentation d'outils comme ROR bien que je sois plus Pythoniste et son pendant Django :) . Cependant, tu dis être converti professionnellement, mais il manquerai un paragraphe sur l'acceptation de ROR par l'industrie. Java et .Net sont aujourd'hui les langages qui ont l'étiquette "technologies sérieuses destinées à l'entreprise", PHP commence à se faire une place au niveau pur web dans des cas particuliers. A tu un retour a faire sur la proposition de ROR ? Je ne rebondirai pas sur la discussion trollesque qui s'annonce, mais je voudrai dire que Git, comme tout gestionnaire de sources décentralisé, propose avant tout un concept d'utilisation différent. Une bonne pratique sous SVN ne permettra pas d'arriver aux même avantages que ceux proposés par un SCM distribué. Et un SCM distribué n'est pas une réponse ultime non plus.
  • Hello Darko, "Rails en entreprise" sera l'objet d'un article à part entière (avec du jruby dedans). To be continued .... ;-)
  • Ruby en entreprise... tout dépend de l'entreprise. Les entreprises du CAC 40 qui ne laissent pas vraiment de place à la nouveauté, qui mettent en place des cellules transverses afin de rationaliser leurs développements (pour assurer une pseudo homégéneité de leur SI), clairement, ne se laisseront pas tenter par Rails. En revanche dans les PME de moins de 5 ans et les startups dont l'IT doit être un avantage concurrentiel, il est de plus en plus fréquents de voir Rails. Par exemple, lors de la startup week end à Paris, Rails est la techno qui arrive en tête devant PHP et bien sûr Java. source : http://fr.readwriteweb.com/2010/05/10/divers/startup-weekend-paris/ Sinon, il existe dans la communauté Rails un concours annuel distribué, Rails Rumble, où 300 équipes livrent une appli en 48h (pas de pb pour organiser cet événement, donc niveau industrialisation, ça doit pas être si mauvais...). Cela pourrait être marrant de faire la même chose tout langage confondu, sur un thème imposé. On pourrait alors comparer ce qui est comparable.
  • > Et en fin de compte, cette variété de frameworks nuit à Java : elle apporte beaucoup de complexité, aussi bien dans le choix des briques que dans leur assemblage. Je ne suis pas d'accord. Avoir le choix entre plusieurs frameworks sera toujours un avantage rien que par le fait qu'un framework ne peut pas répondre à tous les besoins. On parle d'applications web et on est d'accord tout ces frameworks y sont destinés mais diversité rime avec nouvelles idées et donc inovation (ex. Spring a initié le concept d'IOC et maintenant c'en est devenu un standard que l'on retrouve dans JEE). Rails a beaucoup apporté en termes d'innovation à tel point que de nombreux frameworks s'en inspirent mais on trouve aussi du bon ailleurs... En plus en lisant cet article j'ai eu le sentiment que dans le monde Ruby, Rails était l'unique framework existant ce qui n'est pas vrai. Or dire par exemple: > Mais Rails s’en sort mieux sur ce point car d’une part la « colonne vertébrale » d’un projet Rails est standard alors que ce n’est pas le cas en Java (où l’on peut être basiquement en JEE, Spring ou Seam) c'est comparer un framework du monde ruby avec plusieurs frameworks Java! Pas incroyable que la "colonne vertébrale" d'un projet utilisant Seam ne suive pas celle d'un projet JEE6. Par contre tout projet JEE6 peut (et devrait) suivre la même structure de projet en projet. Je terminerai en disant que Java en terme de communauté n'a pas trop de souci à se faire. Que ce soit en quantité ou en qualité, l'éco-système Java est plutôt gâté!
  • Le troll s'engraisse vite :-) Ruby On Rails souffre peut être d'une image effectivement basée sur des préjugés d'il y a 3 ans, mais en terme de préjugés et de caricature je crois que c'est Java qui est le mieux servi (le "tank" qui défonce tout hein...) Si on remonte à 3 ans, JEE 5 était encore tout frais et Struts encore en vogue... Les gens qui se sont arrêtés là et ont basculé sur d'autres techno n'ont-ils pas continué de suivre l'évolution de Java? Donc moi ça me fait rire ceux qui parle de Java comme une techno vieillotte, qui manque d'innovation... Personnellement, j'ai passé l'été à "apprendre" un nouveau framework: JEE 6. C'est pas encore fortement orienté "web" (et ça ne le sera jamais) mais y'a pas mal de bon truc. Perso j'aime bien JSF2 et je trouve CDI vraiment énorme... Ouh là je donne trop à manger à ce troll... En commentaire sur l'article, je dirais qu'il est excellent! :-) Pourquoi? En partie parce qu'il est mesuré et semble vraiment objectif. J'attend avec impatience le prochain qui traite de "Rails en entreprise"
  • Dommage que Waddle ne soit pas encore repassé par ici pour nous donner ses informations sur JRuby :)
  • Le bazar qu'est devenu Java a surtout permis de dissimuler la piètre qualité de nombreux développements derrière une pseudo labélisation 'entreprise'. En clair : vendre de la m*rde à prix d'or mais de manière rassurante pour le client final (un grand compte la plupart du temps). Bavard, devenu un sac à bidouilles introspectives mal assumées, Java et ses satellites resteront pour moi l'exemple typique d'une technologie prometteuse dont l'évolution est un raté monumental. Combien d'année avant d'arriver à un Struts well done ? Y est-on d'ailleurs ? Quant à Rails, j'ai découvert ce framework (et Ruby par la même occasion) il y a 4 ans à une époque où j'étais à deux doigts de l'écœurement total. Aujourd'hui la version 3 est un produit mature complètement cohérent avec lequel programmer est un plaisir (oui on peut aimer son boulot et ses outils, ça n'est pas sale !). Je ne regrette qu'une chose, être trop marqué par les langages ancienne génération. Ruby est une merveille dont l'apprentissage des subtilités est un peu raide pour un vieux routard formé à la POO des années 90. Dernière chose, au delà des outils l'état d'esprit qui anime le monde de Rails est excellent. La différence se fait aussi de ce côté là. Rails s'impose lentement, influence de plus en plus et on en rigole de moins en moins. Reste à espérer que Rails ne deviennent jamais 'mainstream' !
  • Sans avoir eu trop à me plaindre de Java, un jour j'ai essayé Ruby et RoR. Quelle bouffée d'oxygène, je ne crois pas re-écrit du Java depuis (Mais ce n'est que partie remise). L'univers Java est si riche qu'on a tendance a ne pas avoir le temps de regarder ailleurs, pourtant ça vaut vraiment le coups, et pas seulement pour Ruby.
  • Grails bénéficie d'une très bonne communauté (fort enthousiasme de la part des javaistes) et a le très net avantage de tourner sur une jvm nativement et donc de pouvoir cohabiter à côté de développement java si on a besoin de fonctionnalités plus poussée.
  • A mon avis, ce qui fait la force de rails ce n'est pas tant la richesse de ces fonctionnalités (l'ecosysteme java est au moins aussi riche) que les capacités du langage ruby sur lequel il repose: -parametres nommés, closures et autres syntaxic sugars -typage dynamique -metaprogramming -dynamic module system Avec les caractéristiques ci dessus il devient facile d'exposer et de distribuer des fonctionnalites sous forme de DSLs et de module dynamiques. En effet un DSL est bien plus expressif (donc concis) qu'une API. Ensuite un systeme de module dynamique permet de les distribuer et de les utiliser facilement (versioning, hot deploy, etc...), en tout cas plus facilement qu'en java ou l'on risque le JAR Hell.
  • Suite à cet article, j'animerai une courte présentation de Rails au prochain Paris Java User Group : https://blog.octo.com/presentation-rails-au-paris-jug/
  • Bonjour Christian, Et merci pour cette introduction ainsi que pour la prez (un peu chaotique ;-) ) du Jug. Je m'interroge sur les possibilités d'interaction entre RoR et l'univers Java. Si j'ai besoin par exemple d'utiliser un framework spécifique comme Drools ou Lucene. Que conseilles-tu. Trouver un équivalent dans le monde Ruby ? Utiliser JRuby ? Utiliser un Bridge ? L'idée étant de récupérer le meilleur des 2 mondes. Merci
  • Comme l'a très bien présenté Nicolas Martignole au dernier ParisJUG, il existe un framework appelé Play!, qui est exactement Rails mais en syntaxe Java (pour ceux qui ne veulent pas apprendre le langage Ruby - mais c'est vraiment dommage). Voit plutôt par là, car les bridges entre langages aussi performants qu'ils soient, c'est toujours un peu galère et ralenti les choses...
  • Mouais, franchement Play ne me branche pas des masses. Je préfère investir du temps dans une nouvelle plateforme cohérente que dans quelque chose de bricolé pour ressembler à cette plate-forme. Dans le genre, je préférerai lorgner du côté de Grails. Maintenant je m'interroge sur la capitalisation du savoir faire sur des briques Java qui n'ont à priori par d'équivalent en Ruby (comme les deux exemple sus-cités) pour jouer sur les deux tableaux.
  • Bonjour Antoine, Moi je vois les choses comme ça : 1/ vérifier que tu as vraiment besoin d'un moteur de règle (je dis ca parce que j'ai déjà vu de nombreux projets utiliser ou songer à utiliser un JRules hors de prix à mauvais escient). Sinon j'ai rien à redire sur Lucene / Solr 2/ chercher un alter-ego dans le monde ruby est une bonne idée. Je n'en connais personnellement pas, mais je n'ai pas eu ce besoin. Mais visiblement google est assez bavard sur le sujet "ruby on rails" + solr 3/ imaginer des architectures intégrant ces briques hétérogènes sur la base de services REST ou de middleware asynchrones Pour ce qui est d'utiliser JRuby à ces fins, je ne pense pas que ce soit une bonne idée. Je pense qu'il est préférable de voir JRuby comme une plateforme de run alternative permettant de déployer du Rails sur une infrastructure Java existante (serveurs d'app, monitoring ...). Mais en gardant à l'esprit que l'on peut rebasculer sur du run Ruby plus classique (passenger, nginx, unicorn ...) quand on veut. En se mettant à utiliser des apis Java depuis le Ruby, tu risques de t'enfermer dans une architecture où tu pourrais vite te sentir tout seul, et qui en plus te contraindraient à utiliser un serveur d'app Java en dev (ou comment tuer la productivité de Rails) Voilà pour mon avis, bon courage :)
  • Bonjour tout le monde, J'ai une question concernant Play framework. Est-il judicieux de développer un site web via une plate-forme Java généralement utilisée pour le développement d'application web. Cela ne présente-il pas des inconvénients? Peut-elle être facilement utilisée par quelqu'un d'autre qu'un développeur pour tout ce qui est changement de contenus? Je vous remercie d'avance pour vos retours. :-)
  • Hé bien, 7 ans après, il semblerait que RoR n'a pas vraiment percé :D
  • hello, rails n'a jamais vraiment percé ??? lol une communauté toujours très active et toujours open source, on peut faire à peu près tout et n'importe quoi avec rails la preuve : http://rubyrails.ninja/formations du webmarketing à la blockchain , en passant par les chatbots et le machine learning, tout est possible !
  • Whaou, tout ceci date de 2010. Pas sur que ce soit encore d'actualité à la vitesse ou les technos évolues ;) Ne continuons pas à comparer un framework (Rails) et un language (java), ça n'as pas trop de sens. News côté Rails : Websockets intégrés, upload de fichier intégré. News côté Ruby: Version actuelle 2.4.1. New communauté: Les devs ruby jouent avec Elixir/phoenix, Crystal, Elm et Rust.
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha