Lors de la Djangocong 2013 à Belfort, @Evlf a proposé un très bon sujet de réflexions avec sa conférence : Une logique métier bien placée. Son constat est simple : tout bon débutant qui se respecte va avoir tendance à utiliser les fonctions spécifiques de l'ORM dans ses vues Django.

Ce qui est plutôt normal pour un débutant devient problématique aux yeux de quelqu'un d'un peu plus expérimenté : quel est la part de "logique métier" qui se retrouve ainsi dans un espace dédié à la vue, la présentation.

Je rejoins @Evlf sur ses questions : comment bien placer la logique métier ? Pour ma part, je pense qu'il est possible d'éviter bien des ennuis en utilisant correctement les managers de Django, et ces derniers sont donc le sujet de cet article.

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.

Il n'y a pas très longtemps sur Twitter, un petit débat autour du livre numérique et le jeu de rôle s'est tenu entre @stephanegallay, d'autres twittos, et moi-même. Il en est ressorti ceci : et si j'écrivais un article de vulgarisation sur la fabrication d'epub ?

Bon, comme le sujet mérite bien plus qu'un seul article, je vais donc en faire plusieurs - dont voici le premier - pour parler de ce format, et sur comment fabriquer un fichier epub dans les grandes lignes. Je vais le faire en deux grandes parties, la première très technique, et la seconde sera orienté vers un public curieux mais sans avoir de solides compétences techniques.

Et vous verrez que le format epub n'est pas si compliqué que ça, et qu'on peut obtenir un résultat tout à fait potable avec quelques bons outils (libres et gratuits) et un brin de méthode. Le plus dur dans un livre numérique, ce n'est pas le format : c'est d'écrire un bon livre !

Je ne parlerai cependant pas des DRM et de toutes ces saloperies qui viennent bousiller tout espoir d'avoir un format ouvert et interopérable entre les mains des utilisateurs.

J'ai envie d'aborder un sujet difficile : le sexisme ; plus spécifiquement, le sexisme dans les communautés de développeurs (et autres informaticiens, ne nous battons pas sur les mots), et sans doute plus précisément encore dans le logiciel libre et l'open-source.

Sexisme ordinaire

C'est difficile pour moi d'en parler : je suis un homme, français, blanc, hétéro, avec une situation économique, familiale et sentimentale stable - et plutôt enviable je dirais. Si j'ai connu la discrimination et les brimades étant enfant (pour tout un tas de raisons), aujourd'hui je ne souffre pas de discrimination portant sur ma couleur de peau, mes origines, ou mon orientation sexuelle, et encore moins parce que je suis un homme. C'est plutôt facile comme vie, et je ne me rends compte que très difficilement du privilège que représente ma situation. D'ailleurs, la prise de conscience de cet état de fait a été une véritable révélation pour moi.

C'est un sujet d'autant plus difficile que je me pose beaucoup de questions, tant sur ma légitimité à aborder le sujet, que sur le sexisme ou non de mes propos ou de mes actes. Je ne peux oublier, à aucun moment, que la blague que je m'apprête à faire est peut-être sexiste (qu'elle le soit ou non). Je ne peux oublier que le trait d'esprit que je crois amusant est, finalement, peut-être sexiste (ou peut-être pas). C'est quelque chose d'assez pénible de devoir lutter sans cesse contre son éducation et ses habitudes prises en société. Et pourtant, je sais aussi que ce n'est rien face à ce que doivent ressentir toutes ces femmes qui subissent le sexisme, ordinaire ou non.

