Make est l'outil le plus couramment utilisé pour automatiser la production d'un fichier à partir de règles. L'exemple typique est la compilation d'un logiciel à partir de ses sources. Mais Make a des inconvénients de taille, dont :

1. La syntaxe sujette aux erreurs ;
   
2. Les appels récursifs à make posent problème ;
   
3. Le manque de modularité ;
   
4. L'absence d'atomicité de l'application des règles.

Daniel J. Bernstein, l'auteur de qmail et djbdns, a proposé une alternative à Make qu'il a appelée redo, mais celle-ci se présente sous forme de notes et non pas de code.

Avery Pennarun a trouvé ses notes et en a écrit une version en Python sous licence LGPL.

Redo fonctionne avec des scripts shell avec l'extension .do et chacun de ces fichiers décrit une règle. Par exemple, le fichier default.o.do qui servirait à générer des fichiers .o à partir des sources .c correspondantes s'écrirait de cette façon :

redo-ifchange $1.c


gcc -MD -MF $3.deps.tmp -c -o $3 $1.c


DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)


rm -f $3.deps.tmp


redo-ifchange $DEPS

Note : $1 est le nom du fichier cible sans l'extension et $3 le nom du fichier temporaire qui deviendra le fichier cible ($3 sera renommé à la fin de la règle, évitant ainsi de laisser un fichier cible corrompu si quelque chose devait mal se passer). redo-ifchange est une commande servant à déclarer une dépendance.

Rubinius est une implémentation du langage de programmation Ruby, dont le code est placé sous licence BSD. Rubinius permet d'exécuter du code Ruby, mais vise également les objectifs suivants :

• Rubinius est Threadsafe ;
  
• Son code est propre, lisible, facile à comprendre et à étendre ;
  
• Il est fiable et solide (avec l'aide de Valgrind) ;
  
• Et surtout, il apporte les dernières avancées de la recherche sur les machines virtuelles, les ramasses-miettes et les compilateurs à Ruby.

Le développement de Rubinius a commencé en novembre 2006 et, aujourd'hui, une étape importante a été franchie : la sortie de la version 1.0. Celle-ci marque la compatibilité avec Ruby 1.8.7, y compris Ruby on Rails (aussi bien la version 2.3 et que la version 3), Rspec, Rubygems, les bibliothèques Ruby et même une grande partie des extensions codées en C.

D'un point de vue plus technique, Rubinius est écrit majoritairement en Ruby, et pour les parties où ce n'est pas (encore) possible en C++. Il fonctionne avec une machine virtuelle dont le bytecode est transformé en code machine à l'exécution grâce à LLVM et utilise un garbage collector générationnel, précis et compactant. Et pour ceux qui seraient d'humeur taquine, je ne résiste pas à l'envie de mettre un petit lien vers un benchmark. Vous pouvez voir que Rubinius est l'implémentation Ruby la plus rapide, ou du moins, l'était en janvier quand le benchmark a été fait.

Si vous êtes convaincus, vous pouvez installer Rubinius soit en suivant les instructions officielles, soit en utilisant Ruby Version Manager. Je recommande d'utiliser la seconde solution, car RVM vous permet d'installer plusieurs implémentations de Ruby sur la même machine, d'installer des gems pour chacun d'eux et de passer d'une implémentation à l'autre sans problème.

Ruby est un langage de programmation génial (je vous assure, je suis totalement objectif quand je dis ça ;-) ), mais qui a quand même quelques petits défauts. On peut par exemple citer la mauvaise prise en charge de la concurrence ou l'absence de rechargement de code à chaud. À l'opposé, Erlang a une syntaxe parfois cryptique mais sa machine virtuelle est très avancée pour tout ce qui concerne les aspects distribués, la concurrence et la tolérance aux erreurs.

Reia est un langage de programmation qui cherche à prendre le meilleur des 2 mondes (licence MIT). Le code en reia ressemble à s'y méprendre à du code Ruby, mais il s'exécute sur la machine virtuelle d'Erlang. Voici à titre d'exemple le très classique Hello World :

"Hello world!".puts()

Pour le moment, il n'y a pas encore de version officielle de reia. Si vous souhaitez l'essayer, il vous suffit de cloner le dépôt git, d'avoir Erlang et Rake installés puis de lancer rake.

JSLint est un outil sous licence MIT qui permet de vérifier la qualité d'un programme JavaScript. Écrit par Douglas Crockford il y a 10 ans, JSLint continue d'évoluer pour prendre en compte les nouveaux usages et les avancées de la standardisation d'ECMAScript. Une nouvelle version vient d'ailleurs d'être publiée et le code est disponible depuis peu sur GitHub.

JSlint tourne partout où JavaScript ou Java est disponible et peut notamment être utilisé directement depuis le site officiel. Il prend du code JavaScript en entrée et en vérifie la qualité en fonction d'un certain nombre de règles configurables.

