La première édition de Devoxx France s’est terminée depuis quelques jours, voici donc un bref retour d’expérience ainsi que les réponses au concours que nous avions organisé.

L’organisation était au top. Les gilets rouges ont bien pris en main l’organisation globale, et malgré la jeunesse de l’évènement, aucun aléa n’est venu perturbé ces 3 journées. Les sessions étaient très variées, et certaines demandaient un niveau technique assez élevé. D’autres au contraire permettaient de découvrir des sujets qui ne sont pas forcément connus des développeurs Java comme par exemple la session d’Alexandre Bertails sur la théorie des langages.

D’un point de vue personnel, j’ai adoré cette première édition. On sentait que l’expérience de Stephan Janssen a permis à Devoxx France de paraître déjà rodé. J’ai pu assisté à de nombreuses sessions très intéressantes et enrichissantes comme celle de Pablo Lopez présentant Hadoop pour gérer les 7Go de logs produites chez son client. J’en ai malheureusement loupé d’autres. Vivement que les sessions soient sur Parleys. Devoxx a vraiment été une cure technique revigorante de part la diversité des sujets et la maîtrise technique des speakers.
D’autre part, en jouant chez divers sponsors j’ai pu gagner un Samsung Galaxy Tab et un Kindle ! Un petit bonus qui a contribué à passer un excellent moment.

Application In Fine Devoxx France

Nous avions mis à disposition des utilisateurs Android une application permettant de gérer son planning pendant les 3 jours de Devoxx France. Les retours des utilisateurs ont été très bons et peu de bugs ont été recensés.
Lors du deuxième jour, le planning a pu indiquer des salles qui ne correspondaient pas à la réalité. Ceci est en fait dû une désynchronisation entre l’application et l’API du site Devoxx. L’API REST ne renvoyait pas les bonnes salles ce qui a pu en gêner certains. Le troisième jour, tout est rentré dans l’ordre et l’API renvoyait les données exactes.

Comme nous l’avons annoncé avant Devoxx France, nous mettons en open source le code de cette application. Le code source est en licence Apache 2 et est disponible sur mon GitHub.

Cette application est censée se connecter à un serveur qui renvoie des données JSON qui ont un format spécifiques. Cette partie peut être adaptée facilement pour récupérer les données renvoyées par le serveur devoxx.

Concours In Fine avec un Mac Book Air à la clé

En tant que sponsor, nous organisions un concours de code. Le gagnant pouvait emporter un Mac Book Air. Le principe était simple : modifier 6 morceaux de code en sept minutes trente.
La difficulté venait du fait que le code était édité dans un navigateur web et pas dans un IDE ! A chaque modification de code, une compilation automatique était envoyée à un serveur permettant de valider la réponse du candidat.

Les réponses aux questions ne nécessitaient pas de connaître les API du JDK par coeur, seules le nom des classes et leur constructeur étaient utiles. Les questions et réponses sont données un peu plus loin dans ce post.

Nicolas De Loof a emporté haut la main le concours en étant le seul à donner les 6 bonnes réponses dans le temps imparti. Les autres participants n’ont pas démérité, mais le fait de coder dans un navigateur a dû en déconcerter plus d’un.

Questions du concours

Chaque question comprend un énoncé, une partie de code éditable par l’utilisateur ainsi que du code non éditable. Les imports se font automatiquement.

Question 1

Comment faire en sorte que myMap puisse garder l’ordre d’insertion

// Début de la partie éditable

Map<String, Integer> myMap = new HashMap<String, Integer>();

// Fin de la partie éditable
myMap.put("val2", 2);
myMap.put("val1", 1);
myMap.put("val3", 4);

Iterator<Integer> i = myMap.values().iterator();
assert(result = i.next() == 2 && i.next() == 1 && i.next() == 4);

Réponse 1

Il faut une certaine connaissance des collections Java. TreeMap n’est pas utilisable ici car il réordonne les entréés à chaque insertion.

Map<String, Integer> myMap = new LinkedHashMap<String, Integer>();

Question 2

Le test est valide lorsque myVar vaut 66666

// Début de la partie éditable

long myVar = 5432l;

// Fin de la partie éditable
myVar += 12345;
assert(myVar == 66666);

