insideIT.fr : le blog des architectes IT de SFEIR

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

Tag - Google App Engine

Fil des billets - Fil des commentaires

lundi 23 novembre 2009

La conférence "Innovation WEB" fait son retour

Le 4 décembre 2008, l'association GET (Google EFREI Technologies) organisait en association avec SFEIR une conférence sur les technologies Google.

Fort de son succès, une deuxième édition est programmée pour le 11 décembre 2009.

Cette année, il sera question d'Android, de Google App Engine, de GWT, de Google Wave et des standards du WEB (HTML5, CSS3, SVG).

Les intervenants de cette année seront Ludovic Perrier, Didier Girard et Patrick Chanezon.

Les conférences se tiendront de 13h30 à 16h30 dans les locaux de l'EFREI.


A la fin de la conférence aura lieu un cocktail, ce dernier sera suivi d'un atelier de développement Android organisé en association avec le Paris GTUG.

Pour plus d'informations, rendez vous sur le site de l'association.

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.

mercredi 8 avril 2009

Développez en Java vos applications Google App Engine :

Il y a à peu près un an, Google ouvrait l'App Engine aux développeurs, il n'était alors possible de déployer que des applications développées en Python.
Pour rappel, Google App Engine est une offre de Cloud Computing permettant aux développeurs d’héberger leurs applications Web sur les serveurs de Google. Les applications ainsi hébergées bénéficient de ce fait de la même capacité de montée en charge que les services Google tels que Gmail ou Google Finance.
Google n’est pas la seule entreprise positionnée sur ce secteur, bien que pas tout à fait similaires, Amazon et Microsoft ont eux aussi leurs offres avec respectivement AWS et Windows Azure.
Un des atouts de Google App Engine c’est que gratuitement un développeur peut déployer une application qui soit accédées à raison de 5 millions de pages vues par mois. Ce qui est somme toute une offre d’hébergement intéressante. Au-delà de ces quotas, il est possible d’acheter des ressources supplémentaires.
Depuis quelques mois, nous pouvions voir dans la roadmap de ce projet que le support d’autres langages était un des objectifs de Google. Aujourd'hui, c’est chose faite, Google ouvre son service à une nouvelle communauté et contrairement à leur poisson d’avril, ce n’est pas Fortran mais bien Java qui est désormais supporté.
Cette nouvelle devrait donc être accueillie avec un vif enthousiasme lorsque l’on sait que le support de Java a été l’une des premières évolutions suggérées par les développeurs lors de la sortie de la première version de l’App Engine.
La version Java ne déroge pas au qualificatif de « Simple d’utilisation » qui caractérisait la version Python. En effet, il n’y a pas de différence majeure dans l’approche qu’ont ses deux dernières. Un atout supplémentaire de la version Java et qui a son importance, c’est le fait qu’elle s’accompagne d’un plugin Eclipse. Il est ainsi possible de créer une application et de la déployer en quelques clics.
De plus, l’intégration avec GWT (Google Web Toolkit) est enfantine et proposée par défaut par le plugin.
L’environnement de développement App Engine Java supporte les versions Java 5 et Java 6, sachant que sur les serveurs distants c’est la 6 qui est supportée. Les pré-requis au développement et au déploiement d’applications sur la plate-forme sont relativement faibles : avoir installé Java et le SDK de l’App Engine. L’installation du plugin Eclipse est bien entendu un plus non négligeable.
L’administration des applications se fait via la même interface que pour les applications Python. Il est ainsi possible de voir la répartition de la charge dans le temps, les requêtes HTTP les plus récurrentes, le taux d’utilisation ramené aux quotas. Il est également possible de consulter les logs. Enfin, une page permet d’accéder aux données stockées dans le Datastore.
Etudions de plus près l’architecture d’un projet et l’utilisation des APIs

Passons à la pratique : 

Les applications Google App Engine doivent être structurées en respectant l’arborescence WAR, ainsi, si vous créez un projet via le plugin Eclipse, vous obtiendrez une structuration semblable à celle-ci :

