Retour sur le TakeOff Conference de Lille 2013 Retour sur le TakeOff Conference de Lille 2013

Retour sur le TakeOff Conference de Lille 2013

par ,
le 31 janvier 2013

0
0

A Lille, le Jeudi 17 et le Vendredi 18 janvier 2013 c’était la neige, le froid mais surtout le TakeOff, une conférence sur les technologies web front-end et back-end !

C’était surtout 37 intervenants présentant des technologies web, leur étude sur un outil en particulier ou encore les bests practices à employer, je vais donc tacher de vous relater au mieux ce que j’y ai appris au travers de cet article.

Bref c’était The Place To Be et comme j’y étais, je vais vous synthétiser les conférences auxquelles j’ai pu assister, à savoir :

  1. The Photostory of everythingMichal Budzynski
  2. Responsible use of data visualizationIrene Ros
  3. Writing awesome codeHans Christian Reinl
  4. Business logic in the cloud with google apps scriptThomas Parisot
  5. Event-driven phpIgor Wiedler
  6. Web.NextRobin Berjon
  7. 12 steps to win at software developmentGregg Pollack
  8. Push and use responsive imagesAnselm Hannemann
  9. 3D CSS, finding the right perspectivePeter Westendorp
  10. Clean and clear software with ErlangAnthony Eden
  11. Science-based developmentOlivier Lacan
  12. Go: Code that grows with graceFrancesc Campoy Flores
  13. Let’s fly to the moon!Jerôme Etienne
  14. Network architecture based on game philosophyJoão Moura
  15. Designing better javascript apis – Rodney Rehm

1- The Photostory of everything – Michal Budzynski

Dans cette première conférence, Michal mettait en avant le fait qu’une image n’est rien qu’un ensemble de pixels de couleurs et que par conséquent il est possible de la recréer en HTML pur. Il s’agirait tout simplement de prendre un tableau HTML, d’associer une couleur de fond à chaque cellule pour ainsi obtenir des pixels et pouvoir recréer ladite image. Son raisonnement va même plus loin, s’il est possible de recréer une photo ainsi, il est possible de recréer n’importe quelle photo de la même façon !

Du coup, il a créé un script qui génère les cellules du tableau de façon automatique en y associant les différentes combinaisons de couleurs et ainsi peut générer toutes les photos du monde !

Sa problématique étant le nombre de possibilités, en effet pour une image de 640×640 ça fait déjà 409 600 cases dans le tableau. Qu’on multiplie par le nombre de couleurs hexadécimales (255^3), ça nous fait donc 6 791 731 200 000 images différentes, rien que ça !

Du coup il s’agit de faire le tri entre les images générées qui ne ressemblent pas à quelque chose en particulier, et celles qui ont un lien avec la réalité.

Pour ce faire, il utilise un outil de reconnaissance faciale, vérifiant ainsi si l’image générée contient un visage et le notifiant quand une combinaison semble pertinente.

Le nombre de possibilités pose un autre problème, celui de la performance. Un tel nombre de combinaisons, et un tel script implique beaucoup de temps pour générer les combinaisons. Du coup il va mettre en place un système à la « seti-home » pour que les internautes de partout dans le monde puissent prêter une partie de leurs performances d’ordinateur pour l’aider à générer ces images. (plus d’infos sur ce concept ici)

Bref, une conférence qui me laisse un peu rêveur sur les possibilités encore non envisagées du web !

 

2- Responsible use of data visualization – Irene Ros

Cette conférence d’Irène Ros avait pour objectif d’expliquer comment faire une bonne représentation visuelle de ses données.

Je vais tacher de vous expliquer son raisonnement tel qu’elle nous l’a présenté.

Il faut avant même de vouloir représenter celles-ci, s’assurer de la véracité et de l’intérêt que présentent ces données.

Une fois cette étape validée, il ne faut pas forcément dessiner 100% de ses données. S’il n’y en a pas de trop c’est envisageable, autrement il faudra fusionner ses données ou en supprimer une partie à condition que cela ne change pas fondamentalement la valeur de l’information à délivrer.

Il faut ensuite savoir qu’une représentation visuelle spécifique des données n’est pertinente que si elle a une utilité et pour déterminer quelle représentation visuelle choisir. Et pour ce faire, il s’agit d’analyser les 4 points suivant :

