Concours Orange API

Orange Partner organise un concours des meilleures applications mashup utilisant leurs APIs. On peut y gagner :

• Un « gadget » électronique d’une valeur de 500 Euros
• Un téléphone portable
• Une entrée au Partner Camp qui se déroulera en Floride en décembre 2008 (Mais je n’ai pas l’impresssion qu’ils payent le billet d’avion )

Personnellement je prépare une petite application, j’en ecrirai plus une fois qu’elle sera terminée

Google Developer Day à Paris

Jeudi 18 avait lieu le google developer day à Paris. Petit résumé de la journée.

Accueil

Après avoir montré patte blanche deux fois, on peut enfin entrer dans le hall, un petit déjeûner est offert. C’est entre deux petits fours que je croise Grégory Weinbach d’object Direct.

Une fois bien rassasié je continue le tour du bâtiment pour me diriger vers la salle de repos. Et pour une salle de repos c’est une belle salle de repos ! 4 écrans plats avec des Wii, deux baby-foot, un mikado géant, un domino géant, un puissance 4 géant, un jeu d’échec géant.. rien que ca ! Et le top du top c’est un tas de gros coussins aux couleurs de Google.

Après deux parties de Wii Tennis, il est temps d’assister au discours d’ouverture.

Message d’introduction

Pour démarrer la journée, Patrick Chanezon nous présente très rapidement l’ensemble des outils Google :

• Chrome
• Gears
• App engine
• GWT
• OpenSocial
• Androide

A chaque démo il faut switcher du Mac qui à les slides au PC, car Chrome ne fonctionne que sous Windows . Et en plus de ces petites démonstrations, plusieurs sociétés nous présentent leur produit basé sur des outils Google :

• Mapeed est un outil pour fusionner des marqueurs en fonction du niveau de zoom basé sur Google Maps.
• MYerp.com est comme son nom l’indique un ERP en ligne ecrit avec GWT. 
• Viadeo annonce l’ouverture de ses nouvelles APIs compatible OpenSocial

Par contre la petite démo d’android n’a pas été spectaculaire, l’application « blue dot » est beaucoup moins spectaculaire qu’à Londres où ils avaient un vrai téléphone.

J’ai ensuite choisi de participer au code lab sur App Engine.

Code lab App Engine

App Engine est une solution d’hébergement fiable basé sur le langage python. Et la première question qui nous vient tous à l’esprit est bien sûr : « Pourquoi en Python ?? » Et la l’équipe google nous répond que c’est peut être en lien avec l’arrivée de Guido van Rossum chez eux… Pas très technique comme explication.

Sinon App Engine propose plusieurs briques intéressantes :

• Gestion de l’authentifcation Google
• Gestion d’une base objet
• Api d’envoi de mail

Le Code lab est bien fait, le but est de développer une application wiki avec le kit de dev. Il permet de tester son application en local.

En sortant du bâtiment j’ai même trouvé le scooter d’un Googler

Même si ce code lab était bien fait, je suis resté un peu sur ma faim. J’attendais beaucoup plus d’explications sur la gestion de l’hébergement.

Repas

J’ai profité du repas pour rencontrer Julien Dubois de spring source et Ludovic Toinel de Capgemini qui travaille sur les API Orange Partner. Un moment d’échange très intéressant.

Ensuite j’ai participé à deux sessions sur Gear et Chrome.

Gear

C’est Aaron Boodman qui nous présente Gear. C’est aussi l’occasion de fêter les un an de l’application. Gear offre des fonctionnalités avancées pour les applications web et notamment de pouvoir rendre en partie l’application accessible Offline.

Plusieurs points sont présentés :

Desktop shortcuts

Ca permet d’ajouter un icon sur le bureau pour ouvrir directement l’application Web. Le seul avantage par rapport à un lien http « normal » est de sauvegarder le navigateur utilisé et donc de ne pas simplement d’ouvir l’URL avec celui par défaut (intérêt très limité je trouve…)

