HTTP, pour Hypertext Transfer Protocol, est le protocole principal pour les échanges internet. Il est utilisé aussi bien par le navigateur que vous utilisez pour lire cet article, que pour faire communiquer des applications.
Il s’appuie sur un échange de requête et réponse, entre un client et un serveur, au format texte. L’avantage du format texte est qu’il est facile à implémenter dans tous les langages de programmation.
Le protocole HTTP est spécifié par la RFC 2616, protocole dont la toute première version d’HTTP date de 1990.
Que ce soit pour un projet d’entreprise ou un projet open-source, la documentation utilisateur et technique est cruciale.
Dans une documentation d’usage, les utilisateurs doivent pouvoir retrouver les instructions leur permettant d’accomplir les gestes métier de tous les jours.
Pour la documentation technique, les administrateurs, opérateurs et développeurs doivent pouvoir retrouver les opérations d’installation, de mise à jour, ou encore de développement du produit.
Lors du développement d’une application pour Kubernetes, le développeur est souvent lié à une boucle de feedback assez longue:
Développement
Contruction de l’image Docker (quelques secondes/minutes)
Push de l’image sur un registry
Déploiement sur Kubernetes (quelques minutes)
Cette boucle est généralement implémentée par des pipelines de CI/CD. Ces pipelines augmentent encore le temps entre le développement et une application démarrée sur Kubernetes. Ce temps est relativement long lorsqu’on compare un cycle de développement local auquel un développeur peut être habitué.
Je suis le genre de développeur qui travaille toujours avec un terminal ouvert sur le côté, en plus de mon IDE.
Je lance souvent des commandes mvn pour m’assurer que mon projet compile et que mes tests s’exécutent correctement. C’est un vieux réflexe qui date de l’époque où les IDE n’avaient qu’un support limité de Maven. Lancer ces commandes hors-IDE m’aide souvent à valider que tout fonctionnera bien dans un environnement de CI par exemple.
J’ai donc parfois besoin de changer de version de Java en fonction du projet dans lequel je me trouve.
Maven utilise la variable d’environnement JAVA_HOME pour localiser l’installation de Java à utiliser. Donc être capable de charger des variables d’environnement différentes en fonction d’un projet peut s’avérer pratique.
Un autre usage courant consiste à venir charger des clé d’API ou des secrets d’accès cloud comme des variables AWS_ACCESS_KEY ou autres en fonction de mes différents projets.
Cet article explique comment configurer un fichier .gitignore global, pour exclure des fichiers ou des répertoires pour tous vos dépôts git.
Utiliser un fichier global permet d’ignorer des fichiers dans l’ensemble des répertoires Git de votre poste.
C’est très utile pour certains fichiers, comme les fichiers .env. Cela empêche surtout les commits accidentels.
J’ignore aussi les répertoires communs pour les développements liés à Java et NodeJS (target/ et node_modules), ainsi que les fichiers IntelliJ IDEA (*.iml et .idea/).