eponyme's blog : linux, dev & cie

fail2ban : punir les récidivistes

Fabien Nicoleau — Fri, 14 Oct 2011 00:08:00 +0200

Fail2ban permet de bannir des adresses IP tentant de s'attaquer à votre système. Elles sont repérées grâce aux fichiers de log des différents services. Fail2ban les consulte et agit en fonction des expressions régulières qui lui sont données, et d'une tolérance d'erreurs donnée.

Les "bans" ont une durée, mais parfois on se rend compte qu'aussitôt son ban terminé, une adresse tente de nouveau de s'attaquer au système. Une solution simple peut être de mettre une rêgle permanante avec iptables, ce qui règlera définitivement le problème. Cependant cette solution ne me convient pas totalement car je n'aime pas le fait d'ajouter des règles à iptables qui ne seront peut être pas toujours utiles (l'attaquant peut s'arrêter, ou son adresse peut changer). De plus, j'aime assez l'idée qu'un serveur puisse être un minimum autonome. Si je ne consulte pas les logs de mon serveur pendant 1 mois et que je ne me rend pas compte qu'une adresse m'attaque à longueur de journée, mon serveur risque d'être en danger.

Pour régler ce problème, il suffit de créer un jail dans fail2ban qui scrutera son propre log. Ainsi il sera possible de bannir pour une très longue durée une IP qui déjà été bannie plusieurs fois. Cette technique est expliquée dans un article en anglais, je propose ici une explication en français.

La première chose à faire est de créer un filtre, qu'on placera dans /etc/fail2ban/filter.d/fail2ban-recidivist.conf . En voici le contenu :

[Definition]
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban-recidivist\] Ban <HOST>

La ligne du failregex indique la regex qui permettra de repérer les lignes de ban dans le fichier de log de fail2ban. La dernière ligne permet d'ignorer les bans ajoutés par notre nouvelle règle. Cela évitera de les comptabiliser et donc de fausser le nombre de bans à prendre en compte pour une IP. Notez ici que nous ignorons les bans pour le jail fail2ban-recidivist. Si vous changez le nom du jail, pensez aussi à modifier le filtre pour que l'ignoreregex soit correcte.

Il faut ensuite ajouter un jail dans le fichier /etc/fail2ban/jail.conf, dont voici la définition :

[fail2ban-recidivist]
enabled = true
filter = fail2ban-recidivist
action = iptables-allports[name=recidivist]
logpath = /var/log/messages
maxretry = 5
# 1 semaine
findtime = 604800
# 1 semaine
bantime = 604800

Comme pour les autres jails, on indique ici le nom du filtre utilisé (et dont nous avons donné la définition précédemment), l'action à effectuer (je choisis ici de bannir sur tous les ports l'attaquant, et de passer le nom "recidivist" à iptables pour la règle. Il serait aussi possible, voir même judicieux, d'envoyer un e-mail pour vous prévenir de ce ban particulier grâce à l'action sendmail-whois), le fichier de log à scruter, qui est pour ce jail celui de fail2ban (qui utilise SYSLOG dans mon cas), le nombre de tentatives infructueuses, la plage de temps sur laquelle on fait le décompte, et enfin le temps de banissement.

Pour ce cas précis, je bannis pendant une semaine une personne qui a déja été bannie 5 fois durant la dernière semaine par d'autres règles. Sachant que chaque règle a elle aussi un nombre de tentatives d'essais (3 par défaut), cela donne tout de même une bonne tolérance.

Il faut noter que si vous utilisez une action qui ne prend pas en compte de nom (ici recidivist), et qui enregistre simplement l'adresse IP, ce système ne fonctionnera pas. En effet, si une personne est bannie parce qu'elle a essayé de s'authentifier sans succès plusieurs fois, pour une durée d'un jour, et qu'ensuite ce jail bannit l'IP pour une semaine, au bout d'une journée, le premier ban sera retiré, l'IP donc retirée, et le ban d'une semaine annulé. Ce problème n'apparait pas avec iptables car il prend en compte le nom de l'action, et ne confond donc pas les bans. En revanche, cela semble pouvoir se produire avec ipfw, hostsdeny et shorewall.

Voilà grâce à cette règle un serveur un peu plus autonome, qui sévira de façon plus dure s'il est attaqué trop souvent par la même personne.

Fabien (eponyme)

fail2ban : classement des IP les plus bannies

Fabien Nicoleau — Sat, 08 Oct 2011 19:22:00 +0200

J'utilise depuis très longtemps fail2ban, qui permet de bannir des IP générant trop d'erreurs (le plus souvent des échecs d'authentification). Il se base sur les logs des différents services et des expressions régulières pour retrouver les tentatives et les bannir.

Je m'y suis un peu plus intéressé ces derniers temps car j'ai été attaqué par des scripts vraiment insistants (ce sera l'objet d'un prochain billet). Dans un premier temps, j'ai voulu obtenir une liste des adresses bannies, avec le nombre de fois, afin de déceler des "récidivistes". Voici la commande utilisée (fail2ban log avec SYSLOG sur mon serveur) :

cat /var/log/messages|grep Ban|awk '{print $7" "$9}'|sort|uniq -c|sort -r

Voici l'explication de la commande :

cat : affichage du fichier de log
grep Ban : on ne conserve que les lignes concernant un bannissement
awk : on extrait simplement les 7ème et 9ème parties, c'est à dire le "jail" utilisé pour le ban, et l'IP bannie
un premier sort pour faire en sorte que les IP identiques soient listées les unes en dessous des autres
uniq -q : réunies les lignes communes et affiche devant le nombre de fois qu'elles apparaissent
un dernier sort (avec l'option reverse) pour faire un tri inverse

On se retrouve ainsi avec une liste indiquant le nombre de fois qu'a été bannie une IP, le jail utilisé et l'IP bannie, le tout dans l'ordre décroisant. Voici un exemple :

      8 [ssh-iptables] 188.138.98.75
      2 [apache-dfind] 93.174.2.202
      2 [apache-dfind] 81.196.179.210
      2 [apache-dfind] 217.70.51.154
      1 [ssh-iptables] 96.8.121.185
      1 [ssh-iptables] 87.106.132.104
      1 [ssh-iptables] 58.211.5.130
      1 [ssh-iptables] 221.207.229.6
      1 [ssh-iptables] 201.140.103.17

Le défaut de cette commande est que l'odre est faire sur du texte, et donc si une IP est bannie plus de 9 fois, elle apparaitra en bas, au lieu d'être en haut.

Cela permet cependant de repérer rapidement une IP trop "agressive" pour la bannir définitivement par exemple.

Fabien (eponyme)

Mise à jour de quvi pour rawhide : éclatement des paquets

Fabien Nicoleau — Sat, 08 Oct 2011 19:00:00 +0200

Je paquage le logiciel "quvi" pour Fedora. Ce logiciel fournit une bibliothèque (libquvi) permettant de parser les vidéos des sites tels que youtube ou dailymotion (et beaucoup d'autres) ainsi qu'un outil (quvi) utilisant libquvi pour parser les vidéos. La dernière version, la 0.4.0, est maintenant divisée en 3 sources : libquvi (la bibliothèque), libquvi-scripts (les scripts lua utilisés par libquvi permettant de parser les sites) et quvi, l'utilitaire.

J'ai donc aujourd'hui fait les demandes de revue pour les paquets libquvi et libquvi-scripts. Je mettrai à jour quvi quand les deux dépendances auront été importées dans les dépôts:

Ces changements sont importants et ne seront donc effectués que dans rawhide.

Fabien (eponyme)

NomNom présent dans les dépôts !

Fabien Nicoleau — Mon, 19 Sep 2011 22:40:00 +0200

clive et cclive sont deux logiciels (du même auteur) permettant de récupérer les vidéos de sites tels que youtube ou dailymotion (et beaucoup d'autres !). Il existait auparavant un "frontend" à ces utilitaires, toujours du même auteur : abby. Ce dernier a été remplacé par NomNom (encore et toujours du même auteur), et permet de visionner les vidéos directement en streaming, ou simplement de les télécharger. Il permet aussi de profiter des options de umph (dont je vous laisse deviner l'auteur ..) pour télécharger toute une liste de lecture, ou de favoris de YouTube. NomNom peut être une bonne alternative à ceux ne souhaitant pas utiliser de plugin flash avec leur navigateur.

umph et NomNom n'étaient pas présents dans les dépôts. Je les ai donc packagés et proposés. Ces deux paquets ont été acceptés et sont maintenant disponnibles dans les dépôts de Fedora, à partir de la version 15. Pour installer NomNom, en root :

# yum install nomnom

Fabien (eponyme)

Orphan de certains de mes paquets

Fabien Nicoleau — Mon, 19 Sep 2011 22:21:00 +0200

Bonjour,

En raison de manque de temps, et souhaitant me concentrer sur les paquets que j'utilise avec Fedora, j'ai pris la décision "d'orphan" 6 des paquets que je maintiens dans les dépôts :

gestikk : permet de lancer des logiciels avec un simple mouvement de souris
immix : mixage de photos
itaka : serveur de capture d'écran
perl-WWW-Curl : extension perl pour manipuler libcurl
vbindiff : visualiseur de fichiers en hexadécimal, avec prise en charge de fichiers à forte taille
xcftools : suite d'utilitaires en ligne de commande permettant de manipuler les fichiers au format XCF

J'ai de plus retiré deux paquets :

abby : cette interface graphique à clive et cclive a été remplacée par nomnom, que j'ai ajouté dans les dépôts (j'en parlerai bientôt)
trustyrc : mon robot IRC, que je ne maintiens plus

Ceux qui souhaitent maintenir ces paquets pourrons compter sur moi en cas de besoins/questions.

Fabien (eponyme)

Adieu amen, bonjour 1&1 !

Fabien Nicoleau — Mon, 05 Sep 2011 22:10:00 +0200

Ce blog était hébergé depuis 2 ans chez amen. Je n'avais pas hésité longtemps à l'époque car c'était les seuls à proposer une config pour 5 euros HT. Evidemment, "on en a pour son argent", mais ça fonctionnait plutôt bien pour mes faibles besoins. Cependant au fil du temps, et des mises à jour je suppose, le serveur ne faisait plus l'affaire. Impossible de faire une mise à jour sans planter yum, en manque de RAM. Amen ne proposait plus depuis quelques temps cette config, mais la laissait disponible en renouvellement. Après une réinitialisation du serveur, je me suis retrouvé avec un serveur "nu", impossible à mettre à jour, et avec un yum inutilisable. Bref, un serveur qui ne sert pas.

En attendant le remboursement de mon abonnement je me suis mis à la recherche d'un nouveau VPS, pas cher, mais suffisamment robuste tout de même. C'est 1&1 qui propose l'une des meilleures config pour 12 euros TTC, prix le plus bas en France pour une config potable. De plus 1&1 a plutôt une bonne réputation, c'est assez rassurant. Je paye le double, certes, mais la config est largement supérieure.

Voilà donc ce blog reparti, après une semaine offline, hébergé chez 1&1 !

Fabien (eponyme)

Bye bye adSense

Fabien Nicoleau — Tue, 12 Jul 2011 20:12:00 +0200

Beaucoup de place occupée, peu de revenus ... je me suis décidé à retirer les publicités adSense qui se trouvaient sur ce site. Le revoilà vierge de toute propagande (qui n'était pas toujours en armonie avec le but de ce blog) ! :D

Fabien (eponyme)

Créer un fichier Excel à partir d'un script

Fabien Nicoleau — Thu, 09 Jun 2011 18:47:00 +0200

J'ai récemment eu besoin de générer despuis un script un "vrai" fichier Excel. J'entends par "vrai", un fichier qui ne s'importe pas, mais qui s'ouvre directement et qui puisse contenir de la mise en forme. En recherchant sur internet, j'ai découvert que OpenOffice et Microsoft Excel (et peut-être d'autres tableurs) savent ouvrir un fichier content une description de table au format HTML. En plus, ils savent gérer des styles (de type CSS). Tout est donc imaginable, sauf que se pose le problème récurent des formats de cellule. N'ayant à travailler que pour Excel (on ne choisit pas toujours ses outils!), j'ai trouvé sur internet une solution pour celui-ci. En effet, il prends en compte la directive mso-number-format permettant de définir le format de la cellule. Ce billet indique différents exemples de valeurs possibles pour définir les formats.

Ainsi j'ai pu, à grand coup de echo et de redirection de flux, générer des fichiers Excel avec de bons formats pour les dates, les chiffres, forcer du texte (notamment pour les chaines ne contenant que des chiffres), et ajouter un peu de mise en forme.

Histoire de servir d'exemple, et pour moi de pense-bête, voici le contenu d'un fichier xls qui peut être généré avec différents exemples de formatage de cellule :

Voici le rendu dans Excel :

Notez que les cases A1 et A2 contiennent la même valeur, mais A1 étant formaté en texte, les zéros sont bien affichés. Pour l'instant je n'ai pas réussi à appliquer plusieurs classes à une même cellule, ce qui force à créer des classes spécifiques avec plusieurs mises en forme.

Voilà donc une solution rapide qui permettra, lorsque le langage de programmation ou de script utilisé ne contient pas de module pour gérer le format xls, de générer des fichiers Excel correctement formatés.

Fabien (eponyme)

GNOME 3 : passer de Gnome-Shell au mode restreint (et inversement) facilement

Fabien Nicoleau — Sun, 29 May 2011 19:02:00 +0200

Il est facile, dans la configuration de GNOME 3, de forcer le mode restreint. Il suffit d'aller dans les paramètres système, Informations système, carte graphique, et d'activer le "Mode restreint forcé". Il faut ensuite relancer sa session GNOME. C'est cette dernière étape qui me pose soucis. En effet j'ai besoin de passer en mode restreint pour pouvoir jouer confortablement aux jeux en 3D, et il devient vite contraignant de devoir relancer ma session juste pour une partie.

Pour contourner ce problème, j'ai créé un petit script qui permet de passer de Gnome-Shell au mode restreint, sans redémarrer sa session, et évidemment de passer du mode restreint à Gnome-Shell. Le seul prérequis pour que cela fonctionne est de désactiver l'option "AutoRestart" de Gnome-Shell, sinon, il essaiera de se relancer par dessus gnome-panel ...

Pour que cette modification n'affecte que ma session, j'ai importé dans mon compte le fichier de lancement de Gnome-Shell :

$ cp /usr/share/applications/gnome-shell.desktop ~/.config/autostart/

On désactive ensutie l'AutoRestart :

$ sed -i -e 's/AutoRestart=true/AutoRestart=false/' ~/.config/autostart/gnome-shell.desktop

Il faut maintenant redémarrer votre session GNOME pour que cette option soit prise en compte. Une fois votre session réouverte, vous pouvez utiliser ce script (téléchargeable dans les fichiers joints au billet) , que j'ai nommé gnome-mode.sh :

#!/bin/sh
case $1 in
   "panel"|0)
      gnome-panel --replace &
      killall gnome-shell
      metacity --replace &
      break
      ;;
   "shell"|1)
      gnome-shell --replace &
      break
      ;;
   *)
      echo "usage : $0 panel|shell"
