Bruno Michel a écrit 3285 commentaires

> Est-ce que j'ai réellement bien compris le système de "persistance" ?

Redis propose deux modes. Dans le premier, il recopie de temps en temps tout ce qu'il a en mémoire vers le disque dur. Cela convient bien pour une utilisation de type 'cache' (si on perd les données entre deux écritures, ce n'est pas grave).

Dans le second mode, il va aller faire une écriture sur le disque systématiquement, et cette écriture se fait en mode append-only pour éviter tout risque de corruption du fichier. Cette technique est donc beaucoup plus fiable que la précédente, mais les performances sont nettement moindres.

J'aurais tendance à recommander Redis pour de nombreux usages, mais pas pour des données sensibles comme des informations bancaires.

> J'ai l'impression qu'il n'y a pas de notion de vérou par ligne/par clé

Il n'y a effectivement pas de verrou par clé. En pratique, cela ne m'a jamais manqué car les opérations proposées sont riches fonctionnellement (et bien entendu atomiques). Par exemple, il est possible d'incrémenter une valeur et récupérer la nouvelle valeur en seule commande (INCR).

> Ben non, il ne devine rien, puisqu'on lui dit de façon explicite avec l'utilisation de "rpush". C'est pas un reproche sur le produit, hein, mais juste que je ne vois rien de magique là-dedans.

Il n'y a effectivement rien de magique. Je voulais juste montrer qu'il n'y a pas besoin de déclarer le type d'une valeur avant de l'utiliser.

> L'équipe de Linuxfr les a-t-elle testés ?

Oui, et ce n'était pas très concluant. Par exemple, awstats a besoin de tourner pendant plus de 12h par jour pour générer les stats, ce qui n'est pas acceptable.

Heu, le site existe déjà (c'est le site de l'association Ruby France), et je suis également actif dessus. Par exemple, j'ai écrit la dernière dépêche sur le site (celle qui parle de Ruby 1.9.2). Mais je ne vois pas ce que cela vient faire ici. Cette dépêche parle de Redis, une base de données de type clé-valeur que l'on peut utiliser avec de nombreux langages : python, php, perl, java, erlang, clojure, scala, C, C#, javascript, Lua, Go, Haskell, Io et bien sûr Ruby (plus ceux que j'ai oublié).

Je n'utilise pas Emacs, mais on m'a dit sur IRC qu'il y a un module org-habit dans org-mode qui fait la même chose.

Il a été annoncé sur le site d'OSDC.fr [http://act.osdc.fr/osdc2010fr/cfp.html] et relayé à divers endroits, mais pas sur LinuxFr.org.

La conférence en elle-même n'est pas orientée web, mais il est vrai que les interventions proposées le sont. Il ne tient qu'à vous, lecteurs de LinuxFr.org, de proposer des confs sur des sujets plus variés.

Je ne connais pas Dancer, mais je vais m'appuyer sur mon expérience de Rails vs Sinatra pour répondre.

Un framework léger, comme Dancer et Sinatra, c'est bien pour :
* faire rapidement un petit site de démo, un proof of concept, essayer rapidement quelque chose (exemple : essayer redis lors d'un atelier d'une demie-journée)
* ajouter une interface web à une application existante (exemple : gembox fournit une interface web pour consulter la doc des gems Ruby et son code réutilise intelligemment Rubygems)
* développer une application avec un nombre limité de fonctionnalités, surtout si elles ne s'appuient pas sur une base de données (exemple : Gollum, un wiki qui utilise un dépôt git)

Par contre, Rails est bien mieux adapté pour un site web avec pas mal de fonctionnalités et qui va évoluer dans le temps. En gros, dès que l'on pense que l'on va avoir plus de 3 ou 4 fichiers, Rails apporte une structuration intéressante là où ça peut vite devenir le bordel avec Sinatra.

Oui, bien vu :-)
Je corrige la dépêche.

Non, il n'existe pas d'appel système pour faire de la résolution de noms. Les applications font généralement appel à la libc pour ça, mais dans certains cas assez rares, l'application fait elle-même la résolution de nom à sa sauce (en ignorant alors les fichiers /etc/hosts et /etc/resolv.conf).

Oui, c'est d'ailleurs comme ça que feront la plupart des vilains qui n'ont pas envie de payer 5$.

> alors pourquoi tu fermes à clef ta voiture ou ta maison en la quittant?

Pour ma part, uniquement pour pouvoir faire jouer l'assurance si on me cambriole.

> je veux bien un peu d'éclairage à ce sujet!

