TakeOff Conf 2014

Introduction

La TakeOffConf à lieu à Lille. C'était cette année la seconde édition. Soutitrée "The Future of Web Technology", elle est à vocation européenne et s'adresse aux développeurs, et vise à toucher un grand nombre de sujets, sans forcément rentrer beaucoup dans la technique.

Deux jours de conférences, c'est intense, il y avait du très bon, et du moins bon. Je ne vais pas trop m'attarder sur le moins bon et surtout décrire les highlights.

LES TRÈS BONNES CONFÉRENCES

We made a hack, with fire, a gun and multiple robots.

Michal Wawra de Twilio nous présente une machine de Robinson qu'il a fait durant un hackathon. C'est un moyen compliqué de faire quelque chose de simple. Dans ce cas, c'était comment réussir à envoyer un sms (grâce à l'API Twilio) en passant par des billes qui coulent dans un tunnel en carton pour actionner un robot en plastique qui va s'agiter eu tout sens et déclencher une cellule de mouvement qui va faire déplacer un autre robot qui va amener une petite bougie sous un élastique qui, en brûlant, va libérer un régime de bananes accroché à une corde qui va actionner la gachette d'un pistolet Nerf qui va shooter une cible qi actionne un bélier qui va rentrer une disquette dans un lecteur qui va lancer le script final.

En plus d'être un sujet assez drôle, il en a profité pour extrapoler sur le fait que cette machine n'était finalement qu'une suite d'input et d'output dans des formats complétement différents. Il indiquait aussi qu'ils testaient unitairement chacune des parties mais que faire un test d'intégration complet était extremement couteux en initialisation, du coup ils n'ont pas pu en faire beaucoup avant la "mise en prod". De même, pour la partie avec la bougie, ils ont fait l'équivalent d'un try/catch dans le monde réel, c'est à dire au cas où le feu se répande anormalement, des capteurs devaient sonner une alarme.

Improv and Open-Source

Haleigh Sheehan de Github nous parle des parallelles qu'elle fait entre son boulot de musicienne de jazz, de joueuse dans un théatre d'impro, et de son boulot à GitHub dans le milieu de l'Open-Source.

Pour elle les deux milieux ont beaucoup de points communs, comme l'apprentissage de ses erreurs, la mise en public de son travail, le coté éphèmere, et l'importance du feedback.

Security Good Practices

Olivier Lacan, de CodeSchool (qui se révèle habiter à quelques rues de chez moi en fait), nous présente quelques bons conseils assez simples mais souvent oubliés pour améliorer notre sécurité, et la sécurité de nos apps.

Déjà, ne jamais fixer de limite au nombre de caractères maximum d'un mot de passe. Ne pas forcer de caractères spéciaux, majuscule, minuscule, etc. Plus on ajoute de règles, plus un password est difficile à retenir et donc plus on aura tendance à toujours utiliser le même ou bien à le noter quelque part. Il conseille 1Password (ou KeyPass) pour gérer son portefeuille de pass.

Le juste milieu entre User-Friendliness et Security est toujours très difficile à trouver. Il donne ensuite quelques outils pratiques comme GnuPG ou Meldium.com pour partager des accès à un service en ligne au sein d'une équipe sans pour autant utiliser plusieurs comptes, ni partager le mot de passe commun.

Il enchaine sur le fait que se faire voler son téléphone ou son laptop ne devrait pas être un problème. Le pass d'accès doit être assez complexe pour protéger l'accès. En ajoutant la possibilité de wiper le device à distance et en ayant fait une encryption complète du disque, tout va mieux. Truecrypt permet le chiffrement et permet même un plausible deniability.