Vous le trouverez probablement trop strict au départ, mais suivre ces recommandations permet d'améliorer sensiblement la qualité et la lisibilité du code JS que vous écrivez. Par exemple, il vous forcera à éviter les variables globales et à utiliser les accolades {} avec if, for et while.

AMQP, ou Advanced Message Queuing Protocol, est un protocole standard ouvert pour les MOM, ou Message Oriented Middleware. Pour résumer, c'est un protocole de message entre serveurs offrant des mécanismes de files d'attente, de routage (point à point et par diffusion/abonnement), de fiabilité, et de sécurité. Citons les implémentations OpenAMQ (en C, sous GPLv3) ou RabbitMQ (en erlang, sous MPL).

Le sujet n'est pas nouveau, mais iMatix considère ce standard comme dépassé et en propose un nouveau, ØMQ ou ZeroMQ, avec une implémentation de qualité : légèreté, facilité d'intégration et performances. iMatix a pendant un temps développé OpenAMQ, mais soutient et développe désormais le projet ØMQ.

Que vous utilisiez Ruby, Python ou C n'est pas un problème, les bindings existent déjà. Vous pouvez vous en rendre compte en consultant le livre de recettes. La bibliothèque est elle-même développée en C++, sous licence LGPL.

Le transport des messages entre les nœuds est assuré par différents biais selon la disponibilité des moyens : TCP/IP, PGM, InfiniBand ou encore socket Unix dans le cas de communications internes. L'interface proposée permet d'implémenter de façon concise les principaux usages de messagerie inter-applications : requête/réponse, abonnement/notification, éventuellement avec restriction à un sujet particulier. L'utilisation de fonctions avancées comme le zero-copy ou le scatter-gather est rendue possible dans les dernières versions de la bibliothèque.

Dans la grande famille des bases de données NoSQL, je vous ai déjà présenté Cassandra, MongoDB, Redis et FlockDB. Laissez-moi vous présenter un nouveau membre de cette famille : Riak.

Riak est une base de données distribuée de type clé-valeur, sous licence Apache 2. Basho, la société derrière Riak, s'est inspirée de Dynamo d'Amazon pour nous offrir un stockage qui scale facilement. En particulier, sa grande force repose sur son modèle distribué où toutes les machines jouent un rôle équivalent, ce qui apporte à la fois une grande résistance aux erreurs et la capacité d'ajouter ou retirer facilement des machines à la volée.

Dans la seconde partie de la dépêche, je vais présenter plus en détails Riak, puis vous parler des nouveautés de la version 0.10 sortie récemment. J'aborderai également bitcask, un moteur de stockage clé-valeur local, qui peut être utilisé pour le stockage par noeud de Riak. Je finirais par une note très rapide à propos de ripple, le client en Ruby pour Riak.

C'est avec discrétion que le projet Unladen Swallow - dont le but est d'accélérer Python en s'appuyant sur LLVM et son compilateur JIT - a sorti la version 2009Q3, environ 3 mois après la version 2009Q2

Dans cette nouvelle version, les choses qui font plaisir :

• Par rapport à la version Q2, gain en utilisation mémoire de 930% ;
  
• Gain de performance par rapport à la version 2009Q2 entre 15 et 70% suivant les benchmarks ;
  
• Intégration avec GDB 7.0 permettant de débugger le code passé par le compilateur JIT ;
  
• Intégration avec OProfile 0.9.4 afin de fournir une interface de profilage sans difficulté qui couvre le C et le Python ;
  
• Beaucoup de bugs et de restrictions du compilateur JIT de LLVM ont été corrigés au passage ;
  
• Unladen Swallow 2009Q3 passe toutes les suites de test de projets Python majeurs tel que Twisted, Django, Numpy ou Swing (cf la liste de tests pour la liste complète des suites de test).

Les choses qui font moins plaisir :

• Le compilateur JIT de LLVM et d'autres outils ont demandé plus de travail qu'imaginé au départ. En conséquence, le projet n'a pas progressé autant en performance que les auteurs l'auraient voulu ;
  
• L'utilisation mémoire reste entre deux et trois fois supérieure à celle de Python 2.6.1. Cependant, il y a des pistes intéressantes pour réduire cela d'ici la version 2009Q4 .

DataMapper est une bibliothèque en Ruby qui vous permet de manipuler des données dans des bases de données sous forme d'objets Ruby (c.-à-d., c'est un ORM). Sous licence MIT, il vient de sortir en version 1.0, grâce au travail de 66 contributeurs.

Dans le monde Ruby, l'utilisation d'ORM est devenue une pratique courante sous l'influence de Ruby on Rails. ActiveRecord, l'ORM de Ruby on Rails, est ainsi très utilisé mais il ne convient pas à tout le monde. Les développeurs de Ruby on Rails ont des avis très tranchés sur certains points et, notamment, cherchent toujours à répondre aux 20% de cas d'utilisation qui couvrent 80% des besoins. Mais certaines personnes ont des besoins plus particuliers : c'est ce qui est arrivé aux développeurs de DataMapper.

