Rechargement à chaud et Développement Google App Engine / Maven

appengine mavenGoogle App Engine est une plateforme vraiment sympa. En plus d’être multi-langage (Python, Java, Go et Php), App Engine fournit tout un tas de services appréciables, tels qu’un DataStore intégré, un BlobStore, une gestion de Cache, un service d’envoi de mail et j’en passe… Retrouvez la liste complète ici : https://developers.google.com/appengine/docs/java/apis

Bref, C’est un PAAS complet et performant, qui a fait ses preuves en production.

Mais parlons maintenant de confort de développement.

Je suis développeur Java, et j’essaye autant que possible d’avoir des projets standardisés autour d’un outil de build, au hasard Maven. A priori, tout va bien, Google fournit le plugin qui va bien. Si l’on suit les instructions et que l’on construit correctement son projet, tout devrait bien se passer. Plus qu’à lancer en local mon serveur et ses services associés :

mvn appengine:devserver

Mon projet se build, mon serveur se lance, ma jolie page HTML s’affiche, je suis content !

Habitude oblige, je laisse mon serveur tourner et je commence à modifier mes pages HTML. Sauvegarde, F5, et……. rien. Ma page n’est pas actualisée. Pourquoi ? Et bien le serveur App Engine qui est lancé se base sur votre dossier target généré par Maven. Et sans nouveau build, aucune raison que ce dossier n’évolue.

Alors comment faire pour profiter des fonctionnalités App Engine (datastore par exemple) en local, tout en pouvant développer son Front-End confortablement ?

L’objectif est d’arriver à découpler le Front et le Back End… Le serveur App Engine, qui contient les fonctionnalités du back-end qui nous intéressent, pourra être lancé une fois à l’aide de Maven, disons sur le port 8000. Pour configurer le port, il suffit de changer votre POM :

<plugin>
   <groupId>com.google.appengine</groupId>
   <artifactId>appengine-maven-plugin</artifactId>
   <version>${appengine.target.version}</version>
   <configuration>
     <port>8000</port>
   </configuration>
 </plugin>

Maintenant, nous allons ajouter un serveur qui nous servira le front, par exemple Jetty. Hop, on alimente le POM.xml avec le plugin qui va bien :

<plugin>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-maven-plugin</artifactId>
   <version>9.0.3.v20130506</version>
 </plugin>

On lance notre Jetty (qui lui se lancera sur le port 8080)

mvn jetty:run

On ouvre notre navigateur favori, on va sur localhost:8080 pour attaquer notre Jetty et si tout s’est bien passé, le site apparaît… On modifie l’index.html (par exemple), on sauvegarde, F5 sur le navigateur, et la modification est bien prise en compte, ouf !

Problématique : à un moment, votre front va vouloir parler au back, par exemple à travers une requête REST, L’objectif est donc d’appeler son serveur App Engine, qui se trouve sur un autre port. On fait un petit Hack dans son code Javascript pour appeler la bonne URL, on lance sa requête, et…. Erreur dans le navigateur, Requête Cross Domain non autorisée. Et oui, un navigateur ne lance pas de requêtes vers un autre site, question de sécurité ! Pour Chrome, il existe une solution simple, le lancer avec l’option

--disable-web-security

Mais ce n’est pas l’idéal. Pourquoi ? D’abord parce que cela compromet votre navigateur si vous l’utilisez pour vous balader sur le net. La seconde raison est que de toute façon ça vous oblige à avoir un petit hack dans votre code côté client pour faire pointer vos requêtes vers le bon port.

La Solution ? Apache 2 et un Reverse Proxy

