I met today with a young entrepreneur, you might know his kind of company. They have a niche in a local market, a sweet business model, they are four and their business is running great, they are really good at SEO and know how to strike a partnership deal.

The site is good looking. And it does what it is supposed to do.

They built everything in-house, in PHP/MySQL and they don't really have big performance issues (500ms average response time of their scripts which they find acceptable). They know they are not supposed to do sys admin and have a hosting company that takes care of their machines. The guy writing the code is not that bad either. He doesn't really do OOP programming nor does he really know what is the practical use of the MVC pattern. But he does separate logic from design using his own templating solution, there is not a lot inline css, and the majority of the javascript code is not inline either.

So these guys are really not in that much of trouble, I can surely say I have seen much much worse.

The code to be vs. The code that is

So what do I mean when I say their code is Liability not an Asset? It means that more or less all project code is. Before you are running a live system the "code to be" represents what you need to do in order for your business to run, and make money.

Afterwards the same code, "the code that is" mostly represents the added cost to implement new features. The more code you have, the costlier it will be to add anything new. And the real bad news is that everything you add will just pile up on top of the "code that is" making every subsequent addition even costlier. Now the negative marginal utility of the existing code is not a fixed quantity : the better structured you code is, the more unit tests you have, the more cool schema-less or loose schema databases you use, the less new code is costly. This is true of course for small changes (just change the graphic design of the site), but when it goes down to structural issues (getting your site multilingual, adding user roles, changing workflows) the difference can be tremendous. And some times it means that the moment the company succeeds in its local niche -- and wants to go bigger, go international -- or resist the big players coming to the niche market it simply can't. Even if it can now raise the money to have enough development power, it will take too long. Becoming from an innovative first player, the late to market guys can be a real hard wake up call.

Now, these companies: brave, self-financed and successful can probably not exist by doing "stuff right" from the beginning. There is an initial investment in development quality that would probably not have been able to afford. You don't have that many professional developers running around looking for biz-dev guys with an idea, willing to work for a year and a half without salary, and being able to explain to their partner: hey let's not implement anything new this week, let's write some more tests, let's just refactor that old code (from 4 weeks ago). In order to hire an external professional team well you need to have the seed money, and not everybody has access to that.

Is doom a fatality?

But doom is not a fatality, there is a tipping point. There is a specific moment in time, when the company is already successful enough a time where there is still time to refactor, not that much code has been written. Although it took a year to write it a bunch of professionals can probably redo the whole thing in a month this time with the scalability, the internationalization, the security built-in and maybe the most important, the ability to add new stuff without breaking the old one, to tweak the system without being afraid it will make the whole thing collapse.

So if you are the business guy, how can you prepare yourself well to throwing away everything and still staying in business? What can you do to make sure you will not fail by succeeding? Here is a preflight checklist you should verify with your tech guy, before you write a single line of code. If you don't know you are going to be writing marvelous code. You should try to find out how to write as less code as possible and how to make it as disposable as possible.

Best practices for people who can't follow best practices

First three:

• You are using existing open source code that enforces as many good practices as possible such as Ruby On Rails, Django or Drupal and you know the implications of the licensing model on you business model
• Your coder is a respected open source contributor, he has a bunch of projects up on github or bitbucket and many people fork his stuff
• On some of the comments you see on these platform people tend to be respectful for the number and the quality of tests he has written and praise his documentation

At this point there is a very good chance you can stop reading this. Things will be cool. Trust the tech guy. Just really make sure you have some kind of back up for your data, and if you see the tech guy drinking too much whisky before noon, also make sure you have access to backups of the code as well as the data, maybe on a physical support only you have access to.

You should still talk to the guy and make sure:

• You are paying him enough money and he won't quit on you too soon

You could also verify together:

• You are using standards, and don't invent anything but your core value
• You respect as much as possible the spirit of the framework you use
• You have discussed together the ambitions in terms of scalability, and he is thinking about that

The big checklist (not that big)

Normally the framework you have chosen will take care of most of the following. But if you can't use one (because you tech guy is too young/too old, he is not a respected open source contributor, he doesn't like frameworks for X/Y reason, he says doesn't have time for, etc.), you still must check the following list:

• The source code of the application is on an SCM (source code management system)
• You know where the SCM is. You know it is backed up. You have learnt how to get your own copy of the code or some third party you trust has
• No development is done directly on a server
• There are at least two environments: test and production. But really, there are four environments: the local environment of the developer(s), an unstable integration machine representing the current status of the code, a testing machine -- representing the next version to be put to production -- and the production environment.
• You have a procedure in place to use the SCM to move code from development to production
• If you need to put more then just code changes to production (modify database structure, dependencies on libraries/executables) you have a procedure to make these modifications
• If you have interesting data on the server (anything that if lost might pose any kind of problem), it is backed-up
• You have a way to verify that your backups work

Talk with the tech guy if you left any of the checkboxes unchecked. Stop, there is no point in reading this post any further. Talk with the tech guy again. Make sure all are checked, that you have a way to verify this. Make sure the procedures are written.

Next verify the following:

• You know what your application is supposed to do, and you know how this can be tested
• This is written in a simple text format or nice images, but both you and the developer can understand these documents

Now go on the following checklist with your developer(s):

• The application has a single point of entry
• Design is separate from application code
• The application code does not talk directly to a database but uses some kind of abstraction
• There is a single source for text strings, with every call to static text running through a translation layer
• You have a caching infrastructure in place
• You use something else than MySQL queries for full-text search

To earn some extra points try and check the following:

• You only develop the features that you can make money out of and do the simplest thing that might possibly work
• You don't develop code you are not going to immediately use
• You understand what "Horizontal Scalability" means
• You don't have anything in the architecture that prevents that

Every time you add a feature, every single time, go through the checklist. If you could not tick a checkbox, don't develop the feature.

On the next blog post in the series I will get into some more details on each element of the checklist, to be clear on how you verify this. The last chapter will address what happens when you've already started coding, and this article has put the fear of god into you.

• Ori Pekelman's blog

• http://vimcasts.org/ : ce site met diffuse des screencasts sur vim. Chaque semaine, un nouveau screencast de 5 à 10 minutes est publié, mettant en avant une fonctionnalité particulière de Vim.

• http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/ : cet article d'Ilya Grigorik discute de la pertinence des bases de données NoSQL. En particulier, il souherait voir émerger un moteur Schema-free pour MySQL. Les discussions qui ont suivies cet article sont également intéressantes.

• http://www.opscode.com/blog/2010/02/28/chef-0-8-2-release/ : Chef est un outil d'automatisation pour son infrastructure. La sortie de la version 0.8.2 est la première de la nouvelle branche, et apporte des nouvelles fonctionnalités majeures comme une API REST complète, un outil en ligne de commande, knife, totalement opérationnel, ou encore un mécanisme d'authentification plus robuste.

• http://code.google.com/p/html5media/ : cette initiative vise à offrir la balise HTML5 <video> pour tout le monde. Tous les navigateurs web ne supportent pas cette balise, et pour ceux qui la supportent, les codecs ne sont pas toujours les mêmes. Ce projet permet aux développeurs web d'utiliser la balise <video> sans avoir à se soucier de ces problèmes.

• http://rickosborne.org/blog/index.php/2010/02/09/infographic-migrating-f... : ce document est une représentation graphique d'une transformation d'une requête SQL en requête MongoDB équivalente. Elle illustre une méthode permettant de convertir systématiquement des requêtes SQL relativement complexe en requête de type Map-Reduce pour MongoDB.

• http://groups.fsf.org/wiki/Group:GNU_Social : des personnes proches du mouvement GNU ont décidé de monter leur propre réseau social décentralisé. Celui-ci vise à offrir un équivalent distribué à facebook dans un premier temps. Il devrait également permettre un meilleur contrôle des données et de sa vie privée par la suite. Tout le code est diffusé sous licence AGPLv3.

• http://bsonspec.org/ : le BSON, ou Binary JSON, est un protocole de sérialisation dans le style de JSON. Il est notamment utilisé par MongoDB, et présente des avantages intéressants si on le compare à Protocol Buffers : légèreté, traversabilité et efficacité.

• http://www.cdncatalog.com/ : ce catalogue de CDN pour les bibliothèques javascripts et CSS est une ressource utile. Utiliser pour ces bibliothèques est très pertinent, car il permet aux utilisateurs d'avoir ces versions dans le cache de leurs navigateurs, ce qui accélère le temps de chargement des pages de manière non-négligeable.

• Le blog de Bruno Michel

