Andy Hazoume

Carbone Modifié T3

2026-06-05T00:00:00+00:00

Troisième et dernier tome de la trilogie de Richard Morgan, « Furies déchaînées » referme le cycle Takeshi Kovacs. Cette fois, Tak rentre chez lui : le Monde de Harlan, sa planète d’origine, là où tout a commencé pour lui.

Contrairement à mes notes sur les deux premiers tomes, je n’ai pas relevé de citations précises cette fois. Voici plutôt les éléments qui m’ont marqué.

Retour sur le Monde de Harlan

La boucle se referme : Kovacs revient sur sa planète natale, là où tout a commencé. Le décor n’est plus un terrain d’aventure parmi d’autres, c’est le sien — et ça donne au récit des airs de règlement de comptes.

Quellcrist Falconer, au cœur du récit

La figure de la révolution, jusqu’ici citée et mythifiée, prend une place centrale. Elle n’est plus seulement une voix qu’on cite avant l’assaut : elle devient un moteur de l’intrigue.

Le passé de Kovacs, avant les Diplos

Morgan creuse enfin l’homme derrière l’enveloppe. On croise des figures de son époque de Diplo, et de bien avant — de quoi comprendre ce qui a fait de lui ce qu’il est.

L’interface homme-machine

La techno qui m’a le plus titillé l’imagination : une interface homme-machine branchée en prise directe sur le cerveau. Un esprit humain connecté aux systèmes au point de brouiller la frontière entre l’opérateur et la machine. Vertigineux.

Se battre contre soi-même

Le concept le plus fort du livre : Kovacs affronte une version de lui-même. Littéralement — une copie plus jeune, d’avant sa carrière de Diplo, lancée à ses trousses. Que reste-t-il de soi quand l’adversaire, c’est exactement ce qu’on était ?

Le mystère de la technologie martienne

Le fil rouge que j’ai toujours aimé : les Martiens, race disparue, et ce qu’ils ont laissé derrière eux. Morgan résiste à tout expliquer et préfère entretenir le merveilleux. Une belle manière de refermer la trilogie.

Carbone Modifié T2

2026-04-05T00:00:00+00:00

Deuxième tome de la trilogie de Richard Morgan, “Anges déchus” nous retrouvons notre Diplo préféré, Takeshi Kovacs, dans une nouvelle enveloppe. Cette fois-ci, il est plongé en pleine guerre sur Sanction IV, une planète colonisée par les humains.

Au programme : aventure spatiale, guerre, technologies qui titillent l’imagination, sexe, romance, philosophie futuriste, et cette fois-ci les Martiens font leur entrée.

J’ai parfois été un peu perdu, avec une impression de récit bâclé à certains passages. Certaines descriptions m’ont échappé, difficiles à visualiser. Mais le livre m’a quand même tenu en haleine jusqu’au bout.

Sur le corps et la souffrance

Travailler le corps humain au point de la destruction n’est que l’une des voies vers la supériorité…

Dans un monde où on peut changer d’enveloppe, le rapport au corps devient étrange. La souffrance physique n’est plus une limite absolue.

Sur le pragmatisme

Se préoccuper du monde suivant, c’est être incapable de faire face à celui-ci de façon efficace.

Kovacs reste fidèle à lui-même : ancré dans le présent, méfiant de tout ce qui détourne de l’action immédiate.

Sur le prix à payer

Dans n’importe quel projet, politique ou autre, il y a un prix à payer. Demandez toujours quelle forme il prendra, et qui s’en acquittera. Sans cela, les planificateurs du projet sentiront votre silence comme les panthères des marais sentent l’odeur du sang. Et avant de comprendre ce qui vous arrive, la personne chargée de supporter ce coût, ce sera vous. Et vous n’en aurez sans doute pas les moyens.

Un passage qui résonne bien au-delà de la fiction.

La paix n’est jamais gratuite. On la paie forcément, à un moment ou à un autre. Par son opposé.

Sur la guerre et la politique

La guerre a un effet apaisant et simplificateur sur la politique, qui doit faire aux politiciens l’effet d’un rush de bétathanatine. On n’a plus à faire la part des choses, et on peut justifier n’importe quoi. Combattre et gagner, remporter la victoire. Tout le reste s’efface dans un grand flou blanc.

Morgan reste cynique sur la nature du pouvoir. La guerre comme drogue du politicien, où tout devient binaire et justifiable.

Sur la religion

Je croyais que c’était le principe de la religion. Simplifier pour les non-pensants.

La foi est une métaphore.

Votre monde est limité si vous n’y laissez aucune place pour le merveilleux.

Morgan continue son exploration critique de la religion, mais avec plus de nuance cette fois. La foi comme métaphore laisse entrevoir une certaine ouverture.

La religion établie a contre-attaqué. Les stratégies habituelles : incorporer les Martiens dans le grand tout, réinterpréter les écritures, voire en créer de nouvelles. Si ça ne marche pas, faute de matière grise suffisante pour réussir, tout nier en l’attribuant aux forces du mal, et brûler tous ceux qui diront le contraire. Ça devrait marcher.

