No more air conditioning, wheel chairs, dual screens, coffee break, cantine, daily standup, weekly meeting, headset, skype calls or who’s-the-hell-broke-the-build mornings. It’d be great to get that body to finally do something (gym doesn’t count and I’m not really into it) and let that full of not-that-important-stuff brain relax a bit.

Via sab.ch, I found some farmers looking for a hand this summer, applied and accepted. This means I’ll know how to milk cows and make cheese by this automn, will let any computer-related activities aside for a while and concentrate on a work that is more meaningful, at least seems to.

I’ll be up there, send me a postcard.

This ends mid-October and I don’t know yet what I’ll do then. Freelancing as I do since December is the logical way but as I know me, I don’t know what’s ahead and it’s a good feeling.

Suite à un camp de ski à Zinal, une mouche m’a piqué. Celle de profiter de mon statut d’indépendant pour vivre une expérience dépaysante, à l’air de la montagne. Le genre de mouche qui m’a fait prendre le large pour Paris ou la Norvège mais dans une autre orientation.

Adieu air conditionnée, pauses café, chaises à roulettes, cantine, meetings, échéances, bugs, IE6, casque audio, … et bienvenue vaches, veaux et fromage. Il est temps de (re)mettre en activité ce corps jeune (tant qu’il l’est) et reposer cette tête qui finit par trop penser et sature de contenus aussi inutiles qu’inintéressants.

Via Sab.ch, j’ai trouvé un petit alpage auprès duquel je pourrai offrir mes services et y apprendre le b.-a.-ba du monde agricol alpin tel qu’il existe toujours en 2010. Départ le 17 mai pour 5 mois de bonheur.

N’hésitez pas avec les cartes postales :

Yoan Blanc c/o
Gilbert Henchoz
rte des Blanchettes 51
1660 L’Étivaz

Le retour à la vraie vie est prévu mi-octobre et j’imagine que je reprendrai le cours des choses là où elles sont restés. Enfin, peut-être pas, me connaissant je sais qu’il faut laisser les portes ouvertes aux idées.

Let’s take that simple piece of PHP code :

<?php
$req = "http://pipes.yahoo.com/pipes/pipe.run?_id=…&_render=php";
$data = unserialize(file_get_contents($req));

It grabs some external content and might take some time to achieve this depending of Yahoo! Pipes. This is where the problem starts to itch. When the server gonna call that page it’ll do mostly nothing but waiting for the external data to arrive.

Using Apache, a process or a thread is spawned, waiting on external data and, more importantly, consuming memory and CPU by just waiting.

Going asynchronous would mean being able to do other stuff, answer to other requests while waiting.

Unfortunately, I don’t know any solutions for that problem in PHP. PHP is designed to be executed as fast as possible and not for doing heavy operations. Big websites that are using PHP use it in general as pure front-end language (for example, the before-Google YouTube).

They are a couple of solutions to go async. Some come from a specific language that is asynchronous by design, like JavaScript (with node.js) or Erlang (to name a few). Ruby can achieve this by using EventMachine and Python (which I explored more) has a couple of solutions (Twisted, Tornado (coming from FriendFeed, bought by Facebook), Eventlet, Gevent, …). Take this dummy WSGI code:

from time import sleep

def application(environ, start_response):
 start_response("200 OK",
		[("Content-Type", "text/plain")])
 sleep(1)
 return ["Hello, world!"]

The external stuff you’re waiting on is simulated by a sleep, which makes it easy to understand. Up to you to fetch external data that will take a fixed time to arrive (which is the same).

When you run this particular code, a process/thread will be dedicated for that during one second blocking other incoming ones, right? You’ll need as many workers/threads/processes as requests to handle them all in one second. Suboptimal since those particular processes aren’t doing anything special.

Take a look at some tries I made.

Eventlet and Gevent, the more convenient to use imho, will run each incoming requests into a coroutine (like a sub process) enabling the main process to do something else when some time is available. The only thing to change in the code above is where the sleep function comes from.

