VisualGST est un IDE (environnement de développement intégré) pour GNU Smalltalk - une implémentation du langage Smalltalk. J'ai le plaisir de vous annoncer la sortie de la version 0.5.0 de VisualGST.

VisualGST, logiciel sous licence GPL, est écrit en Smalltalk et utilise le binding GTK+ de GNU Smalltalk.
Voici un aperçu de VisualGST :

• Un navigateur de classes qui permet de naviguer à travers les projets et de rajouter/modifier du code ;
  
• Un Transcript : c'est utilisé pour afficher des résultats ou des exceptions (par ex : (2 + 2) printNl)) ;
  
• Un Workspace : un éditeur de texte qui sert surtout à exécuter du code ;
  
• Un debugger : pas besoins d'explications ;) ;
  
• Un Senders/Implementers : ces deux outils permettent de voir qui utilise ou implémente telle méthode/classe/namespace ;
  
• Un inspecteur : il permet de naviguer à travers des objets. Il est ainsi possible de voir les variables d'instances et de naviguer parmi celles-ci. La vue de l'inspecteur sera adaptée en fonction du type des variables : si c'est un entier on verra les valeurs en base 2, 8, 16. Si c'est un dictionnaire, ce sont les clefs et leurs valeurs qui seront montrées ;
  
• Des refactorings de bases (principalement les opérations ajout/modification/suppression) pour les namespaces, classes, méthodes. Avec support de l'Undo/Redo ;
  
• etc.
  

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.

Le langage Go (sous une licence de type BSD) est issu d'une discussion entre Ken Thompson (un des auteurs d'Unix et d'UTF8) et Rob Pike (un des auteurs de Plan9 et d'UTF8). Rob Pike a pu monter une équipe chez Google pour travailler dessus, et en novembre 2009, une première version a été dévoilée au reste du monde.

Depuis, le développement continue d'avancer à un bon rythme. Des versions sont publiées tous les 10 à 15 jours.

Dernièrement, une proposition pour un mécanisme similaire aux exceptions a été discuté sur la liste de diffusion. C'est un exemple très révélateur de la manière d'avancer de l'équipe en charge de Go : ils ne se précipitent pas pour ajouter des fonctionnalités présentes dans d'autres langages parce qu'elles sont très demandées. Ils prennent le temps de réfléchir à chaque problème, et quand ils ont trouvé une piste qui semble pouvoir répondre à leurs exigences, ils publient une proposition sur la liste de diffusion. Il s'en suit des discussions qui permettent de raffiner la proposition et, sauf surprise, la proposition est intégrée dans la version suivante.

Côté communication, l'essentiel se passe sur le canal IRC #go-nuts sur freenode et sur la liste de diffusion Go-nuts. Un wiki a récemment été mis en place pour regrouper des informations sur l'écosystème de Go. Quelques jours plus tard, un blog officiel a suivi. Enfin, un dashboard permet de voir l'état des compilations sur les différentes architectures supportées.

Globalement, les personnes qui ont essayé Go semblent convaincues que ce langage est promis à un grand avenir.

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.

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.

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.

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.

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.

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.

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 .

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.

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 d'annoncer aujourd'hui la disponibilité de la première version stable publique de MeteoIO.

MeteoIO est une bibliothèque C++ sous licence LGPL v3 destinée à la gestion des entrées/sorties météorologiques ainsi que leur préprocessing dans le cadre des modèles numériques faisant usage de telles données. Cette bibliothèque à été conçue afin de libérer le développeur de modèles numériques de la gestion des entrées/sorties en lui offrant une bibliothèque robuste, stable, facile à utiliser et intégrée.