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.

16 avril 2009

breizhjug channel

Annoncée depuis décembre, avec des démos à n'en plus finir de nous allécher, parleys.com se prépare d'ici une semaine à ouvrir une "private beta" de son publisher, qui permettra de monter et diffuser une présentation vidéo/slides sur le site que vous connaissez déjà tous (!)
Pour avoir testé la précédente bêta en octobre, la nouvelle mouture s'annonce fantastique (par rapport à un montage manuel qui est ultra pénible). 

Cerise sur le gâteau, Stephan offre l'hébergement aux JUGs du monde entier, à croire qu'il à un super prix sur son accès Internet ;) Parleys va vite devenir la plateforme vidéo incontournable pour ce type de contenu.

Ajoutez à ça que Adobe vient de m'envoyer une suite complète CS3 production premium en cadeau pour avoir accueilli François en février, et ça vous donne une idée de mon occupation pour le week-en à venir (surtout si le temps se maintien...)

12 avril 2009

Maven @ PoitouCharentesJUG

Le PoitouCharentesJUG m’a invité pour son inauguration à venir présenter Maven. J’ai donc rencontré la communauté enthousiaste et accueillante d’une région que je connais bien pour y avoir fait mon service militaire et déniché ma moitié.

14ème JUG français, le « bravitudeJUG » (surnom totalement non-officiel mais qui leur va si bien) est l’exemple d’une réussite : organisation sans faille, équipe motivée, public pointu, participatif et très chaleureux. Pour une première, qui plus est la veille du week-end de pâques, les 25 membres présents sont une preuve de la dynamique locale, surtout pour une session organisée en à peine 10 jours !

J’ai très largement débordé des 90 minutes qui étaient prévues pour la session, sans pour autant perdre qui que se soit en route. De très nombreuses questions ont été posées par un public mixte : le monde de l’entreprise rencontre ici les universitaires et le secteur public local – une diversité qui promet des échanges riches !

La vidéo et les slides de la session sont disponibles, en attendant que je puisse la diffuser sur Parleys.com. N’hésitez pas à contacter l’équipe du tout jeune PoitouCharentesJUG pour les encourager ou pour leur proposer votre collaboration. La prochaine session devrait être organisée sur Niort et portera sur les IHM, web (GWT) et desktop (Eclipse RCP). Encore une soirée riche en perspective ;)

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.


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 ! 

03 avril 2009

Maven au Poitou-Charente JUG !

Je serais vendredi prochain à l'inauguration du PoitouCharenteJUG pour y présenter Maven.

Si vous êtes de la région, que vous connaissez du monde dans le coin, faites passez le mot car nous avons très peu de temps pour faire connaître ce nouveau JUG et faire venir du monde. Nous comptons beaucoup sur le bouche à oreille, un petit coup de main sera le bienvenu !


30 mars 2009

Fonzie Coding Fryday

Vendredi dernier j'ai voulu sortir un peu de quatre jours à corriger des bugs en série pour réussir à faire passer le projet dans l'intégration continue Hudson. Le temps d'appliquer une correction, deux nouvelles boulettes appraissaient sous Subversion.
Vendredi donc, j'ai voulu faire du codage cool. J'ai donc délaissé mes bugs (ils seront encore là lundi,  d'ailleurs ça c'est confirmé) pour me lancer dans un code expérimental : recoder Grails en pur Java. Pour commencer modestement, je me suis contenté de GORM, la couche d'accès à la base de Grails, et plus précisément à son mécanisme de requête sur les entités "domaine".

Pour faire court, si je déclare une méthode User.findByNameOrderByBirthDate(String) à votre avis  quelle est la requête passée en JPA ? Le concept "Don't Repeat Yourself" (DRY) consiste à s'obliger à chercher des outils et des conventions intelligentes pour ne pas avoir à coder ce genre de méthodes. Si un esprit raisonnablement tortueux arrive à deviner ce qu'elle fait, un soft bien ficellé devrait pourvoir en faire autant.

