Bruno Michel a écrit 3285 commentaires

Oui, c'est prévu mais pas encore fait. La difficulté n'est pas de faire cela en RoR, mais encore une fois du coté de templeet. On ne connait pas de liste (même approximative) de URL existantes. Oumph a commencé à regarder pour parser les logs d'apache2 pour ça, mais je ne sais pas trop ce que ça a donné.

> je crains que le choix de RoR oblige à mettre en place une artillerie d'outils supplémentaires pour tenir la charge du site (redis et autres astuces....) et c'est assez long à mettre en place.

Oh que non, ça, c'est la partie simple et sympa à faire. C'est vraiment de la rigolade par rapport à l'import des donnés existantes. J'ai passé facilement 10 fois plus de temps à créer et tester le script d'import [http://github.com/nono/migration-linuxfr.org] qu'à m'occuper des questions de performances de Rails, et je vais encore avoir pas mal de travail sur ce script.

Il me semble que cette solution n'a pas été retenue pour des questions de sécurité. Il aurait été possible de s'en servir pour envoyer des spams, forger des requêtes HTTP POST, outrepasser le Single-Domain Policy, accéder à des services locaux qui ne tournent que sur 127.0.0.1 justement pour ne pas être accessible depuis ailleurs, etc.

Bref, la sécurité dans le monde du web est déjà bien assez compliquée comme cela. Je suis bien content que ce ne soit pas la solution retenue.

> Est ce que la nouvelle version de linuxfr.org utiliseras Unicorn?

Je ne sais pas encore. J'étais plutôt parti pour thin, mais Unicorn est intéressant aussi. Va falloir que je regarde pus en détails les deux.

Alors, comme je ne connais pas bien FastCGI, je vais avoir du mal à répondre.

Je constate juste qu'en pratique, les serveurs applicatifs qui utilisent HTTP sont en train de remplacer FastCGI et qu'ils ont l'air plus performants.

Ça fait beaucoup de questions d'un coup, mais je vais essayer d'y répondre.

Tout d'abord, je me rends compte que ma dépêche pourrait laisser à penser qu'Unicorn est un concurrent d'apache2 ou de nginx. Ce n'est pas le cas, il est utilisé pour du contenu dynamiques, pas pour servir des ressources statiques.

Les mod_* pour apache, ça existe aussi dans le monde Ruby : ça s'appelle phusion passenger. Il existait auparavant un mod_ruby, mais il n'est plus maintenu et personne ne l'utilisait car il avait des performances désastreuses.

Mais ces solutions ne conviennent pas à tout le monde : certains utilisent d'autres serveurs web comme nginx, d'autres vont faire tourner les applications Rails sur plusieurs serveurs et n'ont pas envie de faire tourner apache sur tous ces serveurs, etc. Ces contraintes se rencontrent généralement sur des sites à fort trafic pour lesquels on cherche à séparer les problématiques pour différentes raisons : meilleures performances, plus facile d'isoler les bugs, maintenance plus aisée, etc. Pour arriver à cela, le serveur applicatif va servir des requêtes HTTP dynamiques très rapidement.

On le place derrière un reverse-proxy pour un tas de raisons (sécurité, bufferiser les uploads, etc.) mais surtout pour éviter qu'il ne serve les fichiers statiques (nginx, ou à défaut apache, fait ça bien mieux).

Maintenant, pourquoi utiliser HTTP plutôt que CGI ou FastCGI pour communiquer entre le reverse-proxy et les processus applicatifs ? J'aurais envie de dire que HTTP est un protocole connu qui convient bien pour ça, alors pourquoi utiliser autre chose ?

Pour WSGI, il n'a pas vraiment sa place avec CGI ou fastCGI, c'est une interface pour les applications Python qui définit quelle fonction appeler (et comment) quand une requête HTTP arrive. Sous le capot, ça peut utiliser un mod_ pour apache, du CGI, du fastcgi, etc.