esac

Il est assez simple. Lorsque vous utilisez Gnome-Shell, pour passer en mode restreint (avec gnome-panel) :

$ ./gnome-mode.sh panel

Notez que l'on peut utiliser 0 au lieu de panel comme paramètre.

Lorsque vous êtes en mode restreint, pour réactiver Gnome-Shell :

$ ./gnome-mode.sh shell

Notez que l'on peut utiliser 1 au lieu de shell comme paramètre.

Voilà, ce petit script vous permettra donc de passer d'un mode à l'autre facilement, quand le besoin s'en fait sentir, pour les jeux par exemple, quand comme moi, votre configuration matériel ne permet pas de faire tourner Gnome-Shell en même temps que des applciations 3D.

Fabien (eponyme)

umph : récupération de liens à partir de flux Youtube

Fabien Nicoleau — Sat, 28 May 2011 16:51:00 +0200

Il y avait longtemps que je n'avais pas proposé un nouveau paquet au projet Fedora. Je travaille actuellement sur l'empaquetage de NomNom, un logiciel permettant de télécharger ou visionner en streaming des vidéos provennant de sites comme Youtube, Dailymotion, et bien d'autres, en utilisant les outils quvi et clive/cclive que je package déjà (Pikatchu_2014 a d'ailleurs permit d'allonger la liste des sites supportés en me faisant corriger une option de compilation de quvi :D ). NomNom (qui devrait donc succéder à abby, projet devenu inactif, mais du même auteur), permet aussi de récupérer des vidéos à partir d'un flux youtube. Pour cela il se repose sur l'outil umph, du même auteur, qui permet de récupérer sous différentes formes les informations d'un flux Youtube (voir les exemple sur la page du projet).

umph n'est donc pas d'une immense utilité en lui même mais devient très pratique lorsqu'il est associé aux autres utilitaires de "legatvs", et est naturellement une dépendance pour NomNom.

J'ai donc packagé cet utilitaire et en ai proposé la revue, qui j'espère ne devrait pas poser de problèmes.

Fabien (eponyme)

emesene pour MSN

Fabien Nicoleau — Sat, 28 May 2011 15:04:00 +0200

A chaque nouvelle version de Fedora, j'essaie une alternative à l'un des logiciels que j'utilise quotidiennement, histoire de voir ce qui se fait ailleurs, de changer mes habitudes, de découvrir des fonctionnalités ... C'est d'ailleurs ainsi que j'ai adopté quodlibet pour ma musique !

Pour la version 15 de Fedora, j'ai décidé d'utiliser emesene en lieu et place d'aMsn, que j'utilise, je crois, depuis toujours sous linux. Le fait qu'aMsn ait des petits soucis de systray avec Gnome-Shell (cette fois-ci c'est vrai ! :D) aura joué en sa défaveur ! Et puis je n'ai jamai été vraiment fan de l'interface en tk. J'appréciais en fait aMsn pour les nombreuses fonctionalités qu'il à toujours apporté, souvent en avance sur les autres alternatives.

J'avais essayé emesene à ses débuts, et je m'étais dis que je retesterais quand il aurait murit. Je n'ai pas été décu, je le trouve complet, et vais donc l'utiliser avec cette nouvelle Fedora !

Fabien (eponyme)

Me voilà sous Fedora 15

Fabien Nicoleau — Thu, 26 May 2011 23:32:00 +0200

Ces derniers temps, j'étais peu (ou moins) enthousiaste lors des sorties de nouvelles versions de Fedora. J'installais, ça tournait, et puis voilà ... Cette fois-ci les choses sont assez différentes, car parmi les nombreuses nouveautées se cache une qui va changer mon quotidien : GNOME 3. Avec les pré-versions de F15, je l'avais testé rapidement, sans vraiment m'y mettre. La, plus le choix ! Et franchement mes craintes se sont vites envolées, je m'y suis habitué en une soirée, et ce grâce à llaumgui et trashy qui ont rédigé cette documentation qui a répondu à beaucoup de mes questions.

Une autre bonne surprise, pour moi, sera la disparition de ce vieu bogue de son. Plus besoins de remonter le volume à chaque démarrage, ca sera un petit confort.

Il me reste encore trois soucis, qui trouveront peut être solution dans les commentaires :

De nombreuses applications (xchat, amsn, quodlibet, packagekit) n'ont plus d'icône dans le systray. C'est vraiment gênant et je suis surpris de ne pas trouver d'info la dessus sur le net
Je ne trouve pas l'endroit ou indiquer les applications que je souhaite lancer au démarrage de gnome, comme conky
Je n'arrive plus à cacher un utilisateur dans la fenêtre de login, le fichier custom.conf de gdm ne semble plus faire effet

Il me restera à trouver un jeu d'icones et un nouveau thème pour les fenêtres car je ne suis pas un grand fan de celui par défaut, mais ca n'est pas le plus important pour le moment.

Il faut noter que GNOME 3 n'utilise plus gconf mais gsettings (avec dconf-editor, son interface graphique). Pour, sous Nautilus, être en mode "saisie de l'emplacement" par défaut, j'ai donc utilisé cette commande :

$ gsettings set org.gnome.nautilus.preferences always-use-location-entry true

Et vous, sous Gnome 3, ça va ? :D

Fabien (eponyme)

QtScript : exemple d'utilisation

Fabien Nicoleau — Sun, 20 Mar 2011 02:12:00 +0100

J'ai essayé dans mon billet précédent de démystifier QtScript et de montrer au travers de différents exemples quelques unes des possibilités offertes par ce module de la bibliothèque Qt. Après ces premiers pas, je vous propose ici d'utiliser QtScript dans un exemple concret. Il s'agira de créer une calculatrice pour laquelle chaque type d'opération possible sera un plugin développé en JavaScript. Il sera ainsi possible "d'étendre" cette calculatrice comme bon vous semble en codant de nouveaux types d'opérations. Cependant je m'en tiendrai dans cet exemple aux simples addition, soustraction, multiplication et division. J'ai appelé ce petit projet QtExCalc pour Qt Extendable Calculator.

Le projet

Pour commencer, assurez vous que le package qt-devel est installé sur votre poste. Si ce n'est pas le cas, sous Fedora, tapez :

# yum install qt-devel

Il faudra ensuite télécharger les sources du projet, dont vous trouverez l'archive jointe à ce billet. Une fois cette dernière décompressée, déplacez vous dans le dossier qtexcalc puis tapez :

$ qmake-qt4
$ make

Le projet est alors compilé. Vous pouvez l'exécuter :

$ ./qtexcalc

L'application se lance :

Elle est très simple. Choisissez un type d'opération proposé dans la liste, saisissez deux nombre, puis cliquez sur le bouton pour afficher le résultat. Tout l'intérêt de ce programme est donc qu'il est modulable, grâce à des scripts JS. A son lancement, elle charge des plugins placés dans le sous-répertoire plugins. Chaque plugin fourni trois informations :

Le libellé de son opération, qui sera affiché dans la liste ("Addition" par exemple)
Le signe de son opération, qui sera affiché sur le bouton ("+" par exemple)
Une procédure de traitement, prenant deux chiffres en paramètre, et renvoyant un résultat. Le traitement effectué est évidemment propre à chaque plugin

Le code

Les sources sont composées d'une classe Dialog comprennant la fenêtre principale, ainsi que les différents traitements associés aux actions de l'utilisateur, une classe Plugin, dont chaque instance "représentera" un des plugins, et qui sera chargée de dialoguer avec. Enfin, un fichier main, simplement chargé de créer la fenêtre principale et de l'afficher. Passons au code.

