Blog // Exirel.me

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

Identité, authentification, et autorisation

Par Florian Strzelecki - 00:31 - 05.08.2015

Tags : Web, Technique, Vulgarisation, Sécurité, Identité, Authentification, Autorisation

La gestion de l'identité et des comptes utilisateurs est un problème très courant dans le développement web : nous construisons des interfaces de gestion, des "back offices" pour les utilisateurs, et des "dashboards" pour les opérateurs ; bref, nous donnons un accès privilégié à certains utilisateurs.

Pour autant, je suis toujours un peu surpris du manque de culture autour de ces trois notions, qui ne sont que rarement vues comme trois domaines distincts - ce qu'elles sont pourtant. Alors, une fois n'est pas coutume, j'ai envie d'aborder ce sujet là, en essayant de rester simple.

Identité

L'identité d'une personne, c'est qui elle est. Par exemple, je suis Florian Strzelecki, et je suis aussi @Exirel. Ce sont des identités : quelque part, ce sont les données qui existent sur moi. Ces données peuvent être plus ou moins publiques, et peuvent être partagées avec plus ou moins de degrés de confidentialité.

Lorsqu'Amazon affiche mon nom en haut à gauche ou dans mon panier d'articles, c'est mon identité que j'ai chez Amazon qu'il utilise.

Par nature, l'identité n'est pas une clé ni une autorisation : je peux toujours prétendre être quelqu'un d'autre, il me faut plus qu'une identité pour avoir de la crédibilité.

Authentification

C'est là qu'entre en jeu l'authentification : c'est le fait de garantir l'authenticité des informations fournies. De dire : je suis bien le "moi" que je dis être.

