Introduction

DevLille is a two-day event dedicated to the tech world that takes place yearly in Lille (France). I have attended this event for several years and am never disappointed. This year I decided to write a blog post about which talks I liked and my thoughts. Let’s go!

Thursday

In praise of simplicity - Frédéric Leguédois

The usual opening keynote was this time about project management and agility.

The main point I take away from this is that you don’t become “agile” by just snapping your fingers and renaming your schedule to a backlog.

The presenter makes his case that trying to predict the future is a waste of time. What we should focus on is responding to our users’ needs now.

We even got a nice definition of what a schedule actually is: “A schedule is everything you’re certain not to do now and will be outdated tomorrow.”

Even if I agree with this take, I’m wondering how you can integrate non-functional requirements with this approach. I’m thinking of security, maintainability, or even performance of our applications. These are also useful to our users but in a more indirect way.

Next came the question of how to prioritize subjects, joking about how estimates in dev work and their outputs are notoriously unreliable. So of course, when we use those unreliable estimates, we often end up with a ROI calculation that has little basis in reality and is more divination than science. I really liked that way of seeing things.

The proposed solution was to take the most important problems for our users, select a few solutions that might fix them, and implement one of the simplest ones. I am a little bit more worried about that last part. Now, of course, everyone prefers a simple solution to a complex one. But speaking from experience, simplicity is not achieved on the first draft but rather conquered through trial and error. On that point, the iterative approaches that the presenter advocates for are a really good answer.

All in all it was a very pleasant talk with a good performance from the presenter.

What’s under the hood of PostgreSQL - Coenen Benjamin

A very technical presentation, just like I like them, that actually fits in 45 minutes. The idea here is to demystify how some of PostgreSQL’s functionality works under the hood. We went through

• The file hierarchy and structure where postgres stores its data.
• How its different processes are architectured and their responsibilities.
• How queries are executed.
• The inner workings of transactions
• The VACUUM
• The WAL (To handle crash and replication)

I’m not going to go into details over these points, and I highly encourage you to watch the replay once it’s available. I will put up a link when it’s uploaded.

One of the questions I had was that if Postgres has a lot of synchronization processes (from memory to disk) to avoid writing to disk on each query, why would it be okay to write to the WAL for each operation. I asked the presenter, and the reason is that the WAL is a file that is continuous and much faster to write to than the actual data on the disk.

Domain names: the great history of small extensions - Benoît Masson et Théo Bougé

A talk on how TLDs (Top Level Domains) work in DNS. I learned that non-ASCII characters are actually supported thanks to a little transformation that makes it invisible to the end user.

We also had a chance to talk about how certain TLDs that we regularly use are actually country codes. For example :

• .tv : Tuvalu (an island in the Pacific)
• .ai : Anguilla (an island in the Caribbean)
• .yt : Mayotte
• .rs : Serbia

This talk touched on the central role of ICANN (Internet Corporation for Assigned Names and Numbers), which poses real questions. Even if this is a non-profit organization, it is still an American organization that holds existential power over the web.

The bug is not in the code! I finally understood why 50% of women leave the tech industry before 35 - Vanessa Chodaton

A very interesting talk on how some bugs can make the working environment in the tech industry hostile to women, but not only. The starting point was this data that shows that 50% of women leave the industry before 35.

The 4 bugs were as follows:

• Mistaking velocity for competence, undervaluing invisible work such as helping out a colleague, making them grow, or doing reviews.
• Biases, especially gender biases against women, where they’re assumed to be incompetent whereas men have the opposite assumption attached to them.
• Toxic environments with small aggressions, lack of respect, and tolerance for toxic profiles.
• Personal responsibility, where repeatedly having to prove your worth, doubting, and wanting to stay on top of it all can lead to exhaustion.

It was very enlightening, and I’ll try to keep these in mind to promote a safe and pleasant working environment around me. I also really liked the conclusion:

*“We don’t leave tech because we don’t like it but because we don’t have the strength to fight anymore.”

Why nobody likes reviewing your PR - Maxime Clément

Pull request reviews is a very broad subject. This talk was about how to make it easiest for someone else to review your contribution.

The main point was that PRs should tell a story to the reader by making a manageable amount of commits that split the PR into sub-stories. This is achievable by rebasing to rewrite the history and make it clear and linear.

These are already practices I try to incorporate into my work, but I think I’ll try to be especially careful with that in the future.

The talk was also filled with clever comparisons and a few results from psychology, which was very informative.

Vibe coding is dead, long live spec coding - Aurélien Allienne

Next up was the AI part of the day. I’m not a big AI user, and I think this technology poses serious questions about sustainability and sovereignty. But I was willing to learn more about those practices. The premise of the talk was the following: Vibe coding might be acceptable for a weekend throwaway project, but it quickly gets hard to maintain and filled with security holes.

To fix those issues but still harness the power of AI, the presenter proposes “spec coding.” Meaning, instead of focusing on the code, we should focus on the spec. And we should do so by using a precise workflow: Plan/Produce/Assess/Compound, with a live demo showing that off.

