Le blog du garambrogne

Nouille sauce piquante et concombre

Mathieu Lecarme — Fri, 23 Sep 2011 22:15:00 +0200

Recette adapté d'un plat mangé dans un bon restaurant chinois, c'est donc surement peu orthodoxe, comme version.

Ingrédients

Nouilles asiatiques sous vide (des spaghettis devrait faire l'affaire).
Une tomate qui traine au fond du frigo.
Un concombre.
Sauce piment, la bouteille avec le bouchon vert que l'on trouve dans beaucoup de restaurants asiatiques. Elle existe format biberon pour poupée.

Recette

Dans une sauteuse, on fait revenir la tomate coupée en petit morceaux, dans un peu d'huile. Couvrir. Pendant ce temps, préparer le concombre. Le peler en laissant des bouts de peaux de moins d'un centimètre, ça fait joli, mais trop large, la peau dure peut déranger. Couper le concombre en deux dans le sens de la longueur. Avec une petite cuillère, enlever la partie centrale contenant les graines et le liant gluant. On obtient une espèce de pirogue, avec uniquement la chair du concombre. Couper en tranche de un centimètre. On obtient des espèces de demi-lunes, ou des petits ponts.

Normalement, la tomate a attendu et n'a pas pas attachée. Selon le potentiel de la tomate, on peut compléter avec une petite boite de concentré de tomate dilué dans deux fois son volume en eau. Saupoudrer une cuillère a café de sucre, pour casser l'acidité de la tomate. Ajouter les concombres. Faire cuire à couvert pendant au moins 15 minutes. Le concombre va suer et donner un liant à la sauce, une épaisseur un peu gluante. Ajouter de la sauce piment en ayant bien en tête la tolérances des convives. Ils pourront de toutes façons assaisoner plus violement une fois le plat servi.

Une fois la bonne texture de concombre obtenu (il faut gouter, pour obtenir le niveau juste en dessous de croquant). Ajouter les pates sous vide et un verre d'eau. Elles doivent se délier dans la poele, laisser cuire quelques minutes à couvert.

Ni sel ni poivre.

C'est pret. La douceur un peu aqueuse du concombre équilibre le sucré de la tomate et le piquant du piment.

Variantes

Dans la recette originelle, il devait y avoir de l'oignon, des noix de caroubes ou des cacahouètes, des choses vertes, du coriandre peut être? Du poulet aussi, il me semble. Là, la recette utilise ce que j'avais de disponible à la maison, et c'est végétarien. C'est bon pour le karma. Pensez à prendre un steack tartare haché gros avec des pommes sautés, le lendemain, pour compenser.

hacking and logging async server : test on ejabberd

Mathieu Lecarme — Thu, 03 Mar 2011 23:32:00 +0100

Async server is marvelous for handling lots of parralels connection. Understanding what happens inside it is a challenge.

Ejabberd is a mature erlang server with a real world application : chatting.

Ejabberd provide a live console. Very helpful for crash during start (with your own module, provided one a pretty stable), irritating in use in real condition. All things happen in the same window. You wont to enter some commands, taddam, ugly logs hide what you are typing. Logs are multines, with 80 columns very useful on your 1980 Terminal and your stone keyboard.

I wont two things : using ejabberd on a distant Linux, working on a Unix computer. Client/server is needed.

Debugd

Here is debugd, a basic json broadcaster over TCP/IP. Launch the server (it's an OTP application), connect with a client, broadcast message. The protocol is simple, 4 bytes for the message size followed by a Json encoded message. Python example is provided, you can build your own easily.

Hacking Ejabberd

Ugly hack in ejabberd_app.erl to start start the application in the start/2 function :

application:start(debugd),

Polite person should make a module wich start the debugd application.

Cleaner hack in ejabberd_loglevel.erl for triggering messages. Ejabberd use a trick for logging, the code is made on the fly. I add my code inside after the "(Module, Line, Format, Args) ->

debugd:json({struct, [
            {module, Module},
            {line, Line},
            {message, iolist_to_binary(io_lib:format(Format, Args))}
            ]}),

You have to be quick, now. Launch ejabberd with ejabberdctl and in an other winddow the client.py . Now, magic happens :

$ ./client.py 
{u'line': 37, u'message': u'ejabberd has not been compiled with relational database support. Skipping database startup.', u'module': u'ejabberd_rdbms'}
{u'line': 166, u'message': u'Reusing listening port for 5222', u'module': u'ejabberd_listener'}
{u'line': 166, u'message': u'Reusing listening port for 5269', u'module': u'ejabberd_listener'}
{u'line': 166, u'message': u'Reusing listening port for 5280', u'module': u'ejabberd_listener'}
{u'line': 73, u'message': u'ejabberd 2.1.6 is started in the node ejabberd@localhost', u'module': u'ejabberd_app'}
{u'line': 73, u'message': u'ejabberd 2.1.6 is started in the node ejabberd@localhost', u'module': u'ejabberd_app'}

It works. But it's just a POC, I'd like to know the process ID and parents (where I am), and need some works on the display : filter, colors, info on the server status, crash report ...

Finding a way to start the debugger client when the server start can also be a good idea.

To be continued.

Handling production logs

Mathieu Lecarme — Fri, 11 Feb 2011 21:20:00 +0100

Logs, the big files that fill up your hard drives can also tell things to you. Post mortem crash or strange slowness.

You can add temporary logging for slow query (mysql or php-fpm provides such services). Be careful, logging is not your first activity, works have to be done without probing servers to death. Applications and hardware provides data, but never forget to use application specific information. Datas that speaks to you, like page serving time, number of logged users or growth of user’s data.

The basic tools to understanding logs are tail, grep, wc, sort, uniq and all this kind of pipable stuffes. Facebook provides titanic tools for handling iceberg sized volume of logs. There is room between them. There is few step to understand logs.

Reading

First step is reading logs. Some logs come from plain old files, other from sockets, they can be piped. Syslog is an elder unix worker. Its protocol is now funny and ingenuous, but it’s a defacto standard, and rsyslogd is a nice product wich can route some of its incoming logs to another server.

Parsing

Most of logs are one line ascii string. Basic, but grep friendly. Some data are directly usable, other need processing like resolving IP to name or geolocalisation, guessing web browser.

Filtering

Logs line can be boring or hidden like needle in an haystack. Date is an important filter. What happened when the server was so slow?

Storing

Logs are immutable, append only data. It’s a specific case well handled by specific storage, few will cry if you loose some data. Files are easy to handle but some index can help you a lot. Logrotate helps you to compress and erase old logs periodicaly. RRD data is a perfect way to store data with a fixed size store.

Querying

Now, you can querying and digging into this files. Graphing helps you to visualizing your data. You can find where the trouble append, where is the bottleneck, how many user your service can handle, how many server you will have to buy. Such questions can be answered.

Logator try to answer this questions. It’s actually a work in progress. Ip2something is a fast geolocalisation tool which make IP more usable, and logs more understandable. Node-logator is a prototype to graphing real time connection localization.

simple python work queue with zeromq

Mathieu Lecarme — Sat, 23 Oct 2010 18:13:00 +0200

Python is powerful tool, but it can't use more than one core. It's a pity, even an Atom chip is multicore. With zeromq you can distribute work between core (and computer, if you like giga ethernet).

Python can handle thread, but it's only usable for non blocking tasks. Doomed by its big giant lock, you can't handle more than one core.

Zeromq is a library for abstracting and simplifying communication between applications. It means Zero Message Queue. It's a low level tool with a lots of binding. The python binding, pyzmq is pretty complete. Python can handle socket, but zmq do the dirty works, with simplicity.

brew install zmq
sudo pip install pyzmq

My example is common. I wont to parse log and storing it in a NOSQL base. My firsts tests are done with mongodb, because its website is more cute than riak's one. Reading log file is fast, writing Mongodb is fast too, parsing line is CPU intensive. With zeromq you have to find the right pattern, the right already invented wheel. For my task, the work queue task is the right pattern. There is a task list, and workers wich pick one, chew it, and store the result. The multiple server pattern seems to be a goog idea, but using the work queue as a server, and worker as a client is the simplest way.

The queue read the log files, handling it as an iterator. Each client ask for a task, the queue iterate once and answer the line. When the log files are finished, the queue answer an empty string for each query, workers stop querying. You can start one worker per core, per computer. For this example, I use ipc connection, Inter Process Communication, also knows as UNIX socket.

Server

c = zmq.Context()
s = c.socket(zmq.REP)
s.bind('ipc:///tmp/logator')

print "waiting for workers"
for line in sys.stdin:
	msg = s.recv(copy=False)
	s.send(line)
	
while True:
	msg = s.recv(copy=False)
	s.send('')

For each log's line (coming from a zcat piped to the script), we are waiting for a worker question. We don't handle what it's saying, we just gives its work. When it's done, we answer "no more work" for every one.

Client

c = zmq.Context()
s = c.socket(zmq.REQ)
#s.connect('tcp://127.0.0.1:10001')
s.connect('ipc:///tmp/logator')

class Logs(object):
	def __iter__(self):
		while True:
			s.send('', copy=False)
			line = s.recv(copy=False)
			if line == '': break
			yield str(line)

The log analyzer needs an iterator. The worker ask for a job, got it, yield it.

Real code are in the logator project.

With this strategy, each work can consume up to 75% CPU. It's hummer strategy, my CPU is fully used, 300% for 4 cores.

1 worker : 1600 lines/second
2 workers: 2700 lines/second (1350/worker)
3 workers: 3400 lines/second (1133/worker)
4 workers: 3800 lines/second (950/worker)

This is a zeromq poc to make my processor hot. If a worker crash, the log's line is lost. If you wont a real worker queue, have a look to beanstalkd or the amazon's SQS, boto, the python wrapper provides a nice API.

Colors in your terminal

Mathieu Lecarme — Wed, 13 Oct 2010 13:15:00 +0200

In a world where everything has a GUI, the ugly and antediluvian terminal seems to be an abberation. MacOSX brings only one thing to MacOS : the Terminal.

Terminal doesn't have to be sad, you can use audacious colors with it!

Terminal can handle more than simple characters with special instructions.

Ruby

In ruby, you've the wonderful but simple rainbow

sudo gem install rainbow

It's easy to use :

puts "hello " + "colored".color(:red) + " world"

If you are an adventurer, you can do more. Wikipedia tells you everything about ANSI escape code. CSI in ruby is \e[.

With such tools, you can do the extraordinary spinning fan effect :

1000.times do |i|
  print "\e[3G\e[1m"
  print %w{ | / – \\ }[i % 4]
  print " \e[0m \e[8G"
  STDOUT.flush
  sleep 0.5
end

It's cute as a regex.

You put the cursor in an absolute position (third place)
You wont red color
You draw a fan
No more color
Go to hell, cursor, I wont to see my fan

In ruby, when you puts, flush is implicit, but not with print .

No rake user can live without this gem.

The rest of the world

Every language got a library for that. I have trying colors for nodejs and colorama for Python

Rendre DotClear plus joli avec php5.3 fpm et lighttpd

Mathieu Lecarme — Wed, 06 Oct 2010 20:34:00 +0200

Bon, ok, c'est de la beauté intérieur. Mais ce sera moins gourmand en RAM et plus véloce qu'avec le classique Apache. Voici les informations pour déployer un Dotclear sur un lighttpd avec un PHP 5.3.3.

Lighttpd

J'ai choisi lighttpd pour arrêter de me battre avec les fichiers de conf d'Apache. Depuis, je suis devenu accro, mais Nginx est aussi tentant, plus moche que lighty, mais plus vivant.

Deux grosses différences avec Apache, il n'y a ni mod_php ni mod_rewrite. Tant mieux.

Sur Ubuntu, le fichier de conf de lighttpd est découpé en petit morceau (à la mode apache). Il faut donc créer un fichier en .conf dans le dossier /etc/lighttpd/conf-available/ puis de faire un lien symbolique vers /etc/lighttpd/conf-enabled/

On commence par réclamer des modules :

server.modules += (
                "mod_rewrite",
                "mod_fastcgi"
                )

On peu ensuite attaquer le virtualhosting

$HTTP["host"] == "blog.garambrogne.net" {
        static-file.etags = "enable"
        accesslog.filename = "/var/log/lighttpd/blog.log"
        server.document-root = "/data/www//blog.garambrogne.net"
        fastcgi.server = ( ".php" => (
                ("host" => "127.0.0.1",
                "port" => 9000
            )
        ))
        url.rewrite-once = ( "^/(index\.php|admin|public|images|themes).*" => "$0",
                "^/([^?]*)(?:\?(.*))?" => "/index.php?$1&$2"
        )
}

Il faut reconnaitre que c'est moins moche que du Apache, non? L'idée de base est de définir un bloc via une clause, puis d'y définir des réglages. La conf est bien lisible, il y a juste deux points à remarquer. PHP est sur un serveur fastcgi. Pour avoir de jolis urls, il y a réécriture. On laisse tranquille les urls statiques, pour les autres, on réécrit l'url en mettant index.php au début. C'est tout. On profite des réglages par défaut de lighttpd.

Les réglages à faire dans Dotclear sont simple. Dans Paramètres du blog :

Dotclear rale, mais ça passe bien.

PHP fpm

J'avais déjà écrit un billet sur php-fpm : Apache est mort, depuis, ça a évolué, fpm fait parti de php depuis la version 5.3.3.

C'est en compilant des applications que l'on se rends compte du service rendu par les packages. Il manque forcément des morceaux, ça prends des plombes, et il faut recommencer à chaque mise à jour. Mais en compilant son application, ON EST MODERNE, ON VOIT LE FUTUR. La doc de fpm est suffisante. Il y a une pétouille sur Ubuntu, il n'arrive pas à découvrir les lib jpeg et png. Sur une Ubuntu un peu vieille, il faut aussi se fader la compilation de libevent, ce qui ce fait sans douleurs. Si on ne fait pas attention avec les options de configuration de php, on peut tomber sur des bugs qui n'existent pas, comme la conversion des images qui fonctionnent sur du jpeg mais pas sur du png. Dotclear, par exemple estime qu'il est impensable de ne pas avoir le module mysql alors que je pensais que mysqli était le drivers par défaut.

./configure  --prefix=/opt/php533 --enable-fpm \
--with-fpm-user=www-data --with-openssl \
--with-fpm-group=nogroup --disable-cgi --with-zlib \
--with-pcre-regex --with-bz2 --with-curl --with-gd \
--enable-mbstring --with-mysqli --with-pdo-mysql \
--without-pdo-sqlite --enable-sockets --with-tidy \
--enable-zip --with-pear --with-libevent-dir=/opt/libevent \
--enable-exif --with-jpeg-dir=/usr/lib/ \
--with-png-dir=/usr/lib/ --with-mysql

Voilà, avec ça, le futur est à portée de main. Ca permet de valider le fait que Dotclear est pas codé avec les pieds, le passage en 5.3 se fait sans douleur, et il n'est pas marié avec Apache.

rebar is not ready for production

Mathieu Lecarme — Wed, 21 Jul 2010 12:29:00 +0200

When erlang cames to the web, it leaves all its panzer stuff from phone company. No Makefile, no hotupdate. Just a naked erlang. Naked with one tool : rebar, the Make for erlang web developper.

Rebar is the apple in heaven. Erlang bites it. First rebar was made as a compilation tools. You just do ./rebar compile, and it compiles new things, erlang files, C files, wathever can be compiled. Then, erlang saw that each project wasn't alone in the galaxy. So dependency appears. ./rebar get-deps. Heavean is now lost. Dependency can handle differents VSC tools. Basho stuff use mercurial, other stuff use git. But I don't wont to depend on master branch, I wont release, I wont determinist dependences. Releases means http download, I don't wont to install mercurial+subversion+git for compiling erlang product.

Dependencies uses regex pattern for version matching. I never see it working well, if you don't wont to kill some swedish kitten, just use .* pattern, relax yourself, and pray.

I don't wont to fork every erlang's github project to be able to use it. I just wont simple tools like ruby gem or erlang pip.

I wont to use erlang in production, not only as proof of concept.

Autopsie de la grenouille

Mathieu Lecarme — Thu, 13 May 2010 19:01:00 +0200

La réponse à la question : est-ce que ça ce mange?

Le glaçage est plutôt dur, il faut un bon couteau pour ne pas tout écraser. Le cake est bien conservé dans sa gangue, mais l'ensemble est extrêmement sucré, comme on pouvait le prévoir. Ca rends la langue verte et gober des yeux de grenouille plait aux enfants.

En consommant avec modération, ça ce mange!

Dissection de grenouille

Mathieu Lecarme — Sun, 09 May 2010 22:00:00 +0200

La making of du gâteau grenouille.

La base de travail est un cake traditionnel (au raisin sec trempé dans le thé), qui a eut le temps de sécher, pour faciliter la découpe. La pâte d'amande permet de modeler les formes, et d'affiner les formes un peu brut du cake. Les pattes, le dos, les yeux, la couronne sont en pâte d'amande. Il faut de toutes façons recouvrir tout le cake, le glaçage n'étant pas compatible avec les miette du cake. On peut utiliser de la confiture d'abricot délayé et passé au tamis pour faire de la colle. Pour le grenouille, le travail a été fait sans colle. Le modelage en pâte d'amande donne les volumes, les détails seront fait en glace royale.

Pour avoir de jolis couleurs, la teinture dans la masse est la meilleur solution. Les colorants alimentaires modernes sont maintenant des gels, ce qui permet d'avoir des couleurs dense, sans délayer le mélange. Le glaçage royal est un mélange de blanc d'œuf et de sucre glace. J'ai ici testé le blanc d'œuf, plus hygiénique. Pour le gout, un peu d'eau d'orangé. Il est assez difficile d'obtenir la texture adéquat, et en plus ça sèche relativement vite. Les quantité de sucre glace que l'on doit utiliser font assez peur. Mais bon, c'est anglais.

. Le rouge de la bouche lui donne un air classieux. Le blanc des yeux est impressionnant, il donne l'impression que la pâte d'amande est sale.

Il faut appliquer la couleur par plaque, mais les coutures sont facile à faire quand le glaçage est frais. Tout le sport consiste à faire suffisamment de couleur pour la zone choisi, il est impossible de refaire précisément une couleur.

La couleur est fini. Aprés 24h de séchage, on pourra peindre pour amener de la matière, et des détails, comme les pupilles.

Grenouille

Mathieu Lecarme — Sun, 02 May 2010 19:36:00 +0200

Un gateau à l'anglaise. Glaçage royal sur une base de cake.

Les anglais ont une approche curieuse de la patisserie. Le cake qui sert de base est préparé une semaine à l'avance, pour avoir le temps de sécher. Le gateau est de taille classique, moins de 20cm de diamètre. Ensuite, pour mettre en place les formes sur le cake sculpté, de la pate d'amande. 500g. Les anglais ne sont pas raisonnables, mais il faut recouvrir d'une fine couche tout le gateau pour éviter un massacre avec le glaçage. Le glaçage traditionnel se fait avec un blanc d'oeuf et du sucre glace. J'ai testé le blanc d'oeuf en poudre, ce qui évite les risques de salmonelles (et de manger de la crème anglaise/mayonnaise avec les jaunes d'oeufs). Pour obtenir une texture manipulable, et suffisamment de volume, il y a l'équivalent d'un blanc d'oeuf et 400g de sucre glace. Les anglais ne sont pas raisonnables. La teinture est faite dans la masse, avec de la teinture en gel. Le lendemain, un peu de peinture pour ajouter des détails. Encore une journée de séchage pour perdre l'aspect brillant. Il faut donc s'y prendre 10 jours à l'avance. Une fois blindé de sucre, le gateau devient étanche et peut donc se conserver tranquillement à l'abri de l'air.

Le Wifi est mort

Mathieu Lecarme — Sun, 11 Apr 2010 19:23:00 +0200

Le péché d’orgueil l’a tué. L’idée de se débarrasser des fils est séduisante, mais utopique.

Pour le réseau, c’est faisable, et c’est fait, les téléphones cellulaire le démontre de manière écrasante. Sauf qu’un ordinateur a besoin de deux fils à la patte, le réseau, qui est négociable, et l’énergie, et là on est rapidement dans le n’importe quoi. Les batteries actuels commencent à peine à tenir une journée, elle contienne autant de patate qu’une petite centrale nucléaire, et de toutes façons, tôt ou tard, et plutôt au mauvais moment, il va falloir recharger. Le problème est le même pour les voitures et les appareils photos. Et les souris. Et les téléphones. L’arrivée des prises 220V dans les secondes classes du TGV sont un réel progrès. Il nous faut du bon gros nucléaire sous la main. L’homme connecté est comme le poisson volant, il pense être un oiseau libre, et plouf, de nouveau dans l’eau. Essayer d’enlever le câble réseau est donc tout simplement prétentieux. Mais on peut essayer. Les ondes radios fonctionnent plutôt bien, et les militaires qui les trouvent moins jolis qu’avant libèrent des fréquences. Un fil va d’un point A à un point B, alors que l’onde radio part dans tous les sens, ce qui est une mauvaise idée pour la confidentialité. Donc, il y a de la place pour faire les fous, le débit augmente de façons progressive, avec ses jolis lettres a, b, g, n. Il y a dut avoir des lettres mortes en chemin. Mais ces petits trous lexicographiques ne sont que pinaillage, le vrai soucis est la norme permettant de sécuriser tout ça. La première norme, WEP est parti sur une super bonne idée, plutôt que de proposer un mot de passe classique (le nom de son clebs, la marque de sa voiture), ils ont préférés imposer un nombre hexadécimal, de 0 à 9 et de A à F. C’est tellement plus sexy à taper, surtout quand il y en a 30. C’est grâce à cet artifice bien chiant que l’on s’est retrouvé avec des caisses enregistreuses wifi dans des supers marchés qui émettait en clair. Pour les objets électroniques, c’est super pratique de rentrer ce numéro de sécu avec une télécommande ou autre astuces sans clavier. De toutes façons, le WEP s’est avéré être une passoire, en provoquant quelques erreurs dans la communication il est possible de forcer la chance et de voir passer deux fois le même paquet chiffré et d’en déduire la clef. En redémarrant son ordinateur sur un simple CD Linux il est possible de trouver une clef sur le routeur du voisin en quelques heures. Ca a même dut s’améliorer depuis. Donc, le WEP est ni pratique, ni efficace. La tentation de le mettre à la poubelle est grande, mais il existe plein d’appareil électronique qui ne connaisse que le WEP, et qui ne pourront jamais être mis à jour. Orange, dans sa grande sagesse à décidé de rester sur du WEP, en rajoutant une contrainte, il faut enregistrer la carte réseau dans le routeur. Il faut donc se mettre à quatre pattes à coté du routeur, recopier un numéro de sécu, se rappeler que c’est normal si ça ne marche pas, se connecter via un câble, aller sur la page du routeur (devines où elle est), trouver le mot de passe pour rajouter sa machine, recopier l’adresse Mac de sa machine (aussi moche qu’une clef WEP, et deviner où trouver l’info), et enfin ça marche. Enfin non, les DNS d’Orange sont daubés, il faut en prendre des autres. Voila, c’est la démarche que Madame Michu doit faire utiliser son netbook sur sa terrasse. Le wifi est mort. Les entreprises ne veulent pas d’un réseau ouvert aux quatre vents, c’est toujours énervant d’avoir des visiteurs qui repartent avec une proposition commercial d’un client commun. Donc, pas de WEP, le wifi est mort. Vexé par ces gens qui pinaillent et qui n’aiment pas taper des numéros de sécu, la norme WPA est apparu, laissant en plan les vieux équipements. Avec le WPA on retrouve des mots de passe qui veulent dire quelque chose, et une sécurité mieux fichu. C’est mieux, mais trop tard, on continue d’assimiler wifi et problèmes bien pénible. Le seul espoir est la flemme insondable de l’admin réseau. Plutôt que de tirer un câble et de mettre un joli switch, hop, on met une borne wifi, le mot de passe sur un postit, et démerdez vous. Ca va pas assez vite ? Quoi, un wifi à fond, c’est 20 fois plus lent qu’un câble ? Pas de soucis, on a inventer le n, qui donne le meilleur de lui à 2 mètres. Deux mètres, à deux mètres c’est compliqué de tirer un câble ? La loi de l’entropie s’applique à tout, et particulièrement aux fichiers, et de manière bien plus rapide que le wifi, les fichiers accumulent plus de gras qu’un adolescent au MacDo. Donc, si vous rester dans l’outil du travailleur chat/mail/web, ça passe, si vous bossez avec des fichiers, c’est mort. Le wifi est mort. Comme vous êtes quelqu’un de branché, vous fréquentez des gens branchés, et qui du coup veulent se connecter quand ils sont chez vous. Deux méthodes, le non ferme et définitif, le câble réseau qui traine, ou le postit sur la borne wifi. Le wifi est mort. Des acharnés sont arrivé à gérer ce point, partager du wifi sans postit. La connexion est ouverte à tous les vents, mais filtré, on ne peut faire que du web. On tombe sur une page par défaut qui demande de s’authentifier. Une vrai question, et non le classique « devines tout seul pourquoi ça ne fonctionne pas ». Pour accéder tranquillement au web entier, on peut soit donner de la thune, soit échanger un peu de bande passante, on installant un système de partage similaire chez soi. Tu partages, je partage, c’est la logique de Fonera. Bon, cette logique d’échange sans thune énerve un peu SFR qui était arrivé à noyauter tous les hôtels de France avec des tarifs honteux. Ils se sont depuis vengé avec les forfaits data pour les téléphones portables. Le wifi est maintenant sur toutes les modem ADSL, sauf que la télévision a suivi très rapidement, et ensuite la haute définition. Sauf que la gourmandise de la haute définition est énorme, ça passe plus par du wifi, si vous avez un mur en béton armé, c’est mort, il va falloir vous contenter des timbres postes de youtube, dommage. Ou utiliser votre réseau électrique, avec le CPL. Avantage câble. Le wifi est mort. Le wifi, qui ne nécessite pas de tirer des câbles tout moche devait sauver les villages isolés privé d’ADSL, avec sa variante king size : le wimax. Bon, Nokia et Cisco ont fini par bazarder leur jouets prévus pour le wimax. Le Wimax est mort, mais comme personne ne l’a vu, personne ne le pleurera. Plus petit, mon téléphone gère le wifi, mais le wifi n’a jamais été conçu pour tourner sur des trucs aussi petit, il est pas taillé pour, car le wifi, ça mange comme un adolescent teigneux en pleine croissance. On ne peut pas remplir une étagère de pâte sur un téléphone, trop petit. Le wifi est mort.

Bon, je suis une grosse flemasse, et j’écris ce billet sur un portable, connecté en wifi, je râle juste pour trouver une prise de courant, par ce que la batterie est morte (et encore, je ne plains pas, c’est une batterie amovible, je ne serais obligé d’abandonner mon Mac 15 jours pour que des hollandais lui recalamine le pot).

Le wifi n’est pas mort, mais il ne gagnera jamais.

Apache est mort, et c'est PHP qui mettra les clous dans le cercueil

Mathieu Lecarme — Fri, 02 Apr 2010 18:28:00 +0200

Un serveur web ne fait pas grand chose, mais il doit le faire souvent, avec plein de personne. Le protocole http fonctionne en mode déconnecté, chaque page est indépendante des autres. Des astuces (les cookies) permettent de simuler une connexion continue le temps d’une session. Le gros du travail d’un serveur web est donc de gérer un maximum de connexion, et de servir les pages, sans perdre de temps.

De manière traditionnel, on utilise PHP comme module pour Apache, PHP étant alors dans Apache. Le premier Apache, pour gérer les accès concurrents se contentait de créer des processus fils, en gérant un petit stock d’avance pour ne pas avoir à tout créer d’un coup, en cas de pic. PHP, qui est un petit noyau avec plein de modules se contentant d’emballer des bibliothèques existantes s’est épanoui dans cette environnement. C’est cette idée d’emballage simpliste qui explique des chose aberrantes comme l’ordre des arguments change de logique selon la librairie que l’on utilise.

Le problème de cette approche est que créer des fils est couteux, et consomme pas mal de mémoire. L’évolution est de travailler avec des threads, ce qu’a rapidement fait IIS, le concurrent de chez Microsoft. Sauf que personne est capable de garantir que PHP est thread safe (ce qui ce passe sur une page peut mettre le bazar ce qu’il ce passe sur un autre). Le coeur de PHP est propre, mais pas les modules, et il existe plein de modules non officiels (et folkloriques, comme celui pour repérer des images similaires, créer pour bannir des photos à la con, sur les skyblog). Donc, Apache 2 propose fièrement plusieurs moteurs pour gérer la concurrence. Concrètement, il n’y en a que 2 d’utilisable, un à base de fork, un autre à base de thread. PHP n’aime pas les threads, donc, on reste au point de départ, on fork. Le soucis est qu’un serveur web sert aussi du contenu statique, comme les images, les CSS, le javascript. Une page web dynamique, c’est plutôt mou et gourmand en RAM, on ne pas en servir de grosses quantités simultanément. Par contre, pour les fichiers statiques, il n’y a pas d’excuses, si il est lu souvent, l’OS le laisse en RAM, et il est rapide comme l’éclair, pret à s’envoler. Là, le modèle du fork tire la langue.

C’est ainsi que sont apparus les serveurs légers, au début prévu pour l’embarqué, ils ont rapidement ratatiné les performances des anciens serveurs. L’idée de base est simple : « on ne peut pas aller plus vite que la musique ». Un ordinateur n’a que quelques processeurs, et c’est souvent le temps d’accès du disque dur qui pénalise les performances. Le modèle du thread est très pratique pour faire des applications réactives (l’interface bosse pendant que l’application travaille, par exemple), mais son cout est non négligeable, et de toutes façons, créer un thread pour attendre que le disque dur lise un fichier, c’est gâcher. Donc, pas de thread, et encore moins de fork. Un seul thread, enfin, un par processeur va faire le travail. Du coups, on limite les problèmes d’accès concurrents et la communication inter thread. Pour que l’application reste réactive, on inverse la logique, on demande une tache, et quand elle prête, on envoi la réponse, on attends pas. On passe à un modèle événementiel (on parle aussi de callback, « don’t call me, I’ll call you back »), où le noyau prévient quand une tache est prête. Chaque OS propose un ou plusieurs modèles différents, et il existe des librairies pour emballer tout ça, comme libevent. Un serveur web moderne utilise donc un modèle événementiel pour servir un maximum de données, sans écrouler l’ordinateur en faisant monter la charge honteusement. Les premiers serveurs ont été utilisé conjointement à Apache, pour servir les pages statiques, laissant à l’ancêtre le PHP.

En plus d’être mou des genoux, Apache est pénible à configurer avec sa syntaxe pseudo XML, et une fois que ça fonctionne, mieux vaut pas aller l’embêter. Ca fait une deuxième raison d’aller voir ailleurs si l’herbe est plus verte. Il ne manque plus qu’une technique pour lui coller le PHP dans les pattes, pour entrer pleinement dans le XXI° siècle. La première approche pour utiliser conjointement un serveur web et un serveur d’application qui ne soit pas embarqué dans le serveur web est d’utiliser un proxy. Les requètes dynamiques ne faisant que transiter par le serveur web pour arriver jusqu’au serveur d’application. C’est comme ça que fonctionne les applis JEE, Ruby On Rails et autres applications plus ou moins exotiques. Ca manque un peu d’optimisation, mais ça le bon gout de fonctionner. Le protocole HTTP qui est plutôt tolérant est parsé deux fois, une fois par le serveur web, une deuxième fois par le serveur d’application. Pour accélérer le shmulblik, il est possible de prémacher le travail pour le serveur d’application et de lui donner des informations plus précises. Après divers propositions de protocole, c’est le fastCGI qui semble avoir gagné. Donc, il faut un serveur FastCGI pour PHP. Le premier fut Spawn-fcgi crée par les développeurs de Lighttpd. Traditionnellement, et par ce que la plupart des modules PHP sont codés comme des cochons avec des fuites de mémoires, chaque page lit le fichier PHP, l’exécute puis jette tout à la poubelle, pour recommencer à la page suivante. C’est beaucoup de gâchis, mais avec la limitation de temps d’exécutions et la limite de mémoire, ça permet d’avoir des serveurs qui tournent pendant des siècles, sans soucis. Essayer de faire pareil avec un serveur JEE, juste pour rigoler. Des modules PHP permettent de conserver une version parsé du code, pour ne pas recommencer cette étape à chaque fois, mais les serveurs FastCGI vont plus loin, ils gardent le même PHP pour plusieurs requêtes. La tradition préconise 500 requêtes, ensuite, ça sent trop fort des pieds, on balance tout et on repart sur du propre. Spawn-FCGI fait bien le travail, mais a un peu de mal avec les PHP qui partent en live ou qui fuient trop. Il est donc conseillé de l’emballer avec daemontools, qui le redémarre en cas de drame. Cette solution est inélégante. Récemment est apparu PHP-FPM, qui nous vient de Russie, tout comme Nginx, la star des serveurs webs monothreads. Le projet plait tellement qu’il sera livré avec PHP 5.4, et il est actuellement disponible sous forme de patch pour PHP 5.2 et 5.3. Avec ce serveur, on choisit un nombre de worker (le plus simple est de calculer leur nombre en fonctionne de la RAM disponible, 10 workers avec 128Mo, ça fait 1280Mo de RAM pour PHP). Devant, le serveur web bataille comme un grand avec les fichiers statiques, et confie le dynamique à l’un des workers, en gardant le même pour une session, ou en distribuant au maximum pour que tout le monde travaille. Il est possible de mettre les deux applications sur deux machines différentes, et même d’empiler les serveurs FastCGI derrière un serveur http, créant ainsi une grappe. Pour gérer le cache, il faut alors passer par un serveur de cache, dans lequel tous les workers vont piocher, sans aller embêter la base de donnée, elle aussi commune. Le plus célèbre est Memcached, mais il existe des alternatives plus vicieuses, comme Redis. PHP-FPM corrige des pétouilles dans le PHP améliorant son usage de multiplie fois, il surveille aussi les crashs, tuant les workers qui se sont vautrés, et propose même de gérer un redémarrage polie, sans tuer personne, en attendant que les processus soit terminés (graceful en anglais). Pour l’instant, le gros du travail est fait dans la branche 5.3, mais des changements dans l’API empêche des applications bien connu de fonctionner (le module imagecache de Drupal par exemple), qu’il faut soit patcher, soit rester sage et se contenter de la branche 5.2. Ce qui surprends un peu au début, c’est que l’on perds le confort des paquets tout prêt, il faut compiler, et recommencer à chaque mises à jour. Bien sur, on oublie des modules (oh, pas de jpeg dans mon gd, comme c’est pratique), et on doit recompiler. On comprends par contre tout l’intérêt de PECL qui permet d’avoir APC ou uploadprogress sans s’embêter. Une fois installer, on se retrouve avec sa même application web, mais en plus joli. On bouffe moins de RAM, en cas de forte charge on sert moins de page, mais le serveur reste réactif. Comme on ne mélange pas les torchons et les serviettes (le statique et le dynamique), on sait exactement combien de workers vont travailler, et du coups combien de connexions Mysql on va avoir, qui nous remercie d’ailleurs, avec peu de requêtes simultanés, il bosse d’autant mieux.

Cette configuration permet aussi d’utiliser efficacement des petits serveurs sans tout saturer pour servir un pauvre blog que peu de monde lit. Les hébergements léger comme les services 1 tranche sur du virtuel, ou des services à base d’Atom (dedibox, OVH-RPS…) prennent toute leur valeur avec ses services léger. Les microserveurs comme les sheevaplug vont aussi se régaler avec ce genre de serveur. Ils feront à priori parti de la prochaine vague après la 2.0 et ses bannissements, pour passer à des architectures distribuées.

Donc, si vous avez une application PHP qui sait utiliser du cache distribué, vous n’avez aucune excuse pour vous coltiner encore Apache. Il faut passer à un serveur moderne, Lighttpd, Nginx, Cherokee, c’est une histoire de gout, mais le XXI° est là, Apache va pouvoir passer à la case musée rejoindre Netscape, IE6 et autres logiciels qui ont marqué leur époque. Même son logo il est pas beau.

Prochaine étape, uploader des fichiers sur une grappe de serveur.

Faire discuter Drupal

Mathieu Lecarme — Sun, 28 Feb 2010 10:57:00 +0100

Drupal se qualifie lui même le plombier des communautés. Le web est asynchrone, ce qui est plutôt embêtant pour une interaction rapide et direct entre plombiers. C'est là que Jabber peut venir à la rescousse, avec sa variante web, le BOSH, dans le module Drupal-Strophe

Jabber pour le web

Jabber et son protocole xmpp est prévu pour fonctionner sur sa propre connexion réseau, qui reste ouverte le temps de la discussion. Le web, lui, passe son temps à ouvrir et à fermer ses connexions, et une page web, pour des raisons de sécurité, ne peut pas ouvrir une connexion permanente pour faire le fou avec.

Jabber, propose une variante de son protocole pour travailler sur une connexion HTTP, ce qui lui permet de passer les firewalls d'entreprise qui bloque tout sauf le web (port 80), et d'être utilisable depuis du javascript, qui utilise ajax pour se connecter au serveur. L'acronyme de ce protocole a un nom de perceuse : Bosh. Une bibliothèque javascript permet de l'utiliser de manière presque simple : Strophe. Il existe plusieurs serveur xmpp, j'utilise ejabberd qui est fonctionnel et efficace, il propose du BOSH par défaut, et une authentification externe, les deux fonctions nécessaire pour le coupler avec Drupal.

Service

Ajax ne fonctionne que sur le même domaine que la page web, pour des raisons de sécurité. Drupal ne fait pas de BOSH, mais il suffit d'utiliser la fonction de proxy du serveur http (apache, lighttpd ...), pour confier la partie BOSH à Ejabberd.

Authentification

Le premier problème est d'authentifier les utilisateurs. Ejabberd propose un système assez bourrins pour proposer une authentification avec un script extérieur, dans n'importe quel langage, c'est assez facile de voler du code php pour authentifier sur un référentiel utilisateur Drupal. Le soucis est que le code javascript est lisible par tout le monde, et qu'il faut soit demander à l'utilisateur son mot de passe pour initier la connexion, soit stocker le mot de passe en clair, ce qui est une mauvaise idée pour la sécurité. Pour gérer ça, il suffit de créer un mot de passe temporaire, que drupal va confier au javascript, qui lui va lancer l'authentification. C'est le rôle de ejabberd-auth.

Prebinding

BOSH utilise l'équivalent d'un cookie pour identifier une connexion lors des échanges HTTP. Il est possible d'utiliser ces informations pour éviter de recommencer le cycle d'authentification à chaque fois. Il est même possible de confier à Drupal l'établissement de la connexion, avec l'authentification, puis de demander à javascript de se réattacher à cette connexion. Pour l'instant, ça ne fonctionne pas dans le module.

Drupaleries

Modules

Le module est découpé en sous module. Un module parent, qui s'occupe de la connexion et des couches basses : XMPP BOSH, un module pour la chatroom : XMPP Multi User Chatroom, et un module pour discuter avec une personne : XMPP Chatroom .

Ajouter des actions

Drupal permet de passer des variables depuis le PHP vers le javascript, et offre une procédure permettant de déclencher du javascript quand le DOM est chargé, et quand les variables fournits par Drupal sont disponibles. Un système similaire permet d'ajouter des actions avant que l'objet xmpp se connecte.

XMPP est utilisé pour discuter, mais on peut le voir aussi comme un outil beaucoup plus générique, il permet de transmettre des messages entre des personnes et des groupes. La demande de discussion direct est un exemple d'usage non prévu par XMPP.

sshfs is the best Mac web developper tool

Mathieu Lecarme — Thu, 21 Jan 2010 19:59:00 +0100

OSX is a nice operating system for everyday life, but you'll never use it as a developpement plateform. Even Apple doesn't do that.

Okay, Apple is UNIX, just like Linux, and you've got MAMP and Macports, but it's not the same thing. For a nice sandboxing, every project got its own room, you can use virtualisation (virtualbox is nice and free), one box for each project, with snapshots. You can even use a real linux server, bare metal or virtualized (xen, openVZ ...).

There is only one true way to use a linux server : ssh. With ssh you can talk with your box, and sending files, what else can you need? First thing to do is to put your public key on the server, passwords are boring.

I Don't like Terminal, but latest versions are usable, iTerm is more geek. For browsing distant files, CyberDuck is the ultimate tool, you can even edit distant file. But it's not as easy as in local. The über utimate tool is sshfs. A static binary is provided, if you don't wont to fight with MacPorts.

cd /tmp
mkdir toto
sshfs-static-leopard monserveur:/var/www toto
cd toto

toto folder is now a mount point of your server. You can do what you wont with it. Browsing and manipulating with the Finder, editing with your nice editor, and more geek, you can use versionning with mac tools or linux tools. You can mix. Git or SVN works very well in a mount point, so Versions or GitX can be used.

Frangipane

Mathieu Lecarme — Mon, 11 Jan 2010 18:33:00 +0100

La frangipane est une galette typiquement française, et encore, moitié nord, au sud, la brioche au sucre est préférée pour féter les rois mages.

Pour 10-12 personnes

2 x 250g de pâte feuilletée
300g de poudre d'amande
3 oeufs
100-125g de beurre
150g de sucre
un peu de rhum

La qualité de la pâte feuilletée est primordiale. On peut la commander sur Internet (comme François) ou chez un fournisseur de patisserie, comme G Detou, mais c'est par 3kg, ou demander gentiment à son boulanger, sinon, Picard.

La garniture

Mettre la poudre d'amande dans un plat à tarte, et mettez au four en position grill. Régulierement, quand c'est coloré en brun et non en noir, remuer avec une fourchette. Au bon d'un moment, on obtient une poudre d'amande grillée.

Réservez un jaune d'oeuf pour badigeonner la tarte. Mélangez le beurre très mou, presque fondu, avec le sucre, jusqu'à ce que ça blanchisse. Ajoutez progressivement le reste des oeufs (3 blancs, 2 jaunes). Mouillez avec un peu de rhum. Attention à ne pas rendre le mélange trop liquide, on doit pouvoir en faire une couche épaisse.

Assemblage

Etalez les deux pâtes et laisser poser au moins 10 minutes. Rond c'est plus joli, carré, c'est plus rentable. La quantité de pâte est suffisante pour faire le plus grand possible qui tient dans un four (de taille normal, ni mini, ni modèle pour cochon de lait). Il faut reserver 2cm sur le tour. La quantité de frangipane est trés généreuse, ça fait une couche épaisse. Mouillez le bord avec de l'eau, et mettez la deuxième pâte pour couvrir. Il faut bien appuyer pour l'étanchéité. A la fourchette, ça fait joli, mais au doigt ça marche aussi. Badigeonnage du jaune d'oeuf avec un peu de lait sur le dessus, c'est ce qui donnera la couleur et le brillant. Il est possible de tracer des dessins sur le dessus avec un couteau qui coupe bien, mais sans traverser! Pour éviter les phénomènes volcaniques, il est possible de mettre une cheminée en papier sur le milieu de la galette. Il faut laisser poser 20 minutes avant d'enfourner, pour que la pâte feuilleté se remette de ses émotions. Préchauffer le four à 200°C. 30 minutes de cuisson en surveillant de temps en temps.

Bûche au chocolat

Mathieu Lecarme — Fri, 01 Jan 2010 18:27:00 +0100

C'est en fait un simple gateau roulé, avec une ganache comme garniture. Pour être sûr que la dose soit suffisante, un nappage au chocolat est ajouté.

Ganache

450g de chocolat
25cl de crème fleurette
1 gousse de vanille

Le chocolat est haché, avec un grand couteau sur une planche. La crème bouillie. La gousse fendue. Avec un couteau, on racle les petites graines noirs pour le mettre dans la crème. Les batons aussi. 5 minutes d'infusions. Nouveau bouillon pour la crème. On enlève les batons. La crème chaude est versée sur le chocolat, et le tout est mélangé avec un fouet. Si les bouts de chocolats sont suffisamment petits, ils fondent dans la crème, sans laisser de bouts durs. Le fouet permet d'obtenir une ganache bien lisse.

Il faut être synchronisé avec la préparation du biscuit, la ganache doit être liquide pour le garnir. Il est possible de la ramollir au bain marie.

Biscuit

3 oeufs
1 pincée de sel
120g de sucre
30g de farine
50g de maïzena

Le biscuit est simple, tout le sport est dans la cuisson, puis l'enroulage. Il est plus sage de s'entrainer avec la version gateau roulé à la confiture, si on casse tout, on a toujours des biscuits cassés avec de la confiture, ce qui n'est pas très grave pour un gouter. Pour une occasion justifiant une buche, mais vaut avoir essuyé les plâtres avant de se lancer.

Séparer le blanc des jaunes. Mélanger le sucre avec les jaunes jusqu'à ce qu'il blanchisse. Incorporer progressivement la farine et la maïzena. Battre les blancs en neige avec la pincée de sel. Incorporer délicatement les blancs au reste de la pate. Mettre sur une plaque de cuisson, le four est préchauffé à 150°C. Il faut 15 minutes de cuisson. En posant son doigt sur le gateau, on doit obtenir une trace qui se résorbe, il est légèrement coloré. Mettre sur le gateau un torchon mouillé puis essoré. On peut commencer à rouler l'ensemble, avec le torchon au milieu, si tout ce passe bien, ça ce roule sans coller et sans ce briser. Attendre 2 minutes le temps que le biscuit s'humidifie. On peut commencer à le dérouler pour l'enrouler de nouveau, mais avec la ganache cette fois ci. On déroule d'un coté pour enrouler de l'autre, un peu comme un parchemin. Dés que c'est fini, le mettre rapidement sur un plat adéquat, par ce qu'une fois le glaçage appliqué, il ne pourra être manipulé.

Nappage

200g de chocolat
20cl de lait
30g de beurre
30g de glucose

Même tactique que pour la ganache. Le chocolat est haché, le lait bouilli. Le lait chaud est versé sur le chocolat est versé sur le chocolat haché, mais à la spatule, pour éviter au maximum d'incorporer de l'air. Le beurre et le glucose fondent trés vite dans ce mélange. Au début, l'aspect est trés liquide, mais au bout de quelques heures à température ambiante, l'aspect devient brillant et solide.

Pour décorer, j'ai disposé des noisettes grillées puis émondées et enfin caramélisées.

Il manque les petits nains en plastique sur le dessus. Il faut que je trouve un fournisseur de bon goût.

Maintenance Drupal pour les feignants

Mathieu Lecarme — Sat, 12 Sep 2009 13:32:00 +0200

Drupal permet de faire des sites rapidement et simplement, mais une fois mis en place, il nécessite un minimum d'attention. Les mises à jour sont régulière, et il est sage de ne pas laisser un site web avec des failles officielles.

Drush

Drupal propose une interface web très complète, mais pour effectuer des taches répétitives, c'est assez pénible. Pour pouvoir faire un ensemble de taches en ligne de commande, à la main ou via un cron, il existe le module Drush (comme Drupal Shell). Drush est fourni avec un certain nombre de fonctions, et il est possible d'en crée de nouvelles.

Sauvegarde

La première chose à faire est d'avoir une sauvegarde régulière de son site. Snapshot permet de faire des sauvegardes simplement, en bloquant la base de donnée en lecture seul un minimum de temps. Il faut bien penser à aussi sauvegarder les fichiers uploadés. Snapshot permet de prendre un instantané de la base de donnée, il faut le coupler à une sauvegarde distante, en cas de crash violent du serveur.

Maintenant que l'on a une sauvegarde fiable, il est possible de faire des mises à jour brutal, et de restaurer une sauvegarde si ça ce passe mal. Dans tous les cas, avoir une sauvegarde fiable est toujours utile.

Mise à jour

Drupal envoit un mail au webmaster quand une mise à jour de sécurité est disponible. Des mises à jour mineurs arrivent régulièrement, mais sans râler, on peut les appliquer quand on veut.

Le coeur de Drupal

La mise à jour de Drupal lui même est un peu pénible, mais avec un minimum d'attention, cela ce fait sans problèmes. Il faut passer le site en maintenance. On renomme le dossier actuel du site, et on installe le tout nouveau Drupal avec l'ancien nom. Il faut ensuite recopier de l'ancien vers le nouveau les dossiers sites/all/modules , sites/all/themes et sites/default/files ainsi que le fichier sites/default/settings.php. Il faut ensuite aller sur la page d'update (ou avec un drush update) pour appliquer les éventuels mises à jour de la base de données.

Les modules

Drush, dans ses fonctions de bases permet de mettre à jour les modules. Depuis la racine du site, il faut lancer la commande suivante : drush update Drush affiche un tableau qui liste tous les modules, leur version actuelle, la version à jour, et son état. Pour les paquets nécessitant une mise à jour, Drush propose de les mettre à jour, il suffit de lui répondre yes pour qu'il mette de coté l'ancienne version puis installe la nouvelle.

Voila, avec un minimum de méthodologie, la mise à jour prends moins de 5 minutes. Pour l'instant, je n'ai pas encore eut de mise à jour malheureuse, qui casse tout. A part panels, qui était en beta.

Normandie

Mathieu Lecarme — Wed, 26 Aug 2009 19:25:00 +0200

Sous le ponton qui avance dans la mer, à Dieppe.

Le panoramique est à 360°, on est dos au continent, en face, le ponton, puis la mer et l'Angleterre, au delà. A gauche, en plein soleil, la plage de galet avec des gens qui se baignent dans l'eau froide du mois d'aout, à droite, de l'autre coté, donc, le port avec un ferry qui attends pour traverser.

Les coquillages sur le bois, et les poutres dans toutes les directions donnent une ambiance étrange, surtout avec la géométrie écrasée par le panoramique. La prochaine fois, je gérerais la lumière comme il faut, avec du HDR.

Trac, un bien bel outil

Mathieu Lecarme — Wed, 12 Aug 2009 19:34:00 +0200

Trac est un outil de développement collaboratif. Il est souvent vu comme un outil de gestion de bug avec un wiki, mais c'est bien réductif. Trac peut aussi intervenir lors de la phase de développement. Trac comme tout bon logiciel propose quelque chose qui marche "en le sortant du carton", puis des paramètres fins pour le personnaliser, et enfin une utilisation avancée avec ses plugins et son api distante.

Mise en place

Trac s'articule autour d'un VCS, outil de gestion de version de code. Trac a été conçu pour utiliser Subversion, mais via des plugins, il est possible d'utiliser la plupart des outils de gestion de code existants (Git, Mercurial, Bazaar..). Pour simplifier la mise en place, le stockage s'effectue dans une base sqlite, mais les administrateurs consciencieux utiliseront leur base de donnée de prédilection (mysql, postgres) et leurs procédures de sauvegarde. Trac est capable d'être son propre serveur web, ce qui permet de l'essayer facilement, mais il est bien plus efficace accolé à un vrai serveur web, tel lighttpd ou Apache, à qui l'on confiera d'ailleurs l'authentification des utilisateurs. La communication peut se faire en fastcgi, bien plus neutre que mod_python qui est de toutes façons abandonné. A partir d'une installation de Trac, il est possible de gérer plusieurs instances, avec leurs réglages et plugins spécifiques. Il n'existe pas de notion de portail regroupant les différents projets, seul une simple page donne la liste des projets, avec le lien qui va avec. Trac promet l'internationalisation dans une version futur, un patch existe pour coller du français de partout, mais de manière pragmatique, rien n'empêche de mettre du contenu en français dans un Trac anglophone.

Configuration

Une partie des réglages se font dans un fichier plat, la gestion des droits ou des mises à jour se fait en ligne de commande, mais heureusement, la plupart des réglages courants (hors mise en place) se font maintenant via une confortable interface web.

Outils

Trac regroupe un ensemble d'outils cohérents, avec des liens transverses entre eux. La recherche ou la timeline regroupe les informations des différents outils par exemple.

Les droits

Trac ne se souci pas de l'authentification, mais uniquement des droits. Des droits peuvent être assigné à un utilisateur ou à un groupe. Les modules de base et ceux l'on peut installer propose un ensemble de droits, que l'on attribut depuis l'interface web.

Le wiki

L'outil le plus visible est le wiki. Le wiki est une très belle invention, mais comme une tronçonneuse qui s'avère être très efficace pour couper une forêt ou des zombies, c'est aussi très facile de faire des carnages avec. Un wiki est à la fois le tout et le rien, la liberté devient vite confusion et bazar sans un minimum de discipline. Le plugin tags (mots clefs), permet de regrouper de manières transverses des objets, mais l'effort minimum à effectuer est d'avoir une page d'accueil cohérente et disciplinée. Les pages difficilement trouvables seront recommencé et l'information sera dispersé et redondante. Un peu d'arborescence est possible, mais comme il est impossible de déplacer une page de wiki, mieux vaut s'en méfier. La macro qui permet d'afficher la liste des titres dans un bloc en haut de page est vivement conseillé.

A l'usage, le wiki s'avère efficace pour :

Mise en place des outils de développement et des règles de codages, pour avoir des nouveaux développeurs rapidement efficaces
Procédure de déploiement à suivre pas à pas, pour que n'importe qui puisse sans stress effectuer une mise en pré production ou même en production sans avoir à téléphoner à quelqu'un d'indisponible.
Principe de fonctionnement global, que des commentaires dans le code ne peuvent couvrir
Spécification techniques.
Spécification fonctionnelles, pour les audacieux.

Les tickets

Pour limiter les dégâts, il vaut mieux commencer par utiliser l'outil de ticket, qui lui est carré. Les tickets sont typés, propose un certain nombre de champs, que l'on peut modifier pour personnaliser son travail. Un ticket a un titre, une description, une sévérité, un état (nouveau, refusé, attribué, clos...), un propriétaire, une version, un produit (un des blocs fonctionnel de l'application par exemple) et un identifiant. Trac propose trois types de tickets : l'enhancement (amélioration), le defect (problème) et la task (tâche). On peut en créer de nouveaux type. Ces trois types correspondent à 3 usages bien différents de l'outil. Les améliorations et défauts font parti de la gestion de bug classique, plutôt prévu pendant la phase de production ou de la finalisation, alors que la tache est prévu pour la phase de développement. le principe de base est simple, un ticket est proposé par un utilisateur (amélioration, problème) ou le chef de projet (tache), il est attribué à une personne qui fait le travail nécessaire, puis clos le ticket. Chaque personne a accès à la liste des tickets ou juste de ses tickets selon le degrés d'autonomie, trié par priorité, et les résouds au fur et à mesure. L'horodatage permet de faire stresser le chef de projet en voyant l'avancé du travail ainsi que sa qualité. Trac propose de faire des requêtes (et de les conserver) sur les tickets. Un certain nombre de requêtes sont proposés, comme la liste des tickets ouverts ou juste mes tickets. En cliquant partout, il est facile de créer de nouvelles requêtes.

Les milestones

L'autre notion structurante de Trac est le milestone, la borne kilométrique. La parabole est simple, le développement est vu comme une route à parcourir, et les bornes, posés régulièrement sur le bord du chemin sont là pour nous dire où nous en sommes. Un milestone regroupe un certain nombre de taches, et doit permettre d'avoir quelque chose de montrable. Un milestone a une date de fin, ce qui permet de montrer quelque chose au client, et de voir si les choix et méthodologie fait sont à remettre en cause ou simplement conservé. Le but du milestone est d'éviter l'effet tunnel, d'avoir 6 mois de travail pour effectuer quelque chose bien différent de ce que l'on avait imaginé et spécifié. Les adeptes du développement agile peuvent utiliser un milestone comme étant un rush, une itération et spécifier le milestone suivant lorsque le premier est terminé, en remettant en cause ou validant les choix techniques faits.

Trac permet d'attribuer des tickets à un milestone, ainsi qu'une date et un descriptif, l'outil de visualisation permet de voir l'avancé (le pourcentage de ticket fermé) avec une barre qui se remplit progressivement de vert.

Les procédures distantes

Pour ceux qui aiment le python et lire du code, il est possible de faire des plugins pour Trac, l'usage d'interface permet de border le travail et de ne pas tout casser. Mais il est nettement plus simple d'utiliser l'API xmlrpc qui permet de scripter les outils de Trac depuis son langage programmation préféré. Le wiki utilise même une norme de faite, permettant ainsi de recycler du code. Eclipse, par exemple, est capable de s'interfacer avec Trac. il est ainsi possible de générer de la documentation ou d'afficher de manière complexe et graphique des tickets. On peut aussi imaginer un affichage intégré à un site web qui permettra de remplir directement des tickets sur un serveur Trac distant.

Palette

Mathieu Lecarme — Mon, 29 Jun 2009 19:25:00 +0200

Palette est un petit robot expérimental qui donne son avis sur l'usage de couleurs dans une image.

L'informatique voit les images en rouge vert bleu, en synthèse soustractive, c'est comme ça que fonctionnent les écrans, mais c'est un peu dur à manipuler, un peu plus de vert, un peu moins de bleu? Il existe des modèles plus concret, plus facile à bidouiller. J'ai choisi le classique HSV, teinte, saturation, valeur. Pour simplifier, la teinte définit la couleur, la saturation sa saturation, et la valeur est l'image en niveau de gris contiens les formes et les détails. Donc, pour afficher les couleurs, on peut déjà supprimer la valeur. Il reste donc à afficher le nombre de fois qu'une couleur apparaît dans l'image.

Il y la célèbre roue chromatique, que l'on connait avec une petite tirette pour choisir la valeur. L'angle représentant la teinte, et la distance sur le rayon, la saturation. Il faut en plus représenter la fréquence d'apparition, pour ça il suffit de tricher. L'angle représente la teinte, et ça tombe bien, ça boucle, dans une représentation linéaire, on se retrouve parfois avec une zone coupé en deux, de part et d'autre. La distance du rayon va donc représenter tout le reste : la fréquence pondérée par la saturation (que l'on peut voir comme l'épaisseur d'aquarelle que l'on utilise). La plus grande valeur étant le maximum, c'est pour ça que toutes les roues ont un grand rayon, qui sert d'étalonnage pour les autres valeurs. Pour essayer de limiter les scores très variables, j'utilise une échelle logarithmique, pour limiter la variation de valeurs. Pour aider la visualisation des dégradés (et par ce que c'est joli aussi), j'ai relié les extrémités des rayons par un trait blanc.

Comme exemple, j'ai utilisé des images très différentes, la Joconde qui utilise une palette réduite de couleur, aidé par le vieillissement du vernis. Les deux points bleus qui apparaissent doivent être un cafouillage de compression JPEG. De toute façon, cette image qui vient de Wikipedia a été scannée sur un catalogue, une vraie photo doit donner un meilleur résultat.

Le second est une capture du site web d'Apple, étonnement équilibré au niveau des couleurs, ce qui fonctionne bien avec un usage du noir et du blanc. L'usage de la teinte et de la saturation pour qualifier une image exclut les informations sur le blanc et le noir, ce qui est un peu dommage dans ce cas précis.

Le troisième exemple est une photo très célèbre de Yan Arthus Bertrand, avec une grande dominante de vert. La roue fait bien apparaitre ce vert, mais aussi un gros cafouillage dans le reste des couleurs, en travaillant sur des photos de meilleures qualités, on doit pouvoir obtenir moins de bruit.

Le code est disponible sur GitHub, c'est du python qui utilise l'incontournable bibliothèque PIL, Python Imaging Library, le code est a priori portable.

Le résultat est joli, on a une vue en radar pendant la gay pride, mais ce n'est pas très lisible. Je vais tenter d'utiliser une vue avec les couleurs représentées par des pastilles, un peu comme une boite d'aquarelle. Le premier essai avec une taille proportionnelle à la fréquence donne des images psychédélique, mais illisible. Je vais faire une deuxième tentative avec une taille fixe, mais le nombre de pastilles représentant la fréquence, le tout dans une dimension fixe, dans une boite d'aquarelle, quoi.