from eventlet import sleep
from gevent import sleep

And, of course, to run it using the appropriate server (the one from the library, Gunicorn or Spawning (Eventlet only)). Those libraries are doing monkeypatching so no code has to be modified in order to become asynchronous. I.e. using urllib.urlopen to fetch external data will not block the whole process. No code changes are required.

Twisted or Tornado, for example, are using a reactor model, which forces you to handle asynchronous code with callbacks. It’s closer to the metal but the learning curve might gives you some headaches. I do love Twisted, but it’s sometimes just too much, really.

Python has another project, running on top of Python Stackless, called Syncless dedicated to async code. It looks quite promising.

Ruby 1.9 will get coroutines under the name of Fibers, until that EventMachine seems the way to go. It looks like super clean Twisted too me. I hope not hurting too much feeling by saying that. (BTW, there is a great article from the SuperFeedr guys: Ruby Fibers may confuse)

One very interesting project, and very young as well, is node.js. Basically server-side JavaScript. This one is asynchronous by design and totally awesome if you love JavaScript or coming out of hell if you don’t like it. I do like it.

With the web evolving the way it does, where data is coming from multiple sources, heavy or special tasks are delegated to specialized units (SOA), I clearly see this asynchronous idea as an ongoing paradigm shift. Today’s bottleneck is the I/O, most often represented by the database.

Don’t forget that the backend performances aim only to serve more people, faster but 80-90 % of the time is spent on the client side. I’m a frontend guy after all.

Pour changer, je vais parler de backend, de ce qui cause des ennuis et malmène un serveur et les solutions qui sont explorées.

Prenons un code assez simple, qui récupère des données externes, par exemple un pipe Yahoo! ou un flux RSS. Dans la majorité des cas, le temps passé à attendre ces données externes est perdu, ne pouvant être réutiliser pour en faire autre chose, comme par exemple en PHP où, à ma connaissance, aucune solution n’existe.

L’idée de base est de, pendant ce temps d’attente, mettre ce bout de code de côté et en prendre un autre. Ce qui permet pendant que la requête d’Alice est en cours, de s’occuper de celle de Bob. C’est ce qu’on entend par asynchronicité, un système dit non-bloquant où certaines opérations (liées à l’environnement externe) ne bloque pas tout le processus.

Diverses solutions existent, dans différents langages de programmation. Certains sont de part leurs concepts déjà capables de fonctionner ainsi, comme Erlang ou JavaScript. Python et Ruby offrent des moyens d’y arriver également. Jetez simplement un œil aux bouts de code suivant.

Ce sont tous des applications prenant une seconde pour s’exécuter mais qui, au sein d’une seul processus, peuvent fonctionner de manière non-bloquante et parallèle (sans thread). Une comme dix ou vingt requête en parallèle prendront 1 seconde alors que la manière naïve demanderait autant de processus, threads ou autre que de requêtes faites. Les gains de mémoire vive et de processeur sont drastiques.

Comme vous pouvez le voir, certaines solutions semblent plus élégantes, plus simples. Gevent et Eventlet, par exemple, utilisent les coroutines et viennent modifier les éléments existants, bloquants, par une version tirant partie des coroutines, donc non-bloquante.

Selon moi, il y a ici un réel changement dans la manière d’aborder le développement web aujourd’hui. Les applications se distribuent de plus en plus, déléguant certaines fonctionnalités à des entitées plus spécialisées (SOA), voire même, à d’autres services. À l’heure actuelle ça reste souvant les interactions avec la base de donnée qui requièrent le plus de temps.

En tant que développeur frontend, je ne peux m’empêcher de rabâcher que s’il y a là des pistes intéressantes afin de servir plus de visiteurs, plus rapidement avec le même serveur, de 80 à 90% du temps est occupé côté client.

A Quality Assurance role is more than acting as a tester, far more, but let’s start with what a tester can bring you.