Pour lui, il ne faut jamais faire de compromis sur la sécurité. Par exemple, même si la deadline est demain, il ne faut pas envoyer les pass en clair par mail parce qu'on n'a pas le temps de créer correctement un couple de clés. Parce qu'en commencant comme ça, un jour le système forcément sera compromis et un failure public qui révèle la totalité de la base client, qui fait la une des journaux, aura un impact bien pire sur les clients qu'un ou deux jours de retard initiaux (parallelle avec les TU, que le coût de correction d'un problème de secu est exponentiellement plus long plus il est mis en place tard).

Que https est un impératif, qu'il faut supprimer ses logs car ils contiennent des tas d'infos sur les gens, et qu'il est inutile de les garder si on ne s'en sert pas. Qu'il faut stocker les informations sur disque seulement le temps minimum légal, que si on a besoin de garder des données, il faut absolument les anonymiser (discussion intéressante auprès d'une bière après la conf avec un ancien de chez OVH sur ce sujet, comme quoi tout est anonymisé pour les employés). Et finalement, qu'il faut aussi faire attention aux library third party qu'on utilise et s'assurer qu'elles suivent les mêmes standard de qualité de sécu que son propre code.

The Bizarre App Experiments

Deux gars de Blackberry présentaient le framework de dev mobile Qt (prononcez Cute). Le framework est open-source, mais backé à temps plein par des gens de Blackberry. Il permet de faire du crossplatform iOS, Android, Blackberry et Windows Phone.

Ils ont présentés deux démos sympa sur scène. La première avec un capteur de rythme cardiaque, à enfiler autour de son torse, relié à un Blackberry en bluetooth qui lit un mp3 (Eye of the Tiger), et qui le stream en bluetooth vers des enceintes. Le pitch de la musique descends petit à petit et remonte en fonction du rythme cardiaque. Il faut donc s'agiter (courir, faire des pompes) pour remonter la musique au rythme correct. (Le capteur était un Wahoo Blue, ils utilisaient OpenAL pour la manipulation de l'audio et Qt 5.2. Testé uniquement sur Blackberry mais "devrait" marcher de la même manière sur iOs et Android).

Démo du code Bluetooth; découverte des devices, récupération du "heartbeat monitor" -spécifié dans la norme BT-, découverte des services du devices -battery, name, heartbeat, calories burnt, etc-. Tout ceci fonctionne à base d'events à chaque découverte sur lesquels ils se plugguent, et modifient le pitch en fonction.

Deuxième démo dans la même genre, cette fois avec une carte NFC à poser sur le blackberry qui lance un chrono de 10s. Le speaker devait alors courir à l'autre bout de la scène et revenir en moins de 10s, pour reposer la carte, qui lance un nouveau chrono de 9s, puis de 8s, etc. Et si le chrono atteint 0 le public devait lui lancer des balles en mousse. Les cards NFC coutent 0.5€ environ, très facile à mettre en place.

Idem, le timer est executé avec Qt et fire des events. Events fired aussi quand le NFC touche.

Developing Developers

Paul Verbeek, alias @hierow nous explique qu'il est difficile de trouver de bons dévelopeurs à embaucher. 80% d'entre eux sont autodidactes, donc les diplomes n'ont pas de valeur. Il est aujourd'hui bien plus facile d'apprendre le dev web qu'il y a trois ans (maturité des outils, experience, cours en ligne).

Pour lui, le meilleur dev web, est celui que l'on prends comme apprenti. Qui n'a jamais fait de dev avant, mais que ça interesse. Prendre un dev et le former au web va nécessiter de désapprendre beaucoup de choses.

Ne pas confondre Apprenti et Stagiaire. Un apprenti est Luke Skywalker, il sait ce qu'il veut devenir mais il ne sait encore rien. Un stagiaire est Anakin, il ne sait pas ce qu'il veut, il essaie et il deviendra peut-être quelque chose de complétement différent.

Il faut être un bon mentor pour espérer former un bon apprenti. Il faut savoir, et rester à jour sur les technos. Etre positif, et savoir motiver. Connaitre son apprenti, savoir ce qu'il aime, ce qu'il n'aime pas, ses forces, ses faiblesses. Savoir comment il apprends le mieux. Expliquer clairement, et écouter attentivement. Etre discipliné, et lui aussi. Instruire par l'exemple. Définir des règles et s'y tenir autant que lui. Et surtout ne jamais oublier que l'on est soit même un étudiant et qu'on apprends constamment.

