Bruno Michel a écrit 3285 commentaires

Rien n'exclut, certes, mais ça n'est pas non plus encouragé. Par exemple, les technologies autour de PHP semblent être très orientés sur ce qui se passe dans le navigateur, en tout cas, c'est ce que les exemples laissent penser. Et citer les microformats, ouch, j'ai l'impression de revoir le fantôme d'une techno dont je n'avais plus entendu parler depuis 2 ans.

Ha, j'oubliais, dans les sujets à la mode, il y a également les tests A/B et, toujours là, l'agilité (Kanban, Scrum) avec ses outils en ligne (Pivotal Tracker).

Marrant, quand je regarde les thèmes mis en avant, j'ai l'impression de revoir ceux qui étaient proposées il y a 3 ou 4 ans dans les confs Ruby ou Rails. Il manque juste git et Rest à la liste.

Les sujets à la mode maintenant sont plus tournés autour du NoSQL, des modèles événementiels (node.js / EventMachine), des tests automatisés de javascript sans navigateur (capybara, redcar), OAuth, etc.

Bref, je suppose qu'il ne me reste plus qu'à soumettre une proposition « Les technos cools que les gamins utilisent pour vous en mettre plein la vue ».

> offrez simplement la version électronique avec la version papier ça relèvera moins du foutage de gueule.

Si j'ai bien compris, c'est déjà le cas.

Je viens de regarder WebDruid, et j'aurais bien du mal à dire les différences avec Webalizer. Est-ce que tu pourrais m'éclairer sur ce que WebDruid fait de mieux ?

Il faut au moins Rubygems 1.3.6 (pour installer Bundler).

Oui, et il y a sûrement beaucoup de choses à faire de ce coté-là ;-)

Merci pour les retours.

> il manque le paquet rubygems dans la liste des paquets à installer

En fait, je préfère installer rubygems à partir des sources. D'une part, la version dans Debian lenny est trop vieille (idem pour lenny-backports). D'autre part, ça me permet d'installer tout ça dans le $HOME d'un utilisateur (je n'aime pas gérer les gems ruby en root).

> les commandes "bundle" "rails" et "rake" sont dans le répertoire "/var/lib/gems/1.8/bin/"

Oui. L'installation du paquet rubygems ne rajoute pas ce chemin au PATH ?

> pas pu installer le paquet rubyssl avec ma debian unstable mais ça n'a pas l'air de prêter à conséquences

Il me semblait que l'on en avait besoin pour installer un gem (nokogiri ?), mais je peux me tromper.

> Si je dois passer par des messages privées pour lui demander comment réussir à faire tourner le projet, super (non, je n'ai pas réussi en suivant les instructions sommaires de la page du projet et ça m'a vite gonflé).

Instructions sommaires ? Normalement, il suffit de copier-coller les instructions dans une Debian Lenny de base pour que ça marche.

Si quelqu'un me contacte en me disant qu'il a un problème pour l'installer, j'essaye de l'aider et de documenter cela. Mais si personne ne me dit rien, je considère que la documentation est suffisamment bonne pour le moment, et je préfère m'occuper à des choses que je considère comme plus prioritaire.

> Je doute que linuxfr soit éditeur pour ce qui est des journaux.

C'est très difficile à dire. La loi et surtout la jurisprudence à ce sujet sont très difficiles à interpréter. J'aurais également tendance à penser que nous ne sommes pas éditeur, mais je ne prendrais pas les paris qu'un juge puisse être de l'avis contraire.

> PS: Moi, je suis un fainéant, j'accepte les patchs sans problème.

Pareil, j'ai accepté la totalité des patchs^W^Wdu patch que l'on m'a proposé pour la version RoR de LinuxFr.org.

Tu ne bloquerais pas le REFERER par hasard ?

Une base de données clés-valeurs va gérer des accès concurrents, stocker les informations sur le disque et fournir d'autres services autour de l'accès aux données.

Une table de hachage est un algorithme pour implémenter cela. Par exemple, Kyoto Cabinet utilise des tables de hachage quand on spécifie une base de type HashDB. Mais ce n'est pas le seul moyen de faire ça. Par exemple, on peut aussi utiliser des B-trees.

Kyoto Cabinet est une réécriture complète de Tokyo Cabinet. Grosso modo, elles font la même chose, mais Kyoto le fait mieux, surtout sur les machines avec plusieurs cores. La présentation au format PDF de Mikio explique cela sûrement mieux que moi : http://1978th.net/kyotocabinet/kyotoproducts.pdf

Dans ce cas, on est bien d'accord :-)

Je trouve également que l'utilisation de pages web pour faire tout et n'importe quoi ne va pas dans le bon sens. Autant j'accueille l'arrivée de certaines fonctionnalités d'HTML5 avec joie (balise vidéo, types email, url ou tel dans les formulaires), autant l'arrivée de WebGL, de bases de données dans les navigateurs ou encore d'API de géolocalisation me font froid dans le dos.

HTTP + HTML + CSS + JS est une combinaison très bien adaptée pour faire des pages web : des contenus et des formulaires pour interagir. De là à vouloir l'utiliser pour faire des applications, je peux comprendre que des personnes soient tentées, mais ça m'a l'air d'être une très mauvaise idée sur le long-terme.

Par exemple, les navigateurs ont déjà bien des problèmes de sécurité à l'heure actuelle (http://dbaron.org/mozilla/visited-privacy ou http://scarybeastsecurity.blogspot.com/2009/12/generic-cross(...) par exemple). Qu'est-ce que cela va donner quand ils vont se transformer en plateforme d'exécution d'applications ?

> Dans l'abstract, ils disent que c'est pour des pages web. J'ai vraiment rarement vu des pages web qui sont pas en HTTP. Et quand bien même, aujourd'hui (X)HTML et HTTP sont couvrent de plus en plus de choses et websocket est là pour pallier à un énorme problème : « Comment faire de la connexion bidirectionnelle quand on utilise des trucs pas fais pour ? »

La réponse du w3c et IETF a été de proposer un nouveau protocole, WebSocket. Mais ta remarque me fait douter : tu reproches aux développeurs d'utiliser HTTP pour contourner les firewalls ou plus généralement d'utiliser des pages web pour tout et n'importe quoi ?

> J'attends le patch du noyau qui simplifieras la pile IP en retirant tout les trucs qui servent à rien (qui laisseras uniquement le port 21, 22 et 80).

Petite précision, les numéros de ports sont une information TCP, ça ne fait pas partie de la pile IP. Sinon, quitte à ne garder que 3 ports, je préfère perdre le 21 au profit du 443 (HTTPS). Oui, ça fait encore plus de HTTP pour le coup ;-)

