<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>points de vue d&#39;un codeur</title>
    <link>https://www.moquillon.fr/</link>
    <description>Recent content on points de vue d&#39;un codeur</description>
    <generator>Hugo</generator>
    <language>fr-FR</language>
    <lastBuildDate>Wed, 04 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.moquillon.fr/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>L&#39;enfer des dépendances</title>
      <link>https://www.moquillon.fr/post/enfer_des_dependances/</link>
      <pubDate>Wed, 04 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/enfer_des_dependances/</guid>
      <description>Qui ne s&amp;rsquo;est pas retrouvé à s&amp;rsquo;arracher les cheveux à devoir gérer un enchevêtrement de dépendances d&amp;rsquo;un projet logiciel ? Le pire sont celles transitives pour lesquelles différentes versions peuvent coexister. Avec le temps, et la vie de l&amp;rsquo;application, avec la montée en version des bibliothèques tierces, gérer les potentielles régressions peuvent devenir un calvaire.</description>
    </item>
    <item>
      <title>Sortir de l&#39;orthodoxie en programmation Web (et de micro-services)</title>
      <link>https://www.moquillon.fr/post/orhodoxie_en_programmation_web/</link>
      <pubDate>Fri, 27 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/orhodoxie_en_programmation_web/</guid>
      <description>L&amp;rsquo;orthodoxie en vigueur dans la conception d&amp;rsquo;applications Web et de micro-services applique un schéma qui s&amp;rsquo;apparente plutôt à une approche procédurale, bien que s&amp;rsquo;appuyant sur des techniques et des languages dits orientés objets. Je vous propose une autre voie, plus orientée objet, dans laquelle les relations entre services et objets métiers sont inversés.</description>
    </item>
    <item>
      <title>Les mots ont leur importance</title>
      <link>https://www.moquillon.fr/post/importance_des_mots/</link>
      <pubDate>Sat, 30 Nov 2024 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/importance_des_mots/</guid>
      <description>Il y a plusieurs années de ça, dans le cadre d&amp;rsquo;un projet de restructuration d&amp;rsquo;un programme, initialement conçu selon une approche procédurale multi-couches encore en vigueur dans les années 2000, vers une conception plus orientée objet, un des développeurs a lancé, sur le renommage des &lt;code&gt;DAO&lt;/code&gt; en &lt;code&gt;Repository&lt;/code&gt;, que ce ne sont que des mots qui désignent la même chose. Récemment, dans un tout autre contexte, j&amp;rsquo;ai reçu une reflexion similaire sur la dénomination de classes d&amp;rsquo;objet dont les noms étaient soit technique, soit généraliste (du genre &lt;code&gt;FooService&lt;/code&gt; ou &lt;code&gt;FooManager&lt;/code&gt;).</description>
    </item>
    <item>
      <title>L&#39;extensibilité dans différents langages</title>
      <link>https://www.moquillon.fr/post/extensibilite_langages/</link>
      <pubDate>Fri, 27 Apr 2018 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/extensibilite_langages/</guid>
      <description>Il arrive fréquemment qu&amp;rsquo;avec l&amp;rsquo;évolution des besoins dans le temps, les objets métiers qui ont été définis auparavant nécessitent d&amp;rsquo;être étendus par l&amp;rsquo;ajout de nouvelles fonctionnalités. Selon la nature des langages de programmation, mais aussi selon les caractéristiques propres aux langages, les méthodes d&amp;rsquo;extension varient et peuvent être plus ou moins aisées à mettre en œuvre, en particulier lorsque les extensions sont fournies dans des modules (paquetages, bibliothèques, &amp;hellip;) à part et que l&amp;rsquo;existant ne doit pas être impacté par ces ajouts (ou du moins le minimum possible).</description>
    </item>
    <item>
      <title>Foncteurs, Foncteurs Applicatifs et Monades</title>
      <link>https://www.moquillon.fr/post/functor_applicative_monad/</link>
      <pubDate>Sun, 21 Jan 2018 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/functor_applicative_monad/</guid>
      <description>Dans ce premier billet de l&amp;rsquo;année 2018, je vais m&amp;rsquo;essayer de vous présenter ce que sont les foncteurs, les foncteurs applicatifs et les monades de façon simple, sans étalage de la théorie mathématique derrière (celle des catégories) dont, de toute manière, je ne maîtrise pas. Bien que ce soient des constructions utilisées dans la programmation fonctionnelle, elles peuvent aussi être utilisées dans d&amp;rsquo;autres approches de programmation et avec d&amp;rsquo;autres langages que ceux fonctionnels. C&amp;rsquo;est pourquoi je présenterai chacun des concepts non seulement avec du code en Haskell mais aussi en Java.</description>
    </item>
    <item>
      <title>Exemple d&#39;immutabilité en Java</title>
      <link>https://www.moquillon.fr/post/immutabilite_java/</link>
      <pubDate>Sat, 11 Mar 2017 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/immutabilite_java/</guid>
      <description>Dans un billet précédent sur l&amp;rsquo;égalité d&amp;rsquo;identité et celle de valeurs, je vous ai parlé d&amp;rsquo;objets immutables pour lesquels l&amp;rsquo;égalité de valeur et l&amp;rsquo;égalité d&amp;rsquo;identité se confondent. J&amp;rsquo;ai souvent vu dans divers blogues sur l&amp;rsquo;immutabilité en Java l&amp;rsquo;utilisation du mot clé &lt;code&gt;final&lt;/code&gt;. J&amp;rsquo;ai toujours trouvé son usage pour réaliser l&amp;rsquo;immutabilité comme absurde et surtout par trop contraignant. Pour moi, il ne sert à rien de qualifier les propriétés des objets comme des constantes étant donné que celles-ci doivent être encapsulées selon les principes de la programmation orienté objet. Non, l&amp;rsquo;immutabilité des objets devrait au contraire se faire au niveau du comportement et surtout des mutateurs de ces objets.</description>
    </item>
    <item>
      <title>Une histoire d&#39;objets obèses</title>
      <link>https://www.moquillon.fr/post/histoire_objets_obeses/</link>
      <pubDate>Mon, 06 Mar 2017 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/histoire_objets_obeses/</guid>
      <description>Il arrive dans un projet en Java de se trouver, selon le métier ou le domaine adressé, avec des classes d&amp;rsquo;objets obèses en méthodes, qu&amp;rsquo;elles soient publics ou propres aux objets de la classe. Or, sachant que l&amp;rsquo;on passe plus de temps à lire, voir à toucher du code existant qu&amp;rsquo;à en écrire de nouveaux, ceci peut vite devenir pénible. Evidemment, avec nos IDE actuels, il est facile de naviguer entre les différentes méthodes et propriétés d&amp;rsquo;une classe. Mais en général, ceci signifie que l&amp;rsquo;on sait, déjà, à peu près ce que l&amp;rsquo;on cherche ou que l&amp;rsquo;on connait a minima les responsabilités ou certaines particularités d&amp;rsquo;implémentation de la classe.</description>
    </item>
    <item>
      <title>L&#39;égalité d&#39;identité et l&#39;égalité de valeur en Java</title>
      <link>https://www.moquillon.fr/post/egalite_id_vs_valeur/</link>
      <pubDate>Tue, 29 Nov 2016 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/egalite_id_vs_valeur/</guid>
      <description>Dans certains langages de programmation, comme Java, il n&amp;rsquo;y a pas de méthodes ou d&amp;rsquo;opérateurs distincts pour différencier l&amp;rsquo;égalité d&amp;rsquo;identité et celle de valeur des objets. Si, dans un programme classique écrit dans un langage comme Java, l&amp;rsquo;égalité d&amp;rsquo;identité (de l&amp;rsquo;OID pour Object IDentifier) pourrait se faire avec l&amp;rsquo;opérateur &lt;code&gt;==&lt;/code&gt; et celle de valeur avec la méthode &lt;code&gt;equals&lt;/code&gt; surchargée, il n&amp;rsquo;en va plus de même dès qu&amp;rsquo;il s&amp;rsquo;agit d&amp;rsquo;objets persistés. Et là, in fine, c&amp;rsquo;est le drame : que compare t&amp;rsquo;on avec la méthode &lt;code&gt;equals&lt;/code&gt; ? la valeur des objets ou leur identité ?</description>
    </item>
    <item>
      <title>L&#39;architecture Micro-Services et le paradigme Orienté Objet</title>
      <link>https://www.moquillon.fr/post/micro-services_et_poo/</link>
      <pubDate>Sat, 21 Nov 2015 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/micro-services_et_poo/</guid>
      <description>J&amp;rsquo;aime à dire que l&amp;rsquo;évolution en informatique ne connait que très peu de ruptures et ressemble à une grande spirale dans laquelle les nouvelles technologies et approches ne sont que des reprises de plus anciennes que l&amp;rsquo;on a dépoussiéré et adapté aux attentes et au temps actuel ; c&amp;rsquo;est ce qui est appelé &lt;em&gt;innovation&lt;/em&gt;. Les micro-services, le grand buzz de l&amp;rsquo;année 2015, n&amp;rsquo;échappent pas à cette règle. (On est friand aussi de buzz en informatique). Mais qu&amp;rsquo;est-ce que les micro-services ? En fait, rien de spécial. Ce n&amp;rsquo;est ni plus ni moins que le découpage des responsabilités des applications dans des services dédiés, sur un socle HTTP, et qui communiquent entre eux par messages. Du SOA ? Du REST ? &amp;hellip; Oui, tout ça, mais ce n&amp;rsquo;est plus à la mode, il faut parler maintenant de micro-services.</description>
    </item>
    <item>
      <title>PJLRenseignement ... Ô rage ! Ô désespoir !</title>
      <link>https://www.moquillon.fr/post/jplrenseignement/</link>
      <pubDate>Tue, 05 May 2015 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/jplrenseignement/</guid>
      <description>Aujourd&amp;rsquo;hui, je hurle de rage ! La Loi sur le Renseignement, comme pressentie, a été adoptée à l&amp;rsquo;Assemblée Nationale aujourd&amp;rsquo;hui, le 5 mars 2015 et ceci malgré l&amp;rsquo;opposition vive de la société civile. C&amp;rsquo;est une loi liberticide qui a été voté. Elle oblige l&amp;rsquo;écoute de toutes données qui transitent dans le réseau internet et téléphonique par des boites noires, et elle autorise aux forces de police l&amp;rsquo;accès à celles-ci sans aucun contrôle judiciaire.</description>
    </item>
    <item>
      <title>Un petit voyage dans DragonFly BSD</title>
      <link>https://www.moquillon.fr/post/voyage_dragonflybsd/</link>
      <pubDate>Tue, 04 Mar 2014 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/voyage_dragonflybsd/</guid>
      <description>DragonFly BSD est le dernier rejeton de la famille des Unix BSD libres. Il est issu du désaccord de Matthew Dillon sur les choix d&amp;rsquo;architecture SMP de FreeBSD 5 en vue de supprimer le Giant Lock. Créé en 2003 à partir de FreeBSD 4.8 pour initialement proposer une autre implémentation du multi-threading (multiflot en français), plus originale, il devient l&amp;rsquo;opportunité, pour l&amp;rsquo;équipe de DragonFly BSD, d&amp;rsquo;emprunter des directions différentes, voir innovantes, de celles des autres systèmes Unix.</description>
    </item>
    <item>
      <title>Une histoire de slots</title>
      <link>https://www.moquillon.fr/post/une_histoire_de_slots/</link>
      <pubDate>Tue, 04 Mar 2014 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/une_histoire_de_slots/</guid>
      <description>L&amp;rsquo;amélioration de la structuration du code d&amp;rsquo;un programme, la séparation du métier et des concepts manipulés d&amp;rsquo;avec les aspects techniques, est le Saint Graal que poursuivent sans fin les développeurs. Dans ce but, de nombreuses techniques ont fait leur apparition dont nous pouvons citer les &lt;em&gt;traits&lt;/em&gt; ou les &lt;em&gt;annotations&lt;/em&gt;. A côté de ceux-ci, il existe une technique élégante et uniforme que sont les &lt;em&gt;slots&lt;/em&gt;. Mais, que sont ces derniers et en quoi peuvent ils nous aider dans notre quête ?</description>
    </item>
    <item>
      <title>La programmation entre science et art</title>
      <link>https://www.moquillon.fr/post/programmation_entre_science_et_art/</link>
      <pubDate>Sat, 10 Aug 2013 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/programmation_entre_science_et_art/</guid>
      <description>Actuellement, la programmation relève de l&amp;rsquo;ingénierie qui consiste en la conceptualisation et en la réalisation d&amp;rsquo;ouvrage d&amp;rsquo;art fonctionnel et qui repose sur une méthodologie et une rigueur toute scientifique. Paradoxalement, dans l&amp;rsquo;industrie, l&amp;rsquo;activité d&amp;rsquo;ingénierie dans le développement logiciel manque de rigueur scientifique et sa méthodologie s&amp;rsquo;apparente souvent à de la planification et à de la gestion des activités.</description>
    </item>
    <item>
      <title>Evolution de code en Haskell (partie 2) : évolution</title>
      <link>https://www.moquillon.fr/post/haskell_evolution_code_part2/</link>
      <pubDate>Sat, 25 May 2013 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/haskell_evolution_code_part2/</guid>
      <description>Nous savons faire évoluer une application écrite selon la POO en jouant sur les propriétés de rétention, de composition, et d&amp;rsquo;extension des objets, ces entités logicielles qui représentent les concepts adressés par le programme. Mais qu&amp;rsquo;en est-il en programmation fonctionnelle ? Comment peuvent être représentés les concepts ? Comment un code, écrit avec un langage fonctionnel, peut-il évoluer face aux changements ? Je vous propose de montrer ces aspects par un petit tour d&amp;rsquo;horizon d&amp;rsquo;un programme écrit en Haskell.</description>
    </item>
    <item>
      <title>Evolution de code en Haskell (partie 1) : conceptualisation</title>
      <link>https://www.moquillon.fr/post/haskell_evolution_code_part1/</link>
      <pubDate>Thu, 11 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/haskell_evolution_code_part1/</guid>
      <description>Nous savons faire évoluer une application écrite selon la POO en jouant sur les propriétés de rétention, de composition, et d&amp;rsquo;extension des objets, ces entités logicielles qui représentent les concepts adressés par le programme. Mais qu&amp;rsquo;en est-il en programmation fonctionnelle ? Comment peuvent être représentés les concepts ? Comment un code, écrit avec un langage fonctionnel, peut-il évoluer face aux changements ? Je vous propose de montrer ces aspects par un petit tour d&amp;rsquo;horizon d&amp;rsquo;un programme écrit en Haskell.</description>
    </item>
    <item>
      <title>Les programmations orientées objet</title>
      <link>https://www.moquillon.fr/post/les_programmations_orientees_objet/</link>
      <pubDate>Fri, 21 Dec 2012 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/les_programmations_orientees_objet/</guid>
      <description>La Programmation Orienté Objet (POO pour les intimes) est de nos jours la lingua franca de la programmation dite impérative. Pourtant, fort est de constater que celle couramment usitée est loin de l&amp;rsquo;approche définie par son auteur, Alan Kay, au point que l&amp;rsquo;on peut dire qu&amp;rsquo;il existe actuellement en fait deux approches orientées objet !</description>
    </item>
    <item>
      <title>Un benchmark sur le tri rapide dans 5 langages</title>
      <link>https://www.moquillon.fr/post/benchmark_dans_5_langages/</link>
      <pubDate>Thu, 22 Nov 2012 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/benchmark_dans_5_langages/</guid>
      <description>L&amp;rsquo;article de James Roper sur les performances de Scala et de Java via l&amp;rsquo;exemple du tri rapide m&amp;rsquo;a donnée l&amp;rsquo;idée, juste pour amusement, de réaliser le même benchmark mais avec 5 langages différents : C, Go, Java, Scala et Haskell ; on y retrouve donc ici à la fois des langages à orientation impérative et d&amp;rsquo;autres à orientation fonctionnelle.</description>
    </item>
    <item>
      <title>Langages impératifs vs fonctionnels</title>
      <link>https://www.moquillon.fr/post/langages_imp%C3%A9ratifs_et_fonctionnels/</link>
      <pubDate>Wed, 31 Oct 2012 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/post/langages_imp%C3%A9ratifs_et_fonctionnels/</guid>
      <description>James Roper a publié sur son blog un billet qui compare les performances de Java et de Scala via une réalisation du tri rapide d&amp;rsquo;une liste ou d&amp;rsquo;un tableau (&lt;em&gt;quicksort&lt;/em&gt;). J&amp;rsquo;ai trouvé l&amp;rsquo;article intéressant pour deux raisons principales et qui sont liées à la nature particulière de ces deux langages.</description>
    </item>
    <item>
      <title>A Propos</title>
      <link>https://www.moquillon.fr/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://www.moquillon.fr/about/</guid>
      <description>&lt;p&gt;&lt;img src=&#34;https://www.moquillon.fr/img/avatar.jpg&#34; alt=&#34;&#34; title=&#34;Miguel Moquillon&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;Je suis architecte et concepteur logiciel, tech lead, et programmeur. Je travaille actuellement au sein de la société &lt;a href=&#34;https://www.silverpeas.com&#34; target=&#34;_blank&#34; class=&#34;my-link&#34; rel=&#34;noopener&#34;&gt;Silverpeas&lt;/a&gt; qui réalise et vend &lt;a href=&#34;https://www.silverpeas.org&#34; target=&#34;_blank&#34; class=&#34;my-link&#34; rel=&#34;noopener&#34;&gt;le portail collaboratif open-source éponyme&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Bien que curieux sur beaucoup d&amp;rsquo;aspects de mon métier, je porte un intérêt tout particulier au génie logiciel, aux languages de programmation, et aux méthodes de travail centrées sur l&amp;rsquo;amélioration continue et pilotées par l&amp;rsquo;agilité.&lt;/p&gt;&#xA;&lt;p&gt;Ce blog est le fruit de certaines de mes réflexions et expériences sur ces sujets. Initialement motorisé par &lt;a href=&#34;https://dotclear.org/&#34; target=&#34;_blank&#34; class=&#34;my-link&#34; rel=&#34;noopener&#34;&gt;DotClear&lt;/a&gt;, j&amp;rsquo;ai décidé de le générer avec &lt;a href=&#34;https://gohugo.io/&#34; target=&#34;_blank&#34; class=&#34;my-link&#34; rel=&#34;noopener&#34;&gt;Hugo&lt;/a&gt;. J&amp;rsquo;y ai repris toutefois certains de mes anciens billets.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
