Fantomas' side - Derniers articles

Veliberator is alive

fantomas42@gmail.com (fantomas) — Wed, 18 Mar 2015 19:11:41 +0000

Il y a quelques jours, j'ai décidé de mettre à jour le code de veliberator, l'API qui me sert à récupérer en direct les informations du réseau Vélib'. Je vous en avais déjà parlé lors d'un article précèdent en 2009.

Donc après avoir fini la mise à jour de 2015, je me suis demandé à quel point il était compliqué d'en faire un robot pour IRC, une vieille idée qui me trottait en tête depuis longtemps.

Or après quelques recherches il est assez simple de faire un bot IRC, grâce à la librairie irc pour Python. Un module étant même fourni spécifiquement pour écrire ce genre de robot.

Malgré une documentation éparse, j'ai pu en quelques heures mettre sur pied une version IRC de veliberator me permettant de trouver les stations libres les plus proches.

Pour rencontrer veliberator le robot, connectez-vous sur irc.freenode.net/#velib et écrivez une des choses suivantes:

veliberator, status 42001
veliberator, address tour eiffel
veliberator, help

Quand c'est plaisant et utile, le développement devient plus qu'un plaisir.

♪ Je lui dirais des mots vides ♫

fantomas42@gmail.com (fantomas) — Thu, 05 Feb 2015 21:33:29 +0000

Depuis des temps reculés, j'essaye en composant avec mon temps et mon inspiration de toujours développer et maintenir Zinnia. Or un des points que j'essaye d'améliorer ces derniers temps, tant au niveau des résultats, que des performances, c'est la comparaison du contenu des articles, afin de retrouver les articles les plus similaires entre eux.

Une des étapes pour comparer le contenu entre les articles, va être de soustraire dans le texte l'ensemble des mots vides de sens (ou stop words en anglais), tel que "le, la, les", afin de limiter le nombre de mots à comparer, tout en travaillant sur des mots dirons-nous "qualifiés".

Prenons un exemple concret en français :

Maître Corbeau sur un arbre perché,
Tenait en son bec un fromage.
Maître Renard par l’odeur alléché
Lui tint à peu près ce langage :
Et bonjour, Monsieur du Corbeau.

Une fois soustrait de ses mots vides, cet extrait de fable donnera :

Maître Corbeau XXX XX arbre perché,
Tenait XX XXX bec XX fromage.
Maître Renard XXX X’odeur alléché
XXX tint X XXX XXXX XX langage :
XX bonjour, Monsieur XX Corbeau.

On voit donc que l'on conserve les mots essentiels du texte, même si l'on perd le sens des phrases. Et on comprend aussi l'intérêt d'améliorer ce processus, qui peut fortement jouer sur la qualité des résultats et des performances.

Revenons à Zinnia, j'essaye donc d'améliorer cette étape du filtrage, car actuellement seuls les mots vides anglais sont pris en compte par défaut, chose peu pratique pour un blog écrit autrement qu'en langue de Shakespear.

En faisant un petit tour du Web, je constate qu'il existe bien des collections de mots vides dans différentes langues, le tout parfois même accessible en Python !

Mais les API fournies sont un peu trop optimiste, simpliste et/ou ne supportent pas Python3... De plus les collections de mots vides fournis sont parfois légères et disparates.

C'est pourquoi je me suis lancé dans mots-vides, une librairie Python dont les objectifs sont triples :

Faciliter la maintenance des collections de mots vides.
Fournir des collections de mots clefs les plus extensives possible.
Fournir 2 APIs pour les développeurs, une bas niveau et une beaucoup plus élevée.

Petit exemple de l'API haut niveau, pour récupérer et soustraire des mots vides dans un texte en français, comme dans notre précèdent exemple :

from mots_vides import stop_words

french_stop_words = stop_words('fr')
print french_stop_words.rebase('Le lion est mort ce soir.')
'XX lion XXX mort XX soir.'
print french_stop_words.rebase('Le lion est mort ce soir.', '').split()
['lion', 'mort', 'soir.']

L'API de plus bas niveau peut permettre de gérer des collections de mots vides personnalisées. Prenons par exemple que nous voulons créer une collection de langages exotiques tirés de la science-fiction, en commençant par le Klingon :

from mots_vides import StopWord
from mots_vides import StopWordFactory

klingon_stop_words = StopWord('klingon')
klingon_stop_words += ["HIja'", "ghobe'", 'naDev', 'nuq']
factory = StopWordFactory('mes/collections/de/mots/vides')
filename = factory.get_collection_filename(klingon_stop_words.language)
factory.write_collection(filename, klingon_stop_words)  
# La collection est enregistrée

# Plus tard je peux récupérer mes mots vides klingon
factory = StopWordFactory('mes/collections/de/mots/vides')
klingon_stop_words = factory.get_stop_words('klingon')

L'API de bas niveau m'a surtout permis de construire les outils nécessaires à la compilation des différentes collections glanées çà et là sur le net. Grâce à ces outils, la librairie supporte 39 langues différentes, et la mise à jour ou l'ajout de langues peut se faire rapidement.

