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. Les principales nouvelles fonctionnalités sont:
- 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 rails
ou
gem update rails
ou par Git:
git clone git://github.com/rails/rails.git
Je vous conseille ardemment les screencasts de RailsCasts qui sont une mine d'or d'astuces et de bonnes pratiques.
Aller plus loin
- Ruby on Rails (3 clics)
- L'annonce sur le blog RoR (1 clic)
- Lighthouse (0 clic)
- GitHub (2 clics)
- Explication des nouveautés (1 clic)
- Screencasts (1 clic)
# Lighthouse
Posté par Juba (site web personnel) . Évalué à 10.
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 . Évalué à -6.
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 (site web personnel) . Évalué à 9.
On remarquera que c'est pareil avec launchpad.
[^] # Re: Lighthouse
Posté par freeflight00 . Évalué à 3.
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 . Évalué à 6.
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 . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 4.
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 . Évalué à 5.
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 ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
[^] # Re: Et du côté des perfs ?
Posté par Juba (site web personnel) . Évalué à 2.
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 ?
Posté par auve . Évalué à 9.
[^] # Re: Et du côté des perfs ?
Posté par freeflight00 . Évalué à 7.
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 . Évalué à 1.
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.
Envoyé depuis mon lapin.
[^] # Re: Et du côté des perfs ?
Posté par freeflight00 . Évalué à 5.
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 . Évalué à -1.
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 (Mastodon) . Évalué à 3.
[^] # Re: Et du côté des perfs ?
Posté par yellowiscool . Évalué à 3.
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.
Envoyé depuis mon lapin.
[^] # Re: Et du côté des perfs ?
Posté par forc3 . Évalué à 4.
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 . Évalué à 5.
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 . É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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 1.
> Oui, il suffit de lancer plusieurs processus.
T'es sérieux là ?
[^] # Re: Et du côté des perfs ?
Posté par RB . Évalué à 2.
[^] # Re: Et du côté des perfs ?
Posté par Octabrain . Évalué à 2.
[^] # Re: Et du côté des perfs ?
Posté par RB . Évalué à 8.
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 . Évalué à 2.
pour ceux que cela intéresse ..
[^] # Re: Et du côté des perfs ?
Posté par Gniarf . Évalué à 3.
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.
[^] # Re: Et du côté des perfs ?
Posté par Bruno Michel (site web personnel) . Évalué à 1.
[^] # Re: Et du côté des perfs ?
Posté par Gniarf . Évalué à 2.
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 :)
[^] # Re: Et du côté des perfs ?
Posté par Bruno Michel (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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".
[^] # Re: Et du côté des perfs ?
Posté par freeflight00 . Évalué à 2.
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 . Évalué à 2.
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
[^] # Re: Et du côté des perfs ?
Posté par lezardbreton . Évalué à 5.
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 . Évalué à 2.
[^] # Re: Et du côté des perfs ?
Posté par Gniarf . Évalué à 1.
mais merci d'avoir joué.
[^] # Re: Et du côté des perfs ?
Posté par fredix . Évalué à 1.
[^] # Re: Et du côté des perfs ?
Posté par Gniarf . Évalué à 1.
ah zut, tu viens de te rendre compte que c'est pas comparable \o/
[^] # Re: Et du côté des perfs ?
Posté par fredix . Évalué à 1.
[^] # Re: Et du côté des perfs ?
Posté par Gniarf . Évalué à 3.
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
[^] # Re: Et du côté des perfs ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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 Joris Dedieu (site web personnel) . Évalué à 8.
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
Posté par tanguy_k (site web personnel) . Évalué à 4.
Pour avoir un peu essaye, c'est quand meme pas super user-friendly par rapport a subversion.
[^] # Re: Git
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
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 . Évalué à 1.
[^] # Re: Git
Posté par thibault jouannic . Évalué à 1.
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...
Posté par freeflight00 . Évalué à -8.
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 . Évalué à -3.
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 BAud (site web personnel) . Évalué à 3.
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 . Évalué à 10.
[^] # Re: Ce qui devait arriver...
Posté par Houbaa . Évalué à 10.
[^] # Re: Ce qui devait arriver...
Posté par freeflight00 . Évalué à -6.
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 (site web personnel) . Évalué à 4.
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.
[^] # Re: Ce qui devait arriver...
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
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 . É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 !
Posté par desfrenes (site web personnel) . Évalué à 3.
--->[]
[^] # Re: Vive Django !
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Vive Django !
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Vive Django !
Posté par desfrenes (site web personnel) . Évalué à 1.
# sans oublier....
Posté par farib . Évalué à 1.
http://www.ironruby.net/
allez, -->[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.