Je lis régulièrement des livres, et j'ai envie de partager mon avis sur certains d'entre eux. Je vais donc me lancer dans un exercice assez nouveau pour moi : la critique de livres.

Pour commencer, j'ai choisi le livre Web Design For Developers. C'est un livre publié par The Pragmatic Bookshelf qui s'adresse aux développeurs qui souhaitent s'initier au design de sites web. Ça tombe bien, c'est mon cas.

Ce livre explique comment construire le design d'un site web pas-à-pas. On commence par agréger les demandes et faire une esquisse sur papier qui répond à ces demandes. Puis, viennent le choix d'une palette de couleurs et des polices que l'on va utiliser pour le site. On part ensuite dans la partie graphique : création d'un logo et d'une maquette sous photoshop. On attaque alors le coeur du sujet, l'intégration HTML/CSS, avec bien sûr, un chapitre complet dédié au cas particulier d'Internet Explorer 6. Pour finir, on a le droit à des chapitres pour élargir notre horizon : un chapitre sur l'accessibilité (bien que ce sujet soit également abordé tout au long du livre), un autre sur l'optimisation d'un site pour les mobiles, etc.

Globalement, ce livre aborde de nombreux sujets sans demander de connaissance a priori des lecteurs. Il est donc très facile de prendre ce livre et de suivre chaque étape de la construction du site web d'exemple. On y trouve un grand nombre de conseils faciles à appliquer, et généralement très pertinents.

Pourtant, Web Design For Developers me laisse une impression mitigée. J'ai vraiment appréciés certains chapitres, mais d'autres m'ont laissé sur ma faim. Le chapitre sur le SEO m'a même semblé à coté de la plaque (la moitié du chapitre parle de la balise meta keywords, alors que celle-ci est ignorée par de nombreux moteurs de recherche). Je regrette également que le site d'exemple ait au final un design assez décevant.

Au final, je pense que ce livre est une bonne introduction au design web, mais qu'il ne faut pas attendre de miracles. Il vous fera découvrir les problématiques, mais ce sera à vous de creuser chacun de ces sujets si vous voulez vraiment créer un design vraiment réussi.

• Le blog de Bruno Michel
• 1 attachment

Javascript avancé

Vision Media a publié un ebook sur le javascript avancé. Il ne coûte que 4$ canadien (moins de 3€), mais j'ai appris pas mal de choses avec sur le langage javascript lui-même (pas le DOM). Ses 64 pages sont découpées en 6 chapitres :

• Closures, Scope & Context
• Prototypal Inheritance
• Advanced Meta-programming Techniques
• Behavior Driven Development with JSpec
• Creating a jQuery Clone
• Tools of the Trade

Si vous souhaitez mieux comprendre le javascript, pour l'utiliser avec Node.js par exemple, ça serait vraiment dommage de passer à coté.

http://www.dev-mag.com/2010/02/18/advanced-javascript/

Rails 3 Upgrade Handbook

Jeremy McAnally a écrit un ebook de 120 pages avec tout ce qu'il faut pour passer une application à Rails 3 (actuellement en beta). La plupart des informations sont disponibles ailleurs, sur le site officiel ou des blogs, mais il est très difficile d'avoir une vue synthétique de l'ensemble des modifications. Le prix de cet ebook, 12$, se justifie très simplement par le temps gagné. Vous aurez toutes les informations sous les yeux pour faire votre migration, et la liste des points à ne pas oublier est vraiment très pratique. Pour ma part, je ne regrette absolument pas cet achat.

http://www.railsupgradehandbook.com/

Contribuer en retour à l'Open Source

Ryan Bates a lancé une initiative qui va être, je l'espère, suivie par de nombreux développeurs. L'idée est simple : on utilise régulièrement des Logiciels Libres, notamment des plugins ou gems pour Ruby on Rails, et il est souhaitable de participer à cet effort. Pour cela, Ryan Bates propose une méthode :

1. Trouver votre projet Rails le plus important
2. Lister tous les plugins et gems que vous utilisez sur ce projet
3. Pour chacun, faites une contribution avec, au choix :
   • Donner de l'argent
   • Corriger un bug
   • Ajouter de la documentation
   • Ou, tout simplement, remercier son auteur

Je compte sur vous pour faire la différence en faveur de ses plugins et gems Libres.

http://railscasts.com/give_back

• Le blog de Bruno Michel
• 1 attachment

