Romain

Cette utilisateur n'a partagé aucune information biographique


Article par Romain

LessCss et Eclipse

Less Css

Il y a quelques temps, pour un besoin personnel, j’ai utilisé l’excellent Twitter bootstrap. J’y reviendrais sans doute dans un prochain post, mais succinctement, il s’agit d’un bootstrap CSS, c’est-à-dire tout le nécessaire pour partir avec quelque chose de solide lorsque l’on démarre un site ou une application web.

Twitter bootstrap utilise (éventuellement) less. Je voulais faire un article à propos de less, mais Cédric Exbrayat l’a fait avant moi sur son blog. Il retrace parfaitement les principes de cette extension à CSS, je vous invite donc à le lire pour en savoir plus. Pour faire très court, less ajoute au CSS ce qui lui manque depuis toujours : le support de variables, de fonctions, d’imbrications de règles, etc. Le rêve pour tout développeur web qui se respecte !

Une question se pose alors : un fichier .less est un fichier .css enrichi. Mais quel est le niveau de support des IDE ? Regardons ça de plus près pour Eclipse (nous prendrons comme base la version 3.7).

More >

Jouons avec les Entités de Play!

J’avais évoqué il y a quelques temps déjà Play!, et j’avais même traduit le tutoriel officiel en français montrant les capacités de ce framework.

Ayant eu l’occasion de me remettre sur Play! ces derniers jours, je ne peux m’empêcher de vous faire partager le plaisir que j’ai eu à l’utiliser en vous parlant d’un aspect sympathique de ce framework : la gestion des entités.

More >

Calculer sa couverture de code par les tests d’intégration

Nous allons voir ici comment, grâce à Sonar, Maven et JaCoCo nous pouvons obtenir la couverture de code par des tests d’intégration.

More >

How to categorize JUnit tests with Maven

NB: This article is the english version of my previous article, written in french.

For some reasons, I wanted to categorize my JUnit tests, in order to run only a subset of them.
But this is not as simple as it seems…

More >

Catégoriser ses tests JUnit avec Maven

J’ai eu envie de « catégoriser » mes tests JUnit, et de pouvoir ne lancer que certains d’entre eux via Maven.
Ce qui semblait une tâche relativement simple s’est avérée être en réalité un chemin semé d’embuches…

Voici mon carnet de voyage…

More >

Première demi-journée Valtech TechDay

Valtech va organiser demain 21 octobre dans ses nouveaux locaux la première demi-journée technique pour ses consultants. Le programme est le suivant :

  • 13h30 – 14h20 : NoSQL, tour d’horizon par Claude Falguière et Grégory Paul
  • 14h30 – 15h05 : Migration top chrono d’une application JEE sur le Cloud Amazon par Fréderic Sauzet et Hervé Desaunois
  • 14h10 – 15h45 : Migration top chrono d’une application .NET sur le Cloud Azure par Lionel Molas et Cyril Aigoin
  • 16h00 – 17h30 : Ateliers de réflexion sur le thème de la mobilité
  • 17h50 – 19h50 : Coding Dojo Android, Windows Phone 7 et iPhone animés par Pascal Ognibene, Philippe Miossec et Sylvain Rousseau

Demain s’annonce donc être une journée passionnante et très instructive !

Suivez en direct mes tweets ainsi que ceux de @ValtechTechno.

Cours du soir – Git

Git

David Gageot (blog ; twitter) nous a fait l’honneur de revenir dans ses anciens locaux, chez nous à Valtech, afin de nous faire une présentation sur Git. Cette présentation, il l’avait déjà jouée à Vidal il y a quelques jours, et devait faire de nombreux heureux lors de prochains JUG (Ch’tiJUG, puis Paris JUG mi mai).


Nous étions une dizaine à écouter l’enthousiasme de David sur cet outil, qu’il pratique depuis presque 2 ans au sein de la socité dont il est le CTO, Algodeal.
Avant d’attaquer la présentation, un rapide tour de table est réalisé. Qui utilise quel outil pour gérer ses sources, et qui connait et utilise Git ? La plupart d’entre nous utilisons Subversion, et nous connaissions presque tous Git, sans pour autant l’avoir déjà utilisé.


