Bruno Michel a écrit 3286 commentaires

Pour le rant de Zed, ca a fait beaucoup de bruit pour pas grand chose. Il en veut à quelques mecs de la communauté Rails et à Dave Thomas. Soit, ce sont des choses qui arrivent. Et pour une réponse plus détaillée : http://www.akitaonrails.com/2008/1/3/zed-is-not-dead

Est-ce scalabilité signifie juste de mettre un serveur memcached dans l'architecture d'une plateforme ?
Il semblerait que ni PHP ni Ruby ni Python, out of the box ne permettent de batir des architectures scalables...

Oui, mettre un serveur memcached aide pour la scalabilité, mais ca ne fait pas tout. La scalabilité est principalement une question d'architecture, et les langages de programmation n'ont qu'un faible rôle à y jouer.

En attendant, Ruby on Rails n'est pas parfait mais il me semble être encore en avance sur les autres frameworks. Donc pour répondre à ta question initiale, Rails se porte très bien.

Tes arguments me semblent fumeux :

- accesseurs verbeux en java , mais c'est généré en 3 clics dans eclipse

Ca oblige à utiliser un IDE là ou un semble éditeur de texte suffit. Rien de dramatique, mais ca n'en fait pas un argument pour Java.

- mixin c'est cool, mais variable + generate delegate method dans eclipse marche tres bien en java

Heu, tu es sérieux quand tu dis ca ? Si c'est le cas, en de hors des évidentes raisons esthétiques, ca doit être très chiant à maintenir, et qui dit plus de lignes de codes dit plus de bugs.

- typage laxiste ruby versus completion de code complete en java

Tu opposes deux choses qui n'ont rien à voir. La complétion de code fonctionne très bien pour Ruby sous Netbeans par exemple.

- syntaxe legere (a voire) ruby versus correction du code en java

Là encore, tu compares des choses qui n'ont rien à voir. Bien que ce soit une question de goût, je trouve la syntaxe de Ruby très agréable. Par contre, cela ne change rien à la correction du code. Si cela fait référence à la vérification des types, c'est très loin d'être suffisant pour éviter les bugs, et en Ruby comme en Java, j'ai tendance à considérer du code non testé comme du code buggé.

Quand aux perfs, j'ai un facteur 10 sur le même programme en java et ruby a l'avantage de java.

Comparer les performances sur un programme est assez ridicule. Pour ce que j'en sais, les performances de Ruby restent tout à fait correctes face à celles de Java.

java est mille fois mieux loti en librairies tierces

Je suis d'accord que Java est mieux loti que Ruby de ce coté. Avec un peu de mauvaise foie, je pourrais dire que ce n'est pas grave car JRuby permet d'utiliser toutes les bibliothèques Java.

Si tu tiens vraiment à utiliser un IDE, Netbeans 6.0 est, parait-il, très bien pour faire du Ruby ou du RoR.

Sinon, pour avoir moi aussi testé un paquet de langages (grosso modo les mêmes que toi), je trouve que Ruby est un très bon langage. Quand j'essaye un autre langage, je tombe souvent sur des trucs qui existent en Ruby et qui me manquent dans les autres langages, alors que l'inverse est beaucoup plus rare.

Pour ce qui est du cas particulier de Java, je trouve que ce langage assez moche, et se utiliser des outils/IDE pour parer ses problèmes n'est pas une bonne idée. Si tu en as le courage, je te conseille la lecture de http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht(...) qui explique bien le problème.

En fait, nous avions commencé la migration (fin août, il me semble) bien avant les problèmes matériel, mais la migration de templeet fut un travail assez titanesque, et les problèmes de matos nous ont pas mal retardé.

N'hésite pas à proposer une dépêche complète sur valgrind ;-)

C'est par là : https://linuxfr.org/submit.html

C'est un bug qui dépend des navigateurs. Là, je suis sous firefox, et ca marche bien. Par contre, il parait que sous konqueror, on a le double encodage.

Comme http://www.fabernovel.com/news/first-research-paper-from-fab(...) ?

DLFP marche, mais plus personne n'est capable de le faire évoluer. Ca fait des années qu'il y a des entrées dans le tracker qui devraient être faites (voter pour les journaux, pouvoir éditer ses journaux, OpenID, le planet, captcha trop difficile, etc.). Si ce n'est pas fait, ce n'est pas par manque de temps, mais bien à cause du framework (templeet). En rails, ca ferait longtemps que ca aurait été fait.

DLFP, qui utilise PHP (le langage) et templeet (le framework), n'est pas forcément un très bon exemple. Je pense que je pourrais convertir des gens à RoR rien qu'en leur montrant certains templates utilisés.

Sinon, DLFP serait un très bon candidat pour passer sous Rails. Le seul obstacle, c'est la quantité de code à migrer (on parle de 30 000 lignes de code pour les templates) par rapport au peu de temps libre dont les admins dispose.

A mon avis, la période du buzz autour de rails est passée. Rails a été le premier à proposer pas mal de choses qui ont été maintenant reprises dans la plupart des frameworks MVC actuels.