Par exemple, toujours sur Amazon, lorsque je souhaite passer au paiement d'une commande, je dois prouver que je suis bien moi, en fournissant mon identifiant de compte, et le mot de passe associé. J'apporte la garantie de l'authenticité de mes propos lorsque je dis que je suis bien moi, en utilisant une information qui n'est connue que de moi seul (à noter qu'Amazon ne possède pas mon mot de passe, mais le moyen de vérifier que celui que je donne correspond bien à l'information qu'il possède).

Cependant, rien ne dit que l'authentification a besoin de l'identité : imaginez que vous vous rendez à un club privé où il faut fournir un mot de passe. Dans ce cas, rien ne dit qui vous êtes, votre mot de passe ne fait que dire que vous êtes un utilisateur authentifié - ou une utilisatrice authentifiée, il n'y a pas de raison d'exclure quelqu'un s'il ou elle a le mot de passe.

C'est d'autant plus important de comprendre la différence entre l'identité et l'authentification, car l'un est public (ou partageable), et l'autre doit rester secret. Prenez la biométrie : bien que théoriquement unique et personnel, les informations restent publiques. Il suffit de laisser une trace de doigt sur une porte, et il y a au moins votre ophtalmologiste pour connaître les motifs de vos yeux. Et pour un peu, votre ADN est déjà dans un fichier de police...

Ainsi, la biométrie n'est pas un bon moyen de s'authentifier : c'est, au mieux, un excellent moyen de définir une identité, aussi bien qu'un identifiant de compte.

Il y a, bien entendu, d'autres applications à cette différence : vous pouvez très bien obtenir un jeton d'authentification (ou "token" en Anglais) pour accéder à un service, tout en restant anonyme.

Autorisation

Le dernier point est le plus facile à distinguer des deux autres : il s'agit de définir ce à quoi une personne (identifiée ou non) a droit ou non, ce à quoi elle a accès ou non.

Amazon me laisse choisir des produits et payer ma commande, mais il ne me permet pas d'avoir accès aux commandes des autres utilisateurs.

L'autorisation cependant a besoin soit de l'identité, soit de l'authentification :

Pour reprendre l'exemple du club privé, chaque membre qui a un mot de passe a exactement les mêmes droits (et devoirs) que les autres. Il n'y a pas de différence entre l'identité de l'un et de l'autre.

Sécurité et données

Lorsque l'on parle de sécurité, ces trois notions se retrouvent très vite sur la table : que ce soit pour accéder à des données ou à des services. Il est important de comprendre chaque concept, et de comprendre où et comment il s'applique à chaque situation - et à chaque besoin.

Par exemple, certaines informations sont liées à l'identité d'une personne (son nom, son identifiant, etc.), alors que d'autres ne sont liées qu'à son ordinateur ou à son téléphone (l'IP, le navigateur, l'emplacement géographique). Le traitement sera alors différent, et les techniques pour assurer la sécurité du système le seront tout autant.

De même, bien séparer l'identité de son authentification permet de faire évoluer l'un et l'autre séparément : peu importe si vous utilisez HTTP ou HTTPS pour connaître votre prénom, alors qu'il vaut mieux chiffrer les mots de passe dans une base de données (pour que cela reste un secret).

Bref, ce ne sont que quelques explications (un peu imprécises, je m'en excuse) sur ces trois notions, et j'espère que vous serez moins perdu la prochaine fois que quelqu'un vous parlera de l'authentification et des autorisations associées à votre identité.

Mise à jour

Par Florian Strzelecki - 20:47 - 14.07.2015

Tags : Bonjour, Django, Web, Ma vie, Divers

Heh, ça fait longtemps, non ? Depuis Novembre dernier, je n'ai rien publié ici. Je n'en avais pas l'envie la plupart du temps, et pas la motivation le reste du temps. J'avais envie de mettre à jour le site, le blog, le serveur, l'application, etc. comme une excuse avant de publier à nouveau (et, quelque part, avant d'écrire à nouveau).

Un peu de style

Pour commencer, j'ai donc regardé comment "améliorer" le style du blog. Rien de très folichon : j'ai opté pour un design encore plus sobre, encore plus épuré, avec une grosse police de caractères. D'ailleurs, je n'ai indiqué aucune police en particulier : c'est du sans-serif pour les titres, et du serif pour le texte. C'est un choix délibéré de ma part.

Je vais sans doute retravailler un peu cela prochainement, si l'envie m'en prend. Mais pour le moment, cela me suffit ainsi.

Un peu de script

Il y avait pas mal de JavaScript inutile sur ce blog (des reliquats d'un temps ancien). J'en ai donc supprimé une bonne partie pour ne garder que l'essentiel (ie. un plugin pour les images, qu'il faut que je change aussi).

Au passage, je suis passé à Grunt pour gérer tous mes fichiers "frontend" (ie. le CSS et le JavaScript). Ce n'était pas très compliqué, et une fois les bases posées, c'est allé assez vite.

J'ai presque envie de dire que j'ai apprécié cette expérience.

Un nouveau serveur

Parce qu'il n'était pas question de garder un vieux Ubuntu 10.04 en production, j'ai opté pour un nouveau serveur, avec Ubuntu 14.04 - je reste donc sur des LTS.

Je suis aussi passé de Apache à nginx, et de Gunicorn à uwsgi. Enfin, j'ai laissé de côté runit pour utiliser upstart.

Le plus difficile a été de configurer l'ensemble correctement, en utilisant des fichiers de configuration valides, avec des variables d'environnements qui contiennent les données sensibles avec un accès en lecture seule pour l'utilisateur root seulement.

Il me faut encore configurer proprement le système de log, et ajouter une supervision à mes nouveaux serveurs (j'avais déjà migré d'autres applications sur un autre serveur auparavant).

Django avec Postgres

Auparavant, j'utilisais exclusivement MySQL. J'ai, depuis, décidé de braver les épreuves pour apprendre à installer et utiliser correctement PostgreSQL. Je suis loin d'en maîtriser les arcanes, mais je sais au moins créer les utilisateurs, les bases de données, et configurer proprement les droits d'accès.

Enfin, il n'était pas question de rester sur une version non-supportée de Django, et j'ai donc tout naturellement migré vers Django 1.8.

J'ai donc pu :

Lâchez vos com'

C'est la grande nouveauté en terme de fonctionnalité. C'est une petite révolution pour moi : j'ai accepté d'utiliser Disqus. J'avais choisi à l'origine de ne pas mettre de commentaires sur mon blog, car la gestion du spam est particulièrement pénible, et que, la plupart du temps, la qualité des commentaires n'étaient pas suffisantes pour justifier le travail supplémentaire.

Avec Disqus, j'ai ouvert les commentaires en déléguant cette partie à un prestataire. Je verrai bien à l'usage ce qu'il en est. Alors n'hésitez pas.

J'autorise les anonymes à écrire des commentaires, mais tous emails non encore validés devra attendre une modération avant de voir ses commentaires publiés. L'avenir nous dira s'il faut apporter des modifications à ce système.

Bref, allez-y, vous pouvez commenter. Mais n'espérez pas trop de mises à jour, je publie souvent par paquet de billets d'un coup, sans aucune fréquence particulière.

Framework overflow

Par Florian Strzelecki - 00:02 - 10.11.2014

Tags : Framework, Web, Bonne pratique, twitter bootstrap, Angular.js

Je mets toujours beaucoup de temps avant d'adhérer à un framework. Contrairement à ce que l'on pourrait croire, je ne suis pas du genre à adhérer à une nouvelle technologie qui vient à peine de sortir, pas plus que je ne me jette à corps perdu dans un nouveau framework ou une nouvelle méthode. Il faudrait sans doute que j'écrive un long article sur le sujet à l'occasion, car je suis presque sûr que mes amis me voient comme le plus hipster d'entre eux en la matière.

Si vous ne l'avez pas encore fait, je vous invite à lire cet excellent article "Stop Breaking the Web", qui aborde un problème récurrent dans le monde du développement web : l'usage abusif de frameworks et de solutions qui ne résolvent pas les bons problèmes.

Si sur la forme je retrouve la rengaine habituelle de ce que nous devrions faire et que nous ne faisons pas (faire du progressif au lieu de chercher à supporter tous les navigateurs de la même façon), sur le fond, il y a plusieurs points intéressants qui sortent de l'ordinaire ; et avec lesquels je suis tout à fait d'accord.

Dans les passages qui ont attiré mon attention il y a celui-ci :

You should be delivering the content in human-viewable form first, [...] then you can add your fancy JavaScript magic on top of that.

Je ne peux qu'insister lourdement sur cette approche qui n'apporte pas seulement quelques bénéfices : cette approche est la base même de tout ce que nous devrions faire.

Nous devrions faire un premier rendu, sans JavaScript et avec un CSS si possible minimal, de sorte à pouvoir donner l'accès au contenu. C'est le contenu que les utilisateurs, que les êtres humains, viennent chercher en premier. Et il n'est jamais trop tard pour ajouter une couche de JavaScript par dessus.

De plus, cela permet d'avoir un socle solide, unique, et stable, sur lequel s'appuyer pour faire tout le reste : la vue mobile, la vue tablette, la vue desktop, avec ou sans JavaScript, avec ou sans la dernière mise à jour du navigateur.

C'est la base même du web, et cet article nous rappelle à quel point nous l'avons oublié.

Robustesse et anti-fragile

Il y a quelques temps déjà un de mes amis, Sylvain, me disait que nous ne devrions plus penser avec des applications monolithiques, que nous devrions repenser notre façon d'aborder les tests, mais surtout, que nous ne devrions plus chercher à faire des applications robustes, mais penser nos applications avec une approche anti-fragiles.

L'idée, c'est que quoi qu'il arrive, un ensemble minimal doit toujours rester fonctionnel. Que ce qui ne marche pas ne devrait pas avoir d'effet sur le reste, autre que retirer une partie des fonctionnalités.

J'ai un exemple très récent en tête, une expérience désastreuse avec Angular.js : suite à un bug dans la gestion de l'état de l'application, une erreur impromptue bloquait toute l'application, la rendant complètement inutilisable à moins de recharger la page. Certes, il y avait des contrôles pour que l'application soit robuste, mais à la première erreur imprévue, plus rien du tout ne fonctionnait.

Ce genre de problème ne devrait pas arriver : les bugs sont toujours possibles, mais nous devrions être capable de faire en sorte qu'ils aient le moins d'effets de bords possible, et de toujours garder une base fonctionnelle quoi qu'il arrive.

Les choses à l'envers

Le second point soulevé par cet article est que nous faisons les choses à l'envers. Nous ne devrions pas chercher à supporter toutes les nouvelles fonctionnalités dans les vieux navigateurs : à la place, nous ne devrions activer les fonctionnalités que si le navigateur les supporte :

We are doing things backwards. We are treating modern browsers as "the status quo", and logically if someone doesn't conform to "the status quo", we'll be super helpful and add our awesome behavioral polyfills.

La mise en exergue est de moi.

Là encore, c'est pourtant quelque chose qui devrait nous sembler évident. Si quelqu'un utilise un vieux navigateur, il est aussi tout à fait possible qu'il utilise un vieux PC. Ou pour une raison ou une autre, il a des limitations sur son environnement de navigation (peut-être qu'il utilise un bloqueur de pub un peu trop agressif, certes, mais il faut bien dire que les pubs sont souvent très agressives aussi).