En Groovy, Guillaume et sa bande nous font ça les doigts dans le nez. Sans Groovy, j'ai fait appel à AspectJ. C'est un peu moins classe qu'avec Groovy, mais on reste en pur Java - ne jamais changer les habitudes des gens sinon ça fini toujours par vous retomber dessus ;)

C'est donc comme ça qu'est né Fonzie (il est comment Fonzie ? Il est cool !)
J'espère bien répéter l'expérience du Fonzie Coding Fryday (TM) vendredi prochain, ça apporte un bon bol d'air et plein de nouvelles idées.

26 mars 2009

spring-test-context, JPA et dbUnit

Sur ma toute belle appli d'en ce moment que j'adore nous gérons la persistence avec JPA. Comme je suis un grand fan de la testabilité par POJOs (ce qui est super original de nos jours), je préconise d'utiliser spring-test-context pour tester la persistence.

Seulement, j'aime bien aussi utiliser dbUnit pour insérer des données de test prévisibles avant mes tests. Et là ça se complique sérieusement, car il faut passer à dbUnit la connexion JDBC associée à la transaction utilisée par l' EntityManager JPA (vous suivez ?)

Le problème, c'est que spring-test-context ne propose par de méthode listener au sein de la transaction (SPR-4365) ; seulement avant ou après. J'ai donc du étendre le "TransactionalTestExecutionListener" pour ajouter dans beforeTestMethod l'injection des données dbUnit.

La mauvaise surprise, c'est qu'en l'absence d'une indication explicite, Spring utilise un DefaultJpaDialect incapable d'identifier la Connection JDBC utilisée, mais ce n'est pas considéré comme un cas d'erreur donc dbUnit ne partage pas la même connexion :'(
Ajoutez à ça une connexion qui est par défaut en autocommit, des tables Oracle AQ$TRUC qui viennent pourrir les données de test et ça vous donne une idée de mes trois derniers jours :-/

Pour résumer, si vous voulez faire comme moi :
  • N'oubliez pas de préciser le jpaVendorAdapter (HibernateJpaVendorAdapter) dans la définition Spring de votre entityManagerFactory
  • Utilisez DataSourceUtils pour récuperer la connexion associée à la transaction JPA en cours
et là, miracle, ça marche enfin :)

Etape suivante : faire un merge à la volée entre les deux persistence.xml qui vont constituer mon contexte JPA (SPR-2598), le permier étant "mutualisé" avec une autre application ... 


22 mars 2009

IE6 à l'abris grace à nos DSI

Les dernières stats d'utilisation des navigateurs web sont sans appel : IE6 décline face à IE7 et Firefox3 qui se partagent le marché en 50/50


Ce qui est intéressant ici c'est l'effet "dent de scie" sur la courbe, qui montre que de très nombreux utilisateurs sont contraints d'utiliser IE6 5 jours par semaine, et passent sous FireFox le week-end. 

Ca ne vous rappelle rien ? Quel est le navigateur "corporate" installé sur vos postes préconfiguré et labellisé par l'entreprise, recommandé par le service technique et nécessaire pour faire marcher correctement vos applications Intranet ?

Autrement dit, les meilleurs clients de IE6 ce sont ... nos DSI, qui continuent à le conserver frileusement (utilisent-ils FF le week-end ?). Malgré toutes les plaintes des développeurs web, ses soucis de performances et tout ce qu'on pourra lui reprocher, IE6 a encore de beaux jours devant lui : avec la crise-qui-fait-peur aucun DSI ne se lancera dans une migration des postes qui ne rapporte rien à court terme. 

Et pourtant, avez-vous estimé le temps perdu à adapter votre appli web pour qu'elle marche sous IE6, alors qu'elle fonctionnait déjà très bien sur à peut près tout le reste ?

