Gregoire LEJEUNE

Ceci n'est pas vraiment un post, mais plus un exemple d'utilisation de nasm + gcc (sous MacOSX). Il s'agit ici d'un exemple pour l'architecture i386. Il a été testé sous Lion. Promis, je vais proposer une mise à jour, rapidement, pour montrer ce que cela donne en x86_64.

Attention, la version de NASM installée par Apple date un peu ;) Je vous conseille donc d'installer la vôtre.

section .data
   msg: db '%d',0xa, 0
   addition_cumul: dd 0

section .text
   global _add
   extern _printf

_add:
   push ebp
   mov  ebp, esp

   mov eax, [addition_cumul]
   add eax, [ebp + 8]
   mov [addition_cumul], eax
   push dword eax
   push dword msg
   call _printf
   add esp, 4

   pop eax
   leave
   ret

#include <stdio.h>

int add(int nb);

int main() {
   int i;
   int last = 0;
   for(i=0; i<10; i++) {
      printf( "%d + %d = ", last, i);
      last = add (i);
   }
   return 0;
}

all:
   /usr/local/bin/nasm -f macho add.asm 
   /usr/bin/gcc-4.2 -Wl,-no_pie -m32 -c testadd.c 
   ld -arch i386 -macosx_version_min 10.6 -lc -o testadd add.o testadd.o /usr/lib/crt1.o 

Lire la suite...

Non, vous ne vous êtes pas trompé (et moi non plus) ! Ce post a presque le même titre que le précédent. En effet, je vous propose de refaire notre système de messagerie instantanée, mais en remplaçant AMQP par MQTT. Pour cela, nous utiliserons la gem ruby-mqtt et mosquitto comme broker.

MQTT est, tout comme AMQP, un protocole ouvert de messagerie inter-applicatif. Il est cependant beaucoup plus simple d'AMQP. En effet, il n'existe pas de notion d'exchange. Il n'est pas non plus possible d'envoyer des messages qui pourront être "conservés" par le broker afin d'être récupérés plus tard par des clients non connectés.

Un client MQTT va s'inscrire auprès d'une ou plusieurs queues pas la suite il pourra récupérer les messages envoyés à ces queues. De même, il pourra envoyer des messages à des queues, qu'il s'y soit inscrit ou non.

Voyons cela sur un petit exemple. En premier, le client :

 1 require 'rubygems'
 2 require 'mqtt/client'

Lire la suite...

Dans ce post, nous allons nous amuser à mettre en place un système de messagerie instantanée en utilisant AMQP. AMQP est un protocole permettant de gérer des échanges de messages entre applications. Il s'agit d'un protocole ouvert dont il existe de multiples implémentations. Dans cet exemple, nous utiliserons Ruby pour créer notre système de chat.

Afin de rendre notre client de messagerie un peu plus convivial, nous nous amuserons à mettre en place une interface utilisateur en mode texte avec Ncurses. Aucun rapport avec AMQP bien entendu, il s'agit simplement de s'amuser un peu ;)

Autant vous prévenir tout de suite, je ne vais faire qu'effleurer les deux sujets (AMQP et Ncurses). Mon objectif étant de vous faire toucher du doigt ces différentes technologies, en espérant attirer votre curiosité, et en vous laissant le plaisir d'approfondir ces sujets par vous même.

AMQP

Avant de se lancer dans le développement, il faut comprendre les mécanismes d'AMQP. Pour cela, regardons le schéma

Lire la suite...

Depuis quelques jours, nous travaillons, avec @syl20j sur la refonte des installeurs des applications CD VIDAL. Dans leurs versions actuelles, ces installeurs sont générés via des scripts Ant utilisant du NSIS sous Windows et du PackageMaker sous Mac. Nous avons décidé de supprimer ces scripts pour remplacer tout cela par du maven et de l'install4j. Une des étapes consiste donc à comprendre ce que font les scripts Ant. Afin de faciliter notre travail, j'ai développé un petit script permettant de faire une représentation d'un fichier de build sous forme de graph.

Le voici :

#!/usr/bin/env ruby

require 'rubygems'
require 'open-uri'
require 'nokogiri'
require 'graphviz'
require 'getoptlong'

class Ant2Gv
   def initialize(build_file, gv_path) 
      @build_file = build_file
      @build_doc = Nokogiri::XML(open(@build_file))
      @build_graph = GraphViz.new(:ANT, :path => gv_path)
      @build_graph.node["shape"

Lire la suite...

Depuis que je suis (re)passé sous Vim pour développer, j’ai passé un peu de temps à me peaufiner une configuration aux petits oignons. En effet, quand on a pris l’habitude de développer avec un IDE, le moindre refactoring, la moindre recherche ou les imports automatiques nous font oublier que dans la vraie vie, tout n’est pas aussi luxueux ;)

Heureusement, il existe un grand nombre de plugins pour Vim qui peuvent grandement nous simplifier la vie. Parmi ceux-ci, j’utilise :

