La conteneurisation d’une application est aujourd’hui un standard dans le monde du développement, mais orchestrer des applications conteneurisées c’est encore mieux. Automatiser la construction de l’application ainsi que son déploiement est bénéfique pour l’accélération du cycle du développement logiciel. L’automatisation est réalisable par des pipelines de CI/CD et en reposant sur des plateformes de conteneurisation. Dans cet article, on démontrera étape par étape comment automatiser le build et le déploiement d’un exemple d’application Node.js en mettant en œuvre les outils : OpenShift, GitHub et Jenkins.

Je suis utilisateur de Vi/Vim depuis des dizaines d'années et changer ses habitudes n'est pas chose facile. Un élément déclencheur est souvent nécessaire et le mien aura été un essai de Visual Studio Code pour du développement sur microcontrôleur avec PlatformIO. J'ai donc décidé de quitter Vim pour passer à... Neovim. Hé oui, ne vous y trompez pas, car même si VSCode s'avère effectivement agréable, voire proche d'une expérience Vi avec les bons plug-ins, et qu'on s'habitue facilement au confort de la complétion « IntelliSense » et de l'affichage des prototypes de fonctions, cet IDE graphique ne sera jamais Vi. Au contraire, il pousse simplement à faire en sorte que son Vi adopte des fonctionnalités qu'il ne possède pas nativement. Et c'est précisément ce dont il est question ici.

Il est parfois indispensable de modifier l'exécution d’un programme, sans en modifier le code source, pour l’adapter à des besoins spécifiques. Quels sont les moyens que nous offre Linux ?

Pour commencer cette série sur les codes fantastiques, nous allons faire un petit tour dans la page de manuel de dlopen et (re)découvrir une forme d’introspection au niveau bibliothèque partagée.

Comment centraliser la configuration d’une application, tout en permettant un ajustement au cas par cas avec des variables d’environnement, sans se répéter.

L'écriture de pilotes et de modules noyau Linux est documentée en long, en large et en travers sous bien des formes, et ce depuis quelque temps déjà. Pourtant, ce n'est pas là que l'énergie et le temps nécessaire pour ajouter une fonctionnalité ou le support d'un matériel seront obligatoirement les mieux investis. La quantité de développeurs soumettant des contributions au noyau Linux est énorme et très souvent, la question consistant à se demander si un matériel est pris en charge ne se pose même plus. Quelqu'un a forcément développé quelque chose avant que vous ne rencontriez un tel problème. Ce n'est pas forcément le cas pour d'autres systèmes, et NetBSD en particulier. Là, apporter sa pierre à l'édifice est sans doute plus intéressant. Mais avant de pouvoir courir, il faut savoir marcher...

Quand on entend Kotlin, on pense tout de suite à Android, découvrez comment on peut l’utiliser pour développer une API GraphQL.

Après avoir survolé ce qu'était une trace distribuée dans l'article sur les 3 piliers de l'observabilité, et donné une description des différents éléments qui la composaient, nous allons entrer un peu plus dans les détails de l'instrumentation proprement dite. Car si collecter des traces pour mieux comprendre une application en microservices change totalement la donne, pour autant, cela demande un peu de travail. Et c'est justement ce qui explique la montée en puissance d'OpenTelementry aujourd'hui. Vous allez découvrir pourquoi.

Comme nous le dit Wikipédia, la télémétrie « est une technologie qui permet la mesure à distance et la journalisation d'informations d'intérêt vers le concepteur du système ou un opérateur ».