Cette arborescence de projet ne présente pas de spécificité particulière, on notera la présence d’un fichier web.xml permettant d’assurer le mapping entre les URLs et les classes des Servlets.
Lorsque vous déployez une application sur Google App Engine, une association s’opère entre les fichiers que vous transférez sur les serveurs de Google et les applications que vous êtes en mesure d’administrer. Cette association est possible grâce à un identifiant que vous vous devez de retranscrire dans le fichier appengine-web.xml. Ce fichier est l’équivalent du fichier app.yaml de la version Python de l’App Engine.
Les Servlets sont tout à fait communes et ne différent pas de celles que l’on peut développer dans une application traditionnelle. La Servlet d’un HelloWorld pourrait donc se présenter ainsi :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}


Maintenant que nous savons qu’il n’est pas difficile de créer un projet, intéressons nous aux APIs spécifiques de Google App Engine.

Utiliser les APIs :

Authentification

Ajouter un système d’authentification des utilisateurs se fait tout aussi facilement qu’avec la version Python :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
              throws IOException {
        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();

        if (user != null) {
            resp.setContentType("text/plain");
            resp.getWriter().println("Hello, " + user.getNickname());
        } else {
            resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
        }
    }
}


Ici, on utilise le UserService pour récupérer l’utilisateur actuellement connecté à l’application. S’il y a bel et bien un utilisateur authentifié, nous lui affichons un message de bienvenue et si ce n’est pas le cas, l’API nous permet de le rediriger vers une page de login. Lorsque vous travaillez en « local », le système d’authentification est émulé, il n’y a pas de vérification à proprement parler de l’existence des utilisateurs. Lorsque vous déployez votre application, le UserService se base sur les Google Accounts pour vérifier l’existence des utilisateurs.

Il est également possible de savoir si l’utilisateur actuellement authentifié est un administrateur de l’application et ainsi de lui donner accès ou non à certaines fonctionnalités.

Persistance


Attention, comme pour la version Python de Google App Engine, le stockage des données ne s’effectue pas dans une base de données relationnelle. Google dispose de son propre formalisme de stockage des données qui s’apparente à une Map multidimensionnelle partagée.
Le développeur dispose de trois solutions distinctes pour persister ses données, en effet, Google App Engine Java implémente JDO (Java Data Object), JPA (Java Persitance API) et met également à disposition une API de plus bas niveau (Datastore API).
Dans cette version de Google App Engine, Google pousse un Framework de persistance : DataNucleus. Sa configuration se fait très simplement (voir doc pour plus de détails)
Voici un exemple utilisant JDO, la définition des données à persister se fait par annotation.
Ci-dessous, l’objet Comment est défini comme pouvant être persisté, en le sauvant, les éléments annotés comme @Persistent feront parti de la sauvegarde.

package com.sfeir.demo;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Comment {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long id;

    @Persistent
    private User author;

    @Persistent
    private String content;

    @Persistent
    private Date date;

    public Comment(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }

}

Il est ensuite très simple de manipuler cet objet au travers de l’API. Ainsi, pour persister une instance de cet objet, on peut utiliser le PersistenceManager de la manière suivante :

Comment comment = new Comment(user.getNickName(), content, new Date()) ;
PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");
      PersistenceManager pm = pmfInstance.get().getPersistenceManager();
        try {
            pm.makePersistent(comment);
        } finally {
            pm.close();
        }



Avec ce PersistenceManager, il est tout aussi simple de récupérer un objet pm.getObjectById(…) ou encore de le supprimer pm.deletePersistent(…).
Au même titre qu’il était possible d’interroger la base au travers du GQL dans la version Python, il est ici possible d’utiliser un langage de requête proche de SQL pour récupérer des données, il s’agit de JDOQL.
On pourrait récupérer la liste de nos commentaires ainsi :

PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

PersistenceManager pm = pmfInstance.get().getPersistenceManager();

String query = "select from " + Comment.class.getName();
List<Comment> comments = (List<Comment>) pm.newQuery(query).execute() ;


Gestion d'un cache mémoire


Afin de ne pas surcharger le Datastore avec des requêtes récurrentes, il peut être intéressant de stocker un certain nombre d’informations dans un cache mémoire. Cela peut se faire très simplement au travers de l’utilisation de la Memcache API.

cache = CacheManager.getInstance().getCacheFactory().createCache(Collections.emptyMap());
cache.put(‘‘cachedInteger’’, 25) ;
Integer cachedValue = (Integer) cache.get(‘‘cachedInteger’’);