Le support de toutes ces langues est un bon début, et va donc me permettre d'améliorer ce léger détail qu'est le filtrage des mots vides dans Zinnia. Bien sûr d'autres utilisations sont envisageables. :)

Pour contribuer : https://github.com/Fantomas42/mots-vides

Migration des blogs de Libération.fr sur Zinnia

fantomas42@gmail.com (fantomas) — Fri, 05 Dec 2014 20:20:08 +0000

Depuis maintenant 1 an et demi, en tant que développeur, je travaille pour le site internet Libération.fr, du journal du même nom.

Les problématiques sont variées et l'exigence technique au rendez-vous. Grâce à une équipe sympathique et compétente, on a le temps et les moyens de faire de la qualité dans notre travail, le tout dans un environnement particulier, celui d'un quotidien national.

Il y a quelques semaines, suite à de nombreux échanges et écueils techniques, nous avons décidé de migrer les quelques 350 blogs de Libération hébergés chez Typepad, vers une nouvelle plate-forme qui devra être plus adaptée à nos besoins.

Étant spécialistes Django nous avons donc décidé d'utiliser Zinnia, la solution de blogs développée par mes soins, afin de bénéficier ainsi de mon expertise dans le domaine et du retour d'expérience des centaines de blogs déjà déployés sur cette solution.

Une des exigences technique, fut de n'avoir qu'une seule instance Django pour faire tourner toutes les instances de blogs. Car il est inenvisageable pour des raisons de maintenance et de ressources, de devoir installer une nouvelle instance Django à chaque ouverture de blog.

Zinnia étant modulaire et extensible, l'application a donc servi de socle au projet, puis fût paramétrée et enrichie afin de satisfaire aux besoins d'une plate-forme multi-blogs.

Donc autour de Zinnia, j'ai développé plusieurs applications aux fonctionnalités spécifiques, dont on peut citer :

le mécanisme pour rendre Zinnia multi-blogs.
l'éditeur de contenu, basé sur redactor.
le gestionnaire de profils publicitaires.
l'interface d'administration de la plate-forme.
le processus de migration de Typepad vers Zinnia.
et un thème personnalisé aux couleurs de Libération.

Là où je tire une certaine fierté dans la réalisation de ce projet, c'est qu'à aucun moment je n'ai dû modifier le code source de Zinnia pour satisfaire une exigence ou résoudre un problème, tout cela grâce à la modularité du programme. Chose qui arrive assez rarement dans le monde des applications Django, pour qu'on le souligne.

Pour finir, grâce à cette réalisation, j'ai aussi pu me prouver que le petit programme de blogs, réalisé à titre personnel pour ce site, a bien évolué.
Car désormais il peut tout aussi bien servir de blog personnel très simple, que de plate-forme de blogs hautement personnalisée, chose que je n'avais pas forcément en tête en commençant Zinnia il y a maintenant presque 6 ans.

Le temps des releases : django-livereload

fantomas42@gmail.com (fantomas) — Mon, 16 Jun 2014 12:47:53 +0000

Lors de la refonte du site, j'ai découvert l'utilisation de Gulp et de LiveReload, qui permettent de se passer de rafraîchir constamment son navigateur lorsqu'on intègre du HTML, CSS ou JavaScript. En effet lorsque une modification est enregistrée sur ces types de fichiers, le navigateur reçoit un signal lui indiquant de recharger soit la ressource, soit l'intégralité de la page.

Pas mal, mais pas encore assez satisfaisant pour moi, car j'édite aussi principalement des fichiers Python lorsque je développe sous Django, et j'aurais aimé aussi profiter du rechargement automatique du navigateur lorsque que j'édite du code. Malheureusement ce n'était pas aussi simple que cela...

Sous Django avec le serveur développement, les fichiers Python du projet sont déjà surveillés, et dès qu'une modification est détectée sur ces fichiers, le serveur redémarre pour prendre en compte la modification.

Initiative louable, mais qui complique grandement la tâche, car si je surveille aussi ces fichiers avec Gulp, le signal de rechargement sera émit et reçu par le navigateur avant que le serveur de développement Django ne soit totalement rechargé et prêt. Résultat, le navigateur n'arrive pas à recharger, je me retrouve avec une page vide et cela devient contre-productif.

Ce problème à priori peut être résolu au niveau du serveur de développement Django en utilisant des sockets persistantes et à l'heure où j'écris ces lignes un patch est dans l'attente d'intégration : https://code.djangoproject.com/ticket/18855

C'est pour toutes ces raisons que j'ai créé et publié django-livereload. Grâce à cette application qui modifie le serveur de développement, vous pouvez désormais profiter du rechargement automatique de la page en cours quand vos fichiers Python sont modifiés.

Comment ca marche ? Rappelez-vous, le serveur de développement se recharge déjà quand un fichier Python est modifié, et bien quand le serveur est totalement rechargé, une requête de rechargement est émis vers le serveur LiveReload qui lui se chargera de dispatcher la requête vers le navigateur.

En effet après quelques recherches, j'ai compris que les logiciels comme Gulp ou Grunt, se basaient sur le projet tiny-lr lorsqu'il fallait utiliser un serveur LiveReload, hors tiny-lr fournis une API en HTTP pour pouvoir contrôler le rechargement des fichiers. Ce qui dans notre cas est l'idéal.

