Blog // Exirel.me

Retrouvez tous les articles liés au tag Développement via le flux rss dédié à ce tag.

HTTP Accept header

Par Florian Strzelecki - 21:45 - 25.04.2014

Tags : Web, HTTP, Hypermedia, Développement, HATEOAS, REST, Technique, Programmation, Bonne pratique, API

La RFC 2616 de l'IETF est une spécification du protocole HTTP/1.1. Ce document décrit notamment les headers des requêtes HTTP à disposition des clients, et en particulier le header "Accept", qui sera le sujet de cet article.

À quoi sert-il ?

En résumé : il permet la négociation de contenu dirigée par le client.

En utilisant Accept, le client indique au serveur HTTP quels types de contenus il est capable de gérer, éventuellement avec un ordre de préférence. Le serveur est alors invité à fournir le type de contenu le plus adapté pour répondre à la demande du client (mais ce n'est pas obligatoire).

Ce paramètre peut être utilisé avec d'autres headers, comme Accept-Language ou Accept-Encoding ; par exemple, le serveur Apache (qui documente sa méthode de négociation de contenu) utilise plusieurs headers pour déterminer la meilleure réponse possible.

Comment ça marche ?

Prenons un exemple avec une requête envoyée par Firefox (28.0), qui utilise ce header par défaut :

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Ceci indique au serveur que le client attend, par ordre de préférence :

Pour le cas d'une balise img, le header sera différent, et contiendra plutôt image/png (j'ai d'ailleurs remarqué que l'URL n'est absolument pas prise en compte par le navigateur pour générer son header).

PHP est cassé, et alors ?

Par Florian Strzelecki - 23:55 - 18.07.2012

Tags : Web, Programmation, Ma vie, PHP, Développement, loldev, Technique

Comme si j'en avais quelque chose à faire, aujourd'hui, que PHP soit cassé. J'ai beaucoup de souvenirs désagréables, j'ai beaucoup d’anecdotes qui prouvent, à qui souhaite l'entendre, que ce langage est une horreur sans nom, un fléau apocalyptique. Je peux, sans effort autre qu'une perte de temps, prouver et alimenter chaque attaque envers ce langage, et sa communauté. D'autant que je le connais particulièrement bien (mon compte twitter et mon adresse mail sont là pour ça).

Ah ça, si j'avais été payé à la peine et à la frustration causées par ce langage, je serais multimilliardaire. Mais ce n'est pas le cas, car, comme je l'ai constaté à de très nombreuses reprises, le nombre important de développeurs PHP permet d'en faire des développeurs low-cost. Je vous épargne les citations à ce sujet.

Continuez d'utiliser PHP, cela ne me regarde plus. J'ai choisi de travailler avec d'autres langages - principalement python il est vrai, mais pas que - et j'en suis très heureux. Je n'habite pas à Paris, je ne suis pas en télétravail, je ne travaille pas dans une petite start-up innovante, bref, je suis dans une entreprise standard, dans un contexte plutôt neutre, qu'il sera difficile de traiter de "hipster" ou de "niche".

La question pour moi n'est plus de savoir si PHP est bon ou mauvais : il est cassé, et en cela il ne répond plus à aucun de mes besoins. La simplicité d'usage ? La facilité de déploiement ? Je les ai obtenues très largement avec python, qui propose plusieurs façons d'avoir une pile web complète, performante, c'est particulièrement bluffant. Petit indice : il n'y a pas que du python dans un tel système, et il demande un peu plus de compétences que savoir utiliser FileZilla (un logiciel FTP très connu sous Windows). Je n'ai jamais dit que c'était pour le premier débutant venu, mais en même temps, ce n'est pas mon métier pour rien.

Quand j'ai une application serveur (avec une GUI web) en python, je peux lui demander son état. Je peux lui demander avec qui elle communique, et avec combien de processus elle communique. Je peux lui demander de recharger sa configuration, de modifier son comportement. Je peux gérer très finement le nombre de processus qui opèrent en parallèles, visualiser, orchestrer et administrer tout cet ensemble.

Et le tout, avec une facilité qui fait pâlir d'envie le développeur PHP que j'ai été. Qui fait pâlir d'envie n'importe quel sysadmin devant gérer une plate-forme avec plusieurs centaines de serveurs. Oui, le besoin est plus complexe, mais la complexité de la solution n'est pas proportionnelle, ni exponentielle, comme elle l'est avec PHP.

C'est là mon témoignage : faites ce que vous voulez en PHP. Je le connais trop bien, et je peux comparer, tous les jours, à quel point j'avais tort, à quel point la simplicité de son écosystème n'était qu'un mensonge.

Vous n'êtes pas convaincu ? Tant pis pour vous. Moi, je m'éclate. Rien ne pourra vous convaincre, tant que vous ne comprendrez pas les autres langages, un autre système que celui de PHP.

PHP n'est qu'un mensonge.

UnicodeEncodeError : fichiers, formulaires, django et gunicorn

Par Florian Strzelecki - 17:17 - 09.03.2012

Tags : Django, Python, Programmation, Développement, Charset, Problème, Technique

L'erreur bête et très frustrante du jour vient d'un petit formulaire qui permet de téléverser un fichier quelconque sur le serveur. Vous me direz, c'est la base du formulaire web avec des fichiers, et il ne devrait pas y avoir de soucis particuliers... sauf lorsque lesdits fichiers ont des accents dans le nom de fichier, et qu'une erreur aussi frustrante que difficile à analyser débarque avec ses gros sabots.

Alors, premier réflexe : chercher sur le net, entre Stack Overflow et le tracker de bug de django. Vous pourrez tomber sur ce genre de discussions : UnicodeEncodeError: 'ascii' codec can't encode character.

Cela donne déjà un premier aperçu d'où vient le problème, à savoir, une configuration de locale sur l'environnement serveur. Pour vous en dire plus, voici les symptômes auxquels j'ai été moi-même confrontés :

La première "solution" qui est proposée, c'est que l'environnement serveur soit correctement configuré, avec, entre autre, une modification du fichier /etc/apache2/envvars. Personnellement, j'ai essayé, mais cela ne fonctionne pas.

Bref, que faire dans ces cas là ?

Comprendre et analyser le problème

Je ne suis pas un expert, mais voici ma démarche pour comprendre puis résoudre ce problème.

Tout d'abords, j'ai regardé la locale de la machine à l'aide de la commande locale, et j'ai obtenu ceci :

LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Ensuite, j'ai lancé l'interpréteur python, pour en savoir plus :

>>> import locale
>>> locale.getlocale()
(None, None)
>>> locale.getdefaultlocale()
('fr_FR', 'UTF-8')

Bon, je remercie ici mYk et linova sur IRC de m'avoir fait chercher dans ces directions, et de m'avoir proposé ensuite de vérifier la valeur de ces informations là dans le contexte de mon application django. J'ai donc affiché ces valeurs dans un template et voici les valeurs que j'ai obtenues avec le serveur de dev de django :

loc: (None, None)
loc_def: ('fr_FR', 'UTF-8')

Puis la même chose, mais avec gunicorn :

loc: (None, None)
loc_def: (None, None)

À partir de là, j'ai pu enfin comprendre le problème, et comment le résoudre. Merci à linova pour l'idée sur IRC.

Merci encore une fois au chan #djangocong sur freenode !

Résoudre le problème

J'utilise runnit pour gérer mes différentes applications servies par gunicorn, et j'ai donc des petits scripts (comme pour init.d), dans lesquels j'ai ajouté ceci :

export LC_ALL=fr_FR.UTF8

Et c'est tout. Oui, tout à fait, c'était juste ça : la locale n'était pas définie dans ce contexte très particulier, et pas dans un autre, ce qui explique tout mon problème avec ces foutus fichiers. J'ai redémarré les différentes applications, et je n'ai plus constaté de problèmes.

Alors, si vous aussi vous avez ce problème, je vous conseille de suivre la même démarche que moi : vérifiez vos locales, vérifiez vos locales via l'interpréteur python d'une part, puis dans le contexte de votre application plus spécifiquement.

Enfin, allez voir du côté du script de votre serveur, et voyez s'il n'y a pas quelque chose à faire avec.

Python-epub : un projet sous licence libre pour le format epub

Par Florian Strzelecki - 18:05 - 08.03.2012

Tags : Python, Programmation, Format ouvert, Développement, Livre numérique, epub, Technique

Ce n'est pas sans une certain appréhension que je publie ce billet, où je souhaite vous parler de mon travail actuel : la bibliothèque python-epub, placée sous licence libre (LGPL), et disponible officiellement sur pypi.

De l'appréhension, car je n'ai pas la prétention d'être un maître dans l'art du code python d'une part, pas plus qu'être le plus grand expert du format epub d'autre part. Et puis, surtout, c'est la première fois que je publie vraiment du code sous licence libre !

Mais, passons mes états d'âme pour aller au cœur du sujet.

Téléchargement et installation

Tout d'abords, si vous cherchez directement comment l'installer, et avoir une documentation technique, vous pouvez aller sur le site officiel du projet : http://epub.exirel.me. Il est à jour et documente la dernière version publiée (et pas la version en cours de développement).

Pour faire simple : utilisez pip install epub. Si vous voulez la version de développement (je ne garantis pas la stabilité dudit code), vous pouvez faire un clone des sources disponibles en ligne : https://bitbucket.org/exirel/epub.

À quoi ça sert ?

En premier lieu, à ouvrir des fichiers au format epub, dans la version 2 de la spécification (la 3 restant encore trop jeune et trop peu utilisée pour le moment). Qu'est-ce que le format epub ? Il s'agit d'un format ouvert de livre numérique. Il est utilisé de manière majoritaire dans l'édition numérique, et peut être lu par des applications sur mobiles et tablettes, et surtout, sur des liseuses à écran à encre numérique (de type Kobo ou Cybook Odyssey). Je n'entre pas ici dans la polémique autour des autres formats, ce n'est pas le sujet (mais vous pouvez toujours me poser des questions par email, ou via twitter et g+).

Le format Epub 2

Le principe d'un fichier epub, c'est d'avoir un fichier compressé au format Zip, qui contient plusieurs fichiers importants :

Les autres fichiers composent le "vrai" contenu du fichier epub et sont référencés de plusieurs façons, tant par le fichier OPF qui en fait une liste exhaustive, que par le fichier de navigation NCX qui propose une navigation pour l'utilisateur (comme une table des matières, des illustrations, etc.).

Le code python

De son côté, la bibliothèque python-epub permet de représenter les données d'un fichier epub : fichier OPF, fichier NCX, et le contenu du fichier. Elle est même découpée en trois parties :

Ce découpage logique permet une grande souplesse dans l'utilisation de cette bibliothèque. De prime abord, elle ne permet (pas encore) de générer un fichier epub, mais certains éléments sont déjà manipulables en dehors d'un fichier epub pur : c'est le cas pour le format OPF et le format NCX, dont les modules dédiés permettent d'une part de lire ces formats, mais aussi de générer des fichiers dans ces formats.

Le projet

Licence libre : LGPL

Le projet est placé sous la licence libre LGPL : elle correspond à ma volonté, en tant qu'auteur, de rendre libre le fruit de mon travail pour les utilisateurs. Si d'autres développeurs souhaitent utiliser mon travail (avec ou sans modification) ils n'auront pour seule obligation que de donner les mêmes droits sur cette partie là de leur travail (par exemple, dans le cas d'une application, seule ma bibliothèque devra être sous une licence libre compatible, pas l'ensemble de l'application).

