Finalisation de mon mémoire sur ROR, mais pourriez-vous répondre à 2 question stp


#1

Bonjour,

Actuellement je suis en train de rédiger mon mémoire de fin d’année.

Depuis 1 ans et demi je suis sur la techno ROR.

Le mémoire et sur l’engouement de ROR qui à évolué.

J’ai quelques question à vous poser pour compléter mon mémoire

Pourquoi ROR a mis du temps à être utilisé dans les startups et les entreprises ?
Quel avenir pour Ruby on Rails ?

Merci d’avance.

Chris


#2

Ce sont deux très bonnes questions. Je crois premièrement que c’est difficile de changer. Dans les écoles, on enseigne plutôt PHP, JAVA ou C. Apprendre Ruby demande donc un effort supplémentaire.

Une entreprise qui possède déjà une équipe dans un langage ne changera probablement pas facilement. Dans certaines petite boites, l’important c’est que ça marche. On se fout un peu de la qualité du code. PHP fait donc tout à fait l’affaire, pas besoin d’aller plus loin.

Dans les grosses boites, il y a déjà Java qui fait tout et qui à prouvé que c’était viable sur le long terme.

Pour une petite boite, c’est plus facile de trouver des développeurs PHP ou JAVA donc tu as moins peur de perdre un programmeur étant donné que tu peux le remplacer en quelques jours. De plus, étant donné qu’il y a moins de développeurs Ruby, ceux-ci coûtent plus cher.

Je ne sais pas si ce sont vraiment les raison mais c’est peut-être un élément de réponse.

Si tu décides de partager ton mémoire, fais m’en part.


#3

C’est toujours difficile d’aborder ce genre de questions, mais selon moi ROR n’a pas un très grand avenir.

Comme l’a déjà dit @guire_corbel, beaucoup d’entreprise lui préfère Java (qui contrairement à ce qu’on pourrait croire, est plus récent que Ruby) ou même PHP (berk).

En terme de langage et d’ecosystème, je trouve que python est bien plus solide et simple: http://learn.onemonth.com/ruby-vs-python.

ROR était une belle innovation au moment de sa sortie, mais aujourd’hui la plupart des principes du framework ont été repris par certains framework dans d’autres langages (Play en Java/Scala, Django en Python, Grails en Groovy) et je préfère développer en Java, Python ou NodeJS plutôt qu’en Ruby.

A prendre avec des pincettes, mais TIOBE est un indicateur : http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.html


#4

D’autant qu’en France, ROR n’a jamais vraiment percé à l’inverse des USA. Ruby a longtemps souffert de problème de performances et les français raffolent des on-dit, du coup beaucoup de développeurs, sans même avoir testé ou mis à jour leur informations (le plus gros problème, l’héritage d’une réputation en France persiste des années), ont exclu ROR pour ces raisons.

Et je pense que jusqu’à l’arriver d’Heroku, déployer du Ruby/ROR pour une startup était bien plus contraignant que du PHP, d’où la popularité indéniable de PHP.

Après je ne suis pas un développeur ROR, mais je rejoins @Toilal sur l’avenir de ROR. Si aucun changement majeur ou innovant émerge de ROR d’ici la, les gens vont se lasser. Je pense réellement que la “mode” dans les langages existe, et je pense qu’en ce moment le langage en vogue est Go tandis que Ruby/ROR (car ROR est un framework mais porté par Ruby) est bien moins sexy qu’avant.


#5

Salut!

Je ne connais pas ROR, mais cet article devrait t’intéresser:
http://mattbriggs.net/blog/2014/09/09/the-rails-value-proposition-no-longer-adds-up/

Aurélien


#6

Pourquoi ROR a mis du temps à être utilisé dans les startups et les entreprises ?

Ruby a été popularisé par Rails, Rails a été créé par et pour des startups : Basecamp, puis Twitter, etc
Il y a eu un fort engouement entre 2008 et 2011 (jusqu’à ce que Node ne décolle en fait)
Aux US d’abord et c’est arrivé en France ensuite (j’ai plus la prez mais si tu cherches en 2011, si mes souvenirs sont bons, 30% des startups créé en France sont partis sur du RoR)

Donc ROR a été utilisé très vite par les startups, ça n’a pas pris de temps.