Gestionnaire de fichiers

Gear offre une boite de dialogue qui permet d’utiliser des filtres et de sélectionner plusieurs fichiers. Encore mieux il gère une reprise sur erreur au niveau de l’upload de ces fichiers, très pratique en cas de transfert de gros fichiers (utilisé par Youtube bien-sûr)

GeoLoc

Une API de géolocalisation est aussi présente (via un GPS, une cellule GSM ou une IP)

Chrome

Même si le titre de la session était nommée « Google Chrome », c’était plus une présentation du moteur de JavaScripts V8.

D’abord les objectifs de Chrome (très bien illustré dans leur superbe BD) :

• Stabilité
• rapidité
• intuitivité

Kevin Milinkin a fait la présentation la plus technique de la journée. On a même eu droit à un slide montrant le code assembler utilisé.

Déjà pourquoi faire un nouveau moteur de JavaScript ? La réponse est simple, au début des développements de Chrome il y a deux ans, la performance des moteurs Java Script existants n’etaient pas satisfaisante. C’est pour cette raison qu’ils ont lancé la réalisation de V8.

Il nous présente ensuite les clés de la rapidité du moteur :

• Hidden class hidden transition
• Inline caching
• Dynamic Machine Code Generation
• Efficient Garbage Collection

Ces points sont très bien expliqués ici. V8 a aussi acceleré le temps de démarrage de la machine virtuelle en permettant le chargement d’objets en mémoire depuis un SnapShot.

Malheureusement il n’y a toujours pas de date pour la version Mac.

Bilan

Même si je n’ai pas été seduit par le CodeLab, j’ai passé une excellente journée. C’est toujours intéressant d’échanger avec d’autres développeurs.

Fuite de threads dans Jonas

Depuis plusieurs mois nous avions détecté que le nombre de thread de notre serveur jonas augmentait sans arrêt. Un de mes collègues a donc pris le taureau par les cornes pour trouver l’origine du problème. Après 4 jours à fouiller dans le code source de Jonas, il a trouvé le problème au niveau du connecteur Joram (notre application utilise des JMS).

Dans la classe
org.objectweb.joram.client.connector.ManagedConnectionFactoryImpl, on peut lire :

public Set getInvalidConnections(Set connectionSet) throws ResourceException {
  if (AdapterTracing.dbgAdapter.isLoggable(BasicLevel.DEBUG))
    AdapterTracing.dbgAdapter.log(BasicLevel.DEBUG,
       this+" getInvalidConnections("+connectionSet+")");
    Iterator it = connectionSet.iterator();
    ManagedConnectionImpl managedCx;
    while (it.hasNext()) {
      try {
        managedCx = (ManagedConnectionImpl) it.next();
        if (managedCx.isValid())
          connectionSet.remove(managedCx);
        }
      catch (ClassCastException exc) {}
  }
  return connectionSet;
}

Ca met en évidence deux règles de codage Java importantes qui ne sont pas respectées :

1. Ne pas retourner la référence d’un paramètre en valeur de retour
2. Eviter de modifier un paramètre d’une méthode

Depuis que nous avons patché le connecteur Joram, nous n’avons plus de fuite de thread

Le patch :

  public Set getInvalidConnections(Set connectionSet) throws ResourceException {
  if (AdapterTracing.dbgAdapter.isLoggable(BasicLevel.DEBUG))
    AdapterTracing.dbgAdapter.log(BasicLevel.DEBUG,
      this+" getInvalidConnections("+connectionSet+")");
  Iterator it = connectionSet.iterator();
  ManagedConnectionImpl managedCx;
  java.util.HashSet invalidConnections = new java.util.HashSet();
  while (it.hasNext()) {
    try {
      managedCx = (ManagedConnectionImpl) it.next();
      if (!managedCx.isValid())
        invalidConnections.add(managedCx);
    }
    catch (ClassCastException exc) {}
  }
  return invalidConnections;
}