Réponse 2

Il fallait mettre un 1 au lieu du l minuscule. Cette question est une référence à Josh Bloch.

long myVar = 54321;

Question 3

Ecrivez une méthode qui calcule la factorielle d’un nombre n . Si n est négatif alors on retourne Double.NaN

// Début de la partie éditable
double fact(int n) {
    return 0;
}
// Fin de la partie éditable

Réponse 3

Faire une fonction récursive était la manière la plus évidente et la plus naturelle.

double fact(int n) {
    if (n == 0)
        return 1;
    else if (n == 1)
        return 1;
    else if (n < 0)
        return Double.NaN;
    return n * fact(n-1);
}

Question 4

Ecrivez la méthode getDayOfWeek qui prend en entrée le nombre de jour depuis le 1 Janvier 1970 ( ce jour était un jeudi ) et qui retourne le jour correspondant.

public final static int SUNDAY = 1;
public final static int MONDAY = 2;
public final static int TUESDAY = 3;
public final static int WEDNESDAY = 4;
public final static int THURSDAY = 5;
public final static int FRIDAY = 6;
public final static int SATURDAY = 7;

// Début de la partie éditable
int getDayOfWeek(int day) {
    return 0;
}
// Fin de la partie éditable

Réponse 4

Cette question probablement était probablement la plus difficile. Ceux qui ont essayé de trouver une formule qui marche sur une ligne avec un modulo ont tous échoué. D’autres ont essayé d’utiliser la classe Calendar, mais sans auto-complétion et sans connaissance de l’API ils ont échoué également. La solution la plus simple est celle ci-dessous.

int getDayOfWeek(int day) {
    int moduloDay = day % 7;
    switch(moduloDay){
        case 0 : return THURSDAY;
        case 1 : return FRIDAY;
        case 2 : return SATURDAY;
        case 3 : return SUNDAY;
        case 4 : return MONDAY;
        case 5 : return TUESDAY;
        default : return WEDNESDAY;
    }
}

Question 5

Modifiez le code pour que le resultat de la soustraction soit égal à 0.9

void substract() {
// Début du code éditable

    BigDecimal a = new BigDecimal(2.00);
    BigDecimal b = new BigDecimal(1.10);
	
// Fin du code éditable
    assert(a.subtract(b).doubleValue() == 0.9);
}

Réponse 5

Un énoncé et une réponse simple encore une fois. Il fallait connaître les spécifités de ce constructeur. En initialisant un BigDecimal avec un double, la valeur initialisée est une valeur approchante au paramètre. En utilisant un paramètre de type String, alors c’est la valeur exacte qui est utilisée.

    BigDecimal a = new BigDecimal("2.00");
    BigDecimal b = new BigDecimal("1.10");

Question 6

Comment accède-t’on dans la méthode getSuperVal à l’attribut val de la classe B ?

class B {

    int val = 2;
    A a = new A();

    class A {
        final public int val = 3;

        int getSuperVal() {
            // Début du code éditable
            return ;
            // Fin du code éditable

        }
    }
}

Réponse 6

Syntaxe peu utilisée, mais encore une fois cette réponse était simple à donner dans un navigateur sans auto-complétion.

return B.this.val;

Question 7

NB : Cette question a remplacé 6 la question le dernier jour de Devoxx France.
Comment faire en sorte que myMap ait une taille de 3 ? La Map ne doit contenir que des clés “test”.

// Début du code éditable
Map<String, Integer> myMap = new HashMap<String, Integer>();
// Fin du code éditable

myMap.put(new String("test"), 1);
myMap.put(new String("test"), 2);
myMap.put("test", 3);

int size = myMap.size();
assert(size == 3);

Réponse 7

Encore une fois il fallait un peu connaître les classes qui composent l’API Collection.

Map<String, Integer> myMap = new IdentityHashMap<String, Integer>();

Merci à tous ceux qui sont venus nous voir sur le stand, on a passé de bon moments. A l’année prochaine !

The post Bilan de Devoxx France first appeared on In Fine - Le Blog.

In Fine, en tant que partenaire de l’évènement majeur qu’est Devoxx France, a le plaisir de mettre à disposition une application pour Devoxx France sur Android. Cette première version permet :