L'équipe de DataMapper a ainsi voulu fournir une bibliothèque plus complète qu'ActiveRecord. On peut ainsi citer les points forts suivants :

• Support de nombreuses bases de données, aussi bien relationnelles que NoSQL, mais également de fichiers YAML et d'interfaces REST ;
  
• Migrations automatiques : on écrit les classes Ruby, puis on demande à DataMapper de créer les tables correspondantes dans la base de données ;
  
• Unicité des objets : une ligne dans la base de données correspond à un objet ;
  
• Approche modulaire : on choisit les fonctionnalités dont on a vraiment besoin ;
  
• Réduction du nombre de requêtes : DataMapper ne fait les requêtes qu'au moment où vous avez vraiment besoin d'y accéder (Lazyness can be a virtue) et précharge les objets quand vous itérez sur des collections (Strategic eager loading) ;
  
• Intégration plus souple à des projets Ruby existants.
  

La version 3 de Ruby on Rails devrait sortir d'ici quelques semaines et va notamment permettre de remplacer facilement ActiveRecord par un ORM dans les projets Rails.
Saluons donc l'arrivée de DataMapper 1.0 qui va permettre de couvrir des scénarios complexes pour des projets Rails ou autres.

Pendant de nombreuses années, SCCS (Source Code Control System) fut le seul logiciel de gestion de versions disponible sur les systèmes Unix, avant qu'il ne soit supplanté par RCS puis par les gestionnaires de versions modernes comme CVS, ou git. Afin que les utilisateurs d'Unix migrant vers le libre puissent accéder à leur référentiel SCCS, le projet GNU inclut un logiciel astucieusement nommé CSSC (« compatibly stupid source control »), dont la version 1.3.0 est sortie ce lundi.

Cependant, les implémentations de SCCS pouvant être légèrement différentes entre les Unix, et surtout plusieurs hacks ayant circulé pour améliorer ce produit, de nombreux utilisateurs de CSSC doivent modifier ce logiciel afin de retrouver les fonctionnalités de « leur » SCCS d'origine. Jusqu'à présent, modifier le code de CSSC n'était pas évident, et la version 1.3.0 veut justement répondre à ce besoin : elle n'apporte pas de nouvelles fonctionnalités, mais elle a fait l'objet d'un très sérieux toilettage du code grâce à l'utilisation de bibliothèques GNU standards (l'inconvénient étant que GNU CSSC devient moins simple à compiler sur d'anciens systèmes ne disposant pas de ces bibliothèques).

Pour ceux qui se demandent à quoi peut bien servir ce projet, la réponse est derrière le premier lien : de très nombreux logiciels sont stockés au format SCCS, GNU CSSC a pour but de permettre aux développeurs de les récupérer afin qu'ils puissent les intégrer à un système de gestion de versions moderne.

Nous sommes heureux de vous annoncer la sortie de la nouvelle version de Scub Foundation, notre solution libre (licence LGPL) d’industrialisation du développement et de la maintenance d’applications Java. Cette version standardise tous les aspects du développement jusqu'à la mise en place de l’intégration continue via Jenkins et de la gestion de la qualité via Sonar.

En plus des nombreuses améliorations sur les modèles de projets, d’une mise à niveau des bibliothèques et outils, nous avons aussi un nouveau site web avec une documentation plus complète, notamment sur des nouveaux sujets comme la gestion des logs avec Graylog.

note : Scub Foundation permet de standardiser le développement des applications en sélectionnant avec vous un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.

Étoilé se veut être un environnement utilisateur libre et innovant basé sur GNUstep construit à partir de légers et très modulaires composants.
Il a été conçu en gardant à l'esprit une orientation projet et documents, dans le but de permettre aux utilisateurs de créer leur propre workflow en refondant ou combinant les Services (applications) et composants proposés.

La grande flexibilité et modularité aussi bien de l'interface utilisateur que du code doit permettre à Étoilé d'être utilisable d'un environnement mobile jusqu'à la station de travail.

La version 0.4 est destinée aux développeurs. Dans ce but, les Framework constituent la part prédominante de cette version. Quelques applications de démonstration sont également incluses. D'autres seront ajoutées durant la série des version 0.4.x, dans le but d'obtenir une version 0.5 orientée vers l'utilisateur l'année prochaine.

Le site web Phoronix, qui propose des tests de matériels et de logiciels sous des OS de type Unix, principalement libres, a publié hier un mini-sondage (11 questions) sur l'utilisation que vous avez de Xorg, de votre carte graphique, etc.

Le sondage a lieu jusqu'au 15 décembre, les résultats seront publiés peu après, et seront probablement utilisés par les développeurs de Xorg pour orienter leur travail. Le but de ce sondage est bien entendu de fournir aux développeurs de Xorg quelques indices sur la façon dont la majorité des utilisateurs utilisent Xorg, ceci afin de leur permettre de concentrer leurs efforts sur ce qui sera le plus utile.