Pour les ‘entreprises’, j’imagine que tu parles des grands groupes : banques, assurances, etc
Historiquement ces boites ne sont jamais des early adopter de technologie (ou alors à la marge), que ce soit Ruby ou un autre language.

Quel avenir pour Ruby on Rails ?

Bien malin celui qui peut prédire l’avenir :)

La techno a atteint une taille critique qui fait qu’elle est là pour encore de (très) nombreuses années ! Je te laisse te renseigner sur le nombre de ligne de code encore écrit chaque année dans des techno morte depuis plus de 30 ans, COBOL est le meilleur exemples ;)

Pour argumenter et chiffrer tu peux citer :

  • La communauté hyper active : 6e language le plus actif sur Github, à peu près au même niveau que PHP : http://githut.info/

  • Le nombre de grosse boite qui l’utilise comme techno principale :
    Airbnb
    Slideshare
    Stripe
    Soundclound
    Github
    etc

Ca c’est l’existant qui justifie que c’est une techno pérenne.

Mais la vrai question qui intéresse tout le monde, y compris dans ce thread, c’est l’avenir : est ce que c’est une techno qui ‘progresse’ ou qui ‘décline’ ?

Ce qui est sûr c’est que ROR a connu un énorme buzz il y a quelques années, et que aujourd’hui la vague est retombée. L’image de la techno est clairement écornée (lent, pas scalable, etc)

Ensuite pour évaluer ça de manière plus concrète je regarderais :

  • Le volume d’offre d’emploi : à vue de nez, c’est en dessous de PHP, Java, .Net. Mais au dessus de techno plus trendy comme Node.js ou GO

  • L’évolution du classement du language sur les différents sites de comparaisons de languages.


#7

Je crois que concernant l’avenir de Rails, le dernier bon article que j’ai lu à ce sujet est celui-ci :

Il est évidemment subjectif (il agrège l’avis du fondateur de Rails), mais se positionne avec un peu de recul face aux autres technos existantes actuellement.

Bon mémoire, ça doit être rigolo comme sujet ! :)


#8

Oui, c’est cool surtout que j’essaye de retracer l’histoire de ROR,
De ce que j’ai vu avec Rails5, Il sont sur le bon chemin.


#9

TROLL WARNING : je caricature pour avoir un propos simple.
La réalité est plus nuancée. Comme toujours.
[edit: quelques ajouts et un peu de rangement]

Pourquoi ROR a mis du temps à être utilisé dans les startups et les entreprises ?

Says who?

D’où sors-tu tes statistiques ? Que crois-tu et pourquoi le crois-tu ?

Parce que les entreprises ont peur du changement.

"Personne n’a jamais été viré pour avoir choisi IBM."
C’est du business, pas de la techno.

"Parce que les RH ne savent pas l’acheter."
Combien de gens sont embauchés pour faire X et font Y ?

Parce que ton arme secrète… est secrète

Si tu fais du Rails et que ça marche, tu ne vas pas forcément le dire aux autres.
Tu ne veux pas combattre les € rassurants du CAC40 s’ils se mettaient à faire du Rails.
De toutes façons, leur structure fait qu’ils ne peuvent pas forcément accepter l’innovation.
Et puis, tu es occupé à travailler, pas à faire ta pub.

Pourquoi ?

Régie et TJM

Un projet Java ou PHP coûte “moins cher” : tu vires qui tu veux quand tu veux et tu retrouves le même ouvrier peu qualifié à pas cher, surtout en sortie d’école (possible avec Rails, mais pas rentable).

Dans les process que les grosses boîtes se donnent (les achats en premier) c’est cohérent : quand on achète au jour le jour, on cherche à faire moins cher au jour (TJM = Taux Journalier Moyen). C’est pour ça qu’on prend des stagiaires, des juniors, de l’outsourcing… avec les problèmes de qualité et de com que l’on connaît.

C’est la régie, et en cas de dépassement du presta, on accepte que l’on ne trouvera pas toujours du premier coup, mais le risque est porté par le client : si tes codeurs sont en retard, tu les récompense en leur donnant plus d’argent !

=> C’est le combat que se livrent ceux qui sont moyen / bas de gamme.
Vous avez gagné la bataille du prix ? Félicitations, vous avez tué votre marge.

