Jérémie Ducastel

Garder le contrôle de ses flux déportés

Jérémie Ducastel — Thu, 26 Nov 2009 11:27:30 +0000

Amis auteurs de blog, bonjour. Il y a de grande chance pour que vous ne lisiez pas ce billet sur le site où il est publié, parce que comme moi vous ne passez pas votre journée à faire le tour des centaines de blogs et sites d’information que vous suivez mais laissez la tâche à votre agrégateur favori. Vous n’apparaissez donc pas dans les statistiques d’accès du site, mais dans celles du flux de syndication qui est pour cela déporté vers un service externe (feedburner).

Comme vous peut être, je n’aime pas trop me rendre dépendant d’un service et risquer de perdre tous mes abonnés si l’envie me prenait de le quitter. J’ai donc configuré ces flux de telle manière que leur url reste sous le domaine du site concerné. Voici un très bref tutorial.

Il vous faut :

Un nom de domaine dont vous pouvez éditer les DNS (Ici enregistré chez Gandi).
Un compte google/feedburner.
Un outil de publication permettant de modifier l’url du flux public (ici Wordpress).

Choisir le sous-domaine qui sera affecté aux flux. feeds par défaut pour feedburner, mais j’ai choisi flux pour mes sites, essentiellement francophones.
Générer le flux déporté par feedburner en lui fournissant l’url source du flux, c’est à dire celle produite par votre site (ici Wordpress donc votreblog.com/feed ).
Aller sur son compte feedburner. Copier la valeur du champ DNS CNAME (qui se termine par feedproxy.ghs.google.com.)
Ouvrir un onglet avec la configuration du domaine. Ajouter un enregistrement CNAME avec la valeur copiée précédemment. Attention, cette modification pourra prendre plusieurs heures pour être prise en compte.
Revenir sur feedburner. Lui spécifier les domaines complets des flux. Activer le service.
Modifier l’adresse publique des flux sur votre site. Pour Wordpress, il y a sans doute un plugin qui fait ça très bien mais pas celui que j’ai testé. Je suis donc allé dans l’editeur du thème utilisé pour modifier les par http://flux.votredomaine.com/slug-feedburner-du-flux. Les fichiers concernés sont généralement header.php (à plusieurs emplacements, dans la partie et dans ) et footer.php.

Twig, les templates Django sous PHP (le retour)

Jérémie Ducastel — Thu, 08 Oct 2009 15:41:31 +0000

Je dis le retour parce que j’avais moi-même implémenté la syntaxe de templates de Django en PHP il y a plus de deux ans (ça fait partie des librairies disponibles de webappkit). D’ailleurs, il m’avait déjà semblé voir d’autres implémentations ça et là depuis.

Je ne me prononcerai pas sur twig que je ne testerai sans doute pas de sitôt (vous aurez compris que le besoin est déjà couvert). Je trouve juste dommage que Django ne soit presque pas cité sur son site. D’abord c’est inélégant, mais surtout cela passe à coté de l’un des intérêts selon moi de la librairie en question : l’interopérabilité avec un framework python majeur. J’en fais actuellement l’expérience, puisque je réécris une application web PHP avec Django, et que je réutilise quasiment tel quels les templates puisque la syntaxe est la même.

Concernant la syntaxe en question, et l’avantage par rapport à du PHP “pur”, qui semble être le débat en cours sur twig, il y a bien sûr la possibilité d’en permettre l’édition par l’équipe éditoriale sans qu’une erreur dans le template ne mène à une erreur 500 ou une faille de sécurité. Mais aussi le système d’héritage qui permet de définir facilement un layout global ou par section; le marquage des contenus à traduire pour l’internationalisation, etc.

Définir l’ip client dans les tests unitaires Django

Jérémie Ducastel — Wed, 30 Sep 2009 15:40:06 +0000

Note brève, mais ça peut servir :

Pour pouvoir accéder à l’ip client via request.META['REMOTE_ADDR'] lors de l’éxécution des tests unitaires, il faut la définir lors de l’instanciation du client de test. Par exemple :

from django.test import TestCase from django.test.client import Client


class MyTestCase(TestCase):

def setUp(self): self.client = Client(REMOTE_ADDR='127.0.0.1')

Sans cela vous obtiendrez une exception de type KeyError parce que REMOTE_ADDR ne sera pas définie dans request.META. Ceci concerne Django 1.0.2 et j’ai trouvé la solution ici

python : les erreurs du débutant

Jérémie Ducastel — Fri, 29 May 2009 15:38:50 +0000