Dans l’exemple ci-dessus, après avoir récupéré l’instance du cache mémoire, on y insère un entier à la clef « cachedInteger » au travers d’un put. Un simple get avec la clef nous permet de récupérer la donnée que nous avions mise en cache.
Le cache est utilisé pour cet exemple de manière très simpliste mais on pourrait imaginer l’utiliser pour retourner des informations ayant plus de valeur, comme le contenu RSS de l’application ou encore une page fréquemment requêtée.
Cette API de cache propose d’autres fonctionnalités intéressantes comme la possibilité de définir une période de validité pendant laquelle les données peuvent être considérées comme « fraiches ». Différentes politiques de gestion sont également applicables, ainsi il est possible de n’ajouter la donnée que si celle-ci est déjà présente ou réciproquement.

Envoi de mail


L'envoi de mail fait partie des fonctionnalités intégrées à Google App Engine et relativement simples à mettre en place au sein d'un projet.
Dans cette version Java, l'API implémente l'interface JavaMail, pour des raisons de sécurité, seules les adresses d’un administrateur de l’application ou celle de l’utilisateur couramment authentifié peuvent être spécifiées comme adresses de l’émetteur.
       

Properties props = new Properties();
        Session session = Session.getDefaultInstance(props, null);

        String msgBody = "Contenu du mail";

        ...
        Message msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress("admin@mondomaine.com"));
        msg.addRecipient(Message.RecipientType.TO,new InternetAddress("destinataire@sondomaine.com", "Destinataire"));
        msg.setSubject("Email envoyé par Google App Engine");
        msg.setText(msgBody);
        Transport.send(msg);


L’exemple ci-dessus montre l’envoi d’un mail basic, sachez qu’il est également possible d’ajouter des pièces jointes (voir types MIME autorisés) avec la contrainte toutefois que l’e-mail ne dépasse pas les 1mb.

Comme pour la version Python, il est également mis à la disposition des développeurs une API permettant d’interroger des hôtes distants (via l’API URL FETCH) et une autre permettant de manipuler des images.

Cette version de Google App Engine étant toute récente, il va être intéressant de suivre l’adhésion des développeurs de la communauté Java à ce service. D’une part, elle offre une grande facilité de développement et de ce fait un gain de temps dans l’élaboration d’applications, ce qui devrait en attirer plus d’un. D’autre part, tout comme pour la version Python un certain nombre de quotas et de restrictions sont à prendre en compte lors de l’utilisation de ce service, ce qui exclu certain types d’applications de cette offre d’hébergement.

Cette nouvelle version est également un beau coup de pousse donné à GWT, en effet le plugin Eclipse permet de créer en quelques clics une application GWT pour Google App Engine et devrait donc  amener davantage de développeurs à adopter ce Framework Web.

Google Guice sera peut être un autre des bénéficiaires de cette version Java, bien qu’il ne soit pas poussé outre mesure par Google pour être associé à Google App Engine, sa légèreté et sa simplicité d’utilisation devrait lui permettre de s’intégrer facilement aux applications déployées sur la plate-forme.

Quoi qu’il en soit c’est une nouveauté que nous nous devons de suivre.

Références :

Pour s'inscrire
L'annonce officielle
Le Coud Computing
Tout sur Google App Engine
DataNucleus
Découvrir GWT
En savoir plus sur GUICE
Amazon Web Services
Windows Azure

mardi 25 novembre 2008

Rejoignez nous le 4 décembre !

SFEIR et l'association G-EFREI Technologies organisent une grande conférence le jeudi 4 décembre 2008 à l'EFREI.

Au programme, des présentations et des ateliers traitant de RIA, Cloud Computing et mobilité.

Parmi les intervenants, Didier Girard parlera des RIA via une présentation de GWT, Christian Fauré de Cloud Computing et Jieren Wu de mobilité avec Android.

L'évènement est gratuit et ouvert à tous, reservez dès maintenant votre place en remplissant le formulaire ci-dessous.

Pour davantage d'informations et savoir comment vous rendre à cet évènement, c'est par ici.


mardi 18 novembre 2008

Quelques nouvelles à propos de cloud computing