Forfait et TCO

Un projet RoR coûte aussi “moins cher” : plus cher au jour mais significativement moins de jours. C’est l’équivalent d’acheter cher de bonnes chaussures qui font 10 ans, ou 2 paires de trucs pas solides par an.

Dans cette logique-là, tu regardes alors le TCO, Total Cost of Ownership et tu vas compter le dev, mais aussi le déploiement, la maintenance, le coût de la qualité et de l’évolutivité.

Ce n’est pas obligatoirement du forfait : par opposition à tout à l’heure, le risque serait ici porté par le presta intégralement. De plus on aurait un gros cycle en V : tu ne peux t’engager qu’avec l’intégralité du périmètre.
Du coup, c’est plus souvent des lots de fonctionnalités qui permettent de faire des specs légères et itératives, et d’apprendre pour avancer par la suite.

Secret 1 : les gens (qui codent)
Il te faut des gens compétents, auto-disciplinés, capables de bien communiquer sur les enjeux et bien comprendre les besoins. Techniquement ils doivent faire du code évolutif et de qualité, humainement ils doivent aussi être au top. Ils sont aussi plus rares… et avec tout cela, aussi plus chers au jour.

Secret 2 : les gens (qui les gèrent)
Quand tu les embauches, tu as une obligation, pour rentabiliser, de mettre des méthodes plus malines, de former à l’intérieur de l’équipe (ou si ce sont des prestas de t’arranger pour qu’ils forment des gens en interne chez toi), et de capitaliser sur la connaissance.

Ton focus sera différent, tu livres davantage dans le même temps ou pareil mais en beaucoup moins vite. La vraie valeur (je spoile l’histoire) est dans le prototype rapide et itératif, dans l’autonomie que ça donne au métier comme au dev, l’exploration du business model, le droit d’apprendre de ses erreurs…

Ça marche super bien et ça bat les autres projets rien que par le fait d’avoir mis en place une équipe qui a déjà fait sauter les pires barrières à la productivité (possible avec les autres, mais vaut rarement le coup du manager qui met sa réputation en jeu : il faut lui fournir un avantage détonant pour que son chef à lui le laisse casser les barrières).

=> C’est plus rare, mais c’est le combat de ceux qui font du haut de gamme.

Quel avenir pour Ruby on Rails ?

C’est selon le contexte, et il y aura toujours les deux

L’avenir est radieux pour le bas de gamme (pense voitures, chaussures, téléphones) tout comme pour le haut de gamme (idem). La clé est de savoir comment tu te positionnes et d’agir en conséquence : préfères-tu avoir des pièces changeables pas chères et un réseau large de mécanos, ou du haut de gamme tout du long avec plus rare, plus cher, mais vu la qualité un TCO plus faible ?

Bref, je caricature, ça fait longtemps que j’ai jeté cette guerre de religion aux orties.

Il y a du durable en Java mais surtout parce qu’on ne savait pas quoi faire d’autre (à part DotNet). La clé dans tout cela c’est la hiérarchie (et de mon expérience ils en ont marre de prendre les licences que l’écosystème va souvent inciter à prendre).

Hype Cycle, Maturity Model

Les préados qui ternissaient la réputation de Rails sont partis vers Node.

Les startups parties sur RoR ont grandi, on récupère de vrais architectes avec des leçons de plein de langages, plein de frameworks, plein de méthodes (mes préférés sont Arkency et leur super blog). Soit parce qu’elles les récupèrent d’autres technos, soit parce qu’elles les font grandir en interne avec leurs challenges uniques (shopify et github – regarde leurs talks d’infra), ou enfin parce que des boîtes établies font des parties “en dev rapide” dans Rails (LinkedIn).

En France

Je trouve que RoR va bien en France : 2075 membres à ParisRB, de belles boîtes (Capitaine Train, Drivy, iFeelGoods, Algolia…)
J’ai placé du RoR dans de très grosses boîtes, je sais que d’autres prestas l’ont fait aussi. JRuby est mature et performant, ce qui ne gâche rien.

Bref, je pense que l’on n’a plus grand chose à craindre.

Roadmap

