Sous le coude pour lecture ultérieure: "Pourquoi je préfère la programmation fonctionnelle".

php le mal aimé.  ^^

Sous le coude: En matière de "best practice" pour écrire des démons Linux, les choses ont changé depuis systemd. Il ne faut plus faire comme avant.
(via je ne sais plus qui)

Mais c'est tellement ça ! 😂
#docker

Pas encore eu le temps de regarder, mais ce site vous apprend à comprendre et bien utiliser les indexes des bases de données.
(via @framasky@framapiaf.org)

Ok ça m'a fait marrer :-D
(via Sam&Max)
(copie là: https://framapiaf.s3.framasoft.org/framapiaf/media_attachments/files/004/163/185/original/e0b36208f1e00f01.jpg )

Mais c'est TELLEMENT représentatif d'une frange de développeurs.
Cela rejoint ceci: https://sebsauvage.net/links/?J2rX0Q et ceci: https://sebsauvage.net/links/?xJFS6A

Étude de cas intéressante: Construire une interface graphique pour rsync.
La difficulté de présenter quelque chose de simple, sans pour autant empêcher des usages avancés.
Et surtout l'excellent principe du «Tools that teach» qu'on retrouve dans trop peu de GUI: Quand vous sélectionnez des options, l'UI vous montre la ligne de commande correspondante. Ce sont des UI qui DONNENT DU POUVOIR aux utilisateurs.
(Par contre, côté choix technique: Electron.  BEUUUUARRRK!)

Les différentes manières pour un développeurs de corriger les bugs.

Je cite: « Il existe énormément d’informations obsolètes sur la toile à propos de PHP, ce qui conduit les nouveaux utilisateurs de PHP à prendre de mauvaises habitudes, propageant de mauvaises pratiques et du code peu sûr. PHP: La bonne manière est une référence concise et facile à lire à propos des conventions d’écriture les plus connues sur le PHP, des liens sur les tutoriaux faisant autorité sur le web et des pratiques que les contributeurs de ce document considèrent comme meilleures à l’heure actuelle. »

(via twitter).
EDIT: Et un article de Sam&Max très pertinent: http://sametmax.com/le-bonheur-des-frameworks/

Sous le coude pour lecture ultérieure.

Selon la légende, "php c'est de la merde".
Sauf que depuis, php a évolué, son écosystème et ses outils aussi, et il a aussi de bons côtés.
À l'heure des horreurs lovecraftiennes node.js/npm/docker et autres usines à gaz montées en production, la simplicité du php est peut-être plus saine (et puis il y a des frameworks comme Laravel).

:-D

(POO = Programmation Orientée Objets)

Je suis encore tombé sur des articles très critiques envers l'OO.
Dans la pratique, de ce que je peux constater de son usage en entreprise, ça finit toujours en cathédrales démentes et in-maintenables.
Pourquoi ? J'ai une piste.

Quelle est l'une des choses les plus difficiles en informatique ?
Les graphes.
Et quand on fait de l'OO, qu'est-ce qu'on construit ? Des graphes. Des tonnes de graphes avec des dépendances dans tous les sens. La structure même de votre logique métier est codée dans des graphes.
Ça se tient.

Quelques liens pour avoir matière à réflexion:
http://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm
https://dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your-software
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
https://medium.com/@konradmusial/why-oop-is-bad-and-possibly-disastrous-e0844fa96c1f
https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117
http://4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
https://blog.codinghorror.com/your-code-oop-or-poo/
http://www.iwriteiam.nl/AoP_OOCH.html

Et il y a bien sûr bien d'autres problème: L'informatique, par principe, c'est le traitement en masse de données. Quand on fait de l'objet, on s'acharne à découper tout en objets unitaires les plus simples possibles, et à bien les isoler du reste.

Je ne suis pas en train de dire que l'OO c'est définitivement mal, mais il faut absolument arrêter de le traiter de manière religieuse comme certains développeurs le font: Considérer l'OO comme l'unique solution à tous les problèmes, le point de passage obligé, et refuser toute critique.

Tiens je ne sais plus si j'avais partagé ça.

Quand tu met une grosse requête SQL sur un wiki interne et que tu veux éviter que le premier neuneu venu la lance en prod sans réfléchir.
👍

Cutter est un désassembleur d'exécutables (un peu dans le genre d'IDA Pro).

Sous le coude: Un désassembleur libre.
Supporte les codes machine x86/x86_84/APM et Dalvik (Android).
Supporte les exécutables PE (Windows), ELF (Linux), PS1 (Playstation), DEX (Android), XBE (Xbox1) et quelques autres.
Il fait penser à IDA-Pro.

J'aime bien cet article. Il parle d'avoir un esprit pratique et de résoudre des problèmes concrets au lieu de faire des plans sur la comète.
(via https://lehollandaisvolant.net/?id=20190214132802)
Voir aussi: https://sebsauvage.net/links/?J2rX0Q et https://sebsauvage.net/links/?X2bozA

Si JD-GUI ne démarre plus (sous Java 9 par exemple), avec le message d'erreur:
Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make jdk.internal.loader.ClassLoaders$AppClassLoader(jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.URLClassPath) accessible: module java.base does not "opens jdk.internal.loader" to unnamed module @5b87ed94

Il vous suffit de démarrer JD-GUI avec la ligne de commande suivante:
java --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED -jar jd-gui-1.4.0.jar

J'admire totalement Fabrice Bellard  \o/

Mais WHAT ???
Techniquement, en principe, ce qu'il font afficher à l'écran n'est PAS POSSIBLE SUR UN APPLE II.
Visiblement, ils font changer le mode graphique de l'Apple II PENDANT le balayage de l'écran. oO

Je me note ça, je trouve la phrase très bien.
(via https://mastodon.hackerlab.fr/@webshinra/101098084613830479)