Face à la découverte des Martiens, la religion s’adapte. Ou pas.

Sur les rituels

Disons que certains rituels doivent être observés si l’on veut garder une relation profitable avec le monde des esprits.

Moments de légèreté

Vous pensez que je serais lieutenant des Impacteurs de Carrera si je me vexais si facilement ?

Écoute, avec des jambes comme les miennes, n’importe qui avec un codage génétique hétéro me courrait après.

L’humour sec de Morgan parsème le récit, offrant des respirations bienvenues.

Le mantra de Quellcrist Falconer

Regardez la réalité en face. Puis agissez en conséquence. C’est le seul mantra que je connaisse, la seule doctrine que je puisse vous offrir, et c’est beaucoup plus difficile que vous le pensez. Parce que je vous jure, on dirait que les humains sont câblés pour faire n’importe quoi sauf regarder la réalité en face. Ne priez pas. N’espérez pas. Ne croyez pas aux dogmes centenaires, aux rhétoriques mortes. N’abdiquez pas en faveur de votre conditionnement, vos visions ou votre connerie de sens de… ce que vous voulez. REGARDEZ LA RÉALITÉ EN FACE. PUIS agissez.

— Quellcrist Falconer, Discours avant l’assaut sur Millsport

Ce passage condense toute la philosophie de la série. Pragmatisme brutal, méfiance des illusions, appel à l’action. Difficile de ne pas le souligner.

Carbone Modifié T1

2026-01-18T00:00:00+00:00

Carbone Modifié de Richard Morgan est un classique du cyberpunk sorti en 2002 et qui a refait surface avec la série Netflix de 2018.

Le livre explore sous la forme d’un thriller, un futur dystopique où la conscience humaine peut être numérisée et transférée d’un corps à l’autre. Je ne vais pas me pencher sur un résumé du livre ni sur son analyse, mais simplement partager les passages qui m’ont marqué dans ma lecture.

Sur la société et la religion

Qu’est-ce que la « résolution 653 » ? — Une proposition de loi en discussion à la Cour des Nations unies. Le bureau du procureur de Bay City veut assigner à comparaître une catholique en unité de stockage. Un témoin capital. Le Vatican déclare qu’elle est déjà morte et dans les mains de Dieu. Ils disent que ce serait un blasphème de la ramener.

Un des concepts les plus intéressants du livre : les catholiques refusent d’être réinstanciés dans un nouveau corps. La notion d’âme étant alors remise en question, cela crée des tensions juridiques.

Le catholicisme et la tyrannie sont bons amis. Ils sont issus de la même culture.

Morgan ne fait pas dans la nuance.

Sur les relations humaines

Après un peu moins de deux cent cinquante ans de mariage, la politesse est l’essence principale de ma relation avec Miriam.

Que devient une relation de couple quand la mort n’existe plus ?

Sur la nature humaine

Le shopping est une interaction physique, un exercice de prise de décision… un mélange entre la satiété du désir d’acquérir, l’impulsion d’acquérir de nouveau, l’envie d’explorer. Putain, c’est si humain, quand on y pense.

Je ne sais pas si c’est ironique mais ce passage m’a tellement fait sourire.

La pensée consciente n’a pas grand-chose à voir avec le désir. Si l’on en croit les psychologues, elle n’a pas grand-chose à voir avec la façon dont nous vivons notre vie, d’ailleurs. Nous rationalisons nos actes après coup, mais les maîtres, ce sont les hormones, les gènes, et les phéromones pour le réglage fin. Triste, mais vrai.

La personnalité n’est rien de plus que la forme passagère d’une des vagues devant soi… ou, pour ralentir le processus à une vitesse plus humaine, la personnalité est une dune. Une forme passagère qui répond au stimulus du vent, de la gravité, de l’éducation. De la carte des gènes. Tout est sujet à l’érosion et au changement.

Ces réflexions sur l’identité prennent une dimension particulière dans un monde où on peut changer de corps comme de chemise.

Sur la violence et le pouvoir

Mais souvenez-vous de la faiblesse des armes. Ce ne sont que des extensions. Vous êtes le tueur et le destructeur. Vous êtes complet, avec ou sans elles.

Tu veux savoir comment on fabrique un Diplo ? Je vais te l’apprendre. Ils prennent ta psyché, et ils en grillent les mécanismes de limitation de violence. Les signaux de reconnaissance de soumission, les dynamiques de hiérarchie, les loyautés au groupe. Tout ça disparaît, un neurone à la fois… pour être remplacé par une volonté consciente de faire mal.

Comme tous les hommes de pouvoir, quand il parlait de prix, vous pouviez être sûr d’une chose : c’était quelqu’un d’autre qui payait.

Autres passages

L’esprit réagit de manière créative dans les situations de stress intense.

