Blog them all

On the way on the east cost of Taiwan, we found an empty hotel just next to the beach. No tourists, no locals, just a couple and the husband’s father, the hotel’s owners.

Share This

Vanuatu kids

Qui a dit qu’on ne trouvait pas de bonnes photos sur flickr ? Philippe Lafforgue sur un sujet au Vanuatu, au dos numérique Hasselblad. Quelles couleurs…

Share This

On joue comment aux echecs à Taipei ? Avec des lunettes de soleil, évidemment.

Share This

Certains font les choses correctement, et d’autres ne les font manifestement pas correctement. J’ai déjà évoqué ici le fait que le N800 avait du bon matériel, mais une couche logicielle à chier, je ne reviendrai pas dessus, cependant …

Je suis passablement énervé de voir que Nokia s’est lamentablement ramassé sur leur produit. Ils semblent avoir les sous, les compétences en interne, l’experience de l’embarqué depuis des années, alors comment se fait-il qu’en terme d’ergonomie leur tablette Internet soit si mauvaise? Si vous avez des informations de l’intérieur… Le N800 est-il venu d’une équipe de Nokia qui n’a pas de budget?

D’un côté une IHM sans un seul menu (vous savez, ceux à la Windows), que du drag&drop ; de l’autre chez Nokia, c’est tout l’inverse. Aaah Nokia, tu me tues. Alors évidemment l’iPod est propriétaire, mais s’il marche… Je sens que mon N800 me servira beaucoup moins, et que l’iPod touch me tend les bras. Pourtant, Dieu sait que je déteste les balladeurs MP3 et avoir un truc sur les oreilles, mais pour le Wifi…

Share This

On my way to Seoul I met David Alan Harvey, a Magnum photographer, who posted on his blog about being there for a workshop he was giving to Korean students, and an assignment about Korea than few Magnum photographers were shooting. Well the party with David was great, and lots of Alcohol has been drunk. Anyway, as the fun is better with memories, here is some audio recorded during the party.

As David says : “… and I think I’m a little fucked up …”. Enjoy.

 

 Seoul party with David Alan Harvey [1:34m]: Play Now | Play in Popup | Download

Share This

Les statistiques de UUCPssh montrent que le taux de SPAMs actuels que l’on filtre a très fortement augmenté. À l’heure ou j’écris ce billet, on a sur la semaine et seulement pour nouveur serveur (la plupart des utilisateurs n’ont pas migré) 21,377 messages acceptés pour 382,097 refusés. Cela fait 95% de messages refusés… D’autres ont remarqué la même chose ?

Share This

On fait quoi sur une île de Taiwan ? On nage, évidemment, et on regarde les autres pecher.

Share This

Ce qui occupe mon temps libre (j’en ai pas beaucoup) actuellement :

• Réécriture du générateur d’identification auth_generator en plugin, nommé auth_workflow. Le système de cookie est conservé, le format de la base de donnée aussi, mais le tout passe en plugin pour permettre de modifier le plugin pour ses besoins personnels, tout en continuant de mettre à jour en conservant ses propres modifications. La partie gestion des utilisateurs se fera par le plugin active_scaffold (tache rake pour générer les templates d’administration). Sera disponible dès le départ la gestion de roles, de taches et d’utilisateurs. Les roles seront hierarchisés pour permettre d’avoir User > Moderator > Administrator. Les taches seront détectés automatiquement sous la forme Controller::Action. Bientôt disponible …
• Écriture d’un script greasemonkey (déjà fait) couplé à un daemon local (en cours) pour permettre d’écouter la musique envoyée sur binsearch.info, le tout en cliquant sur un bouton “écouter”.
• Réecriture de LinuxFr en Ruby on Rails, avec en tête l’idée de pouvoir tenir la charge actuelle du site (importante…). Bon ce n’est pas en première priorité mais quelques templates sont faits, ainsi que des tests de transfert de la base actuelle. Mais il faudra d’abord que auth_workflow soit terminé.

