Pour ceux qui ne connaîtraient pas encore 'Ruby on rails' ('RoR' pour les intimes), il s'agit d'un framework de développement d'applications Web en Ruby, qui permet de développer des applications Web évoluées très rapidement, en écrivant très peu de code.
Il est basé sur le modèle MVC, et supporte la technologie AJAX, les SGBD SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server, et inclut même son propre serveur web, nommé WEBrick, permettant de développer et tester son application directement sans avoir à installer de serveur web.
La première version de Ruby on Rails date de juillet 2004, et il a bien évolué depuis. Il a changé le monde des développeurs d'applications web, en permettant d'écrire des applications AJAX et des sites utilisant des bases de données, sans écrire une seule ligne de SQL ou de JavaScript. La première version majeure d'un logiciel est toujours une étape importante, montrant que celui-ci gagne en maturité, et que ses concepteurs le jugent prêt à être utilisé. Espérons qu'il en sera ainsi pour RoR, et que les hébergeurs web commenceront à s'intéresser à cette alternative très crédible au fameux PHP.
Aller plus loin
- Site officiel (2 clics)
- Téléchargement (0 clic)
- Vidéos de présentation (0 clic)
- Wiki français sur Ruby (2 clics)
- Site de la communauté francophone des utilisateurs de RoR (6 clics)
# Système d'authentification
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 6.
Ca inclut une interface d'admin, un système facile pour choisir l'algo pour le chiffrage des mot de passe, etc.
# Quelques remarques
Posté par Anonyme . Évalué à 9.
En l'occurence il existe déjà pas mal d'applications basées sur les versions antérieures de Rails. Aussi bien commerciales (Odeo, Basecamp, etc.) que libres (le système de weblog Typo, Collaboa, un outil proche de Trac, etc.).
Vous trouverez une liste plus complète sur le site officiel : http://rubyonrails.org/applications
Je dirais même que c'est une alternative plus que crédible. Malheureusement pour l'instant il n'y a qu'un seul hébergeur français qui propose Rails : Typhon. J'espère que d'autres feront de même !
La liste des hébergeurs proposant Rails sur le site officiel : http://wiki.rubyonrails.com/rails/pages/RailsWebHosts
[^] # Re: Quelques remarques
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Quelques remarques
Posté par Éric (site web personnel) . Évalué à 3.
# Ruby, c'est cool
Posté par Anonyme . Évalué à 9.
Tout est basé sur les capacités de ruby, allie de manière étonnante l'expressivité du perl et des vrais langages objets, avec quelques astuces en plus.
Du bonheur !
[^] # Re: Ruby, c'est cool
Posté par Fabimaru (site web personnel) . Évalué à 2.
Sinon, ça donne quoi point de vue perfs ? Ca tourne vraiment en multi-thread (pas comme python/zope avec son lock global pour l'interpréteur) ?
[^] # Re: Ruby, c'est cool
Posté par Guillaume DESRAT . Évalué à 4.
Sisi, je vous le jure ;-)
Honnêtement, il y a quelques hébergeurs qui commencent à le proposer, et c'est djà pas mal pour une technologie qui n'est en version 1.0 que depuis hier, non ?
[^] # Re: Ruby, c'est cool
Posté par Luc Stepniewski (site web personnel) . Évalué à 4.
Pour le Global Lock (GIL) de Python, d'habitude ce n'est vraiment pas un problème. La plupart des applis se découpent très facilement en différents services (et c'est plus propre). Certaines applis (Twisted pour n'en citer qu'un exemple) n'utilisent pas du tout les threads, et ça fonctionne très bien et c'est super rapide.
[^] # Re: Ruby, c'est cool
Posté par Olivier Grisel (site web personnel) . Évalué à 0.
# re
Posté par Sylvain (site web personnel) . Évalué à 1.
import "rubygems"
Sinon ca a l'air tres pythoniens comme langage mais je goure peut etre =)
[^] # Re: re
Posté par Brice2Nice . Évalué à 3.
(allez moinsser on peut pas donner son avie perso ici, il y a un karma moutonesque)
[^] # Re: re
Posté par Nicolas Évrard (site web personnel) . Évalué à 7.
Pour que ce soit objectif, il faudrait que ce soit mieux que ton avis. Un truc argumenté, réfléchi, pensé. Deux lignes c'est un peu court.
Et puis si tu veux lancer un troll, je te conseille franchement de prendre exemple sur les grands anciens (L. Torvalds, pour parler du plus récent), leur troll, ça a de la gueule, le tien il est tout pourri.
Je ne sais pas tu aurais pu dire:
Bon là je crois que j'ai fait le tour (je m'apperçois que j'ai oublié le TCE, les news cinéma, ... , mais j'ai la flemme de les ajouter).
[^] # Re: re
Posté par kang . Évalué à 2.
Sinon, Python vs Ruby, ca se vaut sur beaucoups de points.
Finalement, pourquoi les gens aiment t-il ruby ?
=> A cause de ruby on rails
Pourquoi ruby on rails ?
=> Parce que ca sonne bien, avec du AJAX dedans, le site est joli et y a une demo avec textmate sous OSX en video.
C'est aussi con que ca. Marketing quand tu nous tiens.. (et oui, même dans le libre :)
[^] # Re: re
Posté par Éric (site web personnel) . Évalué à 10.
Ca vient du perl, c'est indéniable et il y a encore des restes. Par contre de là à dire que la syntaxe est un peu comme perl ....
Je n'aime pas perl, j'ai toujours trouvé ça illisible. Ruby n'a pour moi rien à voir.
> Finalement, pourquoi les gens aiment t-il ruby ?
> Pourquoi ruby on rails ?
> C'est aussi con que ca.
C'est super réducteur et AMHA en large parti faux.
Certes si on en parle c'est à cause de Rails. Si on parle de Rails c'est qu'ils ont eu la bonne idée de mettre à dispo des outils pour ajax et des vidéos d'introduction. Mais tout ça ne fait qu'attirer les gens à regarder.
Derrière si après avoir regardé les gens continuent d'en penser du bien c'est qu'il y a un bon fond :
- le langage est tout à fait dans la mouvance python : moderne, portable, objet, dynamique, facilement lisible. Personnellement j'adore le système des blocs, c'est ce qu'il m'a toujours manqué dans les autres langages de script. Le code m'a l'air très lisible (plus que du PHP ou du Python). Les possibilités de dynamismes sont aussi énormes si on regarde coté maintenance ou extensibilité. Pour exemple le langage ne gère pas les classes abstraites. Il m'a fallu quelques heures et une centaines de lignes pour rajouter ça, alors que j'ai encore assez peu d'expérience dans ruby. Je ne me verrai faire ça avec aucun autre langage que j'ai exploré.
- Rails lui a pas mal d'avantages. Il est extrêment simple à aborder au début et automatise complètement les "80%" des projets habituels. ActiveRecord est une vrai merveille pour ça. Franchement du coté simplicité et "voici mon application en 1 mois avec très très peu de code" je ne vois aucun concurrent réel. Le seul qui peut à peu près suivre c'est Django. Le framework ne couvre pas tous les besoins, n'est pas parfait (personnellement le déteste les limitations des routes), mais couvre un réel besoin. Et pour remplir ce besoin, il est largement en avance sur tout ce qui se fait ailleurs.
Il y a pas mal de buzz, c'est le buzz qui fait qu'on en parle. Mais si le buzz continue et que les technos retiennent l'attention c'est pour leurs qualité, pas pour le buzz qu'il y a autour.
[^] # Re: re
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Je trouvais ce graphique assez bien fouttu ! et je pense que ror est dans le haut de la vague.. On va attendre que ca retombre pour voir.
http://about.me/straumat
[^] # Re: re
Posté par Guillaume DESRAT . Évalué à 2.
Plus sérieusement, sur la liste de Rails France, il y a toujours une solution de proposée quand un problème survient.
[^] # Tant que tu y es...
Posté par Arthur Accroc . Évalué à 2.
Si jamais en quelques heures de plus tu ajoutais de (vrais) destructeurs, je me remettrais probablement à Ruby...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Tant que tu y es...
Posté par Éric (site web personnel) . Évalué à 2.
(pour ceux qui ne connaissent pas la question des destructeurs/finaliseurs dans ruby : voir "Where's the destructor?" dans http://www.rubygarden.org/ruby?GCAndMemoryManagement )
As tu tant besoin des destructeurs que ça ? (je sais, j'évite la question à laquelle je n'ai pas de réponse).
Le système de bloc répond à une partie des problématiques (exemple l'implémentation de File.open(...) { .... } qui automatise la cloture du fichier)
Dans ce qui reste le plus souvent ce sont des lignes de log ou des fermetures de connexion. Les finaliseurs de ruby ont certes une syntaxe dérangeantes mais permettent de faire le travail dans ces cas simples et clairement identifiables.
Quels sont les besoins que tu as vis à vis des destructeurs et qui ne sont pas recoupés ? (je ne les remet pas en cause, je suis juste curieux)
[^] # Destructeurs
Posté par Arthur Accroc . Évalué à 4.
J'en avais eu une : créer une classe de base dont le constructeur crée un finaliseur appelant une méthode considérée comme le destructeur, méthode à redéfinir sur les classes dérivées.
Seulement d'une part, le moment et l'ordre de la destruction des objets ne pourrait être garanti. Au passage, pour moi, ça démontre clairement que la gestion de la mémoire par un garbage collector est une erreur : un choix d'implémentation qui t'empêche d'implémenter un concept du paradigme, c'est un très mauvais choix.
D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
Là, je ne vois pas ce qui obligeait à une telle aberration...
D'un point de vue plus général, comment quelqu'un qui a fait un langage aussi génial par ailleurs a-t-il pu autant saloper la question des destructeurs ? Ruby, ça me fait penser à une Ferrari avec une roue carrée !
Que répondre ?
Tu pourras me démontrer que je peux m'en passer, tout comme les avocats des langages qui ne supportent pas l'héritage multiple ont démontré qu'on pouvait s'en passer.
Seulement il y a une démonstration scientifique comme quoi on peut tout programmer avec juste une machine de Turing et il est empiriquement évident qu'on peut tout faire en assembleur. Ça ne me donnera pas envie pour autant de faire mes programmes avec une machine de Turing ou en assembleur...
Pour citer Matz :
Above all, you can't enjoy programming with much stress.
Là, je suis parfaitement d'accord avec lui,
Ruby's true motto is "Enjoy programming".
mais moi, je ne peux pas "enjoy programming" avec la complication de devoir contourner l'absence de destructeurs avec des méthodes plus lourdes ou plus moches.
Oui, mais cela ne se fait pas au même niveau : cela doit être fait au niveau de l'utilisation de la classe et pas seulement au niveau de sa définition comme les destructeurs.
Si tu programmes ta classe, que tu commences à l'utiliser un peu partout, et qu'à ce moment-là, tu te rends compte qu'il faudrait que tu fasses un traitement après l'utilisation des objets, eh bien avec les blocs, tu es cuit, il faut que tu modifies toutes les utilisations de ta classe !
D'un autre côté, si c'est pour avoir au bout du compte un programme moche, je n'ai pas d'intérêt à passer à Ruby, je reste à Perl. Au moins avec Perl, c'est la syntaxe du langage qui est moche, pas la conception de tes programmes (ou alors c'est entièrement ta faute, le langage ne t'impose pas une conception sale).
Au niveau des concepts de programmation, Perl m'a permis de continuer à faire tout ce que je faisais avant avec d'autres langages. J'attends encore de trouver un langage qui me permette de faire tout ce que je fais maintenant avec Perl...
Cela dit, je m'inquiète un peu pour Perl 6, qui devrait utiliser un garbage collector plutôt qu'un compteur de références. Si, comme je le crains, ça implique la destruction des destructeurs, je me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon goût.
Je ne sais même plus. Quand j'avais découvert Ruby, je m'étais jeté dessus (un truc (qui m'apparaissait) aussi puissant que Perl, mais en joli !) en commençant à programmer avec le premier truc pas trop gros (mais pas trop petit non plus, quelques centaines de lignes, quoi) dont j'ai pu avoir l'utilité.
Arrivé à un moment, je me dis "Tiens, il faut que je fasse un traitement à la destruction des objets de telle classe", mais, m'apprêtant à ajouter un destructeur, j'ai un curieux trou de mémoire sur la syntaxe des destructeurs... et là, je dois faire des recherches un peu poussées... pour finalement découvrir la merde de chat sous le tapis.
Conclusion, j'ai fini mon programme en ajoutant une méthode et en l'appelant explicitement partout où c'était nécessaire, j'ai ensuite passé du temps à essayer de programmer des destructeurs en Ruby, et puis quand j'ai vu que ce n'était pas possible, j'ai abandonné la programmation en Ruby.
Parmi les langages informatiques, Ruby est ma plus grande déception.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par Éric (site web personnel) . Évalué à 2.
> finaliseur appelant une méthode considérée comme le destructeur,
> méthode à redéfinir sur les classes dérivées.
Oui, mais le problème concret c'est que ton finaliseur doit recevoir des paramètres (l'objet étant détruit il faut sauvegarder un contexte avant pour pouvoir se rappeler des valeur utiles). Or un système automatique ne pourra pas savoir de quelles noms d'attributs tu auras potentiellement besoin.
> D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
> Là, je ne vois pas ce qui obligeait à une telle aberration...
C'est volontaire d'après ce que j'ai lu.
L'idée c'est :
- d'empêcher toute possibilité pour l'utilisateur de poser une référence de l'objet dans une variable externe (variable globale par exemple) pendant la destruction. Ca causerait très vite des "oops". D'après ce que j'ai lu ce problème existe en java (je n'ai pas vérifié).
- de limiter très fortement les destructeurs pour décourager les gens de les utiliser (partant du principe que la plupart des utilisations courantes sont des erreurs).
Le premier point est un choix que je peux comprendre mais c'est ce qui amène la "bizarrerie" des finaliseurs ruby. Le second point est pour moi une ahération (rendre volontairement complexe quelque chose n'a jamais été une bonne idée).
> Que répondre ?
> Tu pourras me démontrer que je peux m'en passer
Ce n'était pas mon but. C'était une vrai question, poussée par la curiosité.
> Si, comme je le crains, ça implique la destruction des destructeurs, je
> me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon
> goût.
Je peux me tromper mais de mémoire python c'est un gc aussi, pas un compteur de ref.
[^] # Re: Destructeurs
Posté par Troy McClure (site web personnel) . Évalué à 2.
http://www.python.org/doc/2.3.5/ext/refcountsInPython.html
[^] # Re: Destructeurs
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
Donc je suis d'accord sur tout ton message (sauf que je suis pas encore deçu de Ruby, c'est juste un choix qui m'emmerde).
[^] # Re: re
Posté par Frederick Ros . Évalué à 3.
=> A cause de ruby on rails
Generalement les gens aiment Ruby pour Ruby .. Certes Rails a donne un coup de boost a Ruby (ou du moins a l'eclairage "mediatique"), mais nbon .. j'ai commence Ruby alors que Rails n'existait pas .. et j'ai aime Ruby pour sa syntaxe claire et concise ... entre autre
Pourquoi ruby on rails ?
=> Parce que ca sonne bien, avec du AJAX dedans, le site est joli et y a une demo avec textmate sous OSX en video.
Hum .. certes ils sont tres forts cote marketing ... mais c'est bien plus que cela ... Developper une appli avec Rails c'est vraiment amusant ... et c'est pour cela que les gens aiment Rails
[^] # Re: re
Posté par DPhil (site web personnel) . Évalué à 5.
Ou n'aime pas Ruby à cause de Ruby.
[^] # Re: re
Posté par gc (site web personnel) . Évalué à 9.
=> A cause de ruby on rails
Kof kof kof ! C'est presque une insulte pour tous ceux qui connaissaient/utilisaient/appréciaient ruby bien avant que rails n'existe.
Rails a le tort de faire voir ruby comme un langage dédié au web pour beaucoup qui le découvrent aujourd'hui.
[^] # Re: re
Posté par fredix . Évalué à 3.
Ah ce n'est pas un langage dédié à GTK+ ? :D
En fait tout dépend de comment on est positionné. Il y a certainement plus de développeur web que GTK+, donc l'aspect web de Ruby via RoR est tout simplement plus visible.
Ruby fait partie de ces langages haut niveau qui permettent de développer aussi bien un site web, qu'une interface graphique ou un script système. Au même titre que python voir perl.
Et l'avenir est bien là je pense, n'avoir à connaitre qu'un seul langage pour faire tout type de programme.
[^] # Re: re
Posté par Erwan . Évalué à 5.
A part ca, au Japon Ruby est plus populaire que Perl et Python. Ce qui a freine son essort hors du Japon, c'est que la doc en anglais est arrivee tres tard et Python a eu le temps de s'installer un peu partout.
[^] # Re: re
Posté par reno . Évalué à 0.
Cela me fait douter de la qualité de la modération..
Juste pour ajouter mon vote: je déteste la syntaxe de Perl (qui encourage à écrire n'importe comment) mais j'aime bien celle de Ruby, encore qu'elle soit loin d'être parfaite à mon avis: déclaration automatique des variables (je me souviens qu'avec un outil ils ont trouvé des variables inutiles dans les librairies de base de Ruby, quelle surprise, une déclaration des variables comme dans Limbo serait plus élégant..), évolution vers une syntaxe de moins en moins simple à mon avis.
Et non RoR ne m'intérresse pas.
[^] # Re: re
Posté par Guillaume DESRAT . Évalué à 1.
"Finalement, pourquoi les gens aiment-ils Ruby ?"
J'ai découvert Ruby grâce à un copain (coucou Maz (sans "t" hein !)) fin Mars 2002, et la même personne m'a conseillé de jeter un coup d'oeil à RoR il y a de cela deux mois et quelques.
Entre temps, je te rassure, sans connaître RoR, je me suis régaler avec Ruby.
Donc ta première affirmation est douteuse.
"Pourquoi Ruby on Rails ?"
Tout simplement parce que d'une part, lorsqu'on aime bien un langage, on a envie de l'utiliser partout, et d'autre part parce qu'après avoir regardé d'un peu plus près, force est de constater que c'est bien pensé !
C'est vrai que le site est joli (surtout depuis la 1.0), les vidéos sous OSX avec Textmate en mettent plein la vue (mais elles se montrent d'excellents exemples !), et c'est vrai qu'il y a AJAX.
Même si c'est sympa d'avoir AJAX avec RoR, ce n'est pas ça qui fait l'intérêt du framework ! C'est en bonus ! Rien ne t'empêche de "faire de l'AJAX" avec PHP et prototype.js...
Bref, Ruby j'aime (gem), RoR aussi, et je pense que l'un comme l'autre mérite qu'on s'y intéresse, sans avoir d'a priori ou un esprit réducteur comme certains...
[^] # Y'a pas que RoR dans Ruby
Posté par Maz (site web personnel) . Évalué à 1.
Y'a une jolie vidéo pour GTK+ et GTKMozEmbed aussi, y'a pas que RoR qui fait du marketing
http://ruby-gnome2.sourceforge.jp/hiki.cgi?RubyZilla
Sinon, avec moins de buzz, de notable :
En dev web, Nitro
http://www.nitrohq.com/
Alexandria
http://alexandria.rubyforge.org/
C'est tout ce dont je me rappelle comme ça de tête, mais il y a surement pas mal d'autres choses.
[^] # Re: re
Posté par Yusei (Mastodon) . Évalué à 5.
Moi j'aime Ruby parce qu'il a su conjuguer le meilleur de la programmation objet, des langages de bricoleurs comme Perl, et de la programmation fonctionnelle.
[^] # Re: re
Posté par Frederick Ros . Évalué à -1.
Pas d'insulte s'il te plait !! ;) :) ;) ;)
[^] # Re: re
Posté par TNorth . Évalué à 1.
[^] # Python on rails ?
Posté par Nimlar . Évalué à 2.
http://linuxfr.org/~manatlan/19618.html
J'y ai fait de belle découverte.
[^] # Re: re
Posté par Éric (site web personnel) . Évalué à 3.
Les idées et concepts sont assez proches, mais je ne sais pas s'ils ont intégré autant d'outils javascript/ajax
[^] # Re: et TurboGears?
Posté par Luc Stepniewski (site web personnel) . Évalué à 4.
TurboGears a *aussi* un screencast (http://www.turbogears.org/docs/wiki20/20MinuteWiki.mov ) de démonstration.
[^] # Re: re
Posté par gc (site web personnel) . Évalué à 2.
je sais pas trop, moi j'aime pas du tout python et pourtant j'adore ruby. ruby est plus perlien (utilisation des regexp) et a des fonctions anonymes a la coule.
# SGBD
Posté par Philippe Makowski (site web personnel) . Évalué à 5.
et Firebird !
[^] # Re: SGBD
Posté par Philippe F (site web personnel) . Évalué à 1.
---> []
[^] # Re: SGBD
Posté par Papey . Évalué à 10.
# Présentation en français
Posté par Yann KLIS (site web personnel) . Évalué à 6.
http://strasslab.net/blog/depot/Rails.pdf
Et pour rappeler le contexte:
http://strasslab.net/blog/index.php?2005/10/28/98-mini-conf-(...)
http://strasslab.net/blog/index.php?2005/11/10/101-retour-su(...)
# Ruby/Java etc
Posté par Jean Parpaillon (site web personnel) . Évalué à 1.
Est-ce que quelqu'un pourrait résumer les avantages/inconvénients de Ruby Rails par rapport à Java/Struts (sans troller, SVP ;-) ?
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Ruby/Java etc
Posté par Vincent Behar . Évalué à 3.
et pas de configuration (ou trés trés peu, juste le login/password/type de la base de données)
prends quelques minutes pour regarder les vidéos, ce sera beaucoup plus efficace que l'avis de quelqu'un que tu ne connais pas...
[^] # Re: Ruby/Java etc
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Rien que ta question peut etre discutée.. je trouve struts horrible :D je préfère jsf et d'autres te diront que wicket est mieux.
Java, c le best of breed, chacun compose sa plateforme. Nous perso, c Hibernate + Spring + JSF + JOnAS.
Si je voulais fais des petites applis, ROR est pas mal mais je prendrais Java Studio Creator et j'irais aussi vite qu'avec ROR sans avoir les limitations (AOP, mapping O/R, drivers db manquants, JMS, JTA, interface riches, RMI...)
http://about.me/straumat
[^] # Re: Ruby/Java etc
Posté par bengali . Évalué à 7.
D'autant +, que les frameworks Web frameworks Web en Java (MVC et évenementiels avec composants) sont légion et contribuent à dérouter les newbies dans leur choix.
S'il faut attendre que le débutant maîtrise hibernate + Spring, + un framework Web + un conteneur Web + un IDE pour produire une application Web qui fait du CRUD et bien bonjour sa productivité.
Avec ROR, la couche persistance (active records), les contrôleurs et le modèle sont parfaitement intégrés et tu ne retrouves pas avec une multitude de fichiers XML (même si les annotations Java5 ou Xdoclet ont permis d'en réduire le nombre mais dans le même temps compliquent le build).
Le tout est facile à tester (pas de redémarrage du serveur) et déployer (copie de fichiers sans packaging à la WAR, EAR,etc.).
Spring a fait un bien énorme en simplifiant l'utilisation de "technos" JEE mais difficile de retrouver la simplicité de ROR. Ceci dit Java et son "écosystème" est une valeur sûre et éprouvée côté serveur. Pour ROR, je ne l'ai pas encore vu à l'oeuvre en entreprise...
[^] # Re: Ruby/Java etc
Posté par pvincent . Évalué à 2.
Je rajoute aussi qq arguments toujours imbattables : eclipse et le refactoring.
Allez, j'en rajoute un dernier : le côté pédagogique/universitaire qui fait bien dans les écoles d'ingé ou de Dess
Cependant Java a malgré tout des défauts qui font tâche et je vous en résume qqs uns :
- la complexité de la version 1.5 avec les generics, enums, annotations. Au final, la lecture de l'API devient vraiment barbare pour un néophyte.
En face, Ruby modèle de langage pur objet, magnifiquement pensé (a la smalltalk) , une cohérence, une finesse dans la structure.
Bref, c'est beau -> pour une vraie pédagogie objet, Ruby est un candidat sérieux et en plus il n'est pas élitiste, lui !
- eclipse logiciel libre et la JVM de Sun pas libre : tout le monde sait que Sun n'aime pas le logiciel Eclipse et qu'il fait tout pour lui barrer la route ; un jour IBM derrière le consortium OTI en aura vraiment marre. Clash en perspective (mais j'espère me tromper). Mais bon le refactoring saura en sortir vainqueur de toute facon.
- le côté entreprise pertube toujours l'innovation. J2EE a mis je ne sais combien de temps à devenir + ou - potable (allez que je te remets une petite couche de XML) mais était vendu malgré tout sous couvert de gros arguments marketing. Bref, on se retrouve avec des vieilles versions de pseudo-J2EE Oracle, IBM ou autre vendu hyper méga-cher pour rien et ca fait mal d'expliquer que Java c'est bien quand même...même si on peut tout jeter et recommencer avec un Jonas/Tomcat
En conclusion, ca me rappelle beaucoup la théorie de la cathédrale (Java) et le bazar.
Pour l'instant je n'irais pas jusqu'à dire que le bazar est incarné par Ruby. Il faut avouer que dans le secteur : PHP reprèsente mieux le bazar suivi à qq encamblures par Python. Mais bon, c'est peut-être justement trop le bazar.
Ruby c'est le juste milieu, un bazar cohérent.
[^] # Re: Ruby/Java etc
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Ruby/Java etc
Posté par Éric (site web personnel) . Évalué à 5.
Même pour les non débutants. Le ticket d'entrée est très élévé (architectures complexes et grand nombre de couches/classes même pour faire des choses simples).
Si tu n'as pas besoin de choses poussées à l'extrême, c'est souvent beaucoup de gachi. Et en pratique coté Web on n'a pas si souvent besoin de choses aussi poussées, on peut le plus souvent se contenter de ce qu'il y a de plus simple. Oui, même en entreprise (surtout en entreprise d'ailleurs, vu que c'est là que le critère "coût" est important)
Ruby on rails (mais aussi PHP) privilégie la possibilité de faire les 80% simplement sans perdre du temps ou ajouter de la complexité. Java et permet d'attendre les 20% derrière sans surcout, mais simplement parce que la complexité tu l'as déjà mise en oeuvre pour les premiers 80%.
[^] # Re: Ruby/Java etc
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Quand aux couches, si elles ajoutent de la complexité, elle permette aussi une flexibilité importante et une économie de code. Sur le long terme, c'est beaucoup plus rentable et je sais de quoi je parle, j'étais développeru delphi à la base ;)
http://about.me/straumat
[^] # Re: Ruby/Java etc
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Maintenant si tu veux faire un truc rapide et vite fait (crud), essaye java studio creator ou JBuilder, tu auras la même chose.
http://about.me/straumat
[^] # Re: Ruby/Java etc
Posté par Anonyme . Évalué à 9.
[^] # Re: Ruby/Java etc
Posté par gc (site web personnel) . Évalué à 2.
[1] c'est très résumé
[^] # Re: Ruby/Java etc
Posté par Al_trent . Évalué à 2.
Les avantages de java:
- bibliotheque impressionnante. Je peux générer des PDFs (jasperrepports), des documents word ou autre (openoffice controllé par Java). De plus JSF (myfaces) est fournie avec quelques composants sympa (calendrier Web), et va recevoir 100+ composants d'Oracle tres bientot. :)
- systeme d'i18n bien rodé
- Java est stable et tient la charge coté serveur.
Les inconvenients:
- c'est lourd.. faut pisser pas mal de code pour ne faire qu'une seule page web...
- le cycle compiler/deployer prend du temps...
RoR me parrait tres bien, mais ne repond pas encore totalement a mes besoins (surtout de reporting), donc pourquoi pas dans 1 an ou plus...
# Hébergement Rails
Posté par Anonyme . Évalué à 4.
Du côté des Etats-Unis, il semblerait que TextDrive (http://textdrive.com/ ) ait des gros problèmes de stabilité (même si c'est l'hébergeur "officiel" de Rails). J'ai également vu Planet Argon (http://planetargon.com/ ), qui me semble pas mal, avec un bon compris entre services et tarifs.
Si quelqu'un a des retours d'expérience à ce niveau, je suis preneur.
[^] # Re: Hébergement Rails
Posté par Yann KLIS (site web personnel) . Évalué à 1.
1. c'est le prix à payer pour avoir du Rails
2. c'est le prix de la qualité (enfin, on peut l'espérer)
[^] # Re: Hébergement Rails
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
[^] # Re: Hébergement Rails
Posté par Florent Bayle (site web personnel) . Évalué à 4.
Donc, comme dirait mon maître spirituel :
[^] # Re: Hébergement Rails
Posté par chl (site web personnel) . Évalué à 2.
# A propos de la vidéo
Posté par Uld (site web personnel) . Évalué à 2.
[^] # Re: A propos de la vidéo
Posté par underflow . Évalué à 3.
http://cocoamysql.sourceforge.net/
Et l'éditeur de texte est TextMate
http://macromates.com
[^] # Re: A propos de la vidéo
Posté par Uld (site web personnel) . Évalué à 2.
Quels équivalents performants conseillez vous sous gnu/linux?
[^] # Re: A propos de la vidéo
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
http://dev.mysql.com/downloads/query-browser/1.1.html
Libre, multi plateformes, des packages partout. Seul défaut: tendance a planter de temps en temps, comme ca.
# livre
Posté par Guillaume D. . Évalué à 1.
Agile Web Development with Rails
(anglais juin 2005 rails 1.0 / 550 pages / 26 euros chez amazon.fr)
- un tutorial boutique online complete (avec admin et tout) (170 pages)
- Rails en profondeur (+ajax + securite) (300 pages)
- Ruby en condensé 20 pages
- Code source (40 pages)
a+
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.