Le gestionnaire de versions Git est devenu omniprésent et son utilisation a depuis longtemps dépassé le cadre des projets logiciels. Cet article est le premier d'une série qui s'adresse tout autant à ceux qui connaissent tout juste trois ou quatre commandes Git qu'à ceux qui ont une utilisation avancée et souhaitent une compréhension plus profonde. Cet article décrit les concepts sous-jacents à Git : le commit (non, ça n'est pas un diff), la branche (non, ça n'est pas une séquence de commits), HEAD… L'article introduit une représentation graphique de ces concepts et liste rapidement quelques représentations alternatives que l'on peut trouver ailleurs. Pour permettre une compréhension profonde de l'outil, cet article détaille enfin comment Git stocke vos informations dans le système de fichiers. Les articles suivants de la série présenteront différentes façons de travailler avec Git, en étudiant par exemple l'impact des commandes merge et rebase. Ils expliqueront de nombreuses commandes Git et leurs options en s'appuyant sur votre nouvelle compréhension des concepts et sur notre représentation graphique.

Qui n'a jamais, dans les logs d'une machine ou d'une VM exposée au grand nain Ternet, remarqué des tentatives de connexion sur l'un ou l'autre service qui, de toute évidence, n'était pas de son fait ? Je sais, ceci est monnaie courante et la plupart du temps totalement bénin, dès lors qu'on aura configuré son serveur SSH avec un minimum de sérieux. Mais ne vous êtes-vous jamais demandé quelles informations de connexion étaient utilisées ou quel mot de passe aura été tenté ?

La revue de code représente une pratique essentielle dans le processus de développement logiciel. Cet article illustre l'amélioration du processus en intégrant les retours de l’analyseur statique SonarQube Cloud au serveur de source GitHub. Pour cela, une application minimaliste développée en Rust, exécutée à l'aide d’AWS, facilitera cette intégration.

Java est un langage de programmation très connu et largement utilisé pour des applications côté serveur, des applications mobiles ou des clients lourds. Ce qui est sans doute moins connu, c’est qu’il est aussi possible de l’utiliser comme un langage de script, avec certaines limitations que nous allons voir.

Je ne vous apprends rien en vous disant que GNU/Linux dispose de bien plus de pilotes de périphérique que, disons, OpenBSD. Ceci n'est pas bien grave en soi puisqu'il suffit d'en développer de nouveaux, tout en s'inspirant du travail du développeur s'étant déjà cassé les dents sur le sujet (merci, le logiciel libre). Là où cela devient pénible, c'est que les bêtises coûtent cher lorsqu'on touche à un noyau et qu'elles se soldent généralement par des resets brutaux et à répétition. Ne serait-il pas merveilleux de pouvoir accéder à certains matériels depuis l'intérieur d'une machine virtuelle, pour rendre cela plus digeste ?

Le but de cet article est de mettre en place un protocole d’échange de défi chiffré via OpenPGP pour éviter d’avoir à transmettre le mot de passe d’un utilisateur dans une application web.