Windows7 on VMWare Fusion Souhaitant tester la plateforme Microsoft Azure (si j'ai le temps), je viens d'installer Windows7 CTP (quitte à essayer des nouveautés) sur mon MacBook dans une machine virtuelle avec VMWare Fusion. Je n'avais entendu que du bien de ce produit de virtualisation, c'est vrai que ça dépote ! La preuve, image à l'appui :

Je voulais également en profiter pour regarder Visual Studio 2010 CTP, mais après avoir regardé la configuration requise, je me suis rabattu sur la version 2008 !

Sinon, quelques nouvelles à propos de cloud computing lues sur InfoQ :
Pour commencer, un article comparant les offres Amazon EC2, Google App Engine et Windows Azure.
Et en plus récent, la sortie de CloudFront Beta par Amazon.

Windows Azure SDK System Requirements
Visual Studio 2010 System Requirements
Comparing Amazon's EC2, Google's App Engine and Microsoft's Azure
Amazon Has Started Delivering Its Clouds with CloudFront

lundi 29 septembre 2008

Google Developer Day Paris 2008 - Résumé de la journée

2888831206_678d2cdedf Le 18 septembre dernier, à l'ENSA (Ecole Nationale Supérieure d'Architecture), Google faisait étape à Paris pour son tour du monde 2008.

Cette journée avait pour ambition de présenter les technologies Google et de proposer aux développeurs français présents de participer à quelques séances pratiques de codage avec ses APIs et frameworks. Pour certains, c'était les premiers pas comme développeur d'App Engine ou de GWT et pour d'autres, l'objectif était déjà d'aller un peu plus loin et d'échanger avec d'autres présentateurs ou participants sur leur expérience dans ces technologies ou de voir comment les intégrer dans les développements de solutions diverses...

Après la traditionnelle file d'attente devant l'entrée du magnifique bâtiment de l'ENSA, l'évènement a commencé vers 10h00 par une présentation des thèmes de la journée: le standard d'interopérabilité de réseaux sociaux OpenSocial, la plateforme de développement pour téléphones mobiles Android, le framework de développement web GWT, le service d'hébergement d'applications web Google App Engine, et les outils de localisation géographiques basés sur Google Maps et Google Earth.

La présentation du programme de la journée à peine terminée, la foule des participants quittait le hall central pour prendre place dans les amphis et dans les salles équipées afin de suivre des présentations "magistrales" et des sessions de code.

Ces présentations ont été animées par des ingénieurs Google mais également par des acteurs du terrain, des ingénieurs d'entreprises qui mettent en œuvre ces technologies dans leur travail quotidien telles que Sfeir et Viadeo.

Pour ce qui est des " Sfeiriens ": Jieren Wu et Didier Girard ont pu faire découvrir Google Web Tookit lors d'une session de code. Bruno Guedes et Vincent Bostoen ont présenté Google App Engine.

Les thèmes abordés ont été très nombreux : mobilité avec Android et en démonstration une balle fluide et rebondissante; Cloud Computing où on a pu faire héberger un wiki développé bien sûr en Python pendant que dans une autre salle nos collègues Bruno Guedes et Vincent Bostoen montraient à quoi sert l'infrastructure App Engine et comment l'utiliser; RIA où le Directeur Technique de Sfeir Didier Girard a présenté GWT puis accompagné de notre collègue Jieren Wu ils ont aidé les développeurs à écrire une application GWT pendant que d'autres suivaient en amphi une présentation d'Ajax; navigateurs avec la plateforme Chrome et sa gestion innovante de processus; réseaux sociaux où Viadeo a fourni son expertise lors de la session de code dédiée principalement à OpenSocial, avec quelques touches des APIs de géolocalisation et d'intégration dans le Google App Engine; ... Beacoup de sujets intéressants donc mais on ne pouvait pas être partout à la fois!! Difficile pour les participants de faire un choix.

Tout au long de la journée, un espace de détente était accessible à tous. Une occasion de discuter des dernières APIs autour d'un BabyFoot ou encore d'argumenter sur GWT tout en jouant à la Wii. Pour les moins agités, une masseuse ainsi qu'une montagne d'oreillers étaient également à disposition.

La journée s'est terminée vers 21h00 autour d'un buffet, une occasion de discuter avec ceux qui créent les technologies mais également ceux qui les utilisent.