Nos sens nous donnent l’illusion de la stabilité dans l’univers et nous l’acceptons, parce que sans cette illusion, rien ne peut être accompli.

Pourquoi cela ne me surprend-il pas ? — Peut-être parce que… — Laissez tomber. C’était une figure de style.

Ce dernier échange m’a fait sourire. Kovacs a cet humour assez sec à travers tout le roman.

Le MDM est-il mort ?

2025-11-07T00:00:00+00:00

Cat article a été écrit à 70% par un humain.

MDM = Master Data Management

Je suis récemment tombé sur ce post sur le r/dataengineering :

I have a few, potentially false beliefs about MDM. I’m being hot-takey on purpose. Would love a slap in the face.

Data Products contextualize dims/descriptive data, in the context of the product, and as such they might not need a MDM tool to master it at the full/edw/firm level

Anything with “Master blah Mgmt” […] Modern Data ecosystems overall is probably dead just out of sheer organizational malaise, politics, bureaucracy and PMO styles of trying to “get everyone on board” with such a concept, at large.

Even if you bought a tool and did MDM well — on core entities of your firm (customer, product, region, store, etc.) — I doubt IT/business leaders would dedicate the labor discipline to keeping it up. It would become a key-join nightmare at some point.

Do “MDM” at the source. E.g. all customers come from CRM. Use the account_key and be done with it. If it’s wrong in Salesforce, get them to fix it.

Il a tout de suite attiré mon attention, surtout que je baigne dans le MDM depuis quelques années déjà dans mon rôle actuel.

La discussion est centrée sur le fait que le MDM est “mort”, surtout dans un contexte de modern data stack.

Le consensus : Le MDM en tant que concept demeure essentiel, mais les implémentations traditionnelles échouent souvent à cause de facteurs organisationnels et culturels plutôt que de limitations techniques.

Ce avec quoi je suis totalement d’accord. J’ai remarqué que c’est avant tout une affaire d’hommes et de processus, plus que de technologie.

Un problème de culture et non de technologie

“It’s not about the tool, it’s about the org culture.”

Les implémentations échouent fréquemment par manque de soutien de la hiérarchie, de politiques organisationnelles adaptées et d’une incapacité à maintenir la discipline dans le temps.
Plusieurs utilisateurs ont rapporté leur expérience selon laquelle les initiatives MDM perdent souvent de leur élan après que l’excitation initiale s’est estompée.

La taille et le contexte sont importants

Les grandes entreprises sont celles qui ont le plus besoin du MDM : les entreprises du classement Fortune 500, notamment celles qui réalisent des acquisitions fréquentes, considèrent le MDM comme un avantage stratégique.
Les petites organisations n’en ont peut-être pas besoin : les structures simples, disposant d’un seul CRM ou de sources de données limitées, peuvent souvent se passer d’outils MDM dédiés.
Les industries réglementées (santé, banque, finance, assurance) requièrent le MDM pour gérer les risques et la conformité.

Les principaux problèmes que résout le MDM

Résolution d’entités : savoir si “le client X du système A” est le même que “le client Y du système B”.
Cohérence inter-domaines : garantir que les rapports de chaque département utilisent les mêmes dimensions analytiques (hiérarchies produits, géographiques, temporelles, etc.).
Intégration rapide des données de sociétés récemment acquises ou, dans mon entreprise, des données de GP (General Partner).

Le piège du “Do MDM at the Source”

Le point 4 de l’OP (juste utiliser le CRM ID comme source de vérité) simplifie grandement la réalité.
La plupart des grandes organisations ne disposent pas d’un seul système source de vérité pour leurs entités clés.

“You never have a single definition of what a customer is in a company.”

Défis de mise en œuvre

Discipline opérationnelle : les entreprises peinent souvent à dédier des ressources pour maintenir les systèmes MDM.
Dette technique : l’absence de MDM dès le départ transforme sa mise en place ultérieure en un projet de rattrapage coûteux et difficile à faire valider par la direction.
Limitations des outils clés en main : les solutions existantes (Informatica, Profisee, Reltio, Stibo) sont souvent perçues comme coûteuses, surdimensionnées, difficiles à intégrer et à maintenir.
Gestion du changement : le turnover des équipes peut poser problème ; les nouveaux collaborateurs sont rarement enclins à suivre rigoureusement des règles de gouvernance établies par leurs prédécesseurs.

Alternatives modernes et évolution des pratiques

Certaines organisations développent des solutions légères sur mesure (tables SQL, registres d’identifiants avec tables de correspondance).
Les concepts de Data Mesh contournent le MDM mais créent de nouveaux défis (comment croiser des produits de données entre domaines sans identifiant client commun ?).
Importance croissante de l’IA/ML : les LLM et couches sémantiques nécessitent des données de référence propres et cohérentes pour fonctionner efficacement.
Approches émergentes : résolution d’entités via l’analyse de graphes, algorithmes de rapprochement pilotés par l’IA.