Je ne suis pas d'accord. Je trouve cela très réducteur que de considérer que les développeurs choisissent et utilisent HTTP que pour passer au travers des firewalls sans problèmes.

Déjà, faire un protocole réseau est quelque chose de compliqué, et utiliser un protocole existant et éprouvé est sûrement préférable à en recréer un bancal juste pour le plaisir, et sans une gestion sérieuse des erreurs parce que l'on n'aura pas eu le temps. Cela permet également de bénéficier des bibliothèques existantes aussi bien pour faire la partie serveur que la partie client. C'est aussi un avantage si de nouveaux développeurs doivent apprendre à s'en servir : tout le monde sait ce qu'est une erreur 404.

Ensuite, HTTP est un protocole qui présente de nombreux avantages. Par exemple, les admins sys, en cas de montée en charge, auront à leur disposition des load balancers connus, sauront mettre en place un reverse-proxy, etc. Les développeurs pourront également profiter des directives de cache (etags, conditional requests).

Bref, je ne pense pas que l'on doit utiliser HTTP pour tout et n'importe quoi, mais c'est très souvent préférable d'utiliser HTTP plutôt que d'inventer un nouveau protocole.

PS : dire que WebSocket n'a d'intérêt que pour tout faire en HTTP est assez étrange, vu que WebSocket est justement un protocole de communication qui n'est pas du HTTP (en plus d'être une API).

En gros, Websocket, c'est une connexion TCP où l'on commence par s'échanger des headers HTTP puis il y a quelques marqueurs pour que les navigateurs sachent quand ils doivent déclencher des événements javascript. Puis, il y a une description de l'API qui les navigateurs doivent implémenter.

Oh, le joli troll !

Pour ma culture, j'aimerais bien connaître l'équivalent de Sass en python (ce serait pour un projet django).

Oui, j'ai écrit la dépêche vendredi avant ces sorties, mais avec le serveur qui était down ce week-end, elle n'a été modérée que aujourd'hui. Ça sera pour une prochaine dépêche ;-)

Non, on a qu'un seul serveur, mais c'est le notre. Voyages-sncf doit de son coté avoir une jolie ferme de serveurs : une vingtaine sous windows il y a deux ans d'après http://www.tgvlab.com/voyages-sncf-et-vous/un-service-publiq(...) .

Sinon, je vous encourage à voter pour la mise en place d'API ouvertes : http://www.tgvlab.com/voyages-sncf-et-vous/un-service-publiq(...)

Surtout celles de Boa Treize en ce moment ;-)

> L'utilisation de LLVM permet-t-il à Rubinius de compiler du code Ruby comme Clang le fait ?

Pas à ma connaissance, mais peut être qu'en creusant un peu, c'est possible.

> Parce que la distribution des scripts Ruby est une vraie misère (surtout dans l'univers Windows)...

Il existait un programme qui permettait de créer un exécutable windows à partir du code Ruby et qui embarquait l'interpréteur Ruby et les dépendances. Du coup, ça faisait un .exe que l'on pouvait lancer sur n'importe quel windows sans avoir rien à installer auparavant. Je ne me rappelle plus du nom de ce programme, et je ne saurais pas dire s'il est encore maintenu (la dernière fois que je l'ai croisé, ça doit remonter à 3 ou 4 ans).

> Rubinius c'est donc l'équivalent Ruby de PyPy non ?

Je ne connais pas très bien PyPy, mais ça m'en a tout l'air.

D'ailleurs, des rubyistes pensent que Rubinius est l'avenir de Ruby, et je viens de tomber sur un billet qui dit que PyPy est le futur de Python : http://alexgaynor.net/2010/may/15/pypy-future-python/

Ruby 1.9, anciennement YARV, a pour objectif premier les performances, et a fait des concessions sur d'autres points pour y arriver (casser la compatibilité avec Ruby 1.8 par exemple). Rubinius cherche également à devenir une implémentation performante de Ruby, mais a également d'autres buts : un maximum de code doit être écrit en Ruby, par exemple.

D'un point de vue technique, Ruby 1.9 est écrit majoritairement en C, avec quelques classes de la bibliothèque standard en Ruby. Rubinius est écrit en Ruby, et là où ce n'est pas possible d'utiliser du Ruby, en C++. Les 2 VM ont également des bytecodes différents.

En pratique, cela veut dire qu'il est peu probable que les 2 projets échangent beaucoup de code, mais les développeurs partagent les idées et retours d'expérience.