[Toulouse-pm] OSCON 2006, Mardi

[Michel Rodriguez]

   Mardi matin
     Donc me revoila tout frais, après une soirée tranquille hier soir, en
     companie de quelques italiens, vu qu'il faut bien que je bosse un peu
     (mon italien) pendant cette conf. donc quelques bières, peu de chanve de
     convaincre 2 adeptes de Rails que Perl est bieng mieux, et au dodo.

    Real World Web Services - Scott Davis
     <http://www.davisworld.org/presentations/handsOnWebServices.pdf> est une
     partie de la présentation.

     Et oui, c'est l'année du ouèbe tout poynt ziro, donc je m'intéresse aux
     technologies de l'an dernier... mais vous inquiétez pas, O'Reilly donne
     un livre gratuit aux participants, et j'ai choisi "Ajax Hacks".

     Il commence par un peu de pub pour sa boite, dont je tairais le nom
     parce que je suis méchant et rancunier.

     Au passage, pour taper les compte-rendus en français sur un clavier US,
     quelques imap en vi comme ":imap e' é" évitent de taper <CTRL-K>
     avant... bien pratique, et ça me donne l'impression de pas avoir perdu
     mon temps hier. Ca donne juste des trucs un peu bizzare avec le curseur,
     après une voyelle il se positionne _devant_ la lettre pendant 1 seconde,
     mais on s'y habitue. Remapper <CTRL-N> sur <TAB> est aussi excellent, ça
     auto-compléte les mots si je les ai déja utilisés dans le fichier (ça
     tombe bien, je me repète souvent et j'ai un vocabulaire limité). Je ne
     peux plus taper de tabs, mais de toute façon j'aime pas les tabs, et ça
     sert à rieng en POD.

     Maintenant une longue liste d'accronymes... beurk!

     Bonne idée, il donne les définitions des accronymes tirées de Wikipedia.

    SOA
     Il commence par SOA: au choix Service-Oriented Architecture, ou
     Sarbanes-Oxley act (si vous savez pas ce que c'est, vous avez bien de la
     chance, ou Soldiers of Allah)

     <http://en.wikipedia.org/wiki/Service-oriented_Architecture>

     Il parle beaucoup, vite, donc ça va être dur de tout retranscrire, je
     pense que je vais devoir me limiter à vous donner les liens vers les
     définitions.

    WS
     Maintenant on passe à Web Services (WS)

     <http://en.wikipedia.org/wiki/Web_service>

     Un truc: un web service n'est pas forcément en XML, le plus important
     c'est qu'il soit "remote", et "message-oriented". En plus il devrait
     être "platform-independant", "vendor-neutral" et "internet-based".

     Pour l'instant c'est un peu du vent quand même, beaucoup de "c'est
     super" et pas beaucoup de détails technique.

    Ajax
      L<http://en.wikipedia.org/wiki/Ajax_%28programming%29>.

     Client/SOA: pour certains c'est l'étape après Ajax. Un gros problème
     cependant: XSS (cross-site scripting), les requêtes Ajax ne peuvent pas
     contacter un server dans un domaine différent pour limiter le risque. On
     pourrait avoir du javascript signé par le site web d'origine, mais ça ne
     marche pas cross-browser. Donc ça doit être le serveur d'origine qui
     appelle les autres sites web pour le client. Par exemple on peut avoir
     un proxy qui gère les appels à différents sites. Là ça commence à
     devenir intéressant.

     <http://en.wikipedia.org/wiki/Client/SOA>

    Web 2.0
     Donc comme c'est une conférence O'Reilly, il doit maintenant nous causer
     de Web 2.0

     Il demande à la salle: qui a déjà utilisé Mapquest? Toutes les mains se
     lèvent. Qui à déjà utilisé Google Maps? Pareil. Qui a utilisé Mapquest
     depuis que Google Maps existe? 3 mains! Web 2.0 - Web: 1 - 0

     Mash-ups: pour ceux qui vivent dans une grotte, c'est la combinaison de
     données venues de plusieurs sources. Exemples
     <http://www.chicagocrime.org/map/>.

     Au passage, en cherchant autre chose, je tombe sur un catchpa sympa:
     <http://www.hotcaptcha.com/> (pas forcément un truc à voir au boulot)

    SOAP
     <http://en.wikipedia.org/wiki/SOAP>

     Avant SOAP il y avait XML-RPC, qui une fois trituré par un commité est
     devenu SOAP (la trituration à été assez importante!).

    WSDL
     <http://en.wikipedia.org/wiki/WSDL>

     SOAP est le format du message, WSDL décrit l'interface du WS.

     Il y a plein d'outils pour générer au moins un squelette de code à
     partir du WSDL... en Java. En Perl je sais pas, les spécialistes peuvent
     nous dire.

    UDDI
     <http://en.wikipedia.org/wiki/UDDI>

     Pas vraiment utilisé, au contraire des 2 précedentes technologies. Ca
     permet de faire des répertoires de WS, mais en pratique on récupère le
     WSDL directement, sans passer par une étape intermédiaire.

    SOAP en action
     SOAP avec l'API WS de Google (en béta depuis le dernier millénaire).

     Il nous montre le format des messages, requêtes et réponses. Je tape pas
     assez vite pour retranscrire le tout! En plus ça cause surtout Java,
     fait chier.

     Il nous montre le résultat de WSDL2Java sur le WSDL de Google. Puis
     déclare que c'est pas trop joli, donc il préfère utliser l'API fournie
     par Google, plus pratique.

     Je vous passe le code en Java, pour ne pas me faire virer de la liste.

     Pause, il est content que tout le monde revienne après le café.

     Une remarque du public: pourquoi c'est tot en Java. Il s'excuse et avoue
     que ses exemples en Perl sont trop horrible pour qu'il les montre en
     public.

     Conclusion sur SOAP: c'est lourd, pas vraiment browser-friendly. Donc on
     va passer à:

    REST
     <http://en.wikipedia.org/wiki/Representational_State_Transfer>

     Plus simple (mais il y a quand même une thèse par Roy Fielding dessus
     (<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>)

     Il y a 2 types d'applications REST: pur REST, qui suit les principes
     développés par Fielding, et "popular REST", en fait tout ce qui est WS
     mais pas SOAP.

     Il explique l'origine du terme "cargo-cult"
     (<http://en.wikipedia.org/wiki/Cargo_cult>)

     Le principe c'est de faire des requêtes simplement avec une URL et des
     paramêtres, et de récupérer le résultat en simple XML (ou en fait autre
     chose, genre JSON). Ce qui est cool c'est qu'en regardant la requête on
     la comprend. Par contre il faut lire la définition de l'API pour pouvoir
     l'utiliser, il n'y a pas l'équivalent de WSDL (encore qu'il semble qu'il
     y ait un projet pour ça).

    Rest en action
     Un service REST: Yahoo! Ca tombe bien, ça complète bien le service SOAP
     de Google. Effectivement, sur ce qu'il montre, c'est bien plus simple à
     utiliser que le WS de Google. Pas besoing de générer le squelette du
     client, c'est tellement simple qu'il n'y en a pas besoin!

     Il demande: "comment rendre ça sûr?" Ben de la même façon qu'on rend un
     site web sûr: https!

     C'est un des avantages de REST: ça réutilise l'infrastructure existante
     (ceci dit il me semble qu'on peut faire ça aussi avec SOAP).

    REST toujours
     Un exemple avec l'API REST d'Amazon (Amazon a aussi une API SOAP, mais
     vraiment c'est plus simple d'utiliser l'API REST).

     <http://awszone.com> présente un peu toutes les possibiltés offertes par
     Amazon. Je peux pas trop tester le site, la connection wireless est pas
     terrible ici (pour une raison à laquelle je n'aurais pas pensée:
     <http://radar.oreilly.com/archives/2006/07/oscon_kicks_off.html#comments
     >), mais le site a l'air assez impressionant: il présente aussi la
     version SOAP du service, génére du code si on veut... la totale ("really
     cool stuff" d'après le speaker).

     Il fait une erreur en tapant le critère de tri dans une requête,
     récupère un message d'erreur: avec SOAP il aurait utilisé le WSDL et
     n'aurait pas eu ce problème (mais bon, s'il avait lu la doc du service
     REST non plus, et pis les tests devraient révéler l'erreur assez tôt
     dans le processus de développement).

    Un peu de philosophie sur REST
     En fait, pour lui, il n'y a pas vraiment de différence philosophique
     entre la version SOAP (Google) et la version Yahoo! (REST).
     L'implémentation est différente, mais le code suit exactement les même
     principes.

     Il rentre dans une discussion sur la différence entre URI et URL. Les
     vrai RESTeurs (ou RESTafarians) affirment que seule les URIs devraient
     être utilisées, pas les URL. Il avoue ne pas vraiment être d'accord.
     J'avoue ne rieng comprendre au débat! Donc j'en profite pour aller faire
     un tour sur le site de la Gazzeta dello Sport pour voir le résultat de
     l'appel des clubs punis... zut, ça sera dans demi-heure, donc je
     retourne à mon compte-rendu, vous avez de la chance.

     Je vois qu'il recommande de jeter un oeil à
     <http://www.xml.com/pub/a/2004/12/01/restful-web.html> (et aux autres
     articles du même auteur (<http://xml.com/pub/at/34>).

     Une des forces du "popular REST" est qu'en utilisant GET, ça permet de
     bookmarker facilement le résultat d'une requête. Bien sûr ça limite
     aussi la taille des donnés passées entre le client et le serveur. Il n'y
     a pas de règles qui force à utiliser GET, mais c'est recommendé pour
     respecter l'esprit REST.

    Encore quelques exemples de services REST
     Un peu de Google maps (obligé non?). Il nous montre le lien généré par
     le bouton "link to this page". Ca montre bien l'interêt de REST, qui
     permet de retrouver facilement les choses, en donnant une URL à tout les
     résultats renvoyés par un service.

     Par exemple je suis là:
     http://maps.google.com/maps?f=q&hl=en&ie=UTF8&t=k&om=1&ll=45.529508,-122
     .663008&spn=0.001853,0.003573

     Atom suit aussi les principes REST (et au passage, je trouve Atom bien
     mieux fait que RSS, c'est plus logique, ça permet de mettre à peu près
     tout ce que je veux dans le feed... recommandé!)

    JSON
     Le principal avantage de JSON, c'est que ça n'est pas XML! (*"we don't
     need no stinkin' XML"*) C'est dur de parser du XML en Javascript, tandis
     que JSON ça se charge hyper facilement en Javascript dans le client.
     Malgré mon (lourd!) passé XMLien, je dois dire que je suis complètement
     d'accord. Tiens, je savais pas que JSON est un sous-ensemble de YAML.

     json.org pour plus d'info. En perl on a JSON et JSON::Syck (parce que
     *"JSON is YAML"*)

    ESB
     Un dernier accronyme pour nous achever, mais je saisis pas ce que ça
     veut dire: le E est pour "Enterprise", donc mon cerveau se déconnecte
     automatiquement, désolé.

     C'est fini, c'était pas mal en fait, des fois d'un peu trop haut niveau,
     et un peu marketing parfois, mais c'était un bon tour d'horizon quanf
     même.

     Bon, je vais devoir aller manger sans savoir ce qui se passe en
     Italie... je pense que je survivrais quand même.

     A plus.

   Mardi Après-midi
    Rolling your own Google Maps - Scott Davis
     Il recommence avec sa pub au début du cours.

     Il commence par expliquer en quoi Google maps est important:
     l'utilisation de Javascript et CSS pour une application complètement
     nouvelle, et impossible à faire sans ça. En plus il n'y a pas besoin de
     plug-in pour s'en servir.

     En plus Google a publie' une API pour Google maps.

     Les limitations du service: c'est gratuit, mais pas libre. L'utilisateur
     DOIT utiliser l'API fournit par Google.

     2 frameworks pour faire la même chose: MapBuilder
     (<http://mapbuilder.sourceforge.net/>) et OpenLayers
     (<http://www.openlayers.org>)

     Donc attaquons la partie pratique: créons notre propre appli!

     Le code est disponible pour les participants au cours, il sera
     disponible pour le public dès que le livre qu'il est en train d'écrire
     sera publié. Donc vous n'aurez pas le code aujourd'hui, juste la
     description de la démarche qu'il utilise.

     Version 1: d'abord on crée une image avec des "tiles", dans une table, 3
     lignes, 4 colonnes.

     Version 2: il crée 2 "div"s autour de la table: une qui définit la table
     entière, et une qui définit la partie affichée de la table. Il utilise
     CSS pour que la partie affichée soit plus petite que la table entière.

     Version 3-5: Il commence à écrire le js qui fait bouger la table
     entière. Du coup la table affichèe montre une autre partie de la table.
     Il assigne ça au drag-n-drop de la souris (entre mouseDown et MouseUp il
     "dragge"). Il utilise prototype (librairie javascript).

     Un truc qui me plait: dans son script il écrit "Event.observe( window,
     'load', myscript, false);" au lieu de mettre le script dans l'attribut
     "onload" du tag "body". Je débute en js, et c'est le genre d'info que
     j'apprécie (je sais pas si c'est spécifique à prototype ou si ça marche
     de base en js, j'essaierai plus tard). Le "false" empêche l'évênement de
     "bubbler".

     Version 6: il ajoute un peu de code pour empêcher l'utilisateur de
     dragger trop loin, pour bloquer le déplacement de la table entière.

     Version 7-8: Il se débarasse de la table, et commence à faire des
     calculs (semi-)sophistiqués pour savoir quelles sont les lignes/colonnes
     affichées et ajuster le positionnement de la carte entière avec CSS,
     puis il télécharge les images (toujours de fausses images à lui.

     Bon, en fait ce tutorial me fait quand même un peu chier. Ce genre
     d'exercice, pour moi, ça marche si c'est un TP. Mais suivre un mec qui
     explique son code au podium pendant 3 heures, ça commence à me fatiguer.
     Donc je suis pas sûr de rentrer aprés la pause...

     Ma conclusion perso sur ces 2 cours est que Web Services ou Google maps
     ou Ajax bidule... au bout d'un moment, c'est plus la peine de lire des
     papiers ou d'aller à des cours, il faut se poser devant le clavier et
     JFDI (*"Just Fucking Do It!"*).

     Doc... ce soir il y a la soirée MySQL au bar d'un des hotels de la conf,
     puis le State of The Onion de Larry Wall, donc c'est l'heure d'aller
     faire la sieste et de prendre des forces.

     Ciao

-- 
Michel Rodriguez
IEEE Standards - Electronic Services