Une analyse technique du Registry de Windows, c'est la ou Windows range la configuration.
A priori c'est bien de la merde 😁
The major difference is that this Registry filesystem format is half-arsed. The format is badly constructed, fragile, endian-specific, underspecified and slow.
Une infographie sur toutes les marques liées à Apple, Microsoft, Amazon et Alphabet (Google)
Les 4 différentes organisations possibles avec un architecte (la dernière c'est ne pas avoir d'architecte du tout)
De mon expérience, tant que les membres de l'équipes (AKA les développeurs) sont aussi capable de faire l'architecture alors on a la meilleure configuration possible car les mêmes personnes réfléchissent aux choix architecturaux et à la manière de coder.
Il vaut toujours mieux réduire la bureaucratie et se concentrer sur ce qui apporte vraiment de la valeur au produit, c-a-d les lignes de codes produites pour réaliser une fonctionnalité.
Une plateforme en SaaS pour uniformiser la connexion à tout ce qui peut exister: serveurs, bases de données, applications, bureaux, K8S, etc.
Ça permet de centraliser les accès à tous ses services via une plateforme unique.
Ça me fait toujours un peu peur ce genre de chose qui centralise tout ce qui est sensible car du coup ça devient le SPOF de l'infrastructure.
Après je comprends le besoin aussi car des centaines d'utilisateurs qui accèdent à des dizaines de services différents c'est très compliqué à sécuriser et monitorer.
Une excellente suite d'articles sur les algorithmes génétiques.
Les algorithmes génétiques sont une famille d'algorithmes d'intelligence artificielle qui s'inspire du fonctionnement du vivant pour trouver une solution à un problème.
Individus adaptés, reproduction, mutations, c'est une reproduction de la théorie de l'évolution en informatique.
Une implémentation C++ 👉 https://github.com/Aschen/genetics-algo
J'ai eu l'occasion d'utiliser concrètement ce genre d'algorithmes pour un bot de trading, même si cela n'avait pas marché (sur-apprentissage) c'était quand même très instructif.
On commence à voir des tests des performances de Bun par rapport à Node.js.
Pour l'instant il manque encore trop de compatibilité à Bun avec les lib Node.js pour pouvoir aller très loin (pas de child_process) par exemple.
Dans cet article, l'auteur note un gain sensible de performances avec Bun.
Un autre article qui analyse les faiblesses des Hooks de React.
Une source de bug très courante est l'oubli d'une propriété dans le tableau de dépendances avec useEffect.
Le respect de la Règle des Hooks qui force le nombre de Hooks d'un composant à toujours être le même impose des architectures de composants contre nature.
L'auteur continue son raisonnement en avançant notamment que depuis les Hooks, React peut être utilisé comme un framework alors que ce n'était pas vraiment prévu, ce qui cause pleins de problèmes d'architectures.
Proposition d'un operateur pipe (|>) en Javascript.
Plutôt que d'encapsuler ou de chainer des appels à des fonctions, on pourrait utiliser l'opérateur pipe.
// Nesting
divide(half(convert('6')))
// Chaining
'6'.convert().half().divide(2)
// Pipe
6 |> convert(%) |> half(%) |> divide(%, 2)Perso je suis pas vraiment pour rajouter des couches de complexité supplémentaire à un langage qui ressemble déjà au monstre de Frankenstein.
Ça va compliqué le boulot de tout ceux qui travaillent avec l'AST et rendre le langage plus difficile à aborder pour des nouveaux venu.
Un ensemble d'outils pour PostgreSQL.
Une liste des erreurs les plus courantes lors de la mise en place de processus Agiles.
Mon top:
- Focus on output: ce qui compte c'est l'impact réalisé par les livrables et non les livrables eux-mêmes
- Agile is IT only: l'ensemble des équipes (marketing, sales, product) doivent travailler en Agile
- Implementing immutable processes and tools: la base de l'Agilité c'est justement la capacité à évoluer
Si on résume la pensée de l'article, être Agile c'est:
- Focus sur la valeur ajoutée aux clients
- Implication forte des équipes au plus prêt du produit
- Être capable de constamment remettre en question le mode de fonctionnement
Un article très (trop?) technique sur le fonctionnement des buffer TCP dans le kernel Linux.
Une alternative à ES qui est un fork de Sphinx Search.
A priori ils proposent de meilleurs performances à la recherche et à l'indexation que Elasticsearch en plus de supporter une syntax SQL.
PRO:
- meilleurs perfs de recherche et d'insertion
- support SQL (syntax et clients existants)
- 100% open source (GPLv2 + Apache 2)
- recherche temps-réel (max 1sec avec ES)
CON:
- obligé de définir le schéma à l'avance
- moins de ressources dispo car moins populaire
- robustesse du scaling à prouver
- pas complètement intégré avec les autres outils de la suite Elastic
Si vous avez besoin d'ajouter un moteur de recherche et que vous n'avez ni besoin de fonctionnalités très avancé, ni de scale à plusieurs centaines de millions de documents alors c'est une alternative à creuser.
L'article revient sur toutes les raisons qui font partir les employés d'une organisation.
Les plus importantes de mon point de vu:
- employer des managers qui ne savent pas faire de logiciels ou trop de managers
- mauvaise specification des tâches
- trop de réunions (voir manager vs maker schedule)
Plusieurs méthodes pour attaquer un fichier .zip ayant été chiffré.
Le format obsolète ZipCrypto, utilisé par Windows, est le plus vulnérable à cause d'une attaque fonctionnant même pour des mots de passes forts.
Pour un chiffrement AES classique on en revient à un crack avec John The Ripper ou Hashcat
Un article sur l'architecture hexagonale qui explique notamment la distinction entre port et adapter.
L'auteur fait aussi un commentaire intéressant I’ve never applied these architectures to the letter, though.
Comme pour tout, il faut éviter de rentrer dans une application dogmatique de tel ou tel architecture, process, etc
L'architecture hexagonale offre un excellent moyen de structurer son code en modules indépendants mais elle doit être utilisée avec un regard critique et peut être contournée lorsque cela s'avère nécessaire.
Excellent guide dont je recommande la lecture à tout développeur Node.js ;-)
Mon top:
Un article qui va dans le sens inverse de la tendance actuelle autour de l'utilisation des Hooks dans React.
L'auteur disserte sur le non respect des principes SOLID par les Hooks et sur les problèmes de dettes technique que cela créé.
Les Hooks sont vraiment quelque chose d'étrange, ils ne respectent pas la programmation fonctionnelle, ni la programmation objet.
Ce sont juste des helpers pour écrire et lire de la donnée dans une sorte de gros objet global, l'avantage avec le système de props étant qu'on n'a pas besoin de les passer entre chaque composant.
Un autre article sur la recherche de memory leak en Javascript.
L'auteur utilise une fonctionnalité non documenté de Chrome qui permet d'afficher toutes les instances d'une classe.
class User {
//...
}
const user = new User();
// find all instances of User
queryObjects(User);Ça ne marchera pas pour les POJO du coup mais c'est un bon outil supplémentaire pour aider dans la recherche des fuites mémoires.
Un bot qui s'occupe d'ouvrir des PRs pour mettre à jour les dépendances des projets. (Directement disponible sur Github)
Lorsqu'elles ne sont pas mises à jour, les dépendances font croître la dette technique.
Cela pose de potentiels problèmes de sécurité avec des failles non patché mais ça rend aussi plus complexe les mises à jour ultérieurs.
Un nouveau langage conçu pour être la relève du C++ avec une syntax proche, des performances équivalentes et surtout une compatibilité avec les libs C++ existante.
Le langage compile vers du bytecode LLVM et on profite donc de tous les outils de l'écosystème.
Encore une fois, c'est des ingénieurs de chez Google qui poussent pour un nouveau langage, c'est encore expérimental mais prometteur 👌