L’absence de MDM peut avoir des coûts cachés

Sans MDM, les équipes sont souvent amenées à « réinventer la roue » à chaque nouveau projet.
Les incohérences de données sont corrigées au cas par cas, créant une charge opérationnelle continue.
Il existe un risque d’incohérences dans les indicateurs clés, les rapports aux investisseurs, les opportunités commerciales manquées, ou encore la non-conformité réglementaire.
Les migrations ERP peuvent échouer de manière catastrophique sans données de référence fiables.

Conclusion

Le MDM n’est pas mort. Comme tout concept lié à de la gouvernance il est difficile à appliquer.

Le succès de sa mise en œuvre nécessite :

L’engagement de la direction et des ressources pérennes.
De le traiter comme un programme continu, et non comme un projet ponctuel.
D’adapter l’approche à la complexité de l’organisation.
De le considérer comme une discipline de processus métier, et non simplement comme un outil technique.
De rendre les utilisateurs métier responsables de la gouvernance des données.

La vraie question n’est pas de savoir si le MDM est nécessaire, mais si les organisations ont la maturité, l’envergure et la volonté de le mettre en œuvre correctement.

Expanding a Proxmox VM Disk on Debian

2025-10-22T00:00:00+00:00

This post was generated largely by AI based on my notes.

1. Check the current layout

See how the disk and partitions are structured:

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,TYPE
sudo fdisk -l /dev/sda

If you resized the disk in Proxmox, it shows a larger size for /dev/sda but partitions still reflect the old size.

2. Fix the GPT table

gdisk corrects the GPT header so it matches the new disk size.

sudo gdisk /dev/sda

Type w and confirm with y. This writes the corrected GPT to disk.

3. Reload partition table

Tell the kernel to reload the partition layout:

sudo partx -u /dev/sda

If partx is missing, you can install util-linux or just reboot.

4. Expand the root partition

growpart automatically extends partition 1 to fill all remaining space.

sudo growpart /dev/sda 1

The output should confirm that partition 1 has grown.

5. Resize the filesystem

Extend the ext4 filesystem to fill the new partition size:

sudo resize2fs /dev/sda1

This can be done online while mounted.

6. Verify everything

Check the new size and ensure all space is available:

df -h /

You should now see your full expanded disk space in use.

To confirm integrity:

sudo gdisk -l /dev/sda && sudo e2fsck -n /dev/sda1

Both should report clean results.

The Debian root filesystem now uses the entire expanded Proxmox disk.

Gestion des conflits de dépendances avec Maven

2025-04-08T00:00:00+00:00

Lorsqu’on travaille avec des projets Java, on utilise souvent des librairies (dépendances) qui viennent avec leurs propres dépendances; c’est ce qu’on appelle des dépendances transitives. Il est très fréquent pour des librairies de dépendre de différentes versions d’une même dépendance, ce qui peut conduire à des conflits de versions. Ces conflits peuvent provoquer des erreurs à la compilation ou au runtime, rendant le diagnostic difficile. Maven fournit une stratégie claire pour résoudre ce genre de conflits.

Maven résout les conflits de dépendances en utilisant la stratégie de la définition la plus proche (aussi appelée chemin le plus court) :

La version utilisée est celle de la dépendance qui est la plus proche de la racine de l’arbre de dépendance.
Si deux dépendances en conflit sont au même niveau, la première déclarée dans le POM est utilisée.

Dans l’exemple suivant, la librairie library-A:1.0 sera utilisée car elle se retrouve au niveau 1 (directement déclarée dans le POM), même si library-B dépend d’une version plus récente.

Déclaration des dépendances :

<dependencies>
    <dependency>
        <groupId>org.example</groupId>
        <artifactId>library-A</artifactId>
        <version>1.0</version>
    </dependency>
    <dependency>
        <groupId>org.example</groupId>
        <artifactId>library-B</artifactId>
        <version>2.0</version>
    </dependency>
</dependencies>

Arbre des dépendances :

my-app
├── library-A:1.0         (depth 1)
└── library-B:2.0         (depth 1)
    └── library-A:2.0     (depth 2)

Identification des conflits

Pour identifier les conflits de dépendances, on peut examiner l’arbre de dépendances soit directement dans l’IDE ou via la commande :

mvn dependency:tree

Pour un diagnostic plus détaillé, utilisez l’option verbose :

mvn dependency:tree -Dverbose

Cette commande fournit une vue claire de l’arbre complet des dépendances, ainsi que les versions utilisées et celles qui sont omises pour cause de conflit.

Résolution des conflits avec dependencyManagement

Une bonne pratique pour résoudre les conflits de dépendances est d’utiliser le tag <dependencyManagement>. Cette section donne plus de contrôle sur les versions utilisées dans le projet sans ajouter directement les dépendances.