18 mars 2009

Big Blue croquera t-il Java ?

Vous l'avez sans doute lu un peu partout, IBM pourrait bien s'offrir SUN. La crise aidant, les cours sont au plus bas et donc les rachats deviennent possible, même les plus innattendus.

IBM a beaucoup misé sur Java, aussi devenir propriétaire de la marque Java TM et de la gouvernance de la plateforme serait assez naturel. On peut s'intéroger sur l'orientation qu'IBM donnerait à Java, mais si on considère le temps pris par SUN pour passer à un modèle ouvert pour son JDK, ça ne peut pas être tellement pire.

Pour le reste, que pourraient bien devenir (Open)Solaris, GlassFish et NetBeans face aux projets directement concurrents d'IBM ? 

Passons sur Solaris, dont la base d'utilisateur assure au moins la survie. GlassFish vs Websphere, un match qui aurait pu semblé joué d'avance (je n'ai pas testé GlassFish, mais par contre j'ai déjà suffisement subi Websphere). Netbeans est apprécié de ses utilisateurs, mais l'omniprésent Eclispe - malgré ses défauts - est le bébé d'IBM.

Reste les offres "hard" des deux géants. Je ne suis pas spécialistes mais elles semblent plus concurrentes que complémentaires. Alors, un rachat de SUN signifiera t-il le sabordage d'un pan entier de technologies au profit des produits IBM ? 

Allez, on a qu'à dire que tout celà n'est qu'un mauvais poisson d'avril ! Ou encore que Google et Oracle vont fonder une Joint-venture pour racheter SUN les premiers... 

13 mars 2009

Grails rocks !

Sur mon projet actuel, d'une taille assez colossale, tout (et même le reste) est configurable, si bien qu'il faut une appli de gestion de la conf qui à elle toute seule est déjà une belle appli web.

Les données de configuration qui sont manipulées sont des entités JPA manipulées ailleurs. J'ai donc fait un essai du côté de Grails, que je n'avais fait qu'éffleurer précédement sans rentrer dans le vif du sujet. En quelques heures, j'ai une appli fonctionnelle pour gérer mes données JPA !

Grails permet de définir son modèle en Groovy mais s'accomode très bien d'un modèle "legacy". Les metadonnées Grails (selon une syntaxe de closure Groovy très compactes) peuvent en effet être déportées dans des classes compagnon suffixées "Constraints". Ma belle entité JPA Habilitation peut donc rester 100% java (Groovy fait encore un peu "geek") sans m'interdire de l'utiliser dans une belle application Grails.

Groovy fait son chemin dans le monde professionnel. Les IDE le supportent de mieux en mieux (même Eclipse s'y met, c'est dire :p), les frameworks et plugins pour Grails se multiplient. Reste à le rendre "acceptable" pour nos décideurs ... et paradoxalement ce n'est pas le plus facile. J'ai donc une astuce : plutôt que de coder en Groovy mon application JEE ultra-stratégique holala faut surtout pas prendre de risque avec un truc de geek, j'intégre le support de la JSR 241. C'est la même chose, je sais, mais bizarement ça ne sonne pas pareil ;)

12 mars 2009

A quoi bon ?

Dans le milieu des "architectes Java" on se targe d'appliquer des patterns, de structurer des architectures et d'offrir des applications flexibles, maintenables et évolutives.

Mais dans la vraie vie, ça donne quoi ? 

Des concepts abstraits qui perturbent les nouveaux arrivants, de longues heures de formation sur les design pattenrs qui ne laissent que bien peu de traces dans le code produit, un joli tas de voeux pieux qui n'aboutit à rien de concret, et une belle architecture, plus ou moins bien appliquée, mise à mal au moindre bug un peu bloquant qu'il faut corriger en urgence.