To be honest, I’m not sure I understood how this approach could protect us from security holes or bad code. Because in the end, it is the code that is actually executed. If you understand this part better than I do, don’t hesitate to share it with me.

ClaudeCode.proTips(20, minutes=20).run() - Erwan Gereec

A short list of tips for using Claude Code. Now, I’m not a user of this tool (or any equivalent for that matter), but explanations were clear enough that I could follow along, and I noted them just in case I take a look at this tool in the future.

It still convinced me to at least give it a shot to make my own opinion, with the caveats I mentioned earlier.

Deploy often, worry less: feature flags in critical production - Marion Chineaud et Elise Souvannvong

I followed that talk, which highlighted the different strategies to deploy code regularly without impacting users negatively with a feature that wouldn’t be completely ready. All thanks to feature flags. This is a practice I discovered when I read “The DevOps Handbook.” I was able to experiment with it, and I can testify that this is a really good way to deploy safely and control your production.

The presenters mentioned different kinds of feature flags for different targets: PMs, devs, ops. They also mentioned a few ways to implement them, either as config on application startup or in a database with an admin panel.

I highly recommend looking at this talk if you’re not familiar with this practice, as it can really be a lifesaver.

From pioneers to invisible: where did women go in computer science ? - Chloé Masse

I love technical talks, but I also love talks about societal issues linked to the tech world. This one was a good way to retrace the history of big contributions made by women to the computer science field. I must admit that aside from Ada Lovelace, I did not know any of these women, such as Grace Hopper, Margaret Hamilton, or Alice Recoque.

The presenter made the point that when programming was not seen as a prestigious activity, it was women who were handling it. But once programming became serious, it became mainly an activity for men.

Then she touched on the absence of role models in technical jobs, which does not help make women more visible.

I will have to do my homework and learn a bit more about these histories, as I was completely ignorant of that. And it is important to have a good idea of computer science history.

Friday

Are we still developing applications for humans ? - Johnathan Meunier et Julien Gaudet

The second day started with this presentation, which invited us to think about a future where a lot of our lives would be handled by an agent. In that world, user interfaces (UIs) would become irrelevant because agents do not use them, and they would be replaced by MCPs.

We took a detour on matters such as FAANG dependency, sovereignty, and even the place that we are comfortable giving to these agents in our lives. I was pleasantly surprised to hear about those matters that are too often shoved under the rug for my taste.

One of the arguments, which I had already heard before, was that now we would “code” using natural language, in markdown for example, with an LLM generating source code for us, which in turn would be compiled. This would give us a compilation chain such as: .md => .js => .c => .asm

As far as I’m concerned, I think reality is a bit more nuanced than that. First, a compiler is a deterministic tool, whereas LLMs aren’t. On top of that, it seems to me that keeping the skills and knowledge of those intermediary steps is important as far as security and performance go. Knowing the JS runtime makes writing performant code possible, just as much as knowing some amount about the Go or Rust compiler can help optimize programs.

An interesting though experiment, let’s see what the future holds.

Keeping the keys of one’s data : Sovereignty through encryption - Aeddis Desauw

A presentation of three offerings from OVHCloud for cryptographic key management around HSMs (Hardware Security Modules).

• Dedicated HSM: Where you rent an actual HSM. This requires you to master the appliance and its interfaces. But it’s the most performant option and gives you the most control.
• Key Management Service (KMS): A managed offering that gives access to an API to handle cryptographic operations on mutualized HSMs that are fully operated and managed by OVHCloud. This is the simplest solution but the least performant and with the least amount of isolation.
• Managed HSM: A still-in-development solution with mutualized HSM but isolated. OVHCloud manages the administration of these appliances and gives you a PKCS#11 interface that allows you to abstract the vendor interface away. It offers you better performance because you can reserve a fraction of an HSM, so it is a middle ground.

Very interesting, and presented by a member of the CHATONS association, which is an association of alternative hosters. If you’re interested in software freedoms, I encourage you to check them out.

What if your database was the queue you needed ? - Julien Lampin

The last talk of the morning proposed an idea that might seem counter-intuitive at first: Use one’s database as a message broker. The main point was that sometimes, actual message brokers such as Kafka, RabbitMQ, or Pub/Sub might be overkill for your needs.

With some examples based on MongoDB, the presenter walked us through how to implement some of their properties easily using a table (or a collection in MongoDB’s case).

To cite a few examples, you might want to set up a Dead Letter Queue (DLQ), the place where asynchronous tasks go when they fail. You can easily model that in your table by adding a specific status field.

I found this take interesting, and the talk ended with a summary of when it might be a good idea to try this approach and cases where you should probably avoid it. For example, if you need strict ordering, then Kafka is still the king.

EcoScore A or E : where is our API - Emmanuel Peru

Today, the tech industry represents around 4% of global greenhouse gas emissions, and with the AI era, it’s not going to decrease anytime soon.

We started with some numbers on the impact of the digital world on pollutions. For example, half of the energy consumption is for building the computers, and the other half is for using them. For other environmental matters such as water and raw materials, it is mainly the production of the devices that is polluting the environment. But the presenter warned us not to be fooled by that: device production is driven up by our applications requiring more and more resources each year.