Alors comment faire ? Ma solution est d’avoir un troisième serveur, en frontal, qui va décider vers qui envoyer vos requêtes vers App Engine ou Jetty. Pour ma part j’ai choisi Apache2 et son module Proxy / Reverse Proxy qui fait ça très bien. (Documentation officielle : http://httpd.apache.org/docs/current/mod/mod_proxy.html )

Pour résumer ma configuration Apache 2 : Un fichier apache2.conf qui écoutera le port 80

Listen 80

Et la définition d’un site (il faudra avoir chargé les modules adequat auparavant, cf documentation officielle) :

<VirtualHost localhost:80>
   ServerAdmin webmaster@localhost
   ServerName localhost

   ProxyRequests Off
   ProxyVia Off

   ProxyPass /_ah http://localhost:8000/_ah
   ProxyPassReverse /_ah http://localhost:8000/_ah

   ProxyPass / http://localhost:8080/ 
   ProxyPassReverse / http://localhost:8080/
</VirtualHost>

Maintenant, quand avec mon navigateur je vais sur http://localhost/, Je sais que toutes mes requêtes REST qui sont préfixées par « _ah » sont redirigées vers App Engine sur le port 8000 par le reverse proxy, le reste allant vers Jetty.

Mission accomplie 🙂

Conclusion

On résume.
J’ai un Apache frontal qui dispatch mes requêtes vers Jetty ou App Engine en filtrant les URL appelés grâce à un Reverse Proxy.

Maven Apache frontal

OK, j’entends d’ici la critique : il faut vraiment lancer 3 serveurs différents pour pouvoir développer confortablement un simple site Web hébergé sur App Engine ? Prenons le temps de relativiser, et intégrons le fait qu’App Engine transporte avec lui sa persistence, c’est déjà un service d’économisé.

Dans mon exemple, j’aurais pu aussi éviter de devoir lancer Jetty. En effet, si mon front-end est 100% statique, aucune JSP à compiler ni rien, je pourrais demander à Apache de me restituer directement mes fichiers statiques en configurant un Directory qui pointe vers mon projet dans le VirtualHost. Qui plus, mon Apache est démarré comme service, et une fois lancé il est fait pour être oublié !

Passer une heure à configurer tout ça est un sacrifice que je referai tant les services rendus sont appréciables, le résultat étant un projet buildable, intégrable dans une usine de développement continu, testable et facilement déployable dans un environnement puissant.

LB.

Instacode

Juste un petit pointeur vers un site que je  trouve rigolo : Instacode.es ! A quoi que ça sert ? A la mode Instragram, ce site va proposer d’appliquer quelques filtres stylés à des captures d’écran de code.

Deux choses que je trouve intéressantes :

  • Il existe un plugin IntelliJ, qui après sélection d’un bout de code, va l’envoyer à Instacode en pré-sélectionnant le bon langage. Simple, efficace.
  • L’interface cliente est faite en WebGL ! De la 3D pour appliquer ses filtres, faire pivoter son bout de code dans l’angle qui nous plait le plus, j’aime bien…

Pensez-y pour illustrer quelques slides un peu tristes !

64079

 

L’évolution de carrière dans l’informatique

toulouseLe week-end dernier, j’étais à Toulouse, retour dans mon ancienne vie, mes anciens collègues, aujourd’hui mes amis. C’était bien entendu l’occasion de parler potins, ragots, évolutions, savoir qui a démissionné et où chacun est parti.  C’était aussi l’occasion de remettre un débat sur le tapis : pour nous, développeurs, quelles possibilités d’évolution de carrière ? Mais au fait, qu’est ce que c’est l’évolution de carrière ? Comment ça se mesure ?
Continuer la lecture de « L’évolution de carrière dans l’informatique »

[Programatoo] Greenfoot, Kinect, et Ubuntu 64 bits !

GreenfootEn ce moment, un de mes hobbits (haha) dans le cadre de Programatoo, c’est de jouer avec Greenfoot. Mais qu’est ce donc? Et bien c’est un logiciel créé pour introduire le langage Java et la notion d’objets auprès d’apprentis développeurs. En quelques mots, il permet de définir en Java des objets (Actor) qui vont pouvoir évoluer dans un monde (World). C’est bien foutu, même si l’interface mériterait un petit coup de jeune.

L’un des intérêts de Greenfoot, c’est que l’on peut facilement le faire intéragir avec une Kinect ! Une API bien faite, et des exemples sont fournis pour arriver rapidement à un résultat sympa, et les enfants adorent le concept de la Kinect. Après tout, coder en jouant avec la position de sa main, sa tête ou ses pieds, c’est plutôt fun !

Bref, tout cela mériterait un article à part entière. Mais pour l’instant on va se concentrer sur la première étape: l’installation ! Pour Greenfoot, pas de soucis, ça s’installe bien, à l’aide d’installeurs automatiques dédiés à différentes plateformes.

Greenfoot et Kinect

Si l’on souhaite aller plus loin, avec pourquoi pas le branchement d’une Kinect, l’installation peut se corser. Je vais tâcher de donner quelques astuces pour mes soucis rencontrés, c’est à dire avec deux distributions Ubuntu 12.10, l’une 32bits, et l’autre 64bits. La documentation Greenfoot étant assez bien faite et complète, on arrive très vite sur un tutoriel :

http://www.greenfoot.org/doc/kinect/ubuntu.html

Dans le cadre de ma distribution 32 bits, le tutoriel est parfait, à deux détails prêts. A l’étape 0, les packages présentés n’étaient pas disponibles chez moi, j’ai remplacé libglut3-dev par libglui2c2

1
2
sudo apt-get install g++ libboost-all-dev libglui2c2
sudo apt-get install libwxbase2.8-dev libwxgtk2.8-dev wx-common

Le deuxième soucis que j’ai eu, c’est qu’une fois l’installation terminée, la Kinect n’était pas reconnue. Il suffit juste de recharger le module adequat :

1
sudo modprobe -r gspca_kinect

Et en 64 bits alors ?

Et bien là, n’essayez pas de suivre le tutoriel, cela ne fonctionnera pas. Le tutoriel est fait pour faire télécharger OpenNI, NITE et le driver en 32 bits (stockés sur le site de Greenfoot), il y aura forcément un problème de dépendance au moment de l’installation. Plusieurs solutions s’offrent alors à vous:

Une fois que OpenNI, NITE et le driver sont installés, il faut tout de même installer KinectServer qui fera la passerelle entre Greenfoot et OpenNI. Pour cela se référer à la fin du turoriel disponible sur le site de Greenfoot.
(A noter que je n’avais pas utilisé Simple-OpenNI à la base, mais l’installation manuelle de chaque élément, et pour la peine KinectServer n’arrivait pas à se connecter à la Kinect… Il faudrait que je comprenne pourquoi)
S
i la Kinect n’est pas reconnue à la fin de l’installation, pensez à recharger le module adequat, comme pour le mode 32bits.

Une fois que KinectServer est lancé, vous pouvez ouvrir Greenfoot puis les projets d’exemple fournis pour Kinect, qui sont une bonne base de travail !
Have Fun !

LB.

PS : Pour avoir une traduction récente et en Français de l’interface Greenfoot, vous trouverez votre bonheur sur mon compte Github !

Démarche de recrutement : comment ne pas tomber au 42ème étage…

Bientôt un an que je suis développeur Parisien, le temps est passé vite… Cet article sera une tentative de feedback, histoire de raconter comment, et pourquoi je pense avoir fait le bon choix.

Petit retour en arrière…

Ne soyons pas mesquin, pour ma précédente, et première expérience professionnelle, j’aurais pu tomber sur bien pire ! (Citons les : Infotel, à Toulouse). J’y ai bossé au forfait plus de 4 ans, principalement pour Airbus… Une bonne ambiance, de très bons amis et une structure très professionnelle dans la gestion des projets, j’y ai vraiment énormément appris. Le problème d’une société de service Toulousaine, c’est qu’il est souvent difficile de toujours proposer à ses collaborateurs des projets super excitants quand son plus gros client s’appelle Airbus. La façon de faire d’Airbus est de mettre sur le marché des pools de projets, avec des choses plus ou moins funky, et si une SSII le gagne, c’est du boulot assuré pour 50 personnes pendant 3 ans au moins… Autant dire que pour l’entreprise, difficile de refuser.
La conséquence directe avec ce genre de projets, c’est que Struts 1, JSP et IE6, à Toulouse, ça nous connait ! 🙂 La marge de manœuvre technique était assez faible avec un client comme celui-là, d’après mon expérience en tout cas.

Bref, on se lasse un peu vite du contenu purement technique. Pour palier à ça, mon réflexe a été de me tourner vers le Toulouse JUG. Et là, paf, une révélation! On se met à rencontrer plein de geeks qui codent avec plaisir, et qui sont payés pour le faire 😉 Et puis ça permet de découvrir, se tenir à jour, de discuter, de se faire peu à peu un cercle de connaissances, tout en partageant Tariquet, Saucisson et autres mets raffinés !

Comment en sortir ?

Vint le jour où j’ai voulu déménager pour Paris… Bon. Comment trouver du travail et surtout comment s’y retrouver ? Solution de facilité : un CV sur Monster…. Hors de question. C’est un peu comme ça que j’avais trouvé ma première boite, mais la donne avait changé, j’avais un peu d’expérience, et ce coup-ci j’avais envie de choisir mon entreprise, et pas l’inverse. J’étais encore partant pour une SSII, je voulais voir différents types de mission, plus courtes si possibles, techniquement plus sympas, et SURTOUT, sentir que ma boite était derrière moi, soutenait la communauté des développeurs et en voyait la vraie plus-value. Avec ces critères, le premier site sur lequel je me suis dirigé est le site… du Paris JUG ! Et hop, colonne Sponsors… Une 15aine de sponsors, parfait, j’ai même le choix ! A partir de là, on commence à s’inscrire à des mailings lists de développeurs parisiens pour prendre la température, commencer à connaître les noms qui comptent… On suit les gens sur Twitter, et rapidement on voit que l’un des Jug Leader parisien tient un site de recrutement orienté offres de qualité, pour développeurs passionnés… (Coucou Nicolas Martignole, et merci pour ton site de recrutement !). Ma méthode a été simple, j’ai bêtement filtré les offres d’emploi disponibles avec les sponsors du Paris JUG que j’ai repérés, pour tomber à 4 ou 5 entreprises. Et voilà, si on enlève 2 ou 3 autres repérages relatifs aux salaires, je n’ai vraiment postulé que dans ces quelques sociétés. Pour être honnête, je ne les connaissais pas, mais je savais que je signerais chez l’une de celles-là, si j’étais à la hauteur, bien entendu.

La suite, c’est une touche de hasard, des emplois du temps compliqué (gérer ses entretiens à 800km, ce n’est pas si simple 🙂 ), du feeling, et un petit détail qui m’a aidé à me décider : le 42ème étage ! Vous en avez surement entendu parler, de cette Web-Série bien geek caricaturant les SSII, leurs gestions des ressources humaines inexistantes, et leurs perfides commerciaux :p J’ai aimé la façon dont Sfeir, la SSII à l’origine de la Web Série, voulait se démarquer de ses concurrentes de façon originale, sans trop se prendre au sérieux. Je ne vais pas le cacher, les autres entretiens parallèles s’étaient aussi très bien passés, et je n’avais pas trop de critères objectifs pour choisir. Alors voilà, le choix d’une entreprise ne tient pas à grand chose des fois… Quelques entretiens plus tard, j’avais signé !

Bilan

Durant cette année, j’aurais assisté, avec le soutien de Sfeir, à Devoxx France, à Devoxx World, je suis encouragé à venir échanger avec mes collègues une fois par mois autour de différents sujets techniques (les BOFs), j’ai rencontré des collègues passionnés, je me surprends à vouloir apprendre la programmation aux plus jeunes, on m’a même envoyé à La Rochelle pour en parler (au JUG Summer Camp)… Pour l’anecdote, si vous fouillez dans certains épisodes de la deuxième saison de 42ème étage, vous pourrez même tenter de me reconnaître ! (Oui oui, chez Sfeir, nous sommes plein de talents cachés !)
Plus concrètement je commence à me dépatouiller en Scala, je connais tous les buzz word et les noms des 1000 frameworks du moment, et encore, tout ça c’est sans compter les collègues motivés qui m’ont emmené des dizaines de fois rencontrer plein d’enthusiastics du Paris JUG, du GDG Paris, aux Meetup HTML5, au Paris Scala User Group, et j’en passe !

Bref, professionnellement cette année a été vraiment très riche. Et je pense que les choses auraient été moins cools si je m’étais entouré différemment en arrivant à Paris !

En espérant que ma démarche puisse aider l’un d’entre vous, et surtout vous croiser dans un évènement bien geek en 2013 !

LB.

ANNEXES

Sites de recrutement auxquels je me fierais facilement :

Liens relatifs à SFEIR et la web-série 42ème étage :