Puis, pour capter plus encore notre attention (comme si cela était nécessaire !), David commence en nous montrant un cas où Git lui a épargné bien des tracas, et sans aucun doute, de très longues heures de recherche. Sur son projet, la commande « mvn eclipse:eclipse » ne fonctionne plus (c’est le drame). Pour information, cette commande analyse un projet configuré sous Maven, et en établit les fichiers de configuration d’Eclipse (les .project et .classpath en particulier) afin de l’intégrer au sein de l’IDE. Donc cette commande ne fonctionne plus. Que faire pour comprendre pourquoi, et savoir quand le problème est apparu.


David nous sort son premier joker, sous le nom de « git bisect« . Il faut savoir que Git est en réalité est constitué d’une batterie d’outils (un peu comme Maven avec sa pléthore de plugins, à l’exception que Git ne télécharge jamais tout Internet pour travailler ;) ). « bisect » est l’un d’entre eux. Donc David sait que sur une version un peu ancienne, tagguée VERSION1.1.3, la commande Maven fonctionnait bien, mais plus maintenant. Il va donc demander à Git de trouver quand, dans cet intervalle de temps séparant la version 1.1.3 à aujourd’hui, la regression est apparue. Il lance donc la commande suivante :
git bisect start HEAD VERSION1.1.3
Grosso-modo, cela indique que l’on va lancer l’analyse bisect entre le HEAD (code courant) et la version tagguée 1.1.3.
Ensuite, on va exécuter la commande suivante :
git bisect run sh -c « mvn eclipse:eclipse > /dev/null »
On indique à Git d’éxecuter la commande SH « mvn eclipse:eclipse > /dev/null » (on redirige vers le /dev/null pour éviter trop de logs). Là, Git nous indique qu’entre la version 1.1.3 et le HEAD, il y avait environ 140 révisions du code. Git bisect estime à 7 le nombre maximum de tentatives dont il aura besoin pour trouver le commit fautif (utilisation du principe de dichotomie). Après ces tests, notre outil finit par détecter le commit ayant introduit cette erreur. Voici les logs de git bisect :
cat ../maveneclipse.sh
#!/bin/sh
mvn eclipse:eclipse > /dev/null
git bisect start HEAD VERSION1.1.3
git run ../maveneclipse.sh
running ../maveneclipse.sh
Bisecting: 140 revisions left to test after this (roughly 7 steps)
[49be0b426f3469b154d66179ecdbaad2128b872e] Now formats Javadocs
running ../maveneclipse.sh
Bisecting: 70 revisions left to test after this (roughly 6 steps)
[18a0eddab7a745c9cec538b9184efb25499e06c1] More optimisations
running ../maveneclipse.sh
Bisecting: 37 revisions left to test after this (roughly 5 steps)
[051bccc6252b23be6c9074545986cd057bcc69d8] Merge branch ‘master’
running ../maveneclipse.sh
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[1183351cf1976571138c80dcf70e702dc3575177] Merge branch ‘master’
running ../maveneclipse.sh
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[a586dcbddca57d93e00ed7ebaeb02239bfdc515c] Merge branch ‘master’
running ../maveneclipse.sh
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[b4938d0a2aacabb4e71c2c08cab5e63ce12efbce] Merge branch ‘master’
running ../maveneclipse.sh
Bisecting: 1 revision left to test after this (roughly 1 step)
[6536952979f24786db146217b81f7d612bede425] Before we fix the build
running ../maveneclipse.sh
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[56750bb15630dbf1af1976ad0e7161c7ed696e69] Force Maven3
running ../maveneclipse.sh
56750bb15630dbf1af1976ad0e7161c7ed696e69 is the first bad commit
commit 56750bb15630dbf1af1976ad0e7161c7ed696e69
Author: David Gageot <gageot>
Date:   Wed Mar 17 18:20:29 2010 +0100
Enforce Maven3
On le voit à la toute fin, c’est un commit réalisé par David le 17 mars, avec pour commentaire « Enforce Maven 3″ qui a introduit ce problème.


(post du blog de David relatant la traque de ce problème)


Voilà comment, en quelques secondes, l’outil Git bisect a permis à David de comprendre où était le problème, et comment du coup le résoudre (non, il n’existe pas encore d’outil corrigeant automatiquement les bugs dans Git ;) ).


