new Blog( perso );

Affichage des articles dont le libellé est google. Afficher tous les articles

02 octobre 2009

Google Chrome Frame : amusant

Google nous sort un de ces petits ovnis dont il a le secret : Google Chrome Frame.

Il s'agit d'un plugin pour IE qui remplace tout simplement le moteur de rendu du navigateur le plus décrié mais aussi le plus installé par le moteur Chrome. Celui-ci n'est actif que sur les pages qui déclarent une balise magique, autrement dit quelques sites de geek et probablement quelques applications Google, mais pas plus. Un petit Script est proposé par Google pour permettre à ces sites de proposer l'installation de Frame sur postes qui ne l'ont pas encore.

Il est évident que la cible n'est pas l'entreprise, car si on y utilise encore massivement IE6, c'est à cause d'applications utilisant massivement des ActiveX et/ou l'authentification MS Active Directory, ou simplement pour ne pas mettre des sous dans une migration technique risquée (?) et sans R.O.I. facilement chiffrable.

De mon point de vue, la cible c'est les millions de particuliers qui utilisent IE juste parce qu'il est fournit avec l'OS, qui n'ont aucune idée de ce qu'est un navigateur (je pense à ma belle mère qui "clique sur Internet"). Ceux qui ont déjà installé sans trop réfléchir le plugin Flash par ce que le site de la redoute le demandait, et qui installeront donc Frame un site grand public de renom le propose (par exemple ... www.google.com ?)

Quel intérêt pour Google ? Faire que le web soit toujours plus consommé par les utilisateurs à la place de l'informatique traditionnelle. Les gMail, gDocs, gCalendar et consorts ne gagneront du terrain que s'ils sont au moins aussi performants que l'équivalent desktop. Ce qui signifie bien sur un moteur rapide - en tout cas plus que celui natif d'IE - et le support du mode déconnecté (google Gears).

Ceci dit, il y a un intérêt pour Frame en entreprisse : sur un SI massivement MS/IE, proposer une installation 'transparente' de la petite extension magique reste acceptable (enfin, pas pour tout le monde), et cela ouvre aux développeur de nouvelles possibilités (HTML5 !) pour les nouvelles applications. Penses-y, amis lecteur, si tu es DSI - vous êtes probablement plus nombreux à être des geeks furieux, mais sait-on ...

26 mai 2009

Maven, Eclipse et GWT main dans la main

Avec la sortie du Plugin Google Eclipse, il me restait à intégrer proprement le couple Maven + GWT avec l'IDE le plus connu des développeurs java - je n'ai pas dit le meilleur ;p

C'est désormais chose faite avec le dernier SNAPSHOT du plugin GWT, qui devrait clore une longue liste avant une release que j'espère proche, le temps de fixer les derniers bugs et erreurs de documentations.

Comme je l'explique sur cette page, la principale difficulté est que le plugin Google Eclipse n'est pas très "maven compliant" et oblige à faire quelques concessions. Cependant, avec l'aide de m2eclipse (ça doit aussi marcher avec IAM, je n'ai pas encore testé) on obtient le résultat suivant, que vous pouvez expérimenter à la maison en utilisant le projet de test it/reactor du plugin, ou sur votre propre projet (dites moi ce que ça donne) :

import du projet Maven sous Eclipse par m2eclipse. Les dépendances, répertoires de sources et de génération de code sont identifiées et configurés sous Eclipse, et surtout lesmodules d'un multi-projet et dépendances présentes dans le workspace sont "résolues" en tant que références inter-projet et non via les jars du repository local.
ajout du support GWT (étape encore manuelle, j'y travaille) via Google Eclipse Plugin. Soucis ici, le plugin ajoute lui même les dépendances GWT qui font donc doublon avec celles gérées par m2eclipse. Ca n'a pas l'air gênant à condition bien sûr que les versions soient cohérentes. Si quelqu'un à une astuce je prend ;)
génération des lanceurs pour les modules de l'application en lançant mvn gwt:eclipse. Cette tâche gère désormais aussi bien les lanceurs "classiques" et ceux exploitant le plugin Google Eclipse (cas par défaut). Au passage, le plugin prépare le répertoire /war du mode hosté.
un simple run as > web application sur le lanceur généré et le mode hosté démarre. L'URL de la page web hôte n'étant pas déclarée dans le fichier module, j'ai pris comme convention qu'elle porte le même nom que le module et est présente dans son répertoire public. C'est un peu limitatif mais ça doit être assez courant. Sinon il suffit d'éditer la configuration d'exécution.

Le gros progrès (en terme de confort et de productivité) c'est que si votre application est découpée en modules maven, une modification dans le code source d'un de ces modules sera directement exploitable dans le navigateur hosté par un simple refresh. Pas besoin de repackager un Jar ou tout autre manipulation - perte de temps.