Par exemple ici library-A sera utilisée dans sa version 2.0 à travers tout le projet, peu importe les versions rencontrées dans les déclarations transitives :

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.example</groupId>
            <artifactId>library-A</artifactId>
            <version>2.0</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Il est important de noter que déclarer une dépendance dans <dependencyManagement> ne l’ajoute pas au projet. Il faudra toujours la déclarer dans la section <dependencies>, mais sans préciser de version :

<dependencies>
    <dependency>
        <groupId>org.example</groupId>
        <artifactId>library-A</artifactId>
        <!-- Pas besoin de spécifier la version ici -->
    </dependency>
</dependencies>

Utilisation des exclusions

Parfois, vous pourriez avoir besoin d’exclure explicitement une dépendance transitive. Par exemple, si library-B dépend d’une version de library-A qui n’est pas compatible avec votre code :

<dependency>
    <groupId>org.example</groupId>
    <artifactId>library-B</artifactId>
    <version>2.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.example</groupId>
            <artifactId>library-A</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Cas pratiques

Les conflits de dépendances ne sont pas forcément à résoudre. Le projet peut compiler et fonctionner comme il se doit avec des conflits de dépendances que Maven gère selon les règles mentionnées plus haut. Toutefois pour des soucis de cohérence il faut parfois s’assurer d’utiliser la bonne version.

Par exemple, dans un projet Spring, on peut rencontrer différentes versions de spring-core (par transitivité). Il est recommandé d’utiliser <dependencyManagement> afin de s’assurer d’utiliser une même version à travers tous les composants Spring.

On peut aussi rencontrer des problèmes lorsqu’une nouvelle version d’une librairie apporte des changements non compatibles avec des versions antérieures. Dans ce cas il faut :

identifier les dépendances utilisant la nouvelle version
mettre à jour le code avec la nouvelle API
ou utiliser les exclusions et dépendre explicitement de l’ancienne librairie

Outils supplémentaires

Pour une analyse plus poussée de vos dépendances, utilisez la commande :

mvn dependency:analyze

Cette commande identifie les dépendances utilisées mais non déclarées, ainsi que celles déclarées mais non utilisées, ce qui vous aide à optimiser votre POM.

Utilisation des BOM (Bill of Materials)

Pour les projets complexes, l’utilisation d’un BOM peut grandement simplifier la gestion des versions :

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.7.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Cela importe toutes les versions de dépendances compatibles définies par Spring Boot, évitant ainsi de nombreux conflits potentiels.

La Règle des 37%

2025-03-17T00:00:00+00:00

La règle des 37% trouve son origine dans le “problème du secrétaire”, un classique de la théorie d’arrêt optimal. Dans ce problème, un recruteur doit embaucher un secrétaire parmi un nombre fini de candidats qu’il rencontre un par un. Après chaque entretien, il doit décider immédiatement : embaucher ce candidat ou passer au suivant, sans possibilité de rappel.

Le défi est que le recruteur ne peut pas attribuer une note absolue aux candidats, seulement les comparer entre eux. La question devient donc : quelle stratégie adopter pour maximiser les chances de sélectionner le meilleur candidat?

La stratégie optimale, démontrée mathématiquement, consiste à:

Observer (sans choisir) les 37% premiers candidats
Identifier le meilleur candidat de ce groupe initial
Ensuite, sélectionner le premier candidat qui surpasse cette référence

Le chiffre 37% correspond plus précisément à 1/e, où e est le nombre d’Euler (≈ 2,718). Cette formule garantit une probabilité de 37% de sélectionner le meilleur candidat possible - ce qui est le maximum atteignable dans ce contexte.

Cette règle s’applique à diverses situations impliquant des choix séquentiels: recherche immobilière (explorer 37% des options disponibles avant de prendre une décision), recrutement (évaluer 37% des candidatures avant de commencer à embaucher), ou rencontres (consacrer 37% du temps disponible à explorer avant de s’engager).

La règle fonctionne de manière optimale lorsque le nombre total d’options est connu à l’avance, les décisions sont irréversibles, et l’objectif est uniquement de trouver la meilleure option.

J’ai découvert cette règle dans le livre Algorithms to Live By. Elle offre un cadre structuré pour aborder les décisions séquentielles et éviter deux erreurs communes: choisir trop tôt par impatience ou trop tard par perfectionnisme.

Le chiffre 37% constitue donc un point de référence précis et efficace pour les situations de choix séquentiels où l’on ne peut pas revenir en arrière.

Creating SSL Certificate in Nginx Proxy Manager

2025-02-17T00:00:00+00:00

If you self-hosted and/or have a homelab, you’ll need to expose some services to the Internet. This guide provides step-by-step instructions for creating SSL certificates for your services in Nginx Proxy Manager (NPM). We’ll use Let’s Encrypt as the certificate authority and Cloudflare’s DNS validation method.

Prerequisites

Nginx Proxy Manager installed and running
A domain managed through Cloudflare
Access to your Cloudflare admin dashboard
DNS records properly set up in Cloudflare