• De mettre en favoris vos sessions préférées
• De consulter le planning des sessions, et le détail des speakers
• De voir ce qui se passe sur Twitter avec le tag devoxxfr
• D’avoir accès au plan des 2 étages de l’hôtel où se déroulera la conférence
• Et d’autres fonctionnalités…

Cette application fonctionne parfaitement sur téléphone , mais n’est pas encore totalement adaptée pour les tablettes. Dans les semaines qui viennent, nous allons continuer à mettre à jour l’application pour qu’elle soit la plus simple à utiliser possible. Voici une prévision des futures évolutions :

• Complète adaptation de l’ergonomie de l’application aux tablettes
• Ajout de la recherche sur les speakers. Actuellement elle ne fonctionne que sur les sessions
• Quand on clique sur une salle, afficher la carte de l’étage correspondant
• Pouvoir mettre en favori des speakers
• Et bien d’autres choses qui dépendront des retours que nous aurons

Nous sommes très fiers de mettre à disposition cette application. Elle sera mise en open source au moment de la conférence Devoxx France, certainement en licence Apache 2.
Si vous rencontrez des problèmes ou avez des suggestions, écrivez un commentaire ici, ou envoyer un mail au compte indiqué sur la fiche du Google Play Store.

Dans la suite de l’article, nous allons approfondir l’aspect technique de l’application. Si au contraire vous souhaitez directement aller télécharger l’application, alors il faut aller ici : Play Store

Architecture technique

Comme le montre le schéma ci-dessus, nous n’avons pas directement connecté l’application Android avec les API RESTful fournies par le site Devoxx. En effet les temps de réponse sont très variables, certains service ont déjà mis plus de 5 minutes à répondre. D’autre part, certains service renvoient des données en double ou incomplètes.
Le serveur intérmédiaire permet donc de mieux maîtriser les données. Grâce à Play et à Mongo DB, les temps de réponse sont excellents et la charge que peut encaisser le serveur est bien au dessus de ce que nous atteindrons. Un test JMeter a mesuré que le serveur pouvait encaisser 300 requêtes par secondes. La plupart des requêtes répondent en moins de 0.1 seconde. Nous estimons que le serveur aurait à supporter, au maximum de son activité, 25 requêtes par minute

The post L’application Devoxx France d’In Fine est disponible sur le Google Play Store first appeared on In Fine - Le Blog.

Ceylon est un nouveau langage s’exécutant sur la JVM. Il rejoint une liste désormais assez longue qui comprend notamment :

• Groovy
• Jython
• Jruby
• Scala
• Kotlin
• Fantom
• Gosu
• …

Gavin King a créé Ceylon parce qu’il était frustré par les limitations de Java. Cette session a été animée par deux français, Emmanuel Bernard et Stéphane Epardaud qui sont commiters sur le projet. Ils ont débuté la session en définissant les objectifs de Ceylon, avant de continuer sur ses fonctionnalités à l’aide de code. Je ne vais pas reproduire le code qu’ils ont utilisé pendant la présentation dans cet article, je vais essayer d’être plus concis.

Emmanuel commence par nous indiquer les objectifs de Ceylon :

• Permettre d’écrire du code plus simple que l’équivalent en java
• Éviter au développeur de tomber dans les principaux pièges de java

Ceylon est pensé pour être lu facilement par des développeurs venant du monde Java. Emmanuel insiste bien sur ce point : Ceylon doit être simple à utiliser mais également simple à lire. Le code ne doit pas soulever d’ambiguïté.

Principes de base

Classe simple

shared class User(String username, Natural age) {
    shared String username = username;
    shared Natural age = age;

    shared void printUser() {
        print("User name : " username " with age " age " is printed");
    }
}

Cette classe est courte, mais il y a déjà plusieurs choses à dire dessus :