> La relation entre ces données

Par exemple s’il s’agit de relations entre des internautes, un diagramme relationnel représentant les liens sous forme d’un nuage moléculaire est pertinent.

Dans un autre cas, il n’y a pas de raison d’avoir une telle représentation.

> La distribution des données

Il s’agit des tranches de données que vous souhaitez analyser, des tranches d’ages par exemple (de 0 à 5 ans, de 5 à 10 ans etc..)

> La comparaison

Il s’agit de trouver une représentation au plus simple pour comparer les différentes données que l’on souhaite mettre en valeur.

> La composition

La couleur, la forme, l’apparence affecte énormément l’interprétation. De ce fait, le chiffre 31 pourrait aussi bien évoquer un nombre de jour dans un mois pour certains, une date de naissance pour d’autres.

Par contre 31° peut impliquer une température ou un angle.

31° donne une notion de chaleur et ferait donc penser à des degrés Celcius

31° lui donne une notion de fraîcheur et peut donc faire penser à des degrés Farenheit

Un autre point qui peut-être intéressant c’est l’interactivité avec les données. Il est possible de n’afficher qu’une partie des données, et au clic sur une des tranches de données particulières, afficher un détail de cette tranche, etc..

3- Writing awesome code – Hans Christian Reinl

Ecrire du code n’est pas chose simple, et quand il s’agit de partager son travail ou de le réutiliser quelques mois après, ça devient une horreur pour comprendre ce que l’on avait réalisé à l’époque et une longue phase d’adaptation est requise, à moins de recommencer le script à zéro.

Hans nous présente dans sa conférence les différents moyens de faire en sorte que ce fameux code reste explicite, facile à utiliser et à ré-utiliser en quelques méthodes simple.

Commenter son code pour expliquer les fonctions, les appels, l’utilité des scripts utilisés, prendre des noms de fonctions et de variables explicites, ne pas penser à « ce qui pourrait être éventuellement nécessaire à l’avenir » mais se concentrer sur le besoin du moment présent.

L’interopérabilité du code si possible, afin qu’il puisse être réutilisé, amélioré ou que le reste soir amélioré sans que celui ci ne cesse de fonctionner.

De telles actions ne coûtent pas énormément de temps ni de poids dans les fichiers et permettent un gain de temps précieux dans le futur !

Et surtout, quand un code semble trop compliqué ou trop mauvais « if your code stinks, change it !« , il ne faut pas hésiter à le retravailler pour qu’il soit récupérable, compréhensible, clair et efficace !

Les slides : http://slides.drublic.de/takeoff-awesome-code/#/

 

4- Business logic in the cloud with google apps script – Thomas Parisot

Dans cette conférence, Thomas nous montre qu’il est possible à l’aide des Google Script de faire interagir des technologies Google avec des technologies externes telles que Twitter, linkedin ou même avec d’autres technologies google.

La méthode semble compliquée notamment à cause de la méthode d’insertion du code, du manque d’aide au débogage, de problèmes de sécurité (autorisation requise entre les différents logiciels pour interagir).

Dans les points positifs de ce code, on notera la possibilité de créer des librairies avec la possibilité de les appeler dans d’autres scripts/documents.

On note également les évènements du genre « creation de document », « ouverture du doc » etc..

Néanmoins ça ouvre des opportunités, pour faire intéragir les différentes APIs et pouvoir générer des rapports automatiquement ou faciliter la création de documents, les mettre à jour en live à l’ouverture etc..

 

5- Event-driven php – Igor Wiedler

Reactphp NodeJs alternative

Qu’est-ce que l’Event-driven php ?

C’est le projet sur lequel Igor Wiedler a travaillé et qu’il nous présente lors de sa conférence. Pour faire simple, si vous avez déja entendu parler de Node.Js, c’est une solution similaire mais en PHP.

Le principe est identique, à savoir une websocket (un canal de communication bidirectionnel) permettant d’envoyer/recevoir des informations en live sans rechargement de page. Ce genre de procédé permet par exemple d’actualiser l’affichage d’un internaute en live et grâce à ce principe de websocket laissée ouverte, ça peut notamment être utilisé sur un tchat, ou pour des requêtes très dynamiques entre client/serveur.

