This year I had the opportunity to attend two conferences: the Breizhcamp in Rennes and the DevFest Perros-Guirec. Among all the interesting conferences I attended, I wanted to share my thoughts on one conference per event, those that interested me the most.

Breizhcamp - Setting up an ADR

For some time now, I have read articles about how to track architectural decisions for software. The subject strongly interested me because I saw a major advantage (or complementary) compared to traditional technical specifications: it allows you to put context back into decision-making.

An ADR (Architecture Decision Record) is a tool that allows you to track architectural choices throughout a project, with each decision including:

the date
the people who participated in the choice
the different options proposed
the reasons for the choice (or non-choice if it is decided to remain as is)

Sébastien Lecacheur presented at Breizhcamp 2023 a return of experience on the method, with a tool and its use within his company. They work in an environment with legacy and many applications. One of the recurring problems is that when a new developer joins a project, after some time they ask questions about the architecture and certain technical choices. If the person who knows the history best is not there, it can generate frustration (why did they do that?). One of the goals of implementing the tool was to be able to easily provide reliable answers to this type of questioning.

Another objective was to make decisions more collaborative, to integrate and track everyone’s ideas more easily. That architecture is no longer the holy grail of leads/architects, but it’s something that everyone can have their say. Today, after a certain period of using the tool and its internal dissemination, more people are interested in it and making proposals. The teams are well-appropriating the tool and the evolution of the architecture has become more collaborative.

The tool he presented is the one they implemented: log4brains. It is a NodeJS tool that is easy to install and deploy, and it allows you to generate a static site from markdown files. Each file corresponds to an architectural change proposal, and you can track all the necessary information. Then, using the following command, you generate the site:

$ log4brains init

The CLI then guides you through the initial configuration of your ADR in relation to the project context. Once this step is completed, you can launch the site to see what it looks like:

$ log4brains preview

Here is a screenshot of the home page of the site just after the initial configuration: Home page of the site generated by log4brains: an explanation of how the tool works

And here is another one of a completed decision: First ADR created automatically: use log4brains to manage ADRs

As you can see, the interface is simple, the history of decisions is presented in the form of a timeline on the left, the basic model lists the main information, and at the bottom there are links to navigate from one decision to another.

We have implemented it on our ongoing projects; we are satisfied with its simplicity and it suits our usage after adapting the basic decision model (we use a very simple model). Here is a GitHub repo with lots of other information if you are interested in going further.

I am putting the link to the talk video again: here.

Devfest Perros - Copilot: Artificial Intelligence at the Service of Developers

Since the arrival of GPT3 and ChatGPT, AI has become a major topic in the tech community, as well as in society in general. GitHub Copilot has been available to everyone for over a year now, so this conference was an opportunity for me to discover more about the product and its capabilities.

Tugdual Grall, an engineer at GitHub, presents this talk on how Copilot works and its daily usage. He starts by introducing us to what lies behind Copilot:

The engine is trained 2 to 4 times a year on everything that is public in GitHub
There is a toxic filter to moderate the prompt (for example, “I want to create a DDOS tool” will yield nothing)
Emphasis is placed on securing and optimizing the suggested code
There is a parameter to detect code duplication from a public repo and avoid having a suggestion too close or identical to that code
To generate a suggestion, context is sent to Copilot; nothing is kept (ephemeral session)
All languages present on GitHub are supported

That’s for the generalities. Now let’s move on to the demos. Once the extension is installed (in VsCode or IntelliJ), Copilot can make suggestions:

Automatically, based on the cursor position in the open file
By writing a comment describing what you want to do (in natural language, French works)
Or via Copilot Chat

Copilot can assist us with simple tasks, but for implementing business logic, it won’t be relevant. It can also help us understand a piece of code or suggest improvements (security, optimization) using the “explain” command. To create its context, Copilot uses the files currently open in the editor. The better the context, the better the suggestions.

At the end of the presentation, he also talked about Copilot for CLI, which allows you to use Copilot in a terminal. The operation remains the same; it allows generating command suggestions or explaining them.

Since this presentation, I have tried Copilot daily in my development activities. Here are some feedback points after several months:

Copilot can save us time on simple tasks, writing tests, or documentation. Having the right context and the right files open in the IDE makes a difference.
For business logic code, few suggestions are truly relevant; the business aspect is mainly the developer's responsibility (and thankfully)
The “explain” command can be very useful once you get used to it
An important point for me: it might not be suitable for everyone or should come with training and a warning. As a senior, I have seen suggestions that were not at all adapted to our code appear; I'm not sure a beginner would necessarily see the issues. The implementation of the tool must be accompanied by training and monitoring of the results (but everyone does code reviews 🙂 ). It only makes suggestions; mastery and understanding of the final code remain the responsibility of the developer.

As a development assistant, I am satisfied with what it can bring me on a daily basis, and for certain tasks, the productivity gain is evident.

The conference was not filmed, but you can find Tugdual’s blog post about his usage of Copilot here, as well as the video of this talk but at another event here.

If you enjoyed this article or found it useful, feel free to 👏 or share it! 🙂