Alors à quoi bon. Après tout, du bon vieux code "Plain Old Spaghetti Code" (POSC, à ne pas confondre avec le code de PORC)  est-il vraiment si terrible ? De toute façon, d'ici six mois les besoins auront tellement évolués qu'il faudra tout reprendre et que notre magnifique "modèle objet du domaine" sera bon pour la casse - pardon, pour le "refactoring massif". D'ici un an, deux armées de stagiaires seront passées sur le code et auront massacré votre beau modèle en couche faute d'en comprendre les raffinements si subtils. D'ici deux ans, votre magnifique framework de [mettez-ici-le-pattern-que-vous-voulez] sera totalement obsolète. Alors pourquoi se tirer une balle dans le pied ?

Qu'est ce qu'on trouve à pas cher sur le marché ? Des gens pas très expérimentés qui rivalisent difficilement avec leur homologues indiens. Combien celà coute t-il d'en faire des experts à même de comprendre nos architectures hautement modulaires ? Quel bénéfice au final ?

Pourquoi ne pas considérer officiellement le modèle du code kleenex ? Tout pourri, mal ficelé, à peine fonctionnel, mais ça coute de toute façon moins cher de le refaire "from scratch" à bas cout d'ici deux ans que de le maintenir en l'état.

Quelle valeur ajoutée réelle pour nos belles usines à logiciel, toutes automatisées et bardées de contrôle qualité, si personne n'est au commandes ?

Bref je suis de plus en plus dubitatif. D'un côté je voudrais encore y croire, d'un autre côté la réalité est tellement loin de ce beau modèle de développement que je commence à voir venir le sciècle du "code discount" : pas cher, pas terrible, mais pas cher. 

Il me reste donc à aller élever des chêvres dans le Larzac ...

08 mars 2009

Des bugs partout !


Ce week-end j'organisais un "apéro Wii". On m'a donc gentillement prêté deux WiiMotes et un Wii Fit, et bien sur les jeux qui vont avec.

Après les 25 écrans de baratin du jeu Wii Fit on peut enfin faire deux trois mini-jeux rigolos. Autant le capteur est une originalité intéressante pour l'interaction, autant les jeux associés manquent cruellement de "fini". Je veux bien croire que la Wii n'a pas les possibilités 3D d'une PS3 mais tout de même...

Quand à Wii Play... à réserver au plus jeunes qui ont du mal à se servir de la WiiMote. Jeux basiques et graphismes à la limite de l'amateurisme.

A croire que Nintendo ne veut pas mettre la barre trop haut pour ne pas dégouter les développeurs ;p

Restait heureusement les lapins crétins pour me sauver la mise. Evidement, ce n'est pas le même public, mais le style comique et décallé du jeu donne à l'ensemble un style caractéristique bien agréable, très loin de l'aspect "c'est offert avec alors n'en demandez pas trop" des jeux Wii-* d'origine de la console.

Je me suis donc vengé en enchainant les mini-jeux des lapins crétins - les enfants aiment bien voir leur papa se trémousser en rythme devant son écran - avant de tomber sur l'impensable : un bug.

Dans le jeu des "radios sur la plage", on doit cogner sur les lapins (les règles sont assez simple) mais bizarement au bout d'un moment on a beau s'exploser le bras rien ne bouge. Il s'avère que c'est un bug qu'on peut corriger en configurant la Wii sur 60Hz :-/ Mais avant de découvrir ça on passe par une sacré suée à s'énnerver sur sa WiiMote.

Terrible pour un informaticien de voir que les bugs nous poursuivent même en week-end... est-ce que le code des lapins crétins est en opensource ? :D

06 mars 2009

Contribution à la doc gwt 1.6

Les petits gars de GWT, n'utilisant pas Maven, sont confrontés à une armée d'utilisateur qui se casse les dents à faire fontionner ensemble les deux outils. En tant que développeur du plugin Mojo gwt-maven-plugin ils m'ont donc demandé de leur accorder un peu de temps pour écrire une page de doc sur le sujet, à intégrer dans GWT 1.6.

