En janvier 2013 a eu lieu la conférence Takeoff à Euratechnologies à Lille. Les premières vidéos des différentes présentations viennent de sortir !! INEAT Conseil vous propose un petit descriptif afin de vous guider dans vos séances de rattrapage.
The photostory of everything
Michal Budzynski commence en présentant des jeux qu’il a lui même développé en HTML5. En effet, il était à l’origine du phénomène Nyan Cat avant d’être recruté chez Mozilla.
Une intéressante réflexion sur les mystères de l’infini (Tout peut-être trouvé dans le nombre Pi, même des numéros de téléphones !) Il termine par la démonstration d’une application de reconnaissance faciale, un projet équivalent à Seti@Home mais en Node.js.
Science Based Developement
Olivier Lacan des bureaux Envy Labs, société qui édite la plateforme d’e-learning codeschool.com, nous a démontré les avantages à utiliser le « Fumble-Driven Develoment » : Essayer, Rater, Recommencer. Une présentation intéressante et riche en enseignement, qui permet de réfléchir sur ses méthodes de travail.
RequireJS
Jack Franklin explique quels sont les avantages d’utiliser requireJS, et illustre son argumentation avec une démonstration qui présente les problématiques de l’utilisation classique de Javascript :
- Plusieurs requêtes http au chargement
- Chargement synchrone des fichiers
- Difficultés à maintenir le code
Il montre que RequireJS répond à cette problèmatique : en utilisant de l’API AMD (Asynchronous Module Definition) il est possible de scinder le code en module et de déclarer des dépendances entre les fichiers. Ce qui permet au framework de générer un seul fichier minifié.
Creative Coding : Visualizing Music
Ce concert ou live coding en musique présente une belle démonstration de l’utilisation de Javascript avec html5. Jonas a présenté la web audio API de HTML5 et il nous montre un player avec un spectre sonore sur de la musique où les adeptes de métal sont à l’aise!
En changeant de musique et avec un peu de code, les spectres s’adaptent au son, on voit une tête d’alien, des chats et enfin des montagnes en 3D! Un bel exemple d’utilisation de l’API.
CSS Laid Out
Phil Nash – slides (HTML) – slides
Phil Nash réalise une présentation très instructive sur le placement des éléments HTML grâce au nouvelles propriétés CSS. Une session de live coding qui permet de découvrir les points forts des autres types de ‘display’:
- display:table: l’intérêt est de pouvoir appliquer à des éléments les propriétés des tableaux HTML.
- display:flex: couplé à d’autres propriétés CSS comme ‘justify-content’, ‘align-items’, permet de gérer le mode d’affichage des éléments pour les afficher en ligne ou en bloc, verticalement ou horizontalement et également de réorganiser ces derniers dans l’ordre voulu (et ne plus prendre en compte l’ordre du DOM). Très pratique pour des sites responsive.
- display:grid: permet d’organiser en colonnes et en lignes l’affichage rien qu’avec du CSS. Il est donc possible d’intégrer des styles d’affichages comme Pinterest.
Network Architecture based on Gaming
João Moura explique que les temps de chargement sont importants, pour preuve :
- Amazon: 100ms = 1% de chute de ventes.
- Google: 500ms = 20% de recherches en moins.
- Yahoo!: 400ms = 5-9% de clicks supplémentaires sur le bouton “back” avant que la page soit loadée.
Il présente une méthode d’architecture applicative à la manière des Jeux-video.
Le but est donc de charger en parallèle les informations est de les distribuer à la demande. Il explique
plusieurs solutions :
- Stocker les données côté client: Cela réduit le temps de réponse et facilite l’accessibilité des données.
- Précharger les données
- Asynchrone: Il suffit de découpler l’interface utilisateur de l’interaction avec le serveur.
Meteor.JS
Geoff Schimdt – video
Une session de live coding avec Geoff Schimdt qui présente ce framework javascript. Meteor.js intégre l’ensemble des couches applicatives du web. La démonstration est impéressionnante, Geoff démarre un serveur, ouvre
deux navigateurs et un fichier js dans lequel il code un template et un serveur avec accès à une base données. Les templates et données sont automatiquement mis à jour sans action sur le client.
La rapidité de la mise en place de cette petite application est déroutante et l’expérience de
développement a l’air très appréciable. L’envie d’essayer surgit aussi vite que les idées d’applications.
N’hésitez pas à aller voir les screencast sur le site de MeteorJS et de lire cet article assez complet sur la composition du framework.
Un petit bémol quand même, la partie test unitaire est encore à la marge du projet…
12 steps to win at software development
Gregg Pollack – slides – video
Le titre de la présentation, nous donnait quelque chose de déjà vu, déjà entendu, mais dès les premiers moments l’orateur a su susciter l’intérêt. Le choix des illustrations est toujours bon et les conseils sont de plus
en plus pertinents et on se rend vite compte qu’il ne s’adresse non seulement aux développeurs mais à l’ensemble des acteurs de nos sociétés.
Voici quelques steps pour vous donner envie de voir et revoir la présentation :
- More Friendships = Happiness, Happiness = Better work
- Don’t let your ego get in the way of asking for help
- It is not natural to be productive 100% of the time
- “Creating quality software is x % code and y% communication where y is greater then x.”
- Clear writing is a sign of clear thinking.
You are not service-oriented enough!
Jakob Mattson – slides – video
Encore une fois une bonne présentation d’un extrémiste du SOA, et sa démonstration de l’utilité d’avoir une architecture orientée services est plaisante et convaincante. De plus il met en avant pas mal de problèmes de
certains Framework à la mode, qui ne prennent pas en compte les applications distribuées intègrant à fois le serveur et le client, ou qui ne propose pas la possibilité de faire du cross domain en natif.
Robots need love too!
Sebastian Golash – slides – video
Certainement la présentation la plus originale, de Sebastian Golash, ce grand enfant qui s’amuse à programmer toute sorte de robots. Il montre à quel point il est simple pour un web developper avec un peu d’imagition de réalisation des applications encore plus intéractive grâce notamment au matériel Arduino, ou aux drônes de plus en plus populaires et accessibles. N’hésitez pas à aller voir ses dernières invenntions sur MakeyMakey.
FriendCode
C’est lors d’un lightning talks que nous avons pu assister à démonstration de l’outil FriendCode, qui est une sorte de réseau social pour développeurs. La solution est centrée autour d’un éditeur de code simple et permet d’échanger et de collaborer en temps réel avec son équipe “virtuelle”.
L’interface semble soignée, un peu à la sauce Apple. Un produit à tester entre amis !
Designing better JavaScript APIs
Rodney Rehm – slides – video
Rodney évoque les points clés d’une bonne API JavaScript : simplicité, stabilité, performance.
Simplicité
Consistance: ne pas mixer plusieurs normes de développement, plusieurs notations, ne pas inverser l’ordre des paramètres entre deux fonctions similaires, etc. Lorsque l’on pense à la consistance d’une API, on ne pense pas à PHP. str_repeat(), strpos() sont de bons exemples de non consistance d’une API.
Évidence: rendre l’utilisation de l’API la plus simple possible pour l’utilisateur : ne pas se perdre dans des noms non consistants, dans des méthodes qui ne font pas ce qu’elles sont supposées faire. L’évidence fait que plus vous utilisez l’API plus les parties que vous ne connaissez pas encore vous paraissent simple et logiques lors de leurs premières utilisations.
Prédiction: pouvoir prédire le nom d’une fonction ou l’ordre des paramètres fait partie des critères définissant une bonne API.
Stabilité
La stabilité d’une API stable signifie qu’au fil des versions la compatibilité doit être assurée.
D’ailleurs, il est préférable pendant plusieurs versions de notifier les utilisateurs que la méthode utilisée est dépréciée et de proposer la méthode la remplaçant.
Performance
Il est évident qu’une API doit-être performante, sinon elle perd une grande partie de son intérêt. En JavaScript la performance peut-être optimisée sur de nombreux points : architecture de l’API, design pattern utilisés, gestion des objets, boucles…
Bien que la performance est un critère essentiel, il faut trouver le bon dosage avec la simplicité.
Pour aller plus loin voici un article du même auteur : Designing Better JavaScript APIs.