Blog // Exirel.me

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

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.

La bootstrapite aiguë

Par Florian Strzelecki - 01:15 - 02.06.2012

Tags : Framework, Technique, #trolldredi, css, lesscss, twitter bootstrap

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

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 !

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

Ugly code

Par Florian Strzelecki - 01:56 - 28.09.2011

Tags : Framework, Programmation, Bonne pratique, Chaton, Optimisation, Problème, loldev, Technique

Il est parfois difficile de dire d'un code qu'il est bon ou mauvais, qu'il est moche ou élégant. Parfois, les deux se confondent dans un doute profond sur la nature d'une idée, et sur son implémentation.

Beautiful is better than ugly.

Heureusement, parfois, il y a du code php/java/python/javascript/ruby/perl/autre bien sale et c'est très facile à repérer.

Notez l'effort pour ne pas troller toujours sur le même langage.

(bool) $flag

Par Florian Strzelecki - 13:00 - 08.08.2011

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

Je suis toujours autant amusé par ce que je peux trouver dans le code-source du Zend Framework. Oh, rien de grave, cela fonctionne très bien de cette façon là :

public function setNoRender($flag = true)
{
    $this->_noRender = ($flag) ? true : false;
    return $this;
}

Il s'agit d'une méthode de la classe Zend_Controller_Action_Helper_ViewRenderer, qui effectue un traitement fort simple et basique, mais d'une façon que je trouve "inutile".

Je veux dire... si j'analyse ce bout de code d'un coup d'oeil, je peux voir qu'un cast implicite en booléen est effectué, pour ensuite... affecter cette même valeur (mais écrit "explicitement"). En gros, ce bout de code est strictement équivalent au suivant :

$this->_noRender = (bool) $flag;

Pourquoi faire plus compliqué ? Pourquoi s'embêter à écrire explicitement "true" et "false" ?

Oui, c'est du pinaillage. Mais j'aime bien pinailler sur ce genre de choses.

Moins de code, plus de fonctionnalité

Par Florian Strzelecki - 21:17 - 10.06.2011

Tags : Framework, Programmation, Bonne pratique, Optimisation, Technique

En ce moment, je répète souvent à mes collègues (et à d'autres personnes) la maxime suivante :

Moins de code, plus de fonctionnalité.

C'est devenu mon leitmotiv en ces jours sombres où je dois travailler avec des gens qui n'ont pas encore acquis toutes les compétences nécessaires sur le projet. Et vu mon niveau d'exigence, autant dire que c'est vaguement difficile à gérer pour moi (mais je me soigne).

Pour paraphraser cette pensée, je dirais qu'il ne sert à rien d'écrire beaucoup de lignes de code pour apporter de nombreuses fonctionnalités.

L'important, notamment et surtout dans le cas d'utilisation de framework, c'est de proposer un code simple, facile à étendre, et qui s'intègre bien à son environnement. C'est ma façon à moi de rappeler les principes KISS et DRY : Keep It Simple & Stupid, Don't Repeat Yourself.

Je parle du cas où l'utilisation d'un framework est obligatoire (parce qu'il s'impose de lui-même ou parce qu'il a été arbitrairement imposé), car c'est exactement dans ces moments là qu'il faut rester vigilant.

Dans le cas d'un framework, écrire "moins de code" ne veut pas dire littéralement écrire moins de code, mais plutôt "intégrer parfaitement le moindre code dans le contexte du framework".

Si le framework impose d'écrire une classe, ou plusieurs, pour écrire un "plugin", alors il vaut mieux le faire, plutôt que d'écrire quelque part codé en dur dans le code, la modification voulue.

C'est peut-être paradoxal, mais cela fonctionne mieux. C'est peut-être frustrant, mais cela évite bien d'autres frustrations.

Croyez-moi, il vaut mieux que tout fonctionne toujours parfaitement avec le framework, que tout fonctionne maintenant comme vous le voulez contre le framework.

Parce que le framework lui, il a déjà écrit beaucoup, beaucoup, beaucoup de lignes de code.