Ou plus exactement, les erreurs du développeur habitué à un autre langage et qui doit se défaire de ses habitudes et présupposés. Trois cas concrets.

Ci dessous, je veux créer une variable str, et ensuite convertir un entier en chaine. Ce qui me lève une exception.

>>> str = "un chaine"
>>> douze = str(12)
TypeError: 'str' object is not callable

Pourquoi ? Parce qu’en python tout est objet – y compris les fonctions, et que le concept de variable est remplacé par celui de nom, qui référence les objets. En l’absence du $ qui en PHP distingue les variables des fonctions, j’avais tout simplement remplacé la fonction str() par une chaine.

Ensuite, je me suis arraché les cheveux sur une erreur de calcul incompréhensible jusqu’à ce que j’ouvre une console python pour obtenir le résultat suivant :

>>> 9/12
0
>>> 9.0/12.0
0.75

Eh oui, pas de conversion automatique d’entier en float lors d’une opération. Il faut donc explicitement déclarer les opérateurs en float avec le .0.

La meilleure pour la fin. En PHP, j’avais pris pour habitude de déclarer toutes les propriétés d’instance dans le corps de la classe plutôt que dans le constructeur, afin d’y associer des doc blocks et d’y définir les éventuelles valeurs par défaut. Comme ceci :

qt = $qt;
    }
}

Ce qui en python donne quelque chose comme ça :

class MyClass():
    # @var int un entier entre un et douze
    qt = 3

    def __init__(qt = None):
        if qt is not None:
            self.qt = qt

Mais ne fonctionne pas du tout pareil. J’étais d’autant plus perdu que la classe en question était instanciée via une méthode statique et que mes instances se comportaient en singleton sans que ce soit le résultat souhaité. J’ai bien du perdre deux heures là dessus, à multiplier les tests unitaires et refactoriser le code pour trouver la source du problème.

>>> first = MyClass(12)
>>> first.qt
12
>>> second = MyClass()
>>> second.qt
12

Jusqu’à ce que je réalise que tout attribut déclaré dans la classe est un attribut de celle-ci et non de l’instance, bien qu’elle soit accessible et modifiable par l’instance avec la même syntaxe (self.qt). Les attributs de classe sont à peu près équivalents aux propriétés statiques en php, et sont partagés entre toutes les instances de la classe.

Pour qu’un attribut soit propre à l’instance (local), il faut impérativement qu’il soit déclaré dans le constructeur :

class MyClass:
    def __init__(qt=None):
        if qt is not None:
            self.qt = qt
        else:
            self.qt = 3

Tests de portage PHP > Python

Jérémie Ducastel — Thu, 14 May 2009 15:35:31 +0000

Sur un coup de tête (un peu déçu par le PHPCamp, où l’on a beaucoup parlé de technologies connexes et très peu de PHP), j’ai décidé lundi matin de tester l’implémentation en Django/Python d’une application web PHP4 que je dois réécrire pour l’internationaliser (anglais / français / chinois). Je précise que si je développe en PHP depuis 2001, je parcours les manuels python depuis plusieurs années et je me suis déjà bien plongé dans la documentation de Django puisque j’ai implémenté en PHP son moteur de templates. Bien qu’ayant très peu pratiqué, je ne suis pas tout à fait novice sur ces deux technologies.

Voici le bilan de trois jours d’évaluation.

Premier jour : (ré)installation de Django, la version 1.0.2, et création du projet. L’application se compose de trois interfaces : une interface web classique (qui doit donc etre multilingue), une interface XML-RPC et une interface client-serveur proprietaire. J’ai choisi de créer une app par interface. Je commence par l’interface client-serveur, qui est le point le plus critique et qui va subir prochainement une forte montée en charge. C’est elle qui va contenir la couche modèle.

La structure de la base de données étant déjà définie, je crée les classes modèles afin qu’elles s’adaptent aux tables existantes. Il s’agit pour l’instant de code essentiellement déclaratif. Parmi les spécificités, je créé un modèle superflu pour prendre en charge une table de liaison qui ne suit pas les conventions de nommage de Django; et un champ CSVField pour des listes de valeurs stockées en CSV dans la base. Le code ci-dessous, incluant docstrings et doctests (Qui sont pour moi une forme de documentation) :

from django.db import models