Si on forme un dev front, il faut lui apprendre html, css, js. Mais s'il est intéressé par plus (back-end, ops, design) il faut l'aider aussi, et si cela sort de votre domaine de compétence, le diriger vers quelqu'un d'autre qui pourrait l'aider.

Il est normal de ne pas savoir au début, il faut juste savoir d'où part l'apprenti. Quelques questions comme "Qui est Tim Berners Lee ?" "Qu'est-ce qu'HTML5 ?" devrait permettre d'évaluer sa connaissance. Ce ne sont pas des questions pièges, juste pour savoir par quoi commencer.

Ne pas commencer à lui apprendre les table, iframes et floats. Faire du pair-programming pendant au moins une semaine, expliquer tout ce que l'on fait, lui poser des questions, s'assurer qu'il en pose aussi. Lui apprendre à ne pas utiliser w3schools, le rediriger vers MDN ou Webplatform.

Is IT really global ?

Contre-talk au talk sur Developing Developers. Comme quoi "c'est bien beau tout ces principes, mais en France on n'en n'a pas des boss comme ça, c'est pas dans la culture".

Très interessante conférence sur la Culture (dans le sens, les valeurs, les experiences qui entourent les gens du fait de leur milieu, de leur histoire). La culture est une prison, dans laquelle on tombe à la naissance et dont les barreaux sont invisibles. Impossible de voir sa propre culture tant que l'on ne va pas en voir une autre.

Histoire du têtard qui revient dans la mare après l'avoir quitté. On lui demande comment c'est le monde exterieur et il réponds que "c'est sec". On lui demande alors, l'air interloqué, "Sec ? Mais qu'est-ce que ça veut dire sec ?". Il réponds, "Ben, il n'y a pas d'eau quoi.". Et les autres tétards, encore plus interloqués de repondre "De l'eau ? Mais c'est quoi ?".

Confrontés à un même évenement, différentes cultures verront différentes choses, et réagiront différement, selon leurs experiences (directes ou indirectes). La culture est comme un oignon, il faut enlever plusieurs couches pour arriver au centre. Il faut d'abord passer les symboles (la langue, écrite et parlée, les expressions). Puis les Héros, les personnages historiques, réels ou imaginaires qui font partie de la culture d'un peuple. Après ça on arrive aux rituels, des actions que "l'on a toujours fait", même si on ne sait plus exactement pourquoi. Et après ça, finalement on arrive aux valeurs fondamentales.

Ces valeurs sont transmises par l'éducation, la religion, le travail et les lois. Hofstede a identifié 5 valeurs principales, sur lesquelles on peut placer chaque pays du monde sur une échelle de 1 à 100. Des pays opposés auront du mal à se comprendre. Ces valeurs sont Power Distance, Individualism/Collectivism, Masculinity/Feminity, Uncertainty Avoidance and Long Term Orientation

Notes: Il manque quelques CR dans la liste, pour cause de batterie à plat sur mon laptop. Voici quand même les vidéos qui valent le coup :

Comment le Guardian a optimisé son site mobile en terme de webperfs :

Paul Rouget nous explique les méandres de Firefox, ou comment ça se passe à l'intérieur de la machine quand le DOM, le CSS, le Js se mettent en place et comment tout ce beau monde communique avec le CPU et le GPU.

LES BONNES CONFÉRENCES

The web is innefficient, let's fix it

Justin Secor nous parle de green IT, et de l'impact sur l'environnement du Web. Il tente de faire un parallèle entre le poids d'une page web et la consommation d'énergie qu'elle implique. Son calcul se base sur la consommation d'électricité d'un datacenter sur un an (x Mb de donnée stockée coute y kWh).

