Planet Koalabs

Scratchpad is where I write about stuff. It's full of random ramblings, incomplete essays, spelling and grammar errors.

I’ll use this blog for longer and more polished articles, while Scratchpad will be my sandbox.

In case you were wondering

ant clean && adb uninstall com.example && ant debug install && adb shell am start -a android.intent.action.MAIN -n com.example/.ExampleActivity

add -d for a device or -e for emulator.

Atom is an XML-based document format that describes lists of related information known as "feeds"

I use Atom for my Blog. Overall I’m pretty happy with it, the specification is clear and complete. There’s no weird edge cases like with RSS.

I’m working on a virtual scratch pad/notebook. It’s a mix between a Blog & Twitter: Just text with links, and no artificial limitation like 140 characters. I want it to be minimal, just text and links, no more.

Atom requires every entry of a feed to have a title:

atom:entry elements MUST contain exactly one atom:title element.

That’s an unfortunate design choice: many things don’t have a title or a name. We give title to images, essays, & songs, but they don’t really need it, it’s for our own convenience. Requiring everything to have a name can be inconvenient. Every Email must have a subject, which reduces the value of real subjects. Because instead of a relevant information we sometime get unhelpful stuff like “Re”, “Re: mail”, or “Re: your mail”. If Emails that don’t need a subject didn’t have one, Emails might be slightly easier to sort and search.

Another example: In Twitter’s Atom feed every entry contains the complete tweet in the content element, and in the title element. This is misleading because tweets don’t have titles, tweets are not titles.

Small decisions like that can have all short of unintended consequences. What should I put as a title when there’s really no proper title? It will most likely be a duplicate of information already present in the feed. Unfortunate, but I can live with it.

I’ve abandoned all the things I once used and liked. My editor, operating system, browser, database, API’s, & development tools changed —often multiple times— during the past 15 years.

I’ve left everything, except C. C was the first programming language I learned and wrote real programs in. I though I would move to another, better language later. I didn’t realize at the time how beautiful C was.

After 15 years, C is still fun, it still challenges me, it still makes me happy. The older I get, the more I love it.

I've abandoned all the things I once used and liked. My editor, operating system, browser, database, API's, & development tools changed --often multiple times-- during the past 15 years.

I've left everything, except C. C was the first programming language I learned and wrote real programs in. I though I would move to another, better language later. I didn't realize at the time how beautiful C was.

After 15 years, C is still fun, it still challenges me, it still makes me happy. The older I get, the more I love it.

Pour mon employeur actuel, je suis amené à écrire pas mal de code en Perl. C'est un langage je j'apprécie moyennement, notamment pour la raison suivante.

Il y a quelques jours, j'ai cherché comment stocker une référence sur une méthode de classe. Technique relativement commune, j'ai d'abord écrit quelque chose dans ce goût là:

#!/usr/bin/perl -w

package test;

sub new { return bless {}; }

sub hello {
  my $self = shift;

  print "Hello $self\n";
}

package main;

$t = test->new();
$ref = \$t->hello;

$ref->();

Dans le cadre d'une méthode, ce code est incorrect. Au lieu de stocker une référence, la méthode est d'abord exécutée et c'est son éventuel résultat qui sera stocké.

Après quelques recherches sur la toile, je découvre qu'il existe plusieurs solutions (utilisation de la classe de base UNIVERSAL ou encapsulation de la méthode dans une closure).

La correction du code précédent peut donc se faire :

# comme ceci
$ref = $t->can("hello");
# ou comme cela
$ref = sub { $t->hello(@_) };

Je vous laisse choisir laquelle est la plus belle ;-)

