BreizhCamp2024 : à l'ouest toute !

Ivan Béthus — Thu, 11 Jul 2024 14:15:27 +0000

Nous sommes de nouveau sur la route avec quelques membres des équipes onepoint pour le rendez-vous breton des développeurs en tout genre : le BreizhCamp.
Créé en 2011 à l’initiative du BreizhJUG, le BreizhCamp propose de faire se rencontrer les communautés du développement et de l’expertise, avec un contenu à la carte sur plus de 100 thèmes présentés.

En plus des nombreux sujets présentés par nos collègues, nous avons préparé avec @dlucas un petit top 3 de nos conférences préférées. À vos lunettes, il y a de la bonne lecture !

Du code source à l'exécutable : plongée dans les entrailles de la compilation en Rust par Édouard Siha

Comment le compilateur Rust fait-il pour assurer le respect de la notion d'emprunt ? Pourquoi est-il capable de générer facilement des binaires spécialisés pour une plateforme d'exécution différente de celle de la plateforme de compilation ? Quel genre d'optimisations surprenantes est-il capable de réaliser ? Quelles caractéristiques le différencie des compilateurs utilisés pour le C ? Pour le Java ?

Si ces questionnements vous intéressent, la conférence d'Édouard Siha est un incontournable. Il rentre en détail dans les étapes de la compilation en Rust, en faisant une analogie assez pédagogique avec les profondeurs marines. Un deep dive très intéressant pour renforcer sa compréhension du Rust et de manière générale des différentes étapes de création d'un binaire exécutable.

MongoDB en scale-up : comment sortir d’un enfer monolithique par Alexis Chotard et Caroline Becker

Ce talk, c'est l'histoire d'une scale-up spécialisée dans la gestion de fiches de paie : PayFit. Le 15 mars 2023, leur cluster MongoDB s'écroule, alors qu'il contient 95% des données utilisateur et il est vital au fonctionnement de l'application.

A travers cette conférence, on découvre comment de mauvais choix d'architecture ou une croissance organique et (trop) rapide ont pu mener à une situation aussi critique. Heureusement, Alexis et Caroline nous expliquent également comment ils ont réussi à réparer leur application, entre stabilisation technique, détricotage du modèle de données, ou encore élimination de single point of failure.

Si on ne doit retenir qu'une chose de ce retour d'expérience, c'est qu'un modèle de donnée doit coller au métier et que la duplication doit être maitrisée. Ici, le principal problème était lié à des données redondantes et stockées en grande quantité, qui ont fini par saturer la base NoSQL...

RetEx : Optimisation du temps de démarrage d'une application Java Spring par Daria Hervieux

Daria Hervieux nous explique comment elle et son équipe ont étudié plusieurs manières de réduire le temps de démarrage d'une application Spring pour atteindre un taux de disponibilité de l'application à 99,9%

Elle nous livre donc les résultats des trois expérimentations effectuées :

Class Data Sharing (CDS) : cette technique permet de réduire le temps de démarrage et l'empreinte mémoire des JVM en mettant en cache les métadonnées de classes dans un fichier d'archive afin qu'elles puissent être rapidement préchargées dans une JVM nouvellement lancée.
Spring Ahead-of-Time (AOT) : sans aller jusqu'à la création d'image native, Daria nous explique qu'ils ont utilisé la technique de compilation AOT qui permet de pré-compiler le bytecode en code natif avant le démarrage de l'application. Le tout, s'exécutant sur une JVM traditionnelle.
CRaC (Coordinated Restore at Checkpoint) : cette technique repose sur le principe d'effectuer un checkpoint de l'état de l'application à un moment donné, puis de le restaurer à partir de ce checkpoint lors du redémarrage de l'application. Cela permettant notamment d'avoir les hotspots de l'application déjà chargés en mémoire.

Daria conclut par un tableau comparatif en termes de gain, inconvénients, taille de livrable... Pas de spoil ! Nous vous laissons découvrir le résultat de son étude dans le replay (quand il sera disponible) !

Git update-refs in a nutshell

Ivan Béthus — Thu, 23 May 2024 17:26:37 +0000

Original article on my blog (🇫🇷)

When working on a versioned project, it is relatively common to end up with a "stack" of branches. What could be more frustrating than having to rebase all the other branches on top of the first one when updating it? This process becomes even more tedious when the number of branches is high or when they are regularly modified.

Git version 2.38¹ introduces a solution to this problem: the update-refs rebase option.

Stack?

Branch stacking is a way to break down important features, allowing for smaller pull requests. In the example below, three branches dependent on each other have been created, allowing "my feature" to be divided into three distinct blocks.

The assumption here is that when each of these branches is individually merged into the main branch, the code will still be functional, as it has been appropriately divided.

Let's say a small typo was made in the commit of the my-feature-v1 branch. A second commit needs to be added to fix the issue, resulting in the following history:

In this situation, the only solution to update my-feature-v2 and my-feature-v3 is to checkout and rebase v2 on v1, then v3 on v2.

This cumbersome process is remedied by the update-refs rebase option.

The solution

update-refs

The goal of this option is to automatically update the n branches on which the branch being rebased depends.

Thus, in our case, we can simply checkout our my-feature-v3 branch and run the command git rebase my-feature-v1 --update-refs. With this option, Git updates not only the v3 branch but also the v2 branch to preserve the history. The result of this operation is as follows:

In practice:

Updating the Remote Repository

Even if the branches being manipulated have already been pushed to the remote repository, it is possible to update all of them in a single command: git push --force-with-lease origin my-feature-v1 my-feature-v2 my-feature-v3

Here, a specific force push is used to preserve the remote history².

Global Activation

Why not always use the update-refs option during a rebase? The Git team asked themselves the same question and decided to include this possibility in the configuration. Thus, git config --global rebase.updateRefs true activates the option globally for each of your rebases.

In Summary

git rebase {my-branch} --update-refs updates a branch and all its dependencies
git push --force-with-lease origin my-branch-1 my-branch-2 my-branch-n pushes the update of these branches to the remote repository

Happy rebasing!

The release note is available here ↩
See the use case ↩

DEV Community: Ivan Béthus