ET. MERDE.
Unity, le moteur de jeu 3D le plus populaire, a fusionné avec ironSource, une entreprise qui fait des adwares/malwares.
On ne sait pas trop ce que ça va donner, mais ça pue.

De nombreux exemple d'illustration du code en utilisant l'ASCII.
Parfois, c'est utile de mettre des schémas dans les commentaires du code pour aider le développeur qui va maintenir ce code à le comprendre.

OH ! Je me garde cette astuce: Elle permet d'utiliser SQLite pour lancer une requête sur un fichier CSV et d'en récuperer le résultat. Le tout en une seule ligne de commande.

sqlite3 :memory: -cmd '.mode csv' -cmd '.import taxi.csv taxi' 'SELECT passenger_count, COUNT(*), AVG(total_amount) FROM taxi GROUP BY passenger_count'
This uses the special :memory: filename to open an in-memory database. Then it uses two -cmd options to turn on CSV mode and import the taxi.csv file into a table called taxi. Then it runs the SQL query.

EDIT: Voir aussi https://dinedal.github.io/textql/

aka  « Tu peux me dire combien de jours il te faut pour développer ça ? »

Ah mais c'est pas mal, ça. C'est comme CanIUse, mais pour php au lieu d'html/css/js.

Le titre m'a interpellé.

Ok c'est super impressionnant.

Quelques astuces php pour éviter que des données sensibles se retrouvent dans les logs.

