“Working software over comprehensive documentation”

Manifesto for Agile Software Development

Most of us already know about unobtrusive JavaScript and how good it is. Maybe also about event delegation and how many listeners you are sparing with that little technique (thanks to jQuery’s closest). I’ll be a bit more generalist here and talking about writing code that enable you to test them with unit tests (using QUnit, YUI, …).

Before you think about it, yes Test Driven Development or Behavioural Driven Development (which are very close if you do the first one right) will force to you do so. If you know those, go with them but the following pitfalls might still be interesting.

Don’t use the module pattern when you really mean class.

var Foo = {
 init: function(state) {
  this.state = state;
 }
}

Foo.init(42);

How many instances of Foo can you have on your page once initialized ? The answer is one as this represent a kind of singleton. It also means that you won’t be able to test as many instances as you want representing tons of different cases. Stick with the good ol’ way.

function Foo(state) {
 this.state = state;
}

new Foo(42);

Stay away from id’s as well for the same reason and try to use classes instead. It means no document.getElementById within Foo’s constructor.

Separate the content from the logic, you JavaScript module/class should be about the logic only. Strings, translations, configuration, ... should be kept outside. Giving a JSON structure as only parameter of a constructor is common and readable.

new Foo({
 class: "foo",
 quantity: 42
});

jQuery’s extend (YUI’s ..., Prototype ...) offer a good way to mix good default values with configuration.

Next one is loose coupling. Being sure that a module what work as well alone or when it has to interact with many other ones is key when building big and complexe systems.

The involved technique is to rely on an event mechanism. On a very safe web environment (like Opera widgets, Pre application, Apple dashboard, …), DOM3 events can be used. You only have be tied to a DOM node to fire them. YUI implements an easy to use Observer pattern (called CustomEvent in YUI2), jQuery offers something similar which integrates with how it manages DOM events (Prototype as well).

// b will send data to a
var a = new A();
var b = new B(a);

// or
var a = new A();
var b = new B();
a.onChange(b.onChanged, b);

Those are very similar, thus it seems easier to adapt, test or reuse. Isn’t it?terminal

And last but not least, don’t put your init in the libraries/modules/… Anything that involves onload, DOMContentReady, … is tied to a particular usage already and shouldn’t live into a library or module imho.

function A(element) {
 // whatever
}

$(document).ready(function() {
	new A($("#a")[0]);
});

It means that those two blocks of code should live separately. At last in your developement environment. Then, you’re totally free to join, compress and maybe obfuscate them as you won’t test or develop against that version.

And it’s more a personal taste issue here. I don’t like stuff that are automagically loaded because of a particular class name or id.

If you see more of them, feel free to contribute.

Si le must reste de pratiquer le développement piloté par les tests (TDD) ou « comportemental » (Behavioural), il me semble judicieux de pointer différents points qui vont être des freins à la mise en place de tests. En somme des mauvaises pratiques où la justification est qu’elles rendent problématique la mise en place d’une assurance qualité.

• Mon préféré est le module pattern, qui cache un singleton, donc état global ce qui implique des difficultés à une éventuelle réutilisation.
• Mélanger l’instanciation et la définition. Il est plus aisé d’effectuer des tests sur une portion ne faisant rien par défaut, ne s’initialisant magiquement dès qu’elle le peu. Séparer la définition de l’usage est important.
• Fournir de bons défauts mais offrir des possibilités de modification. Un but premier est la réutilisabilité et, chose souvent ignorée, l’interopérabilité entre différents modules, bibliothèques. Et dans une certaine mesure le fait qu’il faille peut-être offrir une version dans la langue de l’utilisateur.
• Pas d’id en dur, uniquement des classes. Pour la simple et bonne raison qu’une id est unique et sera toujours indépendante de votre module/bibliothèque.
• Couplage faible entre modules, voire aucun couplage. Si deux éléments doivent communiquer pensez à leur offrir un canal approprié et ne leur donnez pas la possibilité de le faire directement. Il existe pléthore de solutions via DOM3 ou la bibliothèque de votre choix.
• Et peut-être le plus évident, écrivez des tests. Car la réalité vaudra tous les discours du monde.

Il n’est jamais simple de franchir le pas, de s’y mettre, d’oser les tests. C’est un investissement valable. N’hésitez pas à agrémenter la liste ci-dessus de vos expériences personnelles.

Let’s redo this, keeping in mind that PHP is already a templating language.

<!DOCTYPE html>
<html lang=<?php echo $lang ?>>
<?php echo $html ?>
</html>

This is valid PHP, and can be seen as a template with two parameters: the language ($lang) and some html content ($html).

<?php
$lang = "en";
$html = "<h1>Hello World!</h1>";
// the file above
include("hello.php");

That was too easy. But it’s not very clean, imho because you cannot do anything with the result. Let’s do this a little bit better.

<?php
function template($template, $args) {
 extract($args);
 ob_start();
 include($template);
 $result = ob_get_contents();
 ob_end_clean();
 return $result;
}

echo template("hello.php",
              array("lang" => "en",
                    "html" => "<h1>Hello, World!</h1>"));

This way, you don’t pollute the global scope with variables and are able to reuse templates. It’s still very, very basic but will enable you to understand the final class Template that is used by bluespirit.ch. I’ll show you how it works but let you dive into the PHP code to understand it.

<?php
// templates is a directory
$tpl = new Template("templates");