Share This

Les gestionnaires de source (SCM) il y a quelques années étaient centralisés (CVS, puis Subversion) mais on a désormais des outils bien plus puissants, décentralisés, et qui permettent plus de souplesses (DSCM). Ils sont de plus bien plus rapides. Parmi les acteurs actuels du marché, on a deux gagnants potentiels : GIT, développé en C et utilisé par le noyau Linux (et développé initialement par Linus lui-même) et Mercurial, développé en Python et qui semble plus propre et plus facile d’accès que GIT (on a eu arch, SVK, bazaar, mais ils ne semblent plus aussi actifs).

version divx de la vidéo.

Pour ceux qui sont intéressés par ces GIT, cette vidéo est à voir. Git a été développé par Linus lui-même après avoir utilisé BitKeeper pendant plusieurs années. BitKeeper est propriétaire, mais leurs auteurs autorisaient les projets “open source” à utiliser gratuitement ce gestionnaire. D’après Linus, c’était le seul outil utilisable pour le noyau Linux, et comme il préfère utiliser un logiciel propriétaire qui marche, plutôt qu’un projet libre qui ne marche pas (et moi donc)… (note : le résumé de la vidéo est que Linus déteste CVS, SVN, qu’il apprécie BitKeeper (sur lequel il a globalement pompé les workflows), et que ceux qui ne sont pas d’accord avec lui sont stupides et laids).

Néanmoins comme la levée de bois verts était de plus en plus importante au sein de la communauté et les tensions qui en découlaient de plus en plus pesantes, les auteurs de BitKeeper et Linus ont convenu qu’il fallait mieux que Linus se mette à utiliser autre chose. Après avoir regardé les gestionnaires de sources qui soient :

1. distribués
2. rapides (performants)
3. puissent assurer que le code injecté soit correct lors de son téléchargement ultérieur (sécurité du code)

… et il n’en restait aucun (monotone se rapprochait de ça, mais était bien trop lent d’après Linus). Il a donc commençé à développer GIT en C, pendant qu’en même temps le projet Mercurial était lançé. Les deux ont les mêmes objectifs, et ils ont tous les deux beaucoup évolué depuis. Mozilla utilise Mercurial (liste des projets qui utilisent Mercurial), pendant que le noyau Linux utilise GIT.

Comme l’indique Thomas, Linus passe un peu trop son temps à cracher sur les outils concurrents, mais ceux qui lisent Linus depuis longtemps connaissent son attitude de “tout le monde a tort sauf moi” (mais ça ne l’empêche pas d’être parfois vrai). La vidéo de Linus est aussi évoquée dans ce billet avec quelques commentaires intéressants,

Dans la vidéo Linus évoque des points qui sont tellement vrai, et qui résume l’importance du distribué pour ces outils (et qui s’applique à GIT comme à Mercurial):

• On travaille sur une nouvelle fonctionnalité. On pense qu’elle nous prendra 6H, mais en vérité on ne le sait pas vraiment. À la fin de la journée la fonctionnalité n’est pas terminée, et au final on aura mis 3 jours. Entre temps on n’a fait aucun commit pour ne pas casser le repository central ou avoir une instabilité du repository qui fera gueuler tous les autres développeurs. Avec un DSCM on peut commiter tranquillement dans sa version locale, pour envoyer les modifications une fois tout le code testé et terminé. On peut même envisager de développer cette fonctionnalité dans une branche locale invisible aux autres développeurs, et continuer de développer la branche principale indépendemment si besoin est.
• La gestion de branches centralisées (comme avec SVN ou CVS) est un vrai problème. Comme tout le monde les voit, et on n’en fait donc pas souvent, pour ne pas polluer le repository central. De plus on n’a pas forcément envie que les autres développeurs voient certains travaux temporaires. En décentralisant la gestion des sources, on peut enfin commiter en étant déconnecté (et faire tout le reste). On peut avoir des branches locales pour tester de nouvelles fonctions, sans polluer les autres. On peut même envisager une branche par fonctionnalité.
• Avec un DSCM on peut prendre un logiciel libre et en diffuser une version modifiée si l’auteur du logiciel n’a pas voulu intégrer nos fonctionnalités, et continuer de développer sur sa version locale du logiciel tout en mergeant régulièrement la version originelle de l’auteur avec la notre.