main.cpp

C'est le seul fichier dont je copierai intégralement le contenu ici, tant il est petit :

#include <QtGui/QApplication>
#include "dialog.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    Dialog w;
    w.show();
    return a.exec();
}

Comme expliqué plus tôt, on se contente ici d'afficher la fenêtre du projet.

Classe Plugin

Cette classe a en charge de dialoguer avec le plugin. Elle contient trois méthodes dont voici l'implémentation :

Plugin::Plugin(QScriptEngine* eng)
{
    this->engine = eng;
    this->sign =this->engine->globalObject().property("getOperationSign").call(QScriptValue()).toString() ;
}

QString Plugin::getSign() {
    return this->sign;
}

double Plugin::compute(double num1, double num2) {
    return this->engine->globalObject().property("compute").call(QScriptValue(),QScriptValueList() << num1<<num2).toNumber();
}

Le constructeur prend en paramètre un pointeur sur un moteur de script, qui permettra de dialoguer avec le plugin, et récupère ensuite le signe de l'opération du plugin en appelant sa fonction getOperationSign().

La méthode getSign() renvoie le signe de l'opération du plugin qui a été stocké dans le constructeur.

Enfin, la méthode compute() se charge d'effectuer l'opération. Elle attend deux paramètres qui seront passés à la fonction compute() du plugin. Elle renvoie ensuite le résultat de l'opération.

Classe Dialog

Voici la principale classe du projet. Je laisse de coté ici tout ce qui concerne la gui, pour ne se concentrer que sur QtScript. Commençons par la méthode loadPlugins() qui est appelée lors de la construction de l'objet et qui permet de "charger" les différents plugins :

void Dialog::loadPlugins() {
    QDir dirPlugins("plugins");
    QString fName;
    QScriptEngine * engine;
    QComboBox * cbPlugins = this->ui->cbChoosePlugin;
    cbPlugins->addItem(QString::fromUtf8 ("Choisissez une opération ..."),"");
    foreach(fName,dirPlugins.entryList(QStringList() << "*.qs")) {
        engine = new QScriptEngine();
        QFile file("plugins/"+fName);
        file.open(QIODevice::ReadOnly);
        engine->evaluate(file.readAll());
        file.close();
        cbPlugins->addItem(engine->globalObject().property("getOperationName").call(QScriptValue()).toString(),fName);
        this->plugins[fName] = new Plugin(engine) ;
    }
}

Tous les fichiers dont l'extension est qs (pour QtScript, mais on peut bien sûr utiliser ce qu'on veut) sont listés grâce à la méthode entryList(). Pour chacun des fichiers, on créé un moteur de script puis on évalue le contenu. Ensuite, on ajoute à la liste (addItem()) le nom de l'opération, en appelant la fonction getOperationName du plugin, et on donne le nom du fichier (fName) comme data. Enfin, on construit un nouvel objet Plugin auquel on passe en paramètre le moteur et que l'on stocke dans une QMap, avec le nom de fichier (fName toujours) comme clé. Ainsi, lorsqu'une opération sera choisie dans la liste, on récupèrera le data (correspondant au nom de fichier) grâce auquel on pourra accéder à l'objet correspondant de la QMap.

Passons maintenant au slot choosedPlugin appelé à chaque fois que l'on sélectionne un item dans la liste des opérations :

void Dialog::choosedPlugin(int index) {
    if(index>0) {
        this->ui->bProcess->setText(this->plugins[this->ui->cbChoosePlugin->itemData(index).toString()]->getSign());
        this->ui->bProcess->setEnabled(true);
    }
    else {
        this->ui->bProcess->setText("");
        this->ui->bProcess->setEnabled(false);
    }
}

On vérifie tout d'abord que l'on a pas sélectionné le premier élément, qui est celui demandant de choisir une opération. Si on a bien sélectionné une opération, on récupère la donnée de l'élément (itemData()) sélectionné, qui nous permet d'accéder à l'objet Plugin correspondant, depuis lequel on appelle la méthode getSign(). Le signe de l'opération est appliqué au bouton, qui est ensuite activé.

Passons au dernier slot, compute, appelé lorsque l'utilisateur clique sur le bouton :

void Dialog::compute() {
    if(!this->ui->leNumber1->text().isEmpty() && ! this->ui->leNumber2->text().isEmpty() ) {
        Plugin * selectedPlugin = this->plugins[this->ui->cbChoosePlugin->itemData(this->ui->cbChoosePlugin->currentIndex()).toString()];
        this->ui->lResult->setText(QString::number(selectedPlugin->compute(this->ui->leNumber1->text().toDouble(),this->ui->leNumber2->text().toDouble())));
    }
}

Si les deux champs de saisie ont été remplis, on récupère l'objet Plugin de l'opération sélectionnée. On appelle la méthode compute() du Plugin, en lui passant en paramètre la valeur des champs de saisie, qui nous retourne le résultat de l'opération, résultat que l'on affiche dans le libellé correspondant.

Voici pour terminer, le code du plugin "addition", je ne donne pas le code des 3 autres, qui se devine facilement, et qui est dispo dans les sources :

function getOperationName() {
    return "Addition";
}

function getOperationSign() {
    return "+";
}

function compute(num1,num2) {
    return num1+num2;
}

On y voit donc les trois fonctions nécessaires, donnant le libellé de l'opération, son signe, et enfin le résultat de l'opération.

Voilà pour l'explication de ce petit projet, qui j'espère vous permettra de voir de quelle façon on peut facilement avec Qt gérer des plugins écrits en JavaScript. Si vous avez des questions sur le code, n'hésitez pas à les poser dans les commentaires.

Bon dev'

Fabien (eponyme)

Premiers pas avec QtScript

Fabien Nicoleau — Thu, 03 Mar 2011 15:04:00 +0100

Dans un précédent billet, j'avais parlé de la possibilité d'intégrer très facilement dans vos applications Java des scripts écrits en JavaScript, et de la facilité avec laquelle vos applications peuvent interagir avec les scripts. J'avais ensuite proposé un exemple d'utilisation avec un robot IRC fonctionnant avec des plugins écrits en JavaScript.

La bibliothèque Qt permet elle aussi d'intégrer des scripts JavaScript dans vos applications. Je propose ici de découvrir comment le faire, à travers quelques exemples simples.

Avant de commencer

Avant d'entrer dans le vif du sujet, préparons d'abord le terrain. Je proposerai pour chaque exemple le code dans ce billet, mais je vous conseille, si vous voulez tester, de télécharger l'archive jointe à ce billet contenant les sources des exemples. Une fois décompressée, déplacez vous dans le dossier qtscripting, puis ouvrez une console, et tapez :

qmake-qt4
make

Tous les exemples sont alors compilés. Bien sûr, pour que la compilation fonctionne, ils vous faut installer le paquet qt-devel. Sous Fedora, tapez :

# yum install qt-devel

Une fois les exemples compilés, vous pouvez vous déplacer dans les dossiers, et lancer les exécutables.

Notez que pour ajouter le support des scripts au projet, il a simplement suffit d'ajouter script à la directive QT (voir le QT += script dans le fichier common.pri), et d'include QtScript dans les sources.

Exemple 1 : 1 + 1

Pour le premier exemple, faisons simple ! Il s'agit ici simplement de voir comment exécuter un code JavaScript depuis du code C++, et de récupérer le résultat.

On commence direct avec le code :

#include <QtScript>
#include <QApplication>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QScriptEngine engine;
    QScriptValue resultat = engine.evaluate("1+1");
    qDebug() << resultat.toString() ;
    return 0;
}

Rien de complexe. On créé d'abord un objet de type QScriptEngine, qui sera notre moteur de script, indispensable. On demande ensuite à notre moteur d'évaluer le code "1+1". Le résultat de l'évaluation est stocké dans un objet de type QScriptValue. Enfin on affiche le résultat. En parcourant la doc sur QScriptValue, vous pourrez vous rendre compte qu'il est possible d'effectuer de nombreuses vérifications afin de s'assurer que le résultat est exploitable, notamment en contrôlant son type.

Voilà pour un début, il n'y a rien d'exceptionnel bien sûr, mais les base sont posées : notre programme a affiché le résultat d'un code externe (en l'occurrence du JavaScript, même si ce n'est qu'une addition, et que le code est "en dur" dans le programme). Pour les plus sceptiques, j'affiche la sortie du programme :

[eponyme@localhost exemple1]$ ./exemple1
"2"
[eponyme@localhost exemple1]$

Surpris ? :D

Passons à la suite.

Exemple 2 : appel d'une fonction

Nous allons dans cette exemple appeler une fonction et lui passer un paramètre, puis afficher ce qu'elle nous renvoie. Le code :

#include <QtScript>
#include <QApplication>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QScriptEngine engine;
    engine.evaluate("function disMoiBonjour(prenom) { return \"Bonjour \"+prenom; }");
    QScriptValue disBonjour = engine.globalObject().property("disMoiBonjour");
    qDebug() << disBonjour.call(QScriptValue(),QScriptValueList() << "Fabien").toString() ;
    return 0;
}

Comme dans le premier exemple, on créé un moteur, mais cette fois ci au lieu de lui faire évaluer une addition, nous demandons d'évaluer la définition d'une fonction, appelée disMoiBonjour. Cette fonction retourne une phrase "disant bonjour" à la personne dont le prénom est passé en paramètre. La ligne suivante nous permet de récupérer parmi les objets du script (globalObject()) notre fonction disMoiBonjour (property()), conservée dans la variable disBonjour. Il ne nous reste plus qu'à l'appeler grâce à la méthode call(). Notez le second paramètre, qui est une liste de valeurs qui sont passées en arguments à la fonction appelée. Ici, on envoie juste la chaîne "Fabien".

Voici la sortie du programme :

[eponyme@localhost exemple2]$ ./exemple2
"Bonjour Fabien"
[eponyme@localhost exemple2]$

Cet article ayant juste pour but de découvrir des choses simples et basiques possibles avec QtScript, je ne rentre pas plus dans les le détail concernant les différentes méthodes utilisées ici, mais la documentation vous fera découvrir que l'on peut aller beaucoup plus loin.

Au passage, on voit déjà que du code JavaScript dans une chaine de caractères, ça n'est pas très pratique. Vivement qu'on puisse le mettre dans un fichier !

Exemple 3 : code JS dans un fichier et objet global

Pour le moment, nos scripts étaient "en dur" dans le code C++, ce qui n'a que très peu (aucun ?) intérêt. Voyons ici comment externaliser ce code et le placer dans un fichier. La méthode evaluate() prenant en paramètre une chaine de caractères, il sera très simple (surtout avec Qt) de récupérer le contenu d'un fichier texte pour le faire évaluer. Je profite aussi de cet exemple pour montrer comment exporter depuis le code C++ un objet global dans le script. Comme d'habitude, on attaque directement avec le code :

#include <QtScript>
#include <QApplication>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QScriptEngine engine;
    QFile file("script.qs");
    file.open(QIODevice::ReadOnly);
    engine.globalObject().setProperty("name","Fabien");
    engine.evaluate(file.readAll());
    file.close();
    return 0;
}