Ce qui est bien en informatique, c'est qu'on peut en apprendre tous les jours jusqu'à la fin de sa vie, on ne saura jamais tout.
Je n'avais jamais entendu parler de SSE (Server-Sent Events). Utile pour l'envoi de données temps réel du serveur vers le client. Et ça marche dans tous les navigateurs, en passant par HTTP (donc ça bénéficie aussi de la compression, ce qui n'est pas le cas des WebSockets).

Il existe différents langages de shaders : HLSL, GLSL, MSL, WGSL.

Sous le coude pour lecture ultérieure: Comment est développé le jeu Dwarf Fortress.

Pour info, la version améliorée de Dwarf Fortress (qui doit sortir sur Steam) continue de progresser, mais toujours aucune date de sortie annoncée.
https://store.steampowered.com/app/975370/Dwarf_Fortress/

(Et pour ceux qui ne connaissent pas encore cet incroyable jeu, 4 articles à lire:
https://sebsauvage.net/rhaa/index.php?2011/07/26/08/17/41-alerte-nouveau-bouffeur-de-temps-en-vue
https://sebsauvage.net/rhaa/index.php?2011/07/27/07/41/16-premieres-heures-dans-dwarf-fortress
http://jeux-video.krinein.fr/dwarf-fortress-5692/critique-5716.html
https://web.archive.org/web/20160630152305/http://www.comprendrelactu.com/loisirs/jeux-video/joues-y-c-est-gratuit-dwarf-fortress.html

Tiens, le bullshit du "no code" est de retour.
Encore.
Parce que c'est loin d'être la première fois qu'on nous sert cette soupe réchauffée.
Toujours la même métaphore pétée des Legos pour construire des logiciels.
Et non, ça ne marchera toujours pas. Ça n'a pas marché avant, ça ne marchera pas non plus maintenant.
Ça montre juste une incompréhension de ce qu'est le monde du logiciel (analyse, développement, architecture logicielle, intégration, déploiement, et tout ce qui tourne autour). Il n'y a pas d'outils magique.
Ou plutôt il est là pour vendre sa soupe, vu que - OH BEN ÇA QUEL HASARD - le monsieur a fondé deux boîtes qui vendent des outils no-code (airtable.com et alegria.academy).

"selon Gartner, d'ici quatre ans, 80% des applications créées le seront en no code."
CHICHE !
ALORS NOTEZ BIEN CETTE PHRASE, on on reparle dans 4 ans.  
Moi je vous parie que ça n'aura pas changé grande chose, le no-code, et que 80% des développements, au *minimum*, continueront d'être faits avec des outils traditionnels.

Anecdote: Il y a 20 ans, une personne (sachant que je suis dev) m'avait dit : "Ah tu verras bientôt on aura plus besoin des développeurs pour créer des logiciels !"
Moi: "Ah bon ? Grâce à quoi ?"
Lui: "Ça s'appelle SAP !"
J'en rit encore.
(Si vous connaissez pas SAP, sachez que ce logiciel donne des cauchemars à ceux qui s'en servent, et que c'est horriblement coûteux, lourd et privateur.)

PS: Utiliser la crainte d'un mal-être fantasmé des enfants pour vendre sa soupe, C'EST MAL. Ce sont les méthodes de La Manif Pour Tous.

EDIT: Juste pour vous donner une idée du niveau de bullshit du monsieur: « On ne crée pas des outils Nocode. On crée des solutions digitales à base d’outils Nocode grâce à notre communauté de makers professionnels. » (https://twitter.com/francislelong/status/1478859517777657856)

EDIT: L'ami Bluetouff enfonce le clou : https://bluetouff.com/2022/01/06/nocode-ou-la-promotion-de-lillettrisme-numerique/

EDIT: Tiens, un autre article bullshit: https://www.journaldunet.com/web-tech/developpeur/1509373-non-le-no-code-ne-signifie-pas-la-mort-du-developpeur/
« En 2022, les outils low-code et no code seront incontournables pour le développement d’applications et ils permettront aux entreprises d’accélérer leur digitalisation »
Mais oui, mais oui.

Tired: Faire un jeu de la vie de Conway dans un interpréteur Lisp.
Wired: Faire un intepréteur Lisp dans le jeu de la vie de Conway.
Ces gens sont fous ! 😅

(Contexte: Le "jeu de la vie" du mathématicien Conway est un exercice de programmation classique. On le programme dans des tas de langages différents. Ce jeu de la vie obéit à des règles simples et élémentaires, mais en assemblant suffisament de ces éléments simples, on peut construire des choses extrêmement compliquées, comme simuler des portes logiques (et/ou/etc.) qui sont à la base des microprocesseurs. Là, la complexité a atteint le point de re-créer un interpréteur pour un langage de programmation.)

Une cheat-sheet php orientée php 8. Sous le coude.

(Une "cheat-sheet" est une fiche mémo qui rappelle les principaux éléments d'un langage ou d'un logiciel.)

Oh purée... c'est assez effrayant.
Pour introduire volontairement des failles de sécurité, il suffit parfois de modifications mineures. Par exemple remplacer "==" (signe de comparaison) par "=" (assignation). Ces "attaques" sont visible pour un oeil averti.

Mais qu'est-ce qui se passe si l'oeil ne voit plus ?  Avec Unicode, il est possible d'utiliser des caractères qui ressemblent à notre alphabet latin, mais qui n'en sont pas, ou pire changer l'ordre d'écriture (gauche-droite) afin que le texte s'affiche d'une manière dans l'éditeur de texte, alors que le compilateur l'interprétera autrement. Cela ouvre la possibilité d'insérer des failles de sécurité pratiquement impossibles à voir, même si vous avez le code source sous les yeux dans votre éditeur de texte.
(Pour un exemple d'inversion gauche-droite, allez sur cette page: https://sebsauvage.net/wiki/ et recherchez mon adresse email dans la page: Elle s'affiche normalement, mais si vous regardez le source html, c'est un autre texte qui s'affiche).

Je pense qu'il serait intéressant que les éditeurs de texte aient une option pour afficher dans une couleur particulière tout ce qui n'est pas purement "texte latin" (0000-024F), ainsi que les caractères Unicode qui provoquent des modifications (retour arrière, changement de direction).

Des proof-of-concept de cette attaque dans différents langages sont visible là : https://github.com/nickboucher/trojan-source

Quand ton système a des tonnes de dépendances, la faille d'une seule dépendance devient la faille de ton système. Multiplie les dépendances, tu multiplie les risques. Simple, mathématique.
C'est pour cela que malgré l'attrait du DRY et des jolies librairies qui font le café, je préfère réduire les dépendances tant que possible. Et pas seulement pour des raisons de sécurité, mais aussi de dette technique.

Je pose ça là.

Quelques conseils. À examiner.
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?PwL06A)

Sous le coude.

Je me note l'idée, parce que c'est excellent:
Souvent quand on gère un cache local, on tape sur un script php qui va d'abord regarder si la copie local existe, et la sert avec un read() ou readfile() si c'est le cas (c'est le cas des miniatures de MinigalNano par exemple).

Timo a eu l'idée suivante: Au lieu de taper sur le script php, on tape directement dans le répertoire du cache, directement avec l'url de la ressource. C'est purement statique, donc Apache servira très rapidement la ressource si elle existe, sans exécuter de php.
En cas de 404, on renvoie de manière transparente (avec un .htaccess) sur le script php qui ira mettre la donnée en cache avant de la servir.
Donc pour tout "cache hit" (ce qui constituera la majorité des appels), on évite carrément d'exécuter du php. C'est très malin.
Cela permet d'avoir un cache avec de très bonne performance sans avoir à sortir l'artillerie lourde (genre Varnish ou autre reverse-proxy).

Quand vous scannez une image imprimée, vous avez plein d'effets de moiré désagréables à cause des interférences entre la trame d'impression et les pixels de l'écran (qui non seulement ne sont pas à la même résolution, mais on souvent des angles différents).
Il semble que les trames d'impression génèrent des pics dans les transformées de Fourrier. En lissant ces pics dans la FFT, cela supprime le moirage dans l'image d'origine.
Et ce système conserve mieux les détails que les méthodes souvent utilisées (lissage + renforcement des contours).
Pas mal du tout !

Amusant: Sur ce compte Mastodon, quelqu'un créé des phrases qui pourraient être issues d'un livre de Science-Fiction et les donne à manger à une I.A. qui "imagine" une image.
Ça donne parfois des choses étonnante, comme celui-là: « Un anneau-monde abandonné flottant dans l'espace » : https://botsin.space/@threethousanddreams/106593609165635160
Les sources sont là : https://github.com/lucidrains/big-sleep

EDIT: Voir aussi https://creator.nightcafe.studio/text-to-image-art

EDIT: Et d'autres comptes Twitter qui posent aussi ce genre d'art:
https://twitter.com/ai_curio
https://twitter.com/EErratica
https://twitter.com/unltd_dream_co
https://twitter.com/artgallerai
https://twitter.com/RiversHaveWings

Sous le coude pour lecture ultérieure.

Article technique, mais ce qu'on peut en retenir: Si vous développez une application, plutôt que d'écrire des fichiers (surtout de multiples fichiers), utilisez plutôt SQLite pour stocker les données. Les systèmes d'exploitation sont notoirement mauvais à lire/écrire un grand nombre de petits fichiers (surtout Windows !).

Avantage d'utiliser SQLite plutôt qu'un format de fichier à vous:
- accès en lecture/écriture plus rapide.
- écritures atomiques (moins de risques de corruption des données)
- possibilité de requêtage (vous pouvez demander à SQLite d'aller chercher juste les données qui vous intéressent dans le fichier. Vous n'avez pas à lire tout le fichier d'un coup)
- possibilité de modification partielle (donc plus rapide, car il n'y a pas TOUT le fichier à ré-écrire pour modifier juste une donnée)
- stockage plus efficace (le stockage de données binaires dans une base SQLite est plus efficace que de les écrire dans de multiples fichiers, à cause de la taille des blocs disque des systèmes de fichier).

Super !
... en 56 lignes de Javascript.