Pour contribuer, voici l'adresse du projet : https://github.com/Fantomas42/django-livereload

Mise à jour 2014 du blog

fantomas42@gmail.com (fantomas) — Wed, 23 Apr 2014 13:22:09 +0000

On dit souvent que les cordonniers sont les plus mal chaussés, et en tant que développeur web je confirme l'adage. Ce blog est à l'abandon, depuis pas mal de temps déjà...

J'ai donc décidé pour remettre le pied à l'étrier, dans un premier temps de le rafraîchir visuellement et de mettre à jours ses composants, afin pourquoi pas le ressusciter dans un second temps.

Concernant la partie visuelle, j'ai cédé à la mode du design épuré, et ce pour plusieurs raisons.

L'idée originale étant de mettre en avant le contenu et sa lisibilité, ce genre de thème est adapté en utilisant de bonnes typographies. De plus en me limitant esthétiquement j'ai pu faire quelque chose de maintenable et maîtrisable à mon échelle et intégrer facilement un coté responsive au site qui lui faisait défaut en 2014.

Lors de cette refonte, je me suis aussi imposé des objectifs chiffrés en terme de temps, histoire de ne pas m'égarer sur des détails et d'avancer rapidement, d'où aussi la simplification esthétique. Cela permet de ne se concentrer que sur le cœur du site, c'est à dire les articles et leur contenu.

Pour réaliser et intégrer le design j'ai procédé en deux étapes, en réalisant d'abord une charte graphique qui me convenait, puis une fois le rendu satisfaisant à mon goût, j'ai commencé à l'intégrer dans mon système de templates.

En évitant de mélanger le fond et la forme, c'est à dire d'intégrer le HTML et le CSS en même temps qu'ils soient conçu, j'ai eu l'impression de gagner beaucoup de temps en évitant des errements et des allers-retours inutiles.

Concernant la partie intégration afin de gagner aussi du temps, j'ai utilisé un combo Gulp, Sass et Livereload. Dès que je modifie les fichiers Sass, ils sont automatiquement compilés en CSS et dès qu'une modification a lieu dans le CSS ou le HTML, mon navigateur va se rafraîchir automatiquement afin de me la montrer instantanément. Fini l'époque du Ctrl+F5 toutes les 15 secondes. :)

Pour la partie backend, j'ai opéré un nettoyage drastique sur les fonctionnalités inutiles ou presque du site afin d’accélérer au maximum le développement. Je suis resté sur Django en utilisant la dernière mouture de Zinnia, mon moteur personnel de blog. La principale différence par rapport à la précédente version du site, vient du fait que les commentaires sont désormais chargés de manière asynchrone en Javascript via Disqus.

Le fait de différer le chargement des commentaires, m'a permis de mettre en cache statique toutes les pages du site, afin de les servir plus rapidement, chose que je ne pouvais faire avant à cause du formulaire de commentaire et la protection CSRF.

Pour finir sur les innovations, en termes de processus, j'ai utilisé la méthode git-flow, afin de limiter chaque phases de développement dans une branche et de pouvoir déployer le code en production sur une version stable et spécifique. Les outils et le flow proposé par git-flow rendent le processus de développement et de versionning beaucoup plus facile et professionnel, peu importe au final la taille du projet.

Pour conclure cet article, je dirais que pas mal de chemin a été parcouru depuis le début de ce blog, sous Wordpress, tant sur les domaines de ses aspirations éditoriales et esthétiques que sur le domaine technique.

Lors du passage à Django, qui m'a mené au développement de Zinnia, je voulais plus de maîtrise sur le code déployé afin de faire des choses plus complexes.

Maintenant que j'ai fait pleins de choses complexes et plus ou moins utiles, je veux plus de simplicité afin de me concentrer sur l'essentiel.

Si je dois tirer une certaine fierté de cette refonte, elle viendrait du fait que j'ai réussi à transmettre cet esprit d'essentialité et de simplicité à tous les composants du site, technique ou non.

La face cachée du Sudoku

fantomas42@gmail.com (fantomas) — Tue, 11 Oct 2011 16:49:56 +0000

Introduction

Tout commence un soir entre amis, où une envie démente de coder un petit projet nous surprend entre 2 bières. :D

Lui vient du monde Java, moi du Python, mais ayant subi la même formation, le moment fût propice pour comparer nos progrès et évolutions et aussi lancer un troll ou deux.

Ensuite nous vient l'idée de programmer un résolveur universel de Sudoku, ayant quelques connaissances de base à propos de ce jeu, j'imagine dans les grandes lignes un algorithme pour résoudre ce genre de puzzles...

L'idée générale du programme est d'appliquer de manière séquentielle les 2 ou 3 stratégies de résolutions que j'utilise moi même quand je fais un Sudoku tiré d'un magazine...

Passage à l'acte

Rapidement j'obtiens un résultat, mais se pose le problème de la difficulté. En effet, les grilles disponibles dans les magazines sont classées par difficulté croissante, or cette difficulté est toute relative.