J'aurais tendance à penser que Rails a toujours un coup d'avance sur les autres frameworks. Etant parti plus tôt, il est le premier à arriver à maturité (d'après ce que j'ai entendu, les frameworks PHP, ce n'est pas encore cela, pour les autres je ne sais pas). Il possède également une communauté plus importante que les autres frameworks, ce qui lui permet également d'avoir un grand nombre de plugins (cf [http://agilewebdevelopment.com/plugins/list]).

J'ai également l'impression que Rails est toujours le leader, même si c'est nettement moins marqué que par le passé. Par exemple, Rails a tranché pour REST (contre SOAP), et je ne serais pas surpris que cela devienne la norme pour les frameworks l'année prochaine. Sur les tests unitaires, Rspec [http://rspec.rubyforge.org/] me semble également très en avance sur ce que l'on peut trouver ailleurs.

Enfin, je préfère largement Ruby à PHP, mais c'est un choix tout personnel :)

J'ai un peu de mal à voir à quoi correspond le design pattern data mapper, mais il existe d'autres ORM en Ruby en dehors d'Active Record. Citons par exemple DataMapper [http://datamapper.org/] et Sequel [http://sequel.rubyforge.org/].

D'autre part, quitte à ne pas utiliser Active Record, ca peut valoir le coup d'essayer d'autres frameworks en Ruby comme Merb [http://merbivore.com/].

http://www.liveror.com/

Pour la vision du projet, elle est décrite en une seule phrase sur de nombreuses pages du wiki comme [http://chandlerproject.org/Projects/ChandlerGlossary] et [http://chandlerproject.org/Projects/FAQ] :

Chandler Project is an open source, standards-based personal information manager (PIM) built around small group collaboration and a core set of information management workflows modelled on Inbox usage patterns and David Allen's GTD methodology.

Par contre, il me semble que le projet Chandler ne se revendique de la méthodologie GTD que depuis peu de temps et qu'elle serait plus utilisée dans les fonctionnalités du produit que pour son développement (ie les utilisateurs de Chandler pourront l'utiliser comme un outil de GTD).

Bien sur qu'un peu plus d'agilité aurait aidé le projet Chandler. Mais, il faut voir que Mitch Kapor voulait faire de Chandler un projet totalement révolutionnaire sans trop savoir ce que cela donnerait : il y avait juste quelques idées fortes, mais pas de fil directeur.

Après, il y a eu un manque certain de réalisme sur les délais que cela allaitprendre, mais je crois que c'est dans la nature humaine que de sous-estimer le temps que va prendre un projet (qui ne s'est jamais dit "bon, là, je torche vite fait un script en 5 minutes", et s'est retouvé quelques heures plus tard toujours sur ce même script ?).

Tout ceci est expliqué dans le livre "Dreaming in code" dont je recommande vivement la lecture.

Si, les méthodes d'OCR sont très efficaces. Par exemple, http://sam.zoy.org/pwntcha/ est bien plus fort que la majorité des humains pour le captcha de linuxfr.org.

Le code de linuxfr.org est déjà disponible en passant par le plan https://linuxfr.org/plan/ ou directement sur https://linuxfr.org/linuxfr-snapshot.tar.bz2 (âme sensible s'abstenir, c'est du templeet).

On a le droit de critiquer les admins. Je faisais juste remarquer que Pascal Terjan, en tant qu'admin, aurait pu déplacer lui-même son propre journal.

D'un autre coté, il n'a pas de raison de le faire. Les journaux sont fait pour poster ce que les gens veulent (sous quelques conditions comme respecter la loi et avoir assez de XP).

Il est même admin.

linuxfr.org accessible en IPv6 ? c'est pour bientôt ?

A ma connaissance, ce n'est prévu. Mais ce n'est pas la bonne question à se poser. Si tu veux vraiment que les choses changent, demande toi ce que tu peux faire pour aider à ce changement.

Ca peut être monter un site ipv6fr.org (le domaine est déjà pris, mais il en reste plein d'autres disponibles), écrire des tutoriaux sur le passage d'ipv4 à ipv6 (exemple : qu'est ce que l'absence de NAT va changer pour les personnes qui ont une passerelle/firewall sous linux) ou encore écrire des dépêches sur linuxfr.org parlant d'IPv6. Bref, jette toi à l'eau et essaye d'impliquer d'autres personnes avec toi. C'est toujours plus motivant, et ca permet de tenir la distance.

Oui, c'est l'entrée du suivi avec le plus de votes : https://linuxfr.org/tracker/518.html mais c'est très compliqué à mettre en place à cause du cache templeet.

Moi, j'en ai surtout marre des chieurs qui viennent râler à propos des traductions ou de l'orthographe alors qu'ils n'ont pas la moindre dépêche à leur compteur. Oui, vous êtes tous les 2 visés. Proposez des dépêches, et on en reparlera.

Non, on ne peut pas éditer les journaux. Seuls les admins peuvent aller taper dans la base MySQL et le cache templeet pour modifier un journal (ce que je viens de faire).

Ho, chouette un troll Perl / Python / Ruby !

Ruby n'apparait pas dans le classement, mais je pense que twitter (ruby on rails) fait plus de traffic que plenty of fish. Et les 9 sites les plus gros, je doute que ce soit un échantillon représentatif de quoi que ce soit.

Pour les blogs, tu sais, ce n'est pas forcément parce que beaucoup de monde le dit que c'est vrai. Quand plein de blogs disent que l'Ipod est le meilleur lecteur mp3, faut pas forcément les croire ;)

Par contre, je suis d'accord avec toi quand tu dis qu'il faut savoir apprendre de nouveaux langages. Pour moi, le prochain sur la liste, c'est erlang.

Pour le nombre de modules, la différence avec ruby n'est plus un argument. Perl a plus de modules que Ruby, mais ca reste du même ordre de grandeur.

Hop, une référence pour faire sérieux : http://www.oreillynet.com/ruby/blog/2007/09/rubyforge_vs_cpa(...)

2 journaux à ce sujet : https://linuxfr.org//~jpph/25526.html et https://linuxfr.org//~destop/25497.html