« Optimisé pour »

Il paraît qu’ya un truc qui fait se dresser les cheveux sur la tête de certaines personnes : la petite mention « optimisé pour » tel ou tel navigateur. Leur argument massue est « de toutes façons en respectant les standards du waibe vous n’avez pas à optimiser pour tel ou tel navigateur, ça passera partout ». Et là moi je dis : « pas d’accord » (ya beaucoup de guillemets dans ce billet).

Après m’être vilement fait chourer le domaine sur lequel j’hébergeais mon site perso, je me suis dit comme ça « plutôt que de remettre les trucs en ligne tels quels ailleurs, autant en profiter pour mettre à jour ». Aussitôt dit, aussitôt… commencé (c’est en cours là, ça avance doucement), j’en profite pour refaire une CSS (l’autre j’en avais marre), je bricole tout mon truc aux ptits oignons, je fais valider aux validateurs HTML & CSS, et là j’allume Internet Explorer. Boum. Bon, c’est pas catastrophique, mais quand même, c’est moche. 2 pixels par ici, 3% par là, ça flingue quand même la mise en page. Les problèmes sont connus hein, et je savais que je les aurai avant de commencer à développer. Des nuances dans la gestion du padding des div, dans la gestion des bordures, à l’intérieur à l’extérieur on sait pas trop.

Bon, et dans Safari la gestion est encore différente. *sigh*. Opera me fait la même chose qu’IE, Konqueror la même chose que Safari.

J’avoue, je ne sais même pas si la manière dont les padding sont gérés (intérieur ou extérieur) est normé ou pas. À vrai dire, je m’en fous. Si c’est normé, vu que le comportement est différent dans IE et dans Firefox, yen a un qui fait n’importe quoi. Si ça ne l’est pas, il aurait ptêt fallu s’aligner, au hasard sur celui qui a encore probablement plus de 80% du marché. Quant à la gestion de Safari, je ne la comprends juste pas. (Je passerai sur la gestion IE Mac, là c’est la catastrophe intégrale.)

Bon. Je connais le bug dans l’interprétation CSS d’IE qui permet de modifier la feuille de style afin que la feuille soit différente sous IE et sous Firefox. Safari, je sens que ça va rester comme ça. IE Mac, je laisse tomber. Navigateurs texte, je sais que ça passe 😉 C’est un site perso, à la limite je m’en contrefous, il faut quand même bien l’avouer, surtout que le contenu reste lisible (sauf sous IE Mac 😉 ).

N’empêche que mon site, bin il est « optimisé pour Firefox ». Et j’ai même pas honte.

Le pourquoi du comment du rhaaaaaa.

Christophe m’a demandé de préciser ce que j’avais contre le MVC & le n-tiers etc etc.

Alors, MVC, sur le principe, c’est très bien. J’en suis même, en théorie, un ardent défenseur. Le principe, c’est « pour une appli, on a des données (model), on veut les voir (view), et on veut y appliquer des traitements (controler). Et on découple tout ça de manière à ce que (par exemple) si on change l’algorithme de traitement, il y ait normalement pas besoin de changer ni la visualisation des données ni le modèle de données. Très bien.

Là où ça se gâte, c’est que le cloisonnement du modèle MVC, bien souvent, il est dur. Ça veut dire que pour appeler un truc du côté contrôleur quand on est côté vue, faut se manger des callbacks pas possibles et, bien souvent, c’est pénible ET long. Pour l’exemple, la dernière fois que j’ai dû aller rechercher une fonction à la noix de ce type là, ça m’a pris 4 ou 5 heures pour mettre en place ledit callback. On me rétorquera que 1/ c’est que je suis une buse 2/ c’est qu’y’a ptêt un problème avec le framework que j’utilise ; ça n’empêche que par rapport à appeler bêtement une fonction, c’est long.

En pratique, le problème, et tout particulièrement quand on travaille à plusieurs sur du code, c’est que les choses ne sont jamais aussi claires que ça. Déjà, il va en général y avoir du code qu’on aimerait bien avoir des deux côtés (côté contrôleur (on dit aussi métier) et côté vue (on dit aussi présentation)). Techniquement, on est bien d’accord, ça veut dire que quelque part, on sait pas trop où va le code, qu’il faudrait réfléchir, éventuellement le déplacer d’un côté à l’autre et/ou faire les choses plus proprement qu’elles ne sont faites.

