dimanche 4 mai 2014

Aviapod Le Retour

 

C'est avec un plaisir non dissimulé, que je débute l'écriture de ce blogpost rapide pour effectivement annoncer, que le podcast aéro. Aviapod est de retour ! En effet, ma persévérance a payé et j'ai pu prendre contact avec Philippe, le créateur du podcast et ainsi lui donner envie de se relancer dans l'aventure avec le reste de l'équipe, voici comment cela s'est passé...

Après moult recherches infructueuses, j'ai eu l'idée de contacter par email Len Robinson, qui est un camarde de Philippe Ceretti, le créateur d'Aviapod et souvent cité dans le podcast. Len a eu la gentillesse de transférer l'email à Philippe, qui m'a alors répondu ! Ému et étonné de ma démarche, nous avons alors échangé par email nos impressions sur le travail abattu par l'équipe et rarement récompensé. En effet, une des raisons qui a fait capoter le projet est le faible feedback qu'a eu l'équipe à l'époque et ce au regard du travail accompli, car honnêtement un podcast d'une telle qualité demande une grande quantité de travail. Donc de fil en aiguille et après une bonne bouffe avec deux des pilotes et un pote à moi que j'ai embarqué dans l'aventure, nous avons décidé de relancer le moteur ! Donc, Aviapod next generation est en route avec à son bord, deux informaticiens et trois pilotes passionnés et super motivés pour reprendre du service.

La conséquence de cela est que j'ai retiré les anciens épisodes, qui seront pour certains réenregistrés pour un meilleur son et mis à jour avec la nouvelle formule. Le but de recycler des anciens épisodes est double ; en effet, cela permet à l'équipe de temporiser l'écriture et l'enregistrement de nouveaux épisodes et de diffuser à un rythme plus régulier et plus soutenu.

Si vous voulez en savoir plus, n'hésitez pas à scruter régulièrement le site http://aviapod.fr/ ou à vous enregistrer sur la landing page, afin d'être prévenu quand le site sera prêt (il est en cours de refonte totale) et faites tourner l'information !

Aviapodement vôtre,

jeudi 6 mars 2014

Découvrez Aviapod ! (MAJ)


*** Une mise à jour de ce billet a été faite et plus d'explications dans cet article ***

Pour débuter l'année, je vous propose un hors-sujet assez particulier pour ce blog, où cette fois-ci nous ne parlerons pas de byte/fonction/microprocesseur ou autres drôleries de développeurs, mais plutôt d'aviation. En effet, après l'informatique, l'aviation est l'une de mes autres (trop) nombreuses passions !

Il y a environ deux ans, j'ai eu la chance de m'initier au pilotage sur un Cessna 172 Skyhawk à Toussus-Le-Noble et pour parfaire mon éducation en la matière, je suis parti à la recherche de ressources me permettant d'approfondir mes connaissances sur le sujet. Ainsi, je suis tombé sur le podcast Aviapod, qui malheureusement et sans véritablement de raison apparente, a cessé d'émettre au bout du 22ème épisode.

Ce podcast était animé par trois pilotes de lignes et instructeur sur Airbus : Philippe Ceretti, Cyrille Aubry et Cyril Bez. Les émissions s'articulaient principalement autour des trois sujets suivants :
  • Des sujets techniques pratiques pouvant traiter par exemple des performances au décollage, la gestion du carburant, le vol IFR, etc…
  • Des sujets enquêtes et accidents dont le but n’était pas de montrer du doigt les erreurs de tel ou tel protagoniste impliqué dans un accident, mais plutôt de comprendre les causes et effets d’erreurs humaines et de conception ayant entrainé des accidents,
  • Des sujets consacrés à l'épopée de l'Aéropostale, qui retraçaient les exploits d’illustres pilotes comme Jean Mermoz, Antoine de Saint-Exupéry, Didier Daurat.