En effet seul le nombre de techniques de résolutions nécessaires (en général 3 ou 4) à un puzzle conditionne le niveau de difficulté. A savoir qu'il existe de techniques très complexes pour résoudre certaines grilles de Sudoku, mais il ne sera jamais nécessaire même à un niveau dit "Diabolique" de les maîtriser. Seules les techniques élémentaires seront nécessaire pour 95% des grilles publiées.

Mais concernant les 5% restant, là cela devient beaucoup plus complexe, car après plusieurs heures de recherches et de compréhension de ces techniques, je décide d'en implémenter certaines dans le résolveur pour augmenter ses chances de résolution.

Mais le problème reste entier, même si j'augmente le nombre d'algorithmes de résolution, si je tombe sur un cas que je n'ai pas prévu, je ne peux pas résoudre complètement la grille. En effet, le programme n'est pas capable d'improviser une solution ou d'échafauder une hypothèse qui lui permettrait de se sortir de ce cas imprévu.

A la suite de cette série d'échecs, je décide d'implémenter un algorithme de résolution basé sur le backtracking, solution qui me convient beaucoup mieux car le taux de résolution des puzzles est de 100%, mais insatisfaisante car elle ne permet pas d'expliquer la solution et le temps de résolution d'un puzzle est peu prédicable et très fluctuant.

Réflexions

En guise de conclusion à cette immersion dans le monde du Sudoku qui s'est révélée au final bien plus riche qu'il ne le semblait aux premiers abords, j'ai appris une belle leçon en matière de programmation et surtout d'algorithmique.

En effet mimer la façon de penser d'un homme pour résoudre certains problèmes de programmation peut parfois se révéler intéressant et source de solutions, mais il ne faut pas oublier que l'on traite avec une machine.
Une machine n'a pas la capacité d'innovation ou d'évolution face à un problème non identifié, par contre elle est capable de retenir des millions d'informations et de les traiter beaucoup plus rapidement que n'importe quel humain et ça, c'est un avantage indéniable.

Même si un humain peut utiliser la technique du Backtracking (appelé aussi Nishio) pour résoudre sa grille, il mettra un temps phénoménal mais il n'y arrivera que s'il est très rigoureux et ce n'est pas du tout ludique.

Par contre pour une machine, la donne s'inverse, la machine est rigoureusement rigoureuse et peut faire tous ces calculs très rapidement.

Pour conclure, même si un humain et une machine peuvent plus ou moins faire la même chose, il ne faut jamais oublier de prendre en compte les points forts et points faibles de l'un et de l'autre dans la conception d'un algorithme.

Résultats

Le résultat de toute ces expériences est disponible sur PyPI sous le nom de sudoku-solver.

$ easy_install sudoku-solver
$ sudoku_solver votre_grille.txt

Vous pouvez éventuellement contribuer sur la page Github du projet à l'adresse suivante : https://github.com/Fantomas42/sudoku-solver

Et pour terminer, je n'ai pas pu m'empêcher de réaliser une démo web de ma librairie sous le framework Django. Donc si vous voulez résoudre ou vérifier vos grilles de Sudoku, allez à cette adresse : http://sudoku.willbreak.it/

Bon puzzles !

Ô middleware, mon beau middleware : Request Template Loader

fantomas42@gmail.com (fantomas) — Tue, 08 Mar 2011 14:38:28 +0000

Dans le monde du web, là où tout est anarchie (ou presque), je me retrouve confronté assez souvent à cette problématique :

Comment afficher le contenu d'un site réalisé avec Django sur un autre site déjà existant ?

Là où je bosse, on aime bien les iframes HTML (no comments please :)), mais le contenu ou le style de la frame incluse ne correspondent pas forcément au site recevant la frame. L'idée, vu qu'on se trouve à la base dans un environnement Django, serait de déployer un nouveau site, avec son propre jeu de templates prévues pour le site incluant les frames.

Mais ce genre de technique nécessite de mettre en place un nouveau domaine, de déployer et de maintenir 2 sites. Bon vous me direz que ce n'est pas forcément ce qu'il y a de plus dur, mais il y a moyen de faire mieux. Et surtout que ce passe-t-il si vous devez faire ce genre d'opération non pas sur 1 site, mais sur plusieurs. Tout de suite cela devient plus ennuyeux. :(

C'est là où intervient la solution du middleware. L'idée est de pouvoir passer en GET un paramètre qui conditionnera le chargement des templates dans le site source. Comme cela peu importe combien de frames au look différent on devra gérer, la mise en forme et la personnalisation du contenu se fera très facilement.

Maintenant place au code, les explications sur le fonctionnement viennent directement après.

import os
from urllib import urlencode
from urlparse import urlparse
from urlparse import urlunparse
try:  # For Python < 2.6
    from urlparse import parse_qs
except ImportError:
    from cgi import parse_qs

from django.conf import settings
from django.utils.encoding import smart_str

from BeautifulSoup import BeautifulSoup


GET_VAR_NAME = getattr(settings, 'TEMPLATE_GET_VAR_NAME', 'from_source')