Entendons nous bien, je ne suis pas en train de me plaindre sur ma pauvre petite vie misérable (d'homme blanc, hétéro, etc.), parce qu'elle est loin d'être misérable (elle est même plutôt cool, alors bon). J'essaie seulement de partager le constat que je fais tous les jours : lutter contre le sexisme au quotidien est difficile parce que le sexisme ordinaire est si bien ancré dans la société, si bien attaché à nos habitudes, que ce n'est pas encore naturel de ne pas être sexiste ; alors que l'inverse l'est !

Et je veux que cela change. J'aimerais ne plus avoir à me poser de question lorsque je m’apprête à dire ou écrire quelque chose. J'aimerais ne plus avoir à me demander si je ne devrais pas balancer une répartie bien sentie à un collègue qui sort une blague sexiste en plein open-space devant une collègue. Pas seulement parce que je juge, moi, que c'est mal, mais parce qu'il devrait être communément admis que c'est effectivement mal - et je ne devrais pas être le seul à réagir !

Au quotidien

Toutes les semaines je tombe sur une histoire de sexisme, qu'il soit ordinaire ou non. Je ne cherche pas spécialement à me documenter sur le sujet, ni ne saute sur toutes les occasions de découvrir une nouvelle histoire d'horreurs et de sexismes ordinaires - et oui, je pense que ce sont des horreurs, et je ne vais pas sous-évaluer ce qui est sexiste. Que ce soit sur reddit, sur twitter, dans mes flux rss ou que sais-je encore, je tombe dessus par hasard absolument toutes les semaines.

Cette semaine, c'est l'histoire de Sarah Parmenter, dans son billet de blog "Speaking up" que je vous invite à lire. C'est suite à un tweet que j'ai découvert cet article, et je n'avais jamais lu ou entendu parlé de son auteur. Elle y raconte une histoire ignoble. Ma réaction en la lisant a été la gêne, voire la honte : la honte d'être dans une communauté où ces choses horribles arrivent à des femmes juste parce que ce sont des femmes.

C'est une bonne chose que des femmes arrivent à en parler. C'est aussi une bonne chose que des hommes s'en rendent compte, l'acceptent et essayent de changer les choses. Mais est-ce bien suffisant aujourd'hui ?

Si je n'ai pas d'avis particulier sur l'origine de l'absence des femmes dans les filières informatiques (je pense que le problème est beaucoup plus global à toutes les filières à tendance masculine que spécifique à mon métier), je pense, par contre, que nous avons tous la responsabilité de leurs présences aux conférences et événements dans notre domaine, que ce soit en tant que spectatrices ou en tant qu'oratrices.

Les femmes doivent se sentir autant les bienvenues que les hommes, et ne doivent pas avoir peur de venir ou de présenter quelque chose. La seule chose qui devrait compter, ce sont leurs compétences, leur curiosité, et comme tout orateur, leur timidité face à une salle remplie de leurs pairs.

Bon sang, est-ce si difficile d'être respectueux, ne serait-ce qu'en public, à une conférence où chacun vient avant tout pour partager son savoir ? J'ai envie de hurler quand j'y pense, tellement cela me paraît absurde, stupide, et tellement éloigné des valeurs que je cherche à trouver dans ces rencontres !

Initiative

Je n'ai pas envie de finir sur une note négative, parce qu'il faut dépasser ce constat, il faut dépasser la prise de conscience, et aller plus loin. Je lis de temps en temps le blog de Tarek Ziade, et je me faisais déjà quelques réflexions sur le sexisme, lorsqu'il a publié en Novembre dernier un article (en anglais) "Diversity in Open Source" puis en janvier de cette année "Fosdem & Python" que je vous invite à lire aussi. Dans ce dernier article il a d'ailleurs cette phrase assez terrible :

My only regret is that we don't have any women as speakers.

Et je partage un peu ce regret de ne pas voir d'oratrice. Actif dans la communauté Django, je regrette aussi de n'avoir encore jamais vu de femme prendre la parole pour 15min et faire une présentation. Pour avoir organisé Django Breizh en Novembre dernier, je peux vous dire que je n'ai malheureusement reçu aucune proposition de la part d'une femme - même si, à l'époque, je n'avais pas encore trop réfléchi à la question.

Try to do better - and find the right allies to push on diversity.

En relisant tout ça aujourd'hui, j'ai envie de répondre à Tarek lorsqu'il souhaite faire mieux et trouver les bons moyens / alliés pour promouvoir la diversité : moi aussi, j'ai envie de faire mieux cette année, et, pourquoi pas, tomber sur les bonnes personnes avec qui en parler/échanger/changer les choses.

Il faut que ça bouge, il faut que ça change. La situation actuelle ne me semble absolument pas acceptable, et il est clair que les femmes seules ne peuvent pas juste venir et se sentir bien. Nous, les hommes, en tant que majorité écrasante dans la communauté, nous devons faire comprendre à nos pairs que ce n'est pas acceptable.

J'ai envie que ça change.

Bonne question n'est-ce pas ?

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

• C'est un truc d'informaticien,
• C'est pour fournir des services à des utilisateurs (et vous vous dites ça parce que vous avez entendu votre petit cousin geek de 20ans en fac d'info parler de l'API twouitteur qu'elle est trop bien pour gérer ses faulover).

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.

Hier soir - jeudi 8 Novembre 2012 - j’ai eu l’occasion de participer à une réunion avec les responsables de la Mission Lescure (dont Pierre Lescure évidemment, et au moins trois autres personnes), à la Cantine Numérique Rennaise.

J’ai reçu l’invitation via ma participation au Collectif Open-Data Rennes, et, bien que membre du Parti Pirate par ailleurs, c’est donc en ma qualité d’acteur rennais sur l’Open-Data que je suis venu (et je m’y suis assez bien tenu je dois dire).