Getting the Cloudflare API Token

First, create an API token that NPM will use to validate your domain ownership. From your Cloudflare dashboard:

Navigate to API Tokens in the menu
Click Create Token
Select Custom Token
Configure these settings:
- Name: “MyHomeLab-ApiToken” (or any descriptive name)
- Permissions: Zone → DNS → Edit
- Zone Resources: Your specific domain(s)
Create and copy your token

Setting Up the Certificate in NPM

Now let’s create the SSL certificate in Nginx Proxy Manager:

Go to your NPM dashboard
Navigate to SSL Certificates
Click Add SSL Certificate
Configure the certificate:

Domain Settings

Primary domain: example.com
Wildcard domain: *.example.com

DNS Challenge Configuration

Check “Use a DNS Challenge”
DNS Provider: Cloudflare
API Token: Paste your Cloudflare token
Propagation Time: 120 seconds

Click Save and NPM will:

Verify your domain through Cloudflare
Generate the SSL certificate
Set up automatic renewal

Security Tips

A few important security notes:

Limit the API token to only the domains you need
Keep your API token secure
Check certificate renewal status periodically
Review NPM logs for any certificate issues

Terror in Resonance

2025-01-30T00:00:00+00:00

Terror in Resonance est une série d’animation japonaise de 11 épisodes produite par le studio MAPPA en 2014. L’histoire nous plonge dans un Japon contemporain, marqué par les séquelles de la Seconde Guerre mondiale.

Au cœur de l’intrigue se trouve un programme gouvernemental secret visant à améliorer artificiellement l’intelligence humaine. Pour mener à bien cette expérience, une vingtaine d’enfants de moins de 5 ans ont été enlevés. Suite à un mystérieux accident, le programme a brutalement pris fin, laissant derrière lui de nombreuses zones d’ombre.

Des années plus tard, deux survivants de ce programme, connus uniquement sous les numéros 9 et 12, réapparaissent à Tokyo. Sous le pseudonyme de Sphinx, ils orchestrent une série d’attentats dans la capitale japonaise. Fait notable, leurs actions terroristes se distinguent par une caractéristique surprenante : elles ne font pratiquement aucune victime. Au fil des épisodes, on découvre que leur véritable objectif est de révéler au grand jour l’existence de ce programme qui a façonné leur destin.

Un personnage particulièrement marquant de la série est le détective Shibazaki. Son investigation est rythmée par les énigmes laissées par Sphinx, créant un jeu du chat et de la souris intellectuel qui ajoute une dimension supplémentaire à l’intrigue.

Le scénario, bien que comportant quelques incohérences dans sa construction, parvient à maintenir l’intérêt du spectateur tout au long des 11 épisodes grâce à ses mystères et ses rebondissements.

Monday Mornings Haïku

2023-11-28T00:00:00+00:00

Monday mornings suck

those grumpy faces can tell

blaming you for it

Late Night Haïku

2023-11-22T00:00:00+00:00

3 am in my bed

my eyes are still wide opened

with thrillers in my head.

Context Switching and Task Interruptions

2022-05-08T00:00:00+00:00

As a professional developer, I often get some deeply focused sessions of work, especially when I’m programming. One thing I’ve noticed is the difficulty to resume after I get interrupted from those sessions. My role also requires me to be involved in more than one project, thus jumping from one task to another not necessarily related. It’s hard, without a strategy to quickly get back into an interrupted work in progress.

This difficulty has been studied and explained by cognitive scientists and psychologists. It’s called context switching. In this post I share their findings and my comprehension of the subject and give some strategies to reduce the impact of the inevitable.

Computers vs Humans

It all started with the word multitask, invented by IBM in 1985 to describe a computer capability.

A multitask operating system is designed to work on multiple tasks but not at the same time. It works briefly on the first task, then saves the system state for that task. The interrupted task moves to the end of the queue and the system switches to the next task until all the assigned tasks are considered done. This operation is so fast that we have the impression that all the tasks are executed at the same time. The process of storing the state in order to pause the task and resume another is called context switch. A context switch can also occur as the result of an interrupt.

We can find similarities between how computers multitask and how humans “multitask”. For humans, multitasking means trying to perform two or more tasks concurrently, which typically leads to repeatedly switching between tasks (i.e., task switching) or leaving one task unfinished in order to do another.

What is Context Switching ?

Context switching, also called task switching, is to jump from one task to another unrelated task, causing a mental shift resetting the working memory. Context switching is a consequence of multitasking.

It happens when for example you’re writing an email to explain an issue and get interrupted for a support task by instant messaging. Or when you’re writing technical documentation and paused for a code review.

What causes Context Switching?

Context switching can be caused by something as simple as self interruptions (not motivated to pursue the task on hand, boredom, need to take a break etc.). Other triggers are external events like a shoulder tap, a question from a colleague or a simple disruption like a notification.