A partir de là, il donne quelques exemples. La home page de la BBC pèse tant, elle a tant de visites par jour, donc sur une année, ça fait tant de Mb, donc tant de kWh. Conclusion : la home page de la BBC sur une année consomme moitié moins que la ville de Paris. Deuxième exemple, l'iPhone 5 qui ne consomme que 3.5Kw par an pour se recharger. Pour 9.100.000 iPhone, ca revient quand même à la consommation de Lille sur un an.

Finalement, il enchaine pour dire que nous devrions utiliser une métrique de consommation d'énergie dans nos projets, comme on emploi une métrique de poids des pages, de vitesse d'affichage, etc. Et qu'on se fixe une limite et qu'on travaille à la descendre.

Il conseille donc des SPA pour éviter de recharger trop de choses, et préfère les pixels noirs aux pixels blancs (là, je ne suis pas convaincu). Idem il enchaine sur l'utilisation de gzip, de css preprocessors, de limiter les requêtes, les reflows, les repaints pour diminuer notre consommation d'énergie.

Autant je suis d'accord avec le fond, autant ses méthodes de calculs me semblent oublier un trop grand nombre de paramètres pour être sérieuses. Cela dit, c'est un très très bon speaker et son talk est parfaitement bien rodé.

All your base are belong to us

@ColdFusion10 nous parle du security breach d'adobe et de ce que ça implique. Que leur communication était mauvaise, qu'ils ont communiqué sur 2.9 millions, puis 38 millions, puis 230 millions, et le code source de photoshop.

La base volée est facilement trouvable sur le net (users.tar.gz) et contient id, mail, encrypted pass et pass hint. Beaucoup de personnes indiquent leur mot de passe en clair dans le hint, ou de manière très facile à retrouver ("soleil en anglais", "prénom de maman").

Analyse des mails en .fr. 4 millions. dont des ville-.fr, cc-.fr, mairie-.fr, .gouv.fr. Mot de passe les plus populaire : 123456, photoshop, 12345678.

Il nous présente ensuite quelques outils comme shodanhq.com, qui est un google des devices connectés. On y trouve des imprimantes, des serveurs, des cameras de surveillance, avec leur adresse ip. Et beaucoup ont gardé un mot de passe par défaut (admin/admin). Il nous explique aussi que parfois le fichier de config des dns d'un serveur est accessible publiquement et permet d'obtenir la liste des sous-domaines, ce qui donne des pistes de vulnerabilités (jira.domain.com, phpbb.domain.com, confluence.domain.com, etc).

Nous parle ensuite en vrac de dnsenum.pl, nmap, exploit-db.com/search, openvas, metasploit, backtrack.

Il finit par rappeller les règles élémentaires d'utiliser https sur ses sites, et de surfer derrière un vpn. Et d'utiliser des softs open-sources plutot que propriétaires pour limiter le risque de backdoors.

Largescale Javascript applications

La présentation nous donnait des pointeurs sur de bonnes pratiques pour avoir du code javascript maintenable, même sur une large codebase ou sur une grande durée.

Une application largescale n'a pas forcément beaucoup de lignes de code, mais va toucher beaucoup de monde, ou rester en ligne pendant longtemps.

Il est facile d'écrire du Javascript, mais il est difficile d'écrire du js maintenable.

Avec jQuery il est facile de récupérer une soupe d'events difficiles à suivre, liés au markup, qui considèrent le DOM comme la source primaire d'informations, et qui rends le code extremement dépendant du design visuel. Le DOM est un singleton, global, et stateful, donc difficile à tester et maintenir. Il faut apprendre à ne plus dépendre du DOM, ne plus utiliser jQuery.

Aujourd'hui, de plus de plus de taches qui étaient reléguées au backend bougent sur le front, comme le templating ou le routing. Du coup, "If your app breaks without Javascript, you should treat it as a real language.". Le js produit se doit d'être testable, scalable, maintainable.