C’était intéressant, voire agréable, de pouvoir discuter sur les sujets qui nous préoccupent en tant que collectif, qui se trouve fréquemment confronté aux questions de droits d’auteurs, d’utilisations et de réutilisations des œuvres culturelles (de l’Etat, mais pas seulement).

Retour sur cette réunion qui dura bien trois gros quarts d’heure.

Image : Fronton de l'hôtel de Ville - Lego Créator - Florian Strzelecki - Creative Common By-SA

Hier soir, je suis allé prendre un menu long-bacon au Quick de Rennes, à République. Rien d'extraordinaire, pas plus que la longue file d'attente aux caisses qui me verra lui préférer la borne "Spot" (ou un nom dans le même genre, avec des S, des P et des O). Et là, c'est le drame.

Une bonne demi-douzaine de personnes sont déjà en train d'attendre leur commande au retrait, ce qui est plutôt inhabituel, vu que le système est quand même fait pour être plus rapide, n'ayant pas besoin d'un opérateur pour prendre les commandes (ce qui permet normalement de les paralléliser).

Mais là, le système était manifestement en rade : la serveuse (qui avait tout de l'accoutrement du "manager", c'est à dire la chemise plutôt que le t-shirt lambda des employés du Quick) n'arrivait pas à suivre, soit que cela vienne de la cuisine ou de son incapacité totale à gérer plus d'une commande en même temps. Il ne faut pourtant pas être un génie pour comprendre que faire autant d'aller-retour pour les frites qu'il y a de clients à servir, c'est contre-productif lorsqu'un seul aller-retour suffit en attendant que les burger arrivent.

Là dessus, un nouvel employé arrive, manifestement en retard, il file dans les vestiaires et revient deux minutes plus tard. Il reprend en main la caisse Spot, laissant sa manager se retirer, et se met à gérer les commandes. Pas une par une, mais plutôt deux par deux, voire à un moment trois par trois.

Il regarde son écran, fait la commande en cuisine de tous ses burgers, va s'occuper des frites, et lorsqu'il revient les déposer dans les sacs, il peut récupérer les burgers pour trois commandes à la fois. En moins de 5min tous les clients devant moi était servi, et ceux qui sont arrivés après moi avec une commande simple ont été servis aussi. Le petit bonus, c'est le classic-pepper offert pour le temps d'attente - et avec des excuses du serveur. J'étais admiratif devant ses méthodes, devant son soucis de l'optimisation, devant sa capacité à faire fonctionner le système comme des engrenages bien huilés.

Il a été mon héros du soir, un super-héros ordinaire qui a bien fait son travail : servir le client.

Je veux plus de super-héros ordinaire, j'aime pas attendre au Quick.

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.

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.

So, it has come to this: MrJMad trollant comme un lycéen découvrant un avis un peu différent du politiquement correct.

Note de service : MrJMad est un ami, un mec bien, que j'apprécie énormément. Mais je ne pourrais pas l'apprécier autant si je n'avais pas l'occasion de me chamailler avec lui de temps en temps. Comme là, donc. Prenez tout ça avec humour.

L'affaire et son origine.

Bon, pour commencer, je vais expliquer un peu mieux la situation de base, par une reproduction de la discussion qui m'amena à cette réflexion "y a des gens... et bah ce sont des gens" :

Exirel : Windows pour jouer, Ubuntu pour bosser, et une autre distrib stable pour du serveur

Libriste7814 : Windows c'est le mal ! Et puis y a des jeux sous Linux !

Exirel : Oui, mais pas tous les jeux, et j'aime bien jouer. Et je fais un peu de game-design, alors je ne vais pas me priver.

Libriste7814 : Non tu as tort, il faut faire des choix. Tu peux installer [insérer ici une explication complexe et technique sur comment faire rentrer des octaèdres dans des losages] et ça marche !

FreeBoy3907 : Non mais c'est facile j'ai une technique qui marche super bien pour pas s'embêter : je n'ai pas besoin de jouer. Alors je ne joue pas, et c'est régler !

Libriste7814 : +1, tu devrais faire pareil, pas besoin de jouer == pas de soucis !

Et donc, moi, un peu agacé par ces deux idiots intolérants et suffisants, qui tentèrent de m'expliquer pourquoi j'avais tort et que "de toute façon jouer ça sert à rien LOL", j'ai tweeté ceci :

LesGens‬ qui me disent qu'ils utilisent que du logiciel libre parce que c'est mieux... et qui me disent aussi qu'ils ne veulent pas jouer.

Et puis :

C'est sûr que c'est facile d'être 100% Logiciel Libre quand on a que des besoins limités.

Ce qui était un peu (beaucoup) trollesque. Mais j'assume complètement, parce que j'aimerais bien que les libristes réalisent que les convictions, c'est super, mais que la réalité est bien différente lorsque vous avez des besoins réels qui ne sont pas satisfaits.