class CSVField(models.Field):
    """Python list stored as a single CSV-encoded varchar field"""
    separator = ';'
    max_length = 255

    def db_type(self):
        """Define SQL column type"""
        return 'VARCHAR(%s)' % self.max_length

    def to_python(self, value):
        """Converts CSV to Python list

        >>> CSVField.to_python('1;2;3;4;5')
        [1,2,3,4,5]"""
        return value.split(self.separator)

    def get_db_prep_value(self, value):
        """Converts Python list to CSV

        >>> CSVField.get_db_prep_value([1,2,3,4,5])
        '1;2;3;4;5'"""
        return self.separator.join(value)

Je crée également les premières vues, qui se contentent de réafficher les paramètres passées dans l’url.

Deuxième jour : Je mets en place les premiers tests unitaires. Je découvre le client de test de Django, qui me permet de tester les premières vues, avec des données générées dans une base de tests en partie par un fichier yaml (fixtures) et en partie via l’API de la couche modèle dans le setUp() de la classe de tests.

Ensuite, je m’attaque à l’interface web classique qui doit être internationalisée. J’installe pour cela gettext sur mon poste de travail (windows). Je crée la première vue (la page d’accueil) et les templates correspondant. Je marque les parties à traduire dans le code et les templates, et crée les fichiers de traduction anglais et chinois. Je les édite avec poedit, un logiciel spécialisé (de l’avantage d’utiliser un standard existant). Je copie-colle ce que me donne Google Translate pour le chinois parce que, euh, je ne parle pas cette langue. Mais je peux voir avec satisfaction les premiers idéogrammes apparaitre sur le site.

Ici les contenus textuels n’auront pas à être édités fréquemment. Dans le cas contraire je vois mal comment interfacer simplement gettext avec un CMS. Ici, le choix de gettext et poedit permet de faire saisir les traductions par quelqu’un qui n’est pas webmestre. De plus, gettext est également disponible en PHP via une extension spécifique.

Troisième jour : Il est temps de passer à l’interface xml-rpc. Après une brève recherche, je tombe sur django_xmlrpc qui permet d’associer les vues aux methodes fournies par le serveur (Django sert les vues selon des expressions régulières sur l’url de la requete, or avec xml-rpc toutes les méthodes sont servies sur la même url).

Après avoir listé les méthodes et les vues, je crée quelques tests unitaires pour la première. pour cela, je surcharge la classe TestCase de Django avec quelques méthodes utilisant les utilitaires xml-rpc de python (Voir le code ci-dessous). Après quelques tatonnements, mes premiers tests passent !

from django.test import TestCase

class XmlRpcTestCase(TestCase):
    """Specialisation de TestCase pour xml-rpc"""

    # @param string method
    # @param tuple params
    # @param string uri
    # @return Response
    def methodCall(self, method, params=(), uri='/rpc/'):
        """Issue a methodCall and sends a django's test client Response"""
        from xmlrpclib import dumps
        call = dumps(params, method)
        return self.client.post(uri, call, content_type='text/xml')

    # @param Response response
    # @param bool use_datetime if True return datetimes as object
    # @return tuple
    def parseResponse(self, response, use_datetime=True):
        """Parse django's client http Response to python tuple"""
        from xmlrpclib import loads, Fault
        try:
            result = loads(response.content, use_datetime)
            # result is a tuple params, method
            return result[0]
        except Fault, f:
            self.fail("Response was a Fault")
            return ()

    # @param string method
    # @param tuple params
    # @param string uri
    # @return tuple
    def parseCall(self, method, params=(), uri='/rpc/'):
        """method's result  as a python tuple

        assert False on method Fault"""
        response = self.methodCall(method, params, uri)
        return self.parseResponse(response)

    def assertNotFault(self, response):
        return self.assertNotContains(response, '')

Comme il me reste un peu de temps, je reviens sur l’interface client-serveur qui sert un XML maison. Je découvre donc l’implémentation DOM de python pour le générer. Je rajoute quelques tests, et quitte la boite (tôt) sur un premier test positif

Bilan : Compte tenu de la vitesse à laquelle je me retrouve avec un prototype, et du fait que je n’ai rencontré aucun obstacle, je vais très probablement continuer l’implémentation en python et django. Il s’agit d’un choix tout à fait subjectif. J’apprécie beaucoup la syntaxe Python, son modèle tout-objet, et la philosophie batteries included (il y a en standard une bonne librairie pour la plupart des besoins). Et surtout, la qualité et l’exhaustivité de la documentation du langage et du framework, qui permettent de trouver très rapidement ce que l’on cherche, et même plus !

Webappkit 0.13

Jérémie Ducastel — Wed, 06 May 2009 15:32:14 +0000

