Pour lecture ultérieure.

Je garde le lien juste pour la citation en début d'article qui m'a choqué, mais qui est vraie: « Une base de données, c'est juste une variable globale dans votre application. Avec des accès concurrents. »  Il a raison ! C'est affreux 😱

Ceci est un moteur de jeu d'échec qui tient en 1024 octets de Javascript. Et il paraît qu'il n'est pas mauvais !
Les graphismes old-school en CGA 4 couleurs, c'est plutôt marrant.

Pas eu le temps de lire cette présentation, mais elle semble intéressante.

« Une meute de développeurs Python ayant repéré un jeune développeur éloigné de son troupeau, prêt à se jeter sur lui pour le convertir. »
^^

Je suis d'accord avec ça.
C'est pour ça que certaines applis que j'ai développées comme Shaarli ou ZeroBin ont le moins de dépendances possible, et s'installent juste en copiant les fichiers sur le serveur.
Il y a un tas d'applications qui me semblaient sympa et que je voulais installer sur mon serveur, et j'ai aussi laissé tomber car les installations sont trop compliquées ou lourdes.
A contrario, un DokuWiki ou même un NextCloud, c'est hyper-simple à installer: Vous posez les fichiers et ça roule.
(via http://warriordudimanche.net/article1466/6027db8e4a4da)

Sans déconner ?  Celeste, FEZ, SUPERHOT, Hollow Knight, Spelunky, Sonic et autres refaits en Pico-8 !
Je suis étonné de ce que les gens arrivent à faire dans cette console virtuelle Pico-8 malgré ses possibilités limitées.

Quelques astuces pour travailler plus efficacement en php.

Je garde sous le coude pour lecture ultérieure. L'idée portée par l'article me semble intéressante.
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?ZS952Q)

Go appartient à un GAFAM, Google. Ça oriente déjà assez rapidement le choix ce qui me concerne.
Comme je l'ai déjà dit, au bout d'un moment la qualité technique seule ne suffit plus à choisir une technologie. Il faut voir les licences, la gouvernance (coucou le W3C trusté par les GAFAM!), la juridiction à laquelle elle est rattaché, la communauté, le comportement de ceux qui tiennent le projet, la perrenité (coucou le cimetière Google!), les outils autour (comment sont distribués les paquets), les politiques de cycles de vie, versions et mises à jour, etc.

Tout cela est tellement vrai.
Mais parfois quand on bosse, on est sous pression (surtout au niveau des délais), et on fait de la merde. On se dégoûte soi-même.

Sous le coude pour lecture ultérieure.

