Depuis quelques temps je me mets à Gradle. Après de (trop?) nombreuses années à utiliser Maven (depuis la version 0.9…), je me risque à modifier mon environnement de build. Du moins sur des projets démo.
Quand on a fait pas mal de Maven, on est un peu dérouté au début. On a d’un coté, la plupart des actions qui sont configurées de manière implicite et de l’autre on peut tout coder/étendre ou presque.
Je suis en train de mettre en œuvre des tests de performance avec Gatling. Un des principaux outils libres de tests de performance.
J’ai eu récemment à résoudre un « petit » soucis : je souhaitai partager des variables entre plusieurs scénarios. Il existe pas mal de solutions sur stackoverflow. J’ai condensé certaines d’entre elles pour les adapter à mon besoin.
Ces variables sont issues de exécution d’une seule requête et sont automatiquement injectées dans les scénarios suivants.
Une fois n’est pas coutume, voici un article qui reprend des basiques de la programmation. J’aborde une stack JAVA, mais c’est applicable à d’autres langages.
Il existe une fonctionnalité très intéressante dans Spring (et dans J(akarta)EE) que l’on oublie assez souvent : l’AOP ou encore la programmation par aspect. Cette manière de programmer permet notamment de séparer le code fonctionnel et technique.
Si vous faites du JAVA, vous utilisez déjà l’AOP.
Après avoir soumis mon article sur le coaching des développeurs, je me suis rendu compte que j’ai oublié pas mal de points qui, à bien y réfléchir, me paraissent essentiels.
Dans mon précédent article ( the first blood pour le coup ) je me suis attardé sur le « quoi » : toutes les actions que j’ai testé dans l’encadrement des jeunes développeurs et des développeurs en général.
Maintenant, je vais essayer de m’attarder sur le « comment » : ma démarche, la posture que l’on doit adopter ( ce n’est que mon ressenti ) etc.
Auparavant, dans nos tests, quand on voulait mocker des méthodes « final » ou statiques, on devait passer par PowerMock.
Depuis peu, si on utilise Mockito ( >2.1) , on n’a plus besoin d’ajouter PowerMock pour mocker des méthodes « final ».
Bon il reste toujours la gestion des méthodes statiques à gérer autrement qu’avec Mockito, mais cela va dans le bon sens.
Voici comment activer en quelques commandes le mocking des méthodes « final ».
Juste pour un pense bête, voici comment paramétrer GIT et GITHUB/GITLAB pour signer les commits avec GPG.
1 Configuration GPGExécutez la commande suivante :
1 2 gpg --full-generate-key Sélectionnez une clé RSA (question 1) de 4096 bits (question 2). Une fois cette commande effectuée, vous pouvez récupérer votre clé GPG avec cette commande:
1 2 3 4 5 6 7 gpg --list-secret-keys --keyid-format LONG alexandre@.... /home/alexandre/.gnupg/pubring.kbx ---------------------------------- sec rsa4096/XXXXXXXXXX 2019-08-09 [SC] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX uid [ ultime ] Alexandre Touret <mon.
En changeant de société l’année dernière j’ai eu l’impression de monter d’un cran dans la pyramide des ages.
Pour faire plus simple, je me suis senti un peu plus vieux.
Si vous avez quelques années d’expérience dans le développement ou tout simplement dans la technique, vous avez déjà eu l’occasion de coacher ou d’encadrer techniquement des jeunes diplômés.
Et oui, c’est un signe !
Maintenant vous avez assez de recul ( pour ne pas dire que vous êtes vieux/vieille) pour encadrer techniquement des jeunes ingénieur.