• ack.vim est un module permettant d’utiliser Ack dans Vim.
• DirDiff.vim permet de comparer (et éventuellement merger) des arborescences de répertoires.
• fugitive est une interface à Git, dans Vim.
• NERDTree pour ajouter un explorateur de fichier à Vim.
• surround est un module qui permet de facilement jouer avec les “encadrements”.
• tagbar permet d’afficher tous les tags (classes, méthodes, variables, …) du fichier courant.

Une fois ces modules installés, il me manque trois petites choses:

Lire la suite...

Quand j'ai commencé à développer en Java, parmi les choses qui me manquait le plus, une console, façon IRB, était dans le top 10. En effet, le problème avec les langages nécessitant une phase de compilation et que lorsque vous voulez tester rapidement un petit enchainement, vous avez l'impression de devoir sortir l'artillerie lourde. J'ai donc cherché s'il existait quelque chose pour m'aider, et je suis rapidement tombé sur BeanShell. Ce dernier, utilisé en ligne de commande, répond totalement à mon besoin. Cependant, je me suis également demandé si je ne pourrais pas mettre en place ma propre solution.

Je me suis donc tourné vers ce que je connais et j'ai essayé de mettre en place une solution à base de JRuby et java-inline. Le résultat n'est pas parfait, mais il répond au besoin de base.

Voici un example d'utilisation :

$ export CLASSPATH=commons-io-2.0.1.jar
$ ruby jconsole.rb
jConsole with Java 10.7
> \help
\import [PACKAGE]   : Import package

Lire la suite...

Depuis que j’ai rejoint l’équipe Software de VIDAL, j’avais pris l’habitude de coder avec Intellij. Trois raisons ont motivés ce choix. Premièrement, Intellij est (AMHA) moins lourd qu’Eclipse. En second, le support de Scala et Ruby y est particulièrement bien fait. Enfin il existe le plugin IdeaVIM, permettant de retrouver (presque) toute la puissance de VIM dans Intellij. Puis est arrivé @syl20j, vimiste parmi les vimiste qui m’a permis de me poser la question “Tant qu’à vouloir faire du VIM, pourquoi ne pas utiliser l’original ?” Et c’est ainsi que j’ai dis au revoir à Intellij et (re) bonjour à VIM.

D’intellij à VIM

Côté langage, nous en utilisons principalement trois : Java, Scala et Ruby. Pour le premier et le dernier, VIM ne demande rien de particulier. Pour Scala, il sera cependant utile d’installer un plugin. Après plusieurs tests, j’ai opté pour la version Git de Ross Timson

Lire la suite...

Depuis 2 sprints, nous travaillons, @syl20j, @jblemee et moi, sur un nouveau projet chez VIDAL. Partants de rien, nous avons choisi de développer en Scala, ce qui nous a ouvert la voie vers l'utilisation du modèle d'acteur. Mes divertissements avec Erlang m'avaient déjà permis de jouer un peu avec. Pourtant, il aura fallu que je l'utilise dans un contexte professionnel pour véritablement y consacrer du temps et essayer de l'appliquer en Ruby.

Les acteurs

Le principe du modèle d'acteur vise avant tout à simplifier le traitement parallèle. Pour cela il définit les règles suivantes :

• Un acteur participe à un traitement parallèle et ne partage rien avec les autres acteurs.
• On communique avec un acteur uniquement par le biais de messages.
• Les messages reçus par un même acteur sont traités séquentiellement (et non en parallèle) en suivant la règle FIFO.

Avant de voir comment nous pouvons mettre en place un modèle d'acteur en Ruby, il peut être intéressant de regarder comment il s'utilise dans d'autres langages.

Lire la suite...

Dans la continuité de mon développement de vf, je me suis demandé comment mettre en place de l'autocomplétion. En effet, si vf remplace très avantageusement cd, l'autocomplétion par défaut du shell ne permet d'accéder facilement qu'aux répertoires. Ainsi, un vf <TAB> ne présente que la liste des fichiers et répertoires, masquant totalement l'intérêt de vf, à savoir la présence des alias.

$ vf <TAB>
--< file >--
Capcode/                         lipsum/                          Fragaria/
...

Il serait bien plus intéressant que vf présente non seulement la liste des répertoires, mais également des alias :

$ vf <TAB>
github                           vidal                            docs
...
--< file >--
Capcode/                         lipsum/                          Fragaria/
...

J'ai donc fouillé un peu.

Etant un utilisateur convaincu de Zsh, je m'étais déjà amusé un peu avec le système de complétion de ce dernier. Pour ce qui est des autres, j'ai du

Lire la suite...

Si, comme moi, vous travaillez beaucoup en ligne de commande, que vous passez votre temps à naviguer d'un répertoire à un autre, peut-être vous êtes-vous créé des alias pour vous téléporter plus rapidement dans tel ou tel répertoire. Je me suis amusé à pousser cette idée et j'ai donc créé vf. Cet utilitaire vient remplacer la commande cd en comblant quelques une de ses lacunes.