class RequestTemplateMiddleware(object):
    """Middleware to modify on the fly
    the loading of the templates"""

    def __init__(self):
        self.original_template_dirs = settings.TEMPLATE_DIRS

    def process_request(self, request):
        source = request.GET.get(GET_VAR_NAME)

        if source:
            settings.TEMPLATE_DIRS = (os.path.join(os.path.dirname(__file__),
                                                   'templates', source),) + \
                                                   settings.TEMPLATE_DIRS
        return None

    def process_response(self, request, response):
        settings.TEMPLATE_DIRS = self.original_template_dirs

        source = request.GET.get(GET_VAR_NAME)

        if source and '<html' in response.content:
            soup = BeautifulSoup(smart_str(response.content))
            for link in soup.findAll('a'):
                link['href'] = self.update_link(link['href'], source)
            for form in soup.findAll('form'):
                form['action'] = self.update_link(form['action'], source)
                form.insert(0, '<div><input type="hidden" name="%s" ' \
                            'value="%s" /></div>' % (GET_VAR_NAME, source))
            response.content = str(soup)

        return response

    def update_link(self, link, source):
        """Update the links with the good GET parameter"""
        url_parts = urlparse(link)
        query_dict = parse_qs(url_parts.query)
        query_dict.update({GET_VAR_NAME: source})
        return urlunparse((url_parts.scheme, url_parts.netloc,
                           url_parts.path, url_parts.params,
                           urlencode(query_dict), url_parts.fragment))

Comme on peut le voir, ce middleware va court-circuiter l'ordre de chargement des templates en modifiant la variable TEMPLATE_DIRS utilisée par django.template.loaders.filesystem.Loader, grâce à la variable from_source passée dans l'url en GET.

Ensuite il ne reste plus qu'à créer le dossier de templates correspondant à la variable from_source et d'y placer les templates personnalisés. A savoir que le nom de la variable passée en GET est configurable pour plus de souplesse.

La seule dépendance requise est BeautifulSoup qui va modifier le contenu HTML afin de pouvoir continuer à utiliser le middleware quand on clique sur un lien ou on valide un formulaire.

Au delà de l'utilité de ce bout de code, j'espère que cela va vous motiver à programmer et utiliser vos propres middlewares, car cela s'avère souvent la meilleure solution à un problème complexe lors du développement d'un site internet avec Django.

Le temps des releases : django-blog-zinnia

fantomas42@gmail.com (fantomas) — Thu, 16 Sep 2010 18:51:12 +0000

Incroyable, après presque 2 ans d'attente, Zinnia l'application Django propulsant ce blog est enfin publiée sur un dépôt public.

Le premier article faisant référence à Zinnia date en effet du 16 Novembre 2008.

Beaucoup d'évolutions ont été apportées entre cette première version réalisée à titre personnel et celle qui gère le site actuellement. Ceci explique en partie mon manque d'activité sur le site.

Au final, j'en ai profité pour mettre à jour le code du site en utilisant la version de développement et refondre le skin du site, un peu trop sombre et vieillissant à mon goût.

Maintenant, concentrons nous sur notre sujet. Tout d'abord le code source de Zinnia est disponible sur GitHub, ce qui facilite le travail communautaire, donc si vous voulez participer, forker ou télécharger, aucun problème, vous y êtes même encouragé.

Lors de la publication du code source, je me suis efforcé de documenter un maximum les fonctionnalités ainsi que l'installation, donc pour présenter le projet je vais me baser sur ces documents.

Tout d'abord, qu'est-ce-que Zinnia ou django-blog-zinnia exactement ?

Zinnia est une application générique pour gérer un blog à travers un site en Django. Elle a été conçue pour publier des articles et le faire efficacement ! De manière générale toutes les fonctionnalités qui peuvent être fournies par une autre application réutilisable écrite en Django ont été mises de coté. Pourquoi réécrire ce qui a déjà été testé et approuvé par les autres ?

Mais plutôt qu'un long discours, je vais dresser la liste actuelle des fonctionnalités disponibles.

Commentaires
Flux RSS ou Atom
Vues par archives
Vues par catégories et tags
Détection des articles relatifs
Moteur de recherche avancé
Prépublication et expiration
Widgets
Sitemaps
Protection anti-spam avec Akismet
API MetaWeblog
Ping dans les annuaires
Ping des ressources externes
Support de Bit.ly, Twitter
Gestion de Gravatar
Plugin pour Django-CMS
Travail collaboratif
Autocomplétion des tags
Support des Pingbacks et Trackbacks
WYMeditor ou TinyMCE pour éditer
Templates génériques prêts l'emploi
Utilitaire de conversion depuis WordPress

Je dois certainement oublier des petites choses, mais ça commence déjà à faire pas mal. D'ailleurs, si vous avez une idée de ce qui pourrait manquer n'hésitez pas à m'en faire part.

Une documentation complète et mise à jour se trouve à cette adresse : http://django-blog-zinnia.com/docs/
Vous trouverez dans cette documentation un lien vers une documentation de l'API, ainsi que le code coverage des tests effectués sur l'application. Car bien sûr l'application est testée. Ouf !

J'ai failli oublier de dire qu'une version de démonstration de l'application se trouvait ici : http://django-blog-zinnia.com/blog/