• Le mot-clé class indique évidemment qu’il s’agit d’une déclaration de classe
• Le mot-clé shared est l’équivalent du public de Java. Si le mot-clé shared est omis, alors la visibilité est privée (visibilité par défaut en Ceylon)
• A la suite de la déclaration de la classe User se trouvent des paramètres (String username, Natural age), il s’agit de la déclaration du constructeur. Je dis bien du car une Ceylon interdit la surcharge de méthode et donc un seul constructeur est autorisé
• Natural est l’objet représentant un nombre entier naturel. En Ceylon, il n’y a pas de type primitif
• Les attributs de la classe sont obligatoirement initialisés, il n’y a pas de valeur par défaut, même null n’est pas implicite. Ici, les valeurs sont celles fournies au constructeur
• La déclaration de la méthode printUser se fait comme en Java, le mot-clé shared en plus si on souhaite l’exposer
• La concaténation de chaîne de caractère peut se faire sans le caractère +. La concaténation avec le caractère + fonctionne également

Méthodes

shared class Parent() {
    shared default void printMe() {
         print("I'm in parent class");
    }

    shared void printMessage(String messageToPrint = "default argument value") {
         print("I'm in parent class and I print " + messageToPrint);
    }
}

shared class Child() extends Parent() {
    shared actual void printMe() {
         print("I'm in child class");
    }
}

void testCeylon() {
    // appel de méthodes
    Parent p = Parent();
    p.printMe();
    p.printMessage(); // default value of parameter used - will work on milestone 2
    p.printMessage("message given as argument");  // classic call
    p.printMessage {  // name argument used
        messageToPrint = "message with named arguments";
    };
}

Encore une fois, malgré la petite taille de code et sa lisibilité, plusieurs fonctionnalités sont à décrire :

• Comme dit plus haut, les méthodes ne sont pas surchargeables. Pour palier à cette obligation les paramètres peuvent avoir des valeurs par défaut (ligne 6), des varargs peuvent être utilisés (comme en java), ou des union types peuvent être utilisés (voir la doc pour plus de détails)
• Les paramètres des méthodes sont nommés – ligne 22
• Les méthodes peuvent être redéfinies dans les classes filles mais il faut l’autoriser explicitement grâce au mot clé default dans la classe parent (équivalent du virtual du C++ utilisé dans la classe parent) – ligne 2
• Lors de la rédéfinition de la méthode dans une classe fille, il faut obligatoirement utiliser le mot-clé actual (équivalent à l’annotation @Override de Java) – ligne 12

null et immuabilité

Par défaut toutes les variables sont immuables en Ceylon. Afin de les rendre modifiables il faut explicitement adapter la syntaxe de déclaration d’une variable en ajoutant le mot-clé variable et effectuer l’affectation avec l’opérateur := :

shared class ImmutableExample(Natural year) {
    // immutable
    Natural year = year;
    // Mutable
    variable Natural writableYear := year;
}

Afin d’éviter les trop nombreux NullPointerException de Java, une variable qui pourrait contenir la valeur null doit être déclaré à l’aide d’un ?. Ceci a des conséquences sur la manière d’utiliser ces variables comme le montre le code ci-dessous :

// myBestVariable can be null
String? myBestVariable = functionThatCanReturnNull();
// to work on myBestVariable, a null check must be done
if (exists myBestVariable) {
    functionThatNeedAString(myBestVariable);
}
else {
    functionThatNeedAString("default value");
}

Autres fonctionnalités

Emmanuel et Stéphane ont présenté d’autres fonctionnalités importantes de Ceylon telles que les union type et les intersection type. Pour plus de détails, reportez vous à la documentation officielle.
Malgré les arguments nommés, il est possible d’utiliser les generics. Les annotations sont également disponibles.
La compatibilité entre Java et Ceylon est également disponible. Ceylon peut utiliser du code écrit en Java, et Java peut appeler du code Ceylon.

En pratique

Emmanuel et Stéphane, après avoir transmis les bases à l’auditoire, effectuent une démo en live de Ceylon dans Eclipse. Un plugin Eclipse a été développé et est déjà fontionnel. L’autocomplétion fonctionne bien, la coloration syntaxique et le refactoring également. Plus d’infos sur le repo git associé.

Aucune version de Ceylon n’a encore été releasée. La prochaine version à sortir sera la milestone 1 qui ne comprendra pas encore toutes les fonctionnalités de la spécification. Trois milestones sont prévues avant que la version 1.0 ne sorte.

Test de Ceylon

Il est évidemment possible aujourd’hui de tester dès aujourd’hui Ceylon et pour cela, j’ai réalisé un petit screencast afin de vous montrer qu’avoir le compilateur Ceylon utilisable sur son poste est vraiment simple et rapide.