Comme introduction, je pense que David a réussi son coup ! Nous sommes déjà sous le charme…
S’ensuit alors une présentation des aspects plus basiques de Git. Comme créer un repository, explications des commandes classiques (clone, commit, pull, push, etc.). Là dessus, je pense que j’écrirais un nouveau post un peu plus tard, une fois que je commencerais à mieux maitriser l’outil, et ses particularités. Je voudrais éviter de dire trop de bêtises pour l’instant !


Mais dans les grandes lignes, David a bien insisté sur la simplicité de l’outil – bien qu’il soit assez déroutant aux premiers abords – mais également sur sa puissance et sa robustesse. Il nous a indiqué n’avoir jamais eu a pesté contre l’outil en 2 ans d’utilisation ! Connaissant David, je peux vous assurer que si un outil ne lui plaît pas, il ne se gênera pas pour qu’on le sache ;) L’une des grandes forces de Git, c’est son intelligence à comprendre les structures des projets, de s’adapter facilement et de façon non intrusive aux différentes modifications du code, et à gérer d’une manière presque magique tous les merges.


Un exemple qui me parle tout à fait est celui-ci :
Sa société s’appelait l’année dernière tech4quant. Par conséquent, l’ensemble des packages Java démarraient par com.tech4quant.*. Il y a quelques mois, la société a été renommée Algodeal. Du coup, David a décidé de renommer tous les packages en com.algodeal.*. Or en Java, un package se trouve dans le répertoire du même nom (donc ici com/tech4quant/… et com/algodeal/…). Or si vous connaissez CVS ou Subversion, vous savez que cette tâche est pratiquement impossible, ou du moins les obstacles à sa bonne réalisation vous pousse à tout simplement éviter un tel renommage ! Pourtant, grâce à Git, David a réalisé cela de façon tout à fait normale, en exécutant simplement les tâches de renommage de répertoires, et de refactoring massif du code Java (histoire de changer le nom des packages ainsi que les import). Git, s’est quant à lui chargé de tout gérer proprement, sans perte d’historique, sans aucune douleur. Une fois de plus, bravo Git !


On a bien entendu évoqué l’intégration de l’outil dans l’écosystème du développeur (Java essentiellement). Les plugins Eclipse ne sont pas encore très au point, et David se sert beaucoup du terminal mais également de GitX, qui propose une visualisation très agréable de l’historique d’une ressource, et se montre assez à l’aise avec les différentes opérations de commit.


Bref, David a facilement réussi à convaincre ses auditeurs de l’intérêt de Git. Reste que je reste toujours très sceptiques quant à l’adoption de cet outil au sein de grandes sociétés, et je ne peux hélas que le regretter, tant mon attrait pour Git s’est accru ce soir !


Merci à David pour ta présentation, merci également à Yannick Ameur pour avoir eu l’idée d’organiser ce cours du soir.
Start Slide Show with PicLens Lite PicLens

Tutoriel Play !

Lors de mon précédent billet, j’avais évoqué le framework Play en montrant comment réaliser un simple Hello World.

J’avais promis d’aller plus loin dans l’étude de ce framework, j’ai en fin de compte traduit l’intégralité du tutoriel présenté sur le site officiel. A travers ce tutoriel, vous pourrez découvrir plus de fonctionnalités de Play, d’apprendre la façon dont il gère la persistence, comment créer des pages complexes, d’ajouter de l’authentification, etc.

Vous pouvez lire ma prose sur mon site developpez.com !

Jouons !

Non, rangez les Nintendo, je ne vais pas parler de jeu, mais de Play !. Play ! est donc un framework créé par Guillaume Bort qui s’apparente quelque peu à Grails, mais 100% orienté Java. Je laisse le touilleur donner quelques explications supplémentaires sur cet outil.

Etape #1: Installons Play !

Pour installer Play!, rien de plus simple : il suffit de télécharger le ZIP (ici), puis de le décompresser sur son disque. C’est tout ! Pensons à ajouter le répertoire ainsi décompressé dans notre variable d’environnement Windows PATH, histoire de pouvoir taper la commande play en ligne de commande…

Etape #2 : Démarrons !

