Devoxx France 2012 – 2ème Partie

Restlet

Open API

Dans sa présentation de Restlet, Jérôme Louvel commence par une explication des avantages de l’Open API.

L’Open API c’est fournir des API publiques, libres. Cela permet d’enrichir un site (affichage de tweets, de blogs, etc.) ou encore de créer des API composites.

Cela permet aussi d’exposer son service sous différents formes : mobile connecté, mobile natif, HTML5/Js, API partenaire, etc.

Jérôme Louvel explique par la suite qu’il s’agit d’une évolution logique de l’open source. Après les OS, les serveurs d’application, les API aussi deviennent Open.

Prenons l’exemple de twitter. Il fournit des API publiques pour afficher ses tweets, pour faire des recherches ou encore faire du streaming. Ces Open API permettent à d’autre société de fournir un meilleur service à leurs utilisateurs.

Un autre exemple bien connu sont les Open API de Google Map qui permettent à beaucoup de société de fournir à leurs utilisateurs un service de localisation ou de navigation à moindre coût.

Il est important de comprendre que ces Open API sont en fait des services rendus et ont aussi un cycle de vie et des montées de versions. Le contrat peut évoluer. Il faut donc bien gérer ses API avec sa documentation, maintenir des anciennes versions actives.

Restlet

La conférence se poursuit ensuite par la présentation de Restlet framework dont Jérôme Louvel est le créateur. Ce framework permet d’exposer ou de consommer des API REST et est donc centré sur http.

Le meilleur moyen de standardiser un service est de le fournir sous la forme d’un service REST. Il sera alors consommé via http par un autre site, un navigateur, une application mobile native, etc.

Restlet fournit un support du REST natif, il suit de très prêt les évolutions du protocole http. Il fournit plusieurs éditions (JEE, GWT, Google App Engine, Android, etc.), gère différents modes d’authentification (SSL, Google SDC, Amazon, etc.)

Restlet fournit par ailleurs différents connecteurs, supporte différents formats (Atom, RSS, JSON), gère les uploads de gros fichier, etc.

Le développement des API Restlet en Java se fait via des annotations qui sont beaucoup moins verbeuse et plus intuitives que les annotations JAX-RS.

APISpark

Jérôme Louvel nous a ensuite fait une présentation de APISpark, l’offre PAAS de Restlet. Cette plateforme permet de créer rapidement ses API, d’avoir un hébergement haute disponibilité, sécurisé et fortement scallable pour les montée en charge et gère enfin les différentes versions des API.

APISpark met à disposition des documentions automatisées des API, fournit des clients pour utiliser vos API sur Android, Iphone, Ipad, .Net, Java, etc.

Un servi ce de reporting est aussi disponible permettant de voir les temps de réponse, les type de client, leur localisation, etc.

Les slides de cette présentation sont disponibles sur http://www.slideshare.net/jlouvel/de-lopen-source-lopen-api-avec-restlet

Une idée de Startup ?

Présentation

Camille Roux nous a fait une présentation très intéressante sur comment démarrer une startup. L’idée de est définir les étapes qui permettent de ne pas se perdre, de minimiser les risques ou les impacts d’une idée mauvaise ou incomplète.

Camille Roux est un entrepreneur hyper actif J Il a créer avec son associé différentes idées comme la série des site Live (PhpLive, HTML5LIve, JsLive, JavaLive, RubyLive), des sites de recherche d’emploi spécialisés, etc.

Startup Weekend

Il participe aussi très activement aux startup weekends. Ce type de réunion créé des équipe de 6 personnes (3 marketeux + 3 techos J) pendant deux jours. Le premier jour, ils définissent une idée, l’affine, la mette en forme et le deuxième jour, ils codent un proto très simple déployé sur le cloud. Cette méthode montre combien chacun peut apporter sa pierre à l’édifice, à quel point un groupe peut être productif quand il ne se donne aucune contrainte et démontre aussi la vitesse de développement rapide.

Principe

« Le gaspillage est l’activité humaine qui consomme des ressources sans créer de la valeur » (Womak and Jones)

Cela implique que lors de cette phase de recherche et de validation de l’idée, rien de doit être fait sans s’assurer un retour immédiat, un constat, une validation. Pas de chichi, allez directement sur une fonctionnalité visible qui pourra être testée par vos béta testeur. Faites une fonctionnalité après l’autre. Ne pas se lancer dans le site complet qui fera tout et qui ne sortira que dans 2 ans. Les itérations, les boucles avec les testeurs, les adaptations (pivot sur l’idée de départ) doivent très courtes.

Lean Canvas

Camille Roux nous a ensuite présenté le Lean Canvas. Il s’agit en fait d’une matrice à remplir afin de visualiser les différents points d’une idée (Comment mesurer la qualité du service, qu’est ce qui me différencie de la concurrence, comment monétiser, les couts, les canaux de communication, etc.).

Cette matrice qui permet de mettre en évidence une idée mal équilibrée d’un point de vue business est un outil marketing mais qui est très simple à remplir pour un techos.

Process

Le fond de sa présentation est qu’une bonne startup n’est pas qu’une bonne idée mais surtout un bon process. Des idées il y en a plein (ca c’est lui qui le dit  J ) mais il faut surtout les travailler, les affiner, les tester, etc.