Including a tester in a task can shift from a dialog between the one who’s asking something and the one who gonna do it to a three members discussion forcing everyone to be more precise in what he does or asks and documents more. Is documentation something that lacks on your project? Testing starts at the same time than doing by planning what’s gonna be tested and what are needed in order to test everything. As a developer it always helps to know what you need to deliver in order to cover all the interesting use cases.

QA can help fighting entropy. The fact that you cannot maintain order without creating disorder and that things degrade over time. Nowadays many tools are available to program testing, to run them automatically, to find out what’s tested and what’s not, and many more.

As a developer you might be already writing unit tests, functional tests, integration tests, practicing TDD/BDD, maybe ping-pong development or other kind of XP techniques and it’s awesome. Although I still see the need of someone with a focus on that part as you have your focus on delivering what you’ve been asked to.

Assurance is about preventing problem to happen by acting upstream. They are simple tools against firefighting, like code reviews, using linters but mostly communication is a great help. Having a dedicated QA role helps using those tools and ease communication as well.

What sounds really important to me is the separation of roles, delivering something on time vs delivering something that works as expected. The person who’s asking it wants both and I often found myself not being able to wear the two hats. Like a writers has difficulties to find his own spelling mistakes.

Role plays are fun and I don’t think that wearing the QA hat is degrading or boring.

Au travers des différents postes, projets auxquels j’ai participé, un point continue de m’étonner. Le manque d’attention porté sur la qualité du produit fini. De manière générale, ça ressemble à voici ce qu’il y a à faire, fais-le. La description pouvant être relativement floue et le résultat attendu presque laissé libre à celui qui doit le réaliser. Si de petits projets peuvent fonctionner ainsi car la communication est aisée, les problèmes sautent aux yeux dès qu’une équipe gagne en taille.

Le rôle d’assurance qualité est très vaste et ne doit pas être réduit au terme testeur. Même si un simple rôle de testeur peut apporter énormément déjà.

Le test intervient simultanément avec la réalisation, de manière légère préparant ce qui devra être testé et s’assurant qu’il obtiendra tous les éléments nécessaires aux tests. D’autre part, ça ouvre la discussion entre la personne définition la tâche à accomplir et celle qui la réalisera. De deux à trois personnes, il devient indispensable d’être plus précis et certainement de se reposer sur de l’écrit. En tant que développeur j’ai trouvé intéressant d’avoir une personne venant me demander des éléments testable, devoir préparer ceci aide lors de la réalisation.

Dans un rôle de validation, de tests, il est, à l’heure actuelle, indispensable de mettre en place un certain nombre d’outils permettant de rejouer ces validations dans le futur. C’est une tâche demandant un investissement certain et des compétences adéquates. Même en tant que développeur si vous vous reposer déjà sur du développement piloté par les tests ou simplement des tests unitaires vous verrez comme une grande aide d’avoir une personne concentrée sur la qualité plutôt que les échéances.

Il est souvent dommageable de voir une telle attention portée sur un délai de livraison, voulant absolument tout y mettre. Peu souvent il m’a été donné de voir la mentalité disant : « je préfère en faire un peu moins mais ça doit être du solide »hrom. Un rôle dédié à ce point de qualité peut amener ça, s’il est bien entendu soutenu et pas combattu dans des discussions dites politiques.

L’idée d’assurance soutend que le gros du travail doit être fait en amont, prévenir un problème coûte bien moins que de l’identifier et le corriger. La tendance est à voir cette personne là intervenir à la fin, quand il est souvent trop tard hélas. Être présent dès le début, et pouvoir aux travers de code reviews, de tests spécifiques, d’analyse du code améliorer de manière continue le produit fini est faisable et ne me semble pas avoir un coût énorme. C’est un parti à prendre et une ouverture d’esprit à avoir.

Séparer les rôles en fonction des objectifs est vital. C’est difficile d’être juge et parti. D’autre part, je considère une position de testeur, ou d’assureur (voilà qui fait sérieux) comme n’étant pas du tout péjorative, c’est même un élément intéressant à réaliser quand il s’agit de mettre en place des outils.

“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.