Avec ceux qui partent vers l’essor des frameworks JS MVC front, Rails se retrouve en position de “serveur d’API”. Avec ceux qui en reviennent déjà, le rendering côté serveur n’a toujours rien à envier aux autres.
Même avec de la copie, c’est comme toute entreprise/produit : tu veux aller avec le leader ou avec celui qui suit ? Avec celui qui peut et veut se ré-architecturer (il y a des risques bien sûr) ou avec celui qui se coltine un legacy incroyable ? C’est la raison pour laquelle je suis les innovations de la communauté Ruby et de ceux qui en partent (Lotus, Elixir pour l’incroyable concurrence d’Erlang, Haskell pour les fanas de FP).

Bet on the team

Les rubyistes ont pris l’habitude de surprendre et continueront.
Je veux bien regarder les chiffres, mais si Rails rentrait dans le TOP5, ce serait pour moi signe d’une stagnation : avoir une position dominante ne rend pas bête pour autant, mais autorise la flemme ; avoir une position de challenger oblige à se réinventer.

Conclusion

Je ne t’ai pas aidé ? J’ai posé plus de questions que de réponses ?
C’est bien, c’est comme ça qu’on apprend et c’est comme ça qu’on doit continue à avancer :)


#10

@Toilal, je ne pense pas qu’il y ai de meilleur langage entre Ruby et Python. Ce sont tout deux de très bon langage mais la philosophie est différente. Avec Python, tu va faire un code le plus efficace possible. En Ruby, tu vas faire en sorte qu’il soit le plus lisible. Ruby est fait pour être agréable à coder. Quand tu aimes ce que tu fais, tu es plus productif.

@kakawait, Rails à atteins son point de maturité. Comme @abelar_s le dit, il est utilisé dans plusieurs gros projets très stable.

Personnellement, je ne suis pas certain qu’apprendre Rails et lancer des projets avec ce framework maintenant soit une très bonne idée. Effectivement, il n’est plus novateur. Par contre, si on possède déjà une expérience solide, c’est le moment de l’utiliser. Il est très fiable.

Enfin, je dirais que Rails est extrêmement solide pour faire des API. J’ai toujours trouvé que la faiblesse de Rails était dans le vues. Avec des outils “à la mode” comme Angular et Ember, on peut découpler le client-side et le sever-side. Rails est très fort pour le server-side.

Au niveau de la performance et le comparaison avec Go. Il existe le projet Crystal qui reprend la syntaxe de Ruby avec des performances comparable à Go. À voir si ce projet dure dans le temps.


#11

Je n’ai pas dit qu’il n’était pas stable, je disais juste que je trouvais qu’il n’avait pas beaucoup percé en France en dehors des startups.

Mais j’accepte les arguments et les exemples d’@abelar_s sur sa notoriété en France, je peux me tromper.


#12

je trouvais qu’il n’avait pas beaucoup percé en France en dehors des startups.

J’entends souvent cet argument de la part des écoles qui refusent d’ajouter ça au cursus.
C’est très dommageable parce que ce mensonge est perpétué partout et les jeunes y croient.
C’est pour ça que j’aime le réfuter :D

Les écoles d’ingé sont par nature tributaires du marché sur ce qui donnera la meilleure image perçue, et elles préfèrent Facebook et BNPP que startups anonymes 1, 2, et 3. Pourtant quand l’une d’entre elles survit, ça passe à la Une (Criteo par ex).

Les grandes boîtes sont facilement 5 ans derrière l’innovation. Les écoles qui suivent la progression des demandes des grosses boîtes par leur départements RH/RE sont cinq ans de plus derrière.

C’est aussi un argument anti innovation des DSI sclérosées.
À l’inverse, j’accepte à 100% un argument qui dit “on a déjà un truc qui marche” (c’est rare) ou “on a plutôt investi ailleurs” (c’est vrai même si c’est parfois temps de changer) voire “nos équipes sont expertes en X on veut pas changer” (c’est vrai aussi).

À l’inverse, je suis dans tous les ParisRB et j’ai des contacts d’embauches 1 à 3 fois par semaine.
Je suis conscient qu’un jeune diplômé sur une techno classique en a davantage en moins de temps, mais c’est pour un résultat souvent moins satisfaisant.

Mais j’ai forcément aussi une vue biaisée et j’accepte complètement qu’on me le fasse remarquer :)