You don’t need to be scalable from day 1

I see so many developers asking themselves the following question :

How should I write my code so that it will work if the traffic explodes ?

I believe thinking about this from day 1 is counterproductive. Here’s why :

Most of the time, you aren’t going to scale

Yes, that’s a truth, 99% of the projects will never have to scale. Some of the projects will die, others will just reach a certain amount of users and stay stable from there. Thinking you are part of those few organizations that will scale is an illusion. Furthermore, most of the time, you’ll see when you project is starting to get more traffic. When you know this, you will be able to adjust the size of your team. It is faster than ever to change the size of your team.

The overall speed of your growth is defined by the limiting factor

I went to a generalist engineering school, so I’ve done a bit of chemistry too, and here’s what I learned from that :

If one crop nutrient is missing or deficient, plant growth will be poor, even if the other elements are abundant.

Liebigs Law

Applied to start ups, this means that you can’t scale your business if you just make your application technically scalable. There’s customer acquisition that is very often a limiting factor, but also other bad conversion rates between the acquisition and the revenue.

They are some cases when your app’s design is the limiting factor of your growth, but in this case, you probably know it yourself (because your app is slow, customers give bad feedback , …).

Support is one of your main marketing channel

At beequick, our top priority is answering to support tickets/incoming mail. When a customer asks us something, we try out best to answer in the following hours. However this is not the case everywhere.

The current state of support

I have seen many companies where the employees would say:

This is Tom’s problem, he has some holiday, so I won’t answer that ticket.

And the ticket stays unanswered for a week or more. What a nonsense !

An other problem appears when separating the support team from the development team. Rule number 5 of Six simple Rules states:

5. Extend the shadow of the Future

What does that mean ? It is about responsibility.

If the people who build your stuff are not as well responsible for the support, your developers will not care if the product gets better. If your developers are not responsible for support, the customer feedback loop is broken. This feedback loop ensures that requests of your customers are getting implemented in your product. The customer feedback loop is one of the most important feedback loop in business, especially in the start up environment.

Put your customer’s requests first in line

I don’t have data to prove it, but from experience, I have always felt that customers who get quick answers are more loyal than others. Often a first support ticket that was answered quickly can trigger a purchase from the customer. For example, that’s what triggered the buy process when I first got a response from the support guys at fortrabbit.

It makes your product more valuable

A reason I’m never going to buy again from DELL is their poor support. 2 years ago, I booked a computer on their site, but I never received it. I had to speak hours over the phone with different persons who would never listen to me. They had standard problems they were able to solve, but anything outside of the standard was too complicated for them. I finally got my cash back but without any hassle.

When on the contrary, the support you get is personal, friendly and fast, you appreciate the product even more. It humanizes the product.

Having great support at the beginning doesn’t cost much

At the launch of your product/startup, you should try to do as much support as possible. Don’t try to hide the support button or make « premium paid support ». Support will bring you a lot of:

  • Valuable feedback from real customers : what do they like/dislike, where do they have difficulty to understand your product, what is important to them and what doesn’t matter
  • Trust : when trying a new product that just launched, you just don’t know if the product will still exists 6 month from now. Having spoken with someone about the product will at least give your customers more confidence.

Don’t eliminate support when you become bigger

When companies get bigger, they try to reduce their support budget. The reason for this is the scale argument : we are currently scaling our business, so we’re reducing costs. However, if you’re in the service business (almost everyone nowadays) , support is still one of the core component of your value. If you don’t continue to have nice support, your company will lose in trust, and thus in revenue.

Here’s a great article form Signal vs Noise about why they put everyone at their company on support.

Why docxtemplater is so awesome to generate docx files

I’m creating a library on Github, which is obviously open-source. The library creates docx from a template with data, much like what you’re used to do for HTML with templating languages like Mustache, Twig (for PHP), HAML (Ruby and Node), Jade (Node). The library is called docxtemplater and is specifically for docx. Docx is a format used by Microsoft Word 2007+. The library was named docxgenjs at the beginning. But I’m opinionated and only want to generate docx from templates. So I have decided to rename the library to docxtemplater. I have also removed the JS suffix. In fact, the library is not deeply linked to javascript as there is a command line interface (CLI). The CLI makes it possible to use the library from any language.