En définitive, ce fût une journée bien remplie, de laquelle chacun des participants est reparti avec un tee-shirt et une clé USB en forme de PLAYMOBIL. En attendant l'édition 2009 des Developer Days, n'hésitez pas à vous rendre sur http://code.google.com pour vous former aux technologies Google. Pour ceux qui veulent voir ou revoir les vidéos, rendez vous sur http://fr.youtube.com/view_play_list?p=22350CB6D86B7A2B.

vendredi 27 juin 2008

La réponse de Microsoft au Google App Engine

ssds_googleAppengine 

Depuis le Mix08, on connaît les SSDS ou SQL Server Data Services de Microsoft. Evolutifs à la demande (On-Demand Scalability), offrant un SLA (Service Level Agreement) de haut niveau (haute disponibilité, haute performance, protection contre la perte de données, sécurité) et résolument orientés Agilité.

Cela pourrait paraître une réponse à Amazon et son SimpleDB. Mais ce serait ignorer une vision et n'y distinguer qu'une innovation.

Et ce serait surtout se tromper de cible. Le concurrent n'est pas Amazon, qui convertit une erreur d'estimation de volumétrie de ses serveurs en innovation marketing (très ingénieuse il est vrai, mais au business modèle qui laisse perplexe). La ligne de mire est encore et toujours Google dont la montée en puissance a de quoi faire trembler Redmond. A l'heure du cloud computing, Google a comme un coup d'avance avec son Google App Engine et la capacité de déposer des applications simples directement sur la plateforme Google.

Les Windows Live Services présentent plus ou moins une réponse aux Google Apps. Et Microsoft ne proposerait rien face au Google App Engine ?

La stratégie s+s, Software + Service, propose d'attaquer des données hébergées sur un data-center (SSDS) à partir d'un logiciel client. Ne peut-on imaginer la possibilité de voir au côté de ces services de données, des conteneurs d'applications, proposés sur le même principe ? Non content d'avoir porté vos données sur ces nuages de serveurs (par définition toujours à la dimension désirée), vous pourriez envisager de déployer sans effort des applications web par un simple upload de code. Et celles-ci bénéficieraient des même caractéristiques citées au début de ce billet : évolutives, sous SLA, Agiles.

Alors après "Your Data, Any Place, Any Time" aura-t-on le "Your Applications, Any Place, Any Time" ? C'est plus que probable.

On attend donc avec impatience le prochain grand événement de la firme, le Microsoft PDC 2008 (octobre) où sera vraisemblablement fait une annonce à ce sujet.

mercredi 4 juin 2008

Google App Engine ouvert à tous

Il y a quelques temps, nous vous parlions ici même de Google App Engine, un projet de Google permettant  aux développeurs d’héberger leurs applications WEB sur ses infrastructures.

Les applications ainsi déployées bénéficient de la même qualité de service et de la montée en charge que l’on connaît pour des applications telles que Gmail, Google Finance, …
Le programme était officiellement ouvert à près de 10 000 développeurs depuis le début du mois d’avril.

Chez SFEIR, nous avions organisé une petite rencontre pour présenter cette technologie aux personnes le désirant. A cette occasion, Didier Girard avait porté son jeu KeyboardWarrior (application GWT) pour fonctionner sur Google App Engine. Curieux d’étudier la capacité de montée en charge de son application, il a organisé il y a une semaine environ un "load test". Les résultats ont été publiés ici.

Les retours des utilisateurs en termes de disponibilité de l’application sont diverses, aucun problème pour certains, un peu de lenteur pour d’autres. Quoi qu’il en soit l’application a tout de même supporté un pic de près de 23 requêtes par seconde pendant une minute, ce qui est plutôt pas mal pour un hébergement gratuit.

Mercredi dernier, Google a annoncé sur un de ses blogs l’ouverture de Google App Engine à tous, de ce fait vous pourrez bientôt tester et vous faire votre propre idée. Toutefois, avant de vous lancer dans la réalisation de votre première application, vous devriez peut être jeter un œil à quelques articles. En voici quelques uns qui expliquent comment faire en sorte que votre application soit scalable et comment il faut penser les applications pour Google App Engine. En effet certains concepts de cette technologie nécessitent que l’on pense autrement. C’est notamment le cas pour l’API datastore (persistance des données), pour laquelle il faut oublier les concepts des bases de données relationnelles.

Google a également annoncé quelle allait être la politique de prix pratiquée pour l’hébergement d’applications sur Google App Engine. Tout d’abord, l’offre d’entrée reste gratuite avec 500Mb de stockage et assez de bande passante et de CPU pour supporter l’équivalent de 5 millions de pages vues pas mois.