Qu'est-ce qui intéresse vraiment l'utilisateur ? Un super système de routage d'URL côté client ? Ou le contenu ? Les textes ? Les images ? Ou appuyer le bouton "ajouter au panier" ? Remplir le formulaire de contact ?

Tous ces problèmes de développement pourraient se résumer à "faire les choses biens". J'aimerais ajouter cependant un petit conseil, donné par ma compagne : nous devrions créer nos applications en se basant sur les conditions d'accès de la zone Afrique - Asie du Sud ; des connexions lentes et du matériel dépassés.

Car quand on y pense, entre les connexions en Edge (ou même la 3G ce n'est pas toujours parfait), et la flotte de vieux terminaux Android et les iPhone 4 devenus trop lent avec les dernières mises à jours, ce sont, peu ou prou, les conditions de nos utilisateurs au quotidien. Et je ne parle même pas de tous ces PCs dans les entreprises qui n'utilisent que les versions spécifiques de Firefox (parfois bloquées dans une version ancienne) ou d'IE (avec un Vista ou un Seven jamais mis à jour et IE8 ou 9).

Un peu de bon sens ! Voici ce dont nous aurions bien besoin.

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).

Les versions et les API (partie 2)

Par Florian Strzelecki - 17:23 - 16.01.2014

Tags : Web, Bonne pratique, Technique, API, Version, HTTP, Hypermedia

Si vous ne l'avez pas déjà fait, je vous invite à lire la partie 1, qui parle d'applications installées plusieurs fois, dans des environnements clients spécifiques à chacun, et où, finalement, le numéro de version dans l'URL n'a pas beaucoup de sens.

Sommaire

  1. Partie 1 : L'application fournie un service via une interface (ou plusieurs)
  2. Partie 2 : Le service est fourni par une (ou plusieurs) applications

Le service est fourni par une (ou plusieurs) applications

Dans la partie 1 donc, j'ai présenté un exemple de SIGB, qu'il faut installer dans un environnement client. Cette fois, je vais prendre le même SIGB, mais avec un seul serveur centralisé : vous êtes alors en position de fournisseur de service, comme peut l'être Facebook, Twitter, Google, et bien d'autres.

Dans ce contexte, il existe des différences fondamentales avec le contexte précédent :

  1. Chaque version de l'application n'est installée qu'une seule fois (par vous)
  2. Les mises à jour sont indépendantes de la volonté des clients
  3. Chaque client décide à quel moment il exploite un changement rétro-compatible
  4. Chaque changement non rétro-compatible impose une adaptation du client (immédiate ou différée)

Les contraintes et les attentes n'étant pas les mêmes, la notion de version peut être traitée différemment.

Ma timeline

Par Florian Strzelecki - 16:15 - 19.05.2013

Tags : Web, Société, Twitter, Ma vie

J'ai arrêté de suivre des gens sur Twitter. Je clique de plus en plus sur le bouton "unfollow", à mesure que le temps passe. De plus de 900 following, je viens de redescendre à 750, et je pense que cette tendance va se confirmer prochainement.

J'aime de moins en moins ce que les gens font de Twitter.

Si je suis quelqu'un, c'est parce que son avis m'intéresse. Ça ne veut pas dire que je suis d'accord, mais que ses avis me permettent de forger les miens, de confronter mes pensées aux siennes. Peu importe le sujet d'ailleurs : développement logiciel, photographie, gadget, sexisme, politique, culture, open-data, wikipédia, ou tout ce qui touche au droit d'auteur. Et bien d'autres, j'aime surtout la diversité des sujets.

Pour chaque sujet je trouve des gens intéressants à suivre. Des gens qui ont des choses à dire, et pas toujours la même rengaine. Des gens qui peuvent m'apporter différents angles de vue sur le même sujet. Des gens qui vont faire progresser ma réflexion. Et pas des gens qui se content de RT les mêmes phrases, les mêmes articles, en boucle.

De la même façon, il m'arrive de suivre des personnes qui racontent leur vie via twitter, qui relatent leurs sorties, qui partagent leurs activités. Parce que cela me donne un aperçu de leurs avis, cela me donne leur vision du monde, différente, complémentaire, de la mienne. Et pas seulement "j'ai mangé une pomme", ce sont en général des gens passionnés par quelque chose (voire souvent, par plusieurs choses).