Je pense d'ailleurs que c'est la seule chose pour laquelle je n'envisage pas de changement, contrairement au code en lui-même.

Les évolutions à apporter et celles envisagées

Pour le reste – le code concret, mais aussi la documentation – j'envisage beaucoup d'évolutions, et certaines dont je ne suis pas encore sûr de la façon de les implémenter. Tout d'abords, pouvoir créer et modifier des fichiers epub : il est plutôt simple de lire un fichier epub, mais l'écriture pose beaucoup d'autres questions.

En vrac, j'ai listé les améliorations/évolutions suivantes :

Il y a encore beaucoup à faire pour que je sois pleinement fier de ce projet, mais j'avance correctement, je fais attention à la qualité du code, aux tests unitaires, et à la documentation. Je pense donc que ça va dans le bon sens.

Appel à contribution

Pour le moment, je suis le seul développeur sur ce projet, que j'ai initié en début d'année, mais si j'ai choisi une licence libre, c'est bien pour laisser la place à d'autres personnes.

Ce que je cherche ? Les bonnes volontés : contributions au code, des retours d'expérience, des demandes d'ajouts de fonctionnalités, des rapports de bugs, pourquoi pas des traductions de la documentation ?

Comme je le disais en début de billet : je ne suis pas un maître pythoniste, et au vu de mon expérience, je ne doute pas un instant qu'il me reste beaucoup à apprendre. Je prends donc toutes les remarques et critiques constructives, les avis, les optimisations, les conseils... tout !