It was followed by a presentation of two frameworks to try to assess the energy consumption of one’s application, API Green Score and EROOM. While they are useful, they can be pretty hard to fill, and the presenter showcased their tool to try to make this job a little bit easier zats-greenscore through a pretty UI.

I think this is a good thing that this kind of consideration is taken into account, especially in an industry that mainly speaks about AI nowadays, without asking too many questions about its environmental or societal impacts.

It seems, though, that there are other frameworks to estimate these kinds of things. From my point of view, it’s still going to take some time before those different frameworks converge into something a little bit more standardized.

Take back control of your data platform from american giants - Jonathan Fritsch et Nathan Leclercq

We were then shown how you can build a data platform without using any of the big American clouds. We started with a comparison between a person who manages a beer shop and delegates its beer production to a third party in the US, therefore losing its recipe and control of their costs.

The idea was to show that this could be done with your own hardware, open-source tooling, and ops skills. For that, the presenters used protocols and open-source tools rather than services. So when a typical data platform on Google Cloud Platform (GCP) would probably contain a mix of BigQuery, Composer, Cloud Storage, etc., their stack was made of k3s, Airflow, Minio, or Garage for the S3 part, all of that managed by Ansible.

Of course, to pull that off, you would need some ops skills and time, and you should take into account the server costs, including their maintenance. But even then, the costs can be significantly lower than big American cloud providers.

Even if we put the costs aside, it could still be a good idea to shield yourself from the Cloud Act that allows American authorities to access your data even when hosted in Europe. And if you don’t have the people to make that happen, you can probably use a European vendor such as OVHCloud, Scaleway, or Clever Cloud.

DevGreenOps : From energetic sprint to marathon with Decathlon x Greenspector - Olivier Philippot, Ludovic ROLAND et Nathalie OTTE

We go back to the energy efficiency matter with a joint presentation from Decathlon and Greenspector. It was their experience using the Greenspector tool to try to measure and improve the energy efficiency of their mobile Android application.

The presented process was pretty straightforward, and I find it very similar to how you would think about end-to-end testing. Meaning: Identifying critical paths, implementing tests that go through them, automating them to be played regularly, such as in your CI.

In the Greenspector case, my understanding is that you would do that using their own DSL (Domain Specific Language). I would have loved that it was made using a general-purpose programming language, just like k6 from Grafana is doing. Indeed, if I have to write e2e tests anyway, I would love to be able to reuse them for my energy efficiency assessment tool and not have to duplicate them. I asked them if this is something they would consider, and it was not really in their priorities right now.

Despite some difficulties having reliable results because they were running their tests in production, which could be impacted by a number of things, they still managed to find some improvements in this area, notably by removing a redundant analytics tool.

In any case, I’m glad that this kind of topic is brought up and put forward. I hope this will continue and amplify. I couldn’t help but notice that the way the tool would calculate the impact was yet another calculation from EROOM and API Green Score, as seen in the EcoScore talk, which brings me back to the lack of standardization in that field for now.

Thanks to the presenters for this crystal-clear experience-sharing moment.

What is OID4VP : the protocol behind digital european wallets - Gilbert Djamena

As I had to go, this was actually the last talk I could attend. I finished this DevLille edition with this introduction to the OID4VP protocol (OpenID for Verifiable Presentations). This is a protocol that solves the following problem: How can someone prove to a third party that he or she matches some criteria (like their age) in a secure way and without sharing sensitive personal data such as their national identity card.

We were walked through all the steps in this process. Notably, the presenter explained that all fields in the document that prove the age are shared with the third party, but only those approved by the user can be decrypted by this same third party. I was wondering if this was vulnerable to “store now, decrypt later” attacks, where an attacker could collect some sensitive data in its encrypted form today, and tomorrow, if the encryption scheme is broken, decrypt it. If the data is long-lasting, such as a name or a birthday, this could be a real problem.

I went to the presenter to ask this very question, and he explained to me that yes, this could be an issue, but a new version of the protocol was coming up that was not reliant on SD-JWTs (Selected Disclosure JWTs). This solution would only send required fields and therefore be immune to those kinds of attacks.

Of course, with these technical presentations, it is very hard to retain everything, so I will need to look a little bit more into it to get a good grasp of how all of this works.

Conclusion

This wraps this edition up. I’ll add the links to the replays when they are available.

I was glad to be able to attend. I learned lots of things, be it on Top Level Domains or OID4VP. The talks about societal issues, such as the lack of women in the field, made me want to dig a little bit deeper into those subjects. I also tried to go out of my comfort zone and went to some AI talks, and I think I will try to play with the Mistral AI CLI to see if there is a way to make it work in a non-intrusive and secure way (at least as secure as I want it to be).

I really wish I could have been there for the Factorio talk. As a big fan of Dyson Sphere Program, Satisfactory, and of course Factorio, I always thought we could draw a few parallels between organizing our services and organizing our factories in those games. I’ll be sure to check it out when the video is up. Anyway, it seems like the Discord enjoyed the talk.

A big thanks to the organizers and the volunteers. See you next year!