Articles précédents : Logiciel
- [17] OpenERP : la gestion d'entreprise libre
- [9] PlayOnLinux version 3.0 (Arietis) disponible
- [9] GCstar 1.4.0 est disponible
- [51] Calcul scientifique : Scilab 5 enfin libre
- [26] SMILE : Renaissance d'un projet
- [18] La Poule ou l'oeuf : le livre-application
- [3] SMI : Une gestion de SAV complète
- [9] Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias
- [22] La forge logicielle LibreSource passe sous GPL
- [13] Astitray : déclencher un appel sur un téléphone SIP avec une applet
Liens connexes
- Ruby on Rails (738 hits)
- L'annonce sur le blog RoR (285 hits)
- Lighthouse (836 hits)
- GitHub (529 hits)
- Explication des nouveautés (467 hits)
- Screencasts (539 hits)
Dépêche modérée par
Dépêche éditée par
Cette version marque le passage du dépôt de développement sur GitHub en lieu et place du dépôt SVN, ainsi que la gestion de projet sur Lighthouse au lieu de Trac.
Cela a permis, selon l'équipe de développement, une meilleure contribution au projet avec plus de 1600 patchs provenant de 1400 contributeurs différents.
![[en]](../../../images/en.png)
Ruby on Rails (738 hits)-
L'annonce sur le blog RoR (285 hits)
-
Lighthouse (836 hits)
-
GitHub (529 hits)
-
Explication des nouveautés (467 hits)
-
Screencasts (539 hits)
> Lire la suite (63 commentaires, moyenne: 2,8). [dépêche : 3507 caractères]
- Gestion des fuseaux horaires:
Cela permet plus facilement à une application de personnaliser par utilisateur le fuseau horaire des enregistrements en base. Pour cela il suffit de sauvegarder les enregistrements en UTC (Temps universel coordonné) et une variable globale à l'application "Time.zone" change à la volée le fuseau horaire lors de l'affichage des variables.
- Dirty Tracking (mis à jour partielle):
ActiveRecord subit une évolution importante et remarquée, on peut enfin détecter les changements d'un modèle lors d'une mise à jour (par un formulaire par exemple). Cela permet de connaître facilement dans le code l'ancienne et la nouvelle valeur d'un champ précis seulement si celui-ci a changé et n'est pas encore sauvegardé.
- Périmètre nommé (named scope):
Sans doute LA grosse nouveauté de cette version, la fonction recherche (select) d'ActiveRecord devient extensible à l'infini. C'est en fait le plugin has_finder qui est inclus dans ActiveRecord et permet de définir des méthodes qui ajoutent à la volée des conditions à la requête SQL générée, avec possibilité de les imbriquer.
Un exemple vaut mieux qu'un long discours:
class User < ActiveRecord::Base
named_scope :active, :conditions => {:active => true}
named_scope :inactive, :conditions => {:active => false}
named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end
# Usage standard
User.active # pareil que User.find(:all, :conditions => {:active => true})
User.inactive # pareil que User.find(:all, :conditions => {:active => false})
User.recent # pareil que User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
# Imbrication possible
User.active.recent
# pareil que:
# User.with_scope(:conditions => {:active => true}) do
# User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
# end
- Migrations basée sur une référence temporelle:
En travail collaboratif, la gestion des migrations (script qui permet de faire évoluer le schéma de la base en ajoutant/modifiant/supprimant table, colonne, index, ...) avec un compteur incrémenté devenait rapidement un calvaire: si 2 personnes faisait une migration avant leur prochain commit, les migrations avaient le même numéro. Maintenant, un timestamp (référence temporelle) est utilisée pour le nommage des migrations afin d'éviter toute "collision".
- Dépendances des Gem (paquets ruby):
On peut maintenant configurer la liste des paquets Gem requis pour l'application avec une version exacte ou minimale requise. Une nouvelle tâche à la commande "rake" permet d'installer les paquets manquants ou de les mettre à jour si besoin:
rake gems:install - Meilleure mise en cache:
C'est essentiellement la flexibilité de la mise en cache qui a été améliorée, on peut dorénavant facilement implémenter une nouvelle classe de gestion de cache personnalisée et l'utiliser dans les vues.
Pour installer cette version:
gem install railsou
gem update railsou par Git:
git clone git://github.com/rails/rails.gitJe vous conseille ardemment les screencasts de RailsCasts qui sont une mine d'or d'astuces et de bonnes pratiques.
Lighthouse
J'avais jamais entendu parler de Lighthouse, mais ça me laisse un peu perplexe. Sans présumer de la qualité de l'outil fourni, ce genre de site fournissant des services (payants, même si l'entrée de gamme est gratuite) ne me semblent pas franchement dans l'esprit du libre. M'étonnerait qu'il soit possible de télécharger leur code source.
C'est malheureusement le cas de pas mal de projets tournant autour de Rails, dans la lignée des services proposés par 37signals. Non pas que ce genre de services est mauvais en soit, mais baser le développement d'un projet libre sur ce type d'outils, ça me fait un peu penser à la période Bitkeeper du noyau Linux.
Je précise que j'utilise (un peu) et apprécie (beaucoup) à la fois ruby et Rails.
-
[+] [^]Re: Lighthouse
Posté par freeflight00 () le 03/06/2008 à 15:59. (lien). Évalué à -6.Parce que Rails est libre mais aussi et surtout un framework efficace, intelligent, né d'un besoin et évoluant rapidement depuis 2004.
Ne pas s'arrêter qu'à des considérations purement libre/pas libre sur les outils utilisés (MacOs, git, lighthouse, nginx, apache, github...) à permis à l'équipe de 37signals de développer un framework mature sans trainer de vieilles casseroles (parce qu'ils n'ont pas que cela à faire, et la communauté non plus...).
Bref, le libre c'est bien, mais lorsque d'autres modèles (ici l'utilisation de webapps) remplissent les besoins des développeurs, je pense qu'il est de bon ton d'arreter de perdre son temps à tergiverser/debattre sur l'emploi de tel ou tel outil...-
[^]Re: Lighthouse
Posté par TeXitoi (Jabber id, page perso, ) le 03/06/2008 à 16:10. (lien). Évalué à 9.Ba, quand même, en terme de périnité, c'est pas top : le jour où lighthouse dit «maintenant, c'est payant, si vous payez pas, on vous enleve votre compte», tout les rapports sont perdus. Je pense que c'est pire que l'histoire BitKeeper, parce que perdre des rapports de bugs, c'est quand même différent de changer d'outils de gestion de version.
On remarquera que c'est pareil avec launchpad.-
[^]Re: Lighthouse
Posté par freeflight00 () le 03/06/2008 à 16:21. (lien). Évalué à 3.Oui sauf que Lighthouse est déjà payant. Et que c'est une boite tout à fait serieuse qui existe depuis un moment, qui bosse avec de très gros acteurs.
Ce que je trouve dommage, au delà du fait que mon commentaire précédent est déjà presque "invisible" et qu'il en devient difficile d'avoir une visibilité dès lors qu'on ne sort pas les blagues de potaches du monde du libre et qu'on ne prône pas sans arret que le libre vaincra....
J'insiste mais libre ne veut absolument pas dire pérenne. Le jour ou un serveur crash par manque de moyen, la problématique est la même.
Merci d'éviter de croire que seul le tout libre est synonyme de bon choix stratégiques.-
[^]Re: Lighthouse
Posté par Earered () le 03/06/2008 à 17:12. (lien). Évalué à 6.>Et que c'est une boite tout à fait serieuse qui existe depuis un moment, qui bosse avec de très gros acteurs.
Comme Mosanto, Accenture, Microsoft, Altran, Coca-Cola, LaRoche, GE, Ikea, Leclerc, IBM, Malboro, HP, Atos, FT ou d'autres.
Il y a suffisamment de personne travaillant pour certaines de ces boites sur linuxfr pour faire le distingo entre "j'ai une belle page de référence à la con[1]" et un choix raisonné, pérenne et pertinent.
> Le jour ou un serveur crash par manque de moyen, la problématique est la même.
+1
Mais ça ne dit pas tout: "le jour où je veux changer, est ce que ça sera possible?"
C'est un point sur lequel il faut des solutions basé sur des standards pour s'en sortir, ou avec un accès au modèle de données. Il y a presque tout le temps moyen théoriquement (pas forcément très pratique) de s'en sortir avec des logiciels libres avec la deuxième méthode. En SaaS c'est plus coton.
[1] faire des recherches google sur edf et référence ou grand compte pour rigoler, parfois on a l'impression qu'ils utilisent 3SCM, 20 CMS[2], 5 GED, 8 Groupware déployé sur l'ensemble du groupe... En gros il ne faut pas confondre un test/proto/projet isolé avec un déploiement général.
[2] bon ça par contre, ça arrive vraiment pour certaines grosses boîtes-
[^]Re: Lighthouse
Posté par freeflight00 () le 03/06/2008 à 17:43. (lien). Évalué à 1.Vu la liste des boites citées, (au fait c'est monsanto hein...), ça commence déjà à déborder sur de la politique... :)
Accessoirement, je parlais d'Oracle.
> En SaaS, c'est plus coton.
Ouaip, sauf quand il y a une API. Ce qui est le cas de lighthouse, de github, et de beaucoup d'applis web.
Ce qui me prête à sourire malgré tout dans cette histoire, c'est le manque flagrant d'objectivité de certains.
Je suis développeur web à temps plein. J'utilise (à la pelle sans aucun ordre) Apache, Rails, Ruby, Prototype, svn, textmate, fiveruns, github, lighthouse, etc...
Mes projets web sont conséquents et nombreux puisque mon fond de commerce. Pour autant, je n'utilise pas que du libre. Parce que j'ai des contraintes de pérénité (certes) mais aussi de rendement, de productivité et de qualité.
Alors quoi, seule l'utilisation d'une Debian, d'un vi ou emacs (c'est selon les gouts), et d'une palanquée de produits de gestion de projet libre mais de pietre qualité ferait de moi un développeur heureux, et à l'abri de toute problématique de pérénité???
Seuls ces outils me permettrait de créer du code de qualité, à l'abri des aléas d'éditeur propriétaires vereux?
Peut être, mais aujourd'hui je ne mise plus sur l'avenir, je compte que sur le présent. Je préfère encore prendre ce risque et être à l'aise avec mon environnement plutôt que de proner a qui veut l'entendre que je code QUE du libre avec du libre et sous environnement libre pour au final pondre... un petit caca.
Et je suis bien heureux que nombre de projets libres aient cette mentalité (rails, django et symfony rien que pour les frameworks web).-
[^]Re: Lighthouse
Posté par thibault jouannic (page perso, ) le 03/06/2008 à 19:43. (lien). Évalué à 4.>et d'une palanquée de produits de gestion de projet libre mais de pietre qualité ferait de moi un développeur heureux, et à l'abri de toute problématique de pérénité???
Ce commentaire est tendancieux, il laisse à croire que les gestionnaire de projets libres sont tous de piètres qualité. Par ailleurs, personne n'a dit que les éditeurs de logiciels propriétaires étaient tous vereux.
Personne ne nie que certains logiciels proprio sont excellents. Indépendemment de ça, qu'on soit partisan du libre ou pas, il faut reconnaître que les notions de formats ouverts, de protocoles compatibles, de propriété et de pérennité des données sont des problématiques trop graves pour être laissées de côté.
-
[^]Re: Lighthouse
Posté par Earered () le 03/06/2008 à 20:34. (lien). Évalué à 4.> Ouaip, sauf quand il y a une API. Ce qui est le cas de lighthouse, de github, et de beaucoup d'applis web.
Sauf quand il y a une API _standard_
Exemple: http://jcp.org/en/jsr/detail?id=170
À l'époque d'Alfresco 1.4, l'ECM permettait la lecture via cette API (mais pas complètement l'écriture), ce qui permettait au moins d'envisager d'extraire les données sans développement spécifique. Il n'y avait qu'un unique outil de lecture/extraction sur sourceforge.
Ce genre de merde, quand on ne les notes pas coute très cher aux entreprises/établissement publics quand ils changent de prestataire (l'ancien devant être de bonnes volonté, en cas de bugs anomalies, pour donner l'accès aux données).
Avec un API _standard_ on n'a rien à demander à personne pour extraire les données, et l'outil d'extraction est développé une bonne fois pour toute.
Une API proprietaire, c'est à peu près aussi intéressant que de lancer wget pour récupérer les données (j'exagère, mais si le développement de l'outil d'extraction n'a pas été anticipé, et qu'on se retrouve avec 48h pour extraire les données avant la fin du service...)
C'est un problème orthogonal[1] au libre/pas libre les problème de format/API standard/propriétaire
[1]bon, on va dire à angle aigu avec le logiciel libre, ça facilite parfois d'avoir les sources :P
-
-
-
-
-
-
[^]Re: Lighthouse
Posté par Earered () le 03/06/2008 à 16:17. (lien). Évalué à 5.>ça me fait un peu penser à la période Bitkeeper du noyau Linux.
Ou launchpad de canonical pour ubuntu, inkscape & co?
Woohoohoo ---------------> [ ]
P.S. Pas mal de projet java sont dans le même cas (fondation apache + alfresco) http://wiki.apache.org/general/ApacheJira
En gros il profitent d'un service/produit (genre des admins gratuits), et les sociétés en question gagne une pub phénoménale.
Il n'y a pas une tentative de standardisation (JSR ou autre) pour la gestion des publication/extraction des tâches/anomalies/requêtes ?
(autre que syncml avec les tâches simples), ça remettrait une saine concurrence et un peu plus de raison la dedans (vu que chaque projet à une approche parfaitement raisonnable selon les devs, mais que chaque projet choisit une solution différente pour des besoins similaires (au moins les choix entre git et mercurial reconnaissent presque systématiquement une part d'irrationalité (les pôtes ont choisit git, donc on prend git)).
Et du côté des perfs ?
A l'époque où je m'intéressais à Ruby, il était question de performances un peu en retrait par rapport à ses concurrents. Qu'en est-il aujourd'hui ?
-
[^]Re: Et du côté des perfs ?
Posté par Juba (page perso, ) le 03/06/2008 à 16:48. (lien). Évalué à 2.J'ai l'impression que les reproches faits à Rails en général (même si ruby n'a jamais été considéré comme très rapide) étaient plus liés à sa "scalabilité" (comment ça se traduit ça ?) qu'à ses performances proprement dites. En tous cas de très gros sites fonctionnent avec Rails et semblent tourner convenablement.
De plus de nombreuses solutions ont été développées au-delà de FastCGI pour offrir de meilleures performances (Mongrel, Thin, mod_rails...).-
[^]Re: Et du côté des perfs ?
-
-
[^]Re: Et du côté des perfs ?
Posté par freeflight00 () le 03/06/2008 à 16:53. (lien). Évalué à 7.GitHub, YellowPages, Twitter et Friends for Sales sont de "grosses applis" tournant parfaitement sous Rails.
Pour info, Friends for Sales, c'est grosso modo 200 requetes/sec et 300 millions de pages vues par mois.
T'as une appli plus gourmande à développer? :)
Depuis la version 2.0, le couple Ruby / Rails est devenu très performant sur des architectures high scability.
Puis aujourd'hui, les perfs ne veulent plus dire grand chose car les applications gourmandes sont éclatées en services (Amazon EC2, SimpleDB, S3, etc...). Bref, le langage est de moins en moins prépondérant face à une architecture bien pensée.-
[^]Re: Et du côté des perfs ?
Posté par yellowiscool (Jabber id, page perso, ) le 03/06/2008 à 20:58. (lien). Évalué à 1.8000 requêtes seconde, c'est ce que délivre un lighthttpd en local sur des fichiers statiques.
D'accord il y a la bande passante, mais 200 requêtes secondes, c'est peu. Un serveur mutualisé chez ovh doit fournir bien plus.-
[^]Re: Et du côté des perfs ?
Posté par freeflight00 () le 03/06/2008 à 22:13. (lien). Évalué à 5.Tu m'indiqueras quels site sympa tu utilises avec des "fichiers statiques".
Tes perfs brutes n'ont aucun intérêt. Branche toi un peu sur les problémes de montée en charge et fais nous suivre TON site dynamique avec base de données (bien entendu...) chez ovh capable de supporter plus de 200 requetes secondes, je serais le premier à t'embaucher.
Je ne savais pas que Sylvain Mirouf s'était mis au libre...-
[+] [^]Re: Et du côté des perfs ?
Posté par forc3 (page perso, ) le 03/06/2008 à 23:35. (lien). Évalué à -1.La base de donnée c'est par définition le problème de toute architecture qui veut monter en charge...
Un site c'est bien plus que ca !
C'est pas le manque de présentation sur slideshare ou sur google engEDU video qui manquent pour comprendre cela...-
[^]Re: Et du côté des perfs ?
Posté par Yusei () le 04/06/2008 à 08:44. (lien). Évalué à 3.Sur la plupart des serveurs que j'ai mis en place qui utilisent Rails, les fichiers statiques sont servis aussi vite que peut les servir apache, ça ne passe même pas par Rails. C'est sur les pages dynamiques que les comparaisons de performance sont intéressantes.
-
-
-
[^]Re: Et du côté des perfs ?
Posté par yellowiscool (Jabber id, page perso, ) le 05/06/2008 à 23:16. (lien). Évalué à 3.Pour note, je fais du rails.
Ce que je veux dire, c'est que s'extasier sur un gros site en prod juste pour dire qu'il délivre 200 pages secondes, c'est un peu ironique.
-
-
[^]Re: Et du côté des perfs ?
Posté par forc3 (page perso, ) le 03/06/2008 à 23:33. (lien). Évalué à 4.Ce que tu décris ici est un système distribué, et effectivement c'est le seul moyen de supporter la montée en charge et la haute dispo.
Maintenant je ne savais pas que ruby était capable d'être complètement asyncrhone et permettait de "deleguer" des operations à des processus concurrents permettant dans s'occuper de la transaction en cours pendant que l'internaute en face à dejà reçu une réponse à sa requète.
Tu oublies aussi de parler de tous les artifices nécessaires comme memcached ou xmpp pour twitter. (twitter n'est pas un modèle de stabilité voir les récents articles sur techcrunch)
Ces briques logicielles sont fondamentales pour ces services...
Bâtir de la haute dispo c'est tout simplement gérer les évènements de manière asynchrone.
Une requète à un service externe signifie que ce service retourne tout de suite un token qui va permettre à l'appelant d'être informé de la bonne fin ou pas du traitement demandé.
Qui dit asynchrone dit timeout, je ne sais s'il est tout simplement possible de demander a ror d'effectuer une requète HTTP et de sortir en timeout si en 400 ms aucune réponse n'ai arrivée. De même pour une simple requète DNS.
Une architecture scalable se construit avec des technologies capables de gérer la concurrence. Que ce soit des threads ou des processus; il n'est pas envisageable d'avoir un seul processus au déroulement purement séquentiel pour répondre à une requète.
Ne serait que mettre à jour un compteur, il est n'est pas "normal" de faire l'incrément de ce compteur dans le même processus que celui qui sert la requète. A la place il faut que le processus de traitement de la requète fasse lui même un appel à un service d'incrément de compteur (avec un timeout) et continue son travail. Le processus qui gère l'incrément à tout le loisir pour mettre à jour toutes les ressources liées. Mais en aucun cas un perturbation du réseau pour joindre une des ressources n'aura impacter la réponse à l'utilisateur.
Pour faire simple avec un concept compliqué: la scalabilité c'est ajouter ou enlever des machines de manières transparente, cela signifie que les temps d'exécution observé par l'internaute doivent toujours être semblables.
Un timeout pour toutes les opérations asynchrones et des processus dédiées pour les opérations de types entrée sortie.
Est-ce que ruby sait tirer profit des processeurs multicore ?
Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?
"Puis aujourd'hui, les perfs ne veulent plus dire grand chose car les applications gourmandes sont éclatées en services (Amazon EC2, SimpleDB, S3, etc...). Bref, le langage est de moins en moins prépondérant face à une architecture bien pensée."
Un langage adapté, et ce n'est pas le cas de ruby.
Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...
Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby... Bref creuse le sujet de la scalabilité, car tu fais fausse route...-
[^]Re: Et du côté des perfs ?
Posté par fredix (Jabber id, page perso, ) le 04/06/2008 à 01:42. (lien). Évalué à 5.Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...
Pour le web Ruby on Rails ca été quand même un évènement important dans le développement web. Il a permis d'imposer le modèle MVC qui simplifie le développement et la maintenance. Qui voudrait de nos jour développer sans un tel framework ? Que ce soit en Python, PHP ou Java, tous possèdent leur framework, avec plus ou moins de bonheur, sur le modèle de Rails.
Pour ce qui est du non web, demande à http://metasploit3.com/ ,http://reductivelabs.com/trac/puppet , http://www.snapvine.com/code/ragi/ , les utilisateurs de QtRuby, FxRuby , etc si Ruby est un langage sans intérêt ...
Tu parles de Erlang et je suis entièrement d'accord avec toi, il a été conçu pour la concurrence. Mais aussi bien soit-il (quoi que la syntaxe est plutôt repoussante) sans un framework web digne de ce nom il ne pourra percer (quoique à voir ce que donnera Erlyweb http://erlyweb.org/ (http://twoorl.com est une bonne démo)) et se cantonnera aux backends (tel que le chat de facefook) ce qui n'est pas si mal.
Perso je ne crois plus aux langages ultimes, Rails et Merb font leur preuves coté frontal web, mais une archi qui prétent être haute dispo nécessite de fait un mixage de langages adaptés à leur contexte. Twitter utilise entre autre Erlang sur leur backend, ainsi que Facebook (http://developers.facebook.com/thrift/).
Il n'existe pas un langage adapté à tout.
Quant à Zen Shaw il me semble pas mal trollesque comme personnage.-
[+] [^]Re: Et du côté des perfs ?
Posté par Bozo le Clown () le 04/06/2008 à 09:48. (lien). Évalué à -2.
Pour le web Ruby on Rails ca été quand même un évènement important dans le développement web. Il a permis d'imposer le modèle MVC qui simplifie le développement et la maintenance. Qui voudrait de nos jour développer sans un tel framework ? Que ce soit en Python, PHP ou Java, tous possèdent leur framework, avec plus ou moins de bonheur, sur le modèle de Rails.
Ah Ruby a inventé le MVC pour le Web ?
Et moi qui croyait bêtement que Struts était le précurseur.
et que RoR n'avait apporté que la mouvance de "convention over configuration"-
[^]Re: Et du côté des perfs ?
Posté par CrEv (page perso, ) le 04/06/2008 à 10:16. (lien). Évalué à 4.c'est ptêtre pour ça qu'il parlait "d'imposer" et non d'inventer...
Car qu'on apprécie ou non Rails, il faut bien avouer que depuis qu'il c'est mis à faire du bruit les autres projets (qu'ils existent précédemment ou non) on avancé plus vite (et ce qq soit le langage, php, java, python, ...)
-
-
-
[^]Re: Et du côté des perfs ?
Posté par Bruno Michel (Jabber id, page perso, ) le 04/06/2008 à 03:18. (lien). Évalué à 5.Qui dit asynchrone dit timeout, je ne sais s'il est tout simplement possible de demander a ror d'effectuer une requète HTTP et de sortir en timeout si en 400 ms aucune réponse n'ai arrivée. De même pour une simple requète DNS.
Bien qu'il faille chercher assez loin pour trouver la réponse, oui, Ruby permet de faire cela, et RoR utilise ces capacités, pour ActiveResource par exemple.
Est-ce que ruby sait tirer profit des processeurs multicore ?
Oui, il suffit de lancer plusieurs processus.
Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?
La question est biaisée. Oui, le modèle de threads de Ruby est catastrophique, mais rien n'empêche de paralléliser avec des processus.
Un langage adapté, et ce n'est pas le cas de ruby.
En l'absence d'arguments, c'est du FUD.
Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...
Je me suis documenté sur tout cela. Ruby n'est probablement pas le langage le plus adapté pour la haute disponibilité, mais Ruby présente un réel intérêt à mes yeux. Pour développer des frontaux web, Ruby (ou Python) reste à mes yeux largement préférable aux langages que tu as cité. D'ailleurs, est-tu seulement capables de me donner le nom d'un seul site web à fort trafic qui utilise Scala ou Haskell ? Pour Erlang, c'est facile, Twitter a déjà été cité (et visiblement utiliser erlang n'a pas suffit à résoudre leurs problèmes de montée en charge).
Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby...
Zen Shaw est connu pour être un personnage avec un certain tempérament. Bien que très justes sur le point technique, ses écrits mettent surtout en avant ses relations tendues avec certaines personnes influentes de la communauté Ruby. Il n'y a pas de remise en cause de Ruby.
Bref creuse le sujet de la scalabilité, car tu fais fausse route...
Des sites à fort trafic s'en sortent très bien avec RoR. Je ne pourrais pas en dire autant d'autres langages. Haskell est par exemple connu pour avoir des performances très difficiles à prédire, ce qui est, à mon avis, un point bloquant pour assurer des montées en charge dans de bonnes conditions.
Pour finir, je te ferais remarquer que tu as tendance à mélanger haute disponibilité et scalabilité. Bien que ces deux notions soient souvent liées, elles ne se recouvrent pas totalement. En particulier, pour la scalabilité, respecter certains grands principes est souvent moins important que l'expérience empirique. L'exemple typique est l'utilisation d'un cache : on cache telles ou telles données en testant et en regardant ce qui marche le mieux. Cela aide grandement à la montée en charge à un point tel que le site ne peut plus fonctionner sans un cache "chaud", ce qui est loin d'être idéal pour la haute disponibilité.-
[^]Re: Et du côté des perfs ?
Posté par Octabrain () le 05/06/2008 à 11:24. (lien). Évalué à 1.>> Est-ce que ruby sait tirer profit des processeurs multicore ?
> Oui, il suffit de lancer plusieurs processus.
T'es sérieux là ?-
[^]Re: Et du côté des perfs ?
Posté par RB () le 05/06/2008 à 13:08. (lien). Évalué à 2.Pourquoi est ce que ce serait bête ? Les plus puissant serveurs comme Apache commencent par lancer X instances avant d'utiliser des threads à l'intérieur. Pour servir des pages ce genre de modèle va très bien et c'est une très bonne manière d'augmenter les performances de ruby (et d'utiliser plusieurs CPU) en attendant la version 2 et une nouvelle vm.
-
[^]Re: Et du côté des perfs ?
Posté par Octabrain () le 05/06/2008 à 13:58. (lien). Évalué à 2.C'est bête parce que ça veut dire que Ruby profite autant du multicore qu'un script shell, et ce n'est même pas dû à Ruby lui-même mais à l'OS, et aussi qu'il faut s'emmerder à gérer plusieurs processus (et leur inter-communication).
-
[^]Re: Et du côté des perfs ?
Posté par RB () le 05/06/2008 à 22:49. (lien). Évalué à 8.Tu t'égares, on parle depuis le début du thread d'un serveur web !
Il n'y a normallement pas de communication inter process, mais qu'une bête connection a la DB ou un accès à des fichiers puis la génération d'un rendu....
De toute façon, cela ne sert à rien de s'acharner contre ruby, si ses threads sont merdique c'est parce que son créateur était pas trop porté sur les compilateurs. Maintenant une réécriture est en cours pour ruby 2.0 et il sera de rapidité équivalent a php, perl, python, ...
De toute manière ont s'en fout un peu, à mon avis tout projet d'une grande taille devrait envisager plusieurs languages et pour certains type de frontend ruby va très bien. Et syntaxiquement c'est un de mes langages préféré et je crois que c'est aussi très important.
-
-
-
-
-
[^]Re: Et du côté des perfs ?
Posté par forc3 (page perso, ) le 04/06/2008 à 12:18. (lien). Évalué à 2.Je me corrige c'est Zed Shaw :)
pour ceux que cela intéresse ..
-
-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 01:55. (lien). Évalué à 3.> GitHub, YellowPages, Twitter et Friends for Sales sont de "grosses applis" tournant parfaitement sous Rails.
non-non, Twitter ne tourne pas parfaitement du tout, au contraire, ils ont eu de gros problèmes, très médiatisés. et pourtant c'est une appli simple, hein, à peine plus compliquée qu'une tribune.--
Windows has no users. It has hostages.-
[^]Re: Et du côté des perfs ?
Posté par Bruno Michel (Jabber id, page perso, ) le 04/06/2008 à 02:36. (lien). Évalué à 1.Twitter est bien plus compliqué qu'une simple tribune. Ce ne serait que cela, ils n'auraient aucun problème de scalabilité. Mais twitter est bien plus que cela : l'effet "réseau social" joue un rôle considérable. On peut trouver quantité d'articles sur ce sujet, mais http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi(...) me semble être un bon point de départ pour comprendre les problèmes aux quels sont confrontés les développeurs de twitter.
-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 12:23. (lien). Évalué à 2.ah non-non-non, je proteste, Twitter n'est PAS compliqué : au lieu d'avoir deux tables comme pour une tribune, on en a... 3. c'est tout.
le gag comme expliqué dans ton article et d'autres c'est que pour marcher, l'appli doit faire des full-scans et c'est lourd. surtout si des andouilles d'utilisateurs s'amusent à ajouter des centaines d'autres utilisateurs comme "amis". mais ça n'a rien de compliqué dans le principe.
deux autres articles dessus :
http://highscalability.com/scaling-twitter-making-twitter-10(...)
http://www.mooseyard.com/Jens/2007/04/twitter-rails-hammers-(...)
qui dit que en fait SQL est peut-être pas des plus adaptés ici :)--
Windows has no users. It has hostages.-
[^]Re: Et du côté des perfs ?
Posté par Bruno Michel (Jabber id, page perso, ) le 04/06/2008 à 13:00. (lien). Évalué à 1.Je n'ai pas dit que Twitter était compliqué dans l'absolu, mais qu'il était bien plus compliqué qu'une simple tribune. Le nombre de tables ne fait pas tout, il faut aussi tenir compte du nombre de pages, de l'API, de la gestion des SMS, etc. Note également que les tribunes ne gardent généralement pas d'historique contrairement à Twitter. Bref, c'est comme comparer LinuxFR à un simple blog : c'est un peu la même idée, mais ca n'a pas grand chose à voir en pratique.
surtout si des andouilles d'utilisateurs s'amusent à ajouter des centaines d'autres utilisateurs comme "amis"
Si c'était seulement quelques centaines, ca irait encore, mais certains utilisateurs ont plus de 30 000 "amis" (sic).-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 14:07. (lien). Évalué à 2.c'est la base de données qui fait tout ramer. c'est juste des maths. les jointures c'est quand même un poil vieux comme concept et ca a été un poil étudié depuis le temps.
l'usine à gaz à coté avec des fonctionnalités et des plug-ins à tire-la-rigo c'est pas le problème. au pire ça rend l'expérience de l'utilisateur plus plantogène si un des bidules tombe en rade, mais c'est tout. que ca soit simple ou compliqué (disons, riche) n'a aucune influence sur le coeur de Twitter
> certains utilisateurs ont plus de 30 000 "amis"
*PAN*, rien d'autre à ajouter.
ah si, que y'a rien de neuf sous le soleil, que ça soit ICQ, MSN ou Orkut, les utilisateurs normaux n'ont pas 30 000 contacts dans leur "buddy list".--
Windows has no users. It has hostages.
-
-
[^]Re: Et du côté des perfs ?
Posté par freeflight00 () le 04/06/2008 à 14:15. (lien). Évalué à 2.Twitter est compliqué.
Or les "andouilles d'utilisateurs" sont précisément tes utilisateurs, tes clients et ton fond de commerce. Tu peux avoir à gérer 3 tables, cela n'enlève en rien la complexité du projet qui doit gérer des millions de requêtes.
Accessoirement, gérer des milliers d'upload d'avatar à la minute, c'est compliqué. Gérer des milliers d'accès API mal écrit, c'est compliqué. Gérer des milliers d'écriture en base en simultané c'est compliqué.
Que tout ceux qui doutent fasse valoir leur savoir dans de beaux projets francais de telle envergure.-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 20:34. (lien). Évalué à 2.> les "andouilles d'utilisateurs" sont précisément tes utilisateurs.
non. je parle de ceux qui, disons, dépassent les 100 contacts ou font un usage inconsidéré ou abusif du service
dans un autre domaine si c'était un webmail ca serait les vilains spammeurs, par exemple--
Windows has no users. It has hostages.
-
[^]Re: Et du côté des perfs ?
Posté par lezardbreton (Jabber id, page perso, ) le 04/06/2008 à 21:38. (lien). Évalué à 5.Que tout ceux qui doutent fasse valoir leur savoir dans de beaux projets francais de telle envergure.
Il y a bien mon ancienne équipe qui gérait par un webservice 1 millions d'écriture en 9h avec des pointes à 4 millions sur deux tables différentes, avec bien sûr validation des données par lecture dans deux tables différentes, mais certaines boites concurrentes sont plus proches des 10 millions dans le secteur.
Je peux le dire sans me vanter : je n'en suis pas responsable. Par contre, je te garantis qu'on n'avait pas de souci insupportable pour le gérer.
-
-
-
-
[^]Re: Et du côté des perfs ?
Posté par fredix (Jabber id, page perso, ) le 04/06/2008 à 11:55. (lien). Évalué à 2.Ta tribune a une API qui génère 10 fois plus de requête que le site ? Visiblement tu sais pas de quoi tu parles.
-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 13:44. (lien). Évalué à 1.visiblement tu ne sais pas non plus de quoi tu parles : des user agents comme pyCoinCoin ou wmcc ne sont pas des navigateurs web qui "vont sur le site".
mais merci d'avoir joué.--
Windows has no users. It has hostages.-
[^]Re: Et du côté des perfs ?
Posté par fredix (Jabber id, page perso, ) le 04/06/2008 à 13:48. (lien). Évalué à 1.ahah, et ces agents génèrent autant de requêtes que ce que reçoit l'API twitter ? :) sacré Gniarf.
-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 04/06/2008 à 14:36. (lien). Évalué à 1.à nombre d'utilisateurs égaux ?
ah zut, tu viens de te rendre compte que c'est pas comparable \o/--
Windows has no users. It has hostages.-
[^]Re: Et du côté des perfs ?
Posté par fredix (Jabber id, page perso, ) le 04/06/2008 à 18:46. (lien). Évalué à 1.C'est toi qui vient de te rendre compte que comparer une tribune avec une centaine de users n'est pas comparable avec le volume que traite Twitter. Tu dépasses PgPb en mauvaise fois, c'est pas facile pourtant.
-
[^]Re: Et du côté des perfs ?
Posté par Gniarf () le 05/06/2008 à 10:04. (lien). Évalué à 3.ah non-non, depuis le début je dis que ca n'a rien de compliqué comme structure et que leurs soucis ce n'est pas que ça soit compliqué mais que ça soit utilisé pour de bon maintenant, c'est tout.
pas de chance, en termes de bases de données ils sont dans un cas très défavorable et en fait SQL ou les bases relationnelles sont pas bien bien taillées pour ce cas.
en fait c'était avant. les esprits attentifs auront lu les URLs qui sont passées et auront compris de suite pourquoi l'un des gus avait comparé Twitter à l'email, ou plus généralement à acheminer et délivrer des messages, et que Starling est justement... une message queue :
http://dev.twitter.com/2008/01/announcing-starling.html--
Windows has no users. It has hostages.
-
-
-
-
-
-
-
-
[^]Re: Et du côté des perfs ?
Posté par Slainer (Jabber id, page perso, ) le 03/06/2008 à 19:34. (lien). Évalué à 3.En fait à une époque on critiquais surtout Ruby on Rails pour la difficulté de déployement.
Aujourd'hui tu balances un mod_rails (renommé Passenger en fait) sur un Apache et tu déployes avec un simple drop de l'appli, comme une appli PHP de base et ça fonctionne out of the box.
Pouvoir déployer des belles applications basée sur un framework ultra sympa comme Rails aussi simplement qu'une banale appli PHP, saykewl :). Aucune raison de pas switcher.
Je trolle mais AMHA actuellement Rails c'est clairement le meilleur outil de développement Web existant. J'ai aussi la chance de pouvoir développer avec professionnellement.
Pour rester objectif, je continue de zieuter autour pour voir la concurrence mais elle est encore loin derrière.-
[^]Re: Et du côté des perfs ?
Posté par ... a little wood elfe () le 03/06/2008 à 22:17. (lien). Évalué à 1.Seaside ? ( http://www.seaside.st/ )
J'ai essayé, ça semble super sympa mais pas forcément facile d'approche. Surtout du fait d'un manque de documentation et d'un changement profond d'habitudes à l'utilisation de SmallTalk.
-
[^]Re: Et du côté des perfs ?
Posté par d-jo (page perso, ) le 07/06/2008 à 14:32. (lien). Évalué à 8.Pouvoir déployer des belles applications basée sur un framework ultra sympa comme Rails aussi simplement qu'une banale appli PHP, saykewl :). Aucune raison de pas switcher.
C'est trop gros, je peux pas laisser passer ça.
Mais quand tu veux gérer finement des droits sur des dizaines de répertoires avec autant d'utilisateurs, que tu as par dessus des impératifs sécurité (du style pas de shell pour apache), qu'il faut envoyer des mails qui n'arrivent pas directement dans les boîtes spam et que tu travailles avec des devs qui sont outré parce que tu refuse qu'ils fassent des exec à tout va et que de toute façon leur appli elle marche bien sur leur easyphp. Quand tu t'encaisse 18 millions de requêtes par jours, que tu est réveillé la nuit parce qu'un abruti à réussie à coder une redirection 301 récursive ou qu'Apche 2.2 (ah t'avais dit qu'il fallait la 1.3.41) c'est vautré parce qu'un cron a fait un graceful alors qu'arrivait un trop gros post ... ben figure toi que même php c'est pas simple.
L'avantage de de montgrel / BDD / frontal web, c'est que c'est un modèle 3 tiers propre et scalable. Qui t'évite justement les affres d'un mod_php tout en un.
Mes deux cents
-
Git
...et un projet de plus qui passe a Git, j'ai l'impression que l'on connait desormais le nom du grand gagnant des systemes de gestion de versions distribuees...
Pour avoir un peu essaye, c'est quand meme pas super user-friendly par rapport a subversion.
-
[^]Re: Git
Posté par Fabien Penso (Jabber id, page perso, ) le 03/06/2008 à 16:54. (lien). Évalué à 3.Personnellement (cf mon blog aussi) je trouve que github ou gitorious aide beaucoup pour le succès de git par rapport à mercuriel. Un repo monté en 1 min c est bien.
git ou mercurial c'est quand même vachement du bonheur comparé à subversion, je suis sur que des boites de VoIP auraient réussi si elles avaient commencé par ca (private joke inside).-
[^]Re: Git
Posté par pistouille () le 03/06/2008 à 21:15. (lien). Évalué à 1.Ce serait pas dans une boite dont le nom commence par wen... et termine par go ? par hasard :)
-
-
[^]Re: Git
Posté par thibault jouannic (page perso, ) le 03/06/2008 à 19:46. (lien). Évalué à 1.>Pour avoir un peu essaye, c'est quand meme pas super user-friendly par rapport a subversion.
Hmmm... C'est sans doute subjectif, j'ai trouvé exactement le contraire. Git est différent de cvs ou svn, il nécessite donc un temps d'adaptation avant de se sentir à l'aise. Et toutes ces commandes en paquet, ça fait un peu fatras. Ok, je veux bien reconnaître que git n'est pas trés user friendly au premier abord.
Mais qu'est-ce que c'est pratique et puissant :)
[+] Ce qui devait arriver...
Voilà, j'ai posté 2 commentaires ou je ne fais pas une apologie aveugle du libre et mes commentaires ne sont plus visibles.
Voilà aujourd'hui donc le débat des libristes sur linuxfr.org. Tu es pro libre avec un argumentaire archi entendu, à toi le bonheur d'être "porté en héros" avec des +10 à tous tes commentaires.
Tu as un avis différent, mais argumenté, "couic", on te fais gentillement taire histoire de ne pas eclabousser la merveilleuse idéologie du libre.
Il est bien loin le temps ou je venais débattre et me divertir sur linuxfr. Me reste plus qu'archive.org accompagné d'un bon disque disque de Cabrel pour retrouver cette aura qui était si particulière à linuxfr.
C'était mieux avant...
-
[+] [^]Re: Ce qui devait arriver...
Posté par maximegb (page perso, ) le 03/06/2008 à 17:31. (lien). Évalué à -3.Pire même, il suffit parfois de poser une question qui peut prêter à croire que tu doutes de l'intérêt d'une technologie (libre) ou de la comparer à une autre (libre elle aussi !), pour te faire censurer !
http://linuxfr.org/comments/929065,1.html
Il est bien loin le temps ou je venais débattre et me divertir sur linuxfr.
Aucun débat possible.
-
[^]Re: Ce qui devait arriver...
Posté par baud123 (Jabber id, page perso, ) le 03/06/2008 à 17:36. (lien). Évalué à 3.et mes commentaires ne sont plus visibles
eh oh c'est pas bientôt fini le karma whoring, tu peux monter un club si tu veux : https://linuxfr.org/tracker/804.html
ce serait oublier que pas mal de monde surfe à -42 avec la toolbar DLFP tout de même... cf. http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsLecteurL(...)-
[^]Re: Ce qui devait arriver...
Posté par Frédéric COIFFIER () le 03/06/2008 à 18:00. (lien). Évalué à 10.Non, y a pire : il y a les gens comme moi, qui lisent toutes les réponses et qui se demande qu'est ce qui provoque un tel acharnement, pour finalement aller déplier les fameux posts cachés et suivre la meute en inutilant une nouvelle fois...
-
-
[^]Re: Ce qui devait arriver...
Posté par stephane martin () le 03/06/2008 à 21:39. (lien). Évalué à 10.Sauf que ce qui te manque, c'est un argumentaire. Je suis plutôt d'accord avec toi sur le fond de tes positions, mais quand tu les soumets à des gens qui y sont _a priori_ opposé, tu ne peux pas te contenter d'énoncer tes convictions.
--
Every time you write invalid markup, God kills a kitten-
[+] [^]Re: Ce qui devait arriver...
Posté par freeflight00 () le 04/06/2008 à 14:31. (lien). Évalué à -6.Comment argumenter si mes commentaires sont censuré automatiquement?
Je lis ici et là sur linuxfr des personnes se plaignant du système de 'karma' contraingnant associé à des personnes infoutues de comprendre qu'il n'est pas utile de "moinser" lorsque l'on est pas d'accord...
Ce qui est sûr, c'est que le monde du libre n'est plus ouvert d'esprit.
Gargarisez vous dans votre joli petit monde reclus de théoricien technophiles autosatisfaits. Le libre a perdu pas mal de ses lettres de noblesses à cause de certains extremistes innacommodé par des avis divergeant.
Le débat n'existant plus sur ce site, son intérêt n'en devient que de plus en plus limité.
Amusez vous à cacher ce commentaire tant que vous le pouvez, votre petit monde ne s'en portera que mieux :)
Et branlez vous avec vos points de karma qui vous permettent de diriger le débat dans le sens de votre pensée unique.-
[^]Re: Ce qui devait arriver...
Posté par Johan Charpentier (Jabber id, ) le 04/06/2008 à 15:17. (lien). Évalué à 4.Tu sais qu'il y a des gens qui lisent les commentaires "censurés" comme tu les nomme et qui pertinentent le commentaire si ils pensent que ça en vaux la peine.
Y'en a...
Mais si il y a plus de personnes qui pensent le contraire et qui pensent que tes arguments ne font pas le poids, peut être faut-il que tu change d'approche ou de sujet dans ton argumentation au lieu de penser qu' "ils" font tout pour te censurer.--
"We may not live to see yesterday". (Hoagie)
-
[^]Re: Ce qui devait arriver...
Posté par Guid (page perso, ) le 04/06/2008 à 15:46. (lien). Évalué à 2.Merci d'aller chouiner ailleurs plutôt que de partir dans des grandes généralisations sur les gens qui composent le monde du libre, tout ça parce que certains de tes posts sont en dessous de zero sur dlfp.
Ce système de notation a des faiblesses certes, mais pour moi, c'est comme la démocratie, c'est le moins pire de tous les systèmes. Ou alors on va se retrouver comme sur clubic avec des kilomètres de conneries et parfois des posts intéressants. Et là, je dis "non merci, mais non merci."
-
[^]Re: Ce qui devait arriver...
Posté par benoar (Jabber id, ) le 05/06/2008 à 12:57. (lien). Évalué à 5.Comment argumenter si mes commentaires sont censuré automatiquement?
Problème de l'oeuf et la poule : si tu ne commences pas à argumenter, forcément, tu ne te feras pas plusser. Et si tu attends de te faire plusser pour argumenter ...
Sinon, pour "répondre" vite fait à tes "arguments", je dirais que tu utilises trop le vieux coup du "le libre c'est bien pour faire mumuse, mais quand on est un pro, on utilise du proprio" (OK, je carricature, mais certains ont dû le prendre comme ça). En fait, c'est aussi, je pense, le fait de dire que "utiliser du proprio c'est pas grave", même si là je crois que c'est ce que tu voulais dire : pour certaines personnes, si c'est grave. Bon, chacun fait ce qu'il veut, donc on devrait te laisser en paix, mais quand tu fais de la promotion de logiciel proprio sur un site de "libriste", là ça passe moins bien et l'"inutilisation" en démange certains.
-
-
Vive Django !
Oui, c'est HS, mais bon... pour une fois je voulais inaugurer la grande parade des "mon-framework-web-est-plus-gros-que-le-tien", dans la grande tradition de linuxfr.
--->[]
-
[^]Re: Vive Django !
Posté par patrick_g (page perso, ) le 03/06/2008 à 20:02. (lien). Évalué à 3.Ce ne sera pas hors-sujet si tu nous propose un petit comparatif RoR/Django et pourquoi toi tu a choisi Django.
-
[^]Re: Vive Django !
Posté par Fabien Penso (Jabber id, page perso, ) le 04/06/2008 à 01:12. (lien). Évalué à 3.... pour pouvoir faire un comparatif sur linuxfr.
-
[^]Re: Vive Django !
-
-
sans oublier....
Sans oublier aussi le rubis de fer.
http://www.ironruby.net/
allez, -->[]
Cette page a été générée par Templeet en 0.2096s (dont 0.0256 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.