Pour le cas des jeux vidéos, vous avez le droit de me dire que ce n'est pas un besoin "vital". Je répondrai presque en disant que la guerre est le jeu dont les règles sont les plus simples, et que le jeu est vital pour l'humanité, mais ce serait du troll. Et je ne trolle jamais, moi, n'est-ce pas ?

Le logiciel libre, les autres OS, et les jeux vidéos

Comme l'a fait remarqué MrJMad, et comme d'autres peuvent le faire remarquer (et à raison) : il existe des jeux libres, et des jeux qui tournent sur des distribs linux, d'autres sous Mac. Et c'est super, vraiment, je trouve ça génial, et merveilleux.

Mais revenons à la réalité un instant : quel est le ratio de jeux fonctionnant sous Windows vs de jeux multi-OS ? 10 pour 1 ? 100 pour 1 ? 1000 pour 1 ? Je n'ai pas la moindre idée du ratio exact, mais mon expérience de joueurs (ce qui sert à mesurer ma satisfaction, donc), exprime ceci : trop.

Il y a beaucoup trop de jeux que j'aime disponible uniquement sous Windows, et parfois sous Mac (mais je n'ai pas de Mac, et j'évite les produits Apple). Pire encore : certains jeux, disponibles sous Linux, requièrent des études poussées pour les faire fonctionner correctement, ainsi qu'un matériel tombant précisément dans le cadre d'utilisation "normal" (Quelqu'un a testé ATI avec Linux ? Quelqu'un a testé certaines puces NViDia sous Linux ?). Et je ne parle même pas d'utiliser un autre clavier que le qwerty/azerty classique (des utilisateurs de Bepo dans la salle ?). Oh, et je ne parle pas non plus de la compatibilité avec les manettes... et tout le reste.

Donc, la situation actuelle, bien qu'encourageante, n'est tout bonnement pas satisfaisante pour un joueur comme moi. Je me retrouve dans la situation d'avoir un besoin qui n'est pas comblé par le libre, par le monde du libre et de l'open-source.

Alors je vais voir ailleurs, notamment parce que je n'ai pas les compétences pour changer ces choses là (je fais du web, et sur ce support là au moins, c'est multi-plateforme). Si je veux améliorer les choses, je peux :

• Monter une entreprise qui fasse du jeu libre (hardcore mode),
• Travailler sur des game-design pour du jeu libre (chronophage),
• Faire des applications webs pour des jeux libres (mais c'est indépendant de l'OS),
• Exprimer mes besoins et mes envies

Par contre, coder un moteur de jeu (en dehors de jeu web j'entends), ce n'est pas à ma portée. Et je ne parle même pas d'utiliser des technos 100% libres : même avec du Flash ou C#/XNA, je n'ai pas les compétences pour ça. Je suis donc dans le cas d'un utilisateur sans aucun moyen d'action concret. Bref, j'en suis réduit à être un consommateur par l'industrie du jeu vidéo (ce qui ne me fait pas vraiment plaisir).

Les donneurs de leçons

C'est à ce moment que nous arrivons dans le coeur du troll de MrJMad : faut-il écouter les non-joueurs ?

La réponse est : oui.

Faut-il écouter les libristes convaincus et les puristes ?

La réponse est : oui.

Faut-il accepter qu'un non-joueur vienne vous dire que vous êtes un con et qu'il est meilleurs que vous parce qu'il a des convictions de libristes et qu'il est pur ?

La réponse est : non, [insérer ici une flopée d'insultes dégradantes pour lui et toute sa famille, sur 5 ou 20 générations, au choix, tant que c'est insultant].

Je comprends très bien que quelqu'un se limite à certaines fonctionnalités, pour certains types de logiciels. Par exemple, quelqu'un qui souhaite faire du mind-map pourra trouver des logiciels tout à fait utilisable pour ça. Ce ne sera pas toujours du même niveau qu'un autre logiciel, ce sera parfois mieux (si si, pour de vrai), et il y aura des contraintes à gérer (comme partout ailleurs).

Mais pour le jeu vidéo, ce n'est pas qu'une question de contrainte : il n'y a pas "un" jeu vidéo, il y en a des centaines de milliers. Certains ne sont que des copies, d'autres peuvent être rangés dans un même style, mais les jeux vidéos ne peuvent pas être réduit à une bête question de "fonctionnalités". Ce sont comme des livres : chacun est unique, chacun est un objet à lui seul, aucun ne se résume à une liste de fonctionnalités répondant à une liste de besoins.

Les jeux vidéos sont des histoires, ce sont des expériences, ce sont des mécanismes et des détails. Ce sont comme des livres, qui requièrent des supports très spécifiques. Ce serait comme me dire "passe toi de livres, ils ne sont pas libres, et puis il en existe des libres". Ce serait comme me dire de ne pas écouter de musique, ou d'aller voir des films, parce qu'ils ne sont pas libres.

Par contre, si je peux avoir le choix, je préfère payer pour du libre, je préfère payer pour du jeu indépendant, je préfère donner mon argent et mon soutien à des initiatives qui respectent mieux mes convictions. Mais pour ça, il faut avoir un vrai choix. Au passage : merci les Humble Indie Bundle ! C'est une initiative remarquable, et je souhaite que ces pratiques deviennent la norme, et non plus l'exception.

Comment ça "mauvaise foi" ?

MrJMad, avec tout le respect que j'ai pour toi : non, les jeux auxquels je veux jouer ne sont pas tous disponibles sous Linux, et je ne joue à aucun jeu libre (aucun jusqu'à présent, question de goût). Et non, certains clones ne me suffisent pas. Et non pas la peine de me ressortir The Battle for Wesnoth c'est pas mon style de jeu non plus.