Chaque épisode pouvait traiter d’un ou plusieurs sujets suivant les disponibilités ou envies de chacun, mais le plus souvent, il y avait un chapitre « Rétrospective du mois » où Philippe Ceretti remontait dans le temps par décade en évoquant des événements marquants de l'histoire de l'aviation.

L’intérêt d’écouter ce podcast n’est pas tant les connaissances techniques ou historiques apportées, mais également le plaisir de partager l’histoire et la vie de pilotes chevronnés dans leur travail quotidien. Imaginé que vous ayez la chance de débuter le développement logiciel avec Dennis Ritchie qui vous donne des conseils sur votre design, c’est un peu la même chose.

Donc, comme ce podcast a disparu de la circulation après l’arrêt du site web et comme il m’est impossible de contacter les pilotes, pour leur demander la permission de diffuser ces fichiers, je vous propose de télécharger ces 22 épisodes, afin que vous pussiez profiter à votre tour d’Avipod, donc bonne écoute et pourquoi pas bon vol !

http://aviapod.fr/

Les épisodes du podcast seront mis en ligne toutes les semaines et ce afin de retrouver un peu l'esprit du Podcast. Pour vous abonner, il suffit d'importer le lien RSS ci-dessus :
  1. Rétrospective juin 2006, introduction à l’aérologie, la vie d’Alberto Santos Dumont,
  2. Rétrospective juillet 2006, les différents types de carburants, enquête et accident, l’Aéropostale,
  3. Rétrospective aout 2006, les limitations des masses structurales des avions, enquête et accident, l’Aéropostale,
  4. Rétrospective septembre 2006, la vie de Jean Mermoz,
  5. Les performances au décollage 1/2, enquête et accident,
  6. Rétrospective octobre 2006, l’Aéropostale et la vie de Jean Mermoz,
  7. Les performances et trajectoire d’envol,
  8. Rétrospective novembre 2006, l’Aéropostale,
  9. Les performances au décollage 2/2, enquête et accident,
  10. Rétrospective décembre 2006, l’Aéropostale,
  11. Rétrospective janvier 2007, l’Aéropostale, l’histoire de l’aviation,
  12. La véritable histoire de Gregory Boyington, la conduite technique d’un vol commercial,
  13. Rétrospective février 2007, l’Aéropostale,
  14. Rétrospective mars 2007, spécial enquête et accident et CRM,
  15. Rétrospective avril 2007,
  16. L’Aéropostale, l’histoire de l’aviation,
  17. Rétrospective mai 2007, l’Aéropostale, l’histoire de l’aviation,
  18. Rétrospective juin 2007, l’histoire de l’aviation,
  19. Rétrospective juillet 2007, un vol IFR commercial de A à Z (passionnant),
  20. Rétrospective aout 2007, l’Aéropostale,
  21. Rétrospective novembre 2007, l’Aéropostale, l’histoire de l’aviation,
  22. Rétrospective décembre 2007, les atterrissages automatiques,


dimanche 1 septembre 2013

Faire sa machine virtuelle sous Debian ARM avec QEMU



Introduction

L'objet de ce article est de vous expliquer comment faire pas à pas, sa machine virtuelle Debian Wheezy tournant sur un processeur ARM avec QEMU. Il est relativement simple de trouver des ressources à ce sujet sur le Web, mais je voulais apporter ma pierre à l'édifice sous forme d'un petit tutorial prêt à l'emploi.
A propos d'ARM et d'émulation, il faut savoir qu'au jour d'aujourd'hui, VirtualBox est incapable de virtualiser un OS tournant sur ARM, cela m'a donc obligé à m'intéresser de plus prêt à QEMU. Et si vous vous demandez pourquoi, je veux émuler de l'ARM, vous le serez au prochain épisode...


QEMU