The secret to build large apps is to never build large apps. Break it in smaller parts.

Use a MVW framework. W stands for "Whatever works for you".

La manière dont le code est organisé (en fichiers, dossiers) influe sur la manière dont le code est testé et maintenu. Il suggère de ne pas diviser en controllers/, views/ etc mais par feature : feature1/, feature2/.

Diviser pour mieux régner. Splitter le code en petits modules, indépendant, réutilisables, unaware les uns des autres, et qui peuvent donc s'imbriquer facilement par injection de dépendance. Ca les rends plus faciles à tester et à maintenir.

Designing Apps for Little Fingers

Ensemble de best practices pour développer des apps pour enfants. Il n'y a pas de méthode bulletproof car le principe même d'être un enfant c'est qu'on est en train de grandir et que différents ages ne réagissent pas de la même façon. La conf se limite donc à la tranche 3-8 ans.

• Toujours utiliser le mode landscape et pas portrait, les enfants sont habitués aux livres qui sont plus larges que hauts.
• Penser que l'enfant tient la tablette avec deux mains, il ne faut pas lui demander d'appuyer sur un bouton en même temps qu'il la tient.
• Il est très intuitif pour un enfant d'appuyer sur l'écran, et il a besoin d'un feedback immediat (ontouch, pas on release). Si pas de feedback tout de suite, il va réappuyer encore et encore. Aussi, ne pas faire de différence entre single tap et double tap.
• Facile pour eux de dessiner en déplacant le doigt, par contre il faut s'attendre à ce que le doigt "saute" et donc que le trait soit fait avec des coupures.
• Faire un Swipe d'un coté à l'autre est difficile, il vaut mieux proposer un bouton.
• Darg'n'drop est intuitif, mais ne sera pas précis. De plus, il faut là aussi s'attendre à ce que l'enfant "lache" l'objet en cours de route, il faut donc le laisser où il est plutot que de le ramener au début.
• De manière générale, toute ce qui nécessite plus d'un doigt est difficile.
• Ne pas leur demander de secouer ou pencher la tablette, il risquent de ne pas maitriser le mouvement et la casser. Ne pas non plus mettre de musique de fond (pensez aux parents !).
• Tout ce qui est action "adulte" (paiement, téléchargement, configuration) doit se trouver derrière une "baby gate". Un texte écrit indique quelle gesture l'adulte doit faire pour accèder aux options (pinch zoom, figure complexe), pour que l'enfant ne puisse pas le faire. Et changer la figure aléatoirement pour que l'enfant ne l'apprene pas par coeur en voyant son parent le faire.

La suite des advices étaient plus d'ordre générique game design, pas uniquement pour les bambins :

• Avoir des buts clairs et intuitifs. Potentiellement un personnage virtuel qui dit "bonjour, je suis truc, on va faire ça". Ca permet à l'enfant de switcher mentalement du contexte "home page" de la tablette, à celui du jeu.
• Rendre les éléments interactifs plus visibles que le background (différence de style visuel, glow, highlight, pulse, etc). Si pas d'action pendant 1-2s, highlight des éléments avec lesquels l'enfant peut intéragir.
• L'enfant apprends en faisant des erreurs, donc bien marquer les erreurs (grosse croix rouge par exemple), mais garder les persos happy (pas de froncement de sourcils par exemple). Aussi, si échec la premiere fois, donner un indice. Si échec à nouveau donner autre indice. Si nouvel échec, faire un highlight de la solution. Mettre des rewards visuelles et sonores.
• Utiliser des pictos consistants dans toute l'app et si possible d'une app à une autre, sans texte.
• Si texte, utiliser la même font que celle utilisée dans les livres de lecture du pays en question (différent selon les pays). Si texte lu oralement, faire un système karaoké qui highlight les mots quand ils sont lus.

I have a NoSQL toaster, why should I have a NoSQL database ?

Présentation des db nosql, parce qu'on les qualifie par ce qu'elles ne sont pas, mais pas assez parce qu'elles sont.

