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.

Comparatifs de frameworks web à Devoxx 2011

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

The post Devoxx 2011 – Comparatif de performances des frameworks web Java et plus encore … 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.

Mise à jour du 6 décembre 2010 :CloudBees a levé 4 millions de dollars. Plus de détails sur le blog de CloudBees.

Devoxx 2010 s’est tenue toute cette semaine à Anvers. Entre 2 présentations de Brian Goetz, Joshua Bloch ou Mark Reinhold, je suis allé voir quelques personnalités du monde java afin d’en savoir plus sur leur actualité et leurs impressions.

Stephan Janssen

Créateur du BeJUG et de Devoxx. Je suis allé le voir pour avoir quelques détails sur l’organisation d’un tel évènement.

Bonjour Stephan, peux-tu présenter Devoxx à ceux qui ne connaissent pas ?
Devoxx est une conférence annuelle qui est organisée par le Java User Group belge. C’est déjà la neuvième édition. Quelques statistiques : 3000 personnes qui viennent de 40 pays, et cela dure 5 jours à Anvers dans le deuxième plus grand complexe de cinéma d’Europe.

Comment expliques-tu le succès de Devoxx ?
D’abord le prix qui est vraiment pas cher, moins de 500€ pour 5 jours. On a aussi des rock stars qui viennent ! On a des personnes comme Joshua Bloch, Romain Guy etc. Le lieu aussi avec des écrans géants est vraiment chouette.

Penses-tu que Devoxx se déroulera ailleurs dans un futur proche ?
L’autre endroit possible est le Heysel à Bruxelles, mais le problème est que nous devons créer des salles nous-mêmes, ce qui aurait pour conséquence que le prix de l’entrée doublerait. Je préfère “less is more”.

As-tu eu le temps d’assister à quelques sessions ?
Oui, j’en ai vu quelques sessions. Ca roule bien, mais heureusement on également parleys où toutes les sessions seront diffusées.

Merci
Merci

Sacha Labourey

Après une carrière chez JBoss, Sacha a créé une société CloudBees.

Bonjour Sacha, quelle est la raison de ta venue à Devoxx cette année ?
Manger des sandwichs, et boire des coca zero principalement ! Mais surtout présenter CloudBees, ma société.

Présente nous CloudBees.
CloudBees est une société qui vit dans les nuages, et qui vise à rendre les développeurs à nouveau en contrôle de l’informatique, qui a été trop longtemps volé par ces messieurs de l’IT.
Le désir est de pouvoir faire totalement faire ses développements dans le cloud, ensuite les tests unitaires et le Q&A de manière générale, et ensuite la mise en production. Donc l’unité sur laquelle on se focalise en tant que développeur sera vraiment l’application, on ne se soucie plus du tout de l’IT, on ne soucie plus du tout de virtual machine, de java virutal machine, d’operation system, de storage, de backup, tout ça doit disparaître. On se focalise sur l’application, et nous on fera le reste.

CloudBees est uniquement destiné aux applications java ?
Aujourd’hui on est orienté sur la machine virtuelle java, ça peut être scala, jRuby ou autre chose. Aujourd’hui la majorité utilise java malgré sa mort annoncé jour après jour, c’est quand même un écosystème extrêmement saint et fort, mais rien dans l’infrastructure qu’on est en train de mettre en place en terme de process, en terme de provisionning et autre ne dépend réellement de java. C’est suffisamment générique, mais il faut choisir ses guerres, la notre c’est celle de java pour l’instant.

Pour terminer, quelles sont tes impressions sur Devoxx 2010 ?
J’ai pas encore eu le temps d’aller voir des sessions, mais je retrouve tout à fait l’esprit JavaPolis de l’époque, donc ça se passe très bien, et on est à peine mieux respecté qu’à JavaOne donc ça fait toujours plaisir.

Merci beaucoup Sacha.
Merci !

Nicolas Leroux

Nicolas est expatrié aux Pays-Bas où il travaille en tant que développeur pour la société Lunatech. Il est également un des contributeurs les plus actifs du framework Play!. C’est à ce titre que je suis allé le voir.

Bonjour Nicolas, quelle est la raison de ta venue à Devoxx cette année ?
Pour voir les conférences, faire du networking et aussi pour promouvoir Play! bien sûr.

Il n’y a pas de session sur Play! cette année, en avez-vous proposé une ?
Nous avions proposé une vraie session Play!, pas dans le BoF. Vue la concurrence acharnée qu’il y a à Devoxx, on a été refusé, c’est pas grave, l’année prochaine on réessaiera.

Play! 1.1 est sorti il y a un peu moins d’un mois, quelles sont les prochaines étapes ?
Il y en a beaucoup ! Il y a plusieurs axes de travail. Guillaume Bort est en train de travailler sur une partie qui s’appelle Evolution, qui permet de migrer ses bases de données très facilement.
Personnellement, quand j’ai cinq minutes, je travaille sur un meilleur binding entre JSON et java. Après il a plein d’autres choses à faire. Ce que j’aimerais faire, c’est un conteneur pour JBoss.
Comme c’est actuellement le cas pour Glassfish.
Erwan Loisant est train d’améliorer les librairies clientes pour faire des requêtes à des web services et Peter Hilton travaille sur la documentation

Y a-t-il une roadmap pour la version 1.2 ?
Elle est pas encore définitive, mais la roadmap peut être consultée sur le site playframework.org qui a un lien sur le bug tracker qui est Lighthouse, et là on peut voir la roadmap.

Merci Nicolas, à l’année prochaine pour une session officielle de Play!
Ou alors si vous avez l’occasion d’aller à Paris pour voir Zenexity, c’est des petits gars sympas et ils vous expliqueront tout !

The post Devoxx 2010, vu de l’intérieur first appeared on In Fine - Le Blog.