Pour aller au delà du serveur hosté et passer sur un "vrai" serveur d'appli (-noserver) il faut jongler un peu entre le plugin maven-war et les chemins "en dur" choisis par Google, mais on s'en sort.

On a donc enfin une solution productive pour faire du GWT sous Eclipse sans s'empêtrer dans des builds Maven sans fin. Reste à vérifier que tout ça reste bien compatible avec le fonctionnement "hors eclipse" du plugin : La tâche gwt:run a encore ses fans (à moins que ce soit juste du anti-Eclipse ?)

Je n'ai pas testé le support de GWT sous IDea ou NetBeans, mais si un fonctionnement équivalent est possible je serais ravi de l'intégrer au plugin - les patchs sont bienvenus :)

18 avril 2009

Appengine Java ... réfractaire à Maven !

En tentant de "Mavenizer" le SDK Java d'AppEngine, je tombe sur de nombreuses librairies du SDK qui ne collent pas aux artefacts Maven (somme md5 différente) :

commons-el, commons-logging, jasper-compiler, jasper-runtime, jstl, standard, ant, ant-launcher

rien que ça !

Une petite recherche me fait découvrir une classe de commons-el dont la taille binaire est différente entre les deux JAR. Google aurait-il eu besoin d'adapter ces classes pour son runtime ? Après décompilation : aucune différence !?

Première hypothèse : Google a recompilé lui-même ces librairies. Pourquoi pas, mais ça parrait un drôle d'idée.

Seconde hypothèse : Google a eu besoin de modifier ces classes, non pas dans leur code source mais dans leur structure bytecode. Après tout, le runtime AppEngine a de grande chance de ne pas utiliser une JRE SUN classique, mais plutôt un JVM Dalvik déjà maîtrisé par Google puisqu'elle est au coeur d'Androïd - mais ce n'est que pure spéculation !

Troisème hypothèse : Goole a pris des jars qui trainaient sur un coin de table (ou de disque dur), de toute façon ils n'ont rien compris au problème des dépendances Maven et s'en tappent : ils ne l'utilisent pas (même problème avec GWT-dev). Hypothèse la moins avantageuse car dans ce cas on est pas près de savoir si on peut utiliser les JAR "standard" du dépôt Maven sans risque.

Quatrième hypothèse : Google n'aime tellement pas Maven (il n'y a qu'à voir combien de ses projets majeurs l'utilisent) qu'ils ont décidé de tripatouiller les JARs juste pour nous emmbêter. Un complot mondial je vous dis !

Dernière hypothèse : Jason (Van Zyl, Mr "j'ai créé Maven") a voulu s'assurer l'exlusivité d'un plugin GAE, augmentant ainsi sa mainmise sur l'écosystème Maven. Il a donc collaboré avec Google (dont les bureaux sont voisins) pour s'assurer que ceux qui ne sont pas dans le secret ne s'en sortiraient pas.

Dans tous les cas, il va falloir patienter encore pour avoir une première SNAPSHOT d'un plugin GAE ... ou alors tenter le coup avec les artefacts "officiels" Maven pour voir.

09 avril 2009

Google Developer Day – community feedback

Google organisait jeudi en fin d’après midi une soirée pour présenter son AppEngine en version Java à la communauté et récolter un premier feedback. Didier Girard était de la partie, décidément toujours sur les bons coups :)

L'annonce, c'est bien sur Google App Engine for Java + GWT 1.6 + un plugin Eclipse.

Premier point, la plateforme est un pseudo tomcat tournant sur un Java6 « à la sauce Google ». Comprenez que certaines API Java sont blacklistées, soit parce qu’elles n’ont aucun sens sur le « cloud » (java.io.File par exemple), soit pour des questions de sécurité. Il n’est par exemple pas possible de lancer un Thread, et certaines pratiques de réflexion ne sont pas autorisées.

