Idéalement en France ou avec un télétravailleur en France, mais n’hésitez pas à en proposer des étrangères qui font des choses bien
Idéalement une équipe chez un éditeur produit et pas des prestataires de service, mais ça peut aussi être une équipe de presta dédiée et constituée qui en fait sa spécialité (donc pas juste une SSII qui a travaillé sur un projet)
Idéalement une équipe, mais si vous n’avez que de très bon exemples de sites, je suis preneur aussi
Vous avez des noms ?
De temps en temps j’aime bien explorer quelque chose de nouveau côté programmation.
J’ai tenté de faire une petite remise à zéro en Javascript il y a peu. J’y trouve plein de points positifs objectifs mais je ne vois pas la motivation pour mes projets perso. Je n’ai pas d’atomes crochus avec la syntaxe, le langage lui-même ne m’apporte pas suffisamment de nouveau pour que la découverte me motive, et il y a plein de trucs qui me fatiguent dans l’environnement.
J’ai vu Elm et j’aime bien plusieurs idées mais je cherche quelque chose qui tourne aussi en ligne de commande.
J’ai tenté Crystal. Le langage est sympa : inspiré de ruby, inférence de types, compilé et performant, liaisons simples avec toutes les libs en C. J’ai quelques reproches (genre l’absence d’un type « Numeric » qui m’abstrait des types bas niveau) mais je me suis surtout dit « à quoi bon » quand j’ai eu une exception à l’exécution lors de ma première journée. À quoi bon s’imposer un typage statique si c’est pour que les problèmes les plus courants soient encore gérés à l’exécution sans même un avertissement à la compilation ?
Dans l’idéal j’aimerais tester un environnement où quasiment tout est détecté en statique et qui ne soit pas aussi verbeux qu’un Java ou aussi bas niveau qu’un C. Vous avez quelque chose à me conseiller ?
C’est quelqu’un qui rédige les spécifications détaillées en langage machine d’une solution à un problème. (*)
* * *
Corolaires :
(*) Merci à celui qui m’a distillé cette définition, je ne sais plus d’où elle vient mais elle remplacera agréablement ma précédente.
Oui, comme si je n’en avais pas assez…
Il reste que j’ai envie de présenter ce que je fais en photo autrement que par Flickr. La cible n’est pas précise. Comme les photos elles-mêmes, je le fais d’abord pour moi. Peut-être est-ce simplement donner corps à quelque chose qui commence à prendre de l’importance.
Bref, je pose là pour moi-même – et un peu pour les curieux – ce que j’ai en tête.
Un menu principal à trois entrées : des textes, des photos et des albums. J’ai commencé à écrire un peu autour des photos quand je les publie ici, et c’est finalement intéressant de m’obliger à cette introspection. Les deux autres permettent de séparer le flux de photo chronologique en vrac de la séparation par albums bien pensée.
J’ai tenté un premier jet de la page d’accueil. On y met deux textes et deux albums en avant, à chaque fois un récent et un plus coup de cœur. Plus bas vient un mur d’images, avec les plus récentes et celles que j’aime le mieux (comme je suis un geek fini, j’ai déjà en tête une simili formule pour savoir ce que j’affiche en fonction de la date de publication et de mes favoris).
Travail en cours, le code CSS est certainement bien moche.
Dans les années 2007 à 2009 on avait une collection d’horribles bidouilles CSS pour insérer des images à la place de certains textes via CSS. L’idée c’est que certaines images ne sont pas du contenu mais bien de la présentation, potentiellement dépendantes du contexte.
Le besoin était tel que c’était un des sujets les plus en vue en CSS pendant des années avec « comment centrer un contenu verticalement ».
h3.nir {
height: 75px;
width: 300px;
overflow: hidden;
margin: 0;
padding: 0;
}
h3.nir:before {
content: url(http://…/test.png);
display: inline-block;
font-size: 0;
line-height: 0;
}
Franchement c’était de la bidouille de haut vol, avec plein de défauts. On rêvait d’un truc plus simple, qui fonctionne correctement quand l’image ne se charge pas et sur les lecteurs d’écran, sans flash de contenu non stylé. Je me demande même ce qui suit n’a fonctionné sur certains navigateurs, mais on n’y est visiblement pas encore :
h3 { content: url(http://…/test.png); }
CSS a beaucoup évolué, les navigateurs aussi. J’espérais qu’on avait enfin résolu ce problème ultra bateau. Visiblement non. La seule solution passe par des polices de caractères d’icônes et des reconnaissances de ligature. Le reste n’a que peu changé en 10 ans, on a juste enlevé les besoins de compatibilité sur les vieux navigateurs.
J’avoue que je ne comprends pas. On ajoute des fonctionnalités de folie et on ne gère toujours pas la base qui a généré des milliers de pages en bidouilles de contournement. Qu’on m’explique…
Travailler avec ES2015 c’est quelques changements sur les déclarations des variables.
Premier changement : Les modules ES2015 sont implicitement en mode strict. Y utiliser une variable non déclarée provoque une erreur. Ce seul changement est une bénédiction vu l’ubuesque comportement par défaut de Javascript. Il reste que ça ne changera pas grand chose pour qui utilisait déjà un outil d’analyse de code (linter).
Pour déclarer les variables nous avons aussi le nouveau mot clef let en complément de l’ancien var. La portée est alors limitée au bloc de code parent le plus proche (if, while, function, for…) au lieu d’être étendue à toute la fonction parente.
let a = 2;
for(let b=1; b<3; b++) {
let a = 3;
a = 4;
}
console.log(a); // 2 et non 4
Au début j’étais enthousiasmé. J’ai trouvé exceptionnel de pouvoir travailler avec des variables jetables le temps de quelques lignes et j’ai pensé éviter de nombreuses réutilisations par erreur.
À l’usage c’est un ajout sympa mais pas si révolutionnaire. Si c’est pratique c’est surtout pour gérer les fermetures syntaxiques (closure) au sein des boucles. Le reste du temps ça n’a que peu d’influence quand on a des fonctions de taille et de niveau d’imbrication raisonnables.
var fns = [ ];
for(var i=1; i<3; i++) {
fns.push( function () { console.log(i); } );
}
var fn = fns[0];
fn(); // affichera 3 et non 1
//----
fns = [ ];
for(let j=1; j<3; j++) {
fns.push( function () { console.log(j); } );
}
fn = fns[0];
fn(); // affichera 1
Je me demande si ça pourrait être la portée par défaut dans un langage. Visiblement certains pensent que non mais je n’ai pas été convaincu par l’argumentaire.
L’autre nouvel arrivé c’est const. Déclarée ainsi la variable a la même portée qu’un let mais on ne peut pas y affecter une valeur différente.
Là aussi c’est pas mal d’enthousiasme. Une variable qui est modifiée sans avertissement par une fermeture lexicale ou un module tiers, ça fait parfois des dégâts.
Le problème c’est que ça ne protège pas vraiment de ça. Si on ne peut pas affecter de nouvelle valeur au même nom de variable, la valeur elle même n’est pas immuable. On peut toujours faire changer d’état un objet ou modifier les éléments d’un tableau. Dommage…
const tab = [ ];
tab[3] = 4; // ne provoque pas d'erreur mais change `tab`
const obj = {
var priv = 2;
this.chg = function() { priv = 3; };
};
obj.chg(); // `obj` vient de changer d'état silencieusement
tab = [1, 2, 3]; // là par contre on génère une erreur.
Pour obtenir une vraie sûreté il faut utiliser des des structures de données explicitement prévues pour. On ne peut plus utiliser les raccourcis habituels { } ou [ ] et l’instanciation devient bien plus verbeuse. Facile d’oublier par inattention et par habitude.
import immutable from "immutable";
const map = Immutable.Map({a:1, b:2, c:3});
// map ne changera plus jamais de valeur
Le problème c’est que tous les modules tiers continuent à utiliser les structures de données variables habituelles. Malheureusement des modules tiers, vue la pauvreté de la bibliothèque standard de Nodejs, on en utilise des tonnes, y compris pour des fonctions de base.
Pour se protéger vraiment des changements d’état il faudra non seulement utiliser explicitement nos structures de données immuables (aie), mais en plus faire régulièrement des conversions quand on communique avec des modules tiers (ouch).
Il y a tout lieu de penser qu’on finira par avoir des données variables et d’autres immuables, suivant d’où elles viennent et comment elles sont déclarées. Il faudra réfléchir à chaque utilisation, parfois remonter à la création de la donnée. Possible même que le comportement de const avec les structures de données natives nous incite plus d’une fois à nous croire en sécurité alors que ce ne sera pas le cas.
Pour moi c’est le scénario du pire. Non seulement on complexifie le code (plus verbeux) et la charge cognitive (savoir à chaque fois quel est le type de variable et le type de données), mais en plus on garde des risques.
Pour jouer à ça il aurait fallu que le langage s’assure que ce qu’on déclare comme tel soit réellement immuable, jusqu’en profondeur. Je comprends très bien pourquoi ça aurait été difficile voire impossible, mais du coup ce const m’a l’air d’une vraie fausse bonne idée. Dommage…
Pour autant je me prends quand même à utiliser const pour les littéraux. Ça ne coûte pas grand chose et ça fixe par écrit l’intention que j’ai en tête. Même si je n’y suis pas obligé, je fais tout de même attention à garder let quand j’utilise un tableau ou un objet natif. J’ai trop peur d’induire en erreur le prochain développeur qui passe (d’autant que ce sera probablement moi).
Je jetterai peut-être de nouveau un œil à immutable.js si une partie significative des modules s’y convertit. Entre temps le ratio bénéfices/(risques+défauts) me parait assez faible.
Au delà de ces questions de déclarations, j’en tire un avis plutôt négatif sur la propagation des variables en Javascript. On fait des fermetures lexicales de partout et on ne maitrise pas bien les effets de bord. Pas étonnant que les développeurs cherchent à avoir des variables et des structures de données immuables ! Si la propagation des variables était plus saines au départ, ce besoin ne ferait pas surface ainsi.
var i = 1;
function hello10times() {
for(i=1; i<10; i++) {
console.log("hello ");
}
}
hello10times();
// oups ! i a changé et vaut désormais 10
PHP est plus strict (ouch, dire ça me fait mal) : Les variables ne sont pas déclarées mais ne sont jamais héritées d’un contexte parent sauf à le déclarer explicitement, avec global pour les variables globales, ou use pour les fermetures lexicales. On peut toujours faire des effets de bord assez moche, mais on les voit venir assez facilement.
$i = 3;
$hello10times = function () {
for (i=1; i<10; i++) {
echo "hello ";
}
}
// $i vaut toujours 3
$hello10times = function () use ($i) {
for (i=1; i<10; i++) {
echo "hello ";
}
}
// $i vaut 10 mais là c'est forcément intentionnel
La visibilité des variables de Python est plus proche de ce que fait Javascript mais, sauf à le déclarer explicitement, si on utilise une variable d’un contexte parent, c’est en lecture seule. On garde des effets de bord, mais c’est déjà plus limité (bon, en échange savoir si la variable utilisée est locale ou héritée n’est pas toujours super explicite).
D’ailleurs, quitte à parler d’explicite, je trouve dommage d’avoir à déclarer mes variables en Javascript. Il n’y a pas vraiment le choix vu l’historique du langage mais ça reste agaçant vue la faible valeur ajoutée de la chose, surtout quand je vois avec Crystal que même un langage à typage statique peut s’en passer.
Si j’avais à créer un langage de zéro je pense que j’apprécierais de ne pas avoir à déclarer mes variables, éventuellement leur donner la portée par défaut de let, mais avec la déclaration explicite de PHP pour les fermetures lexicales (avec peut-être une exception pour les petites fonctions anonymes d’une unique ligne/expression).
L’idée de const me plait beaucoup, mais uniquement si le langage se révèle capable de réellement rendre la donnée totalement immuable, et ça en profondeur. À minima le freeze de Ruby serait une demie-solution (une demie seulement parce qu’il faut penser à faire un freeze récursif sur un clone de tous les objets avant leur affectation par const, ce qui est assez pénible). Celui de Javascript ne me semble pas efficace pour bloquer les changements d’état d’objets qui contiennent des propriétés privées (implémentées via des fermetures syntaxiques).
Tiens, ça pourrait même être intégré au langage : si l’affectation se fait avec := plutôt qu’avec =, alors ni la variable se voit affecter une copie immuable de la donnée, sans possibilité de modification ou ré-affectation.
Si vous développez le nouveau langage de demain, vous avez désormais mon cahier des charges :-)
Après la mise en place, il est peut-être temps de faire un premier script. J’ai tenté un petit script que j’ai fait la veille en ruby : lister toutes les images dans une hiérarchie de répertoires et faire un gros fichier Json qui récapitule les différentes tailles.
Faire un petit fichier outil CLI à l’aide de commander.js : un callback. Lister les fichiers d’un répertoire : un callback. Lire les exif : un callback. Écrire dans un fichier JSON : un callback.
Bon, lire et écrire peuvent se faire en synchrone sans callback – et dans mon cas précis ça ne changerait probablement rien – mais je suis là aussi pour apprendre comment faire pour plus tard dans cet écosystème.
Une hiérarchie de quatre fonctions de rappel pour ce qui m’a pris 5 à 10 lignes tout mouillé en Ruby, ça me fait mal. J’avoue, je suis presque surpris que la transformation en JSON ne me demande pas un callback.
Me voici en plein callback hell. Le problème est connu. J’ai bêtement pensé qu’on me donnerait une solution rapidement, un outil ou un usage à suivre.
On me pointe vers les promesses ES2015 mais l’API Node et tous les modules en ligne continuent à utiliser des callback. Sérieusement, personne n’a cherché à présenter l’API Node directement en promesses ?
C’est donc à moi de transformer chaque méthode ou chaque module pour qu’il utilise des promesses. Promisify semble être la baguette magique pour ça. À partir de là il suffit de convertir chaque module pour enchaîner des promesses (attention aux écueils).
Franchement ça reste assez moche. Des gens biens me pointent vers les systèmes à base de générateurs (je recommande la lecture de ce lien) et le module co. Le code résultant est déjà bien plus lisible malgré les artifices.
On me rappelle alors les async / await (là aussi, je recommande la lecture). Je crois que c’est seulement maintenant, après cette exploration, que je comprends l’intérêt et le fonctionnement. Parfait, si ce n’est qu’il faut choisir presque au hasard entre trois plugins différents pour ajouter la fonctionnalité à Babel.
Attention, ce n’est pas magique. Il faut se rappeler que ce n’est qu’une surcouche aux promesses, et il y a quelques écueils (lien indispensable si vous comptez utiliser async/await) à bien connaitre là ici aussi, entre autres pour ne pas perdre les exceptions dans un trou noir.
Je me retrouve avec un code qui a l’air relativement élégant mais la réalité me rattrape : Visiblement quasi aucun code en production ne fonctionne ainsi. Une majorité des gens utilisent encore des callbacks, les autres se sont contentés des promesses. Est-ce une bonne idée de déjà viser les async/await ?
Il reste aussi que j’ai l’impression de retrouver le mode multi-tâche coopératif de Microsoft Windows 3.1 en moins bien intégré. Je ne vois aucune raison pour que la bibliothèque standard m’impose des callbacks, des promesses ou des async/await à tout bout de champ plutôt que de gérer ça en interne.
L’OS sait déjà passer à un autre processus quand mon programme est en attente d’une i/o. Si la machine virtuelle du langage veut gérer plusieurs fils d’exécution en interne pour optimiser le processeur, qu’elle le gère elle-même via l’API mise à disposition. C’est à elle d’identifier que je veux ouvrir un fichier et de savoir qu’elle peut favoriser un autre fil d’exécution en attendant que le disque me remonte la donnée. Je trouve ahurissant que ces mécanismes débordent sur mon code et le complexifient ainsi.
Oui, les promesses ne servent pas qu’à gérer la lenteur des i/o et faire coopérer les différents fils d’exécutions de la machine virtuelle V8 mais c’est quand même pour ça qu’on me les impose partout dans l’API de Node.js. Ça en devient même un style de programmation et les modules proposent des callbacks partout et pour tout (à vue de nez, y compris là où ça n’a pas vraiment de sens, à mon humble avis par mimetisme).
Promesses, async, callbacks… J’adore tous ces concepts, mais quand j’en ai besoin moi, pas pour compenser les choix d’architecture du moteur sous-jacent.
Javascript a énormément évolué, dans le bon sens. Côté syntaxe ES2015 et suivant donnent un résultat qui m’attire beaucoup. Le fonctionnement et l’API de Node.js me semblent pour l’instant gâcher tout ce résultat. Un beau langage avec un boulet aux pieds.
PHP a été mon langage favori pendant presque 10 ans. Ruby l’a suivi pour à peu près la même durée. Javascript a été l’outil secondaire pas très attirant pour quand il n’y a pas d’autre choix, c’est à dire sur navigateur.
Avant-hier j’ai eu un petit pincement de frustration en cherchant à déstructurer un dictionnaire lors d’une affectation. Ruby n’a toujours qu’une demie solution pas très élégante. PHP et Javascript ont tous deux énormément évolué entre temps, au point qu’on ne les reconnait qu’à peine.
Si Ruby garde des capacités inégalées pour faire de la méta-programmation, 10 ans c’est peut être le bon moment pour reprendre un autre langage de zéro.
Je fais du web, j’aime beaucoup l’idée de l’isomorphisme, il me faudra donc quelque chose qui sache compiler en Javascript. Elm pourrait me faire du pied vu sa gestion des types mais c’est un pari osé considérant qu’il est encore absent côté serveur.
Ça sera donc Javascript. D’abord pour quelques scripts en ligne de commande, puis peut-être des applications plus sérieuses.
Reprendre de zéro c’est l’occasion de laisser le passé derrière soi et recommencer comme si c’était un nouveau langage. Je ne prends que les dernières versions et outils récents dans la chaîne, voire ce qui n’est pas encore sec mais qui arrivera demain.
Il s’agit aussi de reprendre de zéro, pour apprendre. Exit donc les boiler plate et autres kits de démarrage rapide.
Première étape : installation de npm (3.10.3) et nodejs (6.3.1).
# Sur Mac avec Homebrew (http://brew.sh/) brew install nodejs
et initialisation du projet (un peu de doc si besoin pour aider à remplir)
mkdir my-js-project cd my-js-project npm init
Ensuite l’idée c’est d’utiliser le nouveau Javascript moderne et ne chercher aucune compatibilité passée. Installation de Babel pour gérer ES2015 et + :
npm install --save-dev babel-cli
La plupart des sites recommandent des preset pour ES2015 ou React mais visiblement Nodejs 6.x gère déjà l’essentiel des fonctions nativement. Il existe au moins trois preset spécifiques pour Nodejs 6 mais la seule configuration commune aux trois est le plugin qui transforme les modules ES2015 en modules Commonjs. Je suis donc reparti de là :
npm install --save-dev babel-plugin-transform-es2015-modules-commonjs
Puis l’édition du .babelrc :
{
"presets": [ ],
"plugins": [ "transform-es2015-modules-commonjs" ]
}
Si quelque chose manque à Nodejs 6, il faudra que j’ajoute le plugin correspondant. Voici les plugins sur lesquels mes trois presets étaient en désaccord :
Je n’ai pas pris le temps de les tester un par un pour voir lesquels étaient réellement nécessaires pour pas. Si quelqu’un a le courage de faire le travail…
Reste à enfin permettre d’exécuter un premier script. J’ai tenté de suivre les usages en mettant les sources dans src/ et les fichiers compilés dans lib/ avec un index.js comme fichier principal.
mkdir lib echo "Compiled files will go here." > lib/README.md echo "Leave these files untouched" >> lib/README.md echo "and modify ../src/* instead." >> lib/README.md mkdir src echo "Source files will go here." > src/README.md echo "They should be compiled before any use." >> src/README.md touch src/index.js
Et la configuration du package.json pour lancer tout ça (notez le main qui prend en compte notre nouveau chemin et le scripts qui liste nos deux nouvelles actions) :
{
"name": "my-project",
"main": "./lib/index.js",
"scripts": {
"build": "babel src -d lib --source-maps",
"watch": "babel src -d lib --watch --source-maps"
},
"devDependencies": {
"babel-cli": "^6.11.4",
"babel-plugin-transform-es2015-modules-commonjs": "^6.11.5"
}
}
Un npm run build permet de compiler tous les fichiers, un npm run watch permet de surveiller en temps réel les modifications des fichiers sources pour mettre à jour les fichiers destination correspondants.
J’ai ajouté un README, le .gitignore proposé par Github pour un projet Nodejs, une licence, et ‘op, vous trouverez le tout sur Github.
Ça fait déjà pas mal pour toujours aucune ligne de Javascript utile.
Quelques feedback après ce tout petit premier pas :
Oui, j’ai cherché les ennuis, il existe des boiler plate tout faits, mais je ne crois pas avoir le même problème avec Python, Ruby, PHP ou d’autres.
Le fait d’avoir une étape de compilation avec Babel n’aide pas mais Java pourrait en dire tout autant. Pourquoi n’existe-t-il pas un babel init qui lit la version courante de Nodejs, m’installe un .babelrc adapté à cette version et me modifie mon package.json pour m’ajouter les raccourcis build et watch ?
Oui, je pourrais faire une pull-request, mais fallait-il m’attendre ?
Franchement c’est la plaie. Je ne dirais pas qu’il n’y a aucune doc, mais il y en a dans tous les sens. La plupart ne sont pas à jour, toutes semblent incomplètes, et il est bien difficile de savoir si telle ou telle a pris en compte les dernières évolutions.
Peut-être n’ai-je pas trouvé la bonne référence ? Dites-moi.
Rien que le npm init n’était indiqué sur aucune doc que j’ai croisé. Pire : si on l’oublie il n’y a pas de message rouge très explicite pour indiquer que les npm install –save-dev n’auront pas l’effet demandé. Il a fallu comprendre qu’il fallait créer un package.json, puis découvrir qu’il n’était pas nécessaire de le faire à la main.
Ce n’est que le début. Quand il va s’agir de choisir une bibliothèque ou des outils, je sens que ça va être toute une histoire pour d’y retrouver. La doc de setup de Babel en donne un premier aperçu.
J’ai l’impression qu’à chaque étape la roue est en pleine reconstruction, et qu’on en a fait plusieurs versions différentes en parallèle, pour tout.
Je suis aussi assez peu fana aussi des config dans des fichiers Json. J’ai l’impression de retrouver les fichiers de configuration XML de Java. Je n’ai pas l’impression que ce soit beaucoup plus lisible.
La grosse différence c’est que Java a créé ces configurations avec tout un outillage autour. Le développeur n’avait que rarement besoin d’y plonger manuellement. C’était géré automatiquement par les IDE et les scripts.
J’ai ajouté un plugin au .babelrc décrit plus haut. Ce plugin a une option. Je me retrouve avec un Json de 7 lignes dont 4 qui contiennent autre chose que des crochets et accolades fermantes.… et déjà un dictionnaire dans un tableau dans un tableau dans un dictionnaire. Rien que ça.
Même mon petit package.json me parait délicat à manipuler malgré l’indentation. Heureusement que les dépendances sont ajoutées automatiquement par npm lors de leur installation.
Là, dès qu’on dépasse le simple clef valeur, j’ai l’impression de me retrouver avec une double peine : Un fichier de configuration peu aisé à manipuler, mais pas pour autant d’outil pour le faire à ma place.
J’ai cherché à agencer des vignettes de photo de façon harmonieuse sur une page web. Le problème à l’air simple mais j’ai des photos de tous formats, dont certains vraiment atypiques.
La méthode la plus simple c’est de choisir un format d’images, choisir un nombre de colonnes, et de s’y tenir. Si une image n’a pas le bon ratio, il suffira de couper ce qui dépasse. 500px utilise encore ce système pour la plupart de ses vues.
Pour aller plus loin on peut mettre quelques photos en grande taille en prenant la place de plusieurs autres. On casse la monotonie tout en permettant de mettre en avant les images les plus importantes.
En prévoyant plusieurs agencements différents prédéterminés on peut réussir à caser des images en format différent, et ne pas trop dénaturer les formats portraits ou les images très étirées. On reste toutefois fixés à des formats prédéterminés.
Le système de grille est rapide et efficace. La seule contrainte est de choisir entre la capacité de respecter scrupuleusement l’ordre des photos et celle de choisir manuellement lesquelles seront mises en avant.
L’algorithme de Packery va encore plus loin sur ce chemin. À partir d’une grille fixée, il propose de définir un nombre de lignes et de colonnes pour chaque image et de la placer à l’espace le plus adapté. L’ordre n’est alors qu’indicatif et on doit toujours rogner les images pour les faire tenir sur un nombre fixe de lignes et colonnes, mais on y place des formats et des tailles très différentes. Pas de secret toutefois, cet agencement laissera forcément des blancs. À vous de voir si c’est acceptable, quitte à tenter de les combler par quelques mots.
Quel que soit le système de grille, le réel enjeu est de savoir ce qu’on peut couper ou pas dans chaque image pour qu’elle colle aux formats prévus. Certains algorithmes y arrivent maintenant assez bien, surtout quand il y a des visages.
Même si mon cas d’usage me permettrait de choisir manuellement comment découper chaque image au cas par cas, intellectuellement ça me gêne de couper des pixels que j’avais volontairement choisi de garder lors de la création initiale de l’image. Je crains aussi que le visiteur s’en fasse une idée faussée et au final n’ouvre pas l’image dans son format voulu. C’est particulièrement vrai pour les images très en hauteur ou très en largeur, qui ne pourront jamais donner le même ressenti si elles sont tronquées.
L’autre méthode est d’empiler les photos par lignes ou par colonnes en respectant leur ratio.
Tumblr le fait par colonnes en mettant chaque image sur la première place disponible. On obtient une sensation de vrac où l’ordre des images n’est qu’à moitié respecté mais le résultat est parfait pour leur cas d’usage. Toutes les images ne terminent pas à la même hauteur mais c’est là encore tout à fait légitime pour le système de flux sans fin que représente un Tumblr.
On peut imaginer de mettre en avant des images en les passant sur deux colonnes mais, sauf à espérer un cas exceptionnel où les deux images du dessus s’arrêtent pile à la même hauteur, il faudra soit laisser du blanc soit couper un peu la plus longue des deux.
Avec un algorithme un peu intelligent on peut tenter de repérer quand deux images arrivent presque à la même hauteur et donc ne couper que quelques pixels qui ne se verront pas, mais ça veut aussi dire que l’image mise en avant est quasiment laissée au hasard. La probabilité d’en avoir une dépend directement de la quantité de pixels qu’on accepte de rogner sur les images.
Pour quelque chose de plus structuré Flickr a choisi une disposition par lignes. On choisit une hauteur cible et on empile toutes les images une à une jusqu’à la fin de la ligne. Ça ne tombe jamais juste mais Flickr se permet alors de faire varier légèrement la hauteur de la ligne à la hausse ou à la baisse. Si on respecte les ratios des images concernées, on finira forcément par tomber sur la largeur de ligne souhaitée. On peut choisir de garder la dernière image ou pas (respectivement en diminuant ou augmentant la hauteur de ligne) en fonction de la disposition la plus proche de la hauteur idéale.
Avec un peu de complexité on doit pouvoir éviter les lignes incomplètes en fin de page. Il suffit de tenter plusieurs combinaisons sur les x dernières lignes puis voir laquelle respecte le mieux la hauteur cible pour chaque ligne parmi celles qui n’ont aucune ligne incomplète. Je ne suis cependant pas totalement certain que ça vaille le coup, et ça peut faire varier significativement la hauteur des dernières lignes.
Ce système permet des mises en avant simples en mettant une image en pleine largeur de temps en temps. On peut même, si on le souhaite, avoir des mises en avant à largeur arbitraire. Il suffit alors de mettre les mises en avant sur un des bord et de reprendre l’algorithme standard sur la largeur restante. Une fois arrivé proche du bas de l’image mis en avant, on la réduit ou l’agrandit légèrement (avec pour effet d’agrandir ou de réduire proportionnellement l’espace horizontal sur le côté, et donc la hauteur correspondante) jusqu’à ce que les deux correspondent.
On peut aussi imaginer ne pas se limiter à une seule mise en avant par hauteur et les empiler sur un ou deux côtés, y compris sur des hauteurs différentes. La contrainte va être de toujours avoir les plus hautes à l’extérieur.
Il reste que la disposition en colonnes de Tumblr flatte les images verticales et vignétise à l’excès des images orientées format paysage. La disposition en lignes de Flickr fait l’opposé et rend difficile la lecture des images au format portrait.
Si un format est très fortement majoritaire, on peut imaginer utiliser le système des mises en avant pour compenser.
Je n’ai pas vu d’adaptation de l’algorithme Flickr en ce sens. Il faut dire que ça complexifierait nettement un système qui est sinon relativement simple. Si j’ai un peu de temps, je vais peut-être tenter l’expérience.
Quelques liens si le sujet vous intéresse :
– Dis, on met quoi dans une équipe technique ?
Ça dépend du temps, du produit, des besoins. Voici ma recette par défaut, à réagencer en fonction de la réalité. Il reste qu’à chaque fois je finis par me dire que j’aurais aimé la voir suivre ce schéma :
1 et 2 : Donc au début on commence, il faut un ou deux développeurs. Idéalement à ce niveau ils savent toucher un peu de front et un peu de back, et apprécient de pouvoir intervenir partout. Pas d’administration système à cette taille, on externalise un maximum.
Petit intermédiaire. Il faut une direction technique avant de passer au troisième membre de l’équipe. Ce peut être un directeur technique à part entière ou un des deux développeurs qui a suffisamment de bouteille mais il faut quelqu’un qui a une vision technique, et pas un néophyte.
3 : Le troisième c’est le grand oublié : le web designer. Il fait de l’UX, de l’UI, et va définir une vraie expérience client. Bien évidemment tout dépend du métier et du produit mais recruter trop tard est habituellement une erreur. La mode est de considérer que ce profil doit même faire partie des fondateurs.
4 : On complète avec un troisième développeur. On peut commencer à envisager un spécialiste qui apporte une expertise qui manque aux deux autres mais il faudra quand même qu’il accepte de toucher un peu à tout.
5 : L’équipe commence à avancer, maintenant il lui faut quelqu’un pour donner une direction et prendre du recul. On peut l’appeler product owner, responsable produit, chef de projet fonctionnel, analyste métier… Il aura pour charge de réfléchir aux usages, imaginer le produit, assurer la vision. Ce doit être quelqu’un de dédié, sans position hiérarchique sur le reste de l’équipe.
6 (et 7 ?) : L’équipe avance, dans le bon sens, il reste à lui donner un peu de puissance avec un ou deux autres développeurs. À partir de quatre développeurs c’est la taille où l’effort est démultiplié et où on peut commencer à assurer les imprévus, ou les congés de chacun. Au delà de 5 développeurs on commence à faire des sous-équipes et ça n’a plus grand intérêt.
Les équipes les plus dynamiques avec lesquelles j’ai travaillé ont des développeurs qui travaillent tous sur l’intégralité du produit mais on peut aussi avoir quelques experts qui interviennent essentiellement sur leur domaine de compétence.
8 : Second grand oublié : Le dev op – ou sys admin, peu importe le nom. Son rôle est d’assurer la production mais sa réelle valeur est de fluidifier tout l’outillage interne, comme la plateforme d’intégration continue ou les scripts de déploiement.
Il n’a d’intérêt qu’avec une équipe qui tourne, mais s’en passer c’est comme continuer en gardant un boulet aux pieds. Avant ce sont les développeurs qui sont obligés de perdre du temps et du focus avec tout ça.
9 : Je vais à neuf avant de m’arrêter mais j’ajoute quand même un dernier profil avec un technicien. C’est lui qui va assurer les tâches d’exploitation courantes, s’occuper du support technique, du support utilisateur, et soulager le product owner.
On peut s’en passer mais c’est au prix d’un manque de focus non négligeable, donc d’un peu de gâchis.
Je n’ai pas parlé de manager mais à neuf le besoin s’est peut-être déjà fait sentir depuis un petit moment. S’il existe, il peut faire le dixième. Le problème du manager mérite plus d’un billet mais je retiens une règle : ni la direction commerciale de la société, ni le product owner de l’équipe. Ce peut être le CTO qui gère la direction technique décrite plus haut.
Je n’ai pas mis de QA non plus. Je continue à penser que l’équipe doit être responsable de ce qu’elle livre. Une QA séparée à tendance à déresponsabiliser mais aussi à ajouter de la distance avec la réalité et du délai lors des livraisons. Ça aura du sens quand il y aura plusieurs équipes, pas tout de suite. Le dev op pourra par contre outiller et automatiser un maximum de tests et de processus entre temps.
Et vous, vous conseillez quoi comme composition ? Qu’ai-je oublié ?