Les fonctions permettant ce genre d’opérations existent depuis longtemps sous php, mais celles ci sont à l’heure actuelle encore très mal connues. De ce fait, la méthode n’est pas encore très populaire.

Le concept est pourtant assez simple, il s’agit d’ouvrir une websocket, et de surveiller les évènements de lecture ou d’écriture sur celle ci tout en vérifiant en plus de cela toutes les secondes la connections.

Si une lecture ou une écriture a été faite, elle est récupérée et traitée avant d’être renvoyée sinon toutes les secondes il y a également une vérification.

Ainsi on obtient un site ou une appli hyper réactive, la seule problématique étant qu’il ne faut pas lier une websocket à un seul utilisateur mais à plusieurs. Autrement les ressources nécéssaires seraient énormes. C’est ainsi qu’il nous présente une solution de « non-blocking I/O » pour attacher plusieurs internautes à un seul « thread » (fil de communication).

Si vous en apprendre davantage, il est possible de revoir cette conférence en détail à cette adresse :

http://conference.phpnw.org.uk/phpnw12/schedule/igor-wiedler/#video

 

6- Web.Next – Robin Berjon

Web Next

Dans cet article, Robin aborde la question du futur du web, vers quoi on pourrait bien tendre et en analysant les technologies actuelles, imaginer ce qu’il sera possible de faire plus tard.

Il aborde la question de la reconnaissance vocale, qui n’est pas encore très répandue avec des fonctions natives sous certains navigateurs.

Exemple pour les possesseur d’un navigateur WebKit, cliquez sur le micro dans le champ suivant :

Et il ne s’agit là que d’un <input name=’takeoff’ x-webkit-speech=’ ‘ > !

Enfin, la question d’accessibilité dans le web et d’interopérabilité est également abordée.
Car oui, un jour le web sera peut-être enfin aux normes !

Les slides : http://berjon.com/presentations/20130117-web.next/web.next.html

7- 12 steps to win at software development – Gregg Pollack

12 steps to win at software development

Tout est dans le titre, cette présentation est un ensemble de guidelines pour réussir un projet.

Dans un premier temps il évoque le fait qu’établir une relation de proximité avec le client est une notion très importante, avoir des échanges rapides, pourquoi pas faire rencontrer l’équipe au client directement et utiliser des outils de gestion de projet.

Le deuxième point est l’ouverture d’esprit face aux technologies à utiliser, en écoutant les idées de l’équipe qui travaille avec vous, en partageant les problématiques, les objectifs et en discutant de la finalité souhaitée. L’idée c’est de prendre le temps de faire des brainstorming et de se forcer à utiliser un vocabulaire positif pour faire avancer les choses.

En commençant sa phare par « Oui et.. » par exemple.

« -On pourrait ajouter une fonctionnalité de partage facebook ! »

« -Oui et on pourrait utiliser le module ShareBox »

« -Oui et on pourrait le mettre en avant en le fixant sur le coté de la page »

Il faut apprendre à écouter les gens également.

En trois, c’est le rôle du développeur de faire du beau travail et le code bien conçu est une forme de beauté dont il doit être fier.

En quatre, il faut apprendre à déléguer les taches auxquelles on ne prend pas de plaisir à faire si cela peut faire plaisir à quelqu’un d’autre et vice-versa. Il y a surement des choses qui sont pas agréables pour vos collègues qui vous apporteraient du plaisir à faire. Il ne faut donc pas hésiter à répartir les taches.

