<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Development on Le Blog d'Arhuman</title><link>https://blog.assad.fr/tags/software-development/</link><description>Recent content in Software Development on Le Blog d'Arhuman</description><generator>Hugo</generator><language>fr-fr</language><lastBuildDate>Mon, 30 Mar 2026 15:24:26 +0100</lastBuildDate><atom:link href="https://blog.assad.fr/tags/software-development/index.xml" rel="self" type="application/rss+xml"/><item><title>Pourquoi je code en Go de cette manière en 2026</title><link>https://blog.assad.fr/post/why-i-code-go-this-way-2026/</link><pubDate>Mon, 30 Mar 2026 15:24:26 +0100</pubDate><guid>https://blog.assad.fr/post/why-i-code-go-this-way-2026/</guid><description>&lt;h2 id="pourquoi-écrire-encore-sur-le-layout-et-les-pratiques-go-en-2026-"&gt;Pourquoi écrire encore sur le layout et les pratiques Go en 2026 ?&lt;/h2&gt;
&lt;p&gt;En 2018, Mat Ryer écrivait un article de référence &lt;a href="https://pace.dev/blog/2018/05/09/how-I-write-http-services-after-eight-years.html"&gt;How I write HTTP services after 8 years&lt;/a&gt; qu’il a mis à jour quelques années plus tard : &lt;a href="https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/"&gt;&amp;ldquo;How I write HTTP services in Go after 13 years&amp;rdquo;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;En 2019, je présentais déjà ma manière de coder en Go dans plusieurs &lt;a href="https://blog.assad.fr/slides/talk-how_I_code_in_go"&gt;présentations d’introduction au langage&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Ce texte est une version révisée de cette présentation, nourrie par mon expérience et mes contraintes en 2026.&lt;/p&gt;</description></item><item><title>Et si votre OOM n’était pas qu’un problème de mémoire ?</title><link>https://blog.assad.fr/post/what-if-oom-is-not-only-about-memory/</link><pubDate>Fri, 20 Mar 2026 15:24:26 +0100</pubDate><guid>https://blog.assad.fr/post/what-if-oom-is-not-only-about-memory/</guid><description>&lt;p&gt;Parfois, une investigation raconte une autre histoire que celle que vous attendez.&lt;/p&gt;
&lt;p&gt;C’est ce qui m’est arrivé récemment en cherchant pourquoi un pod finissait en OOMKilled deux à trois fois par jour.&lt;/p&gt;
&lt;p&gt;Une rapide observation de la mémoire du pod incriminé ne montre pas la courbe croissante typique d’un memory leak. Je manque de données juste avant le OOM (parce que c’est toujours quand votre système de métriques est en train de migrer que ce type d’incident se produit) mais avec les données de la journée, la cause semble se trouver ailleurs.&lt;/p&gt;</description></item><item><title>Et si votre dette technique n’était pas un problème technique ?</title><link>https://blog.assad.fr/post/what-if-tech-is-not-the-answer/</link><pubDate>Sun, 15 Mar 2026 11:05:26 +0100</pubDate><guid>https://blog.assad.fr/post/what-if-tech-is-not-the-answer/</guid><description>&lt;p&gt;Alors que les méthodes se font toujours plus nombreuses, les livres toujours plus prescriptifs, les outils toujours plus performants, la démarche toujours plus industrielle, l’industrie du logiciel continue à produire autant de dette, de retard et de bugs qu’auparavant.&lt;br&gt;
C’est un secret de polichinelle et pourtant rien ne change. Pourquoi ?&lt;br&gt;
Peut-être est-il temps de chercher la cause là où trop peu regardent.&lt;/p&gt;
&lt;p&gt;Laissez-moi vous raconter une histoire.&lt;/p&gt;
&lt;p&gt;Imaginez, vous êtes embauché en tant que chef de projet informatique, dans une startup où le développement est complètement stoppé :&lt;/p&gt;</description></item></channel></rss>