En bref, nous avons quasiment une équivalence un pour un entre le monde Python et le monde Ruby :
mod_python <-> mod_ruby (tous les 2 RIP)
mod_wsgi <-> phusion passenger
wsgi <-> rack
gunicorn <-> unicorn

PS : j'ai pris exemple sur Python, car en dehors de Ruby, c'est ce que je connais de mieux.
PS2 : on a un bonus quand on arrive à caser 3 liens pertinents vers des dépêches LinuxFr.org que l'on a soi-même rédigé dans les 3 derniers mois ?

Je n'ai pas tout essayé, mais à première vue, PDF.js est bien plus sommaire que les équivalents Ruby. Ce qui est compréhensible, car le projet est également beaucoup plus jeune.

DSL == Domain Specific Language

http://fr.wikipedia.org/wiki/Domain-specific_programming_lan(...)

L'hébergement coûte entre 12 et 23€ par nuit. Les détails sont sur http://2010.rmll.info/Hebergement-organise-par-les-RMLL.html et les réservations se passent sur https://reservation.rmll.info/

> Par exemple, il faut modifier la configuration de son serveur SVN si il n'est pas sur la même machine que trac.

On peut également utiliser svnsync.

> vous pouvez fermer un ticket en ajoutant sa référence dans le message de subversion.

Pour ceux qui voudraient faire la même chose avec trac, c'est faisable en suivant http://trac.edgewall.org/wiki/TracFaq#can-trac-automatically(...)

> Bref, je reste avec redmine pour l'instant.

Dis, dis, tu nous fais une dépêche sur Redmine ?

C'est ce qu'il fait : http://www.wzdftpd.net/blog/images/oowall_02.png

Je suis admin et je ne participe donc pas au concours. Et de toute façon, J'ai déjà la plus grosse (7 jours de suite).

Je suis d'accord avec toi, la communauté Ruby et surtout Rails propose de nombreux choix, et ce n'est pas évident de tout suivre. Pour ne rien arranger, il est assez difficile de savoir si un projet va être bien maintenu et suivre les nouvelles versions de Ruby ou Rails.

Mais on peut aussi voir ça comme une force : cela permet de tester de nombreuses approches, et de garder les meilleures idées.