La mauvaise foi, c'est celle qui consiste à fermer les yeux sur l’état actuel du jeu vidéo : les premiers promoteurs de jeux indés, et des petits développeurs, ce n'est pas le Libre. Ce n'est pas la communauté du Libre qui porte Steam, ou le XBox Live, qui ont permis de me faire découvrir ces excellents jeux : From Dust, Super Meat Boy, Bastion, Limbo, etc. ces jeux là sont développés par des indépendants, et produits par de grosses boîtes qui apportent des financements (Ubisoft, Warner, etc.).

Me ressortir le coup de la poutre, de l'oeil, et de la brindille, ça, c'est de la pure mauvaise foi. Notamment parce que je suis le premier à regretter l'état du libre dans le Jeu Vidéo, le premier à regretter de ne pas avoir le choix.

Qu'on vienne me libérer ! Qu'on me donne le choix ! Mes achats sont déjà orientés vers les petits jeux plutôt que les gros jeux, sauf exception (il y a Rift et Portal 2). Je milite pour des jeux moins chers, pour une reconnaissance et un essor de la culture du jeu-vidéo, pour tout un tas de bonnes choses...

... alors si le Libre a une réponse à apporter au monde du jeu vidéo, s'il a des réponses à apporter à cet état déplorable (DRM, location déguisée, etc.), alors je l'en prie à genoux : que le Libre nous libère, et répondent à nos besoins. À tous nos besoins.

Dernières remarques : je n'en veux pas au monde du Libre. J'en veux beaucoup aux constructeurs, au fabriquant de matériels, et aux fournisseurs de drivers propriétaires. Ces gens là menacent l'innovation, ces gens là menacent notre liberté à disposer comme nous l'entendons de notre matériel. Je ne jette la pierre à personne dans le monde du Libre... sauf à ceux qui viennent me faire la morale sans avoir seulement réalisé les questions à se poser.

Image : Les joueurs de carte - Paul Cézanne - Domaine public

Bon, j'ai bien ri, peut-être que vous aussi, mais je ne pouvais pas laisser cet article sur la bootstrapite aiguë sans quelques explications supplémentaires.

Dérives

