10/19/2014

Check-build - Verify that your NodeJS project follow conventions, is well written and secure

Each time I start a new project/mvp/poc/module I don't want to create/edit a new make/grunt/gulp file or whatever hype dev use these days. I want an already packed CLI with good defaults (mine) that I can drop into my continuous build/integration process. Let's build that once and for all.
– 10/19/2014

check-build leverage jshint, jscs, jsinspect, buddyjs and nsp, to enforce DRYness, coherent coding-style, prevent errors and automatically check security issues.



check-build will be gradually integrated into all our projects at Bringr, Redsmin, UserAPI and the soon to be announced Spid project.

9/01/2014

Human benchmark and Mr Trololo


8/25/2014

Dot-clipboard - monitors your clipboard and runs scripts based on its content

When I first thought of — and implemented — clipboard-watcher I knew I will then have to build something like dot-clipboard.

It tooks me a few hours of hard passionate work with NodeJS fs.watch and clipboard-watcher to build the core and a few more hours to write the first download-gif script.

I really liked playing with the idea of script hot-reload and auto-checking. Actually some of these parts are already re-used inside an upcoming project that is targeting a much larger problem : website and SaaS performance... At the time of writing we already have a functional prototype but I will share more on this later...

Coming back to dot-clipboard, the release went well : first page on Hacker News, more than 3 000 unique visitors on Github and some interesting tweets :




Now let's see what scripts the JavaScript/NodeJS community will build!

7/09/2014

[Fr] QuickWin Startup - la session productive du vendredi après-midi

Qu’est-ce qu’un QuickWin ?