For developers, it can be a pull request which interrupts a programming task or multiple upcoming unrelated meetings. Unforeseen events related to ongoing projects can also be sources of context switching (changes in a task priority, blockages due to unavailable resources etc.).

And last but not least, there’s the myth that multitasking makes us overachievers, efficient and high performers. Our contemporary work culture values and rewards multi-taskers and responsiveness and our digital tools don’t help.

No wonder that at the end of the day most of us feel exhausted and drained.

The Cost of Context Switching

As you may have guessed, context switching has a cost (as for computers). We may think that we’re getting more done by accepting more and more tasks and by switching between them but it’s counterproductive. The American Psychological Association (APA) found in a study that it leads to a 40% decrease of an employee’s productive time.

Context switching impacts our mental energy, our brain and even our memory. Even your IQ can be impacted. A study by the University of London found a decrease in IQ for participants who multitasked during complex cognitive tasks.

Another study conducted by Gloria Mark, a Professor from University of California Irvine found that it takes up to 23 minutes to refocus our effort after just one interruption. This leads to more stress, working faster to get more done, thus makes us superficial thinkers.

To study the effects on developers in more detail, Chris Parnin and his colleagues made an exploratory analysis of 10000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio, and a survey of 414 programmers. They found that a programmer takes between 10-15 minutes to start editing code after resuming work from an interruption. It’s less than the 23 minutes mentioned earlier but no less important. Also, when interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute. And finally, developers only get one uninterrupted 2-hours session per day.

It seems context switching cannot be totally avoided. Especially in modern software development, when you’re part of a team and involved in agile projects. But how can we manage to reduce its impact?

How to reduce the Impact of Context Switching?

On the developer’s desk, there are a few things to do in order to reduce context switching. It’s important to have a “where was I?” strategy in case of interruptions. What I found helpful is to quickly jot down keywords linked to the context of the interrupted task. It reduces the load on my working memory and the time it takes to resume the task. It’s also good to adopt best practices in development like clean code (clearly named variables, methods, classes, well organised code, etc.). That way, the code itself can help resume the programming session.

Some IDEs like Eclipse have a set of tools to improve resumption of development tasks.One of those plugins is Mylyn. It integrates various task trackers such as Bugzilla, Mantis, JIRA.

When you mark that you are working on a given task, Mylyn activates the context including the various files opened during analysis and development.

On a more macro level, it’s important to work on how your day is scheduled. For example, you can batch together linked tasks, meetings. Our common advice is also to schedule the more important tasks first in the morning or at the end of the day. The thing here is to have a dedicated, not interruptible period of time. It’s also important to learn how to prioritise. You can ask your manager for help if needed.

If your role requires responsiveness, you need to figure out what level of responsiveness you need to provide. You can also adopt asynchronous communication. When balanced with synchronous communication, It can improve the developing experience and leads to more quality responses.

Conclusion

In this post I’ve tried to give more insights on context switching and task interruptions and how they impact knowledge workers, especially developers. Psychologists have studied context switching, and found it can negatively impact our productivity and also our mental health in many ways… However it’s important to note that not all interruptions are a big loss. Switching tasks is unavoidable and sometimes can even increase developers productivity in some cases. In fact it all depends on the context in which it occurs. If a colleague working on the same project as you interrupts to exchange ideas about the task at hand this can be a productive interruption.

Handling API access token refresh with Caffeine

2022-01-04T00:00:00+00:00

There are numerous resources on the Web on how to handle external API access tokens. One thing they have in common is the best practice that consists in storing the token internally in order to avoid unnecessary refreshes. I was recently confronted with this at work.

Our application needed to make authenticated requests to an external Web API. At first we implemented our client to make a call to the authorization server to retrieve the access token before performing the actual request. We were making unnecessary calls to the auth server. We eventually got a call from the team in charge of the saas, with a suggestion to limit those calls.

We decided to use a cache system to store the access token until it expires.

We chose caffeine, “a high performance, near optimal caching library”. Caffeine is for Java applications and is well integrated with popular frameworks like Spring, Apache Camel or Quarkus …

Caffeine can be added via Maven :

<dependencies>
    <!-- https://mvnrepository.com/artifact/com.github.ben-manes.caffeine/caffeine -->
    <dependency>
        <groupId>com.github.ben-manes.caffeine</groupId>
        <artifactId>caffeine</artifactId>
        <version>2.9.2</version>
    </dependency>
</dependencies>

Then we simply had to write an access token handler :

public class AccessTokenHandler {

	private LoadingCache<String, Object> cache;

	private static AccessTokenHandler instance;

	private AccessTokenHandler() {
		cache = Caffeine.newBuilder()
				.maximumSize(1)
				.expireAfterWrite(Duration.ofMinutes(59))
				.build(key -> requestAccessToken());
	}
	
	public static synchronized AccessTokenHandler getInstance() {
		if (instance == null) {
			instance = new AccessTokenHandler();
		}
		return instance;
	}