Bon il ne reste plus qu'à écrire des articles ! :)

Le temps des releases : easy_extract

fantomas42@gmail.com (fantomas) — Tue, 19 Jan 2010 10:47:56 +0000

Imaginons que j'ai sur un serveur de donnée une grosse quantité d'archives sous différents formats, tel que RAR, ZIP, XTM...

Si je souhaite extraire toutes ces archives, je devrais aller trouver chaque archives dans son répertoire, taper la bonne commande pour pouvoir les extraire, les réparer au besoin et ainsi de suite... Plutôt fastidieux non ? :(

Sur ce constat m'est venu l'idée de easy_extract, un script écrit en Python qui va analyser récursivement les répertoires à la recherche d'archives ou de collections d'archives pour les extraire et les réparer automatiquement si elles sont corrompues.

Pour cela, il suffit de lancer le script de la manière suivante par exemple :

$ easy_extract -r mes_archives/

Pratique et le gain de temps est évident, car une fois le script lancé, vous n'avez plus à vérifier que l'extraction s'est bien déroulée pour ensuite passer à la suivante, donc a scotcher devant votre terminal. Victoire une tâche fastidieuse de plus automatisée. :D

Pour l'installation, il est nécessaire d'installer les paquets suivant avant :

par2
unrar-free
7zip-full

Ensuite l'installation du script se fait grâce à easy_install :

$ easy_install easy_extract

Bien sûr le code est open-source, donc si vous voulez contribuer, forker ou juste critiquer, le code se trouve à l'adresse suivante : http://github.com/Fantomas42/easy-extract

Bonne décompression et bon leech.

Le temps des releases : Vélib'erator

fantomas42@gmail.com (fantomas) — Thu, 24 Sep 2009 14:16:23 +0000

Suite à mon abonnement à Vélib', habitant près d'une station récemment construite, j'ai vite remarqué que de trouver un vélo en bon état ou une place de parking à proximité avant les 30 minutes fatidiques et payantes pouvait vite devenir un calvaire.

Sur ce, après quelques recherches, j'ai pu constater que les informations sur l'état des stations du réseau Vélib' étaient librement accessibles. D'où l'idée de créer un paquet python nommé Veliberator, me permettant depuis mon shell de consulter l'état de mes stations favorites.

Pour les fans de la ligne de commande, essayez ceci :

$ sudo easy_install veliberator
$ sudo synchronize.py
$ find_place.py 42008

Partant de là, je me dis qu'il serait dommage de m'arrêter à ce stade du développement, d'autant plus que mon problème pour trouver une place libre rapidement ne se résous que depuis mon ordinateur, il faudrait donc que ce service soit accessible partout et pour tout le monde.

Un site web semble être la solution idéale, d'autant plus si on est capable d'optimiser l'affichage des pages au type de support, par exemple un mobile.

Equipé de mon module python et de Django, j'ai donc réalisé le site http://veliberator.com.

Au programme du site :

Consultation des statuts des stations Vélib'.
Affichage des stations aux alentours.
Affichage des lieux importants près des stations.
Flux RSS pour monitorer le statut des stations.
Vues par ville, départements, statut, adresse.
Statistiques du réseau Vélib'.
Recherche par : adresse, métro, monument, code postal, coordonnées GPS.
Calcul des distances.
Traçage d'itinéraires entre stations Vélib'.
Gestion de favoris.
Interfaces claires et unifiées.
Cartes détaillées et en plein écran.
Géo-localisation automatique.
Internationalisation
Support pour les téléphones mobiles et iPhone.
Support pour les Télésites Freebox.

En effet le site tourne sous plusieurs versions, chacune adaptées à son environnement d'affichage, et à tout moment je peux consulter ces informations.

Dans mon cas, quand je rentre du travail en Vélib' et qu'il n'y a plus de place en bas de chez moi, je sais directement où aller pour trouver une place libre, sur mon téléphone. Adieu les rondes au hasard à la recherche d'une place libre... Merci Vélib'erator ! :D

Si vous avez des suggestions, je suis ouvert à toutes propositions d'amélioration.

http://veliberator.com

http://m.veliberator.com

Edit 30 septembre 2009 : Suite à un email provenant de la société JCDecaux, je me vois dans l'obligation de ne plus utiliser leurs données sur les stations vélib selon les articles L. 112-3 al 2 et L.341-1 du code de la propriété intellectuelle. Données qui sont pourtant accessible publiquement... A priori, avec Vélib, il vaut mieux éviter les initiatives personnelles.

Le temps des releases : Django-sekh

fantomas42@gmail.com (fantomas) — Mon, 31 Aug 2009 18:17:51 +0000

Vous avez certainement déjà vu dans Google quand vous consultez une page depuis son cache, les termes de la recherche sont coloriés dans le contenu de la page pour permettre de les discerner rapidement.

De ce principe certains sites ont adapté la même technique en coloriant certains mots de la page correspondant à la recherche de l'utilisateur si il provient d'un moteur de recherche.

C'est ce que django-Search Engine Keywords Highlighter fait !

Une fois installé avec BeautifulSoup, il suffit juste d'ajouter ce middleware à la fin de la liste dans votre fichier settings.

MIDDLEWARE_CLASSES = (
  ...
  'sekh.middleware.KeywordsHighlightingMiddleware',
)

Moi quand c'est facile à installer, j'aime ! :D

Ce middleware va rajouter une balise span autour des mots de la recherche, le tout avec des classes qui vont bien permettant la décoration en CSS.

L'inconvénient est que si votre HTML est mal formatté, le middleware risque de faire planter la page.

Pour voir un exemple cliquez ici.

Pour plus d'informations et pour télécharger le code :

http://github.com/Fantomas42/django-sekh/tree/master

Le temps des releases : Django-smileys

fantomas42@gmail.com (fantomas) — Sun, 19 Jul 2009 13:25:48 +0000

Parfois il est temps de se sortir les doigts du code, et d'en parler !
Mais pour en parler, il faut documenter, ce qui prend un peu de temps, mais j'y travaille.

Pour commencer je vais vous présenter une de mes applications favorites, par sa simplicité et son utilité incroyable. :D

Django-smileys est une application Django comme son nom l'indique, permettant d'inclure facilement dans ses templates des smileys, de ce genre :) :p.