Un QuickWin est un challenge dont l'essence même est de développer une idée dans un temps limité (2 heures environ). De la conception à la mise en production de la première itération d'une fonctionnalité, l’objectif est d’impacter au maximum l'utilisateur final en lui proposant in fine des améliorations visibles.
De cette définition, les QuickWin sont alors comparables aux 20% chez Google (bien que le concept semble s'essouffler avec le temps) à la différence qu’ils sont directement pensés pour servir un triple objectif à savoir être en cohérence avec la taille (réduite) des ressources humaines des startups, renforcer l’équipe autour d’un objectif ephémère commun et permettre le perfectionnement rapide du produit.
Par ressources humaines j’entends qu’en startup, contrairement à Google, nous nous battons pour survivre et optimiser nos acquis, lorsque nous lançons un développement il faut qu'il soit utile sur le plus ou moins court terme, les QuickWin sont donc pensés dans ce sens.
Les QuickWin allient l'agréable (sessions recréatives) à l'utile (augmentation de la valeur perçue du produit). Chez Bringr nous réalisons les QuickWin tous les vendredi après-midi. L'initiative de chaque QuickWin est libre mais doit d'abord être validée par le reste de l'équipe. Les participants sont mobilisés selon les compétences requises.

Les 3 fondements du QuickWin

Lors de l'émergence du concept, j'ai formalisé 3 contraintes qui m'apparaissent indispensables au bon déroulé d'un QuickWin à savoir :
  • la surprise : chaque membre de l'équipe doit attendre le lancement d'un QuickWin pour dévoiler ses idées à l'ensemble de l'équipe, ce qui peut le contraindre à garder son/ses projet(s) une semaine durant. De cette façon, cela permet à chacun de se concentrer sur ses tâches dédiées hebdomadaires et se consacrer intégralement lors des sessions de QuickWin par des réflexions et travaux totalement différents. Il est donc préférable de ne pas être à l'origine de son propre QuickWin pour garder cet effet de surprise.
  • la restriction temporelle : un QuickWin est par définition rapide à concevoir, implémenter, tester et mettre en production. Si l'itération n'est pas réalisable en moins de deux heures (théorique) alors cette fonctionnalité doit être implémentée lors d'une itération classique.
  • l'impact visuel (instant feedback) : un QuickWin doit avant tout être visible par l'utilisateur final. L'impact sur l'interface ou l'utilisation de service doit être immédiate.

Ces 3 contraintes assurent le bon déroulé du QuickWin et participent à la création d'une sensation de challenge, sensation très utile et agréable pour les vendredi après-midi.

Pourquoi sont-ils importants ?

  • ils permettent le team building par la mobilisation et la participation de toute l’équipe, quelles que soient les compétences de chacun. Les QuickWin suscitent l’entraide des uns envers les autres et ce, dans un climat de pression (limitation dans le temps) et de stimulation pour tendre vers un objectif commun. C'est la définition même du team building : nul besoin alors de passer par un entrainement militaire de plusieurs jours pour améliorer l’esprit d’équipe, le QuickWin le fait pour vous !
  • ils suscitent la motivation et la créativité pour la conception d'une partie du produit qu'il faudra implémenter rapidement. Alors pendant que certains ont déjà l'esprit en week-end le vendredi après-midi, nous, nous efforçons de rester créatif et performant pour mieux servir nos utilisateurs.
  • l'équipe de développement respire en suivant la règle des 20/80.
  • ils permettent de se concentrer sur un sujet autre et extrêmement bien défini et ainsi s'extirper de la résolution du "sujet problématique de la semaine" (comme il en existe chaque semaine dans une startup !). La prise de recul constitue d'ailleurs souvent une source de solutions.
  • ils permettent de se focaliser sur des problématiques beaucoup (beaucoup) plus restreintes que les contraintes habituelles et limitent donc le stress.
  • ils permettent d'éviter le syndrome de l'imposteur puisque chaque membre de l'équipe doit participer et s'impliquer dans l'amélioration rapide et quantifiable du produit.
  • en seulement deux heures avec une équipe de 6 personnes il est possible de publier en même temps des améliorations visibles tant sur la partie communication (ou marketing) que sur des fonctionnalités pures. 
  • après la session de QuickWin, l’équipe ressent une sensation d’accomplissement, d'achèvement, et peut donc partir en week-end l'esprit libre.

"Done Is Better Than Perfect" ― Sheryl Sandberg
“L’homme qui déplace une montagne commence par déplacer les petites pierres.”  Confucius

6/09/2014

[Fr] Retour sur le Web2Day

Une fois de plus toute l'équipe de Bringr et moi-même avons eu la chance de participer au Web2Day cette année.
Je n'ai pas pu suivre beaucoup de conférences à part (en ordre chronologique) :

1 - Le talk de Stan Massueras de Twitter m'a conforté dans notre vision de Bringr. Nous avons un outil adéquat dans Bringr pour chaque problèmatique que Stan soulevait concernant l'utilisation de Twitter comme outil de communication ou de marketing.


2 - Le talk de Olivier Ezratty sur les semi-conducteurs. Chaque slide étendant un peu plus les limites de notre curiosité (plutôt que d'enfoncer des portes ouvertes comme c'est trop souvent le cas dans ce type d'événement). Terminé le cloisonnement des connaissances, Olivier est même allé jusqu'à nous montrer la formule de la transformation chimique utilisée dans la purification du silicium. Mes connaissances sont limitées sur le sujet mais ayant fait un bac scientifique cela m'a rappelé quelques souvenirs !


Bref, talk passionant, speaker actif et inspirant, on souhaiterait en voir plus souvent !
3 - La table ronde sur le Growth Hacking avec Oussama Ammar de The Family et Willy Braun de France Digitale. Étant un addict du channel youtube Startup Food, j'avais déjà vu la conférence de Willy sur le Growth Hacking.
Donc plutôt que d'observer le fond du talk, je me suis intéressé à la forme, ce qui a eu pour résultat le tweet ci-dessous ainsi qu'une proposition détaillée plus bas dans cet article.

4 - Le talk de François Le Pichon sur les nouvelles interfaces digitales.

Ensuite voici quelques retours triés par ordre d'importance et d'utilité :

Format des talks

Problème : nous sommes beaucoup à avoir trouvé que les talks sous forme de débat ont un réel problème de ratio signal/bruit.
Possible solution : Un nouveau format est possible à la place des tables ronde. Prenons l'exemple du débat autour du Growth Hacking magistralement géré par mon co-fondateur et ami Simon Robic. Un format plus explicite aurait été de sélectionner aléatoirement puis d'appeler sur scène une équipe du startup contest (ou la team gagnante du Startup Contest de l'année précédente) et d'utiliser les 45 minutes pour un échange entre les mentors et l'équipe afin d'appliquer et de trouver des techniques de Growth Hacking.

Pour ajouter de la profondeur à l'échange, les mentors auraient pu illustrer leurs choix par des cas d'usage et du story telling.

Bien entendu, ce format ne peut fonctionner que si la startup sélectionnée a quelque chose à optimiser et à montrer (un site web dans le cas d'un SaaS par exemple). L'idée est d'utiliser ce format pour permettre à l'audience de découvrir le Growth Hacking par la pratique, de discerner les patterns de pensée et les méthodes qui permettent de sélectionner la première métrique sur laquelle cette startup test doit se concentrer et comment elle peut l'optimiser.

La backroom est aussi appelée à poser des questions via Twitter, voir même à intervenir par une prise de parole (le cas typique serait un entrepreneur ayant la même métrique à optimiser).

La startup de test sur scène deviendrait alors un vecteur, une ligne directrice, de la discussion.

Programme du Web2Day

Problème : il nous est arrivé plusieurs fois d'aller à une conférence sans trop savoir de quoi il s'agissait. On a plusieurs fois essayé de deviner la teneur d'un talk en regardant d'où venait la personne. Les titres sont parfois très trompeur, il nous était impossible de deviner que "Why excel sucks in 2014" était un talk sur les PIM et l'e-commerce.
Possible solution : ajouter une description directement dans le programme (ou du moins sur la version web) et spécifier le format du talk (débat, conférence, workshop).


Stabilité du wifi

Problème : le DHCP du Wifi était souvent down et le débit était limité, c'est toujours dommage pour un événement technophile.
Possible solution : Si ce n'est pas déjà le cas, il serait intéressant de trouver un sponsor dans le domaine télécom qui se chargerait de maintenir les bornes wifi, le DHCP et d'assurer le débit. Un rewarding immédiat pourrait par exemple être l'ajout du nom du sponsor dans le SSID, par exemple "Web2Day - [Sponsor]" ou encore l'ajout d'un screen d'accueil lors de la première connexion. (Ce screen pourrait d'ailleurs proposer le programme du Web2Day, les flux vidéos, (géo/tempo)-localiser la personne pour lui indiquer les conférences en cours et à venir les plus proches etc....).

Plateforme de feedback

Problème (meta) : les feedbacks (comme celui-ci) sont unidirectionnel.
Possible solution : Pourquoi ne pas utiliser une plateforme du type getsatisfaction ? Un système de vote permettrait de mieux comprendre les attentes et les problèmes des visiteurs et un moteur de recherche lors de la soumission d'un retour pour limiter les doublons.

Circulation dans la salle maxi

Problème : la partie haute gauche (vu depuis la scène) de la salle maxi était vide car personne n'osait circuler derrière la régie.
Possible solution : pourquoi pas condamner une (ou plusieurs) rangée de siège pour permettre le passage d'un côté à l'autre.

Sandwichs

Problème : la vente des sandwichs nous a bien dépanné (merci à toute l'équipe) mais malgré les 3 bénévoles une queue s'est formée. Les bénévoles devaient répéter pour chaque personne la liste des sandwich disponible.
Possible solution : un tableau des sandwichs en plus de celui des formules avec la possibilité de rayer les sandwichs épuisés. Si une queue se forme, au moins les gens auront le temps de faire leurs choix et le passage en caisse sera plus rapide.

Encore une fois un grand merci à toute l'équipe du Web2Day à NantesTech pour ces 3 jours exceptionnels.

Merci à David Sferruzza pour la relecture.
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.
3/12/2014

How to configure ng-animate to work on a restricted set of elements

Out of the box ng-animate attempt to perform an animation on any element. That's not what you may want if you are building an application for low-powered devices with lot of structural operations. Here is how to overcome this issue and deactivate ng-animate for everything but specific elements.


2/23/2014

Cassandra: ReflectionException: Signature mismatch for operation forceRepairAsync

When running nodetool -h somewherelse you may encounter the above exception:
This exception was thrown because there is a Cassandra version mismatch between from where you ran this command and the Cassandra version installed on somewhereelse. The installed version can be verified with: So the solution is simply to install the same Cassandra version on both node.
1/19/2014

How to backup your Droplr account (before they discontinue your free account)

Cause

Two weeks ago I received the following email from the Droplr team (quoted):
Next week we will release some exciting new features to Droplr that we’ve been working on for a long time and that many of you have been asking us for. At that time, we will be discontinuing our free accounts. All current free accounts and new sign ups will be placed on a 30-day trial. At the end of 30 days, you’ll be asked to pay for a Droplr subscription if you'd like to continue using it. If you don’t want to pay, you won’t be able to upload any more files, but none of your existing data will be deleted, and all of your links will continue to work.
I don't know about you but I felt like being held in hostage when I discovered that Droplr offered no way to export/backup my account nor an open API to programmaticaly do that.

Consequence

As usual I started to write a tool to export my 5322 drops. Here is how DroplrBackup came to life, see the full tutorial on Github (only tested on Google Chrome/MacOS).

Alternatives

Some great open-source alternatives exist, give a shot to FileShuttle or Upshot.

« »
 
 
Made with on a hot august night from an airplane the 19th of March 2017.
http://bit.ly/1II1u5L