Les prérequis sont d’avoir sur sa machine Java 6, Ant et Git. Dans le screencast, je clone les trois repositories Git nécessaires à la création du compilateur. Chacun nécessite Ant afin d’être compilé. Une fois le compilateur généré, je le teste en compilant l’exemple de code que j’ai donné ci-dessus dans le paragraphe Méthodes, et je l’exécute.

Pour ceux qui veulent tester, je vous retranscrits les commandes utilisées dans le screencast afin de faciliter le copier coller

Une fois le compilateur généré, je l’ai testé. Mon fichier source se nomme florian_boulay.ceylon et se trouve dans le répertoire samples. Le répertoire build contient les fichiers Ceylon compilés. testCeylon correspond au nom de la fonction appelée pour lancer le programme.

Ceylon est un langage simple à comprendre pour qui vient de Java. En écrire est également à la portée de tous. Jusque là les objectifs de Gavin King sont atteints.

Fin de la session

Pour finir, Emmanuel nous indique que Ceylon a enfin sont site web : http://ceylon-lang.org

Il contient une documentation très complète, la spécification du langage écrite par Gavin King, un blog et tout ce qu’il faut pour contribuer au développement du langage. C’est là bas qu’il faut aller si vous souhaitez tester le langage qui n’a pas encore été releasé, mais peut être testé via la récupération du code source sur Github.

Comme vous le voyez, le logo de Ceylon est un éléphant, est-ce un hommage à PHP ? On peut lui souhaiter qu’il ait le même succès que PHP

De nombreux nouveaux langages ont émergé ces derniers mois fonctionnant sur la JVM (Eclipse Xtend, JetBrains Kotlin). Comme dit plus haut, Ceylon veut rester accessible à tout le monde en restant simple et facilement compréhensible. Est-ce que ces atouts seront suffisants pour faire de Ceylon une alternative à Java réellement utilisée, comme l’est Scala aujourd’hui ? Faites vous votre propre opinion et essayez le.

The post Devoxx 2011 – Ceylon first appeared on In Fine - Le Blog.

Chet Haase et Romain Guy nous ont présenté pendant Devoxx lors de la conférence Graphics goodies in Android, les nouveautés d’Android pour développer des applications qui tuent. Nous allons voir dans cet article l’utilisation de l’accélération graphique pour les rendus 2D des applications Android 3.0 et supérieures.

L’openGL existe depuis les premières versions d’Android pour les jeux et certains autres composants mais l’interface graphique des applications a toujours été “SOFTWARE”.
Depuis Android 3.0 il est possible d’activer l’accélération graphique pour chaque application ce qui nous permet d’avoir une meilleur expérience utilisateur, avoir des animations plus fluides et de libérer un peu le CPU.

Software rendering vs Hardware rendering

Lorsqu’une application utilise l’accélération matérielle, l’OpenGL est utilisé lors de l’appel de la fonction Canvas.draw().

Activation de l’accélération matérielle

Pour activer l’utilisation du GPU sur Android 3.0+, il suffit d’ajouter android:hardwareAccelerated=“true” dans le tag application du fichier AndroidManifest.xml. Ce simple ajout devrait activer l’accélération matérielle pour toute votre application, cependant certains composant ne peuvent pas (encore) bénéficier de cette fonctionnalité c’est pourquoi nous allons voir par la suite comment la contrôler.

Contrôle de l’accélération matérielle

Si votre application a des problèmes sur certains éléments avec l’accélération matérielle, il est tout à fait possible de définir quels éléments doivent ou non utiliser le GPU.

On peut donc l’activer ou la désactiver sur ces différents éléments :

• Application
• Activity
• Window
• View

Pour utiliser l’accélération matérielle au niveau Application ou Activity il faut utiliser le fichier AndroidManifest.xml

<application android:hardwareAccelerated="true">
    <activity ... />
    <activity android:hardwareAccelerated="false" />
</application>

Voici ci-dessous un exemple de code à utiliser pour l’utiliser au niveau “Window” :

