Magic Box

• Vous est-il déjà arrivé de vouloir tester votre application sur votre environnement de développement et de passer plus de temps que nécessaire à installer des serveur de données, une version spécifique de tomcat ? 
• Vous est-il déjà arrivé de dépendre d'un service tiers fourni par ne autre équipe et de vous retrouver coincé parce que leur service est arrếté ou n'utilise plus la version que vous deviez utiliser ?
• Vous est-il déjà arrivé de rencontrer des problèmes en qualif/prod parce que les environnements de dev/test/prod ne tourne pas sous le même OS ou des versions de serveur Web différentes?

Non ?!? Vous avez bien de la chance...

Et si il existait une boite magique qui contient tous les services dont vous avez besoin... ?

Vous ne me croyez pas! Mais pourtant il y a ... Vagrant ...

image récupérée sur le site vagrant : http://vagrantup.com/

Vagrant

Vagrant est un outil de développement qui permet de gérer des machines virtuelles ainsi que leurs configurations à l'aide de VirtualBox et Puppet/Chef.

Le principe est simple :

1. Vous disposez d'un ensemble de machines virtuelles (boxes) dans un repository accessible via HTTP
2. Vous téléchargez une de ces "boxes" en utilisant la commande vagrant box add
3. Vous initialisez une instance de cette machine (création d'un fichier de configuration Vagrantfile dans votre dossier de travail)
4. vous la démarrez (au premier démarrage, la machine virtuelle est créée par virtualbox et si il y a des fichiers de configuration puppet/chef dans votre box, ils sont exécutés)
5. Votre machine virtuelles est prête.

Voilà c'est aussi simple que ça d'un point devue utilisateur. Le plus long dans l'histoire c'est le téléchargement de la box depuis votre repostiry, un fois téléchargée vous pouvez créer autant d'instances de cette box que vous le souhaitez.

Les boxes sont stockées dans un répertoire .vagrant.d de votre home directory. Si vous voulez changer cet emplacement, il suffit de mettre à jour la variable d'environnement VAGRANT_HOME avec le chemin absolu du répertoire que vous souhaitez utiliser.

Grâce à ces "boites" en quelques secondes (ou minutes en fonction de votre débit) vous pouvez disposez d'une VM avec une configuration identique à votre environnement de production pour tester votre application... merveilleux...

En plus la documentation est très bien faite, je n'ai eu aucun mal à trouver les infos que je cherchais à l'exception du changement de repository local (cf. ci-dessus).

Les fichiers de configuration 

Les fichiers de configuration vont permettre de:

• configurer la redirection de port entre votre machine et la VM créée à partir de la box.
• redéfinir le chemin vers des dossiers créés par vagrant
• configurer les paramètres de connexions via ssh
• préciser la manière dont la VM sera provisionée (puppet/chef)
• etc...
  

La liste des paramètres de configuration est disponible ici.
Lorsque l'on utilise vagrant, il existe 4 fichiers de configuration présentés ci-dessous dans l'ordre de chargement :

1. Un fichier contenant la configuration par défaut dans le dossier "gems". (Dans mon cas il est à cet endroit /opt/vagrant/embedded/gems/gems/vagrant-1.0.3/config/default.rb) Ce fichier ne doit pas être édité, il contient :
• la configuration ssh pour accéder à la VM avec le user vagrant
• les informations de montage du dossier partagé. Chaque Box a un dossier "/vagrant" partagé avec le dossier dans lequel la commande "vagrant init" a été exécutée.
2.  Le second fichier (optionnel) est contenu dans la box, il s'agit d'un fichier qui a été ajouté à l'archive avec l'option --vagrantfile de la commande "vagrant package", il est donc utilisé pour chaque machine virtuelle créée à partir de cette box. Il peut contenir par exemple les instructions de provisioning (via puppet/chef)
3. Le troisième fichier (optionnel) est contenu dans le dossier VAGRANT_HOME (par défaut "~/.vagrant.d").
4. Pour finir, le dernier fichier à être chargé est celui créé à l'initialisation de la VM, il est présent dans le dossier à partir duquel la command "vagrant init" a été exéctée.

Commandes

Voici la liste des commandes disponibles (à prefixer par la command principale "vagrant" ):

• box : pour gérer les boxes dans le repository local (add/remove/list/repackage cette derniere est utile si on change la configuration de la box).
• destroy : suppression de la VM dans VirtualBox, la box est toujours présente dans votre home vagrant mais l'instance de la VM est définitivement supprimée
• gem : permet de télécharger des plugins vagrant
• halt : arrête la vm
• init : crée un fichier de configuration dans un le dossier courant, il faut toujours être dans ce dossier pour pouvoir manipuler une instance de VM. Il ne peut y avoir qu'un fichier Vagrantfile par dossier.
• package : crée une box à partir d'une instance de VM dans VirtualBox. (Peu utile pour un utilisateur lambda)
• provision : execute les mises à jour de configuration déclarées dans les conf puppet/chef si vous voulez les executer alors que votre VM est up, sinon ils sont automatiquement lancés au démarrage de la VM.
• reload : redémarre la VM
• resume : restore l'activité de la VM après un suspend
• ssh : connexion à la VM 
• status : état de la VM
• suspend : mémorise l'état de la VM et la suspend (resume  restore la VM)
• up : démarre la VM et la crée dans virtualbox si elle n'exite pas

VirtualBox attention aux versions...

Pour que vagrant fonctionne sans problème, il faut que les VM utilisent les "VirtualBox addition guest". Seulement voilà, si votre box a été crée avec une version VirtualBox différente de la votre, il se peut que vous ayez un message d'alerte au démarrage de la VM.
Ce message vous prévient qu'il est possible que certaines fonctionnalités comme le partage de fichier ou la redirection de port ne fonctionnent pas trés bien en raison de cette différence de version... pas génial quoi.

[eric@pcfixe test]$ vagrant init lucid32
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

[eric@pcfixe test]$ vagrant up
[default] The guest additions on this VM do not match the install version of
VirtualBox! This may cause things such as forwarded ports, shared
folders, and more to not work properly. If any of those things fail on
this machine, please update the guest additions and repackage the
box.

Guest Additions Version: 4.1.16
VirtualBox Version: 4.1.20

Pour résoudre ce problème, il faut vous connecter à votre VM en ssh et mettre à jour les "Guest Addition" en fonction de l'OS qui tourne dans la VM comme indiqué sur cette page du site VirtualBox.

[eric@pcfixe test]$ vagrant ssh
    Linux lucid32 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:13:04 UTC 2012 i686 GNU/Linux
    Ubuntu 10.04.4 LTS

    Welcome to Ubuntu!
     * Documentation:  https://help.ubuntu.com/
    New release 'precise' available.
    Run 'do-release-upgrade' to upgrade to it.

    Welcome to your Vagrant-built virtual machine.
    Last login: Thu Jun  7 01:56:53 2012 from 10.0.2.2
    Last login: Thu Jun  7 01:56:53 2012 from 10.0.2.2
    vagrant@lucid32:~$
    vagrant@lucid32:~$ sudo apt-get update

    vagrant@lucid32:~$ sudo apt-get upgrade

    vagrant@lucid32:~$ sudo apt-get install dkms

    vagrant@lucid32:~$ sudo reboot

[eric@pcfixe test]$ vagrant ssh

    vagrant@lucid32:~$ sudo mkdir /media/cdrom

    vagrant@lucid32:~$ sudo mount /dev/cdrom /media/cdrom

    vagrant@lucid32:~$ bash /media/cdrom/VBoxLinuxAdditions.run

[eric@pcfixe test]$ vagrant reload

Normalement, l'erreur a disparue.

Ensuite, vous pouvez repackager votre VM dans une box pour pouvoir la réinstaller dans votre repository local à l'aide de la command package

[eric@pcfixe test]$ vagrant package --base <virtualbox_vm_name> --output lucid32AddGuest.box

Voilà, c'est tout pour aujourd'hui.

Prochainement, je ferais un tuto sur la création d'une box "from scratch" avec une config puppet ou chef pour installer quelques services...

Du JSON pour les manipuler tous...

"Mais de quoi tu parles?" me demanderez vous?

Des logs...

Les logs ont toujours eu une grande importance pour nos applications. Une application qui n'informe pas correctement l'utilisateur n'est pas exploitable. Cela est d'autant plus vrai qu'avec des architectures de plus en plus complexes passer 30 minutes à comprendre un problème parce qu'une ligne de log est mal fichue n'est pas acceptable...

Mais JSON est là pour nous aider...

Voici à quoi ressemble une ligne de logs aujourd'hui:

Aug 11, 2012 10:43:47 AM INFO myapp.business.SimpleLogger doSomething with "arg1 value STR"... 
Aug 11, 2012 10:43:47 AM WARN myapp.business.SimpleLogger this is a warning

Quand on est un pro du perl, du python ou autre, on arrive sans trop de problèmes à extraire des info de ce type de log. Mais bien souvent, le format change d'une application à l'autre et il faut presque autant de scripts de traitement que d'applications...


C'est là de le format JSON intervient :

1. toutes les données sont structurées de la même manière (clé - valeur).
2. c'est moins lourd que du XML :)
3. il existe des outils pour manipuler ce format dans tous les langages (ou presque)
4. il est plus simple d'exploiter du JSON que du "full text"

Voici ce que peut donner les deux lignes de logs précédentes en JSON :

{"date" : "Aug 11, 2012 10:43:47 AM", "level" : "INFO", "origin" : "myapp.business.SimpleLogger", "args" : { "arg1 Value STR", {..arg2 as obj..}} , "message" : "doSomething"}
{"date" : "Aug 11, 2012 10:43:45 AM", "level" : "WARN", "origin" : "myapp.business.SimpleLogger", "args" : { "arg1 Value STR", {..arg2 as obj..}} , "message" : "warning details"}

Je ne prétends pas que cet exemple contient toutes les informations nécessaires, mais je trouve qu'il est quand même plus simple d'identifier les informations dans ces logs (sous réserve de ne pas avoir de structure trop complexe...):
- quel élément a produit la ligne ? (clé : "origin")
- quels sont les arguments de cette méthode ? (clé : "args" )

A l'heure des systèmes fortement distribués, avoir une concentration des logs pour pouvoir en extraire des informations consolidées est une chose importante. La production de logs dans un format comme JSON est la première étape à franchir.

Les outils existent déjà à nous de nous en servir...

• Une extension pour logback 
• Fluentd - un démon de collecte 
• Apache Flume, un collecteur basé sur Hadoop que l'on peut coupler avec Apache Hive pour exploiter les données...

Peut-on faire du JavaScript proprement ?

C'est à cette question que Julien Jakubowski a essayé de répondre hier lors de la session Ch'ti JUG.

Je n'en fais pas mystère, le développement Web, c'est pas mon truc mais bon difficile d'y couper aujourd'hui... et qui dit développement Web, dit JavaScript...

Je n'en ai quasiment jamais fait au cours de ma vie professionnelle mais je dois en faire aujourd'hui... et autant dire que la présentation de Julien va m'aider dans ma tâche.

Tout d'abord quelques liens :

• Eloquent JavaScrip une introduction à JavaScript disponible en ligne. 
• JavaScript Garden un guide pour éviter les erreurs de débutant en JS.

Je n'ai pas encore lu "Eloquent JavaScript" mais j'ai parcouru "JavaScript Garden",  on y trouve effectivement des conseils bien sympas comme par exemple la simulation "d'attributs" private.

function Counter(start) {
    var count = start;
    return {
        increment: function() {
            count++;
        },

        get: function() {
            return count;
        }
    }
}
var foo = Counter(4);
foo.increment();
foo.get(); // 5

C'est peut-être évident pour quelqu'un qui connais bien JavaScript mais pour moi ça ne l'était pas...

Bon maintenant que l'on a des guides pour structurer un minimum notre code JavaScript, quelques outils :

• JQuery que l'on ne présente plus
• mustache un outil de templating 
• JSLint un outil de qualité de code qui vous insultera si par exemple vous n'utilisez pas l'opérateur '===' pour vos testes d'égalité
• Jasmine qui va vous permettre de tester votre JavaScript un comme en JUnit

Mais alors, le JavaScript ça n'est pas sale ? Bah, disons qu'avec de la rigueur, du code modulaire, des outils pour tester et vérifier la qualité de ce code, on peut faire quelque chose de sympa. Mais bon, ça reste du JavaScript qui, comme le montre cette video, n'est pas toujours trivial à comprendre...

Voilà, en espérant que ces quelques liens vous aiderons...
Et Merci à Julien Jakubowski pour sa présentation!
 

7 Questions à se poser avant de se lancer...

Voici un article sympathique intitulé : "What Makes a Good Semantic Web Application?"

On y trouve notamment une liste de 7 questions qui nous aident à déterminer si les technos du web sémantique sont nos amis pour notre future application...

Les voici :

• Does your use case involve documents and other forms of unstructured data?
• Do you expect to add more kinds of data in the future?
• Do you expect to add more views on the data in the future?
• Do you expect to expand your application to require more kinds of users in the future?
• Is the data scale less than petabytes?
• Is the transaction volume modest? (e.g., hundreds versus tens of thousands of users)
• Does your application require only modest numeric calculations?

Nous avons aussi quelques avertissements sur ce que ces technos ne sont pas (encore?) capable de faire, notamment le fait que les TripleStores actuel ne sont pas vraiment efficace pour des écritures massive.  Pour ma part je n'en connais qu'un seul (virtuoso) et sur cette question d'écriture massive voici ce que je peux en dire :

• si les URI ne sont pas trop aléatoire (http://home/resource[X] avec X une suite croissante d'entier), il n'y a pas de problème pour les insertions en masse.
• si les URI sont trés aléatoire (http://home/resource[X] avec X une valeur aléaoire comme un UUID), il y a rapidement des problèmes au moment du checkpoint de la base et ceci même si elle contient peu de données.  Le checkpoint passe définitivement toutes les informations du journal dans la base, ce qui cause probablement un rééquilibrage plus complex de l'arbre d'index dans le cas de données aléatoires.  Par problème, j'entends des temps de chekpoint supérieur à 5minutes pendant lesquelles la quasi totalité des requêtes échouent.
• pour finir, jusqu'à la version 6.1.3, virtuoso ne supportait pas très bien les transactions distribuées (JTA ou XA transaction). Elles avaient pour facheuse tendance à affoler le serveur (CPU qui plafonne à 100% et qui ne redescent pas avec parfois quelques crash virtuoso). Je ne sais pas ce que donne la gestion de ces transactions pour les versions supérieures (la 6.1.5 est sortie récemment).

Pour ce qui est de la quantité de données gérée par les TripleStore,
voici un lien qui pourra vous apporter des idées. On peut y lire que Virtuoso peut aller jusqu'à 15 milliard de triples en mode cluster qui n'est pas, selon moi, disponible dans la version opensource. Une version "simple" d'un virtuoso opensource edition 6.1.3 dépasse sans problème le milliard de triples avec des temps de réponses en sélection qui se comptent en ms avec les Bitmap Index appropriés (soit une table de 500 millions d'éléments en SGBDR).
On peut y voir d'autres triplestores dont :

• Mulgara qui ne gére que 500 million de triples (une table SGBDR de 150-200 million de lignes). Cela me paraît peu comparé à Virtuoso mais on m'en a dit du bien récemment... 
• 4Store qui gére 15 milliards de triples en mode cluster qui est disponible de base dans cet outil sous licence GPLv3.

J'èspère avoir la possiblité de tester ces deux alternative à virtuoso...
En espérant que ces quelques informations vous seront utiles...

Microformat, RDFa & Microdata... Comment faire son choix ?

C'est à cette question que Jeni Tennison a essayé de répondre dans ce "HTML data guide"actuellement à l'état de Draft. Nous y trouvons quelques bonnes pratiques ainsi que des comparatifs sur ce que peut ou non réaliser tel ou tel format.

ex :

• RDFa supporte mieux le multi-langage comparé au Microdata.
• RDFa facilite l'utilisation de plusieurs vocabulaires
• ...

A lire donc ou au moins se rappeler de son existence pour pouvoir y jeter un oeil le moment voulu...

Reader PDF en Javascript

Je suis tombé par hasard sur PDF.js.

C'est un outil développé en JavaScript qui permet de visualiser des fichiers PDF en HTML 5. Le résultat est assez saisissant. 

J'aime l'idée de pouvoir fournir un reader sur un site sans que l'utilisateur soit obligé de télécharger un plugin.

Voici le lien de démo proposé par Andreas Gal sur son blog.


Voici le lien de l'article d'Andreas Gal : http://andreasgal.com/2011/06/15/pdf-js/

Et enfin, le repository github : https://github.com/mozilla/pdf.js

Bravo à ceux qui travaillent sur le sujet !