L'idée première de vf consiste à pouvoir facilement créer des raccourcis vers des répertoires. Pour cela, il vous suffit de vous rendre dans le répertoire en question et à exécuter la commande suivante :

vf -s mon_alias

A partir de maintenant, vous pouvez facilement revenir dans le répertoire pointé par l'alias mon_alias en utilisant simplement la commande :

vf mon_alias

Si par la suite, vous souhaitez supprimer un alias, il suffit d'utiliser l'option -r :

vf -r mon_alias

A tout moment vous pouvez afficher la liste de vos alias en utilisant l'option -l.

Lire la suite...

Après 32 versions 0.X et un peu plus de 6 ans de développement, la version 1.0.0 de Ruby/GraphViz vient de sortir. Il est donc temps de consacrer un petit article à ces 4500 lignes de code, dont ~1800 pour les tests. D'en profiter pour remercier les 14 personnes qui ont participé à son développement, et de rendre un petit hommage aux utilisateurs qui vont permettre de bientôt passer la barre des 40000 téléchargements.

Un peu d'histoire...

Une première version en C

La toute première version de Ruby/GraphViz, dont les sources sont encore disponibles, était écrite en C. A l'origine, ce module faisait partie du projet Ruby/ASP qui avait pour ambition de créer un portage d'apache-asp en Ruby. Dans les faits, j'ai longtemps utilisé apache-asp pour développer Webtime, outil de timesheet. Et, vous l'aurez compris, j'avais l'espoir de le réécrire en Ruby.

Quel rapport avec GraphViz ?

Et bien j'envisageais d'ajouter à Webtime des fonctionnalités nécessitant la mise en place de graphes. Ceci afin de permettre de présenter des organigrammes, des schémas de dépendances entre projets, etc...

Lire la suite...

Créer un démon n'est pas des plus intuitif avec Java. Et bien qu'il y ait de l'espoir avec le futur Java 7, en attendant, il existe des solutions très simples à mettre en place. Je vous propose aujourd'hui de regarder ce que propose commons-daemon. Comme nous allons le voir, cette solution possède de solides avantages. Outre sa simplicité, elle permet, à moindre coût, de considérer les différentes plateformes.

Si nous avons l'habitude de parler de démon sous U*IX, un utilisateur Windows entendra plutôt service. Il s'agit d'une différence importante en terme de mise en place. En effet, si sous U*IX l'utilisation d'un fork suffit dans 90% des cas, sous Windows il faudra jouer avec le Service Control Manager. C'est justement ce que propose commons-daemon.

J'utiliserai indifféremment le terme de démon ou service dans la suite de cette présentation.

La partie commune

Dans cet exemple, j'utilise maven. Commencez donc par créer un projet et ajoutez la dépendance suivante :

Lire la suite...

Quand on n'y a jamais été confronté, on a tendance à croire que la cross-compilation est un sujet compliqué. C'est oublié le côté primitif¹ d'un compilateur. En effet, ce dernier n'est rien d'autre qu'un traducteur dont le rôle consiste à générer un code cible compréhensible par une machine donnée, à partir d'un code source. Dans cette définition, rien n'indique, à juste titre, que cette traduction doit être faite sur la machine à laquelle est destiné le code cible. Ainsi rien ne m'empêche d'installer, sur mon Mac, un compilateur dans le but de créer des exécutables pour Windows. C'est ce que nous allons voir ici.

MinGW

MinGW est un projet ayant pour objectif de porter les outils de développement du projet GNU sur la plateforme Windows. C'est donc une excellente base de départ pour ce que nous voulons faire, car il met à notre disposition un ensemble de fichiers d'entêtes pour le développement d'application Windows. Ces éléments sont disponibles dans la partie

Lire la suite...

Depuis quelques semaines, je travaille sur le développement d'une application iPhone¹, et j'ai donc profité de la trêve de Noël pour agrémenter mes connaissances dans le domaine du développement mobile en général. Comme tout utilisateur de Mac et possesseur d'iPhone, je me suis naturellement penché vers ce dernier en oubliant vaniteusement les autres. Dommage² ! Oui, dommage parce qu'aujourd'hui, oublier une plateforme serait faire preuve de caprice irrationnel tant les parts de marchés des uns et des autres sont importantes³. Heureusement ma conviction qu'il est aujourd'hui important de développer des applications mobiles pour le plus grand nombre avait déjà été perçue par de plus sages que moi. Et c'est donc vers eux que je me suis tourné !

Dans ce post, je vais me concentrer sur une solution de développement conjointe entre iPhone et Android. Cependant, comme je l'ai indiqué, il serait dommage de se limiter à ces deux seules plateformes. En effet, il ne faut pas oublier BlackBerry, Symbian ou Palm.

Lire la suite...