Première question : pourquoi ne pas utiliser sql ? Parce que le scaling est difficile avec sql. Parce que maintenir un schema cohérent sur le long terme est presque impossible.

Il présente ensuite des tas de DB NoSQL en les classant selon différents types.

Les DB document-oriented comme mongoDB ou couchBase. Utilisent du json/bson pour stocker la data, et elles comprennent le format du document stocké. Elles peuvent faire du travail qui était habituellement fait par le back-end. CouchBase : ++scaling, ++consistently fast MongoDB : ++easy querying, --no scaling

Les DB au format clé/valeur. Deux versions, soit en mémoire sur une machine, soit distribué sur plusieurs. Si en mémoire sur une machine, extremement rapide. Si distribué, scale beaucoup mieux mais on entre dans de l'eventual consistency (Riak, Dynamo, Voldemort, Cassandra). Ils acceptent tous les writes, même s'ils sont fait en même temps sur deux noeuds (alors qu'il y a un lock en cas de non-distribution). Distributed : ++scaling, ++availability, --manual conflict fixing Non-distributed: ++fast, --scaling

Il m'a ensuite perdu en parlant de columnar db (cassandra hbase) qui sont bien adaptées à du big data, mais sont un cauchemar pour les ops.

Finalement, les bases orientées Graph (Neo4j) qui stockent des objets et les relations entre ces objets. Finalement on s'intéresse dedans plus aux relations qu'aux objets eux-même.

D3.js

Présentation de la lib js D3 pour faire de la dataviz. Output en html ou svg, facile à prendre en main mais aussi extremement puissant pour des besoins plus complexes. Extension Rickshaw spécialisée dans la time visualisation. La lib parait extremement complète et simple à prendre en main, j'ai envie de la tester au plus vite.

LES CONFÉRENCES MOYENNES

Your own adventure web

Robin Berjon, du W3C, prêchait pour un html plus extensible. La possibilité pour les devs front de créer leurs propres balises, et de leur ajouter des comportements particuliers, gérés par les attributs. Un moyen pour lui de sortir de la boucle infernale du "draft > implémentation browser > tests des devs > standard > implémentation partout".

Ca se rapproche assez des directives angular, et c'est un pas dans la bonne direction pour lui, mais il attends que ces primitives soient accessibles directement dans le browser pour tous les devs.

Il a mentionné hitchjs, une libraire js qui ajoute de nouveaux selecteurs css évolués.

OWASP Top 10

Par @airbone42, un recap des règles de bonne hygiène technique en rapport avec la sécu. Que du très basique globalement : attention aux injections sql, ne pas mapper en 1 pour 1 les champs de la db avec les champs d'un menu déroulant (genre si 2 = moderator et 3 = user, alors on peut déduire que 1 = admin).

Quelques exemples de bonne configuration typique Apache (et un lien vers github.com/ioerror/duraconf).

S'ensuit un rappel que ce qu'est un salt, une rainbow table, une attaque XSRF. Qu'il faut bloquer toutes les actions par défaut, et les autoriser au cas par cas plutot que l'inverse. Qu'il ne faut pas stocker un degré d'habilitation dans un cookie (oh, really ?) ni ajouter des infos importantes dans les commentaires HTML. Que toutes les actions "sensitives" (changer mail, changer identifiant, paiement, etc) doivent redemander le pass, même si l'utilisateur est déjà loggué.

Un rappel intéressant au global, mais rien de nouveau.

Emberjs, lessons from the trenches

Slides

Régis Hanol, core contributor de Discourse (forum rails+ember) nous présente Ember. (Note: La présentation en elle-même était assez simpliste et n'apprenais pas beaucoup plus sur le framework que la lecture de la doc, mais j'ai pas mal discuté avec Régis durant les deux jours, et j'en ai appris plus sur Ember).

Ember prone le convention over configuration (comme rails dans l'idée, mais pas les mêmes conventions que Rails, du coup il n'y a pas d'affinité particulière entre les deux si ce n'est le mindset).

Il permet de faire des Single Page Application, en utilisant HandleBars comme moteur de templating en interne (ça limite un peu le templating dans la gestion des attributs html custom par exemple mais devrait s'améliorer dans les prochaines versions).

Il est possible de faire du SEO avec Ember... Enfin, avec Rails surtout. Il suffit d'injecter dans une balise noscript le contenu textuel de la page. Le serveur aura préalablement strippé tous les attributs cosmétiques (avatars, icons, etc). C'est ce qui est utilisé par Discourse.

Ember possède un mécanisme intéressant de rendering pour limiter le nombre de reflow/repaint, il attends que tous les events de sa queue soient effectués pour batcher tout ça. (Angular aussi doit faire quelque chose de similaire sous le capot, mais je n'ai pas trouvé de doc à ce sujet).

Finalement, Ember est jeune, le développement de Discourse a permis de mettre en avant des soucis de performances quand trop de views sont chargées en même temps (d'où le développement d'un principe de cloaking views qui unload les views qui ne sont plus dans le viewport). De même, ils n'utilisent pas ember-data car encore beaucoup trop buggué, ils font leurs appels http à la main.

A noter aussi que les tests d'Ember sont arrivés tard dans le cycle de dev, en ajoutant un member à la core team dont le taff principal était de couvrir l'appli de tests. Il n'y a clairement pas le même support derrière Ember que derrière Angular.

Singing Gophers

Présentation du langage Go, au travers d'un synthétiser de musique de la lib PortAudio (en C). Mais Go peut appeller du code C, et go est rapide (ben, oui parce que si goéland... petit blague pour voir ceux qui lisent mes CR jusqu'au bout), Go a des threads très légers et Go push de la donnée dans des tunnels (channels) qui sont des variables et qui recoivent de la donnée régulièrement.

Exemple d'un suite de fibonacci, on put les nombres dans un channel au fur et à mesure qu'on les génère, tout en continuant de looper dessus. On peut donc les afficher au fur et à mesure de leur génération.

Finalement, sa démo plus ou moins live codée permettait de jouer la marche impériale et donnait envie de tester Go.

LE RESTE

Using promises

Quentin Adam a tenté d'expliquer ce qu'étaient les promises et comment ça pouvait nous aider à sortir du callback hell. Si on connaissait déjà les promises, son talk n'apportait rien de neuf, et si on n'en avait jamais entendu parler, son accent anglais tellement français rendait le talk incompréhensible.

OpenDeviceLab

OpenDeviceLab est une asso internationale pour mettre à disposition des web devs de vieux devices (mobile phone, tablets) pour tester "facilement" son appareil sur toutes les plateformes. La conférence ressemblait plus à une publicité pour l'asso qu'autre chose. Pas été convaincu du tout.

Le seul point valide qu'il ait soulevé est que le parc des devices est beaucoup plus hétérogène que ce que l'on teste habituellement. Et que bien souvent nos tests sont fait dans des univers priviliégiés alors qu'un utilisateur réel aura bien souvent une connection pourrie, coupée par le métro, avec peu de batterie, des reflets sur son écran, etc.

Historique de Windows Azure.

ZZZZZzzzzz

Industrial Javascript

@Swiip nous parle de javascript, pour des développeurs Java. On nous présente tout le panel des outils autour du js, qui permettent au dev java de se retrouver dans un terrain un peu plus connu. Un peu foutoir, ça présente très vite angular (+ember, +backbone), Bootstrap, jshint, grunt (+gulp, +brunch, +jake), scss (+stylus, +less), coffeescript, haml (+jade), yeoman, jasmine, karma, phantomjs, mocha, chai, sinon. Un peu trop de choses à ingurgiter d'un coup, quoi.

Tags : #takeoff

Want to add something ? Feel free to get in touch on Twitter : @pixelastic