echo $tpl->index(array("title" => "Hello",
                       "links" => array(1,2,3));

Now the templates, let’s start with the index (the function call above is in fact using __call).

<?php
$this->inherits("layout");
$this->block("head")
?>
<title><?php echo $title ?></title>
<?php
$this->endblock();
$this->block("body")
?>
<h1><?php echo $title ?></h1>
<ul>
<?php
foreach($links as $link):
?>
<li><?php echo $this->link(array("link" => $link)) ?></li>
<?php
endforeach
?>
</ul>
<?php
$this->endblock();

The layout, from which this template inherits.

<!DOCTYPE html>
<html lang=en>
<head>
<meta charset=utf-8>
<?php $this->block("head") ?>
<title>Untitled Document</title>
<?php $this->endblock() ?>
</head>
<body>
<?php
$this->block("body");
$this->endblock()
?>
</body>
</html>

and link, of course.

<?php
echo $link

Which could have been more complex.

That’s the very basics, the final one includes more features like some block control meaning you can no only override a block but also append or prepend some content which is very useful for the usual end of the page scripts. Another one that I like very much is some cache (using APC (or apc_alt) enabling avoiding regenerating a piece of layout everytime.

Having this kind of cache also means that you might ending up doing bad things in the templates (views) like SQL requests. This is for example used on the homepage of bluespirit.ch where the news are coming from a RSS feed parsed by Yahoo! Pipes. It doesn’t cURL it all the time.

All this in on GitHub, get it, fork it, fix it. And I’ve got one question for the PHP masters in the room, how do you do monkeypatching in PHP? (I know how much evil it is, but I promise that I won’t break anything)

Un des premiers outils que nous avions réalisés avec Batiste dans le cadre de nos débuts dosimplesques (pardonnez ce néologisme) a été un système de template. Nous en avons fait quelques-uns même. Tous reposent sur une syntaxe proche d’HTML, donc à base de commentaires remplacés à l’exécution.

C’était sans bien réaliser que PHP est déjà un langage de templating, intrinséquement. Pourquoi serait-il indispensable de mettre ce <?php sinon ? Ceci étant dit, voici un système de templates reposant sur ce fait-là et offrant quelques fonctionnalités sympathiques, telles que : l’héritage, les blocs, l’inclusion d’autres templates, le cache et même l’envoi de headers HTTP pour les plus bidouilleurs d’entre vous.

Le code ainsi que des exemples se trouvent sur GitHub, amusez-vous y.

So in 2009, I left Oslo and the web application team of Opera Software because I wasn’t happy. Not being able to fully enjoy the Friday beer might be a cause or not.

Back in Switzerland I was able to take some time with my former girlfriend, visiting her and some friends of her in Germany. I still wanted to work on some projects but I realize now that it was stupid to not being able to do one thing at the time and appreciate it.

In June, I joined eboutic.ch as a Rails developer. Those guys weren’t afraid to pick someone who never done anything serious with Ruby on Rails before. Hopefully Raphaël was there to guide me and show me the way when I was being to pythonic or, even worse, phpish. In the six month I spent there, we actually manage to do some big stuff and that is really a good achievement for the company itself. Migrating to a very fresh version of Rails, revamping all the HTML during the redesign, auto-magically generating the daily mailing (that were done by hand before that, every single day) and many more.

Excuse me if I offend you, but the more I work with different technologies the more I realize that the differences between them is basically the syntax of the language itself. As Paul Graham would have said, Ruby is an acceptable Lisp. I’m back at hacking in PHP since a couple of weeks, and it’s, sometimes, quite painful.

During that time, I lived in a couple of flats, looking for a room or waiting for September to know what would have happened on her side. All the flat I lived in or visited sucked. My job was getting on my nerves and I had the feeling to be stuck in a dead-end. So, I blew everything up. Locality, job, girlfriend, ... It’s time to take the time of doing things like I feel them, or to feel them.

Thanks to Paris Web, and the people I met there who told me what I already knew but could see myself. I’ve been travelling between city, jumping from jobs to jobs for more than 3 years now. This is what I like doing: being a pain in the arse, getting stuff done on time, putting some quality, learning stuffs and travelling (it doesn’t have to be far).

So since this month, I’m a (no-yet-too-expensive-)freelancer, I’ve got a flat in Neuchâtel (which is a complete heresy for almost all my friends, the one who didn’t already reject me). I’m looking forward to enjoying this city even more.

As a side thing, thanks to the professor who supervized my diploma (in 2006) I had the opportunity to give a 2 hours JavaScript crash course including an introduction about the awesomeness of getting a new job every six months. And to act as an expert for diploma. It’s good but very hard to go back into the school reality. I knew the gap was huge but felt in it nonetheless.

Enough with last year, let’s look at the bright future. More weddings and children to come. Not mine, but it makes me feeling how good it was to be innocent. Innocent doesn’t mean nice at least not applied to myself.

On the work side, the challenge will be to find a (correct) balance between working and doing anything else that doesn’t involve any kind of computer. Pure utopy, but it’s good to start trying at some point. Another one will be having enough work.

And last but not least, my mother is leaving Switzerland for starting over in Corsica. I’ll have to take care of some of her furnitures but most important the cats for a couple of month. Two devils worse that kinds because it’s totally hopeless to believe in educating a cat.

Feel free to drop me an e-mail if you have some mice for the cats, some freetime or a need for a couch. I’ll be pleased to help.

Et voilà une année qui se clôt, et un énième blog post pour raconter sa vie et se congratuler. Puisque ça fait un peu plus de 10 ans que je joue avec le web, et que je n’ai pris le temps de faire ce type d’écrit là l’an dernier. Le voici avec un petit aperçu de l’année à venir.

Il y a un an, je me gavais la panse dans un hôtel pour backpacker à Interlaken, puis la suite est moins joyeuse. Sinon, j’étais alors employé par Opera Software, basé à Oslo, depuis deux mois et pour deux mois encore (environ). Bref, ceci a conduit à ce que j’en sorte d’une certaine manière.

Pour retourner au pays des modzons, tenter des idées personnelles, retrouver un peu celle que j’y avais laissé. Même si elle s’en était déjà retourné dans son Allemagne natale, à 9h de train de là. Quelques semaines, donc une au Nord de Hambourg m’ont permis de changer d’air. Même si j’aurais pu/dû débrancher un peu plus. C’est dur de lâcher du lest quand le futur est indécis.

Et j’ai rejoins eboutic.ch pour y faire du Rails en n’en ayant jamais fait. Un retour sous Mac OS de bonne augure. Au niveau développement j’y ai eu beaucoup de plaisir. Un mélange de challenge, de nouveauté et de responsabilité. Quelques jolis chantiers y ont été abattu.

Puis une envie de tout envoyer balader, une nécessité. Ville, copine, job pour être un peu plus honnête envers moi-même et les autres ce qui je suis et ce que j’aime faire. Je suis vraiment quelqu’un à double tranchant demandant autant qu’il donne. Et je chéris ses petits moments ou ça chauffe un peu, malgré tout.

Les rencontres faites à Paris Web m’ont décidément conforté dans l’envie de me lancer en solitaire. D’offrir mes services çà et là. Au fond, c’est tout de même plus honnête que de changer de job tous les 6 mois. L’excitation de la nouveauté plus être dans un élément fixé dans le temps font que je m’y plais déjà. Premier mandat devant voir le jour ce soir à minuit.

En parallèle, j’ai donné un petit cours à la HE-ARC de St-Imier plus suis un diplômant en tant qu’expert (une vraie plaie d’expert que je fais). Le fossé entre l’école et l’industrie derrière est grand. Du moins dans le domaine qui m’affectionne. Difficile d’avoir une approche adaptée si tant est que j’en soie capable.

Et voilà, 2010 démarre. J’ai élu domicile en ville de Neuchâtel (à deux pas de la gare). Pour ceux qui ne connaissent pas l’éternelle gué-guerre que jouent le Haut et le Bas du canton de Neuchâtel, c’est un affront énorme que j’ai commis.

Quelques projets sur le feu, des billets pour Lift10, pour (potentiellement) une semaine à ski avec des enfants de 5ème primaire et la niak des débuts. Je pars confiant et ça fait du bien. Il me faut réellement trouver une hygiène entre boulot et le reste (ne nécessitant aucun outil informatisé). Même si c’est en prenant le large de temps à autre, histoire de faire un coupure.

Donc voilà, si vous passez par là ou pensez passer par là, y’a de la place, n’hésitez pas.

Before we start, you can find the code bellow on GitHub.

First the setup.py file that describe our application:

from setuptools import setup, find_packages

setup(name="app",
      version="0.1",
      description="example application",
      long_description="",
      keywords="",
      author="Yoan Blanc",
      author_email="yoan.at.dosimple.ch",
      url="http://yoan.dosimple.ch/blog/",
      license=’All rights reserved’,
      packages=find_packages(),
      zip_safe=False,
      install_requires=[],
      entry_points={"paste.app_factory": ["main=app:make_app"]},
     )

It’s all standard except the entry point called paste.app_factory that will be used by Paste to create the WSGI application. For the Djangoist here, Paster acts like your manage.py.

Make the WSGI application itself, into app/__init__.py:

def application(environ, start_response):
 start_response("200 OK",
                [("Content-Type", "text/html")])
 return ["<h1>Hello World!</h1>"]

And the factory (called make_app inside setup.py) is required as well in the same file.

def make_app(global_conf, **app_conf):
    return application

Now, you might be wondering how this make_app is called. Paste works with ini files that decribe your configuration, from the app your using to the database, the server, logs, and so on. It’s very handy to replicate the same kind of environment you find when working with Ruby on Rails by having different ini files for each.

So there is the app.ini:

[app:main]
use = egg:app

[server:main]
use = egg:Spawning
host = 127.0.0.1
port = 8000
num_processes = 1
threadpool_workers = 1

The first section describes the application to use. It’s the egg that setuptools will create and install. That’s right, your application is exactily like any other python package. It means dependencies resolution, updates,… And the second part describe which server paster will have to use to run it. Spawning is a very efficient server that handles graceful code reloading. Pure happiness.

Before you can run it using :

$ paster serve app.ini

You’ll have to install it.

# python setup.py develop

develop means it symlinks the package to your directory and you won’t have to reinstall it later to take into account the changes made.

It should run just perfectly. Now let’s worry about deploying it somewhere else. Local web applications are nice but sharing them is cool too.

This is the fabfile.py, Fabric is more or less like Capistrano (Ruby):

from __future__ import with_statement
from fabric.api import env, run, put, local, cd

env.hosts = ["localhost"]
env.path = "~/www/app"

def build_egg():
    local("python setup.py bdist_egg")

def cleanup():
    local("rm -rf build")
    local("rm -rf dist")

def start():
    with cd(env.path):
        run("PYTHONPATH=app.egg paster serve app.ini"
            "--daemon --pid-file=app.pid")

def stop():
    with cd(env.path):
        run("paster serve --stop-daemon "
            "--pid-file=app.pid")

def deploy():
    build_egg()
    put("app.ini", env.path)
    put("dist/*.egg", env.path+"/app.egg")
    cleanup()

A pythonic Makefile, more or less that has special power to deal with deployment. This how you can use it.

$ fab deploy
$ fab start

It created a .egg, uploaded it to the destination and started the Spawning server using Paster. It will run on the port 8080, to see it on the port 80 I’d use something like Nginx as a proxy. But it’s a different story (and very simple by the way).

After you made some changes simple run:

$ fab deploy

to see them live.

$ fab stop

Will stop the server.

How awesome is that?

There is a lot more that can be done regarding how you’re playing with the eggs. Using virtualenv to keep multiple, sane environments and maybe your own cheeseshop where all your eggs can live (see Ask’s Chishop)

I’m very fresh on that field but am very happy seeing that such good tools exist. Please share your experience, I’m looking forward knowing what kind of process is used in the real word out there to.

La force de PHP est et a été sa facilité de déploiement, on dépose un fichier et c’est parti mon kiki. Merci Apache + mod_php. Scénario pas toujours aussi simple dans les autres environnements d’applications web (si je mets de côté tout ce qui est CGI bien évidemment). Pour avoir bossé dans un environnement Ruby on Rails ces six derniers mois, un serveur fonctionnant sous Passenger est assez simple par rapport à ça. Recherchant toujours comment mettre ceci en place dans le monde Python, voici une approche assez minimaliste (certainement trop) pour déployer une application WSGI sous forme de paquet Python via Paster, Spawning et Fabric.

Ne voulant polluer cet espace-là, merci de regarder les exemples de code dans la zone anglophone. Ils sont également disponible sur GitHub.

Si Ruby a les gems, Python a les eggs (bien que certains Python soient ovovivipares) centralisés sur PyPI. Les avantages que je vois à créer un paquet pour son application est tout ce qui vient avec setuptools (et ses alternatives), c’est-à-dire : gestion des dépendances, exclusion des tests (et de leurs dépendances), versions, et certainement séparation en de multiple paquets.

Une fois le fichier setup.py créé, il va s’agir d’écrire un application web Python, ici WSGI mais il y a pas que ça et ça devrait couvrir 98% des besoins.

Ian Bicking a mis au point un système d’outils plus ou moins lié à WSGI nommé Paste qui permet de configurer et lancer une application web via des fichier de configuration INI (quand on est cool on fait du YAML parait-il). Paste requiert qu’on lui fournisse une méthode retournant une application WSGI, cette méthode dite fabrique, reçoit tous les éléments de configuration du fichier .ini. Chose très pratique afin d’avoir divers environnements tel que Ruby on Rails le pratique, comme : développement, test, production. Libre à chacun de faire comme il l’entend.

Le fichier .ini en question définit le paquet Python de nombre application et le serveur web à utiliser, ici Spawning qui a la force de se recharger automatiquement en cas de modification de fichiers détectée.

Travaillant avec un paquet, il est nécessaire de l’installer avant de pouvoir s’en servir. L’installation avec develop crée un lien symbolique où les modifications seront prises en compte sans devoir réinstaller.

Vous devriez pouvoir visualer ce hello world sur le port 8080 de votre machine.

Dernière étape, la plus intéressante peut-être, déployer votre application sur une machine distante, même si distante signifie localhost c’est pour l’exercice.

Si Ruby a Capistrano (et d’autres), Python lui a Fabric qui peut être vu comme un makefile pythonique avec des super pouvoirs lié à SSH.

Le fichier donné ici permet de créer le fichier .egg, de l’envoyer sur l’autre machine (votre serveur) via deploy, puis de le démarrer avec start. Tous les autres deploy’s ne demanderont pas de redémarrage puisque Spawning s’occupe de ça directement. Une fois que vous en avez terminé, un simple stop l’arrêtera. Je trouve judicieux de lancer les applications en tant que simple utilisateur sur un port comme 8080. Il est quand même de bon ton d’avoir un véritable serveur web tel que Apache, Lighty ou Nginx servant de proxy vers votre application et s’occupant de tous les fichiers statiques par la même.

In fine, la solution de l’egg exécuté tel quel est un peu brutale. Je vous invite à vous pencher vers virtualenv et Chishop. Et recherchant toujours une bonne manière de combiner tout ceci, vos solutions m’intéressent.

Bien du plaisir!

If the iPhone marketshare is quite big, other platforms are emerging. The cool side is that they are built on Webkit as well, like: Android or Palm Pre. Less powerful phones might run Opera mini which has also a very good support of web standards. I’ll try to show simple things you can do to give your website a better experience everywhere without building multiple versions of it.

The biggest problem, the width. On the desktop side, it’s commonly assumed that 1024x768 is the standard. This is why the ~960px width layout is so common (take Yahoo!, Facebook, LinkedIn, …). My opinion is that netbooks will gain some marketshare too and it also weight the fact that one size fits all will be outdated in the next years.

Devices might use HVGA 480x320 (iPhone, Pre, HTC Dream) or QVGA 320x240 or maybe bigger or smaller. The iPhone comes with a feature to control the viewport, which might be supported by the others (like Opera) or not.

<meta name=viewport
      content="width=320; user-scalable=1;">

Like Daniel Glazman said during Paris Web 2009, please don’t prevent the user to scale in/out. This is totally non-standard and there is a standard way of doing that. It’s called media-queries.

<link href="small.css"
      media="handheld, only screen and (max-device-width: 480px)"
      rel="stylesheet" 
      type="text/css">

This stylesheet gonna be applied on handheld devices and others with a very narrow screen (smaller than 480px in this case) and it enables to do cool things like :

• going with a liquid layout instead of a fixed or elastic one;
• linearizing multiple-columns layout (float:none);
• hiding unnecessary stuffs (like you already do in your print stylesheet of course);
• resizing big picture (max-width: 100%);
• making small things bigger, so you can click them more easily (like tiny icons);
• taking into account that there is no :hover state on a touch screen;
• and many more…

Such small screen cannot take advantages of the two dimensions, like a usual monitor does, so a linear (in the Y-axis of course) layout is preferred.

They are of course many, more issues that can be addressed like the iPhone file-size cache limitation, bandwidth reduction, HTTP calls,… I wouldn’t focus on those until you get an audience worth doing so. If it’s not your target of course.

I won’t throw the baby with the bathwater and native applications are good if you need to do specific things with the device itself or require specific performances. Phones offer, or will offer, access to the address book, the camera, the geo-localization,… Most of those require specific actions which aren’t completely specified/implemented yet, like OMTP Bondi or W3C itself.

The best platform to test that is OSX, simply because the iPhone SDK won’t work elsewhere. Testing with the Android emulator or Opera Mini can be done on any platform. Mozilla promised to release soon a version of Fennec targeting the Maemo platform which is already using Gecko. By the way, the N900 looks awesome! To develop it, simply activate that stylesheet for everyone, so no media-queries.

It very easy to start adapting a website to smaller devices and may even force you to have a better grid structure. Maybe not yet a business advantage, but sooner or later it will.

Un seul web (“One Web”) a été usé et re-usé lors du dernier Paris Web. C’est une idée ou un espoir qui plane depuis toujours il me semble. Avec la démocratisation des appareils nomades permettant de consulter le véritable web (ni WAP, ni i-mode). Le réflexe actuel me semble être : « il faut que je fasse réaliser une application iPhone/Android/Pre (ou un widget Opera/Vodafone) pour mon site ». Dans ce cas, je présenterais ce qu’il est possible de faire avec l’existant, et ce qui nécessiterait une application native.

Si le monde du mobile est une jungle encore plus dense que ce qu’on expérimente avec les navigateurs usuels. Les acteurs principaux se divisent entre Webkit (iPhone, Android, Palm Pre, …) et Opera (avec Opera mini). Des moteurs de rendu connus (entre autres) pour leur support de qualité des standards. Des outils existent pour éviter de produire plusieurs versions d’un même site.

Le pas premier à franchir est qu’il est assumé aujourd’hui que 1024x768 est le minimum syndical. Pour preuve le nombre de sites reposant sur cette largeur là, de manière fixée. L’arrivée des netbooks va, j’espère tendre vers un parc informatique encore plus hétérogène et une fin progression de la taille unique.

Pour revenir à nos moutons, nombre d’appareils ont un écran dit HVGA (demi-VGA, 320x480) ou QVGA (quart-VGA, 320x240). C’est pourquoi vous verrez souvent la ligne suivante :

<meta name=viewport
      content="width=320; user-scalable=1;">

Un élément propriétaire à l’iPhone, qui force la largeur à 320px et dans ce cas autorise le zoom utilisateur. Comme l’a souligné Daniel Glazman lors de sa présentation (ou devrais-je dire show) en novembre dernier, désactiver cette fonctionnalité est un non-sens. D’autres navigateurs peuvent supporter cet attribut là, je pense notamment à Opera.

Mais, la boîte-à-outils du W3C n’est pas en reste, avec les media-queries qui permettent de cibler un navigateur selon des spécification techniques :

<link href="small.css"
      media="handheld, only screen and (max-device-width: 480px)"
      rel="stylesheet" 
      type="text/css">

Comme dans ce cas, la largeur maximale en pixels de l’appareil. Donc si l’appareil est plus petit que 480px de large, la feuille de style est appliquée. Feuille qui permet de faire tout un tas de choses intéressantes :

• passer à une mise en forme fluide, et non plus fixée ou élastique ;
• linéariser des colonnes ;
• masquer ce qui sert de décoration
• limiter la taille maximale des images, par exemple ;
• agrandir certains éléments pour pouvoir les sélectionner avec de gros doigts (sur un petit écran) ;
• prendre en compte qu’il n’y a pas d’effet de survol sur un écran tactile ;
• et tout un tas d’autres…

Il y a plusieurs autres points à prendre en considération si l’audience se servant d’appareil nomade est assez importante. Une version adaptée, ne saura certainement pas contenter tous les usagers. C’est à mes yeux un investissement faible et qui amène forcément un plus qualitatif, passer de deux dimensions à une seule implique que la logique de base soit bonne.

Pour ne pas jeter le bébé avec l’eau du bain, il y a un intérêt à l’option application native, pour ne serait-ce qu’au niveau des performances. Plus spécialement dès qu’il s’agit d’intéragir avec l’appareil lui-même, comme consulter le carnet d’adresse, l’appareil photo ou le GPS. Des solutions au sein du navigateur arrivent tant via le W3C qu’OMTP Bondi pour citer ceux que je connaisse.

En matière de test, tout est testable depuis partout, sauf pour l’iPhone où le SDK nécessite le système d’exploitation OS X. L’émulateur Android offre différentes géométries d’écran, ce qui est intéressant. Opera mini est disponible en ligne. Pour parler un peu de Mozilla, Fennec devrait arriver pour le N900 (Maemo utilisant déjà Gecko) d’ici peu. Sinon, en activant la feuille de style comme une autre permet de faire un premier test également. Il y a de quoi s’amuser à améliorer l’expérience utilisateur de nos sites sur ces appareils là. C’est vraiment ludique à faire, même en tant que non-possesseur de ce type d’appareils là.

Let’s start with the background. The development started in 2008 and they picked Rails 1.2.x when Rails 2.0.x existed for almost one year already. This design decision might have been motivated by the fact that some libraries weren’t yet ported to the latest version but still. PDF-writer instead of Prawn when it was known that the later gonna become the one maintained and I can continue with other examples.

This recalls me a story of a huge homemade CMS that had to run inside an emulator for the OS running an utterly old version of Perl because they were no budget to maintain it. When you get there, it’s obviously too late.

I wanna make an analogy with the (most popular) operating system out there:

• I’m using a GNU/Linux flavoured distribution (the very modular one that compiles everything) so I can update it as often as I want (usually once a day) and when something break it’s usually one of them that is easy to identify and most of the time easy to fix too.
• I also use OSX at work and you can feel the upgrade fear. One medium-sized upgrade with often no possible rollback. It toke one week-end to my workmate to get his dev environment running again. During the last upgrade I had to reinstall everything coming from macports and most of the Ruby gems.
• And last but not least, Microsoft Windows. How many Windows 98, 2000 are out there? Many users of IE6 are stuck to it because there are stuck to a particular version of the OS underneath too. I dunno the cost of installing a new version of Microsoft Windows into a company but it must be big (if you take into account the time required).

Web development nowadays is closer to the Linux (and some other unices) distribution philosophy than the two others. Your application is using a bunch of libraries, maybe a framework. They usually have a website, the open source ones a bug tracker, feed of the changes, mailing list and maybe hosted somewhere you can interact with (like github, bitbucket, google code, ...) You can keep an eye on the changes, update them easily.

# Ruby
gem update
# Python
yolk -U
easy_install -U xxx

I’ll not give any details about CPAN (Perl) or PEAR (PHP) since I’ve never used them.

Software development, in the web field at least because it’s what I know the most, is also subject to entropy and requires some energy to keep everything clean. Keep your working environment clean, like a cook has to clean his entire kitchen once in a while. If project manager should do regular bug triage, developer can do, for example TODO/FIXME cleanup sessions.

A trivial advice: when you start a development that will last a couple of months, go with the most recent version or why not the bleeding-edge one (often called trunk, tip, head, …) if it might be stable when you’ll be done.

I’m wondering if a company that doesn’t have the resources to maintain a piece of code shouldn’t open source it to take advantage of a community-to-build. But this has a cost too.

L’enfer des mises-à-jour, des migrations, des changements de version. Voilà ce qui m’occupe depuis quelques temps déjà. Ça ne se passe pas sans douleur, ni surprise ou questionnement. J’aimerais simplement tenter de sensibiliser à quelques choix simples pouvant être fait.

Un peu d’histoire sur le cas qui nous intéresse ici, un passage de Rails 1.2 à la dernière version 2.3, soit grosso modo 2 ans d’écart, d’améliorations, d’ajouts ou de suppressions de fonctionnalités. 2 ans qui paraissent un peu bête quand le site n’a — lui, dans sa version actuelle — qu’une année. Ce qui est peut-être expliquable en se disant que les outils annexes (telles que les bibliothèques) n’avait pas encore eux été adapté pour supporter la dernière version.

Autre exemple, plus ancien, est un CMS qui devait tourner via un émulateur car la version du système d’exploitation (BSD) n’était plus supportée. Quand ce stade là est atteint, c’est qu’il est généralement trop tard pour agir car les autres solutions ont déjà été écartées.

Pour amener l’idée finale, qui est de toujours tenter de suivre les versions récentes (ou actuelles) j’aimerais faire un parallèle avec les systèmes d’exploitation (ou distributions) :

• J’utilise principalement GNU/Linux et c’est un bonheur de ce côté là puisque tout est généralement orchestré par le système de paquets (les apt, yum, portage, pacman, …). Au final, mon système est mis à jour régulièrement, quand je le souhaite et il est possible de revenir en arrière, corrigé rapidement en cas de problème.
• OSX qui a un système à la Windows Update mais offre (lisez vend) régulièrement des mises à jour comprenant des changements plus importants. Bien que de tailles raisonnables elles ne sont pas toujours sans douleur et généralement sans retour en arrière (simple).
• et le dernier Microsoft Windows, qui traine toujours des casseroles fonctionnant sous des versions vieilles d’une bonne décennie. Des systèmes verouillés dans le temps car une mise à jour est trop coûteuse, impossible ou jugée inutile.

Quand mettre à jour signifie réinstallation avec ou non achat de nouveau matériel, j’ai peu d’espoir que ça puisse suivre rapidement. Point prouvé avec les différentes politiques de mise à jour des navigateurs d’ailleurs.

Le développement web est assez proche d’une distribution Linux, généralement le serveur fonctionne sur cette technologie d’ailleurs. Une application va fonctionner se reposant sur un ensemble de bibliothèques, dans le meilleur des cas open source, dont il est possible de suivre les évolutions et les appliquer. La simplicité d’appliquer une petite mise à jour, au fur comparée a un gros changement est à mon sens d’une logique sans faille. La première étant satisfaisante et la seconde ressemble plus à une corvée.

Dernier petit conseil, au début d’une nouvelle application, n’hésitez pas à opter pour la version de développement, il y a fort à parier que celle-ci se stabilise d’ici à ce que vous aillez terminé. S’il y a effectivement un gain par rapport à celle dite stable.

Je me demande dans quelle mesure une application ne pouvant plus être maintenue peut y remédier en tentant d’ouvrir son code.

But as we are forced to use Gecko we should simple go for the Cross-domain XmlHTTPRequest, it’s simpler and safer.

JSONP works by appending a script to the page that will call a function we gave it with the data we expect:

callback({hello:"World!"});

for example. It’s totally unsafe and you have to really trust that third party. XMLP relies on the fact that E4X makes XML first citizen, like RegExp, Array or any other native type.

var a = <root>I’m the root</root>;

So, XMLP might look like:

callback(<hello>World!</hello>);

On Gecko (reading Firefox and bros), E4X can be enabled by adding eax=1 to the type:

<script type="text/javascript;e4x=1" …></script>

E4X is quite interesting to play with. Unfortunately Gecko and Flash are the only two platforms where you can use it. By Gecko I mean SpiderMonkey and Rhino (the two JavaScript engines Mozilla branded).

Grab this very basic example application for Python.

Voici ma première invention inutile; même d’autres y ont pensé avant moi pas d’illusion sur ce fait là. L’idée est de transposer le fonctionnement de JSONP à XML. JSONP est le moyen d’importer des données venant d’ailleurs et de les récupérer et de les traiter chez soi, comme on l’entend. Les célèbres MashUps, aka combinaisons de différentes sources de données ou outils en un nouvel élément se servent souvent de JSONP (via Y! Pipes ou YQL par exemple).

Dans un long débat concernant le bien fondé d’un JSON vs XML; JSONP me semblait le seul élément qui offrait un avantage intéressant à JSON. En tant compte de tous les problèmes de sécurité. JSONP ressemble à ceci:

maFonction({message: "Salut !"});

Ceci est fournit par un autre serveur est est inclu via une conventionnelle balise scripte. XMLP repose sur le fait que grâce à E4X (ECMAScript for XML), XML devient un élément natif de JavaScript.

var doc = <racine>Salut !</racine>;

Donc, il est également possible d’envoyer ça à sa fonction dite de callback :

maFonction(<racine>Salut !</racine>);

Si c’est assez brillant, le problème réside dans le fait que ça n’est uniquement supporté par Spidermonkey (et Rhino); le moteur JavaScript de Firefox ainsi que les produits Flash.

Petite astuce pour activer E4X, spécifier via le type du scripte.

<script type="text/javascript;e4x=1" …></script>

Firefox supportant dans les versions récentes les requêtes sur d’autres domaines, il est bien plus viable de passer par XmlHTTPRequest.

Bref, c’était un petit amusement, que je vous invite à essayer vous même: xmlp.py.

What we do have at work is a basic session counter. It helps us not pushing a release when a lot of people are surfing the website even it has been easier since we switched from Mongrel to Passenger. From a simple number, like “280 sessions” I’d try to move that to the next level and having a view of the actual usage.

The idea is to count views and to store that into memcached using the current time as a key and putting a timeout of the length of the needed graph.

# first visit
memcache.add(now, 1, 3600)

# next visits
memcache.incr(now)

And to build the graph, you get all the values from a set of keys at once and then use Google Chart is used to build a nifty view.

Stats of the last hour charted by Google Chart.

This is a Rack (or a WSGI) middleware so can fit into your application very easily. Get the source code that contains an example:

• Ruby (thin -R livestats.ru start)
• Python (python livestats.py or spawn livestats.application)

Si Google Analytics semble être devenu l’outil de statistiques le plus répandu pour les modestes bourses, il y a un point où il pèche : avoir des données live. C’est dû à l’architecture choisie par Urchin (à l’époque) j’imagine. Architecture qui sert une fonction précise et justement pas celle d’être instantanée.

Le site internet sur lequel je suis employé utilise simplement un compteur du nombre de sessions en cours afin de déterminé si c’est un moment chaud ou normal face à une mise à jour devant être faite. Le but étant bien sûr de minimaliser les coupures. L’idée ici est de donner une information instantanée qui n’est ni pérenne ni représentative du nombre de personnes physiques utilisant le site actuellement. Pour info, ça n’est pas utilisé actuellement, c’était simplement pour mentionné la source d’inspiration et le contexte.

L’idée est de stocker des compteurs dans memcached pour un temps donné et de laisser Google Chart faire le travail de mise en forme.

Le code est à votre disposition :

• Ruby (Rack)
• Python (WSGI)

Disclaimer, I haven’t tested Lamson but feels more confident to go with a solution built on top of Twisted then another one redoing most of the job using plain asyncore and threads.

We will start by using txmailserver originally built by Duncan McGreggor, a set of tools to set up a basic STMP server, with POP3 support.

Read the file server.tac to see all the boiler plate, I’ll show the interesting parts.

def twitpic_it(dest, message):
 pass # see bellow

domains = {
 "twitpicit.org": [
  Script(r"[a-zA-Z_0-9\-\.]+\+.+",
         twitpic_it)
 ]
}

It’ll accept any email users that look like: me+mypassword@twitpicit.org and call the twitpic_it function. From there we can do whatever we want. No more details on the email treatment.

def twitpic_it(dest, message):
 username, password = dest.local.split("+", 1)
 
 # finding the part which is a picture
 # and building a temporary file with it
 file = file_from_message(message)

 if file is not None:
  datagen, headers = multipart_encode({
   "username": username,
   "password": password,
   "message": message["Subject"],
   "media": file
  })

  request = urllib2.Request(
   "http://twitpic.com/api/uploadAndPost",
   "".join(datagen),
   headers)

  file.close()

  urllib2.urlopen(request).read()

There you go, you’re able to twitpic everything you like from any email client. After you’ve set up that on one of your domain of course or you can try it locally using a simplistic Python script: test.py.

$ twistd -ny server.tac

in a different shell:

$ python test.py mypicture.png My message

The server should display the response from Twitpic. Of course this is purely overkill if you can directly use the API.

Email is still an interesting interface for people that aren’t techie at all. For people that sits behind a desk with only that as an interface to the outside world because the IT service decided that you shouldn’t spend your day playing on Facebook or because you are Richard M. Stallman (RMS) himself.

Most of the time a bad usage of emails is made, like answering leads to nothing (the infamous noreply), of you have to visit it inside a browser to do something. Don’t neglect it as a tool that most of the people understand and know how to use it. It means they don’t have to think too much in order to use it.

The code is on Launchpad.

Email premier usage popularisant le web reste une bête difficile à dompter, en raison de son usage publicitaire intensif, mais a le potentiel d’être un outil de choix pour la simple et bonne raison qu’il est connu de toutes et tous et n’est que très rarement bloqué par un service informatique faisant du zèle (pour ceux qui intéragissent avec le web essentiellement depuis leur place de travail).

En exemple un mini serveur SMTP ne fonctionnant qu’en mode réception — rien ne vaudra jamais un véritable MTA pour fonctionner en mode relay (émission), type postfix ­— qui va poster l’image sur Twitpic avec le texte donné en titre.

Le code est écrit en Python et repose sur Twisted, un ensemble d’outil permettant de programmer de manière évènementielle et contenant bon nombre de protocoles supportés (tel SMTP et POP3, dans notre cas). Le code de base provient du projet txmailserver qui a pour but d’offrir un serveur SMTP/POP3 minimaliste.

Comme vous pouvez le voir dans ce script fonctionnant comme serveur permet de passer les adresses reçues à une fonction. Ensuite, libre à votre imagination créative d’y faire ce que bon vous semble. Je ne connais pas Lamson qui a pour but de servir de boîte à outils pour ce type d’applications là.

Trouvez le code sur Launchpad.

Before going further, Matt Biddulph (CTO of Dopplr) made a very interesting presentation explaining how Dopplr is using messages that transit between the different parts of the application. Take a look at it! Dopplr: It's made of messages - Matt Biddulph

How messages can help your web application to become better? Like every good manager do, by delegating. Instead of doing everything yourself, let other people doing that for you. The drawback is that you’ll have to wait on that person to do his job, the good ones are that you can quickly answering your customer (sending back a HTML page in our case).

I wrote a simple application called up! that is an image uploader. The cool thing about this image uploader is that, like Flickr for example, once the pictures are uploaded the application tells you that the thumbnails are currently processed and that you’ll very soon get them without telling anything before its done (which is rude, but common)

Let’s dive with the image upload.

When John uploads his picture, the file is saved into a temporary directory and a message of this kind is sent to a queue called resize.

("/tmp/foobar.jpg", "jpeg")

And respond directly with a HTML page containing a placeholder for the thumbnail.

<p id="preview">
 <span>foobar.jpg</span> sent.
</p>
<p id="loading"><em>
 Please wait for the preview
 to be generated.
</em></p>

Now, the client will try to obtain the expected thumbnails.

On the client-side a JavaScript code will ping that expecte picture every 2 seconds as long as the server doesn’t find it and therefor answers with an error 404.

During that time, a consumer (a different process, independant from the web server) will get that message, resize the picture in 3 different sizes and put them at the right place. The arrow that goes back to the queue is a message acknowledgement saying that everything went find and that the message can be removed from the queue. The goal is to not lose any messages, if possible.

Once the thumbnails are available, the page displays the picture and the polling is stopped.

Different messaging mecanisms exist, some of them are very simple, like STOMP, but most of them are transcient only. It means no persistancy, if nobody listens; the messages are lost. Because shit happens, I prefer having some kind of persistency and acknowledgement that a message was well processed. Persistance means slowliness too. For that, this demo uses RabbitMQ and the AMQP protocol. The first one is powered by Erlang and both of them are open source. Installing RabbitMQ is as simple as (once downloaded and extracted): make run. Learn more about RabbitMQ reading: Rabbits and warrens.

As libraries, it uses both txamqp (tx stands for twisted matrix) and amqp-lib. I find amqp-lib handy for the client side, to just send a message and prefer twisted matrix for a server that has to live (if possible) for ever and without causing too many trouble. Using only amqp-lib is of course possible.

Resizing image is one use case, maybe not the best one. In another application, I’m also using a queue for sending e-mail notifications, or it could be IM notification (AMQP instead of XML-RPC in my twootr article for example), ... Separating them from the web server logic as the great advantage that you can tune both of them separately, instanciate more processes to handle image resizing the one you have have too much work without affecting anyone else. Small pieces of software collaborating together.

I’ve read once, that once you’ve gone in that path, you cannot go back. You’ve been warned. I think that big monolithics web apps aren’t agile enough those days where data are growing bigger and data are going faster to many people, mediums and third-parties.

Download it from bitbucket and feel free to hack it or to send me any questions.

Envoyer des messages est le cœur d’Internet. Ça a commencé par les courriels (e-mails), puis les messageries instantanées (dont le fameux XMPP) et à l’heure actuelle, Twitter et autres confrères brassent une quantitée impressionnante de petits messages devant être distribués à un grand nombre de destinataires de manière (quasi-)instantanée. Cet article illustre comment l’usage d’une architecture à base de messages peut être bénéfique à une application web.

Avant tout, je vous invite à prendre connaissance de la présentation donnée par Matt Biddulph (CTO de Dopplr) concernant l’architecture qui a été adoptée dans le cadre de ce projet. C’est tout simplement très instructif. Dopplr: It's made of messages - Matt Biddulph

Comme vous pouvez le voir dans la partie anglophone, qui est joliment illustrée d’ailleurs, le but a été de réaliser un système d’envoi d’images qui va déléguer le traitement des images à un tier. Le serveur web peut ainsi répondre directement informant que le fichier a été envoyé et que les miniatures seront très promptement disponible sans avoir à le faire lui-même.

Un message a été envoyé dans une queue de messages, et va être distribué à une petite application dont le but est juste de redimensionner l’image en (dans ce cas) 3 miniatures. En parallèle, un petit bout de JavaScript va tenter d’accèder aux fichiers devant être produits, à intervale régulier (ici 2 secs), jusqu’à ce que ça réussisse et qu’il soit possible d’afficher le contenu à l’utilisateur.

De prime abord, l’avantage de ce mic-mac n’est pas forcément clair, maintenant imaginez que ceci soit fait par le serveur web directement, qui a pour, presque unique fonction, de servir un maximum de monde le plus rapidement possible. Redimensionner une image implique d’ouvrir un fichier parfois volumineux pour en créer un autre un peu moins volumineux. Ça rime avec mémoire. Et si un serveur web qui sert 50 requêtes simultanément ouvre 50 fichiers JPEG de quelque Mo chacun, ça peut être coriace pour lui, et surtout pénible pour les autres utilisateurs qui aimeraient bien envoyer leurs images mais ne peuvent pas accèder au serveur car il est raz-la-gorge.

Déléguer signifie avoir les mains libres pour faire autre chose, signifie également que si ça ne suit pas de leur côté, il est envisageable d’allouer plus de ressources à cette tâche-là. Et bien sûr, découpler un problème en de multiples tâches réduit un gros problème en plusieurs plus petits problèmes. Dans ce cas-ci c’est tout simplement le bon vieux problème du producteur / consommateur.

Le code se compose d’un peu de Python, tout simplement WSGI, utilisant WebOb, AMQP-lib (pour le producteur) et txAMQP (pour le consommateur). AMQP est un protocole libre et qui possède notamment un client écrit en Erlang nommé RabbitMQ, libre lui aussi. L’avantage de ce dernier est qu’il est capable de gérer des listes persistantes avec confirmation de lecture. Ce qui manque souvent dans d’autres protocoles plus simples, comme STOMP. Trouvez-le et faites-en ce que vous voulez sur mon compte Bitbucket

L’usage d’AMQP n’est pas forcément facile à prendre en main, tout simplement car les possibilités offertes sont très vastes mais étonnamment efficaces. Il est, par exemple, très simple qu’un message soit dispatchés vers plusieurs consommateurs différents sans avoir à envoyer son message plusieurs fois. Donc de découpler les producteurs des consommateurs, mais c’est une autre histoire qui est très bien documentée dans cet article là : Rabbits and warrens.