Veille technologique & Virtualisation

La veille technologique impose parfois d'installer des outils, des frameworks et des logiciels. Il arrive qu'un de ces éléments nous amènent à modifier en profondeur notre système (changement de JDK, montée de version Maven, etc...) et il serait agréable de pouvoir le faire sans causer de dégâts sur l'environnement stable que nous avons mis en place depuis plusieurs semaines / mois / années.

Je tente une nouvelle expérience en virtualisant mes différents environnements de tests et je vais tenter de vous faire partager ma façon de faire et peut-être de vous donner envie de faire de même.

Ce premier billet a pour but de poser les bases de ce que j'appelle le Socle Commun. Le Socle Commun est l'image de la machine virtuelle qui servira de point de départ à chaque fois qu'on voudra tester une nouveauté sans pour autant abimer son propre environnement.

La machine Hôte

Mon ordinateur personnel est un portable Dell XPS M1730 Core 2 Duo 2GHz avec 2 Go de RAM. Il date d'un peu plus de 3 ans mais sa robustesse à toute épreuve ne me pousse pas à changer, pour le moment.

J'utilise une distribution Ubuntu 10.4 Lucid Lynx et les machines virtuelles seront installées et exécutées via VirtualBox OSE. J'avais l'habitude d'utiliser les produits VMWare mais après quelques soucis (Kernel Panic Not Syncing, incompatibilité VMWare Server & Firefox 3.6, ...) j'ai décidé de changer. 

 & 

Le Socle Commun 

Le Socle Commun est le système de base pour instancier un nouvel environnement. C'est cette machine virtuelle qui me permettra de gagner du temps lors de mes expérimentations. J'ai la garantie qu'en quelques minutes j'ai un environnement GNU/Linux accompagné d'un JDK prêt à l'emploi!

Système d'exploitation : Ubuntu Server 10.4

Version du JDK : 1.6

Client SVN : subversion

Serveur SSH : openssh-server

Serveur Web : Apache2

Serveur de bases de données : MySQL

Interface de gestion de bases de données : PhpMyAdmin

Le but du Socle Commun est de fournir un maximum de services sans alourdir le système. L'avantage de virtualiser ce socle est de pouvoir le dupliquer et de le spécialiser pour mettre en place par exemple une plateforme d'intégration continue, un nouveau CMS, un nouveau serveur d'application, ...

Le Socle Commun se doit d'évoluer, il doit être maintenu (mise à jour des packages Ubuntu) et enrichi (logiciels, clients, scripts, ...) lorsque les besoins communs changent.

En ce qui concerne la configuration de la machine virtuelle, j'ai prévu 15Go pour le disque dur en allocation dynamique, et 256 Mo de RAM. Ces paramètres peuvent bien entendus être modifiés par la suite pour les besoins de vos prochaines instances. 

Mise en place

La mise en place du Socle Commun est rapide, le plus long étant finalement de télécharger l'iso d'Ubuntu Server et son installation. D'ailleurs, lors de l'installation de celui-ci on nous propose des packages de bases (LAMP, Samba, serveur dns, ...). Cochez ce dont vous pensez avoir besoin dans votre Socle Commun.

Je ne reviens pas sur les détails de l'installation d'Ubuntu Server, vous êtes libres de choisir n'importe quel environnement (GNU/Linux, UNIX, Windows, ...). Sachez juste que j'ai créé un utilisateur unique dont le nom est 'user' et le mot de passe est 'password'. C'est pratique si vous souhaitez partager cette image avec d'autre, le compte est "générique" out-of-the-box.

Après une rapide installation, il ne me reste pas grand chose à faire :

Installation du JDK :

• téléchargement sur le site d'Oracle : http://java.sun.com/javase/downloads/index.jsp
• répertoire d'installation :  /opt/jdk1.6.0_20
• édition du fichier .bashrc de l'utilisateur 'user' pour ajouter la variable d'environnement JAVA_HOME et ajouter $JAVA_HOME/bin à la variable d'environnement PATH.