QEMU est un logiciel développé à l'origine par le célébrissime programmeur Fabrice Bellard. Le succès de cet émulateur vient principalement du fait, qu'il est tout aussi capable d'émuler que de virtualiser. La principale différence entre l'émulation et la virtualisation est qu'un émulateur peut faire tourner n'importe quel OS invité, sur n'importe quel système hôte. Tandis qu'un virtualisateur ne peut faire tourner que des systèmes invités compatibles avec le système hôte. Ainsi, VirtualBox étant développé pour tourner uniquement sur des architectures x86, ne pourra faire tourner qu'un système x86. QEMU en tant qu'émulateur, pourra sans problème faire tourner un système ARM sur une plateforme hôte x86, mais avec un prix à payer, celui de la performance.
Il existe néanmoins des modules dit, d'accélération, disponibles pour Linux. Le plus abouti et le mieux intégré à QEMU étant KVM (Kernel-based Virtual Machine). Ces modules offrent la possibilité au système invité d'être exécuté directement sur le système hôte et accélèrent donc les traitements.

Suivez le guide

a) Préparer votre répertoire de travail :
mkdir ~/qemu/wheezy && cd ~/qemu/wheezy
mkdir mount
wget ftp://ftp.debian.org/debian/dists/wheezy/main/installer-armel/current/images/versatile/netboot/vmlinuz-3.2.0-4-versatile
wget ftp://ftp.debian.org/debian/dists/wheezy/main/installer-armel/current/images/versatile/netboot/initrd.gz

b) Installer QEMU directement avec son module KVM :
sudo apt-get install qemu-kvm qemu-kvm-extras

c) Créer un disque dur virtuel d'une taille suffisante pour vos travaux :
qemu-img create -f raw hda.img 4G

d) Lancer l'installation de la machine virtuelle avec 512Mo de RAM :

Il s'agit d'une étape relativement longue à s'exécuter, où vous êtes assez souvent sollicité pour répondre à des questions, donc pensez à vérifier régulièrement l'état de l'installation. Attention, toujours utiliser des apostrophes !
qemu-system-arm -m 512 -M versatilepb -kernel ~/qemu/wheezy/vmlinuz-3.2.0-4-versatile -initrd ~/qemu/wheezy/initrd.gz -hda ~/qemu/wheezy/hda.img -append “root=/dev/ram”
Une fois l'installation terminée, stopper QEMU.


e) Copier le kernel de boot dans votre installation :

Afin de pouvoir copier correctement notre kernel de boot situé sur le disque dur virtuel. Il faut au préalable monter et calculer l'offset de départ via la procédure suivante :

  1. Exécuter la commande file sur le fichier hda.img,
  2. Noter la valeur de startsector,
  3. Multiplier cette valeur par 512 et vous obtenez la valeur offset pour la commande suivante.
Ainsi, pour ma part :
sudo mount -o loop,offset=1048576 ~/qemu/wheezy/hda.img ~/qemu/wheezy/mount 
cp ~/qemu/wheezy/mount/boot/initrd.img-3.2.0-4-versatile ~/qemu/wheezy/
sudo umount ~/qemu/wheezy/mount

f) Lancer votre VM Debian ARM :
qemu-system-arm -m 512 -M versatilepb -kernel ~/qemu/wheezy/vmlinuz-3.2.0-4-versatile -initrd ~/qemu/wheezy/initrd.img-3.2.0-4-versatile -hda ~/qemu/wheezy/hda.img -append 'root=/dev/sda1'



Si la procédure s'est déroulée avec succès, vous devriez avoir une fenêtre QEMU affichant l'état d'avancement de la séquence de boot. Vous pouvez donc à présent vous connecter avec le compte "utilisateur" crée lors de l'installation.


dimanche 7 avril 2013

Intégration des tests fonctionnels CasperJS avec Grails



Introduction

Le but de cet article est de vous présenter un plugin Grails permettant d'instrumentaliser vos tests fonctionnels via CasperJS. Sans pour autant rentrer dans les considérations de la nécessité ou pas, de miser sur ce type de tests pour votre application, je présenterai néanmoins les grands principes de cette couche tout en espérant vous convaincre de l'intérêt et l'utilité de celle-ci.