Maintenant, considérons la situation suivante. On livre en intégration demain. Il est 16h. J’ai une fonction qui traîne, avec le code kivabien dedans, mais elle est pas du bon côté. J’ai pas de mapping pour faire mon callback. Faire le mapping, ça va relativement vite, sauf qu’il faut recompiler pour mettre le mapping au bon endroit (et ça, c’est long), et que pour mapper, il faut que les paramètres de la fonction soient sérialisables, sinon ça passe pas (et oui, un Boolean, c’est sérializable, un boolean, ça l’est pas. Astuce.) (oui, je fais du Java.) Et, comme dit plus haut, avec toutes ces emm… diverses, faire le mapping proprement, ça peut prendre 4h (avec les divers bugs et autres ennuis) (bon, ça peut aussi prendre un quart d’heure si on s’en tire bien, hein, soyons honnête !!), donc… bin on duplique le code. Moche.

On pourrait contourner ça en ayant une partie de code « commune » qui serait compilée à la fois avec la partie métier et avec la partie présentation. Il faudrait bien sûr faire super gaffe en y mettant quoi que ce soit (c’est un coup à exploser complètement le modèle, donc pas très beau), MAIS quelques fois ça serait intéressant. Je pense en particulier à tout un tas d’utilitaires à la noix qui peuvent très bien servir des deux côtés, traitement de chaînes, tris, etc. Sauf que, évidemment, simplicité et développement à l’arrache obligent, on finirait toujours par y trouver « la fonction qui récupère la liste des gens à qui envoyer un mail pour telle opération » (mbof) et/ou par ne pas y trouver « le petit utilitaire de trois lignes qui appelle le Tokenizer pour parser m chaîne, là ».

En-dehors du code potentiellement duplicable, ya aussi le problème du code qui est « juste pas au bon endroit, du moins il me semble ». Pour moi, une fonction qui envoie un mail à un utilisateur avec des informations sur une instance particulière du modèle, ça va côté présentation (parce que je crée mon mail et je le présente à l’utilisateur). Bon, pour la personne qui a fait la fonction, ça va côté métier. Et là, c’est la lutte. Je sais pas qui a raison (enfin, si, moi 😉 ) mais, techniquement, non, j’ai pas le temps d’en discuter et j’ai pas le temps de corriger quoi que ce soit (rappel : il est 18h et je livre demain en intégration). Donc, on lutte. Pis là on se rend compte qu’il y a deux fichiers de ressources pour les chaînes. Gargl, le fichier en question est côté présentation, il faut donc que je crée le mail côté présentation et que je l’envoie côté métier. Ouiménon, en fait, les chaînes elles étaient dans l’autre fichier. Damned, il est 22h.

Bref, voilà. Le modèle MVC, conceptuellement, c’est très joli. En pratique, entre le code qu’on sait pas où mettre, le code qu’est pas au bon endroit, le code qu’on voudrait bien des deux côtés, le tout dans un environnement d’équipe et à l’arrache, le modèle MVC, ça te pourrit la vie d’une manière monstrueuse.

Quant à l’archi n-tiers… bin mon code métier et mon code présentation, ils sont sur deux serveurs Websphere différents. Il faut lancer le serveur métier avant le serveur présentation, sinon ça plante. Relancer les deux serveurs, ça me prend au moins 10 minutes à chaque fois. La trace d’exécution, elle se fait sur deux serveurs et c’est donc le bordel (d’un côté, ta trace s’arrête sur l’appel au callback, de l’autre, faut déjà voir si elle commence (aka si t’as pas foiré ledit callback)). Debugger du n-tiers, c’est pas marrant.

Voilà. Ceci était mon billet argumenté sur le hurlement primaire de l’autre jour.

Je reprécise donc que dans un environnement parfait où tout le monde sait ce qu’il fait, où personne ne fait de bugs et où on n’a pas (trop) de contrainte de délais, le MVC et le n-tiers, c’est probablement fantastique.