Ces petites limitations ont un gros impact sur les frameworks que nous pouvons utiliser. Guillaume Laforge a fait un gros travail d’analyse sur Groovy pour le rendre compatible (et accompagner ainsi l’annonce très relayée de Google). De nombreux autres frameworks ne sont apparemment pas compatibles. La liste des outils (in)compatibles reste bien sur à construire (je projette d'ailleurs de faire ma première appli AppEngine sur ce sujet).

Autre restriction, la « base de données » de AppEngine n’est autre que BigTable, l’espace de stockage géantissime de Google – et qui n’a rien à voir avec une base relationnelle. DataNucleus (l’ex JPOX) a été choisi pour fournir aux développeurs une approche JDO ou JPA. Bizarrement, c’est la première qui est mise en avant par les wizards et exemples du SDK. JPox était en effet un outil JDO de premier plan, mais la compatibilité JPA n’en est qu’une surcouche. Autre point, déjà JPA a tendance à nous faire faire des choses « pas très bonne au sens relationnel » car on a tendance à oublier trop facilement la base de données qui se cache derrière. Avec BigTable c’est encore pire, car il ne faut pas envisager de passer par des jointures. Autrement-dit, même API qu’en JEE « traditionnel » mais pas mêmes usages et bonnes pratiques !

Pour ceux qui ne veulent (ou peuvent) pas héberger leurs données en dehors de leur SI, Google propose une API « Secured Data Channel », une sorte de trou de souris dans votre Firewall, sécurisée en SSL, et permettant au « cloud » Google d’accéder à vos données. A priori raisonnable, mais ça sent tout de même le hack ;)

Tout ça fait beaucoup de restrictions me direz-vous. Bien sur, pour déployer sur AppEngine une appli « hello world » cela prend deux clics, et l’infrastructure Google peut alors prendre en charge des pics de charge faramineux sans qu’on ait rien eu à prévoir.

Quel est la cible de AppEngine for Java ? Pas les applications JEE, vu l’inconnue sur le bon fonctionnement des frameworks, et surtout pas en l’état vu la nécessité de repenser la persistance des données. Par contre, tout développeur qui fait du JEE au boulot se retrouve en terrain connu pour déployer son appli perso. Et c’est bien la cible de Google : plus d’applications = plus d’utilisateurs du web = plus de revenus. Vous qui n’arrivez pas à vous mettre à PHP, qui ne pipez rien à python, vous allez pouvoir faire votre petite appli Java avec les outils habituels, avec votre API JPA pour stocker des données, avec GWT 1.6 pour faire de supers applis Ajax sans rien y connaître, et publier tout ça sur le Net pour pas un radis. Et si jamais votre site de vente de schewing-gum usagé explose les scores en raison d’un Buzz incontrôlé, l’infrastructure Google tiendra le choc !

Vous cherchiez une solution de cloud-computing pour votre entreprise ? Attendez que AppEngine se stabilise - ou plutôt, qu’on apprenne à bien l’utiliser et que les frameworks évoluent en conséquence.
Vous cherchez à héberger votre idée de super appli délire que personne y avait pensé avant, AppEngine est pour vous ! Au mieux, vous allez lancer le nouveau YouTube, au pire, dans 2 ans, vous vous vendrez comme expert AppEngine à tous les cabinets de recrutement ;)

Surprise pour moi de ne pas voir dans le package Google Guice. Le marketing de Google ne semble pas chercher à pousser ce framework, cela aurait pourtant été une occasion sans équivalent.

Au passage, je prépare un chtit plugin Maven pour ceux qui ne veulent pas se contenter du plugin Eclipse proposé par Google : http://svn.codehaus.org/mojo/trunk/sandbox/google-app-engine-maven-plugin/

Merci à Didier de m'avoir transmit une invitaton pour cette soirée, qui a soulevé de nombreuses questions et beaucoup d'intérêt ;)

08 avril 2009

Google App Engine passe à Java 6

Après être resté chasse gardée des développeurs Python, Google App Engine passe à la vitesse supérieure en répondant à la demande numéro 1 : supporter Java !

Au programme : Java 6, Servlets, JavaMail, mais aussi JPA pour accéder au DataStore google. Autrement dit, la plateforme de rêve pour héberger nos applications Java / GWT ! Google propose même un plugin pour Eclipse afin de fournir un environnement clé en main.

http://code.google.com/intl/fr/appengine/docs/java/overview.html

Si on arrive à coller un Spring (ou plus probablement un Google Guice) là dessus, on pourra déployer sur App Engine la même application que sur notre serveur JEE :D

