insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

mardi 18 mai 2010

Créer sa première extension Chrome

Lors du Bof d'avril 2010, nos équipes ont pu voir de leur propres yeux la rapidité avec laquelle il est possible de créer, installer, débugguer une extension à destination du navigateur Chrome.
En effet, à l'instar de Firefox, le navigateur de Google possède des api simples d'accès pour réaliser des extensions.

Nous allons voir tout au long de ce post comment faire pour créer une extension Chrome en partant de presque rien. 

Avant de plonger dans la partie technique il est nécessaire de bien définir ce que représente une extension pour Chrome. Une extension est vue dans son intégralité comme un onglet de navigation ce qui implique qu'il possède son propre processus système, les extensions ne font en définitive qu'exécuter du code Web (Javascript, Html et CSS) en proposant quelques API supplémentaires permettant des manipulations spécifiques au navigateur (comme la possibilité d'ajouter une vignette à une icône d'extension).

Intéressons-nous maintenant à notre objectif du jour. Le but de notre première extension sera de permettre de visualiser le statut des builds d'un serveur Hudson, serveur qui propose nativement des API Json et XML permettant de consulter son état. Par manque d'imagination et par soucis de rapidité nous donnerons à cette extension le nom barbare de Chrudson.

Une extension Chrome se présente sous la forme d'une archive (signée ou non) qui doit inclure un descripteur d'extension au format json. Ce fichier se nomme dans le jargon "chromien" le Manifest.
Voici à quoi pourrait ressembler notre premier manifest.json

{
  "name": "Chrudson",
  "version": "1.0",
  "description": "Gestion d'un serveur hudson depuis chrome",
  "permissions": ["http://*/*","https://*/*"]
}
Comme on le voit rapidement, il est possible de nommer, versionner, et décrire succintement son extension. Bien que notre extension n'ait aucun lien direct avec Maven, nous l'autorisons à faire des requêtes sur l'internet tout entier grâce à la ligne :

  "permissions": ["http://*/*","https://*/*"]

Une fois ce manifest écrit il est d'ores et déjà possible de l'installer sur un navigateur Chrome en utilisant pour cela le navigateur lui-même en passant par le panneau des extensions et en ouvrant le mode développeur. L'extension peut être chargée soit empaquetée (directement en la glissant dans le navigateur), soit directement depuis un dossier local (ce que nous utilisons en développement).