Pour cela, une fois l'application téléchargée et installée dans votre projet django, il vous suffit dans vos templates d'utiliser le filtre qui va convertir tout les code smileys définis dans SMILEYS_LIST.

{% load smiley_tags %}

{{ object.content|smileys }}

Plutôt facile non ? Surtout que l'on peut maintenant convertir tout type de contenu texte.

La liste des smileys est configurable, ainsi que l'url de dépot et la classe d'habillage CSS.

Pour télécharger ce projet hallucinant : http://github.com/Fantomas42/django-smileys/tree/master

Bientôt d'autres releases.

Paye ta Fabric !

fantomas42@gmail.com (fantomas) — Fri, 01 May 2009 14:53:09 +0000

Le déploiement d'applications, c'est pas toujours facile et rébarbatif surtout quand on travaille sur un parc de machines.

Imaginons que j'utilise un serveur de version, du genre Subversion ou Mercurial et que j'utilise un ou deux serveurs (test, production 1, production 2, ...) pour héberger mon ou mes applications.

Le déroulement est le suivant :

Développement en local.
Propagation des modifications.
Connection SSH sur les serveurs.
Rapatriement les dernières modifications
On redémarre le soft.

Vous me direz que cela n'est pas forcément très long, mais quand vous devez le faire souvent et plusieurs fois par jour, on en a vite pleins le dos et cela est source d'erreur.

Heureusement l'informatique étant un sport où celui qui est le plus fainéant gagne, il existe un solution pour se simplifier ces tâches de déploiements à distance.

Son nom ? Fabric

En quelques lignes de Python, définissant des règles, un peu à la manière d'un Makefile, il est possible d'automatiser ce genre d'opération.

Voici un exemple basique pour le déployement d'un projet Django avec Mercurial :

"""Fabric Rules for MyProject"""

config.production = ['server.domain.com']
config.app_dir = '/home/dev/djangos/myproject'

def publish():
    """Publish the content by pushing it"""
    local('hg push')

def apache_reload():
    """Reload the apache process"""
    sudo('/etc/init.d/apache2 reload')

@roles('production')
def update():
    """Update the code source"""
    run('cd $(app_dir); hg pull; hg update')
    run('cd $(app_dir); python manage.py syncdb')
    run('cd $(app_dir); python manage.py loaddata my_dump.json')
    apache_reload()

@roles('production')
def debug_on():
    """Turn debug mode on for the production server."""
    run("cd $(app_dir); sed -i -e 's/DEBUG = .*/DEBUG = True/' settings.py")
    apache_reload()

@roles('production')
def debug_off():
    """Turn debug mode off for the production server."""
    run("cd $(app_dir); sed -i -e 's/DEBUG = .*/DEBUG = False/' settings.py")
    apache_reload()

@depends(publish, update)
def deploy():
    """Deploy the website."""
    pass

Un des avantages principaux de Fabric est qu'il est possible de l'utiliser sur plusieurs serveurs en même temps, avec des règles spécifiques.

On lance Fabric, et on peut aller prendre un café. :D

Pour information Fabric est basé sur Capistrano, le même principe mais en Ruby.

Un must, à tester absolument.

Edit : le site du projet Fabric

Stop aux spams sur django.contrib.comments

fantomas42@gmail.com (fantomas) — Wed, 15 Apr 2009 23:14:47 +0000

Depuis quelques jours, les formulaires de commentaires fournis par l'application django.contrib.comments dans la distribution de Django, sont devenus vulnérables aux spams.

L'application comments contient par défauts plusieurs sécurités pour éviter le spamming, comme un honeypot et la vérification du temps de saisie du commentaires.

Malgré cela les équipes de spammer sont très réactives, et coder un bot spécifique pour les sites django utilisant ce système de commentaires, rend tous ces sites vulnérables.

En parallèle de cela, dans la version 1.1b de Django, l'application comments acquiert une nouvelle fonctionnalité, qu'est la modération automatique. L'envois de mails en cas de commentaires, et aussi prise en charge.