Installation de PhpMyAdmin :

• sudo apt-get install phpmyadmin

Installation de subversion

• sudo apt-get install subversion

Passage en IP Fixe

• Modification du fichier /etc/network/interfaces

iface eth0 inet static

address 192.168.0.xxx

netmask 255.255.255.0

gateway 192.168.0.254

auto eth0

Et c'est tout. L'environnement est prêt.

Et maintenant ?

Le socle commun en lui-même ne sert à rien, mais dans un prochain billet vous verrez comment monter une plateforme d'intégration continue très rapidement en partant de l'image que nous venons de créer.

En attendant, vous pouvez commencer à monter votre propre socle commun, adapté à vos besoins!


Vous pouviez mettre de côté les fichiers générés par la création de la machine virtuelle du socle commun. On ne sait jamais, une machine virtuelle est si vite perdue, et ce serait dommage de devoir tout recommencer alors que le but est justement de gagner du temps.

Références

Ubuntu Serveur : http://www.ubuntu.com/products/whatisubuntu/serveredition

Virtual Box : http://www.virtualbox.org/

A la découverte de Grails

Quelle surprise de découvrir enfin ce qui se cache derrière Grails. Depuis quelques temps, j'entends parler de Ruby, de Ruby On Rails (RoR), de Groovy et de Grails ... C'est vrai qu'en tant que développeur Java je reste très attaché à mon langage de prédilection et il est assez difficile de me dire qu'il peut exister quelque chose de mieux ailleurs, et pire, que je doive réapprendre une autre syntaxe!

Comment organiser sa veille technologique?

Dans notre métier, il est important de se tenir un peu au courant de ce qui se passe. Dans mon cas, j'essaie de gratter des informations concernant Java, J2EE/JEE5 et tout ce qui peut graviter autour de la programmation et du développement en général.

Sur le blog Chaotic Java on peut trouver une réflexion intéressante sur comment gérer l'accès aux collections d'une classe.

Deux méthodes sont proposées, la première est l'approche "paranoïaque" dans laquelle on ne met pas à disposition les collections utilisées par la classe. On propose juste des méthodes comme add/remove/get avec une gestion des erreurs pour avoir la main sur l'utilisation de la collection.

A la recherche du singleton parfait

Le sujet qui passionne! Quelle est la version ultime, l'implémentation parfaite du pattern Singleton en Java?

Une page intéressante est disponible ici. Les différents protagonistes discutent des avantages & inconvénients des différents façons de l'implémenter.

Pour le coup, j'aime bien cette implémentation :

public final class Singleton {

private static final class SingletonHolder {
static final Singleton singleton = new Singleton();
}

private Singleton() {}

public static Singleton getInstance() {
return SingletonHolder.singleton;
}
}

Remarquez que jamais je n'avais vu le mot-clé static associé à une classe en Java! On en apprend tous les jours.

Spring Batch

Spring Batch vient de sortir! Alors honnêtement je ne savais même pas que ça allait sortir mais comme les batchs m'intéressent je vais en parler un minimum.

Etant donné que dans ma précédente mission, l'équipe Architecture était en train de développer son propre framework de batchs, je me suis dit qu'il serait intéressant de regarder de plus près ce que propose Spring Batch.

Le site officiel c'est ici et la documentation que je suis en train de lire c'est là.
Les instructions pour se lancer!

Schéma de l'architecture

J'espère en faire un petit résumé ou pourquoi pas un tutoriel pour tester la techno.

JMX & Tests unitaires

Voici un podcast sur l'utilisation conjointe de JMX et des tests unitaires lors de la mise en place d'une démarche Test-Driven Development (TDD).

Le fichier audio est disponible ici.

La présentation PDF est disponible ici.

Voici la source de l'article.

Dans le cadre de mon travail, je serai peut-être confronté à utiliser JMX et c'est vrai que je ne m'étais pas posé la question de la manière de tester ...

Qui a déjà testé JMX et quelles en sont vos conclusions ?