	public String getAccessToken() {
		return (String) cache.get("external-api-access-token");
	}

	private String requestAccessToken() {
		//TODO Retrieve access token from Auth server	
	}
}

AccessTokenHandler is a Singleton providing a single access to the token cache.

In the private constructor we build a LoadingCache with a maximumSize of 1, which expires 59 minutes after write. The requestAccessToken() Function is used to refresh the access token from auth server.

AccessTokenHandler provides a getAccessToken()method to retrieve the cached access token value. The cache is then used as the main facade and we only call the authentication server after the access token is expired.

Swagger Codegen

2021-09-10T00:00:00+00:00

Récemment au travail, nous avions eu besoin de connecter à l’API REST d’un SAAS, le progiciel autour duquel nous effectuons nos développements. La documentation de l’API nous a été fournie sous forme de spécification Swagger. Nos développements se faisant essentiellement en Java, nous avons donc besoin d’implémenter un client d’API REST en Java. La méthode naïve aurait été de partir du Swagger et de tout construire manuellement à partir de la description des modèles, des opérations etc. mais la tâche me semblait plutôt fastidieuse.

Après quelques recherches, j’ai découvert Swagger Codegen. Il s’agit d’un utilitaire qui permet la génération automatique de clients d’API REST, de stubs de serveurs et de documentation, et ce à partir d’une spécification OpenAPI. Plusieurs langages et frameworks sont supportés dont Java.

Swagger Codegen est téléchargeable sous forme de fichier .jar et peut se lancer en ligne de commande avec un java -jar :

java -jar swagger-codegen-cli-2.2.1.jar generate -i specification-api-swagger.json -l java rest-client/

La spécification de l’API avec laquelle on doit communique est sous forme de fichier .json qu’on peut télécharger depuis la page HTML de la documentation Swagger. Elle est passée à la commande avec l’argument -i. -l est utilisé pour spécifier le langage dans lequel l’on souhaite générer le code pour notre client REST.

Et voilà! Swagger Codegen nous génère un projet Java Maven bien structurée avec les POJO représentant le modèle de donnée, les utilitaires pour effecturer les appels d’API, la gestion de l’authentification et même la document Javadoc, … Ce projet peut désormais servir de base pour démarrer l’implémentation de notre client REST et permettre d’aller plus vite.

Pour plus d’infos : https://swagger.io/docs/open-source-tools/swagger-codegen/

First post

2020-08-28T00:00:00+00:00

Lorem ipsum dolor amet tousled viral art party blue bottle single-origin coffee cardigan, selvage man braid helvetica. Banh mi taxidermy meditation microdosing. Selvage cornhole YOLO, small batch vexillologist raclette VHS prism sustainable 8-bit ugh semiotics letterpress disrupt pop-up. Celiac shabby chic ugh, jianbing whatever kitsch tattooed edison bulb kogi irony etsy.

Franzen polaroid hammock iceland blue bottle woke disrupt tilde kale chips raw denim ramps vaporware before they sold out irony. Narwhal vaporware offal shaman celiac kinfolk activated charcoal salvia lomo irony readymade normcore. Yr activated charcoal kombucha, man braid whatever biodiesel hella crucifix adaptogen bicycle rights small batch skateboard mixtape. Hot chicken sustainable green juice 90’s. Ennui kickstarter hella pug, meggings man bun shaman messenger bag. Chambray adaptogen kombucha pug affogato, kogi green juice distillery ugh banh mi.

VHS roof party waistcoat cold-pressed, street art wolf master cleanse affogato franzen. Shaman iceland pour-over intelligentsia typewriter tilde, pitchfork copper mug. Wayfarers kickstarter adaptogen vinyl beard kombucha. Organic pinterest master cleanse, mixtape fam gentrify lo-fi kogi.

Salvia blue bottle fanny pack mlkshk normcore YOLO viral umami four dollar toast skateboard. Chambray taxidermy slow-carb street art chartreuse. Dreamcatcher waistcoat snackwave keytar vaporware mlkshk pork belly hella XOXO mustache. Tattooed semiotics edison bulb, disrupt polaroid craft beer vape enamel pin bespoke flannel letterpress brooklyn subway tile copper mug. Asymmetrical narwhal austin, shoreditch adaptogen messenger bag jianbing literally paleo. Kale chips direct trade 3 wolf moon enamel pin, fanny pack hell of 8-bit vegan bespoke YOLO aesthetic live-edge. Retro succulents before they sold out whatever bushwick.

Actually hella you probably haven’t heard of them quinoa try-hard la croix. Street art schlitz actually hell of pour-over air plant. Post-ironic franzen brunch mumblecore readymade. Food truck photo booth polaroid, gochujang vegan street art yr before they sold out man bun. Tilde selfies chia pitchfork everyday carry post-ironic mumblecore sartorial VHS master cleanse activated charcoal biodiesel williamsburg cronut jean shorts. Poutine helvetica keffiyeh butcher pop-up.