Gregoire LEJEUNE
Chef de produit
Posts
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.
add.asm
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
testadd.c
#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;
}
Makefile
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
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'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
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"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:
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 packageDepuis 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
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.
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
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.
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...
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 :
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é primitif1 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
Depuis quelques semaines, je travaille sur le développement d'une application iPhone1, 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. Dommage2 ! 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 importantes3. 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.
La première fois que j'ai touché à Node.js je n'ai pas pu m'empêcher d'avoir une pensée émue pour le défunt1 Netscape LiveWire qui offrait alors la toute première implémentation SSJS. Passons...
Dans un précédent article, je vous ai présenté ma solution permettant d'utiliser GraphViz avec Node. La mise en place de cette solution passe par le développement d'un module. Je vous propose aujourd'hui de voir comment développer ce type d'extension pour Node.
La création d'extensions pour Node peut se faire de deux façons. La solution la plus évidente consiste, bien entendu, à développer en Javascipt. L'autre solution consiste à utiliser l'API C++ de V8. De ces deux méthodes en découle une troisième, évidente, qui consiste à mixer les deux précédentes.
Comme toujours, je ne serais trop vous conseiller de consulter la documentation. Pour la partie JavaScript, la documentation de Node est certes un peu light à certains moments, mais en regardant en plus le code des
Updates
-
Début de la dernière semaine. Après, une petite semaine rien-foutre/moto. Puis début d’une nouvelle aventure !
-
RT @Madel000n: En avril ne te découvre pas d'un fil. En mai remet ton Kway.
-
RT @Carlos_Perez: Nice site filled with .vimrc tips http://t.co/jplH9noxMQ
-
RT @ya_f: Location de voiture pour 1€ pour des trajets simple (d'une ville à une autre) http://t.co/X64WTC6DiH Intéressant ! :)
-
RT @Code_Analysis: JSON Spirit: A C++ JSON Parser/Generator Implemented with Boost Spirit. http://t.co/Xetp9AXBa0 #cpp #boost #JSON
-
@ugobourdon tu vas venir me dire que le jeu vidéo génère des tueurs en séries et que le C++ transforme les gens en terroriste ?
-
@ugobourdon la pédophilie existait avant internet, alors que le hooliganisme est né (par définition) du sport.
-
@ugobourdon la différence c’est qu’internet ne fait pas des pédophiles, alors que le foot fait bien des hooligans #maisnegeneralisonspas
-
Hier nous avons eu le droit à une avant première de “Banlieue 16” grâce à la viande saoule qui supporte le PSG #jaimepaslefoot
-
Et si le Trocadero et la Tour Eiffel étaient traités comme Internet ? http://t.co/rIVbuOCH0C
-
RT @saschild: Une taxe sur la connerie pour rembourser le vandalisme des hooligans ?
-
RT @myriam: Ô France, que n'eus-tu l'idée en son temps de taxer les aiguilles et les machines à coudre pour financer l'industrie textile ! …
-
RT @siddartha: Le CNED met en ligne tous les cours de CP à la Terminale en accès gratuit.. Bravo ! http://t.co/9tlqzyM9Ob v/ @pcouzon
-
RT @Baktoui: Les t-shirts de Sheldon Cooper http://t.co/MgdlOFfuxo