Comme on pouvait s'y attendre, la chose est très simple à réaliser grâce à l'objet QFile. On ouvre en lecture seule un fichier nommé script.qs, et on passe son contenu à la méthode evaluate() via la méthode readAll(). Le contenu du fichier est ainsi entièrement évalué. L'autre nouveauté ici est que l'on "envoie" dans le script l'objet "name", dont la valeur est "Fabien", avec la méthode setProperty(). Ainsi, à n'importe quel endroit du script, il sera possible d'accéder à cet objet.

Voyons d'ailleurs le contenu du script (fichier script.qs) :

print('Bonjour '+name);

Ce petit script se contentera donc d'afficher dans la console un bonjour à la personne dont le prénom est stocké dans l'objet name (et assigné depuis le code C++).

Voyons ce que ca donne à l'exécution :

[eponyme@localhost exemple3]$ ./exemple3
Bonjour Fabien
[eponyme@localhost exemple3]$

La encore, pas de grande surprise ! Mais désormais, vous pouvez stocker votre code JS dans un fichier, ce qui ouvre un grand nombre de possibilités, notamment celui de stocker différents scripts afin de charger différentes fonctions, pour un système de plugins.

Exemple 4 : envoi d'un QObject dans le script

L'exemple 3 nous a montré qu'il est possible d'envoyer un objet avec une valeur dans le script, et ce depuis le code C++. Cependant cet objet ne peut prendre qu'une valeur simple. Nous allons voir ici comment envoyer dans le script un QObject (et donc un de ses objets hérités, ce qui en fait beaucoup).

Pour illustrer cet exemple, je vais utiliser un QLabel, habituellement utilisé pour afficher un libellé dans une interface graphique. Voici le code :

#include <QtScript>
#include <QApplication>
#include <QLabel>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QLabel lbl;
    QScriptEngine engine;
    QFile file("script.qs");
    file.open(QIODevice::ReadOnly);
    lbl.setText("UN");
    QScriptValue object = engine.newQObject(&lbl);
    engine.globalObject().setProperty("label",object);
    engine.evaluate(file.readAll());
    file.close();
    qDebug() <<"Dans le code : " << lbl.text();
    return 0;
}

Le QLabel ne sera pas utilisé ici dans une interface, mais on utilise ses méthodes pour le manipuler. Après l'habituelle création du moteur, on créé donc un objet QLabel, pour lequel on modifie le libellé en le passant à "UN", grâce au slot setText(). Ensuite, la méthode newQObject() du moteur est appelée, prenant en paramètre un pointeur sur notre objet de type QLabel. C'est la valeur renvoyée par newQObject qui est utilisée pour le setProperty() de la ligne suivante, déjà utilisé dans l'exemple 3. Ainsi, dans notre script, on pourra utiliser notre objet QLabel n'importe quand grâce à la variable label, dont le nom est passé en premier argument à setProperty(). Comme dans les autres exemples, on évalue le script, puis on ferme le fichier. Enfin, on affiche la valeur de notre QLabel grâce à sa méthode text(). En toute logique, elle devrait renvoyer "UN", à moins que la valeur ait été changée depuis le script ... Voyons justement le code de ce dernier (fichier script.qs) :

print("Dans le script : "+label.text);
label.setText("DEUX");

Deux lignes, très simples. La première affiche la valeur du QLabel accessible grâce à la variable label. La valeur du QLabel est obtenue grâce à la propriété text de ce dernier. Sur la seconde ligne, on change la valeur du QLabel à "DEUX", grâce à setText().

Voyons ce que donne l'exécution :

[eponyme@localhost exemple4]$ ./exemple4
Dans le script : UN
Dans le code : "DEUX"
[eponyme@localhost exemple4]$

On voit ici l'évolution de notre QObject ! La première valeur affichée ("UN") depuis le script (avec print()) est celle qui avait été fixée dans le code C++. Après avoir affiché la valeur, le script JS a changé la valeur du QLabel, et depuis le code, la valeur affichée est bien "DEUX".

Nous pouvons donc de façon très simple passer à notre script JS des QObject et lui permettre d'en modifier les propriétés.

Exemple 5 : gestion des erreurs

Lorsque l'on débute, ou lorsque l'on commence à faire des choses compliquées, il arrive souvent que l'on bloque car le code JS n'est pas évalué. Dans la plupart des cas, il s'agit juste d'une erreur de syntaxe. Mais il est parfois difficile de savoir pourquoi est ce que notre script n'est pas évalué, et donc qu'il est impossible d'interagir avec lui ensuite. On peut aussi être parfois sûr de son code, et ne pas penser qu'il y a une erreur. Heureusement il est possible, lorsqu'une erreur est rencontrée, d'afficher un message. Voici un code d'exemple :

#include <QtScript>
#include <QApplication>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QScriptEngine engine;
    QScriptValue result = engine.evaluate("print('Bonjour !'");
    if (result.isError()) {
        qDebug() << result.property("message").toString();
    }
    return 0;
}

Dans ce code, on demande au moteur d'évaluer du JavaScript devant afficher "Bonjour !", mais la parenthèse fermante est volontairement oubliée. On se sert de la valeur renvoyée par l'évaluation pour vérifier s'il y a eu une erreur avec isError(). Si c'est le cas, on peut afficher un message explicatif en récupérant la propriété message du résultat d'évaluation.

Voyons l'exécution du programme :

[eponyme@localhost exemple5]$ ./exemple5
"Parse error"
[eponyme@localhost exemple5]$

Notre code n'est pas évalué, et le moteur nous indique une Parse error. On sait au moins ou chercher. Cette vérification vous permettra de gagner un peu de temps si vous n'obtenez pas le résultat espéré.

Exemple 6 : signaux et slots

Les signaux et slots sont l'un des avantages du développement avec la bibliothèque Qt, et n'ont pas été oubliés avec QtScript. Dans ce dernier exemple, nous allons créer une fenêtre basique comprenant deux boutons. Le premier, appelé "Bonjour", devra afficher "Bonjour !" dans la console lorsque l'on clique dessus, et le second, "Au revoir", devra afficher ... "Au revoir !" (et oui !) lorsque l'on clique dessus. La particularité est que ces affichages dans la console se feront depuis un script JS, et non pas directement depuis des slots dans le code C++. L'intérêt ? Ici, aucun. Il s'agira simplement de montrer que l'on peut connecter un signal à un slot dont l'implémentation est faite dans un script JS, ce qui permet de personnaliser facilement une application en changeant le comportement du slot dans les scripts. Pour l'exemple, nous verrons deux façons différentes de connecter un signal à un slot implémenté dans un script, la première sera faite depuis le code C++, pour le bouton "Bonjour", et la seconde directement dans le script JS, pour le bouton "Au revoir".

Passons au code :

#include <QtScript>
#include <QApplication>
#include <QtGui>
int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QWidget fenetre;
    QVBoxLayout vbox(&fenetre);
    QPushButton bBonjour("Bonjour");
    QPushButton bAuRevoir("Au revoir");
    vbox.addWidget(&bBonjour);
    vbox.addWidget(&bAuRevoir);

    QScriptEngine engine;
    QFile file("script.qs");
    file.open(QIODevice::ReadOnly);
    QScriptValue objBonjour = engine.newQObject(&bBonjour);
    QScriptValue objAuRevoir = engine.newQObject(&bAuRevoir);
    engine.globalObject().setProperty("objAuRevoir",objAuRevoir);
    engine.evaluate(file.readAll());
    file.close();
    QScriptValue slot = engine.globalObject().property("bonjourHandler");
    qScriptConnect(&bBonjour, SIGNAL(clicked()), objBonjour, slot);

    fenetre.show();
    return app.exec();
}

C'est un peu plus long que d'habitude, certes, mais le premier pavé ne concerne que l'interface graphique, ce qui n'est pas le sujet de ce billet. On y créé les deux boutons et on les place sur la fenêtre.

Ensuite, comme d'habitude, on créé un moteur, qui évaluera du code JS placé dans un fichier. Deux "objets QtScript" sont créés à partir des deux boutons, grâce à newQObject() : objBonjour et objAuRevoir. Ils nous serviront à réaliser les connexions avec les slots du script. L'objet objAuRevoir est exporté dans le script car nous en aurons besoin pour réaliser la connexion au slot.

Une fois l'évaluation du script faite, on récupère la propriété bonjourHander, qui est une fonction dans le script JS, que l'on stocke dans la variable slot. Cette variable est utilisée ensuite pour réaliser la connexion entre le signal clicked du bouton "Bonjour" et le slot bonjourHandler, grâce à la fonction qScriptConnect().

Voyons maintenant le contenu du script (fichier script.qs) :

function bonjourHandler () {
print('Bonjour !');
}
function auRevoirHandler () {
print('Au revoir !');
}
objAuRevoir.clicked.connect(this.auRevoirHandler);

On y trouve les deux fonctions qui seront appelées lors des clics sur les boutons. bonjourHandler est déjà connectée au bouton "Bonjour" via l'appel à qScriptConnect() dans le code C++. La fonction auRevoirHandler est elle connectée au bouton "Au revoir" à la dernière ligne du script, qui utilise l'objet objAuRevoir exporté dans le programme. Ainsi nos deux fonctions sont connectées à leur bouton respectif, l'une depuis le code C++, l'autre depuis le script JS. A vous de voir ce que vous préférez !

Une petite image pour l'exécution du programme :

C'est sur cet exemple que ce termine cette initiation. Je n'ai pas la prétention avec cet article de donner une vue d'ensemble des possibilités offertes par QtScript. J'en suis d'ailleurs encore au stade de la découverte. Mais ces exemples pourrons vous permettre de vous lancer, et de démystifier un peu les choses ! Je proposerai dans un prochain article un exemple concret d'utilisation de QtScript pour un système de plugins.

Hormis les liens disséminés un peu partout dans l'article, les deux sources qui m'ont le plus aidé sont :

Bon dev' !

Fabien (eponyme)

Réponse à l'article "Fedora vs OpenSuse vs Ubuntu" du Linux Planet #63

Fabien Nicoleau — Sat, 22 Jan 2011 20:56:00 +0100

Vieil abonné de ce magazine, j'ai reçu le dernier numéro il y a quelques jours, qui propose un comparatif des trois distributions mentionnées dans le titre, proposant même en couverture de nous dire quelle est la meilleure ! Le problème est que ce comparatif se trouve en fait être un "travail" bâclé, plutôt pro-ubuntu, contre Fedora, et qui ne nous dis pas grand chose sur OpenSuse. Si le résultat était basé sur un vrai comparatif, on pourrait admettre la chose. Sauf que ce n'est pas le cas, et c'est Fedora qui en pâti le plus. Selon cet article, nous sommes une communauté mal organisée, et notre système est difficilement configurable sans un bon niveau d'anglais. De plus Fedora n'a volontairement inclut aucun outil de configuration afin de ne s'adresser qu'aux experts. Ah si il y en a un, oui oui, nous avons un "centre de contrôle", ils ont même mis une capture d'écran ! En regardant de plus près, le "centre de contrôle" est l'outil de configuration de compiz-fusion. Pas étonnant qu'il soit jugé "séduisant mais incomplet" pour configurer notre Fedora, puisque qu'il n'est pas fait pour ça. Pour l'offre logicielle de Fedora, l'auteur reproche au dépôt Livna de ne pas être à jour ... Bref, vous voyez le niveau de l'article, et surtout le non professionnalisme. On trouve des défauts à Fedora qui se transforment presque en avantage chez les autres distros. Cela dit, Ubuntu n'est pas en reste, puisque qu'un titre nous dis "Ubuntu, des assistants efficaces", et quelques lignes plus bas "Les quelques assistants présents ne sont pas d'une grande efficacité et souvent trop incomplets". En somme, un article qui n'en ai pas vraiment un, et qui m'a exaspéré. On regarde la distro vite fait, on clique ici et la, et on donne un avis. MrTom dans son billet pointe les deux erreurs principales : ne pas avoir parlé des idéaux des distros, et ne pas avoir contacté la communauté.