Dans ceux que j'arrête de suivre, il y a tous ceux qui avait quelque chose d'intéressant, ou dont la production par ailleurs est intéressante (textes sur un blog, vidéos sur youtube, photos ou dessins ici ou ailleurs), et puis qui, au fil du temps, ne m'apportent plus rien. Je peux continuer à suivre la production de quelqu'un tout en refusant de le suivre sur Twitter : trop de promotion, pas assez d'opinion.

Il y a aussi ceux qui ne parlent plus que d'un seul et unique sujet, toujours selon la même approche, avec la même opinion. C'est assez fréquent avec les partisans : en tête des comptes que j'arrête de suivre, ceux du Parti Pirate, d'EELV, du Front de Gauche, et autres "je tweet/retweet toujours la même opinion". Je m'en contrebalance complètement, au bout du 5ème tweet, que machin est contre [SUJET SUPER SÉRIEUX], j'avais compris dès le premier tweet. Je ne veux pas recevoir en boucle l'exacte même position sur les exacts mêmes sujets.

Enfin, dans ceux que j'ai suivi pour leurs opinions, il y a ceux avec qui j'ai de plus en plus de mal : ceux qui ont la colère facile, ceux qui ragent en permanence, ceux pour qui mettre quelqu'un au pilori est une bonne façon de faire. Ceux pour qui le moindre mot de travers est une insulte à l'espèce humaine, ceux pour qui la moindre question est un appel à une sainte croisade contre les autres.

Le pire, c'est que je suis souvent d'accord avec eux. Mais non, je ne veux pas de leur haine et de leur agressivité quasi permanente dans ma timeline. Je ne veux pas voir, tous les jours, des "shit storm" qu'ils ont eux-même déclenchés, par leur attitude détestable.

Parce que finalement, ce sont un peu eux, les trolls dans ma timeline.

Pour qui sont les API ?

Par Florian Strzelecki - 23:51 - 19.12.2012

Tags : Web, Programmation, Bonne pratique, Technique, API

Bonne question n'est-ce pas ?

Normalement, vous avez deux réactions possibles si vous n'êtes pas développeur :

Oui, mais non. Enfin "presque". C'est compliqué.

Je m'amuse souvent à me décrire comme un #apidealer, parce que c'est un domaine qui me passionne. À dire vrai, le concept de deux machines pouvant communiquer, s'échanger des informations, et ce, sans la moindre intervention humaine pour ça, j'ai toujours trouvé cela magique, et c'est toujours ce que j'ai voulu faire.

Ce qui m'amène à mon premier point : une API, c'est fait pour des machines. Ce sont des machines qui vont appeler l'API, qui vont prononcer les doux verbes HTTP servant à récupérer les données, à envoyer des commandes, à demander des traitements.

En gros, pas besoin de parler comme avec les humains. Pas non plus besoin de parler comme avec un navigateur, parce que - c'est peut-être une révélation pour vous - mais le navigateur, c'est vraiment très limité pour appeler une API (sans extension/plug-in/greffon, je veux dire).

Si nous faisons des API, c'est pour permettre d'écrire des applications qui pourront comprendre les données que nous voulons les voir traiter.

Ce qui m'amène à mon second point : une API sert aux développeurs. Ce sont là les premiers usagers des API. Déjà, parce que ce n'est pas sexy comme un beau site web ou comme une jolie petite application sur son smartphone. Moi je trouve ça sexy as hell, mais je pratique le #datalove alors bon ça compte pas. Ensuite, parce que sans le travail du développeur, l'API ne sert à rien.

Une API doit être facile d'accès pour le développeur. Faire ressortir le meilleur de lui-même et de ses capacités. En échange, le développeur doit prendre soin de l'API, la mettre en valeur, ne pas la sur-exploiter pour rien. Bref, une histoire d'amour - mais seulement entre l'API et un développeur.

Il ne reste plus qu'au développeur d'être responsable, et de fournir de bons et loyaux services aux usagers finaux des données. Oui, des données, pas de l'API. Nuance.

Pourtant, ce soir j'ai entendu à peu près cette rengaine de la part d'un homme qui, par ailleurs, a un réel soucis pour ses usagers (ce que je respecte profondément et sincèrement) :

"Pour modifier l'API il faut que ça serve aux usagers.".

Et par usagers, il entendait les usagers du service qui génère les données (ici, un réseau de transport en commun - ce qui fait un paquet de données). Il entendait les usagers finaux, les gens comme vous et moi qui utilisons un service tous les jours, de manière très concrète, dans le monde physique. Tiens, rien que ce matin j'ai pris le métro, puis le bus, et pour rentrer ce midi pareil.

Oui, mais non. L'API n'est pas faite pour les usagers. Elle permet à des développeurs de proposer des services aux usagers. C'est là la grande nuance.

Si vous ne voulez pas faciliter le travail des développeurs, alors ne fournissez pas d'API. Mais ne délivrez pas une API pour vos usagers. Ce ne sont pas les cibles d'une API. Donnez des outils aux développeurs, et eux feront les outils pour les usagers. Ou alors, faites de vrai outils pour les usagers - et les API ne sont pas des outils pour les usagers.

Une API, c'est une nouvelle histoire d'amour entre un développeur, et une machine.

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.

Mélanger redirection, SEO et Webperf...

Par Florian Strzelecki - 01:12 - 07.07.2012

Tags : Web, Bonne pratique, Optimisation, Technique, #trolldredi

Je suis toujours fasciné par la capacité de mes contemporains à chercher la moindre petite bête, le moindre petit détail, là où il n'y a pas besoin de le faire. Ou à, plus précisément, tenter de résoudre un problème qui n'existe pas.

Suite à l'article Réconcilier SEO et WebPerf au niveau des redirections de (sous-)domaines j'ai discuté rapidement sur twitter... mais manifestement mes objections n'ont pas été comprises (mais c'est difficile avec des tweets de débattre de ça).