… est disponible au téléchargement. Pas mal de changements depuis la dernière version, puisqu’il s’est écoulé plus d’un an ! Parmi les changements, un nouveau look pour l’interface d’administration mais c’est la partie émergée de l’iceberg.

Formulaire d’installation de l’administration (création d’utilisateur pour l’authentification HTTP).
Génération de la structure de base des paquets depuis l’admin, ainsi que l’import de fichier de librairie.
Simplification de l’usage des tests unitaires : il suffit de déposer les classes de tests et scripts SQL de mise en place dans le dossier tests/ du kit.
De nouvelles librairies intégrées (bases de données, système de fichiers, et un début d’implémentation de Django Forms.
Et bien sûr pas mal de polissage et de corrections de bugs.

Le site web a également été mis à jour pour l’occasion, avec un nouveau tutorial qui se place dans le cadre de la refactorisation d’un site. La première partie est publiée, le reste suivra prochainement.

Prenons le cas d’une application web vieillissante que nous souhaitons étendre et refactoriser. Comme par exemple, un intranet en code spaghetti, consistant en un ensemble de scripts mixant HTML, PHP et SQL. Bien sûr, il s’agit d’un exemple purement théorique. Toute coïncidence avec une application existante ne serait que pur incident statistique .

lire la suite

Pour rester informés, vous pouvez suivre le twitter du projet. Ses messages sont repris sur le site web et sur l’interface d’administration. Pour participer, vous pouvez également passer par le forum / newsgroup ou envoyer un email.

Google est tout algorithme…

Jérémie Ducastel — Wed, 22 Apr 2009 15:30:17 +0000

L’informatique au service des humains, le retour du balancier : Google est tout algorythme, mon projet est plutôt centré sur le comportement des humains, leurs goûts et les manières « invisibles » dont ils entrent en relation les uns avec les autres.

– le blog de alexis

Google est tout algorithme… peut être, mais pas inhumain pour autant.

Au contraire, l’algorithme de Google prend en compte les évaluations humaines puisqu’il se base sur les liens entre les sites web pour jauger de la pertinence d’un site. C’est cette approche révolutionnaire (A l’époque) qui lui a permis de surclasser, écraser totalement ses adversaires. Plus un site possède de liens entrants (d’autres sites qui y font référence), plus il est supposé faire autorité.

C’est d’ailleurs sans doute la raison qui fait que Wikipedia s’est très vite retrouvé en haut des résultats pour beaucoup de recherches, car il est courant de mettre un lien vers wikipedia dès qu’on cite un concept qui pourrait ne pas être familier pour ses lecteurs (En tout cas c’est ce que je fais souvent).

Scripts SQL de migration SPIP >> WordPress

Jérémie Ducastel — Wed, 15 Apr 2009 15:27:49 +0000

Il y a quelques années, quelques autres anciens de Gobelins et moi avions monté un site sous SPIP, où nous parlions web et culture : exgobz.com

Ayant découvert Wordpress et la qualité de son interface de rédaction qui me pousse à migrer tous mes blogs sur cette plate-forme, j’ai décidé de faire de même pour exgobz. Voilà les quelques requêtes que j’ai utilisé pour importer les contenus. On part du principe que les tables wordpress sont préfixées avec wp_, adaptez selon vos besoins.

# migration SPIP vers Wordpress


# utilisateurs

# ici INSERT IGNORE pour ne pas écraser l'utilisateur #1 (c'est moi sur les 2 sites)

INSERT IGNORE INTO wp_users(

    ID

    , user_login

    , user_email

    , user_url

    , display_name)

SELECT

    id_auteur

    , login

    , email

    , url_site

    , nom

FROM

    spip_auteurs;
# rubriques >> categories

# 2 requetes, wordpress utilise deux tables qui contiennent categories et mots clefs

REPLACE INTO wp_terms(

    term_id

    , name

    , slug)

SELECT

    id_rubrique

    , titre

    , url_propre

FROM spip_rubriques;
REPLACE INTO wp_term_taxonomy(

    term_taxonomy_id

    , term_id

    , taxonomy

    , description

    , parent)

SELECT

    id_rubrique

    , id_rubrique

    , 'category'

    , descriptif

    , id_parent

FROM

    spip_rubriques;
# articles

# attention, tous les articles sont publies d'office !

REPLACE INTO exgobz_posts(

    ID

    , post_author

    , post_date, post_date_gmt

    , post_content

    , post_title

    , post_category

    # , post_status

    , to_ping , pinged

    , post_modified, post_modified_gmt

)

SELECT

    p.id_article

    , u.id_auteur

    , p.date, p.date

    , concat(p.chapo, '  ', p.texte)

    , titre

    , p.id_rubrique

    , '', ''

    , p.date_modif, p.date_modif

FROM

    spip_articles AS p

    LEFT JOIN spip_auteurs_articles AS u ON u.id_article = p.id_article;

# association billets / categories REPLACE INTO wp_term_relationships( object_id , term_taxonomy_id) SELECT p.id_article , p.id_rubrique FROM spip_articles AS p;

C’est loin d’être parfait ni même complet, mais ça peut servir de base de travail. La hiérarchie des catégories semble déficiente sur certains thèmes, je n’ai pas vraiment le temps de fouiller ça pour l’instant.

quizzgeek.net fermé

Jérémie Ducastel — Sat, 11 Apr 2009 15:25:54 +0000

Je viens de fermer Quizzgeek.net, le quizz en ligne pour geeks que j’avais développé. Mais je travaille déjà sur son remplaçant, un site de quizzes plus généraliste. Les questions sont conservées et je tâcherai d’en réintégrer un maximum dans le nouveau site.

A suivre donc…

Safari 4, Google et signets

Jérémie Ducastel — Thu, 09 Apr 2009 15:23:38 +0000

Après quelques semaines de test de Safari 4 (beta), je suis retourné à Chrome pour ce qui est de surfer sur PC. La faute à quelques détails gênants :

Des bogues dans la gestion des cookies et de l’authentification qui m’empêche d’avoir accès à certains sites, dont l’intranet du boulot (que je maintiens).
Impossibilité de définir les préférences de langue (préférences qui pourront être ensuite détectées par le site visité pour adapter le contenu).
Un peu plus lent et gourmand en ressources.

C’est dommage (mais je retenterai dès qu’il sortira en version finale), parce qu’il est pas mal, sinon, Safari 4. Une interface totalement pompée sur Chrome, mais en plus sexy (Apple quoi). Une sorte de Chrome + Cover Flow pour naviguer dans les signets et l’historique.

Autre gros point positif, c’est la synchronisation des signets via Mobile Me qui me permet(tait) d’avoir les même favoris sur Mac, PC et iPhone.

Etant un gros surfeur (j’ai pris du poids mais c’est une coïncidence), j’ai des favoris à la fois dans mon navigateur courant, sur netvibes et sur Delicious (environ 2000), pour les pages qui semblent intéressantes – que je veux garder sous le coude mais que je ne visite pas tous les jours (J’ai également utilisé blogmarks). Sauf qu’au final, je ne me sers (presque) jamais de ces derniers, et mon compte delicious ressemble à un cimetière des éléphants de mes centres d’intérêt.

Au final, comme la plupart des internautes lambda, je passe bien souvent par une recherche google pour retrouver des sites que j’ai déjà visités. Chrome, Firefox et Safari ont intégré ce comportement en suggérant les éléments de l’historique et des favoris lorsqu’on commence à saisir une adresse. La recherche est plus efficace que le classement, même par mot clef.

Google pourrait pousser facilement son avantage avec une simple intégration plus poussée de ses services existants. Il est déjà possible de stocker des favoris en ligne avec Google Bookmarks, avec la possibilité de chercher dans ses favoris, c’est à dire non pas dans les mots clefs ou notes saisies mais bien dans le contenu de la page indexée. Plus besoin de classer soi même les favoris avec une ribambelle de mots-clefs. Aux mots clefs censés indexer le contenu devrait se substituer le contexte d’utilisation (travail, loisirs, etc).

Chrome devrait permettre de synchroniser les signets locaux avec les signets en ligne. De manière générale, tout ce qui est marquable comme suivi (le fameux star this) devrait être accessible via une recherche personnalisée : les items de Google Reader (facile, puisque chaque item fait déjà référence à une url !), mais aussi les courriels (Gmail), les documents (Google Docs), les livres (Google Books), etc.

Et cerise sur le gâteau, tout contenu marqué comme suivi devrait être archivé/mis en cache pour être certain de pouvoir le retrouver si il venait à disparaitre.

L’utilisateur aurait alors à sa disposition un panier de ressources unifié, une présélection pour affiner ses recherches. Un Spotlight (le moteur de recherche unifié de Mac OS X) pour tous ses contenus en ligne. Je me souviens de mon enthousiasme pour Beagle (le moteur de recherche de Gnome), mais je n’utilise que rarement ce genre d’outil car l’essentiel de mes contenus sont désormais en ligne.