OK, voici mon point de vue :

Google prépare son Chrome Web Store. Celui-ci repose sur la galerie des extensions Chrome et nécessite de pouvoir faire payer les développeurs d'extensions. Dans ce cadre, il va aussi être intéressant d'avoir des extensions officielles pour certaines marques. Google a donc développé ces deux fonctionnalités pour le Chrome Web Store. Ensuite, je ne sais pas trop si Google a voulu justifier ces 2 nouvelles fonctionnalités ou si quelqu'un s'est dit que ce serait une bonne idée d'utiliser ça pour la sécurité, mais toujours est-il que Google a promu ces fonctionnalités comme des améliorations de la sécurité.

Je ne nie pas que cela va permettre de rejeter des développeurs mal intentionnés, mais cela va aussi dissuader bien d'autres développeurs. Je suis également gêné par le fait que Google explique que ces fonctionnalités ont été pensées pour l'amélioration de la sécurité alors qu'il semble évident qu'elles ont été en premier lieu développées pour le store.

> Je ne connais pas le prix d'une connexion internet ni d'un PC dans les pays du tiers-monde, mais je soupçonne que celui qui sait se les payer ne va pas avoir trop de difficultés à payer 5$.

Les personnes en question n'ont pas forcément payer leur ordi : cybercafés, récupération, ordinateur partagé dans une école, etc.

> Note issue des commentaires (n°3) : il semblerait que les appels à perl (pour les sleep) ont été virés…

Je confirme, le commit est là : http://github.com/wayneeseguin/rvm/commit/a50631bed651f35dc7(...) .On appréciera le message de commit : « Removed the 'fun with perl' items, some people have no sense of humor. »

Pygments est utilisé sur github, et c'est donc par cohérence que les développeurs ont choisi pygments pour Gollum. Maintenant, pourquoi ce choix de pygments pour github ? Je ne sais pas, mais j'imagine que ça doit venir du nombre de langages supportés.

Par exemple, code ray ne fait pas de coloration syntaxique pour les langages de markup comme asciidoc, creole et markdown. Du coup, ça aurait été dommage pour un wiki comme gollum de ne pas avoir de coloration syntaxique sur ses propres langages de markup.

Oui, j'avais même commencé à faire comme ça. Mais je n'arrivais pas toujours à faire ce que je voulais (je ne suis pas très doué pour le scripting shell), et surtout ça faisait des lignes très longues avec plein d'accolades dans lesquelles je me perdais. Du coup, je suis revenu à mon vieil ami, sed, pour faire ça au plus simple/vite.

Dans la dépêche, je ne suis pas entré dans le détail, mais la documentation de RVM explique les différentes méthodes pour l'installer [http://rvm.beginrescueend.com/rvm/install/] et donne la liste des dépendances [http://rvm.beginrescueend.com/rvm/prerequisites/].

On peut, par exemple, installer RVM en tant que gem Ruby, mais ce n'est pas pratique parce que cela demande à avoir un interpréteur Ruby avant d'installer RVM or on souhaite généralement installer tous ses interpréteurs avec RVM.

Pour les implications de sécurité, cette méthode est strictement équivalente à télécharger un tarball, le décompresser et lancer un ./configure && make && make install. C'est pourtant une méthode généralement utilisée et acceptée dans des univers autres que Ruby. Idéalement, RVM serait packagé dans les différentes distributions et on pourrait l'installer grâce à aptitude|rpm|autres. En attendant, je ne vois pas trop ce que l'on peut faire de plus (à part relire tout le code de RVM avant de l'installer).

À propos de la complétion pour zsh, j'ai également écrit un script pour avoir celle-ci pour bundler 1.0 [http://gembundler.com/v1.0/index.html] : http://dev.af83.com/ruby/whyday-zsh-completion-scripts-rvm-a(...)

> Je serais curieux de connaître le nombre de personnes qui ont contribué à Django ou à PyPy (les équivalents de Rails et Rubinius dans le monde Python).