Les différentes étapes de ce process sont :

  • Customer Discovery : Trouver une cible, un manque ou un besoin sur un groupe d’utilisateur
  • Customer Validation : Vérifier que le business model est scallable et trouvez des clients passionnés dans cette cible. Si pas de client, reboucler sur la première étape pour affiner (pivot)
  • Customer Creation : Réfléchir à la monétisation du service !!!
  • Company Building : organiser la société

Une fois le lean canvas remplie, il faut ensuite être en contact avec un expert ou un référent via les réseaux sociaux par exemple, puis interviewer des cibles pour affiner sa connaissance du besoin et prioriser les fonctionnalités. Il faut ensuite faire la pub pour son service via les réseaux sociaux ou blogs et tester son idée ou les futures évolutions via des votes  pour toujours rester au plus proches des besoins immédiats.

A ce niveau là d’avancement, on peut sortir une Landing Page, qui permettra de tester son nom, son accroche, de faire des votes justement, de récupérer des premiers mails de clients potentiels, etc.

Enfin il faut réaliser le prototype puis le MVP (Minimal Valuable Product), à savoir le produit à moindre investissement qui répondra au besoin. Encore une fois, aller directement à l’essentiel.

Rails / Heroku

La présentation s’est terminer par une introduction à Rails qui permet de démarrer très rapidement une application et à Heroku qui permet de déployer son application sur le cloud en deux lignes de commandes (via un commit Git).

Les slides de cette présentation sont disponibles http://www.slideshare.net/camilleroux/comment-tester-et-amliorer-son-ide-en-un-minimum-de-temps-devoxx

DDD

Cette partie là sera développé dans un autre post (Merci Olivier J) mais l’idée reste la même : Eviter les grosses abstractions, éviter de quitter de vue le besoin premier, le service rendu.

Un modèle simple

L’idée générale est que le modèle de données ne doit pas s’éloigner du service rendu et doit être très proche de l’IHM.

Cela implique un gros changement dans la méthode de travail. On ne cherche plus à modéliser la terre entière dans un schéma de BDD illisible que l’on ne peut même plus imprimer J

Le modèle de donnée d’une application doit être non pas le reflet de la réalité mais le reflet du besoin. Grégory Weinbach va même plus loin en expliquant que les applications elles-mêmes peuvent être scindées en plusieurs applications pour simplifier. Tout ceci permet d’éviter de créer de la complexité qui ne fera que prendre du temps lors de la conception, de la réalisation mais aussi et surtout créera un risque fort lors de futures maintenances correctives ou évolutives.

La mort des Foreign Key

Il y a quand même un dommage collatéral à tout cela, c’est la mort des foreign keys J. Les données sont dupliquées.

Reprenons l’exemple de sa présentation : un écran de saisie de client, un écran de facturation et de livraison. Dans ce cas nous pourrions nous retrouver avec 3 tables (voire 3 applications) qui chacune stockerait le nom de la personne… En fait il faut voir cela avec les bases de données noSql (Cassandra) et le théorème de CAP (http://www.slideshare.net/mfiguiere/breizhcamp-jun-2011-haute-disponibilit-et-lasticit-avec-cassandra)

WOA

Cette partie là sera développé dans un autre post (Merci Olivier J) donc je ne fais que survoler l’idée générale

Principe

« Don’t fight the web »

Le web via http permet de gérer les problématiques de disponibilité, résilience aux pannes, scalabilité, etc.  Alors pourquoi s’embêter avec des serveurs d’application d’entreprise, des EJB ou des sessions, du RPC, etc. ? Http + REST + Cloud suffit à répondre aux exigences des SI d’aujourd’hui.

RPC / Synchrone / Stateful => REST / Asynchrone / Stateless

WOA et SOA

La Web Oriented Architecture (WOA) peut être considérée comme la mise en pratique de SOA appliqué au web. Il part du principe que le bus SOA est remplacé par le HTPP qui gère l’authentification et chaque ressource est disponible via une URI. Les services sont implémentés en REST et donc disponibles simplement via http.

Découpage d’application

On retrouve très rapidement les mêmes principes que dans la présentation DDD ou chaque application peut être découpée en un ensemble de services qui seront des applications indépendantes.

Le besoin de l’utilisateur est découpé en un ensemble de services REST indépendants. Il faut bien entendu choisir la bonne granularité de ce découpage.

Conclusion

En quelque sorte, mon résumé de toute ces conférences de DEVOXX France 2012 serait « ..la perfection est enfin atteinte non pas lorsqu'il n'y a plus rien à ajouter mais lorsqu'il n'y a plus rien à enlever." (Antoine de Saint-Exupéry)

Il faut revenir aux bases.

Finit les spécifications détaillées pendant 6 mois, finis les EJB, les sessions, les plans sur la comète, les mise en prod programmée en 2014, les utilisateurs anonymes, la gestion du back ou des bookmarks dans le navigateur,  etc.

Bienvenus aux applications REST, stateless, proche du http, aux modèles de données simples, proche de son IHM, aux réels besoins du moment de mes utilisateurs, la mobilité,  le cloud, etc.

Toutes ces bonnes pratiques permettent des cycles beaucoup plus court, permettent d’éviter de perdre du temps sur du déploiement ou la montée en charge, permettent de prendre en compte des besoins utilisateurs qui évoluent.

Ces pratiques sont plus rapides, flexibles et économiques.

Et bon, après toutes ses grandes idées, un paquet de livres à lire sur REST, Play, Rails, DDD, Node JS, etc. et des samples sur Heroku, Cloud Foundry, etc.

Et vivement DEVOXX France 2013 !

Enregistrer

Enregistrer

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.