Pour devise [http://github.com/plataformatec/devise/], j'indique dans la dépêche qu'il est développé par José Valim, un des membres de la core team de Rails. Vu que la société qui l'emploie, plataforma, est très impliquée dans la communauté Rails, je pense que l'on peut considérer que Devise est la solution d'authentification la plus pérenne pour Rails.

Pour Rspec, oui, ça vaut le coup de regarder cet outil. Par exemple, la version RoR de LinuxFr.org aurait bien besoin de quelques specs supplémentaires ^^

J'ai essayé de corriger la dépêche, et j'espère qu'elle veut encore dire quelque chose. Si des lecteurs ont des propositions pour l'améliorer, n'hésitez pas.

> C'est vraiment quoi l'objectif à promouvoir Apple ici, sur un site pourtant qui affiche en grand Linux et GNU ?

Je n'ai vraiment pas l'impression de promouvoir Apple en publiant une dépêche telle que celle-ci.

De manière plus générale, le site vise à promouvoir Linux et les Logiciels Libres (et pas uniquement GNU). Apple participe au Libre, il est donc logique que des dépêches parlant de ces logiciels soient acceptées.

Nous souhaitons également alerter nos lecteurs lorsque certains acteurs tiennent des positions dangereuses pour le Libre ou l'Internet ouvert (ce qui serait une menace au Libre). Nous acceptons donc aussi les dépêches à ce sujet, et cette dépêche rentre clairement dans cette catégorie.

> Et là, pas moyen de voir le captcha !

Je viens de regarder rapidement pour le popup, je ne vois pas d'où vient le problème. J'ai créé une entrée de suivi : http://linuxfr.org/tracker/1129.html . Je t'encourage à commenter dessus pour nous donner un peu plus d'informations : navigateur, OS, extensions pour bloquer les publicités, etc.

Vivement la version RoR que ce captcha disparaisse.

> Comment fait-on pour héberger sa CSS sur le site de linuxfr ?

Le moyen le plus simple reste de nous contacter [http://linuxfr.org/moderateurs/].

> Moi, au contraire, je trouve plus agréable de ne pas avoir le commentaire en question directement collé au sommet de la fenêtre mais, en tout état de cause, ce n'est pas dû à ma C.S.S. (ou, en tout cas, pas à ma connaissance).

De manière très empirique, je dirais que ça vient du margin sur le body. Le javascript a l'air de ne pas en tenir compte pour calculé la position à laquelle se déplacer.

Le gros inconvénient de sshfs, c'est que les fichiers se trouvent uniquement sur le serveur, pas en local. Du coup, quand tu veux ouvrir un gros fichier, c'est lent et tu n'as plus accès à tes documents quand tu es dans le train.

;-)

> pour cela il faut etre le seul a modifier un enreg et donc poser un lock/verrou, mais il faut aussi prévenir les copains que cet enreg est verrouillé ...

Il faut effectivement être le seul à modifier un document, mais je ne vois pas pourquoi il faudrait poser un verrou. MongoDB supporte les opérations atomiques [http://www.mongodb.org/display/DOCS/Atomic+Operations].

La contrainte que MongoDB relâche est la durabilité (D). Bien que cette contrainte soit importante en théorie, je ne suis pas du tout convaincu que cela apport beaucoup en pratique. Les bases de données ne plantent quasiment jamais, les problèmes sont généralement d'origine matériel. Du coup, si on a un seul serveur, et que celui-ci lâche, il faudra de toute manière repartir de la dernière sauvegarde.

> apparemment ce style de base est fait pour gérer des versions et stocker les modifications

Tu ne parles pas de CouchDB là ?

> Bien souvent ça peut être remplacé par un montage réseau non (nfs, sshfs,...) ?

Pas vraiment. Nfs, je ne me vois pas le mettre sur internet, et sshfs est très lent. Et SparkleShare a également quelques autres avantages : notifications, documents versionnés, pas besoin d'être root pour le mettre en place, bientôt utilisable sous windows et OSX.

> faire des choses utiles, sympa, instructives

Mais en quoi c'est utile/sympa/instructif d'assister à des confs sur des sujets dépassés (microformats), pour lesquels ils existent des tonnes de livres et articles en ligne (javascript, les tests) ou ennuyeux (Débuter en PHP : je n'ai rien contre les débutants, mais ce n'est pas une session qui va suffire, autant leur faire une journée réservée) ?


> Les critères qui semblent important c'est surtout "professionnel", "utilisé" et "php".

Je ne dois pas attendre la même chose des confs. Si c'est pour faire dans le "professionnel" et "utilisé", ça va, j'ai déjà de quoi faire tout le reste de l'année. Si je vais à des confs, c'est pour apprendre de nouvelles choses, découvrir des sujets que je ne connais pas, avoir de nouvelles inspirations, bref devenir meilleur en cassant la routine.

C'est ce qu'il disait. La démonstration extrêmement rigoureuse est la suivante :

SQL != BDD
(Univers - SQL) != (Univers - BDD)
NoSQL != NoBaseDeDonnées

> Par contre certain cas comme la gestion de stock dans un environnement multi user je vois pas comment on peu faire sans SQL

Je ne vois pas ce qui empêcherait de le faire avec une base de données documents comme MongoDB ou un stockage de type clé-valeur comme Redis.

> ya t il des base de données OBJETS que vous connaissez qui tiennent la route ?

Des bases objets, non, mais des bases de données documents, oui. Je pense notamment à MongoDB : http://www.mongodb.org/ .

Oui, d'ailleurs, pour citer http://dev.af83.com/nosql/nosql-et-apr%C3%A8s/2010/04/12 :

« Textuellement, NoSQL est l'abréviation de Not only SQL, pas seulement SQL. »