J'ai donc joints le courrier des lecteurs, et leur ai envoyé, ce courrier, en espérant qu'il y aura au moins un petit correctif pour ce qui a été inventé de toute pièce, et que comme je le leur propose, pour se rattraper, ils prendront le temps de rédiger un vrai article sur Fedora dans un numéro, en prenant soin de s'intéresser vraiment à la distribution, sa communauté, sa philosophie, bref, leur job.

Edit : Honte à moi, je retire ce que j'ai dis sur le panneau de contrôle qui existe bel et bien. L'erreur vient donc de moi, et non pas du magazine, qui pour le coup me l'a fait découvrir. Merci à eux :)

Bonjour,

Je suis utilisateur de Fedora depuis la "core 3". J'aimerais vous faire part de mon mécontentement au sujet de l'article "Fedora vs OpenSuse vs Ubuntu" du numéro 63 de votre magazine, pour lequel j'ai trouvé qu'il y a eu de la part des auteurs un réel manque de professionnalisme. Je doute même que la distribution ai été réellement testée, tant certaines erreurs sont flagrantes.

Je me permets donc ici de vous faire part de ce que j'ai relevé :

Dans la partie "Configuration", vous mettez un sous titre pour Fedora "Le minimum syndical". Vous ajoutez ensuite que c'est un choix délibéré afin de ne pas attirer trop de débutants. J'aimerais avoir une référence la dessus, car je pense que c'est totalement faux. D'ailleurs les outils de configuration graphique sont très nombreux, et se trouvent dans les menus Système=>Préférences et Système=>Administration. Je ne suis pas débutant, et j'utilise systématiquement des outils graphiques de configuration lorsque j'ai des paramétrages à faire. Les outils graphiques de configuration sous Fedora se nomment tous system-config-... (network, printer, keyboard). Non seulement les outils sont donc présents, mais en plus la plupart (tous ?) ont été développé par RedHat / Fedora, et certains ont été repris dans d'autres distributions... Vous parlez ensuite d'un "centre de contrôle plutôt séduisant" mais "très incomplet et très sommaire". J'ai été très surpris, car utilisant Fedora depuis très longtemps, je n'avais jamais entendu parler d'un "centre de contrôle" propre à ma distribution préférée. C'est en regardant la capture d'écran que vous avez associée à ce paragraphe que j'ai compris l'erreur : vous avez utilisé l'outil de configuration de compiz-fusion... Il est donc normal que vous le trouviez incomplet pour configurer une distribution. En revanche pour configurer compiz (ce pourquoi il a été fait), je le trouve plutôt pratique. J’espère que vous admettrez ici que vous n'avez absolument pas cherché à savoir comment configurer Fedora, que vous avez pris le premier outil de configuration trouvé et que vous vous êtes basé la dessus pour vous faire un avis. Sauf que l'outil n'était pas le bon, et donc l'avis n'a aucun crédit. Vous trompez d'ailleurs vos lecteur. C'est difficilement acceptable. Vous parlez pour terminer de l'installation des pilotes et logiciels propriétaires, tels que flash. Je ne vois pas ce que ça vient faire dans la partie configuration... Vous dites qu'il faudra lire les documentation, mais vous oubliez de préciser qu'une fois la doc lue, l'installation se fait en tapant au maximum deux lignes dans un terminal... Vous oubliez d'ailleurs de parler de la philosophie de Fedora, et de son attachement au libre. Vous dites avoir eu des soucis pour installer flash et la lecture de mp3. Je suis depuis de nombreuses versions la documentation lors d'une nouvelle version de Fedora pour installer (entre autres choses) ces outils, et tout marche à chaque fois. Il serait intéressant que vous indiquiez les problèmes que vous avez rencontré, pour pouvoir modifier la doc si nécessaire, mais étant donné le manque d’honnêteté avec lequel vous avez entamé ce paragraphe, j'ai quelques doutes quand au fait que vous auriez essayé d'installer des pilotes.

Il est aussi intéressant de noter que dans la colonne d’à coté, vous donnez un avis très positif d'OpenSuse en raison de la richesse de ses DVD, alors que votre test est fait depuis un live CD. J'y reviendrais plus tard ... Il est aussi intéressant de noter que pour Ubuntu, vous dites "Pour la partie périphérique, soit ça fonctionne directement, soit il faudra passer par la console pour régler le problème". En gros, soit ça marche, soit non, et la on utilise la console. Bref, quelle différence avec les autres distribution ? D'un seul coup utiliser sa console n'est pas un problème, alors que l'utiliser pour installer un driver propriétaire sous Fedora en est un, curieux. D'ailleurs, toujours pour la colonne "Ubuntu", le titre est "des assistants efficaces", puis plus loin : "Les quelques assistants présents ne sont pas d'une grande efficacité et souvent trop incomplets". J'espère que le stagiaire qui a écrit cette partie n'a pas eu les tickets resto que vous lui aurez promis !

Je passe au point suivant : "Offre logicielle". Vous parlez des nouveautés, du fait qu'il ne faut pas "avoir peur" d'essayer les dernière innovations. C'est assez vrai. Auriez vous donc vraiment testé cette distribution ? Vous parlez ensuite du fait que les dépôts RPM Fusion et Livna, sont parfois "très incomplets" selon vous. Je vous invite à lire la documentation francophone du site que vous critiquez à plusieurs reprises pour vous rendre compte qu'en ce qui concerne Livna, vous risquez d'attendre longtemps de nouveaux logiciels : http://doc.fedora-fr.org/wiki/D%C3%A9p%C3%B4t_livna. Je n'ai pas compris ce que sont les "décalages entre versions" non comblés. Il est intéressant de voir que vous parlez du dépôt ccrma, très spécifique, mais que vous omettez de parler d'un dépôt comme celui de "Remi" (et dont la configuration est extrêmement simple et expliquée dans la documentation francophone ...) pourtant très réputé dans la communauté (et pas que francophone).

Vous trouvez l'offre pas aussi complète que pour Ubuntu. Pour ma part, outre les dépôts standards déjà installés, j'utilise simplement le dépôt rpmfusion, et j'ai toute l'offre logicielle dont j'ai besoins. La fusion des dépôts Fedora a non seulement permis de donner une grande importance à la communauté, mais permet aussi de faire en sorte que l'offre logicielle réponde à des règles communes, et assure une cohérence du système. Oui, Ubuntu est extrêmement complet. Je package des logiciels pour Fedora et j'ai pu m'apercevoir que si un de mes paquets à mis 1 mois de plus que sous Ubuntu à arriver dans les dépôts officiels (et donc ne nécessitant aucune installation de dépôt tiers pour l'utilisateur), le packageur Ubuntu passait lui par un dépôt tiers qui se souciait peu des conventions pour l'emplacement de certains fichiers. Oui, le package ubuntu était prêt avant, mais il n'avait pas été vérifié, et nécessitait un dépôt tiers. Mon insistance auprès du développeur du logiciel pour permettre plus facilement de placer les fichiers du programme au bon endroit sur le système lui ont permit de fournir un système d'installation plus propre, et a facilité l'acceptation du paquet dans d'autres distributions. Chacun sa politique, mais il est important de préciser les choses ...

Le point suivant : "Communauté - Aide". Vous continuez sur votre exemple d'installation du dépôt ccrma (sans préciser à vos lecteurs qu'ils s'agit d'un dépôt très spécifique, concernant surtout les musiciens, et que certains des logiciels qu'il propose nécessitent aussi certainement, pour les autres distributions, l'utilisation de dépôts tiers). Vous dites ne pas être "convaincus" de l'aide donnée sur le site d'aide francophone, sauf qu'elle fonctionne, et que les urls utilisées sont celles des miroirs français données sur le site officiel du projet. Vous vous doutez bien qu'elles n'auraient pas été utilisées si elles avaient été du type "http://jesuisunpirate.com/ccrm.repo" ... L'outil proposé pour installer le rpm est "yum", et l'option --nogpgcheck est utilisée car effectivement le paquet n'est pas signé. C'est une erreur du dépôt (tiers !), et pas une erreur de Fedora. Vous dites que le site officiel donne une solution (utiliser rpm directement, plutôt que yum), et qu'elle ne marche pas. Je viens de faire l'essai, et ça fonctionne chez moi. La encore vous ne donnez aucune précision... En revanche, même en passant par "rpm", on a un avertissement au sujet de la non signature du paquet. Au final vous ne dites pas ce qui a fonctionné. Vous dites ensuite que la communauté française n'est pas "trop organisée" pour la documentation. Je suis curieux de savoir le temps que vous avez pris pour savoir quelle est notre organisation ... autant que pour trouver le panneau de contrôle qui n'existe pas ?