Migration vers Django 1.3

Par Florian Strzelecki - 19:41 - 07.03.2012

Tags : Django, Python, Web, Programmation, Développement, Optimisation, Technique

Sur ma liste des choses à faire, il y avait cette migration concrète de mon site&blog vers Django 1.3. Il faut savoir que j'ai développé à l'origine avec la version 1.1, en ajoutant à l'occasion quelques petites choses de Django 1.2 lorsque j'ai mis à jour mon serveur.

Aujourd'hui, mes dernières applications sont développées avec Django 1.3, et il y a quelques petites choses en plus que j'apprécie bien. Je vous propose donc un retour d'expérience, avec un tour d'horizon de ce que j'ai modifié et eu à modifier.

Nommer les urls

Je n'avais pas touché à mon fichier urls.py depuis longtemps, et j'ai donc commencé par là : remettre certains trucs à plat, et rendre le tout plus propre et plus facile à maintenir.

Premier truc : utiliser la fonction url, qui permet entre autre chose de nommer ses urls, ce qui est très pratiques pour la suite, comme, par exemple, ne pas s'embêter à écrire des urls en dur dans les templates.

Exemple de template (avec Django 1.3) :

{% load url from future %}
<p>Lire l'article : <a href="{% url 'entry' entry.url %}">{{entry.title}}</a></p>