N'hésitez pas à me faire part de vos remarques et à improver my english

Ils aimeraient bien aussi que le plugin maven soit prêt en même temps que la sortie officielle de GWT 1.6.final, mais on en est malheureusment pas encore là. Vous pouvez néanmoins m'aider dans cette voie en testant le SNAPSHOT et en traquant les anneries qui pourrait trainer dans la doc

24 février 2009

L'informatique du XXIe siècle

Si vous voulez connaître ma vision de l'informatique du XXIème siècle, un petit tour par la vidéo tournée par JavaBlackBelt lors de l'anniversaire du ParisJug s'impose :


Au programme : EJB1, datacenter d'Amstrad CPC et Offshoring des bugs

09 février 2009

Coup de pub

Juste un petit coup de pub pour vous annoncer l'ouverture du blog d'Arnaud Héritier, développeur et membre du "Project Management Committee" de Maven.

Vous avez probablement déjà lu ses articles sur le blog Octo, alors faites monter ses stats en lui rendant une petite visite, ça le motivera pour la suite ;-)


Rendez-vous au ParisJug

Le ParisJug fête son anniversaire mardi soir. 
Je viendrais y présenter le BreizhJug, en compagnie de représentants des nombreux JUGs provinciaux qui ont fleuris fin 2008.

Si vous êtes dans le coin, passez me faire un petit bonjour ;-)


31 janvier 2009

Bienvenue sur Facebook !

Invité sur Facebook, et pour une fois par quelqu'un que je connais vraiment, je découvre l'application de "social networking" qui fait craquer les moins de 25 ans. Comme j'ai (un peu) passé ce cap, je reste relativement septique sur l'utilité au quotidien de cet outil. Il faut reconnaitre tout de même la grande maîtrise de ses créateurs : IHM simple mais très complète, plein de chtit trucs Ajax pour une bonne ergonomie. De quoi passer quelques heures par jour pour savoir qui acheter comme ami.

"Amis à vendre" est probablement l'appli facebook la plus incroyablement inutile, donc absolument indispensable. Vous pouvez d'ailleurs m'aider à prendre de la valeur et me donner un pseudo correct (l'acheteur ayant le privilège de renommer son "achat") :

Je viens donc d'ajouter un twitter à ma page facebook, service que je n'utilise pas tellement plus, mais qui sait, en ayant un comportement de "jeune" je vais peut-être avoir les cheveux qui repoussent ? - allez pépé, arrête de blogger, c'est l'heure de ta tisanne.

30 janvier 2009

gMail offline


Depuis peu, google propose le très attendu gMail offline.

Il faut passer en version US et utiliser l'onglet "labs" qui permet d'activer des fonctionnalités à l'essai. Il faut bien sur aussi un navigateur intégrant Gears (dans mon cas : Chrome).

Le résultat est super : une appli web qui supporte les pertes de connexion, idéal pour les transports, ce qui était tout de même super limitant pour une utilisation "professionnelle" de gMail.

Faudra que je teste l'API Gears pour le BreizhJug, ça m'évitera une fois sur deux d'avoir des soucis avec l'accès au Net pour faire le tirage au sort !

un iPod pour 2009 !

Non, je n'ai pas craqué pour le joujou de Steeve Jobs. 

Hier soir avait lieu la soirée annuelle de mon agence. Des prix ont été décernés, et j'ai reçu celui de l'innovation (et oui !). En cadeau, en plus de la bise de mon patron, un iPod 8Go

J'ai merdé pendant dix minutes avant que quelqu'un m'explique que le truc rond est tactile et qu'il faut "tourner" pour descendre dans les menus. Si Steeve est le roi de l'ergonomie - et un génie du marketing aussi - je dois avoir pris un train de retard... 

C'est dur de découvrir qu'on est plus dans la tranche d'âge cible de ces joujous :D