They are two main differences between HTML and Docx. This differences make it difficult to use one of the mainstream templating languages for docx:

  1. Docx is a zipped format, so if you want a solution that works out of the box, you should at least add a way to unzip and then rezip the document. You will also have to write the logic to modify the right files.
  2. Docx is made of xml, and the text is splitted around in the document. For example writing « {tag} » in a word document often results in the following code structure in XML:


This makes it almost impossible to use a « normal » implementation of a templating language.

The library can process variables, but also loops, conditions, custom parsing of variables (with the angular syntax), and replace images.

Why narrowing to a docx templating system ?

I have a big problem with all other libraries that try to solve similar problems: They all involve that you should write all the document’s content in your application code. This seems very inefficient to me. Why the heck should I write static paragraphs inside my code base ? It has been a long time now that the whole software industry agrees that it’s better to use templates to generate HTML rather than echo out stuff in your application. However, this specific problem seems to have been developed with old standards. Yes maybe, you might want to get some super power and insert a very complex thing in your document (eg something that is not some text nor some image). But even if you want that, I created a syntax that allows you to insert some custom XML: {@tag}. If you want to insert an XML tag that is not possible to generate using normal tags, use the XML Tag. But please, avoid making the same mistakes again, eg don’t put all your static content in your codebase, that’s exactly what templates are for !

Even better, if you use templates, you will find it much easier to switch from one output type to an other, because all of the output types will share the data (but obviously not the template).

There’s still one bonus using the templates: Everyone can edit Word templates, but only a developer can change code that echoes out part of the docx. So using docxtemplater rather than an other library will let you as a developer do the data-binding, and your manager/whoever can create the docx template.

What’s wrong about the 40 hour work-week ?

While I’m still pretty young, I think I have a word to say about the way we work together as of 2014. Of course not everyone works like I’m writing in this post, and this may be a bit too opinionated because I very often have thoughts about how bad this is. I have already worked at 5 different companies as an employee, done some contract work twice and am currently one of the three co founders of an other company called beequick. beequick has one main product : a CRM specialized for Junior-entreprises. We have been working on this company totally remotely since more than a year now, and everything is working fine. I think I work between 4 and 10 hours a week for beequick.

You can’t be productive for 40 hours in a week

Yes, I truly believe that. They are mainly two problems with the 40 hour work week: The first being the interruptions: If you work at a company where people come and go to ask questions (which is usually the case), you probably rarely get 1 hour of time where you are fully concentrated. Interruptions are exactly what makes your day inproductive:

It separates your work day into work moments.

37 Signals

Yes, you hear all the time that whenever you get interrupted, you need 15 minutes to re-concentrate. I think you probably can’t even come back exactly at the same state as you were before the interruption, and if you’re able to do that, it probably requires a lot of (unnecessary) effort. The second being that companies don’t care about productivity. What they care about is how much you work.

Do you work 40 hours a week or more ? Yes ? Then fine, continue like this.  // I don’t care about your speed

A random company

Projects, blog posts, reports, take months to be done while they could be done in weeks or even days.

The way productivity happens has changed

While it might be a good idea to measure productivity with the time you put in it if you work in a factory, this is especially not true in the software companies. Programming, designing, and all of the modern jobs are not physical jobs. Everything employees do is taking decisions. Unlike physical jobs, it’s not how much time in a day you work on a problem that will output most of the good decisions. It is more about how good you know the problem, what your past experiences were, etc…  There’s also a huge factor that comes in : you need to take care of your mental health : reading a lot helps, talking with people from different horizons, eating healthy food and also doing regularly physical activity.

Employee happiness matters (more than ever ?)

40 years ago, people had to leave their hometown to find somewhere to work. Now we have all that countless stuff that permits us to collaborate despite of the distance: Trello, Basecamp, Hipchat, … we shouldn’t have to care that much about working all on the same place, on the same hours. More and more people (especially the ones that care about productivity) don’t want to be constrained by rules that make it impossible for them to have a fulfilled life, like being far from their family, from their friends or their favorite activities.