Vous noterez l'usage de {% load url from future %}, car le template-tag url a un comportement modifié pour les futures version de Django.

Du côté de la view, cela permet aussi de se simplifier la vie :

def redirect_to_tag(request, section_url):
    """Section now redirect to tag."""
    return redirect('tag', permanent=True, tag_url=section_url)

J'ai simplement nommé l'une de mes urls "tag", et la fonction redirect s'occupe du reste. Si je change la forme des url des tags, je n'aurai pas à changer le code de cette view.

Séparer media et static

Apparu avec Django 1.3, la gestion des fichiers "statiques" a été grandement amélioré par l'intégration de django-staticfiles directement dans le projet Django en tant que django.contrib.staticfiles.

J'ai pu découvrir son fonctionnement avec mon dernier projet (un truc secret pour le moment...), et c'est vraiment très pratique. Le principe ? Au lieu d'avoir un répertoire de médias, intégrant les fichiers de l'application (css, js, etc.) et les fichiers téléversés par les utilisateurs, il y a maintenant deux espaces différents.

Je ne vais pas détailler ici tout ce que j'ai eu à faire mais voici un rapide résumé :

Ensuite, pour lancer la collecte, la commande suivante fonctionne très bien :

python manage.py collectstatic

Au passage, j'ai aussi simplifié un peu ma configuration Apache, mais ça, c'est un autre sujet.

Et d'autres petites choses...

S'il n'y avait que ça, ce serait trop facile. Et bien, en réalité : il n'y avait que ça.

J'avais déjà fait une première passe pour simplifier grandement le code, faire le ménage, et retirer ce qui n'était pas bien fait et/ou bien pensé (avec un code qui a presque deux ans, c'est normal, j'ai beaucoup appris pendant ce temps). Du coup, une migration assez simple, avec, au déploiement, pas un seul soucis.

J'ajoute, au passage, que c'est une bonne expérience, qui permet de revenir sur ce qui a été fait avant, et sur ce que je fais aujourd'hui - et donc, de pouvoir mesurer l'écart.

Je développe donc j'écris des tests unitaires.

Par Florian Strzelecki - 02:07 - 18.05.2011

Tags : J'aime, Programmation, Bonne pratique, Développement, Unit Testing, Technique

Suite à mon article sur PHPUnit, il m'a été posé la question, fort simple dans sa forme, de "Mais pourquoi faire des tests ?".

Après tout, cette question, je me la suis aussi posé avant de faire des tests, ainsi qu'à mon premier apprentissage, et encore aujourd'hui quand j'écris tel ou tel morceau de code, je me demande à quoi servent les tests que je vais écrire, ou que j'ai déjà écrit.

Je vais essayer de faire rapide, car expliquer "pourquoi faut-il faire des tests" n'est pas mon but premier : tout un tas de gens ont écrit tout un tas de choses sur le pourquoi comment, avec études théoriques et pratiques. Non, moi, je vais me contenter de vous exposer, de manière très subjective, pourquoi je fais des tests unitaires.

Djangocong 2011 à Marseille : c'était le 16 et 17 Avril, et c'était génial

Par Florian Strzelecki - 18:36 - 26.04.2011

Tags : Django, Web, J'aime, Développement, Djangocong, Technique

Avec un peu de retard (c'était il y a une semaine), voici mon petit "compte-rendu" sur la Djangocong, qui se tenait, pour sa seconde édition, à Marseille, les 16 et 17 Avril 2011.

Cette année, donc, j'ai pu y aller, contrairement à l'année dernière, et ce ne sont pas les 6h du Rennes-Marseille (une ligne directe TGV) qui m'en empêchèrent. Même si, à tout prendre, je préfèrerais un lieu plus proche de chez moi pour les prochaines éditions.

La Djangocong, c'est la rencontre d'une communauté, principalement de développeurs francophones, autour du framework python pour le web : Django. Je développe avec ce framework depuis environ 2ans, et il m'apporte tant de satisfaction que j'ai même cherché un travail dans ce domaine - peine perdu, le marché à Rennes est surtout orienté Java.

Mais restons sur la Djangocong :

Cependant, il est difficile de résumer la Djangocong en quelques lignes (même cet article ni suffit pas), car la volonté des organisateurs fut de faire de cette rencontre autre chose qu'une suite de conférences techniques. Djangocong, c'est une rencontre entre humains, qui échangent, partagent, discutent, débattent, lancent de belles idées et rentre chez eux avec le sentiment d'appartenir à une communauté.

Djangocong 2011

Image : Djangocong 2011 - Florian Strzelecki - Creative-Common By-NC