getWindow().setFlags(
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

Pour finir, on peut désactiver l’utilisation du GPU seulement pour un partie de l’écran (View) :

view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Vérifier si un élément utilise le GPU

Il peut être important de savoir si un élément utilise l’accélération matérielle à un moment donné.
Il existe 2 façons de le vérifier :

• View.isHardwareAccelerated(), retourne “true” si la View est attachée à une Windows qui utilise le GPU
• Canvas.isHardwareAccelerated(), retourne “true” si le Canvas est acceleré

Fonctions supportant l’accélération matérielle

La plupart des fonctions habituelles de la classe Canvas sont supportées, cependant certaines ne le sont pas mais le seront peut-être dans les futures versions d’Android.

Voici la liste des fonctions non supportées :

Certaines autres fonctions fonctionnent différemment lorsque l’accélératrion matérielle est activée :

The post Devoxx 2011 – Utilisation du GPU pour les applis Android first appeared on In Fine - Le Blog.

Cette première grosse journée pour Devoxx a été l’occasion de faire différentes annonces. La première concerne le framework Play et la deuxième concerne le monde Java français.

Play

La version 2.0 de Play a déjà été annoncée il y a plusieurs semaines. Une pré-version de test avait été mise à disposition. Aujourd’hui la sortie de la beta a été annoncée.

Lors de la présentation faite par Sadek Drobi (@Sadache) et Guillaume Bort, les nouveautés ont été détaillées :

• Intégration de Scala directement dans Play : les templates ne se feront plus en Groovy mais en Scala. Les classes pourront être faites en Java ou en Scala. Cela a pour conséquence la mise à disposition de la console Scala qui permettra, par exemple, d’appeler directement du code applicatif à parti de la ligne de commande.
• Un système de build est désormais intégré, il s’agit de SBT (Simple Build Tool). Ce choix est certainement la conséquence de l’intégration de Scala. Cela remplacera l’ancien système basé sur Ivy.
• Intégration d’Akka
• Les scripts javascript et les feuilles de styles sont compilés

Plus d’infos disponibles sur le site officiel : http://scala.playframework.org/2.0

L’autre annonce est que Play intègre désormais la stack Typesafe. Cela signifie que Typesafe fournira du support sur Play. De plus Guillaume Bort va désormais siégé au board of advisor de Typesafe (Je ne sais pas comment le traduire, conseil d’administration ?) en tant que conseiller sur les choix techniques web d’après ce que Guillaume a dit durant sa présentation.

Devoxx France

Une version française de Devoxx se tiendra du 18 au 20 avril 2012 à Paris ! Elle est inspirée du modèle belge et elle durera 3 jours et sera à 75% en français et 25% en anglais. Elle est organisée par les membres du Paris Jug (Antonio Goncalves, Zouheir Cadi, José Paumard et Nicolas Martignolle). Ce sera la plus grosse conférence Java francophone, venez nombreux !
In Fine sera bien entendu partenaire de cet évènement.
Plus de détails sur le blog de Nicolas Martignolle.

The post Devoxx 2011 – annonces first appeared on In Fine - Le Blog.

Jeudi 30 juin, dans le cadre d’In Fine Academy, Christophe Havet, consultant In Fine nous a donné une présentation sur Grid Computing avec Symphony. En voici le support :

Application, bénéfices, limites et contraintes du grid computing à travers l’exemple de l’outil Symphony de Platform.

The post In Fine Academy : Grid Computing avec Symphony first appeared on In Fine - Le Blog.

Hier, s’est tenue au siège la deuxième présentation d’In Fine Academy portant sur la programmation parallèle avec GPU sur CUDA par Maxime Fromentin, consultant In Fine.

The post In Fine Academy : Programmation parallèle avec GPU sur CUDA first appeared on In Fine - Le Blog.

Mardi soir se tenait une session consacrée entièrement à Git au Paris JUG qui a été sponsorisée par In Fine. Elle a rencontré un énorme succès, les places ont été prises d’assaut en moins de 4h. Néanmoins beaucoup de gens se sont fait recaler à l’entrée.

La polémique des inscriptions

Certains ont accusé JUG Events pour ce désastre au niveau des inscriptions. Quoi qu’il en soit, ce site semble de plus en plus inadapté au succès que rencontre le Paris JUG. Il y a quelques mois Nicolas Martignole avait indiqué que JUG Events était open source, et que toute contribution était la bienvenue pour améliorer le site (Google Code de JUG Events). Si vous avez quelques heures pour le faire, n’hésitez pas, toute la communauté des JUG vous en saura gré.

Quiz et Mac Book

In Fine, sponsor du JUG a voulu pour cette soirée créer une animation différente : des boîtiers ont été distribués à chaque participant afin de participer à un quiz portant sur Git et Java principalement, présenté par Antoine Ramponi. Le gagnant du quiz s’est vu remettre un Mac Book Air ! Il s’agit de Guillaume Darmont (@gdarmont) qui a fait un sans faute en répondant correctement aux 18 questions. Bravo à lui ! Les photos sont à la fin de l’article.

Sébastien Douche, l’unique speaker

Sébastien Douche, en habitué, est venu présenté Git en 2 parties : la première théorique est la deuxième avec des cas plus pratiques. Contrairement à sa présentation de l’année dernière sur les DVCS en général, cette soirée est entièrement dédiée à Git.

Mais avant d’attaquer le vif du sujet, rappelons qui est Sébastien Douche. Il se présente comme une personne multi-casquettes. Il est directeur technique, responsable R&D, coach et release manager. Cette dernière a fait qu’il s’est intéressé aux DVCS en général, puisqu’il a également pratiqué Mercurial pendant 2 ans avant de passer à Git. Il a créé un blog sur Git (appelé gitfr) qui lui sert surtout de support pour ses présentations. On y trouvera également de nombreux articles intéressants, ainsi gitfr est devenue une ressource francophone de qualité sur Git.
Son espoir : que le gens travaillent ensemble de manière efficace.
Par ailleurs, il fait de l’agilité, du python, aime la bière.
A suivre sur twitter @sdouche

1^ère partie : le backend de Git

A première vue, Git peut sembler complexe, pourtant il est fait de concepts simples. Mis ensemble, ils font la puissance de Git. En passant à Git, Sébastien suggère de tout oublier (en visant SVN notamment). Les habitudes que nous av(i)ons avec Subversion ne sont pas transposables avec Git.
Git est très apprécié par ceux qui l’utilisent. Par exemple dans le Git Survey 2010, 95% des utilisateurs sont heureux ou en extase avec Git. Pas sûr que le résultat soit le même avec un outil comme Subversion.
Sébastien résume Git en 3 points :

• Gestionnaire de contenu
• Stocké sous la forme d’un graphe acyclique d’objets
• Accessible avec des références

Git peut être vu de 2 points de vue : backend et frontend. Le backend est composé de commandes dites “plumbing” et le frontend de commandes dites “porcelain”. Le frontend correspond aux commandes utilisées quotidiennement. Ces commandes font appel aux commandes bas niveau (plumbing) du backend.
Sébastien est convaincu qu’il vaut mieux connaître les concepts clés du backend sur lesquels s’appuie Git afin de mieux l’utiliser et de mieux le maîtriser.

Concept 1 : Git est un gestionnaire de contenu

Git est orienté contenu (contrairement à SVN qui est orienté fichier), cela signifie qu’il stocke les fichiers en entier pour chaque commit, alors qu’un gestionnaire orienté fichier stocke seulement les deltas entre 2 commits.

Les objets sont stockés dans une base de données de type clé/valeur. Les clés sont de type SHA-1. Ce qui assure leur unicité dans le monde entier. Tout objet dans Git peut être identifié à l’aide de son SHA-1.

Exemple de SHA-1 : da39a3ee5e6b4b0d3255bfef95601890afd80709 qui peut être raccourci en da39a3

Git possède 3 types d’objets principaux :

• Blob : contenu des fichiers
• Tree : correspondance entre Blog et nom de fichier
• Commit : ensemble de Tree regroupés lors d’un commit

Concept 2 : La relation entre commits est un graphe acyclique (DAG)

Un graphe acyclique est un graphe sans boucle.
Dans Git, chaque commit connait son ou ses parents, c’est-à-dire quels sont les précédents commits sur le fichier.

Git contient 6 opérations qui permettent d’ajouter du contenu dans le graphe (donc dans la base de données) :

• commit : ajout de contenu dans le graphe
• merge : fusion de 2 branches
• rebase : simplification du graphe en transformant 2 branches en une seule
• squash : nettoyage du graphe
• cherry : copie sans conservation de l’historique
• revert : annulation de l’ajout d’un contenu

Sébastien insiste pour nous dire que sur Git, seule la vision topologique a un sens, contrairement à la vision chronologique d’autres VCS (i.e. SVN). Ainsi Git offre plusieurs commandes permettant d’avoir cette vision en réarrangeant l’historique.
Dans Git, les objets sont immuables. De plus un historique de toutes les actions est conservé, nommé le reflog. Il permet de défaire toute opération qui aurait mal tourné, tel qu’un rebase qui aurait complètement pourri le projet par exemple.

Concept 3 : Les objets sont accessibles sous forme de référence

Deux types de référence existent dans Git :

• Déplacées par Git : par exemple master qui est l’équivalent de head pour Subversion
• Déplacées par l’utilisateur : par exemple un tag léger posé par l’utilisateur

Une branche n’est qu’une référence vers un noeud du graphe déplacée par Git. C’est pourquoi une branche est si rapide à créer. Concrètement, une référence n’est qu’un fichier de 40 octets.

Résumé des concepts

Git peut être vu comme un empilement de couches (de bas en haut) :

• Base de données (objets de type blob)
• Mini système de fichiers (objets de type tree)
• Relation entre objets (objets de type commit)
• Objets facilement mémorisables (références)

La première partie termine comme elle a commencé, en rappelant que Git n’est pas si compliqué. Git n’est pas magique, il est basé sur des concepts simples et bien implémentés. Git est au niveau de ce qu’on attend d’un VCS aujourd’hui, alors que SVN est basé sur CVS qui date des années 80.

2^ème partie : Git en pratique

Bien commencer

Dans cette partie, Sébastien a voulu démontrer la puissance de Git en présentant des bonnes pratiques et des fonctionnalités qui lui sont liées.
Il commence avec de quelques conseils pour démarrer avec Git :

• Tout d’abord configurer son identité dans Git : mettre son nom et son adresse mail qui apparaîtront dans les commits

git config --global user.name "Florian Boulay"
git config --global user.email "florian.b@mail.com"

• Utiliser le projet gitignore afin de configurer les fichiers ignorés par Git
• Utiliser des alias sur les commandes usuelles ou longues.

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

• Utiliser git prompt afin d’avoir un shell donnant beaucoup d’informations utiles. Plus d’infos sur gitfr
• Utiliser la complétion automatique des commandes

La complexité de Git n’est qu’apparente. Git possède 145 commandes, dont 37 porcelain. Au quotidien, Sébastien en utilise 18. Cela réduit considérablement l’image de la difficulté supposée de Git.

Git est en moyenne plus rapide que Subversion, et ce même sur des commandes distantes. Par exemple un git clone est en moyenne plus rapide qu’un svn checkout.

En parlant de la commande checkout, elle permet pour Git de se déplacer sur le graphe. On peut donc potentiellement faire un commit sur n’importe quelle version d’un fichier. Cependant Git va considérer qu’un commit qui n’est pas fait sur une référence de type branche sera perdu. Cela signifie que le gc pourra supprimer ces références. Cela s’appelle un detached head.

L’index

Git fournit un espace dans lequel l’utilisateur peut mettre les fichiers qu’il souhaite ajouter au commit qui interviendra plus tard. Cet espace se nomme l’index (ou staging area). Ce concept paraît inutile au premier abord, mais Sébastien nous certifie qu’une fois que nous avons pris l’habitude d’utiliser l’index, il est presque impossible de réutiliser un VCS n’en possédant pas. L’index permet de préparer le commit que nous souhaitons faire en y ajoutant les fichiers progressivement une fois le travail effectué sur chacun.

git stash

Si un utilisateur doit interrompre son travail de manière inopinée, plutôt que de devoir faire un commit d’un travail à moitié fini, Git met à disposition une commande permettant de mettre le travail en cours de côté afin de pouvoir le reprendre plus tard : il s’agit de la commande git stash.
Les git stash sont empilables. De plus, on peut reprendre le travail en le mettant sur une nouvelle branche en faisant git stash branch nouvelleBranche.