D'après le lien suivant
Zed Rant
la communauté ruby ne brille pas véritablement par ses compétences ...
Est-ce vraiment si dramatique que ca ?
Est-ce scalabilité signifie juste de mettre un serveur memcached dans l'architecture d'une plateforme ?
Il semblerait que ni PHP ni Ruby ni Python, out of the box ne permettent de batir des architectures scalables... Serait-ce peut être le moment de revoir les copies ?
En avons nous véritablement besoin ?
Journal Ror ne se porte plus très bien ? Quid des autres ?
4
jan.
2008
# Tenue en charge
Posté par IsNotGood . Évalué à 2.
Mouaif...
Es-ce à php etc de le faire ?
Pour la tenue en charge, il suffit d'une base de donnée sur une bécane et plusieurs bécanes qui génèrent les pages html via php.
C'est très utilisé et ça marche très bien.
[^] # Re: Tenue en charge
Posté par Mouns (site web personnel) . Évalué à 4.
sinon pour la techno, les problemes de scalabilité ne sont pas des problemes lié à de la technologie mais un probleme lié à la compétence des devs.
en gros, on redécouvre régulièrement qu'en fait la programmation nécessite des compétences qui ne sont pas acquises à l'école et qu'en prime, l'essentiel des informaticiens bac+2, bac+5, bac+8 sont des guignols.
Donc, là, le gars découvre que la communauté RoR puxorise ... cool, c'est normal.
d'abord, il y a des gars avec une idée sympa qui montent un projet sympa ... puis il y a les madame michu de l'info qui arrivent connu aussi sous le nom geek, developpeurs, utilisateurs ... en gros, des guignols.
... garde toi de t'approcher de la célébrité geekesques qui s'appelle avoir une communauté d'utilisateurs/patcheurs .
Comme disait Epicure, vivons heureux, vivons cachés.
[^] # Re: Tenue en charge
Posté par IsNotGood . Évalué à 0.
De façon général/idéal, c'est bien.
Mais maintenant on peut avoir des quadri-coeur pour pas cher et avec des performances redoutables...
On trouve même des quadri quatri-coeur AMD avec une tenue en charge fabuleuse.
Avec PostgreSQL qui tient bien la charge, pour le mettre à genoux il faut un gros gros succès. Cerise sur le gâteau, tu peux mettre ta base de donnée (du moins les parties les plus utilisées et qui n'ont pas besoin d'être conservée de façon permanente comme les donnés de session) en mémoire vive (tmpfs). Dans ce cas il faut vraiment un truc de malade pour mettre à genoux le serveur.
NB : un bon paramétrage de PosgreSQL peut être aussi efficace que l'utilisation de tmpfs.
Pour ce qui bouffe le plus de cpu, c'est-à-dire la génération des pages html, tu peux mettre en oeuvre plusieurs bécanes très facile si la base de donnée est commune. Le goulot d'étranglement est évidemment la base de donnée, mais tu as de la marge.
Ce que je veux dire, c'est qu'avec la méthode "traditionnelle" (un server de base de données commun et plusieurs serveurs pour les pages html dynamiques) tu couvres au moins 99,99 % des besoins.
Pour aller "s'emmerder" avec Ror, MemCache et tout ça, il faut avoir des besoins très très très spéciques.
# Début de réponses
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Oui, mettre un serveur memcached aide pour la scalabilité, mais ca ne fait pas tout. La scalabilité est principalement une question d'architecture, et les langages de programmation n'ont qu'un faible rôle à y jouer.
En attendant, Ruby on Rails n'est pas parfait mais il me semble être encore en avance sur les autres frameworks. Donc pour répondre à ta question initiale, Rails se porte très bien.
[^] # Re: Début de réponses
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
(bon ok ça n'a rien à voir avec le langage, c'est aux dévs/admins réseau de penser une bonne architecture)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Scalability
Posté par Erwan . Évalué à 1.
Avoir un serveur memcached ne suffit pas, ça aide mais il y a beaucoup de choses a prendre en compte pour pouvoir passer à l'échelle. Quoi que tu fasses, quand tu vas monter en charge tu vas trouver de nouveaux goulots d'étranglements (bottlenecks) que tu vas devoir corriger.
* Web server
* Base de données (lectures)
* Base de données (écritures)
* Bande passante
* Réseau local; eh oui, quand tu as un gros cluster tes switchs vont saturer
* etc...
Quand tu fais tu PHP, du Ruby (pur) ou du Python, c'est "stateless" donc en général ça marche bien. Il faut juste t'assurer de ne pas sauver les infos de session localement sinon ça marche plus: l'utilisateur utilise un serveur pour sa première requête, un autre pour la seconde et boom plus d'infos de session.
Avec les frameworks comme Rails c'est plus complexes, avec des trucs comme ActiveRecords qui sont très sympa mais rendent plus difficile le passage à l'échelle. Je ne connais pas bien Rails, d'après un copain ça passe à l'échelle comme PHP ou autre... Mais il faut ajouter des machines plus souvent.
# Revenir aux fondamentaux
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
> permettent de batir des architectures scalables... Serait-ce peut être
> le moment de revoir les copies ?
Il suffit de revenir aux fondamentaux, c'est à dire au Perl qui a toujours su garder une bonne performance tout en évoluant ;-)
Il y a des 'framework' qui vont bien, par exemple Catalyst
http://catalyst.perl.org/
# Non !
Posté par ckyl . Évalué à 1.
Non
http://qcon.infoq.com/sanfrancisco/tracks/show_track.jsp?tra(...)
http://jxh.bingodisk.com/bingo/public/presentations/JHoffman(...)
etc.
# Hmmm?
Posté par romain . Évalué à 1.
Bah ça dépend ce qu'on entend par scalabilité, mais pour qui a utilisé du PHP de manière sérieuse, on peut constater qu'on peut monter des systèmes assez lourds, néanmoins performants et distribués, sans panne.
Après, ça ne dépend pas particulièrement du langage (chaque langage a ses tares, PHP tient le peloton de tête), mais de la façon dont il est mis en oeuvre ; et par qui.
# Ror
Posté par ouah (site web personnel) . Évalué à 0.
# erlang ?
Posté par fredix . Évalué à 1.
http://erlyweb.org/
[^] # Re: erlang ?
Posté par forc3 . Évalué à 2.
Erlang est un peu différent, erlang est né d'un besoin venant de l'industrie.
Ce langage a été créé pour pour répondre à des problématique bien précises.
Les plus notables sont:
- La tolérance au panne,
- La rapidité de maquettage,
- La haute disponibilité.
Les livres et documentation officielle traitant du sujet en parleront mieux que moi:
http://erlang.org/doc/getting_started/part_frame.html
Le langage est fonctionnel ce qui signifie pour nous programmeurs (en simplifié :) que les closures et la récurrence sont omniprésents. Que les travaux sur les listes ou les arbres sont courants.
Malheureusement pour parler de erlyweb je dirais que ce projet tente de recopier RoR, alors que RoR est bati sur un langage complètement différent.
Erlang c'est de la programmation concurrente, et c'est bien là toute la différence avec les autres langage objets (Python, Ruby, Php) ou pas (Php) disponibles... Erlang rejette la notion d'objet, il mets en avant la notion de clients serveurs.
De son point de vue, un objet et un serveur et ses méthodes sont simplement des requètes faites à ce serveur.
L'énorme avantage d'Erlang est aussi sa plus grande difficulté d'accès est le 'share anything paradigm'.
Aucune donnée n'est partagée, tout se fait à travers des messages.
(imaginer une rue commercante où tout les marchants crieraient pour discuter entre eux d'un côté à l'autre, le boulanger faire cuire son pain pendant qu'il réponds au boucher qui fait rôtir son poulet... Le monde est concurrent, ma femme arrive à tenir deux conversations etc.)
Les processus discutent en échangeant des messages de manière asynchrones.
Je lisais encore tout à l'heure pourquoi le projet MERB http://www.railspikes.com/2007/4/1/merb est né, à savoir, avec Mongrel il était visiblement difficile de faire de l'upload de fichier...
Ruby semblait bloquer, or ce n'est pas exactement ce qui se passait et c'est pourquoi MERB est né.
Ce que mets en évidence MERB c'est tout simplement que la concurrence n'était pas gérer du tout dans Ruby (j'exagère à peine).
Et la véritable raison à cela est tout simplement que les programmeurs actuels ne sont pas du tout capables de penser concurrence. La formation n'existe quasiment pas et la culture n'aide pas les éventuels aventuriers du domaine.
Il fait se rendre à l'évidence le modèle concurrent bien plus 'naturel' n'est pas encore à la portée de tous.
Cependant la concurrence nous allons tous devoir nous y mettre, il est tout simplement impensable à l'heure actuelle d'ignorer l'arrivée de processeurs à plusieur coeurs.
Tant que la programmation par sémaphore et par "shared memory" sera utilisée les programmes ne seront pas capables de bénéficier de toute la puissance des nouveaux processeurs.
Penser un programme de manière concurrente cela veut dire qu'on est capable de le faire fonctionner (sans réécrire quoi que ce soit) sur un processeur multicoeur mais aussi sur une grape de serveur... (erlang rends le réseau transparent, les processus ne sont pas que locaux)
Afin de peut être vous familiariser avec ces notions je vous invite à regarder la http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/sli(...) présentation de Randy Shoup (eBay) et plus particulièrement la page 4 décrivant les stratégies adoptées par eBay:
Strategy 1: Partition Everything
– “How do you eat an elephant? ... One bite at a time”
Strategy 2: Async Everywhere
– “Good things come to those who wait”
Strategy 3: Automate Everything
– “Give a man a fish and he eats for a day ... Teach a man to fish and he eats for alifetime”
Strategy 4: Remember Everything Fails
– “Be Prepared”
Une autre excellente introduction au monde concurrent est visionnable dans une conférence http://www.google.fr/url?sa=t&ct=res&cd=1&url=ht(...) mémorable de http://fr.wikipedia.org/wiki/Alan_Kay ... (apprécier le parallèle avec le corps humain et les cellules...)
Pour les plus curieux je tiens un blog sur erlang: http://easyerl.blogspot.com/
le propos est de montrer qu'erlang est adapté à beaucoup plus de tâches qu'on ne pense, et a fortiori au développement web...
[^] # Re: erlang ?
Posté par fredix . Évalué à 1.
le propos est de montrer qu'erlang est adapté à beaucoup plus de tâches qu'on ne pense, et a fortiori au développement web...
Il y a même des applications desktop, exemple wings3D.
[^] # Re: erlang ?
Posté par rewind (Mastodon) . Évalué à 2.
Je ne suis pas du tout d'accord. On peut très bien utiliser des sémaphores et de la mémoire partagées et faire des programmes très performants sur les nouveaux processeurs. Ou alors, je dois m'être trompé depuis plus de 2 ans que j'en fais.
Avoir un langage dédié doit aider (je ne connais pas Erlang) et à l'inverse, avoir des libs de base (la libc pour ne pas la citer) qui ne sont même pas réentrante, ça n'aide pas vraiment. Mais c'est possible quand même.
Il faut se rendre à l'évidence qu'Erlang n'atteindra jamais le niveau d'utilisation (en nombre) de C ou C++ ou Java. Alors autant évangéliser sur les bonnes méthodes à utiliser dans ces langages. Des initiatives comme Intel TBB ou QtConcurrent permettent d'abaisser le niveau de la barrière à l'entrée et c'est dans cette direction qu'il faut aller à mon avis.
[^] # Re: erlang ?
Posté par titi toto . Évalué à 1.
# air de déjà vu
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
Dès qu'un projet arrive à une certaine ampleur, il y a toujours ce genre de choses.
Lorsque Rails était lancé c'était "C'est que du buzz, ça va mourrir.". Maintenant que Rails vit toujours 4 ans après et se porte très très bien c'est : "Les devs ont pris la grosse tete, ça va mourrir.".
S'il y a quelque chose qui ne risque pas de mourrir c'est bien les trolls :).
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
Quelle est la proportion d'utilisation de RoR par rapport aux autres techno web (PHP, Java, etc.) ? Quelle est l'évolution de cette proportion depuis 4 ans ?
L'impression générale (mais il me manque des chiffres à l'appui) c'est quand même que l'excitation du début est largement retombée et qu'il n'y a pas de réelle adoption large, faute d'acteur majeur dans le secteur (qu'il soit utilisateur de la techno, fournisseur de service ou fournisseur de softs). Un Google aurait (pourrait) changer la donne.
Bref le buzz est retombé, même si en soit la techno est loin d'être morte et a des utilisateurs.
A mon avis ca va pas s'arranger : les autes techno concurrentes (Java, PHP, ASP.NET, etc.) sont en train de s'approprier ce qui fait la force de RoR et limiter un peu plus l'intérêt de ce dernier.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
Pour l'instant le soucis de Rails est la difficulté à lui faire tenir la charge sur des sites grand public. Ce problème n'a pas lieu pour des sites internes à une entreprise. Il reste cependant de bon espoir d'améliorer cela avec Ruby2.
Rails a montré la bonne voie et c'est une bonne chose qu'il existe des équivalents avec d'autres langages. De nos jours c'est une hérésie de développer un site sans framework.
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
C'est aussi ce qui est en train d'être repris dans les autres technos : JRuby ou IronRuby par exemple.
Bref il ne va bientôt plus rester beaucoup d'intérêt spécifique à RoR.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
On est d'accord, tout ce qui faisait la plateforme RoR initiale (à savoir un framework web MVC associé à l'environnement Ruby) a été repris ailleurs en intégralité ou en partie.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
Oui mais justement à mon avis l'intérêt de Rails c'est aussi et surtout la syntaxe de Ruby, que ca soit l'interpréteur officiel, Jruby ou IronRuby peut importe.
En Rails tu fais aussi beaucoup de Ruby, Donc un Framework à la Rails en PHP, Java, pour faire aussi pas mal de code en PHP/Java ... vraiment bof, sauf pour les dev qui aiment bien ces langages bien sûr.
Le seul truc qui peut faire "mal" à Rails sont d'autres frameworks MVC en Ruby, du genre Merb http://merb.rubyforge.org/files/README.html
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
En .NET y'a aussi MonoRails ou le ASP.NET MVC Framework, qui peut être associé à IronPython et bientôt IronRuby.
Bref ces plateformes offrent le choix des langages et le choix du framework.
Il ne reste pas beaucoup d'avantage à RoR, par contre il lui reste toujours les mêmes inconvénients : pas beaucoup d'acteurs de service et donc pas beaucoup de support ou de compétences, pas beaucoup d'outils (notamment IDE), intégration avec technos existantes limitées, pas d'acteur "principal" garant de la pérénité de la techno (style Sun, IBM ou Microsoft), pas de gros site de référence ayant éprouvé RoR (style Google et autre MySpace ou FaceBook).
Autant de raison qui font qu'en 4 ans RoR ne soit pas plus adopté que ca et s'il n'y a pas d'engagement plus flagrant de gros acteurs autour de cette techno, elle n'est pas prêt d'être adoptée au même titre que l'est par exemple PHP.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
Pas la peine de te répéter X fois, on avait compris :)
Sinon tu parles de PHP mais il ne me semble pas que les début de PHP ont été foudroyant ... Il est normal qu'une nouvelle techno utilisant un langage encore très peu connu, hormis en Asie, n'explose pas. Et malgré cela Rails a vraiment explosé par rapport à sa jeunesse.
Sinon il y a encore peu de site grand public en Rails, mais je t'assure qu'il est de plus en plus utilisé en interne, par exemple une "petite" banque comme RBC Dexia IS :
http://2007.parisonrails.org/pdf/6a-PoR2007-Sylvain_Perez-RB(...)
http://2007.parisonrails.org/pdf/6b-PoR2007-Guillaume_Desrat(...)
Voir aussi http://www.business-on-rails.com/ et http://twitter.com
Enfin ce qui a fait le succès de PHP c'est lorsque les hébergeurs/FAI de type Free l'ont proposé... Or il est plus délicat de proposer du mutualisé en Rails qui se propose donc comme alternative à Java. Certes les alternatives comme Groovy et Grails vont tempérer les migrations ce qui est une bonne chose pour Java, mais il n'empêche que Rails et Ruby ont leur place et leur avenir.
Mais bon je n'espère pas te convaincre :)
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
Le truc c'est que PHP avait de net avantages par rapport aux concurrents : web dynamique, simple et libre/gratuit (par rapport à ce que se faisait à l'époque). Ces atouts combinés n'avaient pas d'équivalent et l'ont rendu populaire auprès des développeurs amateurs et des plateformes d'hébergement. On connait la suite.
Sinon il y a encore peu de site grand public en Rails, mais je t'assure qu'il est de plus en plus utilisé en interne,
Ca reste anecdotique non ? Enfin par rapport au buzz initial en tout cas...
Or il est plus délicat de proposer du mutualisé en Rails qui se propose donc comme alternative à Java.
C'est tout le problème : Java vise un public "professionnel" et donc une plateforme complète pour produire des solutions beaucoup plus exigentes (N-tiers, architecture distribuée, etc.) avec support/services de nombreux acteurs du marché, outils de dev/déploiement/exploitation.
Marrant ta signature comparée à la mienne ;)
[^] # Re: air de déjà vu
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> concurrents : web dynamique, simple et libre/gratuit (par rapport à ce
> que se faisait à l'époque). Ces atouts combinés n'avaient pas
> d'équivalent et l'ont rendu populaire auprès des développeurs
> amateurs et des plateformes d'hébergement. On connait la
Pour avoir connu les début de PHP, à mon sens son succès tiens en deux mots : langage basic et easyphp sous Windows. Pour le programmeur Perl que j'était à l'époque, PHP n'avait aucun avantage, on croyais revenir à Perl 1 alors que l'on avait la puissance de Perl5 sous la main avec des classes déjà bien faites comme CGI.pm (pour l'époque) puis est venu assez vite DBI...
J'ai même eu des collègues qui ont bloqué et refusé le Perl et trouvaient génials le PHP du début. J'ai jamais vraiment compris pourquoi ?
Par contre, une chose est sure, easyphp sous Windows a bien aidé, je pense même que c'est la clef principale du succès de PHP.
[^] # Re: air de déjà vu
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: air de déjà vu
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Par contre, ce qui est vrai, c'est que lorsque PHP a décollé chez les providers (parce ce c'était un Perl simplifié à l'époque et que cela devait leur faire moins peur), il était plus difficile d'avoir Perl sur ses pages web.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
C'est loin d'être anecdotique mais peu de boites communiquent sur leur développement interne, normal.
Dans l'une d'elle on avait comparé début 2006 les framework MVC en PHP et Rails et ce dernier a été choisi. Je ne doute pas que depuis les framework PHP ont été amélioré, mais Rails a et aura longtemps une longueur d'avance.
De plus il est à mes yeux pratiquement impossible de migrer rapidement et facilement des développeurs PHP en Java. En Ruby et Rails c'est faisable en 1 mois, voir moins selon le niveau des dev. Pour les multitudes d'applis internes Rails rivalise sans problème avec PHP et ses frameworks, car le problème de PHP c'est le langage très en recul de Ruby, quelque soit les qualités du framework PHP.
Quant aux sites grand public, Eyeka semble bien avoir fait le choix de Rails malgré leurs compétences en Java : http://www.business-on-rails.com/sites/1
A moins de considérer Eyeka / RBC Dexia IS /... comme des non pros :), il faudrait peut être accepter que développer en Rails leur a permis d'avancer beaucoup plus rapidement qu'une application en Java dite "pro" ...
Et même s'il y a un travail plus conséquent qu'en PHP pour la tenue en charge, cela reste plus simple et rapide à développer qu'une usine à gaz en J2EE. Le temps de dev c'est ce qui coûte le plus....
Coté IDE sort de ta grotte et regarde Eclipse / Aptana / Ruby In Steel (http://www.sapphiresteel.com/), etc.
Bref ya moins de buzz parce que l'étape du buzz est terminé et que l'on bosse avec Rails ...
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
Oué bah moi je dis justement que cette longueur d'avance diminue et va bientôt être complètement effacée. Dans le monde qui m'intéresse, le framework ASP.NET MVC Framework n'a pas grand chose à envier à Rails.
Le temps de dev c'est ce qui coûte le plus....
Grossière erreur :) Ca représente kedal le temps dev dans un projet. Le plus gros du boulot c'est la maintenance et les éventuelles évolutions (liées aux fonctionnalités ou à la montée en charge).
De plus il est à mes yeux pratiquement impossible de migrer rapidement et facilement des développeurs PHP en Java.
Faut savoir, une fois ca concurrence Java et pas PHP et là tu migres depuis PHP :) Soit. En Java je sais pas, par contre j'ai déjà eu l'occasion de migrer du PHP en ASP.NET, c'est pas compliqué. Que va m'apporter RoR en plus ?
Et même s'il y a un travail plus conséquent qu'en PHP pour la tenue en charge, cela reste plus simple et rapide à développer qu'une usine à gaz en J2EE.
Ah bon ? Nan parcque je connais aucune grosse architecture en RoR justement. Un truc qui tienne la charge et des millions d'utilisateurs.
Coté IDE sort de ta grotte et regarde Eclipse / Aptana / Ruby In Steel (http://www.sapphiresteel.com/), etc.
Comparé à l'écosystème Java... Moi je veux un IDE qui me permette de tout développer dans mon architecture n-tiers, de ma couche web (avec designer graphique) à la couche d'accès aux données en passant par la couche métier et les services. Le tout intégré, avec environnement de test, d'analyse de performance, gestion de version, etc. Nan parcque là à part la coloration syntaxique, la complétion et le débuggage... Ok c'est le minimum...
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
Je n'ai pas la prétention et l'envie de perdre du temps à convaincre un fan de C#/Mono/ASP :) Donc j'arrête avec ce post.
Grossière erreur :) Ca représente kedal le temps dev dans un projet. Le plus gros du boulot c'est la maintenance et les éventuelles évolutions (liées aux fonctionnalités ou à la montée en charge).
La difficulté de maintenance et d'évolution est liée à la difficulté du développement ... En Rails tu développes rapidement et de fait tu maintiens et fais évoluer ton appli aussi rapidement. Et même si ton modèle de données évolue tu génères un script de migration ...
Le développement par convention de Rails aide beaucoup à cela, ainsi que les tests unitaires, fonctionnel intégrés (cf http://2007.parisonrails.org/pdf/8-PoR2007-Jean-Michel_Garni(...)
Faut savoir, une fois ca concurrence Java et pas PHP et là tu migres depuis PHP :) Soit. En Java je sais pas, par contre j'ai déjà eu l'occasion de migrer du PHP en ASP.NET, c'est pas compliqué. Que va m'apporter RoR en plus ?
Rails n'a pour l'instant pas la prétention de concurrencer PHP sur du mutualisé, c'est à dire à destination du grand public.
Pour la multitude d'entreprises qui développent leurs outils en interne, ou qui destinent leur produit à une clientèle bien précise oui.
Rails ne va rien t'apporter de plus vu que tu es visiblement convaincu par tes technos. Perso je te dirais d'essayer Ruby et Rails mais je doute de ta partialité de jugement de toute manière.
Ah bon ? Nan parcque je connais aucune grosse architecture en RoR justement. Un truc qui tienne la charge et des millions d'utilisateurs.
Et c'est ton seul critère pour juger d'une techno ? J'ai passé l'âge de jouer à celui qui a la plus grosse :)
Twitter semble l'appli Rails se rapprocher le plus de cette description. De toute manière la tenue en charge et les millions de users importe peu à 99% des entreprises. Pour les autres qui ont cette prétention soit elles font un certain effort côté admin comme Twitter, soit elles utilisent autre chose.
Rails n'a pour l'instant pas la prétention de répondre à tous les besoins ...
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
Absoluement pas. La difficulté de maintenance et d'évolution vient plutôt des attentes des utilisateurs clients en terme de performance, de rapidité d'intervention en cas problème, de la conception en amont de la plateforme en ayant réfléchi à son "évolutivité", à son intégration éventuelle avec d'autres applications/middlewares, aux capacité de de montée en charge, etc.
Rails n'a pour l'instant pas la prétention de concurrencer PHP sur du mutualisé, c'est à dire à destination du grand public.
Voilà pourquoi entre autre Ruby ne s'est pas démocratisé comme prévu au près du grand public. L'absence d'acteur majeur est la raison pour laquelle Ruby ne s'est pas démocratisée dans les entreprises.
Perso je te dirais d'essayer Ruby et Rails mais je doute de ta partialité de jugement de toute manière.
Tu remarqueras que j'ai surtout comparé avec Java et PHP, et je peux t'assurer que je suis vraiment pas fan du 2ème :)
De toute manière la tenue en charge et les millions de users importe peu à 99% des entreprises.
En entreprise il peut y avoir d'autres sortes d'utilisateurs : des grosses applis internes (banques, assurances, etc.) qui demande des architectures N-tiers parfois avec de hautes performances.
Au final tu cantonnes toi même Ruby à un petit marché : les besoins internes des entreprises, mais qui n'ont pas trop de besoin quand même. Je rajouterai : et qui ont les compétences en interne.
[^] # Re: air de déjà vu
Posté par fredix . Évalué à 1.
Prévu par qui ? ah merde on est vendredi !
[^] # Re: air de déjà vu
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: air de déjà vu
Posté par Yusei (Mastodon) . Évalué à 2.
Vilain fredix, arrête de cantonner Ruby, s'il te plaît.
Rails facilite la maintenance et l'évolution de la même manière que le développement. Ses atouts qui rendent le développement rapide rendent également la maintenance et l'évolution relativement aisés. Je parle d'expérience, pour avoir dû gérer un projet dont le cahier des charges évoluait de jour en jour, de façon parfois drastique.
En fait, je dirais même que Rails est plutôt destiné aux projets qui ne sont pas bien définis ou qui vont beaucoup évoluer. De même que Ruby est surtout efficace pour prototyper rapidement une application, au détriment de la rapidité d'exécution.
En entreprise, il peut y avoir des besoins forts en termes de performance. Il peut aussi y avoir des besoins forts en terme de rapidité de développement et d'évolution. Qui a dit que les mêmes outils devaient servir dans tous les cas ?
Les cas où Rails est trop lent et où il est le facteur limitant sont relativement réduits: jusqu'à quelques centaines d'utilisateurs concurrents, un gros serveur bien configuré n'aura pas vraiment de mal. Un bon serveur a un coût négligeable pour une entreprise qui a plusieurs centaines d'utilisateurs concurrents. Et multiplier les serveurs est un bon moyen de monter en charge tout en améliorant la fiabilité. Alors, certes, gérer des millions d'utilisateurs concurrents (la précision est importante) est peut-être difficile en Rails, mais ça représente une portion infime des besoins des entreprises.
Je n'essaye pas de dire que Ruby et Rails sont des outils universels, mais je pense qu'il est vraiment simple d'identifier quand un projet sera trop lourd pour cet outil, et que dans les autres cas, lorsque c'est possible, on gagne à l'utiliser.
# Et le plaisir de coder dans tout ca ?
Posté par sooli . Évalué à 2.
Donc je ne suis pas prêt à l'abandonner... même si on est pas nombreux à l'utiliser en France, je continu dans cette voix.
Je n'ai pas eu a gérer de trop gros sites. Mon plus gros fait dans les 5000 visiteurs/jour. Et avec une bonne gestion du cache, pas de soucis avec 10 process mongrel le tout balancé par un Nginx.
J'ai développé en Java, C, C++, C#, PHP et RUBY...
# .
Posté par ccomb (site web personnel) . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.