Il subsiste néanmoins un léger problème. En général, on ne stocke pas une référence sur une méthode (au lieu d'une fonction) juste pour faire joli. Pour ma part, je le fais lorsque je sais avoir besoin d'accéder à d'autres informations comme les attributs d'une classe.

Si je modifie ma classe test comme suit :

package test;

sub new { return bless {text => "world"}; }

sub hello {
  my $self = shift;

  print "Hello $self->{text}\n";
}

le code précédemment corrigé redevient invalide! Son exécution doit normalement donner le résultat suivant :

Use of uninitialized value in concatenation (.) or string at ...
Hello

Mais que se passe-t-il? (hmmmm mais qu'est ce qu'il se passe?!)

Pour une raison que j'ignore encore, Perl ne passe pas l'instance de classe en tant que premier argument de la méthode comme il le fait d'habitude! Pour corriger ce problème, il suffit de passer manuellement l'instance de la classe en tant que premier argument à chaque utilisation de notre référence :

$ref->($ref);

Ce qui nous donnera enfin le résultat tant attendu :

Hello world

Bref, tout ça pour ça comme dirait l'autre...

Peut-être l'avez vous déjà remarqué mais les extraits de code présentés sur ce blog sont en couleur. La coloration syntaxique est, de mon point de vue, un élément indispensable pour faciliter la lecture du code source.

Cette coloration est gentiment fournie par Pygments et son utilisation dans zinnia en mode restructuredtext se fait de la manière suivante :

• Récupérer le fichier contenant l'instruction sourcecode fournie avec pygments,
• Le copier quelque part au sein des sources de votre blog,
• Importer le contenu de ce module dans le fichier __init__.py situé à la racine :

from rst_directive import *

• Extraire l'un des styles CSS disponibles en standard :

$ pygmentize -f html -S colorful > pygments.css

• Rendre cette feuille de style accessible par votre blog en l'intégrant au contenu statique.

Vous voilà rendu!

Vous pouvez dès à présent utiliser cette nouvelle directive pour rédiger vos billets:

.. sourcecode:: python

  #!/usr/bin/env python

  if __name__ == "__main__":
      print "Bonjour le monde :p"

Zinnia offre la possibilité d'écrire des billets avec autre chose que de l'HTML. Il supporte plusieurs languages (parce que Django le vaut bien) comme, par exemple, le ReStructuredText.

Certains se demanderont peut-être quel est l'intérêt d'utiliser une syntaxe aussi archaique. D'un point de vue tout à fait personnel, j'en vois plusieurs :

• Comme tout bon pythonista qui se respecte, j'écris de la documentation en utilisant cette syntaxe. Ce qui est cool en faisant cela, c'est que je peux par la suite utiliser Sphinx pour générer de la belle documentation,
• C'est lisible, le formatage est efficace et bien organisé,
• C'est facile à retenir.

Bref, je ne cherche pas à convaincre qui que ce soit, plutôt à combler un manque du côté de Zinnia car ce dernier ne propose pas d'outil de migration. Prenez l'exemple suivant (qui est celui de ce site) :

• Changement d'outil,
• Une base existante rédigée en HTML,
• Un besoin d'homogéinité (utiliser une seule et même syntaxe pour mes travaux de rédaction).

C'est classique et je ne pense pas être le seul dans ce cas de figure.

En cherchant un peu, je suis tombé sur Pandoc, une sorte de couteau suisse de la conversion entre formats. J'ai même poussé le vice jusqu'à chercher un module python parce que je suis un gros paresseux :p

En combinant ces outils avec une analyse rapide des modèles utilisés par Zinnia, le résultat obtenu est le suivant :

#!/usr/bin/env python
# coding: utf-8

from django.conf import settings
from zinnia.models import Entry
import pandoc

pandoc.core.PANDOC_PATH = "/usr/bin/pandoc"

def migrate():
    for e in Entry.objects.all():
        print "Converting '%s'..." % e.title
        doc = pandoc.Document()
        doc.html = e.content
        e.content = doc.rst
        e.save()

if __name__ == "__main__":
    migrate()

C'est court et, le plus important, cela fonctionne... presque toujours.

Le module python en question n'est pas très bien écrit et il utilise mal le module subprocess. Le risque : un blocage potentiel en cours d'exécution.

Bref, il a au moins le mérite d'exister :-)

Pour les besoins de ma boite actuelle, j'ai mis un peu de temps (trop à mon goût) à retrouver la manière d'indiquer à Amavisd de ne pas filtrer les emails sortant.

Outre le fait de désactiver tout filtrage pour la policy bank MYNETS:

$policy_bank{'MYNETS'} = {
    # Trucs avant...
    bypass_spam_checks_maps   => [1],
    bypass_banned_checks_maps => [1],
    bypass_header_checks_maps => [1],
};

il faut aussi indiquer à Postfix d'utiliser l'extension XFORWARD lorsqu'il cause avec amavisd. Extrait de mon fichier master.cf:

smtp-amavis unix        -       -       n       -       2       smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes

On redémarre les services et le tour est joué!

Je l'avoue, j'ai quelque peu laissé tomber mon blog ces derniers temps. Manque de temps, de motivation et je ne sais quoi encore mais tout ça c'est terminé!

Pris par une soudaine envie de partager mes connaissances (un peu comme l'autre envie bien connue...), j'en ai profité pour dépoussiérer mon blog :

• Passage de Wordpress à une solution qui me ressemble plus : Django CMS + Zinnia,
• Changement du thème graphique pour quelque chose de plus sobre,
• Nettoyage des billets inutiles (oui, il m'arrive d'en faire),
• Déplacement des billets concernant Modoboa au sein du site de ce dernier,
• etc.

Bref, le résultat de tous ces petits travaux est devant vos yeux. S'il vous plait tant mieux, dans le cas contraire n'hésitez pas à partager vos remarques.