D'ailleurs, je vous invite à lire les commentaires de l'article, car deux personnes ont déjà soulevé ce que j'ai essayé de dire. Comme le sujet m'intéresse un peu (et que nous sommes vendredi), je vous livre mes réflexions sur le sujet.

Quel est le problème ?

Première question : quel est le problème ? Non mais, vraiment, où est le soucis d'une redirection (de www vers no-www, ou no-www vers www) ?

Si votre site est bien fait - et il l'est, puisque nous sommes des experts, n'est-ce pas ? - vous n'exposez, au monde extérieur, aucun lien incorrect. Les liens de ces immondes boutons collés avec des scripts externes (et qui suivent à la trace vos utilisateurs qui n'ont rien demandé) utilisent le bon nom de domaine, tout comme vos flux rss, vos newsletters, etc.

Bref, de votre côté, tout est bon, et il n'y a donc pas lieu de craindre ni pour votre référencement, ni pour vos performances. Vous assurez grave, bravo !

Considérons ensuite vos utilisateurs, ces gens bizarroïdes qui utilisent "cmd+entrée", et tapent directement le nom de votre site dans leur barre d'adresse. Concrètement, s'ils perdent 75 millisecondes à attendre que leur navigateur trouve la bonne adresse, puis redirigent vers le bon domaine, je pense que ce n'est vraiment pas un soucis. Par contre, si la moindre petite redirection chez vous implique une seconde, je pense que vous avez de sérieux problèmes à résoudre avec votre serveur.

Quant à ceux qui n'indiquent rien (ni TLD, ni sous-domaine), les comportements varient selon les navigateurs et les configurations : avec un label bien placé sous Firefox, cela revient à cliquer sur un favoris, et sans label, à faire une recherche Google (je viens de re-tester à l'instant, histoire d'être sûr).

Dernier petit point que je souhaite soulever : quel est l'importance d'éviter une redirection totalement minoritaire, alors que nous savons tous - vous le savez n'est-ce pas ? - que les scripts des publicités, comme tous les autres chargement de ressources externes et en dehors de votre contrôle, sont bien plus à même d'effectuer des redirections qui pénaliseront le chargement de la page. Pas seulement le chargement de la première requête, mais bel et bien pendant l'ensemble du chargement de la page. C'est à dire, en même temps que le chargement de vos images, de vos scripts et feuilles de style externes. L'échec complet quoi.

Bref, un non-problème. Mais on va dire que c'est quand même un problème, rien que pour parler des solutions.

Quelle est la solution ?

L'internaute moyen ne vois pas où est le problème d'attendre 75 millisecondes de plus dans le chargement de sa page pour une seule et unique redirection. Par contre, il râle lorsque le site affiche plusieurs publicités, chacune faisant perdre plusieurs secondes à sa navigation. Je dis ça, je ne dis rien. Enfin si, je dis quelque chose, je sous-entends même un petit peu que c'est chercher à résoudre un non-problème, mais je l'ai déjà dit plus haut.

Quant aux moteurs d'indexations, ils doivent être considérés comme des utilisateurs comme les autres. Si vous voulez leur parler, vous avez les codes de réponse HTTP (2xx, 3xx, 4xx mais aussi 5xx). Vous avez aussi les robots.txt et les sitemap.xml - mais je ne vais pas vous apprendre le métier.

Si vous cherchez à les cibler plus particulièrement, vous pourrez tout aussi bien avoir de bonnes comme de mauvaises surprises. Les User-Agents n'ont rien de fiable ni de sûr, ils peuvent changer, ne pas être utilisé comme vous le pensé (je suis toujours aussi surpris du fonctionnement de certains User-Agent), et tout un tas d'autres trucs que seuls les robots qui rêvent de moutons électroniques peuvent comprendre.

Dernier point : si vous commencez à avoir des règles conditionnelles de réécriture d'URL pour ça il est peut-être temps de se demander où vous mène toute cette complexité. Oui, je sais, la simplicité, c'est un truc de hipster-bobo-indépendant-hackiviste. Mais quand même, la simplicité, c'est souvent une bonne pratique de WebPerf.

Un A dans YSlow

Il y a un soucis que je me pose avec cette recherche d'une bonne note de WebPerf. Je ne veux pas remettre en cause la note ou sa recherche. Mais par contre, quel est l'intérêt de tester des liens avec le mauvais sous-domaine ?

Parce que, concrètement, si le fonctionnement normal et principal de votre site, c'est sans le sous-domaine (ou avec, vous remplacez mentalement par l'inverse), en dehors d'une éventuelle phase de transition, vous n'avez aucune raison de tester la mauvaise version. Ou alors uniquement pour vérifier que votre serveur sait faire une redirection rapidement et efficacement.

Le reste, ça n'a pas d'importance.

On me souffle à l'oreille qu'un A dans YSlow n'est pas vraiment un bon objectif. Et je vous épargne la citation exacte pour vos chastes oreilles.

À mes "amis" sur Facebook

Par Florian Strzelecki - 20:00 - 12.04.2012

Tags : Web, Société, Ma vie, Facebook, Divers

Or donc il advint que j'ai un compte sur Facebook. Il m'est arrivé de beaucoup l'utiliser, de trop l'utiliser, de ne rien en faire, je l'ai même clôturé à une période, avant d'y revenir, et de travailler avec son API pour différents projets (notamment du "social-gaming"). Bref, je commence à avoir une certaine expérience de Facebook, et m'intéressant depuis longtemps aux sensibles sujets sur la protection de la vie privée et surtout des données personnelles, j'ai de quoi écrire un livre.

