Une alternative aux appli Web classiques qui sont entièrement en Javascript et reçoivent du JSON.

Ici le concept c'est plutôt d'envoyer du html pour remplacer à la volée certaines parties de la page.

Du coup le rendu se fait côté serveur et le frontend est beaucoup moins complexe.

C'est Basecamp qui pousse ça (la boîte à l'origine de Ruby on Rails)

Une infographie sur toutes les marques liées à Apple, Microsoft, Amazon et Alphabet (Google)

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.

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.

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

Tous les patterns de destructuration d'objets en Javascript

Un de ceux que je trouve le plus utile c'est celui pour avoir une valeur par défaut si la propriété n'existe pas.
C'est très utile pour les options par défaut:

function checkout (name, { currency='€' } = {}) {
  console.log(currency);
}

checkout('aschen'); // print €
checkout('aschen', { currency: '$' }); // print $

On peut même mixer ça avec un type:

function checkout (name, { currency='€' }: { currency: string } = {}) {
  console.log(currency);
}

Sinon j'avais jamais utilisé celui pour conserver le reste:

const user = {
  name: 'Chris',
  age: 33,
  username: 'DailyDevTips',
};

const { name, ...rest } = user;

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.

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.

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.

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.

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é.

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 ensemble d'outils pour PostgreSQL.

Un article très (trop?) technique sur le fonctionnement des buffer TCP dans le kernel Linux.