Il serait bon que Google s'intéresse plus à la JSR 299, qui portait au départ sur jBoss Seam mais c'est réorientée sur l'injection de dépendance. Elle permettrait de ne pas être lié à un framework particulié dans notre code. Les annotations proposées sont inspirées de Google Guice, autant dire un appel à peine voilé au soutien de Google - qui répond absent pour l'instant - et si celui-ci y va, SpringSource sera plus ou moins obligé de suivre (en tout cas, d'y réfléchir).

Je suis invité chez Google France demain soir pour discuter avec la communauté de cette annonce technologique phare (à moins qu'ils veuillent m'embaucher ?). Plus d'infos très bientôt donc !

20 juin 2008

Google App Engine : simple comme un coup de fil ?

Pour ceux qui ont raté le début, Google a lancé un service d'hébergement d'applications web basé sur son infrastructure massivement distribuée (on parle de cloud-computing). Autrement dit, même l'application web de votre club de fans de star treck peut potentiellement supporter un pic de traffic temporaire, gràce aux ressources énormes du "cloud", ce que ne permet pas un hébergement sur serveurs dédiés.

Lors du lancement, Google a offert 10000 clés au premiers inscrits. Intile de dire qu'elles sont vites parties et que comme beaucoup je suis arrivé après la bataille.

Google a changé sa stratégie, et on peut désormais obtenir une clé depuis un compte google par une simple procédure de vérification, qui consiste à donner son numéro de mobile pour recevoir la clé par SMS.

Premier point, c'est super : on va pouvoir tester G.A.E !

Deuxième point, d'où Google sort-il cette procédure d'enregistrement ?

Je suppute que Google prépare une attaque en règle du marché mobile, et profite de GAE pour se faire une base de donnée des n° de portable des développeurs web du monde entier... Faut il faire un rapprochement avec les téléphone basés sur androïd (l'OS google pour mobile), qui sont attendus en fin d'année ?

"We will use your phone number to send an invitation code in a SMS message to your phone. In accordance with the Google App Engine Privacy Policy, we will not use your phone number in any other way."

Vais-je recevoir d'autres "invitations" pour tester les nouveaux services mobiles de Google ???

11 avril 2008

Hébergeurs ... tous aux abris !

Google vient de lancer la pré-version béta limitée (donc "web 2.0" ;-p) de son tout nouveau service d'hébergement d'application.

L'idée est simple : vous développez votre petite application web en utilisant toutes les ressources des API Google (BigTable, Google File System, ...) et Google se propose d'héberger l'application sur son infrastructure - y compris la promesse d'un réseau hautement fiabilisé, capable d'absorber sans broncher les pointes de traffic, et de supporter l'incompréhensible engouement des internautes pour votre site "mon-chien.net".

Google App Engine s'accompagne de son SDK pour aider au développement. Les applications sont écrites en Python, seul runtime supporté pour l'instant. L'architecture est prévue pour permettre à l'avenir d'autres langages/runtimes.

Quelle différence avec l'offre existante ?

Pour de "petits sites", PHP+MySQL est l'offre courante, mais généralement accompagnée de restrictions de traffic / bande passante / charge CPU. Aussi, vous devez être capable d'évaluer vos objectifs de traffic au plus juste, tout en n'étant pas à l'abris de rencontrer le succès. Rien de plus déplaisant que de voir son site préféré - devenu indispensable - "déménager" vers un autre hébergeur et être indisponible pendant plusieurs longues journées...

Pour les "gros sites d'entreprise", J2EE ou .Net, il faut maîtriser toute la chaîne d'hébergement - serveur, base de données, sécurisation, déploiement, monitoring ...

D'ou la question : quelle techno retenir pour mon site de vente de chewing-gums d'occasion ? Sans hésiter Google App Engine :

Gratuit, dans la limite de restrictions très raisonnables (500Mo stockage, 5Mon pages/mois)
Prométeur : le SDK va probablement s'enrichir pour faciliter l'accès aux services Google.
Cool : c'est encoure tout chaud !

Seule limitations, bloquantes :

je n'y connais strictement rien en Python
Je ne fais pas partie des 10000 chanceux qui ont obtenu les ID de test de cette pré-version béta ;-(

Le bug n°1 dans la gestion googleAppEngine réclame le support de Java. Pas étonnant vu l'absence (presque) totale d'offre d'hébergement Java. Les PHP-iste se feront sans doute égallement entendre, mais ils n'en sont pas réduit à lancer tomcat sur leur PC perso accessible d'Internet par la ligne ADSL, eux !

Comme quoi, J2EE a raté quelque chose ! Ce n'est qu'une bonne grosse norme bien compliquée, bien vendue par les grands éditeurs, rapidement dénigrée (qui fait encore de l'EJB2 CMP ?), et inadaptée à l'hébergement mutualisé - vu l'absence d'offre.

La cause (à mon avis) étant l'impossibilité de :

limiter les ressources attribués à une application web (un while(true) {} et tout le serveur est bloqué) - sauf extension propriétaire ...
l'impossibilité de recharger les classes à chaud (c'est si simple de remplacer un .php)
le packaging inutilement compliquée (seul Axis2 fait pire)

Je pense qu'il y a une place à prendre pour les applications Groovy : sue la base d'une structure WAR (explosée), incluant les jars de librairies utilitaires, Chaque fichier .java peut être interprété comme un script Groovy. On pourrait donc modifier un .java et observer les effets immédiatement. -- juste une idée, si quelqu'un à du temps devant lui...