Git et Mercurial peuvent être utilisés de multiples manières, à la CVS avec un serveur central sur lequel toutes les modifications sont envoyées, ou sans serveur central. La méthode qui semble être utilisée par les utilisateurs de GIT et qui s’adaptera bien pour les projets “Open Source” (Logiciels Libres) est d’avoir votre repository privé sur lequel vous travaillez et vous commitez (votre machine du bureau probablement), puis un serveur public sur lequel vous “pushez” vos travaux une fois que vous souhaitez les diffuser (et accessoirement qui vous sert de backup de vos travaux). Ce serveur public est accessible en HTTP par les autres contributeurs, et vous y accédez en SSH. Les contributeurs ont la même configuration, et vous envoie des patches par mails (par le biais d’une mailing list par exemple), et pour ceux qui contribuent fréquemment vous ajoutez leur repository public dans votre repository local, pour pouvoir télécharger leur version quand ils vous le proposent (quand ils ont développé une fonctionnalité par exemple). S’il arrivait que vous abandonniez votre projet, un contributeur régulier pourrait simplement proposer aux autres de venir se greffer désormais sur son repository public et plus sur le votre.

Pour les projets propriétaires ou d’entreprises, on peut envisager d’autres configurations. Pour une équipe de 10 développeurs sur un même réseau :

• Chaque développeur a un repository local (rapide pour les accès disque), et il peut envoyer ses commits sur un GIT distant (serveur local utilisé par tout le monde), accessible en HTTP (seulement en local, le réseau entreprise étant évidemment doublement firewallisé) pour les autres développeurs du groupe. On aura donc par exemple http://git.localdomain.com/notre_super_logiciel/user1/projet.git http://git.localdomain.com/notre_super_logiciel/user2/projet.git, etc, pour autant de développeurs. Ça facilitera le backup, il suffira de prêter attention à ce serveur, et non à chaque station de travail (et chaque développeur sera libre d’installer ce qu’il souhaite, Linux Ubuntu, Debian, Mandriva, *BSD, etc).
• Un repository local “maître” sur lequel tout le monde peut se raccrocher. Seul le chef de projet ou les développeurs seniors ont un accès en écriture dessus.
• Une liste de diffusion locale sur laquelle les développeurs envoient leurs patchs, ou proposent de télécharger leur repository personnel public quand ils ont terminés une fonctionnalité.
• Si plusieurs développeurs sont attribués à une fonctionnalité spécifique importante, ils pourront travailler en groupe indépendamment sans gêner les autres développeurs, dans une branche qu’ils se partageront entre eux, ceci sans polluer le repository central “maître”. Par nouvelle fonctionnalité on entend aussi “nouvelle version du logiciel pour voir s’il ne serait pas plus rapide de faire complêtement différent”.

Pour être complet sur les DCSM, il y a une vidéo sur Mercurial mais je trouve son auteur moins percutant, je ne suis pas allé jusqu’à la fin (update: finalement la vidéo est pas mal, allez jeter un oeil), et voici une autre vidéo sur Mercurial de Bryan O Sullivan. Le site de Mercurial est complet, vous y trouverez comment faire vos développements à la manière du noyau Linux, à la manière de CVS (même si c’est déconseillé), ou pour une entreprise avec un développement contrôlé.

Au final mon coeur pencherait plutôt vers Mercurial, qui donne la sensation d’être fait proprement, rapide, avec pas mal de documentations. Et vous, quel outil de gestion de source décentralisé utilisez-vous ?

Share This