Allons à la racine de notre répertoire d’installation de Play!, et tapons la commande suivante :

d:\developpement\play-1.0> play new helloworld

La commande nous demande alors quelle est le nom de notre nouvelle application :

d:\developpement\play-1.0>play new helloworld
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ The new application will be created in d:\developpement\play-1.0\helloworld
~ What is the application name? HelloWorld
~
~ OK, the application is created.
~ Start it with : play run heloworld
~ Have fun!
~

Notre première application est prête ! Eh oui ! Voyons les choses plus en détails… Regardons le contenu du répertoire ainsi créé :

app/
conf/
lib/
public/
test/

Ces répertoires ont les rôles les suivants :

  • app : contient le code de l’application elle-même, à savoir les classes Java ainsi que les pages HTML.
  • conf : les fichiers de configuration, en particulier application.conf qui contient les paramètres de notre application (par exemple le port du serveur, la configuration de la connection à la base de données, etc.), le fichier routes, qui définit les liens entre les URL et les pages web. Enfin, ce répertoire contient le fichier messages utilisé pour l’internationalisation du projet.
  • lib : ce répertoire contient les librairies Java optionnelles.
  • public : place contenant les ressources publiques, à savoir les images, les fichiers Javascript ou CSS.
  • test : le répertoire permet de stocker les fichiers de tests, qu’il s’agisse de tests JUnit ou Selenium.

Et ça marche ? Voyons voir… Lançons la commande suivante :

d:\developpement\play-1.0\helloworld> play run
d:\developpement\play-1.0\helloworld>play run
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ Ctrl+C to stop
~
Listening for transport dt_socket at address: 8000
20:15:17,611 INFO  ~ Starting d:\developpement\play-1.0\helloworld
20:15:20,579 WARN  ~ You're running Play! in DEV mode
20:15:22,111 INFO  ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...

Rendons-nous sur l’adresse http://localhost:9000 (9000 étant le port par défaut du serveur Play !) pour visualiser la page par défaut :

Mais quelle est la magie ? Le fichier conf/routes définit le routage des requêtes au sein de notre application. En particulier :

# Home page
GET     /                                       Application.index

