5/17/2014

[Talk] Introduction to Redis at Human Talks Nantes

This week I gave a talk on Redis at the third Human Talks Nantes.

I find it kind of sad that each Human Talk is limited to 10 minutes. I know it's a way to discover many technologies rapidly but I see this kind of talks more like 24h news. In 10 minutes we simply don't have the time to go deeper into the subject, leaving sometimes the audience on false belief. Hopefully and exceptionally we were allowed to stay more time on stage. So with the Q&A included I was able to talk about Redis for 30 minutes and tackle deeper subjects like how Redis replication algorithm works, how to use Redis as a LRU cache, how Redis failover works with Sentinel and so on.


Everything went smoothly I will surely give another talk on Redis and it will be way more practical this time!

5/03/2014

[Fr] {StretchText} Retour sur ma première soutenance en tant qu'examinateur

Contexte: La rédaction de ce billet à débutée un vendredi soir (le 2 Mai 2014). Au fur et à mesure de l'écriture une idée vieille d'au moins 4 ans m'est revenue. J'ai toujours voulu permettre aux lecteurs de sélectionner le niveau des détails dans mes articles. C'est d'ailleurs ainsi que nous communiquons, nous commençons par aborder une première couche d'information (la surface) pour petit à petit descendre dans les "strates" afin d'être le plus précis et intelligible possible.