Try to hire remotely and stop to force your employees to work for a specific time.


La librairie jQuery: Principe, Utilisation et liens


Petite histoire du JavaScript

Javascript existe depuis bien longtemps, puisque en septembre 1995, le navigateur Nestcape Navigator 2.0 sort, et avec lui la première implémentation du Javascript qui porte à ce moment le joli nom de LiveScript. Ce nom a changé dans les versions suivantes.

Microsoft à l’epoque était un des grands précurseurs dans le domaine du web, et créa Internet Explorer 3.0 en 1996, qui supportait le Javascript. Cependant, le Javascript a toujours été un langage interprété différemment selon les navigateurs. Ceci a posé beaucoup de problèmes au développeurs pour qui le Javascript n’était pas un langage particulièrement mur et intéressant.

Inventer un nouveau langage pour remplacer le Javascript n’était pas concevable pour éviter de pénaliser une grande partie des utilisateurs qui ne mettent pas à jour leur navigateur fréquemment. C’est dans une optique de simplification du Javascript (et d’accessibilité pour les développeurs) que jQuery a vue le jour

Naissance de jQuery

Il faut savoir qu’il existe plusieurs langages qui ont été créés pour améliorer l’utilisation du Javascript, comme par exemple jQuery, Dojo, Backbone , Coffeescript, jQuery UI, EmberJS.

jQuery est devenu un des incontournables, puisqu’il permet de simplifier largement l’utilisation du Java-script: L’idée du créateur de jQuery est très simple: sélectionner un élément avec javascript est assez compliqué nativement:

En effet pour obtenir tous les éléments qui ont le tag html h1 par exemple, il faut utiliser le code suivant:

var h1_array = document.getElementsByTag('h1');

var h1_class_array = [];
for (var i=0, len=h1_array.length; i < len; i++) {
if (h1_array[i].className.indexOf(‘classname’) !== -1) {

En jQuery, l’operation est bien plus simple:


L’idée est d’utilisée les mêmes sélecteurs que ceux utilisés en CSS, pour ne pas avoir à apprendre un nouveau langage de sélecteur. C’est pourquoi jQuery a eu un tel succès:

Voici des graphiques montrant la répartition des sites qui utilisent jQuery:
Statistiques jQuery

Les gros sites (classés dans les top 10k) utilisent en majorité jQuery, les sites de plus grande ampleur ayant souvent peur de dépendre d’autres librairies, ou ont créés leur propre librairie. Cependant, jQuery reste un incontournable en terme de développement web, et je pense qu’il faut au moins réfléchir à cette possibilité lors de la création d’un site internet.


Dans cette partie, je vais vous montrer quelques exemples de code permettant de faire certaines opérations rapidemment: 

Changer la couleur d’un élément


Ajouter un élément à une liste

  • Banane
  • Pêche
  • Framboise

On utilise le sélecteur ul.ex2 qui signifie de choisir les éléments ul qui ont la classe ex2

Effectuer une action pour chaque élément

Exécuter$("div.ex3 input").each(function(){$("div.ex3").append("<b>"+$(this).val()+"</b><br>")});

Utiliser jQuery

Pour utiliser jQuery, c’est très facile, il suffit d’utiliser une simple balise script dans le code HTML de sa page. Une bonne pratique est de la placer juste avant la balise <body> pour éviter les temps de latence du à l’attente du chargement du javascript.

Il est possible d’utiliser une version de jQuery hostée par google. Cela offre les avantages suivants:

  • pas de téléchargement de la librairie pour chaque site qui utilise la librairie, puisque les utilisateurs auront très souvent cette librairie dans le cache de leur navigateur
  • pas de bande passante utilisée supplémentaire pour la librairie

<script src="//"></script>

Site du Javascript ninja


Je m’appelle Edgar HIPP, créateur du site Mon but est de montrer l’importance de l’ergonomie dans les sites internet, ainsi que de la bonne utilisation des langages de type client (c’est à dire qui s’exécutent sur le navigateur de chaque ordinateur). Je parlerai donc d’utilisabilité des sites internet en général, mais également des technologies intéressantes qui existent dans tout ce qui concerne le développement front-end des applications web.