Some times ago, I was trying to re-synchronize subtitles and video whithin VLC player, the typical : "150 ms after ... erf, 50 ms before, that's it ! no ... it's still desynchronized ...".

After giving up, and by curiosity, I opened the file, and found that the SubRip format is, in fact, quite simple. Just for trying, I read and displayed them in a browser. This is the way SubRipReader was born, using Mootools 1.2.

Unfortunately, it won't resolve my initial problem. But it's still able to load the subtitles through an Ajax request, to parse them, and to display them step by step, into a DOM element.

It supports :

• play / pause states
• overlapping subtitle levels : when several lines of texts should be displayed at the same time, each one took a different css class :
  

  1. 2

  2. 00:00:15,000 --> 00:00:25,000

  3. A text

  5. 3

  6. 00:00:20,850 --> 00:00:30,000

  7. An other text

  For instance, the previous subtitles lines will be injected in DOM and could be displayed like that, depending of your custom styles :

  1. <div class="overlapping0"><p>A text</p></div>

  2. <div class="overlapping1"><p>An other text</p></div>

  

For playing subtitles, use Srt.Parser and Srt.Reader :

Then, you should be able to call the start and pause actions :

I've just seen about the Universal Subtitle Format, it's going to be the time to implement its own parser !

• Clément Hallet's blog

Et voilà sur le même thème un petit billet en français pour les non anglophones.

Nous avons libéré sur github une petite classe qui installe un gestionnaire de session personnalisé. Sa particularité est de stocker les données de session dans un cookie chiffré.

L'intérêt est que nous n'avons plus besoin de partager les sessions entre serveurs si nous avons plusieurs frontaux.

Le chiffrement permet d'éviter toute modification par l'utilisateur du contenu du cookie. Le chiffrement par défaut utilise la paquet pear Crypt_Blowfish.

Son utilisation est très simple, on utilise toujours les fonctions habituelles de gestion de session (session_start(), session_destroy(), etc.). La seule exigence est de fermer la session en écriture juste avant la sortie HTML/whatever.

Vous pouvez retrouver le code sur le dépot session-cookie. L'utilisation est décrite dans le README.

• Le blog de François De Metz
• 1 attachment

Fin 2008, les développeurs de Merb et Rails ont annoncé qu'ils allaient joindre leurs efforts pour sortir un Rails 3 qui combinerait les avantages de Rails et ceux de Merb. Depuis, nous avons porté beaucoup d'espoirs qui s'annonce très prometteuse, mais qui est également une source de frustration que cette version ne soit pas déjà disponible. Enfin, la semaine dernière, Rails 3 est officiellement sorti en beta (avec les release notes détaillées).

Pour le moment, Rails 3 reste encore le domaine des développeurs aventureux, ceux qui n'ont pas peur de rencontrer des bugs. Par exemple, de nombreux plugins ne sont pas encore compatibles avec Rails 3 (railsplugins.org est une bonne source pour connaître la liste de ceux qui le sont).

Si vous faites parti de cette catégorie, alors deux choix s'offrent à vous. Vous pouvez commencer une nouvelle application avec Rails 3. Le 200ème railscast est un très point de départ pour ça. L'autre choix, plus ambitieux, est de porter une application Rails existante vers Rails 3. Je vous conseille alors de vous faire aider par le plugin rails_upgrade en vous laissant guider par les explications du peepcode Rails 3 Upgrade.

Dans tous les cas, il est intéressant de commencer à se plonger dans les nouveautés de Rails 3. Les articles sur le sujet sont dispersés sur de nombreux blogs, mais des listes permettent de s'y retrouver. Celle de Ruby Inside me semble être la plus complète pour le moment.

Je vous encourage également à participer à l'initiative Give Back to Open Source. C'est très simple : prenez votre plus gros projet Rails, regardez les gems et plugins que vous utilisez, et pour chacun d'eux, contribuez en retour : donnez de l'argent, corrigez un bug, écrivez de la documentation, ou simplement, remerciez son auteur. L'important est de donner en retour.

Mise-à-jour : le Rails 3 Upgrade Handbook est un guide PDF qui vous guide dans votre migration vers Rails 3. Il coûte 12$, mais il les vaut. Vous y trouverez toutes les informations utiles, y compris certaines qui sont très difficiles à trouver ailleurs.

• Le blog de Bruno Michel
• 1 attachment