Merci Riduidel pour cet article (http://nicolas-delsaux.hd.free.fr/Shaarli/?_Abm9A), ça me fait réaliser une chose:

Un développeur a deux choses en main: Le problème qu'on lui demande de résoudre, et la technique qui lui permet de le résoudre.
On cherche à avoir la technique la plus efficace, afin de se concentrer sur le problème. L'objectif, c'est le problème. La technique n'est qu'un moyen.
Donc nous avons conçu des outils pour nous simplifier la vie, pour rendre la partie technique plus efficace. C'est tout naturel.

Seulement ces outils censés nous simplifier la vie ajoutent en réalité une *charge mentale* aux développeurs.
Git est censé nous aider à gérer plus facilement les sources et leur modification. Mais il est complexe et impose un investissement intellectuel non négligeable, une charge mentale pour l'utiliser correctement.
Docker/Kubernetes sont censés simplifier le déploiement. Mais ils ont leur lot de problèmes et imposent une charge mentale pour savoir les utiliser et régler leurs problèmes spécifiques.
Les frameworks comme Vue.js/Angular/React sont censés simplifier et fluidifier le développement du front au back, mais nécessitent de comprendre et maîtriser leurs arcanes bien spécifiques avant même de produire un écran.

Tout ces outils, cumulés, finissent par imposer aux développeurs une charge mentale énorme sur la partie technique avant même de pouvoir commencer à produire du code, avant même de commencer à travailler concrètement sur le problème initial à résoudre. Vous dépensez du temps et de l'énergie pour comprendre la technique au lieu de dépenser ce temps et cette énergie pour réfléchir au problème que vous avez à résoudre.

Est-ce que ça vaut le coup ?  Est-ce qu'on a vraiment gagné du temps ?   Est-ce qu'on en gagnera à plus long terme avec ces outils ?  Je ne sais pas.

En fait si, je sais un peu.  Si on maîtrisait totalement *chacun* de ces outils, on gagnerait sans doute du temps, à court et à long terme. Cela ne fait aucun doute. Ces outils ont été conçus par des gens brillants, qui arrivent (par des sites web ou des conférences) à nous montrer tout le bien qu'ils peuvent produire. C'est beau, ça a l'air de marcher magnifiquement. Mais c'est normal: Ils maîtrisent à la perfection ces outils. Ils les ont conçus.
Dans la pratique, je constate que ces énormes cathédrales sont rarement bien maîtrisées (c'est le sujet de l'article), et que les gens perdent du temps à trouver comment bien faire les choses, voir comment faire les choses tout court. Non pas à cause du code qu'ils ont produit, mais déjà à cause des outils eux-mêmes.

Et c'est même pire que ça: Ces outils imposent une façon de penser spécifique. Mal comprise - et donc mal utilisée - cela impactera le code produit, qui non seulement sera sous-optimal par rapport au framework mais - comme il ne rentre pas bien dans l'état d'esprit du framework - sera compliqué à maintenir et faire évoluer. J'ai constaté ça sur divers projets.

Le monde du développement a oublié le principe du KISS pour se faire plaisir sur des outils qui - pris individuellement - sont séduisants. Du moins sur leur promesses.
Faites attention à la charge mentale que vous vous imposez en ajoutant ces outils.

Et un dernier mot d'avertissement: Faites attention à la perennité des outils que vous choisissez. Je pense en particulier aux frameworks Javascript dont la durée de vie est parfois particulièrement courte. C'est une dette technique que vous paierez. Et cher.
(Je le sais, je bosse en partie sur du WebObjects. Vous ne connaissez pas WebObjects ? Pourtant c'est le framework web qui était porté par une boîte aux moyen titanesques: Apple. Qui a décidé du jour au lendemain que ça ne l'intéressait plus.)
Grosse pensée pour les gens qui ont investi du temps à comprendre et maîtriser des technos mortes (Silverlight, etc.))

EDIT: Le xkcd approprié: https://xkcd.com/1597/

Sous le coude pour lecture ultérieure.

Les raisons de ne PAS utiliser un CDN pour le javascript.
(via Le Hollandais Volant).

Touvé au hasard du net : « le debugging, une énigme passionnante où vous êtes à la fois le détective, la victime et le coupable. »

L'auteur de SQLite (pour qui j'ai une énorme estime) ne veut pas de Git, et voici ses arguments.
(Il utilise FOSSIL, un excellent petit gestionnaire de sources qui contient un bugtracker et un wiki intégrés.)

Après tous les article anti-xml que je vous ai partagés, voici un article pro-xml.
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?ebA_BA)

Sous le coude.

Pas encore lu, mais je met ça de côté.

Alors ça, voyez-vous, c'est amusant.

Contexte:
Quand on développe un jeu, on doit choisir quelle "API" utiliser pour la 3D:
 - DirectX (Microsoft, mais du coup votre jeu ne marchera que sous Windows)
 - OpenGL (multiplateformes, mais très ancien)
 - Vulkan (multiplaformes, moderne et performant). Vulkan est actuellement en développement très actif.

DXVK est une couche d'émulation qui permet de faire tourner les jeux conçus pour DirectX vers Vulkan, donc de faire tourner des jeux Windows sous Linux. C'est son principal but.

Sauf que Vulkan est aussi disponible sous Windows. Et comble de l'ironie, les joueur qui passent par DXVK ont de meilleures performances qu'en DirectX pur !

Jeu => DirectX => DXVK => Vulkan => Carte graphique est plus performant que:
Jeu => DirectX => Carte graphique

(C'est du moins vrai pour DirectX 9/10/11.  DirectX 12 est - comme Vulkan - nettement plus bas niveau.  dxvk ne sait émuler que DirectX 9/10/11. Pour émuler DirectX 12, il faudra passer par un autre programme, vk3d, qui est encore jeune et pas abouti, et qui a priori n'apportera pas de gain de performances.)

Un super article qui explique la différence entre les exécutable liés statiquement et dynamiquement, et qui donne des exemples de liens dynamiques.