Présentation du framework Grails et l'utilitaire CasperJS

"Grails parce que je le vaux bien ! - développeur anonyme
Et oui ! Car qui n'a jamais pesté contre son vieux legacy de dix ans, piégé de mille et un tricks en tous genres trouvés au petit bonheur la chance sur Stack Overflow ? Qui ne s'est jamais demandé pourquoi, il devait manipuler une stack technique aussi complexe, afin de produire un écran de gestion aussi simple que primordial pour le business. Ne cherchez pas, il faut passer à autre chose, à un niveau d'outillage vous permettant d'être réactif et pro, le tout dans un cadre sécurisé, j'ai cité Grails.
Groovy On Rails est un framework d'aide au développement d'applications Web (principalement), dit full-stack, car couvrant à tous les étages, les besoins d'une application moderne. C'est aussi un framework extrêmement populaire pour les raisons suivantes :
  • Grails permet de produire une application saine et robuste en très peu de temps via sa console et sa parfaite intégration aux principaux IDE du marché,
  • La gestion de son architecture interne plutôt orientée convention que configuration, limite le bruit nécessaire à l'organisation et au maintien de l'application,
  • Son extensibilité est sans limite grâce à son mécanisme de plugins, dont le but est d'étendre les capacités du framework, permettant ainsi, d'ouvrir ce dernier à des technologies comme par exemple CasperJS,
  • Et pour terminer, mentionnons, que l'on peut coder du Grails en Java et en Groovy, qui pour ce dernier est un langage ayant à mon sens, sa place parmi les plus grands. J'y ai pour ma part découvert un langage riche, puissant, surprenant et bien plus évolué que Java (qui a d'autres contraintes certes, mais ceci est une autre histoire...).
"CasperJS, parce qu'un bon ouvrier a de bon outils - développeur anonyme"
C'est tellement évident que l'on aurait tendance à l'oublier... Mais comme pour Grails, il est nécessaire de nos jours d'avoir à portée de main, des outils de testing modernes et robustes, capables de répondre aux exigences du marché. Quels sont ces besoins et ces exigences ?
  • Avoir un feedback rapide en cas de bugs, sur une application en production ou sur l'intégration continue,
  • Avoir un outil simple à mettre en oeuvre, capable de s'intégrer dans n’importe quelle infra (intra, PaaS...) et qui mérite mieux qu'une vieille bécane perdue entre deux bureaux de développeurs,
  • Avoir à portée de main, un outil simple, intuitif, qui se pilote et se maintien simplement via un langage de programmation connu de tous.
Vous savez à présent quoi faire de vos vieux tests Selenium... Mais si, ces fameux tests si compliqués à scripter et qui s'intègrent si mal dans votre SI. Ceux-la même que l'on s’obstine à supporter au point même de devoir désigner par Sprint, un responsable du CI, passant le plus clair de son temps à les maintenir ou les redémarrer... Je vous vois sourire !

Une vraie solution passe aujourd'hui par un outil capable de répondre à ces besoins : CasperJS. En effet, cet outil a eu la bonne idée d'hériter de PhantomJS, qui n'est autre qu'un moteur de rendu Webkit headless pilotable en JavaScript permettant la manipulation du DOM. L'intérêt d'avoir CasperJS au dessus de PhantomJS est de pouvoir définir de manière moins rudimentaire, des scénarios de tests ou de navigation, par le biais d'une API un peu moins rugueuse ; le tout éventuellement en CoffeeScript.

CasperJS Tests Runner Plugin for Grails


Comme son nom l'indique, le but de ce plugin est de s'intégrer dans le life-cycle de Grails, afin que ce dernier puisse lancer les tests développés par l'équipe développement.

La configuration


Bien que la page GitHub du plugin explique en détail la procédure d'installation et de lancement, voici les  étapes nécessaires à l'exécution de ce dernier :

  • Installer et ajouter dans votre path les outils CasperJS et PhantomJS,
  • Tester la bonne configuration de votre installation en lançant la commande suivante :
    • casperjs --version
    • Si votre installation est mauvaise, vous aurez alors un message indiquant la nature de l'erreur et à l'inverse le numéro de version,
  • Editer votre fichier Build.groovy afin d'y ajouter dans la section plugins, la configuration nécessaire :
    • test ":casper-runner:0.2",
  • Créer un répertoire casper dans test/,
  • Ajouter un fichier de tests écrit en JavaScript ou CoffeeScript, comme par celui-ci dans le répertoire test/casper,
  • Lancer à la racine de votre application Grails, la commande suivante, afin d'exécuter le test d'exemple :
    • grails test-app casper:
  • Et le tour est joué !

Si l'exécution du test s'est correctement déroulée, vous aurez à quelque chose près, la sortie suivante :

$ grails test-app casper:
| Executing following CasperJS test(s) file(s): [test_navigation_google.js]
| Executed 5 test(s) for test_navigation_google.js: 0 failure, 5 success
| Completed 1 casper test, 0 failed in 1415ms
| Tests PASSED - view reports in target/test-reports

Ainsi par le biais d'une commande Grails dédiée, vous serez capable de lancer à votre guise, votre batterie de tests fonctionnels, dont le résultat des opérations sera reporté dans un fichier xUnit à Grails, vous prévenant ainsi du succès ou de l'échec des ces derniers.

Limitations et évolutions du plugin


Si vous avez été un peu attentif précédemment, vous avez certainement pu remarquer que le numéro de version du plugin est de 0.2, ce qui signifie, qu'il est encore jeune.
Ainsi, si vous décidez de l'utiliser dans votre CI, vous devez disposer de CasperJS et PhantomJS dans votre path au moment de l’exécution de ce dernier. Il est prévu dans une future version, d'embarquer les deux compères si ils ne sont pas présent lors de l'installation du plugin, une issue GitHub est même prévue à cet effet.
De plus, pour que l'intégration soit totale, il ne faut pas oublier d'ajouter à la fonction run le code suivant indiquant à CasperJS, qu'il doit utiliser la sortie fichier XML pour le résultat au format xUnit :
this.test.renderResults(true, 0, this.cli.get('xunitFileName'));


Conclusion


Voilà, l'immersion dans la stack Grails au travers des tests fonctionnels CasperJS est terminée. Je pense que vous avez noté avec quelle facilité, on peut intégrer des tests pertinents et relativement simples à maintenir, pour peu que l'on s'en donne la peine et que l'on accepte un peu de configuration manuelle. A noter, que le plugin est compatible 2.0.1 > ce qui signifie que même vos anciennes applications ont le droit d'être sous l'égide de tests fonctionnels moderne et pour couronner le tout fun !

mercredi 27 juin 2012

Meetup Ember JS #1

Encore une bonne surprise ce meetup consacré à ember.js !

En effet, nous nous sommes retrouvés hier soir, une bonne quarantaine de développeurs/passionnés de tout horizons, afin de participer au premier meetup organisé par Capitaine Train. Le but pour moi était une fois de plus de regarder derrière le rideau de Java et comprendre comment fonctionne ce framework MVC tout JS. Je n'ai pas été déçu, voyons pourquoi...


La rencontre

Comme tout meetup qui débute, nous sommes partis sur le format Présentations, mais ponctuées avec de très bonnes séances de Live Coding à la clé et honnêtement ce n'était pas plus mal, car ember.js n'est pas (pour ma part du moins) un framework que l'on appréhende en un claquement de doigt.

Un bref historique

Et pour cause, car ember.js est la version 2 du framework SproutCore, qui a été originalement développé par Sproutit et dont Apple a été un gros contributeur pour essentiellement sa plateforme iwork. Ce que j'ai retenu de l'introduction de Paul c'est que ember.js est une version allégée de SproutCore, en ce sens qu'il ne contient que les parties essentielles à la gestion d'un MVC simple et robuste. On trouve au menu les properties-bindings bi-directionnels, les propriétés calculées (propriété sous forme de fonction par exemple), un outil de templating efficace appelé HandleBars, qui repose sur Mustach.js, un routeur et... une machine à état permettant de formaliser les transitions entres les vues et faire une abstraction. Ainsi, il est possible de structurer et organiser une application ember.js sans un routage basé sur des URLs par exemple.

Les présentations

Nous avons eu la chance d'avoir droit à quatre présentations, rien que ça :

  • La première était une introduction assez claire sur ember.js animée par Paul. J'y ai découvert par exemple les notions d'outlet et de key value observer...
  • La seconde était une séance de Live Coding from scratch avec TextMate et Chrome animée par MartinEn deux coups d'import JS, Martin a développé une application simple et nous a montré comment "instancier" un modèle, un contrôleur avec comme vue, une simple page Html. Dans cette introduction, nous avons pu voir un peu plus en pratique Handlebars,
  • Le troisième était un introduction intéressante sur la customisation des vues. Cette présentation était animée par Grégoire. L'API d'ember.js permettant par exemple d'ajouter des attributs à chaud, mais aussi de définir proprement des templates et des compositions de templates,
  • La quatrième et dernière était une immersion un peu plus pêchue dans une application de type blog et disponible sur le github de Paul pour ceux qui veulent jouer avec.

Bilan

Et bien cette entrevue avec la communauté ember.js m'a honnêtement convaincu. En effet, j'y ai rencontré des gens, qui ont un vrai bon background de développement Web et qui ont une connaissance assez étendue des standards et outils équivalents. De ce fait, je pense que si ils ont décidé de jeter leur dévolu sur ember.js, c'est que ce choix a été mûrement réfléchi. J'ai par ailleurs oublié de mentionner que Capitaine Train utilise ember.js en production et qu'ils sont, semblerait, motivés pour animer la communauté. Donc, je ne peux que les saluer et les remercier pour cette initiative.

Quelques pointeurs

mardi 21 février 2012

JavaCampParis7



Encore une réussite ce JavaCampParis7 organisé par @LucBizeul, @PhilippeAntoine et Google FR. Nous nous sommes une fois de plus retrouvés dans les locaux de Google à Opéra entre une bonne cinquantaine de dévers de tout poil pour parler de pas mal de choses, mais finalement peu de Java. Journée difficile oblige, je n'ai pu participer qu'à une seule session : FP / Scala...

Comme à l'accoutumé, j'ai croisé mes anciens camarades de Vidal Software où l'utilisation de la programmation fonctionnelle dans des projets sérieux n'est pas une légende. En effet, @ugobourdon@a_thieriot et @tonyskn nous ont fait part de leur retour d'expérience sur l'utilisation de Scala comme outil de développement du gestionnaire de mise à jour pour l'un de leur produit. Après une courte introduction sur les raisons expliquant en quoi Scala avait sa place chez Vidal, nous avons débattu sur les façons/raisons d'intégrer cette technologie en entreprise. En effet, nous constatons que bien souvent, les organisations ne perçoivent pas l'intérêt d'utiliser un nouveau langage de programmation et ont l'impression de subir un caprice de développeur.
Loin s'en faut, je pense que la mission d'un développeur est d'une part d'assurer sa veille technologique, mais aussi de corréler/axer cette veille technologique, suivant les besoins business de son entreprise : chose que certain d'entre nous ont trop tendance à occulter, j'ai l'impression.
Bref, j'arrête de digresser pour revenir au débat principalement animé par les gens de Vidal et Zenexity, où j'ai retenu deux informations intéressantes. La première par Ugo qui expliquait que l'utilisation des listes en Scala était un pur bonheur et que via cette API, il avait pu faire ses premières lignes de codes réellement fonctionnelle. La seconde par @mrspeaker qui m'a tendu un livre à lire pour vraiment se mettre à le programmation fonctionnelle, il s'agit de The Haskell School of Expression: Learning Functional Programming Through Multimedia Il m'a assuré que c'est un pro de programmation fonctionnelle qui lui a conseillé... et comme je vois de qui il parle, je ne peux que le croire :)

En résumé, encore une soirée passée auprès de gens bien capables, qui mettent les mains dans le cambouis, qui n'hésitent pas à venir parler de leur travail et à partager leurs expériences. Donc merci à ces barcampers et à la prochaine !

vendredi 10 décembre 2010

Paris Javascript Meetup #2

L'API Spore

J'ai continué mon immersion dans les mondes parallèles et vous propose un feedback rapide du très intéressant du Paris JS Meetup 2, qui s'est déroulé chez ISART Digital avec en maître de cérémonie Pierre-Loic. Intéressant à plus d'un titre, car non content d'y apprendre des choses passionnantes sur le vrai développement web, j'y ai rencontré des gens hors de la matrice Java/JavaEE, qui codent et qui le montrent. En outre et c'est là que l'on se rend compte de la richesse de ce type de soirée, je me suis trouvé à discuter aussi bien avec des développeurs iPhone, qu'avec des games designers ou encore des administrateurs systèmes fans de devops. La soirée s'est donc à peu près passée comme tout bon meetup qui se respecte, c'est à dire un enchaînement de quelques présentations, une pause pizzas, la suite des festivités et un dernier verre où l'on refait gentiment le monde.

Voici en bref, le contenu des différentes présentations :

Présentation HTML5 - Grégory PAUL

Grégory nous a présenté avec exemples à l'appui, des notions d'HTML5 sur :
  • Les Webworker,
  • Le WebGL,
  • Les Websockets via un exemple de chat avec node.js,
  • Le Webstorage,
  • La Géolocalisation,
  • ...
Présentation de Spore et Node-Spore - François de Metz

J'avais entendu parler de spore à l'OSDC FR 2010 cet été et j'avais trouvé l'idée relativement intéressante, car je n'avais pas réellement compris l'impact de cette API. En effet, le but de spore est de non seulement de décrire une API REST au travers d'une syntaxe JSon simple, mais aussi d'apporter du comportement dynamiquement au travers de middlewares dont le but est d'adapté une API cliente et ainsi de pouvoir gérer les différences de versions par exemple. Parmi les fonctionnalités énoncées par François, on retrouve :
  • La possibilité de rajouter des informations d'authentification à la volée,
  • La possibilité de réparer une API cassée,
  • La possibilité de mettre en cache les réponses,
  • Le middleware connect permettant de rajouter OAuth sur l'appel d'une API Twitter par exemple,
  • ...
Présentation sur les jeux en HTML5 - Pierre-Loic Doulcet

Encore une présentation aussi intéressante que technique avec un petit côté vintage, car Pierre-Loic nous a gentillement rappelé que sans la game-loop, point de salut ! Voici une énumération un peu sommaire du cookbook concocté par le speaker :
  • Un rappel sur ce qu'est une game-loop,
  • Eviter de redessiner tout l'écran afin de gagner en traitement,
  • Utiliser setTimeOut plutôt que setIntervale,
  • Utiliser le Webstorage locale,
  • Utiliser YUI Compressor et Closure pour optimiser le transfert,
  • Utiliser un setTimeOut et dynamique en fonction du temps déjà passé dans la game-loop,
  • Utiliser les Webworker pour l'IA,
  • La balise Audio est juste super limitée !
A noter que Pierre-Loic organise en 2011 le Html Game Jam, soit 48h pour coder un jeu en HTML5 de manière collaborative.

Présentation de La balise video HTML5 et Javascript - Clément Hallet

Cette présentation nous a montré comme améliorer le comportement d'une balise HTML5 en Javascript. Le cas d'école a été la balise vidéo où Clément a pris un malin plaisir à modifier ses attributs par le DOM avec Mooplay. Un exemple intéressant a été l'ajout par incrustation d'une traduction sur l'image en cours de lecture. Un projet à suivre...

...