J'ai donc quitté temporairement l'écriture de ce billet afin de démarrer une autre écriture, celle du code. Après quelques minutes, content d'avoir enfin pu concrétiser ce rêve cette idée. J'ai décidé d'aller lire la définition d'HyperText sur Wikipédia (pourquoi ? Parce que j'avais secrètement nommé ce Proof-of-Concept HyperText). Et c'est à ce moment là que j'ai (re-)découvert le concept de StretchText. Mince ! Dès 1967 Ted Nelson avait eu l'idée de permettre le zoom-in et zoom-out sur le niveau de détail d'un texte. J'avais donc implémenté StretchText avec 47 ans de retard ! La note de T. Nelson sur StretchText est vraiment passionnante, je voulais aussi utiliser des liens (e.g. soulignés en pointillé) pour étendre et réduire le texte mais par soucis de simplicité et par manque de temps j'ai choisi d'utiliser un "[+]" pour remplacer ce comportement.


J'en ai aussi profité pour ajouter un slider et une estimation du temps de lecture. Il serait maintenant intéressant de développer un éditeur (en utilisant contenteditable) qui facilite l'écriture de texte StretchText mais cela sera pour un autre jour !

TL;DR Complet
Temps de lecture : 0 sec

Aujourd'hui j'ai eu la chance de faire passer à des élèves de seconde année de l'EPSI Nantes leurs premières soutenances. Le mot soutenance est sans doute un peu galvodé ici. Il s'agit plutôt d'une présentation de leurs projets suivi d'une séance de questions/réponses.

Ayant moi même passé ce type de soutenance dans un passé relativement proche, j'ai pu y appliquer quelques modifications qu'il me semble intéressant de partager ici. Ce billet a aussi pour but de me servir de compte-rendu sur mes différentes "expériences". Cette trace écrite me permettra au fil des années, je l'espère, de prendre du recul sur ce qui fonctionne et ce qui ne fonctionne pas.


Voici donc les quelques modifications apportée par rapport à ma propre expérience des soutenances :

  • Toute la classe était présente à la soutenance. Le premier avantage logique et que cela permet aux élèves de s'entrainer à maintenir l'attention d'une audience ainsi que de les former à la présentation de projets. Un autre avantage auquel je tiens personnellement beaucoup est que cela permet de partager aux autres les parties intéressantes de son projet, tant d'un point de vue du code que fonctionnel. C'est une forme de récompense que de pouvoir faire découvrir quelque chose de nouveau aux autres. Mieux, l'orateur prends du plaisir à partager et l'audience prends du plaisir à découvrir. Cette approche vertueuse stimule la curiosité intellectuelle qui est pour moi l'une des composantes principales de l'esprit Hacker par "esprit Hacker" j'entends Hacker au sens culturel.
  • Les élèves devaient présenter l'architecture du système et les choix opéré. Obliger les élèves à décrire le projet sur une échelle macroscopique permet de démarrer une critique vis à vis des choix opérés. Comme toujours en informatique, tout est une question de balance e.g. CPU vs consommation mémoire dans le cas des algorithmes. Pouvoir expliquer pourquoi un choix à été fait dans un sens et non dans un autre montre qu'il y a eu une étape de réflection dans le cas inverse, cela montre qu'il faut simplement sensibiliser l'élève à séparer les différentes entitées de son projet. Enfin cela oblige à penser composants ou services suivant l'échelle avant de penser à l'implémentation erreur habituelle lorsque l'on découvre la programmation. L'idée est de former l'élève à penser les composants de son projet en terme de séparation d'intérêts à cette échelle on parlerait de nos jours de Service-Oriented Architecture, SOA n'étant qu'une application du principe SoC à une plus grande échelle.
  • Il était conseillé aux élèves de montrer des parties intéressantes de leurs codes.Cette approche m'a permis parfois de stopper la soutenance, demander au groupe ou à la classe s'ils voyaient un problème à la ligne X, d'expliquer quel était le problème en question et ensuite de reprendre la soutenance. Nous avons ainsi pu découvrir et corriger une faille par Denial of Service (DOS) ce problème DOS venait d'un require dynamique en NodeJS dont les entrées n'avaient pas été contrôlée et simplifier l'implémentation d'un algorithme du déplacement des pions d'un jeu de dame en changeant simplement la structure de données gérant l'echiquier.
  • Même si les projets étaient techniques, mes remarques à la fin des soutenances ont aussi portée sur les techniques d'expression et de présentation. Ces petites astuces pleines de bon sens que l'on apprends avec le temps comme par exemple: répéter en groupe avant la soutenance, répartir à l'avance le temps de parole, utiliser les slides plus comme un support visuel que textuel, regarder au loin plutôt que ses pieds etc. ... Bref, du bon sens.

Ce que j'ai repris :

  • Limitation temporelle et visuelle. 12 minutes de présentation, 12 minutes de questions/réponses, 5 slides maximum pour poser le contexte. Cela force les élèves à rester succinct à s'exprimer clairement.
  • ... tout le reste finalement.

Il est encore trop tôt pour tirer des conclusions, cet article sera donc tenu à jour au fur et à mesure des soutenances mais d'après les premiers retours cette approche a été satisfaisante pour la majorité des élèves. Cette première soutenance a donc été l'occasion de continuer à partager sur diverses technologies et aussi à guider les choix architecturaux de certains projets dont, je l'espère, le développement ne s'arrêtera pas à cette soutenance. Peut-être est-ce trop d'optimisme, le temps nous le dira !

5/01/2014

[Book Review] Getting Started with Grunt: The JavaScript Task Runner

Context

When Packt contacted me to review this book it was fairly natural to me to accept the offer. We are huge fan of Grunt* at Bringr and Redsmin and use it a lot in our everyday workflow.


This book was really quick and easy to read (about a day). While reading it, I discovered that it was primarily written for beginners in mind so I personnally did not learned a lot of new things but that's fine since it will be a great book for them.


Review

Getting Started with Grunt is the perfect book for anyone who wants to improve their workflow with Grunt while building JavaScript applications.

With only 112 pages the book is really short and easy to read, it took me about one day to read it all. It was written for javascript beginners but contains however some tips for advanced developers.

Chapters are written gradually, from building your directory setup to writing your first Gruntfile followed by an introduction on how to write multi and asynchronous grunt tasks.

Broader subjects are explored like: why you would want to use static analysis tools like JSLint or JsHint in your project; what are NodeJS and NPM; how NPM dependencies management works; what is transcompilation and how to configure grunt to transcompile CoffeeScript, Jade and Stylus files; etc.…

I would recommend this book to anyone who doesn't know very much about Grunt, or anyone who just wants a reference for it.


* we are planning to move on Gulp.
« »
 
 
Made with on a hot august night from an airplane the 19th of March 2017.