Ce paragraphe sur la communauté montre parfaitement votre partialité, et de quelle façon vous cherchez à dénigrer Fedora. Vous prenez un exemple très précis sur Fedora, un dépôt dont la plupart de vos lecteur n'aurons pas besoins. Vous dites avoir des problèmes avec ... vous ne donnez pas de solution ... Vous nous servez ensuite une petite remontrance en nous disant que la documentation joue un rôle important dans le choix d'une distribution ... En revanche pour OpenSuse, c'est magique ! Il faut d'abord chercher quels sont les sites d'aide, pour ensuite pouvoir rechercher dessus. Mais ça ne vous pose pas de souci. Vous dites qu'ils répondent au "maximum des attentes", mais vos attentes pour OpenSuse semblent moins pointilleuses que pour Fedora. J'espère ne pas blesser les utilisateurs francophones d'OpenSuse (j'en fais aussi partie !), mais ce n'est pas un secret que de dire que la communauté est "plutôt petite". Vous finissez en disant que la communauté francophone est quasi inexistante (c'est pire que mal organisée (selon vous) non ?). Ne mettre qu'un point d'écart entre Fedora et OpenSuse ne reflète absolument pas la réalité. De plus vos comparaisons sont totalement inégales. C'est bien de mettre des notes, mais il serait bien de mettre un barème, cela rendrait peut être les choses moins aléatoires, et vous aurait peut être forcé à faire une réelle comparaison ...

Votre bilan est plutôt fidèle au reste. Dans l'introduction de l'article, vous dites qu'il ne s'agit pas d'un comparatif de bureau. Heureusement que vous n’êtes pas allés jusque la ! A quoi aurions nous eu droit. Vous arrivez quand même à dire que Fedora et Ubuntu sont diffusées avec Gnome, laissant penser que pour avoir kde avec Fedora, il faudrait, à l'image de Ubuntu, télécharger une "Kedora". Vous avez simplement utilisé le liveCD gnome, comme vous auriez pu prendre le liveCD KDE de Fedora. Sinon, le DVD propose les deux bureaux (puisque vous parlez des dvd comme un point positif pour OpenSuse ...).

Bref, j'espère vous avoir montré que votre "article" n'a rien de professionnel, et n'a pas fait l'objet d'un réel travail (la bourde sur le panneau de contrôle de compiz est franchement énorme, et a du mal à passer !). Voir que l'un des auteurs est rédacteur en chef du magazine me fait peur. Utilisant Fedora et m'investissant un peu dans la communauté, j'ai pu relever vos erreurs. Mais je me dis aujourd'hui qu'il est probable que vous aillez fait le même genre d'article sur des sujets auxquels je ne connais rien, et que je me sois fait "avoir" comme vous aurez bien eu les gens qui ne connaissent pas Fedora et a qui vous aurez fourni un tas de fausses informations.

Je ne sais pas comment vous réagirez à ce message, vous n'hésitez pas de temps en temps à publier des courriers négatifs de vos lecteurs, ce qui est plutôt une bonne chose. Le mien est bien long et nécessiterait quelque pages. Cependant les erreurs ayant été grosses, je trouve normal que des utilisateurs de Fedora puissent avoir un droit de réponse, et surtout rectifier les choses. J'ai donc rédigé un article sur mon blog (http://blog.nicoleau-fabien.net/index.php?post/2011/01/22/R%C3%A9ponse-%C3%A0-l-article-Fedora-vs-OpenSuse-vs-Ubuntu-du-Linux-Planet-63), diffusé aussi sur le planet fedora francophone. Thomas Canniot en a aussi rédigé un, diffusé sur plusieurs planet, et reprends de façon constructive les points qui ont manqué pour que votre article puisse avoir un réel sens (http://blog.mrtomlinux.org/index.php?post/Plan%C3%A8te-Linux-%3A-num%C3%A9ro-de-janvier-2011-d%C3%A9cevant-!). Il pose d'ailleurs une bonne question : pourquoi ne pas être venus nous voir ? Je pense que vous vous devez au moins de rectifier les choses dans votre prochain numéro, notamment à propos du centre de contrôle. Une réaction plus positive, et constructive, serait de proposer dans un futur numéro une réelle présentation de Fedora, avec un réel investissement, un rapprochement avec la communauté, et de mettre en évidence sa philosophie, qui fait d'elle une distribution à part. D'ailleurs, toutes les distributions mériteraient cela, pas seulement Fedora.

C'est la première fois que je vous écris, je me permets donc d'enchainer sur un avis à propos de votre magazine :

contrairement à ce que vous aurez peut être pu penser, je ne suis pas un "anti ubuntu", ou "anti OpenSuse", qui sont deux distribution que j'ai utilisées et appréciées. Cependant je regrette que tous vos articles tournent autour de ubuntu, ça en est exaspérant. Bien sur vous présentez d'autres distributions, mais lorsqu'il s'agit de parler d'un logiciel, de son installation, c'est toujours sous ubuntu (à une époque c'était mandrake). Moi, comme beaucoup d'autres personnes, je ne suis pas utilisateur de ubuntu. Est ce une tare au point de ne pas avoir le droit de temps en temps d'avoir UN article qui ne se base pas sur Ubuntu. Bien sur en parlant de ubuntu, vous touchez le plus de monde, mais les autres ? Toutes les distributions ont des choses à proposer, et je trouve dommage que vous tombiez dans la facilité de toujours rester sur la même distro. Vous dites parfois que c'est "plus simple", mais ça en devient lassant. Vous rencontrez aussi des problèmes sous ubuntu, et vous fournissez des solutions. Pourquoi ne pas en fournir pour les autres distributions ? Linux est considéré comme un système alternatif, mais bientôt, les gens, à force de lire vos articles, penseront que mandriva, opensuse, fedora, et bien d'autres, sont des distributions secondaires par rapport à ubuntu. Ce serait des alternatives à Ubuntu, dans un système alternatif à Windows.

Il est évidemment difficile de connaitre toutes les distributions, et de pouvoir changer chaque semaine. Cela doit prendre beaucoup de temps. Mais je regrette que vous ne sembliez pas essayer. Si les choses sont moins faciles ailleurs, alors ça ne vaut pas le coup de chercher et fournir une solution ? Vous pourriez vous aussi être une source de documentation et un fournisseur francophone d'aide, comme vous semblez y tenir. Il est bien loin le temps ou j'avais sur mon bureau quelques numéros de linux planet avec des marques pages partout parce qu'il y avait la petite astuce qui résolvait mon souci. J'ai de plus en plus l'impression de lire "Ubuntu planet". C'est très bien ubuntu, et c'est très bien que les utilisateurs puissent lire vos articles et utiliser facilement les commandes que vous fournissez. Mais moi je n'utilise pas Ubuntu, et j'aimerai avoir un magazine comme il l'était avant, quand il mettait en avant la diversité de Linux, et de tout ce que ce système offre.

J'ai tous vos numéros depuis le #23, mais suite à cet article, et la sensation de ne pas être "le bon lecteur puisque je n'ai pas la bonne distro", je ne pense pas que je renouvellerai mon abonnement.

Fabien Nicoleau

Un très fidèle lecteur, très déçu

Scripts JS avec Java et Rhino : mise en œuvre avec un bot IRC

Fabien Nicoleau — Sat, 20 Nov 2010 14:18:00 +0100

Je montrais dans mon billet précédent que grâce à Rhino il est possible d'exécuter du code JavaScript depuis un programme Java, et comment il possible de se servir de ce système pour gérer des plugins. Je propose dans ce billet de mettre en œuvre ces fonctionnalités et de les appliquer à un projet simple : un robot IRC modulaire. Le principe est d'avoir un robot écrit en Java et capable de se connecter à un serveur IRC, puis de communiquer avec lui (envoi et réception de messages). Nous n'ajouterons rien à ce programme Java, aucun savoir faire pour ce robot, à une exception prêt : la possibilité de stocker des plugins qui lui permettront d'avoir de nouvelles fonctionnalités. Attention, le sujet de ce billet n'étant pas le codage d'un robot IRC (il y en a de meilleurs pour ca ^^), celui présenté ici est ultra simple, et se contente du minimum.

Pour comprendre ce programme, il faut avoir quelques notions sur Rhino/Java, des notions sur les expressions régulières, et notamment les groups qui seront bien utiles ici, et savoir en gros ce qu'est un client IRC.

Le décor

Le programme sera donc codé en Java. Une classe JIrcRobot se chargera de se connecter au serveur IRC, et de communiquer avec lui. Une interface permettra de définir les méthodes à implémenter par les plugins. Elle sera originalement nommée Plugin. La classe JIrcRobot chargera les plugins disponibles, c'est à dire ceux contenus dans le dossier originalement nommé plugins et dont l'extension est .js, puisqu'ils contiennent du code JavaScript. Cela permettra aussi de pouvoir désactiver le chargement d'un plugin en modifiant simplement son extension. Une fois les plugins chargés, le programme attendra des messages du serveur. A chaque message reçu, il interrogera tout ses plugins pour savoir si l'un d'eux est concerné par le message. Si c'est le cas, le plugin sera alors exécuté et pourra alors réagir en envoyant des messages au serveur IRC.

Le test

Pour ceux qui préfèrent voir les choses fonctionner tout de suite, et voir comment ca marche, je vous propose de tester tout de suite le programme. Il vous faut récupérer tous les fichiers en annexe de ce programme : le fichier JIrcRobot.java ainsi que tous les fichiers en .js, qui seront à mettre dans un dossier nommé plugins. JIrcRobot.java sera à mettre au même niveau d'arborescence que le dossier plugins. Vous pouvez sinon juste prendre le fichier jircrobot.tar.gz et le décompresser.

Ouvrez ensuite le fichier JIrcRobot.java et éditez les paramètres de connexion, situés sous le commentaire "CONFIGURATION DE LA CONNEXION AU SERVEUR" pour donner un pseudonyme au robot, lui indiquer sur quel serveur il doit se connecter, et quels canaux il doit rejoindre. Sauvegardez les modifications et compilez le programme :

javac JIrcRobot.java

Vous pouvez maintenant l'exécuter :

java JIrcRobot

Le robot charge les plugins puis se connecte au serveur. En l'état actuel, le robot est capable de répondre aux PING du serveur, afin qu'il ne coupe pas la connexion, de rejoindre des canaux de discussion, de se présenter quand il rejoint un canal et souhaiter la bienvenue à ceux qui arrivent ensuite, de se couper si quelqu'un tape "!QUIT" et enfin de crier "COCORICO" si une phrase contient "france". Ces fonctionnalités sont toutes apportées par les plugins. Le programme Java en lui même ne sait rien faire de tout ca.

La classe JIrcRobot

Il est maintenant temps de comprendre comment tout cela fonctionne. Je passe rapidement sur les fonctionnalités liées au protocole IRC. Sans entrer dans le code, il faut juste savoir que la classe propose ces méthodes :

connect() : se connecte au serveur IRC
getNickName() : renvoie le pseudonyme du robot
joinChannels() : envoie les commandes au serveur IRC pour rejoindre des canaux de discussion
loadPlugins() : charge tous les plugins disponibles dans un dossier
readLine() : lis un message provenant du serveur, s'il y en a un d'arrivé
run() : boucle conservant la connexion avec le serveur, et exécutant les plugins si besoin
setStayConnected() : permet d'indiquer si l'on souhaite rester connecté au serveur ou non
write() : envoi un message au serveur IRC

Les méthodes importantes seront détaillées ensuite : loadPlugins et run.

Enfin la classe contient une interface privée, Plugin, qui permet de définir les méthodes que devront implémenter les plugins :

getPattern() : retournera l'expression régulière qui si elle est validée, indiquera que le plugin doit réagir au message arrivé
patternMatch() : cette méthode sera appelée si l'expression régulière du plugin match avec le message arrivé

Nos plugins devront donc implémenter ces deux méthodes.

Le programme Java

Après avoir vu les méthodes permettant de dialoguer avec le serveur, intéressons nous, dans le détail cette fois-ci, au code des deux principales. Avant cela, un rapide coup d'œil à la méthode main du programme :

public static void main(String[] args) {
    JIrcRobot jir = new JIrcRobot();
    jir.loadPlugins("plugins");
    if (jir.connect()) {
        jir.run();
    }
}

Rien de complexe : on créé un objet JIrcRobot, on charge les plugins, on connecte le robot au serveur IRC, et enfin on se met en attente de réception des messages avec la méthode run(). Il est maintenant temps de voir comment sont chargés les plugins, avec la méthode loadPlugins ;

public void loadPlugins(String folder) {
    ScriptEngine engine;
Invocable inv;
File dir = new File(folder);
    for (File file : dir.listFiles()) {
        if (file.isFile() && file.getName().toLowerCase().endsWith(".js")) {
            try {
                engine = new ScriptEngineManager().getEngineByName("JavaScript");
                engine.put("robot", this);
                engine.eval(new FileReader(file.getAbsolutePath()));
                inv = (Invocable) engine;
                this.plugins.add(inv.getInterface(Plugin.class));
                System.out.println(file.getAbsolutePath() + " loaded.");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

Cette méthode va lister (listFiles) le dossier dont le nom lui est passé en paramètre (folder). Pour chaque fichier dont l'extension est .js (endsWith), elle créé un moteur de JavaScript (getEngineByName) et place dans l'environnement du script une variable nommée robot pointant sur l'objet JIrcRobot (put). Ensuite elle lit le contenu du fichier et stocke dans le tableau plugins une instanciation de l'interface Plugin provenant du fichier (getInterface).

Le chargement des plugins consiste donc à stocker des objets implémentant l'interface Plugin et dont le contenu provient des fichiers JavaScript.

Maintenant, la méthode run :

public void run() {
    String buffer;
    Matcher matcher;
    while (this.stayConnected) {
        buffer = this.readLine();
        if (!buffer.equals("")) {
            System.out.println(buffer);
            for (Plugin p : this.plugins) {
                matcher = Pattern.compile(p.getPattern()).matcher(buffer);
                if (matcher.find()) {
                    p.patternMatch(matcher);
                }
            }
        }
    }
}

Cette méthode contient une boucle qui attend un message du serveur IRC (readLine). Une fois qu'un message est reçu, elle boucle sur tous les plugins chargés. Pour chacun d'eux, elle teste si le pattern du plugin (p.getPattern()) match avec le message reçu (buffer). Si c'est le cas (find), la méthode patterMatch() du plugin est appellée et on lui passe en paramètre le matcher, ce qui permettra au plugin d'analyser les groupes capturés grâce à l'expression régulière. C'est assez pratique car le plugin reçoit ainsi seulement ce qui l'intéresse, et qu'il a lui-même spécifié dans la regex.

C'est ici que s'arrête le détail ! Nous avons un système qui stocke des plugins et un autre qui communique avec eux pour savoir s'il faut les solliciter (grâce à un système de regex ici, mais ca pourrait être autrement) et qui qui les exécute si besoin. Ce robot IRC est donc ainsi fait d'un noyau, disposant de peu de fonctionnalités, mais extensible à volonté.

Les plugins

Notre programme étant prêt, concentrons nous maintenant sur les plugins. Nous créerons un fichier par plugin.

ping.js

Le serveur IRC envoie régulièrement un message PING auquel le client doit répondre. Si la réponse n'est pas envoyée dans un certain laps de temps, le serveur rompt la connexion. Ce plugin est donc vital. Le message est du type "PING :msg". Le client doit répondre "PONG :msg". msg est parfois le nom du serveur, ou parfois un numéro aléatoire. Pour un PING reçu, on récupèrera donc la partie droite, et on s'en servira pour envoyer le PONG. Voici le contenu de ping.js :

importClass(java.util.regex.Matcher);

function getPattern() {
return 'PING\\s:(.*)';
}

function patternMatch(matcher) {
robot.write("PONG :" + matcher.group(1));
}

On commence par importer la classe Java Matcher. On implémente ensuite les deux méthodes nécessaires de l'interface Plugin. Le regex renvoyé par getPattern contient un groupe qui capturera la partie à renvoyer par le PONG. La fonction patternMatch qui est appelée si le regex a matché envoie le PONG suivi du groupe capturé dans le PING. Pour cela elle utilise la variable robot représentant l'objet JIrcRobot pour envoyer un message au serveur.

endOfMOTD.js

Le Message Of The Day (MOTD) est un texte envoyé par le serveur au client lorsqu'il se connecte. Il contient souvent des informations sur le serveur. Une fois le MOTD envoyé, le serveur envoie un message indiquant la fin du MOTD du type : ":calvino.freenode.net 376 jircrobot :End of /MOTD command.". Il est important de réagir à ce message car certains serveurs n'autorisent pas le client à rejoindre des canaux tant que le MOTD n'a pas été envoyé. En attendant la réception de ce message pour rejoindre des canaux, on est sûr qu'on ne sera pas bloqué. Ce plugin réagira donc à ce message, et une fois reçu, appellera la méthode joinChannels de la classe JIrcRobot :

importClass(java.util.regex.Matcher);

function getPattern() {
return ':.*\\s376\\s.*';
}

function patternMatch(matcher) {
robot.joinChannels();
}

C'est assez simple ici encore. On donne la regex pour capturer la fin du MOTD et lorsque que le message est arrivé, on utilise la variable robot pour se connecter aux canaux.

quit.js

Ce plugin permettra de stopper le bot. Lorsqu'une personne tapera !QUIT sur un canal, le robot se stoppera. Biensûr dans le cadre d'un "vrai" bot, il faudrait s'assurer que la personne voulant couper le robot en a le droit, en se basant sur son nom d'hôte ou son pseudonyme. Le message envoyé par le serveur sera du type ":someone!~someident@some-host.com PRIVMSG #channel1 :!QUIT". Voici le contenu du plugin :

importClass(java.util.regex.Matcher);

function getPattern() {
return ':.*\\sPRIVMSG\\s[^ ]+\\s:!QUIT';
}

function patternMatch(matcher) {
robot.setStayConnected(false);
}

La regex ne capture rien ici car on ne gère pas de droits. Pour quelque chose de plus sécurisé, il faudrait capturer au moins le pseudonyme de la personne. La fonction appelée utilisera la méthode setStayConnected avec false en paramètre, ce qui aura pour effet de stopper la méthode run du robot.

join.js

Afin de rendre notre robot un minimum sociable, ce plugin aura pour tâche de le faire se présenter lorsqu'il rejoint un canal et de souhaiter la bienvenue aux nouveaux arrivants. Pour cela, il suffira de capturer les messages de type JOIN provenant du serveur, qui sont envoyés quand une personne rejoint un canal, ou quand le bot lui même le fait. Le message est du type ":nick!~ident@hostname.fr JOIN :#channel". Il suffit alors de comparer "nick" avec le propre pseudonyme du robot. S'il sont équivalents, c'est que c'est lui qui entre sur un canal, il doit donc se présenter. Si ce n'est pas le sien, alors il souhaite la bienvenue au nouvel arrivant. Il faudra donc capturer le pseudonyme et le nom du canal afin de s'en servir pour envoyer le message :

importClass(java.util.regex.Matcher);

function getPattern() {
    return ':([^!]+).*\\sJOIN\\s:([^ ]+)';
}

function patternMatch(matcher) {
    // Si c'est le robot qui JOIN
    if(matcher.group(1) == robot.getNickname()) {
        robot.write("PRIVMSG "+matcher.group(2)+" :Salut tout le monde, je suis "+matcher.group(1));
    }
    else { // si c'est un nouvel arrivant
        robot.write("PRIVMSG "+matcher.group(2)+" :Salut "+matcher.group(1));
    }
}

On voit donc la regex avec les deux captures (nick + canal). Ces informations sont ensuite utilisées pour le message envoyé.

patriote.js

Un plugin beaucoup moins utile, qui permettra simplement de montrer comment réagir à un texte particulier. Nous souhaitons ici que le bot montre qu'il est fier d'être français. A chaque fois que le mot France (peu importe la casse) sera écrit, il réagira. Le message reçu sera du type ":someone!~someident@some-host.com PRIVMSG #channel :Vive la France". Voyons le code du plugin :

importClass(java.util.regex.Matcher);

function getPattern() {
return '(?i):[^!]+.*\\sPRIVMSG\\s([^ ]+)\\s:.*france.*';
}

function patternMatch(matcher) {
robot.write("PRIVMSG "+matcher.group(1)+" :COCORICO !!!");
}

La regex indique que la recherche sera insensible à la casse. On capture simplement le nom du canal d'où le texte est envoyé pour pouvoir répondre.

Voilà pour quelques exemples de plugins. Le but ici est de montrer que presque tout est possible, mais que surtout ce genre de programme, modulable, auquel on peut ajouter des fonctionnalités, est facilement réalisable. Pour les plus courageux qui auront lu jusque ici (j'espère que number80 en fait partie !), n'hésitez pas à poser des questions dans les commentaires. Il n'est pas facile de synthétiser tout cela en un seul billet, il y a donc probablement des passages obscurs !

Fabien (eponyme)

Java : gérer facilement des plugins JavaScript

Fabien Nicoleau — Wed, 17 Nov 2010 00:11:00 +0100

Dans une application, il peut être parfois intéressant d'extraire une partie de l'intelligence afin de répondre à un besoins sépcifique. Un exemple courant est une application fournie à différents clients. Elle comporte un socle commun, puis les spécificités sont développées dans des plugins afin de ne pas avoir à toucher au code de l'application pour une demande particulière. L'autre intérêt est de pouvoir charger dans une application des fonctionnalités supplémentaires, permettant de réduire le poids de l'application en retirant des fonctionnalités inutilisées. Le fait d'avoir du code externe permet aussi d'en facilité les mises à jour.

En Java, il est possible de créer des plugins de différentes façons : avec des classes externes, chargées grâce à un ClassLoader, grâce à groovy, très populaire, ou encore jython, permettant d'exécuter du code Python depuis un programme Java. Il existe de nombreuses autres solutions, comme celle d'utiliser le moteur JavaScript de la fondation Mozilla : Rhino. Sa particularité est qu'il est fourni par défaut avec Java depuis la version 6.

En ayant eu besoin pour un projet, et ayant trouvé peu d'aide en français, je propose ici quelques exemples très basiques afin de mettre en place un système de plugins JavaScript avec Java. 90% de l'aide dont j'ai eu besoin a été trouvée sur cette page de documentation. Je reprends donc ici quelques exemples, commentés, afin de comprendre le principe et d'imaginer les possibilités qu'offre Rhino. N'hésitez pas à poser des questions dans les commentaires si vous avez besoins de précisions.

Tout d'abord, je vous indique ici les import dont vous aurez besoin et qui seront à utiliser tout au long des exemples (mais pas utiles pour tous). Il ne seront pas réécris ensuite, pour plus de lisibilité :

import javax.script.Invocable;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import java.io.FileReader;

Toujours pour simplifier le code affiché, les exceptions ne seront pas gérées, mais renvoyées par le main. Il vous faut évidemment avoir quelques bases de Java et de JavaScript pour pouvoir suivre ces exemples. Dans chacun d'eux, j'utiliserai des fonctions JavaScript. Si vous préférez utiliser du code orienté objet, il vous sera facile de l'adapter grâce aux exemples de la page Oracle citée en préambule.

Enfin, pour chaque exemple, je n'afficherai que la fonction main, qu'il faudra évidemment que vous incluiez dans une classe pour que le tout fonctionne, cependant les sources de chaque exemples sont disponibles en annexe de ce billet.

Exemple 1 : un simple affichage

Pour le premier essai, nous allons exécuter une simple ligne de code JavaScript dans du code Java :

public static void main(String[] args) throws Exception {
     ScriptEngineManager manager = new ScriptEngineManager();
     ScriptEngine engine = manager.getEngineByName("JavaScript");
     engine.eval("println('Mon premier script !');");
}

Rien de plus ! C'est en fait assez simple. Nous commençons par instancier un ScriptEngineManager qui nous permettra de charger le moteur de script souhaité. Nous l'utilisons sur la deuxième ligne : nous chargeons le moteur JavaScript. Aucune installation de bibliothèque nécessaire, car ce moteur est fourni avec Java 6 ! Ces deux premières lignes seront utilisées dans tous nos exemples. Nous terminons en demandant à notre moteur d'évaluer une ligne de code, ici l'affichage du texte "Mon premier script !".

Après compilation et exécution, la ligne s'affiche bien. Rien de transcendant ici, mais nous voyons que nous allons facilement pouvoir exécuter du code JavaScript.

Exemple 2 : interagir avec un script externe

Dans l'optique d'utiliser un système de plugins, il nous faut d'abord pouvoir sortir le code JavaScript du code Java, et le placer dans un fichier externe. De plus il nous faut pouvoir appeler une fonction en lui passant des paramètres, puis pouvoir récupérer le résultat obtenu.

Pour illustrer l'exemple, nous allons imaginer un programme Java qui passe à une fonction nommée compute() deux chiffres qu'elle traitera. Le code Java récupèrera le résultat du traitement effectué par compute() et l'affichera. Enfin, nous allons créer deux plugins JavaScript qui implémenteront tous les deux la fonction compute(). L'un fera une addition (plus.js) des deux chiffres donnés, l'autre une soustraction (moins.js). On commence par le code Java :

Comme dans le premier exemple, nous récupérons le moteur JavaScript. Ensuite plutôt que directement évaluer du code, nous passons un fichier à la fonction eval(), qui contiendra notre code JavaScript. Nous commençons ici par plus.js, qui fera une addition. Vous pourrez ensuite utiliser moins.js. Enfin, nous invoquons la fonction compute() et lui passons deux arguments (3 et 2). Nous récupérons le résultat du traitement, qui est un Object, et qui contiendra ici un chiffre (un Double à vrai dire), nous l'affichons directement.

Voici le contenu de plus.js :

function compute(a,b) {
return a+b;
}

Celui de moin.js :

function compute(a,b) {
return a-b;
}

Aucun commentaire nécessaire ! Exécutez le programme avec plus.js, puis moins.js, les résultats seront 5.0 puis 1.0.

Nous voyons ici que nous pouvons très facilement avoir du code Java qui exécute une fonction dont il ne connait pas le contenu. Il en récupère le résultat sous forme d'un objet et peut le traiter. D'un autre coté, nous avons des fichiers contenant du code JavaScript qui traitent de façon différente deux arguments identiques, et renvoient le résultat. Dans une application gérant des plugins, il suffit alors que le nom du fichier JavaScript soit une variable, ou provienne d'un choix de l'utilisateur, et le tour est joué ! Attention tout de même, pour un système robuste, il est important de gérer les exceptions afin de réagir aux problèmes qui pourraient survenir.

Exemple 3 : Exporter des variables dans le script externe

Lorsque l'on mets en place un système de plugins, on souhaite que ces derniers puissent avoir accès aux informations de l'application, souvent par l'intermédiaire d'un noyau depuis lequel on accède à des variables. De cette manière le plugin agit de façon directe avec l'application, en consultant des informations, et en les mettant à jour. Nous allons dans cet exemple voir qu'il est tout à fait possible de faire cela avec Java et Rhino. Nous allons créer une classe Afficheur contenant la méthode affiche() qui se contente d'afficher dans la console une ligne de texte. Ensuite, nous allons instancier un objet de cette classe et l'exporter dans notre script JavaScript. Ce dernier utilisera dans son code l'objet exporté et appellera la méthode affiche() :

private static class Afficheur {
   public void affiche() {
       System.out.println("J'affiche !");
    }
}
public static void main(String[] args) throws Exception {
    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine engine = manager.getEngineByName("JavaScript");
    engine.eval(new FileReader("afficheur.js"));
    Afficheur aff = new Afficheur();
    engine.put("monAfficheur",aff);
    Invocable inv = (Invocable) engine;
    inv.invokeFunction("affiche");
}

On voit ici qu'une fois l'objet Afficheur instancié, on l'exporte dans le script grace à la méthode put(). On indique que le nom de variable par laquelle l'objet sera accessible dans le script sera "monAfficheur". Enfin on appelle la fonction affiche() implémentée dans le script afficheur.js dont voici le contenu :

function affiche() {
monAfficheur.affiche();
}

La fonction affiche() utilise donc la variable monAfficheur disponnible grace à l'export fait depuis le code Java, et appelle la méthode affiche(). Voilà notre liaison réalisée ! Depuis notre code JavaScript, nous accédons à un objet de notre application Java et pouvons l'utiliser. Ici nous ne réalisons qu'un simple affichage, mais tout est possible. Notez qu'il est possible de définir différent scope lors de l'export des variables permettant ainsi de leur donner des valeurs différentes selon le contexte utilisé lors de l'évaluation. Plus de renseignement dans la documentation.

Exemple 4 : Implémenter une interface

Nous progressons dans les fonctionnalités proposées pour réaliser une gestion de plugins. Mais il est possible d'aller plus loin, et de définir plus précisément les fonctionnalités offertes par les plugins. Pour cela, nous pouvons définir en Java une interface, et l'implémenter depuis un plugin. Une fois le code du plugin évalué, nous appelons une méthode depuis le code Java, dont l'implémentation a été réalisée depuis le code JavaScript ! Il devient alors possible de définir proprement en Java les méthodes qui seront à implémenter par les plugins, sans en connaitre le traitement évidemment, et d'utiliser ensuite dans le code des objets instanciant cette interface. Mieux que du blabla, le code :

private interface Afficheur2 {
    void affiche2();
}
public static void main(String[] args) throws Exception {
    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine engine = manager.getEngineByName("JavaScript");
    engine.eval("function affiche2() { println('affiche (2)'); }");
    Invocable inv = (Invocable) engine;
    Afficheur2 aff = inv.getInterface(Afficheur2.class);
    aff.affiche2();
}

Pour l'exemple, je n'utilise pas de fichier externe, mais directement une ligne de code JavaScript. Ce code implémente la méthode affiche2() de l'interface Afficheur2 en faisant un simple affichage de ligne. Nous créons un objet de type Afficheur2 puis récupérons l'instanciation de l'interface grâce à la méthode getInterface().

Enfin, nous utilisons ce nouvel objet et appelons la méthode affiche2() qui effectuera ce qui a été défini dans le code JavaScript, c'est à dire afficher une ligne de texte.

Nous voyons ici qu'il nous est donc possible d'écrire du code générique et de l'utiliser. C'est grâce aux plugins utilisés que instanciation est faite et nous pouvons ainsi pour un même code Java obtenir des comportement totalement différents.

Exemple 5 : Utilisation des classes Java depuis le code JavaScript

Comme dernier exemple et pour montrer toute la puissance de Rhino, nous créons un code Java qui se contentera d'évaluer un script :

Le script en revanche est particulier, car il importe directement des classes Java et utilise les objets instanciés. Le script frame.js va créer une JFrame et l'afficher. Il affichera aussi le titre de la fenêtre, qu'il récupère directement depuis la propriété de la JFrame :

importClass(javax.swing.JFrame);
importClass(java.awt.Dimension);

var frame = new JFrame("hello");
frame.setSize(new Dimension(250,250));
frame.setVisible(true);
println(frame.title);

Exécutez le programme, une fenêtre apparait !

Voilà pour cette petite initiation au scripting avec Java et son application avec l'utilisation de plugins. Il y aurait surement beaucoup plus à dire, mais vous disposez maintenant d'une base pour débuter, et de l'alliance du Java et du JavaScript pour vos applications ! Ce sujet aura aussi été pour moi l'occasion de reprendre la plume sur ce blog, chose qui n'avait pas été faite depuis trop longtemps !

Fabien (eponyme)

5 ans (et quelques mois) de fedora-fr.org !

Fabien Nicoleau — Mon, 06 Sep 2010 23:54:00 +0200

Comme tous les ans depuis quelques années maintenant, je profite de mon "anniversaire" d'inscription sur le site fedora-fr.org (datant du 07/07/2005) pour faire un petit bilan de mon activité autour de fedora. En relisant les billets précédents, je m'inquiete un peu de voir que ça diminue de plus en plus, mais maintenant que j'ai de nouveau ma connexion, et la motivation après une longue pause, plus d'excuses ! Voilà donc un petit tour d'horizon, à aujourd'hui :

Le forum

Je suis un lecteur assidu (et modérateur aussi parfois!), un peu moins contributeur. Je reste fidèle et continue la lecture quotidienne des sujets. J'ai aujourd'hui 2185 messages au compteur.

Le wiki

Comme l'an dernier, honte à moi ... Je n'ai toujours que deux articles à mon actif :

Les cannaux IRC

J'y suis présent tous les jours, c'est d'ailleurs le meilleur moyen de me contacter. Présent pour causer .. aider.. C'est par ce biais que je reste le plus au sein de la communauté.

Packaging

J'ai au cours de cette année ajouté trois paquets à ma liste pour les dépôts de fedora :

monkeystudio : un EDI multi-plateformes dédié à Qt4
quvi : une bibliothèque permettant de récupérer les informations des vidéos disponnibles sur de nombreux sites de partages de vidéos (youtube & co) utilisée par cclive
xcftools : paquet fournissant quelques utilitaires permettant de récupérer des informations sur les fichiers au format .xcf

Comme l'an dernier, c'est de ce coté que je contribue le plus, et les choses devraient continuer dans ce sens, car j'ai quelques paquets sur le feu que je proposerai certainement cette année.

Même s'il n'y a pas de rapport direct, ma minuscule contribution à xchat a été prise en compte dans la dernière release, permettant enfin de rendre le temps des notifications configurable.

Mon blog

Principal reflet de mon activité, il a logiquement été peu mis à jour. J'ai cependant cette année passé la barre des 100 billets. C'est à cette occasion que j'ai mis en place un nouveau thème, sur lequel je devrais encore travailler. En tout cas dans l'état actuel il me convient bien. Le blog à donc aujourd'hui 103 billets, et 271 commentaires.

Voila pour cette année, peu de choses à dire, mais je suis aujourd'hui de nouveau disponnible pour faire en sorte d'avoir de nouveaux chapitres à ajouter l'an prochain ;)

Fabien (eponyme)

Petite absence ...

Fabien Nicoleau — Thu, 01 Jul 2010 15:15:00 +0200

C'est l'été, et les vacances arrivent (enfin!). Je profite de ces quelques semaines pour déménager, et donc déplacer mon abonnement ADSL. La mauvaise nouvelle est qu'avec quelques difficultés rencontrées, je vais avoir plus d'un mois d'interruption, la bonne en revanche est que je reviendrais avec un abonnement totalement dégroupé (merci SFR!).

Du coup plus de billets, plus de forums, et plus de packages pendants quelques semaines.

A bientôt !

Fabien (eponyme)

XChat 2.8.8 est sorti, la hache de guerre avec les balloons est enterrée !

Fabien Nicoleau — Sun, 06 Jun 2010 22:19:00 +0200

Il y a quelques jours, une nouvelle version du client IRC XChat est sortie. Cette version intègre le patch que j'avais soumis il y a quelques temps, afin de régler le problème de temps d'apparition bien trop long des notifications. C'est donc une petite satisfaction personnelle de voir dans cette release quelques lignes de codes que j'avais proposées, même si le mérite en revient plutôt à Remi car je m'étais inspiré de son patch plutôt que de mon original pour en proposer un nouveau.

Avec la version 2.8.8, il est donc maintenant possible de régler le temps d'apparition des notifications par la commande

/set input_balloon_time

ou bien sûr directement dans le fichier de configuration. C'est un soulagement pour moi car je n'aurais plus à reconstruire une version du paquet avec le patch pour ne plus avoir à hurler lorsque je joue à un jeu et que des notifications viennent manger une partie de l'écran pendant 20 secondes !

La version est déjà packagée pour fedora, et une demande d'envoi vers le dépôt stable a déjà été faite, elle apparaitra donc bientôt dans les mises à jour !

Fabien (eponyme)