En fait, les réponses étaient à portée de main :
- presque 100 contributeurs pour PyPy (source : http://codespeak.net/pypy/dist/pypy/doc/contributor.html )
- environ 500 contributeurs pour Django (source : http://code.djangoproject.com/browser/django/trunk/AUTHORS )

Cela confirme que Ruby n'a pas de problème particulier vis à vis de Python pour fédérer le plus grand nombre autour de grands projets.

> Perso, passé l'enthousiasme initial ça m'a toujours dérangé que Ruby soit l'oeuvre d'une personne mégalo, qui gère la chose en dictateur intraitable, Y. Matsumoto.

*Cough*, Matz, une perso mégalo ?!??

Pour l'avoir rencontré lors de Solutions Linux en 2009, je peux t'assurer que Matz est tout sauf mégalo. C'est quelqu'un d'extrêmement poli (c'en est même devenu un motto sur des mailing-lists Ruby : Matz is nice, so we are nice), qui met les autres en avant et qui n'hésite pas à dire qu'il a fait des choix regrettables pour Ruby (reprendre toutes les variables $ + un signe de ponctuation de Perl, par exemple). Bref, on peut reprocher des choses à Matz, mais sûrement pas d'être mégalo (pour ça, vaut mieux aller voir du coté de DHH).

> De plus ce qui m'a toujours rebuté avec PERL et Ruby c'est qu'il y a souvent plusieurs façons de faire la même chose.

C'est aussi le cas en Python, mais si les pythonistes diront le contraire. Par exemple, les list comprehensions peuvent très bien s'écrire avec filter() et map().

> Est-ce que cela favorise la compréhension par tous ?

Oui, probablement pour Ruby. Cela permet d'écrire du code de manière courte en choisissant la forme la plus compréhensible.

> Est-ce que cela est à même de fédérer le plus grand nombre autour de grands projets ?

En tout cas, ça n'a pas l'air d'être un point gênant. J'en veux pour preuve les 1600 contributeurs de Rails (source : http://contributors.rubyonrails.org/ ) ou les 150 contributeurs de Rubinius (source : http://github.com/evanphx/rubinius/contributors ).

Je serais curieux de connaître le nombre de personnes qui ont contribué à Django ou à PyPy (les équivalents de Rails et Rubinius dans le monde Python).

Suite à une maladresse d'un des modérateurs, ce journal et les commentaires associés ont été supprimés. Nous avons restauré ce que nous pouvions depuis le backup de cette nuit, mais les commentaires postés aujourd'hui sont définitivement perdus.

Nous présentons nos plus plates excuses pour les commentaires perdus.

De gros progrès ont été faits entre Ruby 1.9.1 et Ruby 1.9.2 en termes de stabilité, mais ce n'est pas évident de chiffrer ça.

Pour les tests unitaires, Ruby 1.9 s'appuie notamment sur la suite de tests RubySpec. 99% de ces specs passent. Le dernier pourcent ne vient pas forcément de problème de stabilité, mais plus de cas particuliers qui sont sujets à discussions.

Les développeurs restaient avec Ruby 1.8 principalement parce que c'était compliqué de migrer vers Ruby 1.9. Ruby 1.9.1 avait tendance à segfaulter un peu trop régulièrement, beaucoup de bibliothèques n'étaient pas compatibles avec Ruby 1.9, faire tourner Ruby on Rails avec Ruby 1.9 était un défi de tous les jours. En plus, il n'était pas forcément facile de faire cohabiter Ruby 1.8 et Ruby 1.9 (il faut éviter de mélanger les gems par exemple).

Mais c'est en train de changer. La version 1.9.2 est nettement plus stable que la 1.9.1. Rails, et tout particulièrement Rails3 qui devrait sortir bientôt, supporte de mieux en mieux Ruby 1.9.

L'arrivée de Ruby Version Manager fait également beaucoup de bien. Il est maintenant très facile d'avoir plusieurs implémentations de Ruby sur une même machine et de passer de l'une à l'autre selon les projets. RVM permet de lancer facilement les tests unitaires d'une bibliothèque avec plusieurs versions de Ruby. C'est, je pense, ce qui a permis à beaucoup de développeurs d'avoir des bibliothèques Ruby qui fonctionnent avec les différentes versions.

Voilà, c'est commité : http://github.com/nono/linuxfr.org/commit/fc12b93a6e49caaa55(...)

Merci.

> Mais comment savoir ce qui se fait ?

Il n'y a pas grand chose pour ça. À la limite, suivre les commits sur github donne une petite idée de ce sur quoi je travaille (mais pas plus).

Si tu souhaites contribuer, la première étape est d'installer la version RoR de LinuxFr.org en local et de regarder le code. Si tu en as le courage, tu peux aussi contribuer quelques tests par la même occasion (le projet en aurait bien besoin). Ensuite, n'hésite pas à me contacter en me disant sur quoi tu voudrais contribuer, j'essayerais de trouver des tâches pas trop compliquées, mais pas trop chiantes non plus que tu puisses faire.