Cette ligne indique que lorsqu’un utilisateur se connecte à la racine de notre application (ici http://localhost:9000/), sa requête sera prise en charge la Application.index. Ce contrôleur est visible dans app/controlles/Application.java :

package controllers;

import play.mvc.*;

public class Application extends Controller {

  public static void index() {
    render();
  }

}

La première chose à constater ici c’est que notre contrôleur étend la classe play.mvc.Controller. Cette classe nous propose – entre autres – la méthode render() qui est ici utilisée dans l’action index. Cette action est par ailleurs définie comme une méthode publique et statique. C’est la façon de définir une action dans Play !. Dans cet exemple, cette dernière ne fait qu’afficher le contenu d’un template se trouvant dans app/views/Application/index.html (c’est le template utilisé par défaut, car nous n’en avons pas défini dans notre classe Java) :

#{extends 'main.html' /}
#{set title:'Home' /}

#{welcome /}

Ce template est divisé en trois parties. Tout d’abord, on y voit que notre template étend le main.html :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>#{get 'title' /}</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <link rel="stylesheet" type="text/css" media="screen" href="@{'/public/stylesheets/main.css'}" />
    <link rel="shortcut icon" type="image/png" href="@{'/public/images/favicon.png'}" />
  </head>
  <body>
    #{doLayout /}
  </body>
</html>

Dans ce fichier, on y voit le tag #{doLayout /} qui marque l’endroit où sera inseré le contenu du fichier Application/index.html.

Ensuite, on constate la façon dont un paramètre du template (le title) est passé à la page parente, via les #{set …/} et #{get …/}.

Enfin, la partie #{welcome /} génère le message d’accueil que nous avons pu voir précédemment.

Etape #3 :Utilisons Eclipse

Pour faciliter le développement de notre application, nous utilisons Eclipse. Pour ce faire, utilisons la commande suivante :

d:\developpement\play-1.0> play eclipsify helloworld

Play ! se charge alors de créer les fichiers nécessaires à Eclipse :

d:\developpement\play-1.0>play eclipsify helloworld
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ OK, the application is ready for eclipse
~ Use File/Import/General/Existing project to import d:\developpement\play-1.0\helloworld into eclipse
~
~ Use eclipsify again when you want to update eclipse configuration files.
~ However, it's often better to delete and re-import the project into your workspace since eclipse keeps dirty caches...
~

Les fichiers nécessaires à l’importation du projet dans Eclipse sont désormais créés. Il s’agit du .project, .classpath et .settings/.

Voilà, nous avons notre première petite application Play ! qui tourne. On a vu deux ou trois concepts intéressants, mais il y a encore plein de jolies choses à découvrir sur ce framework (si vous avez suivi le lien du Touilleur que je vous ai donné en début de post, vous en avez déjà vu quelques unes) ! Nous les aborderons dans un prochain post, très bientôt !

Bonus

Voici la liste des options proposées par la commande play :

C:\developpement\play-1.0\>play help
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.0, http://www.playframework.org
~
~ For all commands, if the application is not specified, the current directory is used
~ Use 'play help cmd' to get more help on a specific command
~
~ Available commands are:
~ ~~~~~~~~~~~~~~~~~~~~~~~
~ auto-test      Automatically run all application tests
~ classpath      Display the computed classpath
~ clean          Delete temporary files (including the bytecode cache)
~ eclipsify      Create all eclipse configuration files
~ help           Display help on a specific command
~ id             Define the framework ID
~ modules        Display the computed modules list
~ netbeansify    Create all netbeans configuration files
~ new            Create a new application
~ out            Follow logs/system.out file
~ pid            Show the pid of a running application
~ precompile     Precompile all Java sources and templates to speed up application start
~ run            Run the application in the current shell
~ restart        Restart the running application
~ secret         Generate a new secret key
~ status         Display the status of the running application
~ start          Start the application in background
~ stop           Stop the running application
~ test           Run the application in test mode in the current shell
~ war            Export the application as a standalone WAR archive
~
~ Also refer to documentation at http://www.playframework.org/documentation
~
Start Slide Show with PicLens Lite PicLens

Et une année de plus chez developpez.com

Début avril 2008, il y a presque deux ans maintenant, mon premier article sur Hudson paraissait sur le site de developpez.com. Depuis, j’ai écrit 4 autres articles, 2 compte-rendus de conférences, ainsi qu’une critique de livre :

Quelques chiffres maintenant, concernant l’année 2009 :

On voit que la fréquentation quotidienne – hors week-end – est d’à peu près 120 – 150 visiteurs. On distingue cependant quatre pics lors du second semestre de l’année :

  • Le 14 août, avec 750 visites, correspond à la mise à jour de l’article sur Sonar.
  • Le 6 octobre, avec 340 visites, pour le compte-rendu de la conférence CitConf 2009.
  • Le 25 novembre, avec 682 visites, atteint grâce à l’article sur les comparatif des outils de builds Java.
  • Le 17 décembre avec 743 visites, pour l’article traitant des nouveautés de Maven 3.

Au total, durant cette année 2009, ce sont 35,940 visites qui ont été faites par 20,935 visiteurs sur mon site de developpez.com ! Cela fait un total de 62,322 pages vues.Pas mal non ?

Malgré cela, c’est mon « vieil » article sur Hudson (paru en avril 2008) qui truste la première place, avec 35,77% des pages vues.

Côté visiteurs, c’est évident la France qui héberge la plupart des visites (27,945 visites sur les 35,940), le Maroc arrivant deuxième (1,363 visites), suivie de près par la Belgique (1,105).  La Suisse, la Tunisie complète le quinté.

Au niveau des navigateurs, Firefox obtient la médaille d’or, avec presque 3 visiteurs sur 4 (71,56%), suivi d’Internet Explorer (16,32%), puis Chrome (5,93%). La très forte majorité des visiteurs tournent sur Windows (83,86%), Linux étant leur deuxième choix (11,80%). Il arrive également que quelques adeptes de la Pomme visitent mon site (3,89% pour MacOS, 0,24% pour l’iPhone !)…

Voilà une très belle année 2009 pour moi de ce côté-là. L’année 2010 sera-t-elle aussi productive ? Réponse dans 363 jours !

Start Slide Show with PicLens Lite PicLens