Outre le fichier manisfest, une extension chrome peut aussi se composer d'autres modules "actifs" comme une tâche de fond ou background_page (service venant alimenter les données locales ou mettre à jour l'état de l'extension), d'une page d'options ou options_page (page permettant de configurer l'extension) et enfin soit d'une action navigateur ou popup, soit d'une action de page ou page_action (icone cliquable ajoutée à la barre d'adresse, ex : icône rss).

Options_page


Cette partie de l'extension est disponible lorque l'utilisateur clique sur "options" dans le menu déroulant disponible sur l'icône d'extension.
Pour Chrudson, cette page permet de renseigner l'URL du serveur qui sera surveillée par l'extension. Une page d'options simplifiée de Chrudson ressemble à ceci :

<html>
    <head><title>Chrudson Options</title>
    <script type="text/javascript">

    // Saves options to localStorage.
    function save_options() {
      var url = document.getElementById("url");
      localStorage["hudson_url"] = url.value;
      // Update status to let user know options were saved.
      var status = document.getElementById("status");
      status.innerHTML = "Options Saved.";
      setTimeout(function() { status.innerHTML = "";}, 750);
    }

    //Restores select box state to saved value from localStorage.
    function restore_options() {
      var url = localStorage["hudson_url"];
      document.getElementById("url").value = url;
    }
    </script>
</head>
<body onload="restore_options()">
    Url :<input type="text" id="url">
    <button onclick="save_options()">Save</button>
    <span id="status"></span>
    </body>
</html>

On peut remarquer qu'il est possible de stoquer localement des données via la table localStorage, cette table étant accessible par toutes les parties javascript de l'extension. Tout comme une page web, l'évènement onload de la balise <body> est levé chaque fois que l'utilisateur affiche la page des options.

Pour définir cette page comme la page d'options il suffit d'ajouter la description suivante au manifest.json précédent : 

"options_page":"options.html"

Background_page


Ce module de l'extension va permettre à Chrudson de scruter à intervalles régulier l'état du serveur Hudson précédemment configuré dans la page d'options. Pour des raisons de synthèse, le code n'est pas au complet dans ce post. Quelques morceaux de cette page sont cependant intéressant

var pollInterval = DEFAULT_POLL_INTERVAL;
function onLoad() {
    chrome.browserAction.setTitle({title :"Hudson " + getHudsonUrl()});
    if(localStorage["poll_frequency"]){
        pollInterval = localStorage["poll_frequency"];
    }
    startRequest();
}

Cette fonction, exécutée au chargement de l'extension met à jour le tooltip disponible sur l'icône d'extension. Le localStorage est une fois de plus utilisé pour récupérer la fréquence de rafraîchissment des pages (fréquence que l'utilisateur pourra changer dans une version plus évoluée de notre page d'options). Dans notre exemple, cette valeur n'est jamais renseignée, la valeur par défaut est donc utilisée.

La tâche de fond peut aussi utiliser les APIs plus spécifiques aux extensions Chrome:

function setStatus(text, color) {
    chrome.browserAction.setBadgeText({text :text});
    chrome.browserAction.setBadgeBackgroundColor({color :color});
}

La fonction setStatus permet de changer l'état de l'icône de l'extension en lui affectant un badge de couleur à la manière de ce qui peut se trouver sur les iPhones (limité à quelques caractères).

Une fois la page html/javascript crée, il suffit de rajouter la ligne suivante au manifest.json pour s'assurer de le déclencher à chaque lancement du navigateur :

"background_page":"background.html"

Browser_action


L'icône d'extension à laquelle fait référence la background_page est définit par ce que l'on appelle une Browser_action. Cette page permettra lors d'un clic utilisateur sur l'icône de l'extension d'afficher une fenêtre qui contient en fait la page html définie comme popup pour la browser_action.

Pour cela il suffit d'ajouter la description de la browser_action au désormais bien connu manifest.json

"browser_action": { 
   "default_icon": "butler.png",
   "popup": "popup.html"
}

Dans notre cas, le fichier popup.html simplifé ressemble au code suivant :

<html>
<head>
<title>Chrudson Popup</title>
<script type="text/javascript">
    ...
    function onLoad() {
        url = localStorage["hudson_url"];
        titleDiv = document.getElementById("title");
        titleDiv.innerText = "Status hudson ("+url+")";
        statusDiv = document.getElementById("status");
        statusDiv.innerText = "loading";
        refreshStatus();
    }

    function refreshStatus(){
        var xmlUrl = url+"api/json";
        updateReq = new XMLHttpRequest();
        updateReq.open("GET",xmlUrl,true);
        updateReq.onload = parseResult;
        updateReq.send(null);
    }
    function parseResult(){...}
    ...

    function onClick(url){
        return function(){open_tab(url)};
    }

    function open_tab(url){
        chrome.tabs.create({"url": url});
    }
</script>
</head>
<body onload="onLoad();" class="status">
    <div id="title" class="title"/>
    <span id="status"/>
</body>
</html>

Il se contente d'afficher l'état des jobs listés sur le serveur dans des éléments HTML simples. Ces éléments peuvent être enrichis de styles CSS 3. On peut signaler dans ce code la possibilité d'ouvrir de nouveaux onglets Chrome lors d'un clic souris sur le nom d'un job par exemple. Il est cependant nécessaire de compléter les autorisations données à l'extension dans le fichier manifest comme suit :

"permissions": ["http://*/*","https://*/*","tabs"]

C'est bien beau tout ça ...


Tout ce qui nous avons vu jusqu'à présent montre à quel point il est simple de coder, installer et utiliser rapidement une extension. Cependant, que se passe-t-il lorsque l'un des traitements javascripts foire lamentablement, ou que certains styles CSS présentent finalement des problèmes d'alignement ? 

L'une des forces de Chrome sur ce point réside dans la possibilité d'inspecter dynamiquement chacune des parties de l'extension (background, options et popup) directement dans le navigateur. 
En effet, un lien d'inspection du background est disponible dans le menu des extensions, la page d'options est quant à elle inspectable comme n'importe qu'elle autre page Web, et la popup peut être inspectée en effectuant un clic-droit->inspecter sur l'icône de l'extension comme le montre la capture d'écran suivante (réalisée sous chrome 6.0.401.1) 



Le wrapping GWT


L'une des extensions les plus réussie de Chrome, livrée avec GWT 2.0, s'appelle Speed Tracer. Cette extension a été codée en grande partie avec le Framework GWT. Pour cela, les développeurs ont réalisé une implémentation partielle des API d'extension chrome pour GWT. Si vous êtes un fervent admirateur de GWT ou simplement un petit curieux, je vous invite à explorer le code par vous même pour vous faire une idée de la puissance de l'engin (l'implémentation des api d'extension se trouve dans le package com.google.gwt.chrome.crx.*). 
Cette variation d'utilisation du Google Web Toolkit sera d'ailleurs abordée au Google I/O cette semaine http://code.google.com/events/io/2010/sessions/gwt-linkers-webworkers-extensions.html

Vous savez maintenant tout ce qu'il faut savoir pour coder votre première extension chrome, vous savez aussi qu'il sera bientôt possible de coder des extensions avec GWT de manière encore plus intuitive pour les Java-istes qui lisent ce post.

Ressources 

SpeedTracer  http://code.google.com/p/speedtracer/
Guide & APIs  http://code.google.com/chrome/extensions/devguide.html
Projet Git d'où nos exemples sont librement inspirés http://github.com/sanitz/hudson-chrome-extension

vendredi 15 janvier 2010

Evénement : Conférence "Jump Camp 4 IT" jeudi 21 janvier à 19h

Jeudi prochain aura lieu le premier opus du Jump Camp 4 IT.

Alors Jump Camp 4 IT, c'est quoi ?

Jump Camp 4 IT est une mini conférence en soirée sur Paris mêlant présentations et ateliers de coding, destinés aux passionnés des technologies de l'information.
Ainsi, ce qui est intéressant dans ce format, c'est que cela vous permet de mettre un premier pied à l'étrier sur le framework présenté, et non pas juste d'écouter une présentation théorique. Il est donc conseillé de venir avec son ordinateur portable pour profiter pleinement des présentations ;)

Ah, et petit détail qui ravira tout le monde : c'est gratuit.

Le premier opus de la série aura lieu jeudi prochain, soit le 21 janvier, de 19h à 21h.
Au programme, 6 présentations/séances de coding live autour des dernières technologies/tendances web du moment :

  • Surprise... : une présentation/annonce surprise par Didier Girard
  • Atmosphere :  un framework permettant de faire des applications web asynchrones (Comet) à partir de simples POJO (https://atmosphere.dev.java.net)
  • HTML5 : découverte de html5 step by step
  • Robots Wave et le WadRobotFramework : un framework qui simplifie énormément la création de robots pour Google Wave (http://goo.gl/6pOC)
  • Sisyphe version GWT : une interface à refaire ? reprogrammer ? Non, utilisez dès maintenant sisyphe.
  •  gwt-mvc : Framework pour GWT permettant de structurer le code client en suivant le design pattern MVC (http://code.google.com/p/gwt-mvc/

Si vous souhaitez vous inscrire, connaître le lieu exact de la conférence, ou avoir plus de détails sur les présentations, c'est par ici.

vendredi 18 décembre 2009

La communication, entre efficacité et complétude : L'échelle d'humanité

Communiquer pour le projet.

Dans des projets où parfois les acteurs sont distants, la communication est un facteur déterminant de succès ou d'échec. C'est même l'élément essentiel du projet. Mais de quelle communication parle-t-on ? Dans le cadre d'un projet, la communication doit couvrir :

  1. La Connaissance.
  2. Les Statuts.
  3. Le Ressenti.


Le formel et l'informel

Le DDD introduit la notion d'Ubiquitous Language, ce langage défini et partagé par les différents acteurs du projet. Je voudrais ici mettre l'accent sur l'optimisation des échanges. Comment fait-on pour être sûr que l'information est bien partagée, qu'elle l'est dans son entier et qu'elle l'est à temps ? Sachant que dans la communication, il y a des données intangibles, certes, mais aussi des données informelles où rentre le subjectif, le ressenti. Le daily scrum permet d'échanger cette seconde catégorie d'information. Et c'est indispensable. Par exemple, si on ne communique pas, on ne perçoit pas les frustrations à temps et on se retrouve face à des problèmes de turn-over.


L'acteur et son texte

Vous préférez voir un film ou lire son scénario ?

On est tous d'accord pour dire qu'un projet n'irait pas très loin si les gens se contentaient d'en discuter autour d'un café, sans jamais échanger autre chose que des impressions, des bons mots et des généralités. Mais à l'inverse, parieriez-vous sur l'avenir d'un projet, où les acteurs ne se voient jamais mais s'envoient des tonnes de fichiers Word ? Personnellement, je n'y mettrais pas un Euro.

La communication informelle, qui profite de la complicité s'installant entre l'émetteur d'une information et ceux auxquels elle s'adresse, passe par le visuel et l'auditif. Il y faut un peu de spectacle, pour que l'essentiel soit retenu. On parle alors du Body Language, on y retrouve les notions d'empathie, de synchronisation. Je préfère dix fois aller voir David Chappell dans sa présentation sur Azure et sur le Cloud, que lire son livre-blanc sur le même sujet. Je préfère aussi traverser le bâtiment, et aller échanger avec un collègue, de vive voix, plutôt que d'attendre sa réponse à mon mail. Pas un leader, aussi bon soit-il, ne fera passer sa vision dans un mail, un article, une news. Ce sont de bons supports, pour tracer et conserver mais ce ne sont que des supports. Et la communication sans le communiquant, c'est un peu le plat sans le cuisinier. C'est du Picard. Ce n'est pas forcément mauvais mais servi comme ça, c'est froid.


Entre trop et trop peu

Il y a quelque chose qui ressort de l'observation des échanges entre personnes, c'est la relative proportion inverse entre la quantité de données échangées et la perception qui en est faite. Si je vous dis : "Le projet est mort". Le message est clair, on aura tous compris qu'on peut rentrer à la maison. Si je vous envoie un document de 758 pages de diagrammes, de tableaux, de bilans, d'analyses d'experts et si dans un élan de professionnalisme rare, vous allez jusqu'à le lire, n'allons pas jusqu'à dire "en entier", vous en sortirez confus, désorienté, partagé, vous demandant si on a juste essayé de vous beurrer les lunettes ou si votre intelligence commence déjà à décliner. Voyez, rien que cette phrase. Il vous a fallu la lire deux fois, non ?


L'échelle d'humanité

Partant du constat de cette proportion inverse, je me suis amusé à essayer de situer sur un rapport entre la quantité de données échangée et leur perception, les différents médias utilisables dans le cadre d'un projet. Et voici de que ça donne :

HumanityScale

Reprenons le diagramme, dans l'ordre de lecture.

  • Le face à face a le meilleur degré de perception possible, de partage, avec un volume utile d'informations limité.
  • Le live-meeting (écran et web-cam interposés) perd juste un peu d'humanité.
  • Le téléphone est un peu en retrait car on perd l'information visuelle donc une bonne part de la communication informelle.
  • Le chat (IM) permet d'échanger plus de données puisqu'il est écrit, tout en restant "dans la discussion" donc de garder un fort aspect humain. Il offre aussi un bon équilibre entre rapidité et pertinence dans la réponse.
  • Le mail est plus factuel, il prend note, il prend date, il permet de tracer la transmission. Mais il perd en spontanéité. Il devrait être réservé soit à des réponses plus construites ou pour les aspects intentionnellement plus formels ou officiels, souvent nominatifs, comme un bon rappel à l'ordre ou une félicitation.
  • Le blog et son flux RSS restent vivants, tout en fournissant un somme importante d'informations actuelles, à jour. Ce sera le pouls du projet. Il peuvent donner l'état des builds, les infos générales de la vie du projet, ses grandes étapes, événements ou incidents.
  • Le Wiki, outil essentiel de tout projet, devrait contenir l'ensemble des informations du projet. Et comme il est collaboratif, il garde aussi un aspect humain encore perceptible. Il décrira les pratiques et les procédures du projet. Il garde en somme tous les sujets statiques du projet quand le Blog reçoit les sujets dynamiques.
  • La documentation classique elle, est au maximum pour le volume de données mais c'est le degré zéro de l'échange humain.


J'ai omis à dessein deux outils, pourtant très prometteurs, même au niveau projet, que sont Wave et Twitter. La raison est simple, je n'ai encore aucune idée de l'endroit où les placer. Mais je ferais une petite piqure de rappel, quand j'aurai soigné cet aspect de communication virale.


Voulez-vous réussir ?

Alors, lequel de ces médias utiliser ? Si vous voulez vraiment que votre projet avance, vous n'avez pas le choix, il-vous-les-faut-tous !

Chaque média a son objectif et son cycle de vie, chacun doit avoir son cadre d'utilisation et ses limites établies. Certains sont là pour aider à s'y retrouver, d'autres favorisent l'esprit d'équipe, d'autres encore permettent de guider la troupe. Vous voulez prendre le risque de vous passer de l'un de ces médias ?
Préférez-vous alors :

  1. Que les gens soient perdus ?
  2. Qu'ils se détestent ?
  3. Ou qu'ils ne sachent juste pas où aller ?

Un camionneur peut se passer de cartes, de CB (l'éméteur radio, pas le moyen de paiement) et de GPS. Mais entre nous, c'est une économie de courte vue ! Aujourd'hui, on a tous les outils pour organiser et optimiser un flux d'informations efficientes. Et là où certains y voient des gadgets, osons y voir le panel d'outils indispensables et sinon une garantie de succès, en tout cas des alliés sûrs et fidèles sur la route qui y mène.


Think Big, Start Small

En supposant que vous avez le téléphone et un ordinateur relié au réseau (sic), installer un wiki prend 5 minutes, un blog 5 de plus. S'abonner à un flux RSS prend 30 secondes. Installer un outil de Chat prend bien 10 minutes. Alors mis bout à bout, tout ça prend donc 20 minutes et 30 secondes. Ce qui est plus long, c'est le temps d'adoption par tous les acteurs des outils et de leurs avantages. Il y en a bien encore aujourd'hui qui résistent au téléphone portable ! Faites-vous l'évangéliste de vos outils. Les convertis seront nombreux.

Bien sûr, il faudra éviter la redondance, qui est source d'incohérence. Par exemple entre la documentation classique et le Wiki projet. Mais une fois encore, ces deux médias ne visant pas les mêmes acteurs, ils ne devraient pas contenir les mêmes informations et ce, de façon naturelle. Et puis la redondance, c'est déjà un problème de riche. J'ai l'impression de conseiller à un acheteur de bateau, de faire attention à la taille du mât pour passer sous les ponts ou que le bateau ne soit pas trop grand pour entrer dans le port, quand ce qu'il veut, c'est traverser la rivière. Il sera toujours temps quand les outils seront là et utilisés, de veiller à ne pas trop les utiliser (sic).

Et puis il ne faut pas hésiter à faire "signer" une charte de bon usage des médias de communications, pour mettre d'accord tout le monde sur le périmètre de chaque média, ce qui peut y être échangé, ce qui ne le peut pas. Ne cherchez pas trop, elle est juste au dessus.

Je ne sais pas si on est déjà dans le Web 4.0 ou encore dans le Web 3.0 mais ce que je sais, c'est que les outils du Web 2.0 peuvent vous aider dans vos projets. Alors, prêts à communiquer ?

samedi 28 novembre 2009

Vidéo de présentation de la conférence pour le Web organisée par GET (Efrei)

Nous en avons déjà parlé sur ce blog.
Voici la vidéo très réussie pour présenter cette conférence :
Au programme :
  • Android : par Ludovic Perrier
  • GWT/Google Wave : par Didier Girard
  • Standard du Web : par Patrick Chanezon
  • Cocktail à 17h00
  • Atelier Android par le GTUG (Google Technologie User Group) à partir de 19h30
Inscrivez-vous sur le sur g-e-t.fr.

mercredi 18 novembre 2009

Flash Catalyst

  • Flex est un framework open source pour créer des applications web riches
  • Flash builder : Plugin eclipse pour construire des applications flex
  • Flash Catalyst : Logiciel pour faire le lien entre le designer et le developpeur flex.

Flash Player 10 est maintenant présent sur 93,5% des ordinateurs connectés dans le monde, en seulement 10 mois après sa sortie, et est disponible sur tous les navigateurs et systèmes d'exploitation.

Il possède une large communauté en s'ouvrant à elle de plus en plus (les spécifications FLV, SWF, AMF, RTMP sont ainsi disponibles).

Flex :

  • MXML : interface
  • Action Script 3 : code

Compilé en un fichier .SWF et exécuté par le Flash player ou packagé dans un fichier AIR et exécuté sur l'ordinateur.

Jusque-là, le designer visuel (qui utilise Photoshop et Illustrator) et le designer d'interactions (Flash) envoyaient leurs fichiers aux developpeurs qui s'occupaient d'intégrer tant bien que mal le tout dans l'application.

Flash Catalyst permet une interaction directe entre le designer graphique et le designer d'interaction mais aussi avec l'utilisateur qui peut tester le prototype et enfin le developpeur qui peut alors importer et utiliser tout ce travail directement dans Flash Builder.

Flash Catalyst permet de faire des interfaces en wireframes pour rapidement valider l'organisation d'une application. Des fonctionnalités de base pour dessiner des formes sont possibles mais le plus important est peut-être le fait de pouvoir créer les différents états (ou pages) de notre application et définir simplement les actions basiques possibles (clique sur un bouton et changement de page). Il est aussi possible de définir les effets entre les états de l'application.

Ce qui est vraiment le plus impressionnant est le moment où l'on importe un fichier photoshop (ou illustrator) créé par le graphiste qui contient alors tous les visuels de l'application dans des calques ou des éléments différents. Il suffit alors de sélectionner le cadre et le texte qui représente un champ de saisie pour indiquer à Flash Catalyst de le transformer en TextBox Flex qui prendra alors l'apparance définie par le graphiste.

On peut ensuite créer un composant personnalisé qui pourra être réutilisé dans une autre application.

Une fois l'interface définie, on peut directement prévisualiser le rendu directement dans le flash player.

Une fois la partie de design et d'intégration terminée, il suffit alors de générer un projet flex. En ouvrant le projet avec Flash Builder, on y retrouve tous les composants créés, mais aussi les images et tout ce qu'il faut pour faire fonctionner le projet. Une nouveauté dans Flash builder, la possibilité de configurer simplement l'accès aux données via de nombreux services (blazeDS, PHP, HTTP, etc.), des assistants nous permettent d'afficher les services disponibles sur le serveur et de les plugger aux composants de l'interface.

La démonstration est vraiment convainquante. 

lundi 16 novembre 2009

Soirée Google Des Paris JUG

Android

AndroidCette soirée Google commence tout d'abord avec une présentation d'Android proposée par deux consultants d'Oxiane, Gabriel Kastenbaum et Stéphane Liétard. Les deux conférenciers ont d'abord évoqué les approches historiques et marketing autour des smartphones et d'Android avec quelques rappels :

  • le début des smartphones avec les technologies BlackBerry et ses fonctionnalités pushmail dès 2001-2002, iPhone en 2007,
  • les premiers modèles de smartphones s'appuyant sur Android en 2008,
  • les chiffres publiés par Gartner prévoyant que la plateforme Android prendra la deuxième place en 2012 derrière Symbian de Nokia et légèrement devant iPhone,

Et ont continué avec les aspects plus techniques en rappelant qu'Android est un système d'exploitation pour Smartphones, PDAs et autres terminaux mobiles. Il est basé sur un noyau linux allégé de son gestionnaire de données.Android vient avec sa machine virtuelle, DALVIK VM, spécialement conçue pour les systèmes embarqués ayant peu de ressources.

DALVIK offre la possibilité d'écrire des applications pour Android en Java. Les classes compilées sont transformées en .DEX et non en .CLASS (bytecode pour JVM classique). Ce format est spécialisé pour la DALVIK VM et est optimisé pour un terminal mobile. Aussi, l'ensemble des classes du JRE classique n'est pas supporté, mais l'essentiel y est.

Développer avec Android peut se faire simplement en récupérant le SDK Android et le plugin Eclipse associé. Toute application Android est définie dans un fichiers (android manifest) au format XML.

Une application sur Android est composée d'un ou plusieurs composants qui sont de 4 types:

  • Activity : Un écran de l'application,
  • Service : Un service qui tourne en tâche de fond,
  • Content Provider : Un fournisseur de contenus (souvent une base de données SQLite),
  • Broadcast Receiver : Réception d'un événement envoyé à toutes les applications (niveau de la batterie, réseaux, appel, sms, etc.).

Une application peut appeler un composant d'une autre application (exemple : ouvrir une page du navigateur ou la configuration du système), lancer un service d'une autre application, ou accéder aux données d'une autre application (exemple : accéder aux contacts).

Pour relier les composants entre eux, on passe par la notion d' "intent" qui encapsule les actions et données échangées. C'est ensuite Android qui s'occupe de trouver l'application à lancer pour l'Intent donné, il utilise pour cela le fichier android manifest où tous les composants de l'application sont enregistrés.

Et enfin, on a eu droit à une petite démonstration avec une application Android présentant une page et un bouton qui, en l'actionnant, affiche une autre application.

Pour plus d'infos : http://developer.android.com/index.html

Google App Engine, Groovy and Gaeylik

Google App Engine GroovyLa soirée continue avec la conférence Google App Engine proposée par Marc-Antoine Garrigue et Gaël Lazzari d'OCTO et Guillaume Laforge de Spring Source

Guillaume Laforge a commencé par la présentation de AppEngine en rappelant que c'est la Plateform as a Service (PaaS) de Google où on peut héberger ses application et y accéder via URLs. Google propose à l'application "hébergée" des APIs et fonctionnalités qui permettent de gérer le cache, email, XMPP, Cron, etc.

Les principales limitations de la plateforme sont :

  • pas de base relationnelle,
  • la durée d'une requête est limitée à 30 secondes,
  • le système de fichier est en lecture seule,
  • impossibilité d'utiliser des Threads,
  • pas de sockets natif,
  • certaines classes de l'API Java ne sont pas autorisées,
  • taille de fichier est limitée.

Les services de la plateforme App Engine sont gratuits jusqu'à un certain seuil. Les quotas au-delà desquels les services deviennent payants sont assez larges. Ils concernent le volume de données échangées, le nombre de requêtes, etc. Une interface d'administration permet de gérer les applications déployées, et via un tableau de bord de visualiser les statistiques et le graphe d'activités. Pas de base de données relationnelle classique pour la persistance de données mais une sorte de Hashtable/Bigtable. Par contre sur cette structure, Google propose des abstractions permettant d'utiliser JPA/JDO pour la persistance de données. Avec ce gestionnaire de données, le nombre d'occurrences retournées par une requête est limité à 1000. Il n'y a pas de support de transaction ni de possibilité de lancer des requêtes de type JOIN ou CONSTRAINT. En revanche on peut bénéficier des "facilités" permettant de gérer des entités hétérogènes de l'application dans une même structure de données.

Par la suite Marc-Antoine Garrigue et Gaël Lazzari ont présenté Groovy et Gaelyk. Groovy, langage dynamique basé sur Java, à présent peut fonctionner avec App Engine. Pour arriver à cette compatibilité, Groovy a modifié quelques lignes de codes après un travail en commun avec Google. Avec Groovy on peut faire des composants qui ressemblent à des servlets, les Groovlets ainsi que des pages Groovy Template Servlet.

Gaelyk, le Framework/boite à outils facilite le développement avec Groovy et aide le développeur à interagir plus facilement avec App Engine. L'application de démonstration FetchFeeds est plus qu'une simple application. Proposée en open source sous licence Apache, elle utilise bien sûr les technologies App Engine, Groovy et Gaelyk. Elle montre de plus comment implémenter les mécanismes subtils permettant de réduire l'utilisation de ressources et donc comment ne pas dépasser trop vite les quotas imposés par App Engine.

http://groovy.codehaus.org

http://gaelyk.appspot.com

Google Wave pour les développeurs

Google WaveAprès le buffet sympathique et classique des conférences Paris JUG, nous remontons de nouveau les quelques escaliers I.S.E.P qui nous mènent à la salle de conférence pour suivre la dernière conférence de la soirée.

Didier Girard le Directeur des Opérations et de l'innovation de SFEIR, et Salvador Diaz, consultant spécialisé dans les technologies Google, nous présentent le tout dernier outil collaboratif de Google, Google Wave.

À en croire les sondages à mains levées, la grande majorité des participants présents dans la salle développe en Java, a déjà développé en GWT et pour certains sur Android et beaucoup possèdent déjà un compte Wave !

La présentation débute par une revue des principales fonctionnalités de Wave suivi d'une série de démonstrations.

Google Wave est généralement présenté comme une plateforme de communication faisant la synthèse de messagerie instantanée, d'email et de wiki avec donc la possibilité de partager un même espace entre plusieurs intervenants, drag & droper des photos ou partager des données pendant une conversation, etc. Cet outil collaboratif est développé en GWT et apporte deux principales innovations qui sont la possibilité de créer et de déposer des gadgets dans une Wave et la possibilité de développer des Robots (Goldorak pour les intimes !), une sorte de servlet qui collabore à sa façon aux conversations.

En effet, un Robot est un automate que l'on fait participer à une Wave. Il peut se comporter comme n'importe quel autre participant et dès lors il peut modifier le contenu de la Wave, ajouter des participants, etc. Les Robots supportés par Wave sont déployés sur Google App Engine et communiquent en HTTP et peuvent être indifféremment écrits en Python ou en Java. En déployant un Robot sur AppEngine, Google crée implicitement une url de type http://application.appspot.com que wave va appeler pour le robot qui aura alors comme adresse mail : application@appspot.com. Pour illustrer les possibilités que Wave offre aux développeurs, Salvador et Didier ont proposé de nous faire trois démonstrations.

La première démonstration nous montre comment créer un gadget, le déployer sur App Engine et l'ajouter à une Wave. Il suffit de récupérer un wrapper, étendre un gadget et lui donner un titre. Le gadget créé dans la démonstration, n'est autre que le logo de Paris JUG qui se déplace dans tous les sens sur l'écran. Un simple copier/coller de l'url suffira pour l'ajouter à une Wave. Les autres invités de la Wave pourront dès lors le voir et interagir avec.

La deuxième démonstration consiste à créer un Robot qui va participer à une chaine de transmission et de traitement de SMS qui utilise les technologies Android, AppEngine, GWT et enfin Wave. Le jeu consiste à faire un sondage via SMS avec la salle sur la présence des participants à un prochain événement Paris JUG. Les participants envoient un SMS à un téléphone Android, le téléphone possède une application qui réceptionne tous les SMS du téléphone pour les envoyer sur un serveur AppEngine. Enfin, un gadget écrit en GWT et ajouté sur une wave va interroger régulièrement AppEngine pour afficher les SMS. Le Robot développé pour la démonstration est déployé sur App Engine. Pour recevoir le messge, il est abonné aux événements de la wave (modification d'un message, ajout d'un participant, etc.), s'il détecte une commande particulière (SEND(message;téléphone)), il va former le message que l'application Android vient scruter et envoyer en SMS. La salle participe activement en envoyant des SMS que l'on voit défiler avec les chiffres consolidés dans la "boite" Wave de nos deux conférenciers.

La troisième et dernière démonstration nous montre un exemple d'utilisation de Wave en entreprise. Il s'agit d'un outil collaboratif léger à base de gadgets de prise de congés. Le demandeur de congés rajoute les gadgets dans sa Wave et renseigne les jours demandés. Il invite ensuite son responsable et dès lors un mini workflow de prise de congés s'engage via le Wave entre le demandeur et le responsable qui doit valider la demande.

Ces trois démonstrations et l'explication de code qui a suivi, ont montré aux participants comment Wave peut se placer au sein des technologies Google et comment on peut assez simplement et sans besoin d'infrastructure complexes, mettre en oeuvre via ces technologies des applications techniquement complexes.

https://services.google.com/fb/forms/wavesignup/

http://code.google.com/intl/fr/apis/wave/

À la fin de la conférence, les Juggers qui le souhaitent peuvent demander leur nouveau compte Wave juste avant de se diriger vers la troisième mi-temps qui promet d'être riche en discussion.

jeudi 2 avril 2009

Fin d'Encarta

encarta2009 La concurrence n’est pas toujours bonne pour tout le monde. Dans le domaine des encyclopédies en ligne, le prix a déterminé la fin du combat. Le gratuit a gagné. Est-ce bien le meilleur qui l’a emporté ? C’est loin d’être aussi sûr. Dans le produit payant, les articles étaient tous vérifiés et a priori fiables. L’information libre triomphe mais elle traine avec elle le pire comme le meilleur.

La vision de Microsoft est que l’information doit être accessible à tous dans le monde: “Chez Microsoft, nous pensons que chaque être humain sur la Terre doit pouvoir accéder à des ressources éducatives de qualité. C’est notre vision”. Microsoft s’adapte comme toujours au monde qui l’entoure. Peut-être un peu plus douloureusement cette fois.

Ils donnent en tout cas raison au modèle gratuit ou libre. Mais c’est tout le paradigme de l’information qui est en cause. A l’heure où le Quid a abandonné sa version papier du fait de la baisse des ventes, les dictionnaires ne font plus recette parce que l’on peut trouver des définitions d’à peu près tout en tapant des termes approximatifs dans des moteurs de recherche pour se faire sa propre idée à partir de données éparses, souvent douteuses et très instables. L’orthographe devient moins importante, la provenance est secondaire, l’exactitude du résultat laissée à la seule appréciation du lecteur. L’opinion prend vite le pas sur la “définition”. Des notions apparaissent au grand jour qui semblaient réservées à des cercles restreints, comme la taxonomie ou l’ontologie et qui risquent vite de servir de camouflage à l’ignorance organisée. Le mot même de “pertinence” doit être pris avec circonspection. Car il n’a pas la même signification selon qu’il s’applique à la définition d’un mot ou au résultat d’une recherche sur le web. Pourtant, n’a-t-on pas déjà mélangé les deux notions ? Et qui aujourd’hui a la culture suffisante pour dire à coup sûr que l’information qu’il lit est “pertinente” ? D’autant plus quand les résultats de recherche se comptent en millions de pages et que celles mises en avant, le sont sur des critères de nombre de visites.

C’est tout le paradoxe du “libre”. En donnant à tous l’accès à l’information mais en permettant à tous d’y contribuer, il la dilue. Et ce faisant il l’affaiblit. Pourtant c’est bien l’information qui donne accès à la liberté : liberté de penser, liberté d’agir en connaissance de cause.

Quand un dictionnaire disparait, c’est un peu de la mémoire du monde qui s’efface. La Culture doit être accessible au plus grand nombre. La question est de savoir de quelle Culture il s’agit.

samedi 28 mars 2009

Chrome experiments, un sacré coup marketing

googleExperiments Google a trouvé un moyen très efficace d’imposer son navigateur. Un petit site très sympa proposant un tas de démos plus impressionnantes les unes que les autres et… nécessitant Chrome bien sûr. En effet elles reposent toutes ou presque sur le HTML 5 Canvas qui n’est pas supporté par tous les navigateurs avec la même fidélité.

Il s’agit ni plus ni moins d’une publicité comparative. Le site est là pour comparer les moteurs javascripts des différents navigateurs et c’est Chrome qui obtient les meilleurs résultats. Bien sûr, le site affiche son affinité. Mais force est de constater l’efficacité de la chose. Et puis c’est quand même plus drôle qu’une série de graphiques comparatifs.

Le site sort le même jour que le nouveau navigateur de Microsoft, IE8. La guerre est ouverte. Alors même qu’elle semble relancée entre Apple et Microsoft. Google tenterait-il d’en profiter ? Quand les arguments entre Mac et PC ne varient pas : “ils sont trop chers” contre “ils nous pillent”. Google apportera-t-il un peu de fraîcheur ? En tout cas on ne va plus savoir où donner de la tête.

Ces arguments semblent avant tout montrer que c’est la crise pour tout le monde. Quand il y avait de la place pour tous, les arguments étaient moins trash. Maintenant, on ne va pas bouder son plaisir, ces petites campagnes de pub comparatives à l’américaine sont assez drôles en général. C’est déjà ça.

On attend avec impatience le match MacOS/Windows 7. Alors, à quand l’OS Google sur PC ?

En tout cas de bons moments de rigolades en perspective (je parle du site bien sûr). Et à tester avec vos enfants bien sûr.

Le site à visiter absolument : http://www.chromeexperiments.com/

mardi 24 mars 2009

Pourquoi Douglas Bowman quitte-t-il Google ?

stop_google Vous ne le connaissez peut-être pas mais vous avez forcément vu ses œuvres. Douglas Bowman est le Visual Design Leader de Google et le fondateur de Stopdesign. Il est entré chez Google il y a trois ans, une opportunité unique, comme il l’avoue lui même. Quelle carte de visite en effet ! Alors pourquoi quitter, au bout de trois ans seulement, une entreprise en plein boom ? Et quelle entreprise. Au delà du simple différend, une coopération de 3 ans ne s’arrête pas pour rien. Trop long pour être une erreur de casting, trop court pour tenir de l’envie de “voir du pays”. Il n’arrête pas Google juste pour reprendre Stopdesign.

Il s’en explique dans un billet, sans amertume mais sans édulcorer la chose. Il semblerait bien que, de son point de vue, Google ne soit pas tout à fait la panacée pour les créatifs. Il faut dire que, passé l’écran d’accueil sur fond blanc, la créa ne parait pas forcément des plus recherchées. Ceci explique peut-être cela : Marissa Mayer (vice president of search products and user experience) centralise le design de Google, ne laissant que peu de marge de manœuvre aux designers de métier. Plus prosaïquement Google ne cherche pas le clinquant, ce qui se comprend vu son business model. Comme elle le dit elle-même “it’s not a party”.

Ce qui ressort du billet, c’est ce qu’il va en regretter. En somme, il va certes regretter l’environnement (personnes, locaux, nourriture gratuite, etc., c’est vrai qu’ils savent y mettre les moyens, quoi jaloux, moi ?) mais pas son métier là-bas : "I won't miss a design philosophy that lives or dies strictly by the sword of data."

Mais peut-on encore parler de design ? Au sens créatif visuel en tout cas. Ce qui ressort surtout du constat, est la main-mise des données sur toute décision prise. Rien n’est laissé au hasard (à l’inspiration ?). Tout découle d’études rigoureuses sur des données. Pas très excitant pour un créatif, on est d’accord. L’épaisseur d’un trait fait l’objet d’âpres discussions et de preuves attendues (comme dans la méthodologie “Split A/B testing”). Cela ressemble à l’aboutissement du rêve de la Business Intelligence : Quand les données sont suffisantes, les décisions ne sont plus nécessaires. L’étude des données suffit à établir le plan de route. Et des données, Google en a. Beaucoup.

Google n’en est plus à la création (visuelle s’entend) mais à l’optimisation permanente. Le poids des pages, la vitesse de chargement sont des facteurs qui passent avant l’apparence.

Comme quoi, malgré une réputation de geeks et de créatifs, ils sont surtout restés mathématiciens (avec les pieds sur terre quoi). "On the Web in general, (creating sites) is much more a design than an art…. You can find small differences and mathematically learn which is right." (M Mayer)

logo32Tout le contraire de chez Apple. En tout cas c’est l’avis de Chris Matyszczyk. Apple selon lui démontre de son côté que l’on peut marier l’ingénierie et le goût. En somme Google s’occupe des formules mathématiques, Apple du feeling. Mais quoi d’étonnant, après tout. On va acheter un Mac parce que c’est beau, sexy, valorisant et faire ses recherches sur Google parce que c’est performant et pas le contraire. Alors si vous êtes designer et que vous cherchez du travail, surtout, ne vous trompez pas de cible. Google n’est pas FaceBook. Google n’est pas Virgin. Google est l’aboutissement d’un rêve d’ingénieurs, un monde mathématisé, en équations, en algorithmes et en téra-octets de données. Un monde minéral ? Non, une projection sur un axe pragmatique. Un outil, mais quel outil. Au fond les vrai créatifs ne sont pas dans le visuel mais dans le fonctionnel (voir leur labs).

L’explication de l’intéressé : http://stopdesign.com/archive/2009/03/20/goodbye-google.html

L'analyse de Stephen Shankland : http://news.cnet.com/8301-17939_109-10201160-2.html

L’avis de Chris Matyszczyk : http://news.cnet.com/8301-17852_3-10201641-71.html

Marissa Mayer dans ses œuvres : http://news.cnet.com/8301-10784_3-9954972-7.html

Une petite bio de Marissa Mayer : http://www.iht.com/articles/2009/03/01/business/01marissa.php

Stopdesign : http://stopdesign.com/

Les Labs : http://labs.google.fr/

Les design guidelines google : http://googlesystem.blogspot.com/2008/03/googles-design-guidelines.html

mercredi 10 décembre 2008

Microsoft exemplaire dans le stockage des données privées

Camera A l'heure des bouleversements de toutes natures, la communication est plus que jamais primordiale pour les entreprises et le ressenti des clients analysé avec la plus grande attention. Il en ressort que le public est plus averti qu'on ne croyait de prime abord. Les clients sont mieux instruits qu'auparavant, moins crédules qu'on imagine souvent et la plupart du temps bien informés. Chaque secteur de l'économie aborde donc aujourd'hui comme une forme de mue dans sa relation clientèle. Les banques par exemple, adoptent de plus en plus le "parler vrai" qui leur faisait défaut, abandonnant l'infantilisation et l'émotionnel ou pire le "réenchantement du monde" qui leur faisait envisager des clients crédules et faciles à berner. L'industrie s'engage dans la lutte contre le changement climatique, elle qui représente 20% des émissions de gaz à effet de serre. Et elle maintient le cap malgré la crise. Ce faisant, elle communique directement ou indirectement sur le sujet, véhiculant à ses clients une nouvelle image plus valorisante, plus responsable. De leur côté, les entreprises du secteur informatique s'intéressent au respect de la vie privée de leur client, lieu de toutes les inquiétudes et de tous les fantasmes. Et dans ce domaine, c'est bien Microsoft qui décroche la palme. En effet, d'après La Tribune du 10 décembre, le géant de Redmond s'apprêterait à passer de 18 à 6 mois la durée de conservation des données privées des internautes (Durée recommandée par le "Groupe article 29"). Là où Google les réduit de moitié, à 9 mois et Yahoo! les conserve 13 mois.

Devoxx 2008 - The future of rich Internet applications

C'est avec intérêt que je rentre dans la salle 4 pour assister à la présentation sur le futur des applications RIA, et je me rends compte d'office que cela va parler de Flex en grande substance.

J'apprends que la communauté de développeurs double chaque année, plutôt bon signe pour Adobe.
Dans un premier temps Chet Haase (ex Sun) nous présente les nouvelles fonctionnalités comprises dans le Player Flash 10, en voici brièvement la description :
  1. Flash Text Engine : permet d'avoir des fonctionnalités similaires à celles de Word, comme la justification, le mutli-colonne, etc ...
  2. Gestion de la 3D : Présentation d'une application 3D nommée Clothes, dans laquelle on a une robe que l'on peut accrocher par des pinces à linge, faire flotter au vent, etc ... C'est beau, bluffant, mais pas très utile
  3. Sound Engine : démonstration des nouvelles capacités sonores
  4. Pixel bender : animation d'images, application de filtres similaires à ceux que l'on connait dans Photoshop.
Sortie de Air 1.5, prenant en compte Flash 10 et l'encryption locale des données.

Le nom de la future version de Flex se nomme Gumbo, voilà c'est dit ...

Chet, pour garder l'attention de son public, manie l'humour en nous montrant la photo de WC avec une mouche collée à l'intérieur, nous expliquant que cela permet de se concentrer lors d'un soulagement. Cette métaphore traduit la volonté d'Adobe de se focaliser pour Gumbo sur Flash Catalyst, qui permet une séparation claire des responsabilités entre les infographistes et les développeurs.

Si ma compréhension fut bonne, avec Flash Catalyst, les infographistes utilisent les outils d'Adobe puis après il sera possible d'en créer un projet Flex qui permettra au développeur de partir et d'intéragir avec les infographistes. Cela m'a fait un peu penser à JavaFX avec le plugin Adobe Illustrator/Photoshop qui génère un projet JavaFX.

Les produits Adobe génèrent des fichiers FXG, incorporables dans Catalyst.

Bien que la présentation soit sexy, amusante, attrayante, je commencais à me dire que ça tournait encore trop autour de fonctionnalités trop 'marketing' et pas assez 'entreprise'.

Je fus rassuré par l'intervention de Matt Chotin, notre Backend developper guy ...
Maat nous annonce qu'Adobe travaille en étroite collaboration avec la société SpringSource, et que l'intégration de Blaze DS avec Spring a été améliorée notamment par l'utilisation de Spring Blaze DS, par exemple il n'est plus nécessaire d'avoir de fichier de configuration web.xml spécifique.
Matt fait une démonstration montrant la facilité de 'cablage' de données via une datasource dans une DataGrid. En effet, après avoir configuré sa DataSource, ce qui va générer le fichier de configuration Spring associé, on obtient la liste des entités disponibles, il suffit donc de glisser cette entité, choisir la méthode (getAll, getByName, etc ...) et de glisser le choix sur la DataGrid et hop ... comme par magie la DataGrid est alimentée ...
Par la suite il fait faire le lien avec une autre DataGrid, pour récupérer la liste des employés d'une compagnie par le nom de celle-ci ... Bon là il faut 'retoucher' le MXML, pour lier les DataProvider entre eux, ceci dit, cela reste très simple pour faire du CRUD.

J'avais déjà fait des POC, et autres maquettes avec Flex, et j'avais bien apprécié le DataBinding qu'il offrait. J'ai bien apprécié cette démonstration, et je vais continuer à suivre les évolutions de Flex version Gumbo ... Reste maintenant à vivre Flex sur un projet d'entreprise digne de ce nom.

mardi 12 août 2008

Revue de presse Web 2.0

UWA : Netvibes lance une API de développement de widgets multi-plateformes

UWA (Universal Widget API) est une API qui permet de développer des widgets pouvant s'éxécuter sur une grande partie des plate-formes Widget actuelles (Netvibes bien sûr, mais aussi iGoogle, Windows Vista, Apple Dashboard, Live.com, iPhone, Opera, MySpace, etc.).
UWA répond ainsi au paradigme "write once, run anywhere" pour les widgets. http://dev.netvibes.com/doc/universal_widget_api


Une BI gratuite... avec Google Docs !

L'éditeur Prelytics lance LiveDashboard 4 Team, un service gratuit de tableaux de bord s'intégrant dans Google Docs. Il est possible de créer soi-même ses tableaux de bord, de les partager, et de travailler de manière collaborative.
Enfin LiveDashboard 4 Team se présente comme une offre de type SaaS.
www.livedashboard4team.org