Bootstrap en lui-même n'est pas vraiment un problème. Il y a certaines choses que je n'aime pas du tout (notamment une "légère" perte de contrôle sur l'agencement des classes), mais avec lesquelles je peux vivre. Ou le fait qu'il faille modifier certains fichiers de bootstrap pour modifier des variables d'ajustement (comme le souligne @nautilebleu).

Les dérives peuvent vite venir. J'en parlais un peu en dénonçant ce système de grille, avec ses multiples classes .span* et .row. Pour reprendre la phrase d'un grand philosophe de ces 5 dernières années :

Des .span* et des .row c'est pas grave quand il y en a un ou deux, mais quand il y en a 50 bonjour les problèmes !

Le soucis, c'est qu'il faut passer par l'attribut "class" de vos éléments HTML. Ce qui veut dire que, pour chaque élément HTML que vous avez, vous devez considérer les classes, ce qu'elles font, et en ajouter/retirer au besoin. Donc modifier le code HTML uniquement pour des questions de style.

Ok, là vous pourriez me dire que c'est normal, que, quoi qu'il arrive, soit je modifie le CSS, soit je modifie le HTML, soit les deux, mais que je ne peux pas y couper. Mais je ne suis pas d'accord : vous ne devriez pas avoir à toucher au HTML pour modifier la tête de la bordure de vos éléments, mais seulement à une classe css.

L'intérêt de CSS, c'est de séparer le style de la structure. L'attribut class de mes balises HTML appartiennent à la structure de ma page, et pas au style. Par exemple si un tableau ou un bloc est lié à des données de clients, les classes CSS utilisées devraient avoir un rapport avec ça : "client_facture", "client_achat", ou encore "client_profil". Si j'affiche plusieurs fois ces éléments, je n'ai pas à m'inquiéter d'une longue liste de classes CSS à ajouter à tel ou tel endroit.

Mais si vous utilisez les classes de bootstrap, vous devrez alors ajouter partout où vous en avez besoin une montagne de classes : positionnement, typo, bordure, etc. Ce qui est trop, surtout que vous avez lesscss à côté pour faire des mixins à la place (mais il faut que ce soit compatible avec le fonctionnement de bootstrap, ce qui n'est pas assuré, surtout avec le jeu des imbrications).

Quelques pistes de solutions

Tout n'est pas si sombre. En tout cas, certainement pas aussi sombre que ce que je m'amusais à le décrire dans mon précédent billet (mais nautilebleu l'a fait remarqué, c'était un #trolldredi assumé).

Je pense que le concept de lesscss est une bonne façon de résoudre certains problèmes. Principalement grâce aux mixins. Au lieu de réutiliser les classes de bootstrap pour les assigner à votre code HTML, il serait préférable de les utiliser pour créer vos propres classes css.

Cela demande un travail différent, mais cela permet de conserver la partie style dans la feuille de style, et pas ailleurs. Retour à plus de sémantique, et moins de pollution dans le HTML (et moins de travail si vous avez beaucoup de pages et de vue dans votre application).

Bon, après, reste à tester tout ça, pour voir si ça fonctionne quand même (et cela demande de fouiller dans le coeur de bootstrap, et là, tout de suite, j'ai la flemme).

À noter aussi une idée de @nautilebleu : créer un preprocesseur de css (qui lit le langage less, ou sass ?), en python. Cela nous permettrait, à nous développeur python, de créer ensuite des ponts vers django-compressor et autres techniques. L'idée étant de créer d'autres preprocesseurs avec la même syntaxe, dans différents langages (et assurer une portabilité).

Bref. Il y a du boulot, mais l'idée de structurer le développement des CSS, ce n'est pas une mauvaise idée.

Aujourd'hui, plutôt qu'un #loldev du jour, je préfère poster dans le #trolldredi. Et aujourd'hui, je vais troller sur Bootstrap by Twitter.

Préambule : ceci est un troll, vous avez le droit de répondre, mais n'oubliez pas que je ne me prends pas vraiment au sérieux (sauf sur certains trucs), et que, globalement, j'en ai pas grand chose à faire de bootstrap. Utilisez le si ça vous chante, ce n'est pas non plus le mal absolu.

Enfin, quoi que...

Je pense - notez l'usage du "je" d'une part, et du "pense" d'autre part - qu'il s'agit d'un fléau terrible, d'une maladie cataclysmique, d'une épidémie apocalyptique - je dis cela en toute modestie, bien évidement. De là à dire qu'il y a un lien entre #ZombieBukkake et Bootstrap il n'y a qu'un pas, mais je vous laisse le faire. Le pas, pas ZombieBukkake. Enfin, ça, ça ne me regarde pas.

D'ailleurs, si vous croisez quelqu'un dans la rue qui gémit un "boooostrappp" c'est peut-être qu'il faut l'achever à coups de pelle. Et vite, de préférence.

Bootstrap et Less

La documentation n'est pas spécialement claire sur le fonctionnement de bootstrap, mais vous risquez très vite de vous retrouver avec ceci directement en prod :

<link rel="stylesheet/less" href="/path/to/bootstrap.less">
<script src="/path/to/less.js"></script>

Enfin, ça, c'est si vous arrivez à trouver la bonne partie de la documentation (cela dit, c'est un peu plus simple en passant par le site de {less}).

Et là, j'entends déjà les prophètes noirs de ce "framework css" :

Hérétique ! C'est uniquement pour le dev, il faut compiler les fichiers .less avec lessc !

Je sais. J'ai fini par trouver les informations dont j'avais besoin pour :

1. Comprendre de quoi il s'agit (rien que ça),
2. installer tous les paquets, logiciels, bibliothèques, etc. requis, (j'en ai encore des cauchemars)
3. prier 50 fois les dieux de mon choix, en sacrifiant un hamster avec des clés usb et en rebootant 3 fois mon ordinateur,
4. obtenir les fichiers bootstrap.css et site.css dont j'avais besoin.

Si, comme moi, vous avez eu la mauvaise idée de ne pas utiliser une version minimisée des fichiers css, vous aurez droit à un fichier de 5000 lignes (mais sinon c'est super pour les mobiles).

Hérétique ! Il faut choisir uniquement les modules de bootstrap dont tu as besoins !

Oui, alors, là, je veux bien hein, mais c'est pas exactement ce que j'appelle "une documentation claire sur le sujet" que j'ai sous la main. C'est la documentation officielle (déjà, il faut comprendre où aller pour trouver toutes ces infos), et elle n'est pas claire pour deux sous.

Pour vous abreuver de variables à utiliser avec lesscss, ça, y a de quoi faire. Tout comme il y a largement de quoi faire des tableaux avec des divs et des classes aux noms génériques. Mais une putain d'explication simple, claire, et concise de comment faire son propre bootstrap propre et minimaliste, c'est la croix et la bannière !

Pourtant, sachez-le, je pense qu'il y a moyen de faire un truc "pas trop crade".

Bref, je n'ai rien contre less (enfin, si, j'ai un tas de trucs contre, mais je comprends l'intérêt de la chose, et je pense même l'utiliser), mais je résume par l'équation suivante :

bootstrap + less == grosse prise de tête.

Divite aiguë

Je pensais cette maladie oubliée, perdue, et disparue dans les tréfonds du web des années 2004-2006, lorsque CSS est devenu vraiment populaire, que Firefox sortait en version 1.0 puis 1.5 (j'ai une anecdote croustillante à vous raconter à ce sujet d'ailleurs, mais ce sera pour une autre fois), et que tout le monde s'accordait à dire "non mais, remplacer les <table> par des <div> partout en cascade, ça va pas être possible".

FAUX

Bootstrap permet aux plus neuneux d'entre nous de faire les plus ahurissantes combinaisons de cellules façon tableau 1998 à base de div. Et ouais, ces bonnes vieilles div.

Il y a même un nom pour ça : grid system et fluid grid system.

Comment dire. Je comprends parfaitement l'intérêt d'un design qui s'aligne sur une grille. Mais vous ne croyez pas qu'il y a un problème avec ce genre de code html :

<div class="row show-grid">
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
</div>
<div class="row show-grid">
    <div class="span4">4</div>
    <div class="span4">4</div>
    <div class="span4">4</div>
</div>
<div class="row show-grid">
    <div class="span4">4</div>
    <div class="span8">8</div>
</div>
<div class="row show-grid">
    <div class="span6">6</div>
    <div class="span6">6</div>
</div>
<div class="row show-grid">
    <div class="span12">12</div>
</div>

Avec ce genre de documentation :

With the static (non-fluid) grid system in Bootstrap, nesting is easy. To nest your content, just add a new .row and set of .span* columns within an existing .span* column.

Ce qui donne ce genre de règles pour css :

.row .span6 .row .span6 { /* ... */ }

Quoi ? La lisibilité ? Pour quoi faire ? On a un putain de grid-system-de-la-mort pourquoi on se ferait chier avec de la sémantique ou bien de la lisiblité.

lol noob.

Vous en pensez ce que vous voulez : moi, je n'en pense que du mal. Je comprends l'utilisation de technologie comme less pour factoriser le calcul des tailles des blocs pour chaque élément. Mais là, c'est exactement ce qui était reproché à la divite aiguë en 2007, et qui est toujours aussi désagréable.

Surtout que - excusez du peu - mais tant qu'à mettre un framework de css aussi lourd que bootstrap, autant utiliser des balises HTML5 (genre <aside>, <footer>, et autre <article>) avec un peu de JS pour supporter les anciens navigateurs. Après tout, ce ne seront que quelques ko en plus à télécharger.

Digression sur la notion de "standard"

Deux remarques de @revolunet :

C'est surtout l'aspect standardisation du markup qui est utile. Une bonne base pour themer, partager et faire evoluer des pages web

Deux remarques en un seul tweet. Je ne vais m'intéresser qu'à la première, puisqu'elle me révulse profondément. La seconde, j'en parle dans la suite, dans la partie des trucs biens.

La standardisation, justement, à quoi sert-elle ? Dans un cas comme bootstrap, à ce que tout le monde puisse parler de la même chose en même temps. C'est bien, c'est louable, mais il y a une chose qui manque : un sens à tout ça.

Ici, la standardisation ne sert qu'elle-même, et pas à donner du sens à ce que vous écrivez. Cette "standardisation" est l'exact contraire du travail de standardisation sur HTML5 & CSS3.

J'ai hâte que nous ayons un grid-layout en CSS3 implémenté partout et utilisable, mais je ne suis pas prêt à farcir mon code html d'une multitude de classes sans aucune sémantique.

Imaginez le bordel que ça doit être quand il faudra savoir si dans ce .row là il faut mettre un .span4 + .span2 ou deux .span4. Imaginez que cette question se pose dans un flot de .row .span4 les uns à côté des autres. Avec des .container dans les coins, histoire de vous faire un croche-pied.

Bon courage, mais je ne veux pas de cette standardisation là.

Ton .css tu ne comprendras plus.

Autre point qui me frustre particulièrement avec bootstrap. Que vous ayez un .less (et ses multiples import), ou un immense .css, comment comptez-vous vous y retrouver là dedans ? Comment allez-vous vous assurer, à chaque instant, de comment ça marche tout ce bordel ?

Et si, par malheur (et ça arrive tout le temps en réalité), quelqu'un se met à modifier certains fichiers .less de bootstrap, et pas seulement le local.less... bon courage !

lol noob c'est que du css on s'en fout !

Un intégrateur débutant qui mettait des #id partout pour tout. Il est mort dans d'atroce souffrance. IE6 overdose.

Je me suis retrouvé devant ce cas concret : on me file des .less, et à moi de me débrouiller avec. Problème de compilation parce qu'il manque un truc ? Débrouille toi ! Problème parce qu'un style ne fonctionne pas / ne fait pas ce qu'il devrait ? Débrouille toi ! Et surtout, paye toi tous ces fichiers dans tous les sens.

La doc n'est d'aucun secours, puisqu'il s'agit d'un problème que vous aurez entre votre html, vos css perso, et les règles de bootstrap. Ce ne serait pas un problème si c'était juste un reset de style, ou des classes ayant un sens sémantique...

... mais là, vous avez bootstrap, et son paquet d'éléments tous plus génériques les uns que les autres.

Et en prime, dès que vous voudrez changer le style de quelque chose, vous devrez modifier les classes css que vous utilisez pour cet élément (et donc le html)... #fear.

Là où c'est utile...

Bon, je vais cesser de troller pour aujourd'hui. Il y a un tas de trucs qui me dérangent avec bootstrap de twitter, mais il y a aussi des points positifs.

Comme le disait @revolunet c'est une façon de partager un point commun dans une équipe pour partager un style. Cela permet d'avoir un rendu "basique et standardisé" rapidement. Enfin, rapidement... je me comprends.

Standardiser des techniques d'utilisation de CSS

Je sais, mon précédent point était de dire que la standardisation de bootstrap c'était le mal. Et je n'en démords pas.

Par contre, l'effort de proposer une approche de "standard" est très intéressante - principalement pour le grid-system justement. Mais il aurait été beaucoup plus intéressant d'exposer des structures à réutiliser avec less, plutôt que des classes génériques à tout faire.

Après tout, une grille n'obéit qu'à quelques règles relativement simples, principalement, des règles mathématiques (je ne vais pas détailler, c'est un peu long et technique, mais ce n'est pas aussi compliqué que ça en a l'air).

Bref : bootstrap propose un concept intéressant, en cela qu'il démontre la logique mathématique derrière un tel système.

Un exemple pour la route :

Avec bootstrap, si vous voulez mettre un style à vos tables html :

<table class="table table-striped table-bordered table-condensed">
...
</table>

Ok... mais pourquoi ne pas simplement avoir des mixin less de ce style là :

# in table.less
.table-striped {
    /* style for striped table */
}
.table-bordered(@border: 1px) {
}

# in local.less
.customer_table {
    .table-striped;
    .table-bordered;
}
.product_table {
    .table-bordered;
}

Et voilà : vous obtenez le même résultat final, mais au lieu de rajouter plusieurs classes à votre élément <table>, vous ne lui ajoutez qu'une seule classe : la votre, celle qui a du sens customer_table pour vos clients, product_table pour vos produits. Si vous devez changer le style de ces deux tables, vous n'avez pas à changer le code html.

Et puis surtout si vous changez l'un vous ne changez pas l'autre par erreur...

Prototypage et application

Pour un prototype, bootstrap est peut-être une bonne idée. Je dis bien : peut-être. Je suis convaincu que, pour un petit site, il est une usine à gaz. Mais pour un prototype, il pourrait permettre de présenter quelque chose rapidement.

De même, pour une application web de type "intranet" ou "panneau de commande" réservée à un petit groupe qui utilise un système d'administration (de contenus par exemple, ou de gestion comptable, ou de ressources quelconques), il permet de standardiser rapidement le style de l'application. Mais cela reste un cas particulier - certes très utile (ce ne serait pas un mal à mon boulot par exemple), mais pas n'importe où n'importe quand.

Trolldredi, c'est fini pour aujourd'hui.

Allez, je m'arrête là, c'est déjà beaucoup de temps passé pour comprendre, analyser, et découvrir bootstrap. C'est un outil dont je n'ai pas besoin, mais il m'aurait fait mettre un doigt dans less. Ce qui n'est pas un mal en soi.

Il y a des bonnes idées à reprendre, mais en l'état : je dis non. Filez moi la même chose avec des mixin lesscss, et peut-être que j'y prendrai goût (mais c'est pas sûr).

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.

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 !

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.