Les tarifs se présentent ensuite ainsi :

-10 à 12 cents par heure de CPU

-15 à 18 cents par GB de données par mois

-11 à 13 cents par GB de bande passante sortante

-9 à 11 cents par GB de bande passante entrante

Cette annonce est accompagnée par la mise à disposition de deux nouvelles APIs, une pour la manipulation d’images et une autre pour gérer un cache afin de diminuer les requêtes du datastore.

Je vous invite à suivre les retours des personnes qui assistent aux Google I/O sur Google App Engine, nous en saurons sûrement plus.

mardi 13 mai 2008

Codathlon Google App Engine, pour ceux qui n'y étaient pas

Jeudi 8 mai dernier, le premier Codathlon Google App Engine s’est tenu dans les locaux de SFEIR à Suresnes.

Cet évènement organisé par Didier Girard a été l’occasion pour les participants de découvrir ce projet qui est ouvert à environ 10 000 développeurs depuis le début du mois d’avril.

Google App Engine , le principe :

L’objectif de Google App Engine est à terme de permettre à tout le monde de déployer ses applications WEB sur les infrastructures Google. Il s’agit d’une réelle aubaine pour les développeurs qui peuvent ainsi bénéficier de la robustesse et de la qualité de service des infrastructures Google. De plus, ils n’ont plus à se soucier des phases de configuration ou encore de monitoring, le développeur peut se concentrer pleinement sur la réalisation de son application, déployer n’est alors plus qu’une histoire « d’upload ».

Les comptes ayant été mis à disposition sont gratuits, ils permettent de stocker près de 500MB de données et sont conçus pour pouvoir répondre en terme de CPU et de bande passante à près de 5 millions de pages vues par mois. A terme, il sera bien entendu possible pour les personnes le désirant d’acheter des ressources supplémentaires.

Pour l’instant, seuls les développements en Python sont supportés par App engine, d’autres langages devraient l’être dans les prochaines versions de ce projet.

Bien qu’actuellement, tout le monde ne puisse pas déployer un projet App Engine, toute personne souhaitant s’initier à cette technologie peut le faire. En effet Google met à disposition un SDK permettant de développer des projets App Engine en local. Le tout est de plus très bien documenté sur http://code.google.com/appengine.

Le déroulement de la journée :

Le Codathlon a commencé vers 9h00 du matin, les participants ont alors installé l’environnement de développement sur leurs machines. Une fois cette opération effectuée, une présentation s’est tenue sur le sujet, les thèmes abordés ont été diverses et les questions assez nombreuses. Il est vrai que bien qu’il n’y ait pas encore eu de réel Buzz autour de ce projet, les possibilités offertes n’en demeurent pas moins innombrables.

Après une première introduction, et une démonstration de comment réaliser un Hello World, les participants ont mit les mains dans le cambouis pour réaliser à leur tour leur première application Google App Engine.

Une fois l’heure du déjeuner arrivée, nous sommes tous aller déjeuner à la terrasse d’un restaurant, innovation, avenir du web et autre sujets passionnants ont animé les débats.

De retour au Codathlon, une dernière présentation s’est tenue sur les APIs embarquées par Google App Engine, ce qu’elles permettent de faire et comment elles fonctionnent. Nous avons pu voir comment identifier un utilisateur, comment persister des données dans le datastore, comment envoyer un mail, ...

L’heure était venue pour chacun de coder sa propre application, par groupe de deux nous avons développé des petites applications, le but étant de mieux appréhender les concepts ayant étés présentés durant la matinée en les mettant en application concrète. Certains se sont même amusés à lier leur application Google App Engine avec une interface conçue en GWT.
Didier Girard a d'ailleurs porté son Keyboard Warrior sur cette plate-forme, vous pouvez le trouver ici

Vers 20H00, les derniers participants ont pris le chemin du retour.

Une journée assez riche qui, nous l’espérons aura séduit les participants, un type d’évènement que nous espérons pouvoir renouveler à l’avenir avec pour prochain thème … pourquoi pas GWT ?

Slides de la présentation :

SlideShare

Ils étaient là pour l'évènement et ils en parlent :

http://www.elkhalfi.com

http://www.msepehr.com