J'en ai donc profité pour développer une protection contre le spam plus efficace basée sur Akismet à partir de cette nouvelle fonctionnalité.

"""Moderator of Entry comments
   Based on Akismet for checking spams
   Need to override the default Moderator,
   for getting request in parameters."""
from django.conf import settings
from django.utils.encoding import smart_str
from django.contrib.sites.models import Site
from django.db.models import signals
from django.contrib import comments
from django.contrib.comments.signals import comment_will_be_posted
from django.contrib.comments.moderation import Moderator
from django.contrib.comments.moderation import CommentModerator

from django.conf.settings import MAIL_COMMENT
from django.conf.settings import AKISMET_COMMENT

AKISMET_API_KEY = getattr(settings, 'AKISMET_API_KEY', '')

class EntryCommentModerator(CommentModerator):
    """Moderate the comment of Entry"""
    email_notification = MAIL_COMMENT
    enable_field = 'comment_enabled'

    def email(self, comment, content_object):
        if comment.is_public:
            super(EntryCommentModerator, self).email(comment, content_object)
            
    def moderate_akismet(self, comment, content_object, request):
        """Need to pass Akismet test"""
        if not AKISMET_COMMENT:
            return False

        from akismet import Akismet
        from akismet import APIKeyError

        akismet = Akismet(key=AKISMET_API_KEY,
                          blog_url='http://%s/' % Site.objects.get_current().domain)
        if akismet.verify_key():
            akismet_data = {'user_ip': request.META.get('REMOTE_ADDR', ''),
                            'user_agent': request.META.get('HTTP_USER_AGENT', ''),
                            'referrer': request.META.get('HTTP_REFERER', 'unknown'),
                            'permalink': content_object.get_absolute_url(),
                            'comment_type': 'comment',
                            'comment_author': comment.userinfo.get('name', ''),
                            'comment_author_email': comment.userinfo.get('email', ''),
                            'comment_author_url': comment.userinfo.get('url', '')}
            return akismet.comment_check(smart_str(comment.comment),
                                         data=akismet_data,
                                         build_data=True)
        raise APIKeyError("Your Akismet API key is invalid.")


class EntryModerator(Moderator):
    """Moderator for Entry"""

    def connect(self):
        comment_will_be_posted.connect(self.pre_save_moderation, sender=comments.get_model())
        signals.post_save.connect(self.post_save_moderation, sender=comments.get_model())
        

    def pre_save_moderation(self, sender, comment, request, **kwargs):
        """Overriding the existing method by passing request to allow"""
        super(EntryModerator, self).pre_save_moderation(sender, comment, **kwargs)

        moderation_class = self._registry[comment.content_type.model_class()]
        if moderation_class.moderate_akismet(comment, comment.content_object, request):
            comment.is_public = False



moderator = EntryModerator()

Il suffit juste d'installer le module Akismet pour Python, et cela devrais fonctionner en définissant sa clef d'API Akismet.

Bon par contre, on remarque de suite qu'il est dommage de devoir écrire une nouvelle classe Moderator, pour pouvoir récupérer et passer le context, c'est peu pratique en effet, surtout que comments peux le gérer par défaut avec le signal comment_will_be_posted.

Mais à priori cela risque de changer si on en regarde le ticket suivant, prévu pour la version finale de Django 1.1 : Ticket 10878, projet Django

Donc une réécriture du code sera certainement nécessaire à la sortie de cette version, qui commence à se faire attendre....

Pour plus d'informations : Documentation sur la modération

Un CMS en Django ? la suite

fantomas42@gmail.com (fantomas) — Tue, 10 Mar 2009 16:19:33 +0000

Ces derniers temps occupé par certains projets personnels, j'ai pu tester de nouveaux outils de développement. L'idée est d'en faire un retour et je vais commencer par la suite de mon dernier article.

La dernière fois je vois ai parlé d'une des premières applications disponible en Django permettant d'intégrer un CMS dans son site, nommé Django-cms. Mais mon retour sur cette application m'avait laissé un petit goût de frustration, me laissant penser que ce n'étais pas encore au point. Mais cela va mieux avec Django-page-cms. :)

Ce dernier en plus des fonctionnalités essentielles, comme la gestion de l'arborescence dans le module d'administration et la prise en charge de différents langages, possède certains atouts qui en font mon favoris.

Voici les petits plus qui m'ont séduit :

Définition de plusieures zones de contenus dans un template. (trop fort !)
Surcharge des urls existante dans le CMS. (enfin !)
Possibilité d'édition du contenu directement depuis le Front. (la classe !)
Les contenus du CMS peuvent être interprétés en temps que code. (super !)
Pas de besoin de définir une "RootPage" comme dans Django-cms.
Gestion des révisions.
Code propre.

De plus j'ai pu tester la rapidité de l'équipe du projet qui a intégré en moins de 12h ma contribution pour fixer un bug mineur.

Un projet qui mérite donc d'être suivis.

Le site de web de Django-pages-cms.

Edit du 7 avril 2009 : une traduction en français est désormais disponible, ou ici.