Pourtant, aussi étrange que cela puisse paraître, ce n'est pas tellement pour ces raisons là que j'ai décidé de supprimer mon compte Facebook : je gère très bien ma vie privée, ainsi que la diffusion de données personnelles me correspondant. Je sais prendre mes responsabilités, et mesurer les risques, et surtout en assumer les conséquences. Aussi, Facebook ne m'a pas vraiment posé de problèmes - de problèmes autres qu'idéologique, j'entends.

Aujourd'hui, un compte Facebook ne me sert à rien. Je n'en fais rien, je n'en obtiens rien d'utile, je ne l'utilise plus ou presque plus, et mes amis - ceux qui comptent et avec qui je souhaite rester en contact - sont déjà tous à porté de ma main grâce à l'email, IRC, le téléphone, et les rencontres physiques.

Je n'ai pas besoin de publier de photos de mes vacances sur Facebook, j'ai un service dédiée pour ça. Je n'ai pas besoin de lire l'actualité sur Facebook, j'ai une pléthore de services dédiés pour ça - sans parler même de la pertinence de l'actualité sur Facebook (vaste sujet, mais ce serait une dépense d'énergie bien vaine tellement la conclusion est évidente à mes yeux). Je n'ai pas non plus besoin d'occupation de mon temps libre, j'ai là encore une pléthore de services pour cela, ainsi que des activités tout à fait satisfaisantes par ailleurs. La géolocalisation, je la choisie lorsqu'elle m'arrange, et je la diffuse lorsque je le souhaite.

Non, aujourd'hui, si je quitte Facebook, c'est parce qu'il est inutile, et je n'ai donc plus aucune raison d'y rester. Si vous souhaitez connaître toutes les raisons possibles et imaginables pour ne pas y rester, je vous en prie : faites des recherches, croisez les informations, vérifiez les données et les sources. Et faites vous une idée par vous-même.

Je suis las - vraiment - d'expliquer aux gens les problèmes de la gestion des données personnelles, dès qu'il s'agit de parler de Facebook. Moi, j'ai fait un choix, je ne vous demande pas d'être d'accord. Quant à tous ceux avec qui je vais perdre le contact : tant pis, tant mieux.

J'ai prévu de fermer mon compte la semaine prochaine. Je laisse à mes amis qui auront pris soin de noter l'information de réagir en conséquence. J'ai toute confiance en eux.

Tu ne routeras point comme un cochon

Par Florian Strzelecki - 19:57 - 11.04.2012

Tags : Framework, Web, Documentation, Bonne pratique, PHP, loldev, Technique

Ces derniers jours, j'ai un problème avec les URLs. Plus spécifiquement, avec certaines URLs, qui sont gérées par certains mécanismes de "routage d'url" (et de réécriture d'url).

Il y a les bons routages et les mauvais routages.

Les bons routages d'URLs considèrent un format type (à base d'expressions régulières par exemple), et permettent d'associer une URL concrète à ce format, et d'en tirer une représentation à usage interne pour l'application. Les mauvais routages d'URLs considèrent un format type (à base d'expressions régulières par exemple), et permettent d'associer une URL concrète à ce format, et d'en tirer une représentation à usage interne pour l'application. Sauf que c'est un mauvais routages d'URL.

Trêve de blagues (et faisons plutôt la paix) (...) (ok j'arrête) voici le vrai problème que j'ai en ce moment : lorsque / et /home/default produisent exactement le même résultat, c'est à dire, pointent finalement sur la même "ressource". Autant c'est bien gentil de vouloir de jolies urls, et d'avoir des mécanismes simples pour gérer automatiquement un tas de cas, mais ce n'est quand même pas très RESTFull au final (je hais la duplication de contenu).

Car il s'agit bien d'un problème de "comment", et pas de "quoi" : réécrire des URLs à usage interne, et adapter le routage en conséquence, c'est tout à fait normal - ce n'est pas sale. Mais autant le faire bien, s'il vous plait. Ce problème n'est malheureusement que rarement traité, même si lors de mes recherches, j'ai été agréable surpris par les documentations de Symfony 2 et CakePHP.

Faisons un petit tour d'horizon de ce que nous proposent certains frameworks "à la mode" du monde PHP, puisque c'est majoritairement chez eux que j'ai rencontré ce problème, que chaque développeur devrait connaître et savoir gérer. Je veux dire, en commençant par reconnaître le problème quand ils l'ont devant leurs yeux.

Zend Framework

Allez, on commence avec du lourd, du sale qui tache : ce bon vieux Zend Framework. Après toutes ces années, je ne sais pas pourquoi je dis encore "ce bon", parce que je le trouve tout sauf bon, et même si ce n'est pas le sujet, encore une fois, ce framework montre des faiblesses de conception.

Dans sa documentation concernant le système de routage d'URL, vous pouvez tomber sur Zend Framework: Default Routes, section qui vous explique ceci :

Zend_Controller_Router_Rewrite comes preconfigured with a default route, which will match URIs in the shape of controller/action.

Ah, donc non seulement c'est le routeur par défaut, mais en plus il a pile le comportement qu'on ne veut pas avoir. Heureusement qu'à la fin de cette section il est ajouté qu'on peut supprimer cette route par défaut... bien que, par expérience, les résultats sont plutôt hasardeux (du genre vraiment, et pénible avec ça).

Cela dit, ce n'est pas encore terminé, sur la partie Dispatcher vous pouvez lire ceci :

If any of the module, controller, or action are not found, it will use default values for them.

Et pour revenir sur mes expériences : oui, ça peut devenir un problème, puisque le mécanisme qui utilise les routes d'URLs a déjà sa façon de voir les choses, et ce n'est pas toujours à votre avantage. Rien que d'y penser... non, je n'ai pas envie d'y penser.

CakePHP : presque !

Je ne connais pas bien CakePHP, et de ce que j'en ai lu, ce n'est pas trop mal - mais bon, mon avis ne vaut pas grand chose, testez plutôt vous-même. Que nous dit la documentation de CakePHP : Default Routing ?

You can access an action directly via the URL by putting its name in the request.

Brrr... ok, la même chose que pour Zend-Framework (mais avec une documentation plus sympa cela dit), ce qui n'est pas vraiment une bonne chose. D'autant que la suite n'est pas mieux, puisqu'on retrouve même des conseils sur comment faire de mauvaises choses automatiquement :

The keys of the array should be named after the route elements in the URL, or the default elements: :controller, :action, and :plugin. The values in the array are the default values for those keys.

Erm... je reviens, je vais boire une litre ou deux de ice-tea, pour me calmer. Ah moins que... CakePHP : Disabling the default routes : en voilà deux paragraphes intéressants !

Dommage qu'ils ne prennent pas beaucoup de place, mais ils ont le mérite d'être là. Je retiens plus particulièrement ceci, qu'il faudrait peut-être mettre en gras, en gros, avec des néons et des balises <blink></blink> tout autour (non, je déconne, les néons c'est en trop) :

If you have fully customized all your routes, and want to avoid any possible duplicate content penalties from search engines [...]

Bon, d'accord, la raison mise en avant, c'est pour faire plaisir aux moteurs de recherches : en attendant, c'est déjà une mise en garde sur les dangers d'un routage un peu trop permissif et automatique. Un bon point, au moins (et puis la doc a vraiment une jolie tête).

Symfony : le 1, et puis le 2 ensuite

J'ai connu une version de la branche 1.x de Symfony, et si le framework ne m'a pas marqué plus que ça, je me souviens très bien de son système de routes, qui est relativement facile à configurer (notez que je ne parle jamais de performance ici). Cette fois je peux nuancer plus facilement mon discours.

Tout d'abord, il est parfaitement possible de se passer d'une route par défaut avec Symfony 1.x, et je le conseille même vivement. Le soucis, c'est que la documentation section 9 ne précise pas forcément très bien cet aspect là. Je reprends cet exemple de code fourni :

# generic rules
# please, remove them by adding more specific rules
default_index:
  url:   /:module
  param: { action: index }
default:
   url:   /:module/:action/*

Alors, oui, il y a un commentaire, mais c'est à peu près la seule remarque sur le sujet, et j'ai vu bien des développeurs l'ignorer complètement, l'oubliant, et reléguant cette ligne au fin fond des poubelles de l'histoire de leur framework favori.

D'ailleurs, un exemple de code un peu plus loin ne reprend déjà plus le commentaire, c'est dire... bref, là encore, Symfony rejoint la liste des frameworks qui permettent des choses bien crades, et qui en plus ne documentent pas bien la chose. Pas cool.

Symfony 2.x : de bonnes inspirations ?

N'ayant pas travaillé avec Symfony 2, j'ai du faire un peu plus de recherches, et j'ai été agréablement surpris par une documentation bien plus claire, et plus encore, par le système de routage.

Ce derniers ne propose pas (de manière documentée explicitement en tout cas), un mécanisme "générique" pour des urls qui peuvent correspondre automatiquement à une représentation interne (du genre :controller/:action comme dans la version 1.x). En cherchant un peu, j'ai trouvé que c'était tout à fait possible de mal faire les choses quand même, mais cela me semble moins grave, du fait d'une information qui n'est pas mise en avant du tout (là encore, contrairement à la version précédente).

Bref, bon point pour Symfony 2.x, qui propose un mécanisme de routage d'URLs relativement intelligent. Le point bonus : il propose même un système d’annotations, comme les décorateurs en Python, pour gérer ses URLs... un peu à la manière de Pyramid (un framework web minimaliste en python).

TL;DR: Tu ne routeras point comme un cochon

Vous l'aurez compris aux travers de ces exemples, je ne critique pas le principe de routage d'URLs en lui-même, mais seulement son implémentation, sa documentation, et les conseils fournis aux développeurs. Il y a dans la conception de ces outils une mauvaise compréhension des contraintes posées par les URLs et les bonnes pratiques. Les solutions apportées, bien que facile d'utilisation (et encore...), ne me semblent pas bien répondre aux problématiques posées, ou alors, seulement en partie, alors que toutes les parties sont importantes.

Je compare ces problèmes de conceptions à d'autres implémentations : celles de Django et de Pyramid, deux frameworks web en python. Ni l'un, ni l'autre, ne permettent simplement d'instaurer un tel mécanisme, mais proposent à la place une grande souplesse et une grande réutilisabilité.

Comme quoi, c'est un problème de conception, pas de fonctionnalité.

Sinon, une dernière blague pour la route ? Essayons de ne pas nous fâcher en si bon chemin !

Faire des trucs

Par Florian Strzelecki - 20:27 - 10.04.2012

Tags : Web, Ma vie, Lecture, Citation, doing things

Aujourd'hui, j'ai envie de partager une certaine coïncidence entre mes réflexions personnelles, un lien ou deux, et quelques discussions avec des amis. Cette concomitance (au sens large de faits, incluant les idées, les réflexions, et les faits en eux-même) est tout à fait bienheureuse et positive, et je ne peux m'empêcher de la partager avec vous. Au passage, c'est un bout de réflexions et de "trucs", et je prétends n'avoir qu'un avis personnel, peut-être naïf, peut-être faux, incorrect, ou tout simplement ridicule. Non, je n'ai pas peur, j'ai seulement envie d'écrire un peu.

doing things

Cela commence - enfin non, je commence plutôt - par une affiche où se lisait ceci :

We have a 'strategic' plan. It's called doing things.

A quote from Herb Kelleher.

Je n'ai pas la moindre idée - dans mon ignorance - de la véracité de cette citation, ni de son exactitude, ni de son origine, n'ayant rien trouvé sur le sujet ou sur la personne de Herb Kelleher (mais je n'ai pas beaucoup cherché, je vous en laisse tout le soin).

Mais, il se trouve que cette phrase me plait, ce concept de simplement "faire des choses" et de se laisser guider par nos réalisations a quelque chose de particulièrement séduisant pour moi. Non, je ne sais pas bien dire pourquoi, là, comme ça.

getting things done

Et puis, il y a cette expression anglaise tout à fait charmante : "getting things done". Je dis "charmante", mais ce n'est pas toujours le cas : dans la bouche de certaines personnes avec qui je ne souhaite plus avoir à faire, c'est une façon stupide et écœurante d'instaurer une pression malhonnête sur une équipe de travail - j'ai d'ailleurs eu quelques soucis avec cette expression dans ce cadre là, ce qui m'amena souvent à la considérer avec circonspection.

Or donc aujourd'hui je la trouve "charmante", comme "il y a quelque chose à en retenir de bon". En quelque sorte, c'est un "rappel" constant des objectifs : il faut savoir "faire les choses". Non seulement les commencer, les continuer, mais aussi les finir : les "faire", dans leur ensemble, et pas seulement sur quelques points.

"prier pour une avancée"

Beaucoup plus récent, je lisais cet article par @LeReilly "1268 - Envy" qui faisait, d'une certaine façon, écho à mes réflexions personnelles du moment.

Il dit ceci :

Tu ne peux à la fois dépenser de l’énergie pour t'élever et en dépenser pour descendre les autres.

Et aussi ceci :

Parce que dans tous les domaines qui soient, je ne fais que prier pour une avancée. Tout autre schéma de pensée, de l’immobilisme jusqu’à la rétrogradation, me foutent la trouille.

Ce qu'il y a d'amusant, c'est qu'aujourd'hui même je discutais avec un ami et ancien collègue (comme quoi, je me fais des amis dans le monde du travail, pour de vrai) à propos de nos projets, des choses qui avancent, de ces choses dans le monde du travail qui nous dégoutent et nous déplaisent... et j'ai trouvé qu'il y avait un lien entre notre discussion et l'idée de cet article.

Je le livre donc à votre réflexion, puisqu'il alimente la mienne.

Et moi donc ?

Bref, j'en arrive à la fin de ce petit billet, de cette note entre l'humeur, la réflexion, et le partage. Je retire de toutes mes expériences, de mes rencontres, cette même impression : mon temps est précieux, mon énergie aussi, il faut que je les dépense bien ou correctement - même si j'ai du mal à définir ce qui est "bien" et/ou "correct" (ce qui donne lieux à de passionnante discussion entre moi-même, volant parfois mes heures de repos durement acquises la journée).

Je réfléchis sur le sujet, parfois digressant, parfois oubliant, parfois animé d'une passion dévorante que mes amis connaissent bien (mes amis venant souvent de mes passions, le contraire serait pour le moins surprenant).

Mais il me faut aussi agir quand je le peux, quand j'estime cela nécessaire, ou simplement, quand "je le dois". Dernier sujet en date : écrire des tutoriels autour de l'utilisation du framework python Django. C'est un sujet comme un autre dans la longue liste des choses à faire.

Ladite longue liste ayant, au passage, déjà maigrie plusieurs fois sous la coupe franche de mes conclusions : "aujourd'hui, je fais un truc, je le termine, et ce sera bien".

Sur ce, je vous laisse à vos propres réflexions et idées, et si vous avez quelque chose à partager sur le sujet, mon @ mail est toujours disponible. À vos idées.

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.

DjangoCong 2012 à Montpellier, en face de la mer !

Par Florian Strzelecki - 17:14 - 29.11.2011

Tags : Django, Python, Framework, Web, J'aime, Djangocong, Technique

J'étais à la DjangoCong 2011, c'était à Marseille, et c'était super. Et ça tombe bien, parce que pour l'édition 2012, j'assiste les organisateurs dans cet évènement, qui a été pris en main par une équipe locale... à Montpellier !

Plus exactement à Carnon-Montpellier, devant une immense étendue de sable chaud et la mer Méditerranée.

Quand ? Le 14 et 15 Avril 2012. Prévoyez vos billets de train !

Où ? À Carnon-Montpellier, dans le Sud de la France. Il y a une gare TGV et tout le confort sur place (la mer, et on l'espère tous du Soleil).

Le lieu ? Dans la journée, ce sera à la Maison Familiale EAGA, et le soir au Gédéon. Oui, ça vend du rêve en barre (j'ai hâte).

Les inscriptions ne sont pas encore ouvertes : elles le seront lorsque l'appel à conférences sera clôturé, c'est à dire aux environs du 13 - 15 Janvier 2012. Donc, si tu as quelque chose à proposer, il est temps de le faire !

La mer devant Carnon-Montpellier

Image : La mer devant Carnon-Montpellier - DjangoCong - DR

Multi-Db avec Zend

Par Florian Strzelecki - 20:20 - 07.10.2011

Tags : loldev, Framework, Web, Zend Framework, Technique, Documentation, Programmation, SQL, PHP

Depuis que je travaille avec le Zend Framework (et ce n'est définitivement pas par passion ni envie), je ne passe pas une semaine sans avoir besoin d'aller voir dans le code source du framework pour comprendre ce qu'il fait, pourquoi, comment, et en quel honneur.

Et généralement, je me marre - enfin pas vraiment, mais faites comme si.

Cette semaine pour le #loldev du vendredi, c'est la documentation qui m'a donné l'info qui me manquait pour résoudre un problème qui n'est pas trivial à l'origine, mais qui devrait l'être avec un framework web digne de ce nom : comment gérer une application qui doit se connecter à différentes bases de données ?

En voilà une question intéressante... voici ma réponse.

Pages and pages of source code.

Image : Pages and pages of source code. - Neil Crosby (http://www.flickr.com/photos/thevoicewithin/) - Creative-Common By-NC-SA