Cinq et Six, il faut savoir apprendre dans la compagnie comme en dehors. (Travail collaboratif, auto formation, Relecture des scripts à postériori, Rétrospectif, partage des scripts pour en discutter.

Le septième point est de se faire des amis, de construire des relations, ne pas hésiter à manger tous ensemble, à mettre en avant les relations dans le travail.

Plus de relationnel = plus de bonheur = un meilleur travail

En huit, ne pas hésiter à demander de l’aide, ne pas buter sur une problématique plus de 30 minutes, si quelque chose prend trop de temps, la méthode utilisée n’est sans doute pas la bonne..

Neuf, se débarrasser des distractions, les minimiser. Prioriser les activités, utiliser les communications asynchrones (mail plutôt que téléphone ou contact visuel)

Dixième point, la solution la plus complexe est rarement la meilleure.

Onzième : il faut communiquer mieux que quiconque et partager les idées, les connaissances. (Skitch ou Jing sont des outils prévus à cet effet)

Et douzième point : Il faut déterminer ce qui vous apporte du bonheur.

Bref, superbe conf, le pdf est accessible ici :

http://courseware.codeschool.com/uploads/12_steps_takeoffconf.pdf

 

8- Push and use responsive images – Anselm Hannemann

Les images en responsive, voila un sujet que j’attendais avec hâte car la problématique est fréquente et les solutions encore mal exploitées.

Car si en prenant une image de bonne qualité et en l’adaptant à la largeur de son conteneur fluide pouvait jusqu’ici faire office d’image dite « responsive ». Ce n’est désormais plus suffisant avec des écrans « rétina » qui requièrent une image jusqu’à quatre fois plus lourde pour avoir un rendu maximum.

Bref il fallait une solution et voila plusieurs années qu’Anselm se bat avec toute une communauté pour faire passer un standard d’images afin de pouvoir définir en html un tag unique permettant plusieurs sources à un fichier d’image.

Ainsi la balise Picture est née:

<picture>
<source src="small.jpg" media="(max-width: 20em)">
<source src="normal.jpg" media="(min-width: 20em)">
<source src="image.tiff" media="print">
<img src="small.jpg" alt="fallback image">
</picture>

Mais le temps d’actualiser les standards il fallait un moyen de remplacement : l’attribut SRCSET est né, il est donc possible via cet attribut de définir plusieurs sources sur une balise IMG ainsi :

<img src= »fallback.jpg » alt= » » srcset= »small.jpg 640w 1x, small-hd.jpg 640w 2x, med.jpg 1x, med-hd.jpg 2x « >

Et encore une fois la problématique est que le seul navigateur capable de comprendre cet attribut est Chromium avec une extension prévue à cet effet..

Du coup un polyfill Javascript a été créé, permettant de switcher sur le bon fichier source en fonction du device: github.com/scottjehl/picturefill

L’écriture actuellement utilisable est donc :

<div data-picture data-alt="alt text">
<div data-src="small.jpg"></div>
<div data-src="medium.jpg" data-media="(min-width: 400px)"></div>
<div data-src="large.jpg" data-media="(min-width: 1000px)"></div>
<noscript>
<img src="external/imgs/small.jpg" alt="alt text">
</noscript>
</div>

En définitive, il sera un jour possible d’utiliser des images « responsive » qui s’adaptent vraiment au device, mais d’ici là il faudra feinter comme on sait si bien le faire avec un script JavaScript.

Les slides :  http://slides.anselm-hannemann.com/respimg-takeoff/#/

 

9- 3D CSS, finding the right perspective – Peter Westendorp

La magie du CSS 3D, c’est là l’object de la conférence de Peter Westendorp.

Si vous n’avez pas encore vu le potentiel du CSS 3D je vous conseille de commencer par regarder ces quelques liens :

http://codepen.io/peterwestendorp/pen/wGECk

http://keithclark.co.uk/labs/3dcss/demo

http://2012.beercamp.com/

http://clicktorelease.com/code/css3dclouds

Bref, les possibilités sont assez vastes. Et tout ceci est possibles grâce à l’ajout de fonctionalités CSS dans les dernières normes qui sont majoritairement admises par les navigateurs.

Ainsi les CSS transform nous permettent de définir une perspective et des positions en X / Y et Z ainsi que des translations/rotations/animations dans cet espace.

Le résultat est assez fou, mais l’apparence reste assez « plate » et vous n’aurez pas d’effet ombre/lumières en css.

Pour des représentations plus poussées il faudra se tourner vers du WebGL / Three.Js

Les slides : http://peterwestendorp.github.com/3d-css-talk/#/

 

10- Clean and clear software with Erlang – Anthony Eden

Erlang c’est un langage fonctionnel à très haute disponibilité, c’est à dire qu’il s’agit d’un langage conçu pour rester stable, avoir une notion de tolérance aux erreurs, aux pannes.

Au dela de ça, ses processus sont extrêmement léger et il utilise le parallélisme pour faire le plus de chose possibles dans un intervalle court ce qui fait de lui un langage fiable et rapide.

Ce qui fait son avantage est également le défaut reproché à celui ci, il s’agit d’un langage de contraintes, des contraintes qui permettent une fiabilité accrue.

La syntaxe du langage est donc difficile à maitriser, mais si le langage souhaité est un langage fonctionnel, fiable et rapide, vous avez votre solution !

Les slides : https://speakerdeck.com/aeden/clean-and-clear-code-with-erlang

 

11- Science-based development – Olivier Lacan

Cette conférence était très axée sur notre travail à Altima en Optimisation, c’était donc intéressant de suivre ses méthodologies et sa façon de voir les choses !

Au travers de cette conférence, Olivier nous montre que réaliser des expériences scientifiques permet d’avoir des réponses, une approche de la vérité, de la solution à une hypothèse.

Et cela est très important dans tous projet car concevoir un outil sans avoir la certitude de son efficacité ou de son impact final c’est risquer de propager du mécontentement, de devoir recommencer, améliorer.

Alors qu’au final une simple expérience peut réveler les pistes d’une solution idéale.

La science c’est exactement ça, des expériences, des tests, des réussites et des échecs.

Et il ne faut pas voir un test qui ne réussit pas comme une perte de temps. C’est une expérience acquise.

Et comme dirait Thomas Edison lors de ses recherches sur l’électricité:

« Je n’ai pas échoué mille fois. J’ai simplement découvert mille façons de ne pas faire une ampoule électrique. »

Pour être un « bon scientifique » il faut être ouvert à la vérité. On a beau passer sa vie à croire une vérité pseudo démontrée par mille expériences, quand on est face au fait qu’il ne s’agissait que d’une erreur, il faut savoir comprendre et changer sa vision des choses.

Il faut être curieux également, toujours creuser pour en savoir davantage, chercher le détail qui changera tout.

Savoir émettre des hypothèses vérifiables, un concept, une idée avec une logique strictement définie qui se vérifiera via l’expérience.

Analyser les résultats pour établir des conclusions, tirer le meilleur parti de ce test, comprendre et anticiper un test suivant.

Appréhender le fait que l’hypothèse peut échouer et ne pas s’arrêter de chercher des solutions.

Savoir partir du principe que la perfection n’existe pas, il y a toujours moyen de faire mieux !

Oser reproduire les expériences pour s’assurer que la réponse n’était pas un hasard.

Et partager le savoir avec la communauté !

Les slides : https://speakerdeck.com/olivierlacan/science-based-development

 

12- Go: Code that grows with grace – Francesc Campoy Flores

Francesc Campoy Flores qui travaille à Sydney pour Google nous présente le langage Go.

Go est un langage opensource souple, sans définition de classes, avec des interfaces préconçues pour faciliter son usage. Ses « threads » sont léger, il reste donc rapide d’exécution et ses connections sécurisées.

Comme dans beaucoup de langage, on commence par importer les librairies dont on va avoir besoin puis le code s’exécute dans une fonction « main » et au final, vu que le code est très axé interfaces, en quelques lignes il est très facile d’établir un tchat en TCP (serveur/clients).

Il y a une gestion des erreurs, bref je pense qu’il ne reste plus qu’a s’y essayer.

Les slides : http://talks.golang.org/2012/chat.slide#1

13- Let’s fly to the moon! – Jerôme Etienne

Three.js est une librairie 3D en JavaScript, en la fusionnant avec jQuery, on obtient un langage simple permettant de réaliser du webGL, à savoir de la représentation 3D sur le web.

C’est l’objet de la conférence de Jérôme Etienne qui nous montre ô combien il est simple contrairement à ce que l’on pourrait imaginer, de réaliser du 3D avec les librairies existantes.

L’idée de tQuery, au delà de la simplicité, est également de permettre à la communauté de créer des extensions et donc de partager plus facilement le travail sur ces langages. Cela permet également d’établir un ensemble de règles chainées sur un même élément.

Bref tout est très simple d’utilisation et le résultat est là. En quelques lignes de code on a facilement une représentation 3D de ce que l’on veut.

Quelques exemples de webGL :

http://jeromeetienne.github.com/demo.flymetothemoon/

http://jeromeetienne.github.com/demo.minecraftolympus/

http://jeromeetienne.github.com/tquery/plugins/car/examples/

Davantage dans ses slides :

http://jeromeetienne.github.com/slides/tquery.takeoffconf2012/#1

14- Network architecture based on game philosophy – João Moura

Un site web aussi réactif qu’un jeu en ligne ?

Cette conférence était selon mon point de vue, l’une des plus intéressantes.

Créer des applications avec la philosophie des jeux vidéos ? Le concept est plutôt étrange et pourtant la logique est imparable.

Dans les jeux vidéos, tout est prévu pour qu’aux yeux du joueur tout semble instantané, fluide, la logique est axée sur l’interactivité instantanée avec le joueur. Et si cela existe sur de applications web en ligne, c’est qu’il est également possible de s’en inspirer pour des sites webs !

La performance est une notion hyper importante dans le web, elle agit directement sur le chiffre d’affaire, le taux de rebond et sur l’efficacité de votre site web. Alors pourquoi nos sites webs ne pourraient ils pas être instantanés, fluides eux aussi? Comment font les jeux vidéos pour répondre aussi rapidement à la demande de milliers de joueurs?

Certes, le code est optimisé et les requêtes doivent être légères au possible. Au delà de ça, l’ensemble de l’interface est préchargée au lancement de la page. Les images, les vidéos, les musiques, tout est déjà placé coté utilisateur et tout est préchargé en avance.

Les navigateurs de nos jours ont un cache assez important, il est donc judicieux d’agir de la même façon et de télécharger le maximum coté utilisateur pour s’en servir au besoin.

Le deuxième point c’est qu’il faut absolument savoir faire la différence entre la rapidité d’un site web, et la sensation de rapidité d’un internaute.

Le gap entre ces deux notions est énorme un site web rapide c’est un objectif hyper dur à atteindre qui implique des tas de modifications. Alors que la sensation de rapidité, c’est optimiser la navigation de sorte à ce que l’internaute aie l’impression que tout est instantanée ! C’est une grosse nuance car ça implique  que le site n’a pas besoin d’être plus rapide.

Il doit simplement effectuer les actions de l’internautes les unes après les autres sans attendre ou bloquer sa navigation, et pré-afficher le fait que l’action a été faite et le tour est joué !

Après quoi, si le serveur renvoie une erreur, il suffira de corriger l’affichage et d’en notifier l’internaute, c’est moins problématique qu’une lenteur systématique.

Tel l’équipe Pré-crime de Minority Report, il faut savoir utiliser la précognition !

Anticiper les actions d’un internaute pour précharger en avance ce qui l’attend.

Le web nous livre le pouvoir de charger des éléments en asynchrone, pourquoi ne pas s’en servir  ?

Bref, ce qu’il faut retenir c’est que la notion de sensation de rapidité est différente de la rapidité d’un site web. Et qu’il est possible de faire des sites web à chargement instantané aux yeux des internautes. C’est ce qui se fait dans les jeux vidéos, alors il n’y a plus qu’à faire de même sur le web ! 🙂

https://speakerdeck.com/joaomdmoura/network-architecture-based-on-gaming

 

15- Designing better javascript apis – Rodney Rehm

Quand on travaille sur une api javascript, il est important de réaliser un code stable, réutilisable et facilement intégrable, l’interopérabilité est une notion indispensable.

Il faut un code simple à comprendre, à lire, à utiliser, ça ne signifie pas un code techniquement simpliste.

jQuery prévoit un moyen simple d’incorporer ses plugins, d’étendre les fonctions existantes.

Pour réaliser une api javascript idéale, c’est un exemple à suivre.

Et enfin il faut que vos fonctions soient complètes, adaptables, modifiables et utilisables dans tout types de situation. Enfin, je pense personnellement qu’il est bon de coupler ces recommandations avec les recos de la conférence « Awesome Code ».

http://rodneyrehm.de/slides/2013-takeoffconf-designing-better-javascript-apis/index.html#/

mots-clés :

, ,

articles à lire ensuite...

Laisser un commentaire

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

Vos commentaires (0)

Génial cet article ! Un beau résumé de pas mal des conférences de la Take Off !

0
0

Retour sur le TakeOff Conference de Lille 2013