A comprehensive review of DevoxxFR 2024
Authors: Coraline Harlé, Loïc Le Bel, Paola Valdivia, SC., Arij SAKHRAOUI, William Montaz, Emmanuel Guérin, Arnaud Perin, Florian RICHE, Pierre Sudron, Marco Casadei, Vivek Claver and Jiawen ZHU.
Devoxx France’s 12th edition took place from April 17 to April 19 in Paris at the Palais des Congrès, Porte Maillot. This year, Devoxx France expanded with the addition of a new floor to accommodate more than 4,000 people per day. The conference is designed by and for developers, placing special emphasis on content — evidenced by an extensive agenda featuring over 300 speakers. Attending Devoxx France provides an excellent opportunity to network, stay abreast of the latest technologies, and engage in a vibrant community event.
Criteo Booth
This year at Devoxx 2024, we proudly represented Criteo with a dynamic booth and a team of passionate engineers ready to answer visitors’ technical questions. Our presence was marked by the enthusiasm and expertise of our team, who were ready to share knowledge and experience with the technology enthusiasts attending the event.
At the heart of our booth was a particular attraction: the incident management game crafted by one of our engineers. This captivating game drew the attention of many visitors, immersing them in a realistic simulation of technology incident management. Throughout the event, our team was engaged in sharing expertise on a wide range of topics, from algorithm optimization to implementing high-performance solutions.
Criteo R&D Speaker: Gilles Legoux — Cod == Doc
“If you are addicted to code, you will become addicted to docs!”. This is the declaration of Gilles, a Senior Software Engineer at Criteo R&D Paris. His assertion served as the central theme of his presentation, where he detailed the intricacies of technical documentation, emphasizing cost reduction and amplifying its influence. In his own words:
Programming and documenting are the same, understand better why.
You spend your time documenting yourself, also become a “10x tech writer”, revolutionize your tech projects: thanks to the horrible monster that you will learn to tame. But, for this, the tools and knowledge presented will be very useful to you, in order to unleash your ninja potential.
No more F.O.M.O. — Criteos takeaways
We deployed a large team to the DevoxxFR edition, and our Criteos were enthusiastic about sharing what they had learned and experienced from the three-day conference. Here’s a detailed review of Devoxx France 2024. Get your favorite beverage ready and immerse yourself in the reading.
Loïc Le Bel
It’s been quite some time since I had the opportunity to embody Criteo’s technical essence at our Devoxx booth. This experience always offers a delightful blend of exploration and enlightening discussions, providing a rare chance to spend an entire day with colleagues whom we seldom encounter in our daily responsibilities.
The event was truly a demonstration of ambition, as companies brought their best to the forefront. The impressive booths, complete with interactive setups and enticing prizes, created a dynamic atmosphere — a clear indication of an industry pushing its limits and striving for excellence to captivate potential clients. Our booth served as a hub for profound discussions and connections, attracting a substantial crowd that enabled us to engage in deeper conversations, share our enthusiasm for technology, and glean insights from others.
I engaged in an intriguing conversation with Patrick Merlin regarding the risks associated with the use of LLMs (large language models) and chatbots in banking environments. A recent incident occurred wherein a user successfully manipulated an online bank’s support AI into envisioning advantageous terms and conditions for his account, which they were then compelled to implement. Despite remarkable advancements in AI, it appears that human judgment is still indispensable when making final decisions!
Paola Valdivia
I attended my first Devoxx France, and I can say it was an incredible experience filled with engaging interactions and insightful presentations. The whole place had a friendly vibe, making it a perfect setting to connect with colleagues and learn from experts. Here are my takeaways from the talks I attended:
CSS renaît de ses cendres: (re)devenez copains avec votre feuille de style
By Yohan Lasorsa & Olivier Leplus
The first talk I attended was about CSS. If you’ve ever worked with CSS, you might have noticed that not all CSS features are universally supported across browsers, especially in the past (yes, I’m talking about you, Internet Explorer). During this talk, I discovered that since 2022, major browsers have committed to collaborate on specific focus areas to enhance interoperability. You can check the interop status and focus area in this dashboard: web-platform-tests dashboard . And, notably, accessibility is one of their top priorities. Following this, Yohan Lasorsa and Olivier Leplus shared their favorite latest CSS features. My top pick is the view transitions feature that allows implementing fade effects or smooth transitions between page elements, which can significantly enhance user experience. Warning: Use with caution! Overusing transitions can lead to a confusing user interface or even cause performance issues, potentially overwhelming or frustrating your users.
High-Speed DDD (revisited)
By Thomas Pierrain
Moving on to the realm of software architecture, Thomas Pierrain shared insights into “High-speed DDD”. He reminded us that Domain Driven Design (DDD) is not only an approach but also a toolbox. He began by addressing the common practice of adding new functionality atop existing features. This usually involves making code modifications by adding conditions here and there. We will surely finish the new feature quickly, Product will be happy, but we will end up with functional debt.
To counteract this, Thomas highlighted the DDD practice of clearly defining our contexts and implementing effective communication between them. He presented three survival architectural patterns for ensuring high-speed feature delivery while keeping Product happy, contexts well-defined, and our code clean: the hidden supportive context, umbilical ACL, and context extraction. Also, when thinking about these patterns in light of “You Aren’t Gonna Need It” (YAGNI), Thomas reminded us of Martin Fowler's explanation that Yagni “does not apply to the effort to make the software easier to modify.”
⚡Une application résiliente, dans un monde partiellement dégradé ⚡
By Pascal Martin
Continuing with the theme of system resilience, Pascal Martin reminds us that our apps cannot be resilient all the time but that we can increase our chances by following some advice. He quoted, “nines don’t matter if users aren’t happy“, highlighting the user-centric approach to resilience. And he reminded us to accept that “distributed systems are never “up”; they exist in a constant state of partially degraded service”. Pascal outlined several strategies to minimize risks, limit the blast radius, and mitigate the impacts of failures:
- Apply random jitter to distribute load (e.g., in cache TTLs, scheduled jobs, and token validity).
- Automatically deactivating costly functionalities during system degradation.
- Load-shedding techniques (intentionally dropping some requests to maintain app functionality for most users)
- Choose boring technology.
The best part was that the presentation included very cute pictures of his cat, which not only lightened the mood but also helped illustrate his point memorably.
SC.
At Criteo R&D, we have been participating in the “Advent of Code” challenge for a few years now. That’s why I was curious to know what Teiva has learned after nine years of facing the “Advent of Code” problems:
J’ai terminé les 9 Advents of Code : Leçons Apprises
By Teiva Harsanyi
LeetCode is usually only used for interview preparation, which makes it unappealing and not something people want to engage in when they’re not preparing for interviews.
AoC being a challenge at a specific time of the year makes it a fun event that fosters a sense of community.
Our speaker indicated the main things he learned while completing the Advent of Code challenges :
Graphs can be separated along two main properties:
- directed vs undirected
- cyclical vs acyclical
Algorithms depend on the type of graph. For example, a topological sort only works on DAG (Directed Acyclical Graph).
Due to the challenges, one ends up having huge sets of data for the second exercise of the day, our speaker needed to learn about Big O and optimization in order to have a program that would output the solution in an acceptable amount of time for a daily problem.
Different structures of data apply to each problem. For instance, using a Linked List in specific contexts is faster than using an Array due to how accessing memory works (the pattern of memory access is predictable hence it is faster)
YAGNI (“You Aren’t Gonna Need it”): don’t code more features than exactly what is needed.
Behavioral Testing: helps to avoid protracted test doubles, mocks, etc => “Test behavior, not an implementation”, this is especially useful because this is a daily challenge where writing a lot of verbose tests is too time-consuming, but it is still important to be able to assess that the code works as intended to debug it as quickly as possible.
Arij SAKHRAOUI
This was my first time participating in DevoxxFR and, more generally, my first time participating in a tech conference. I admit I did not think it would be this fun and enriching.
Starting with the booths, so many interesting companies were there, big and small, and people were willing to engage in exciting conversations and do live demos of their products. We especially enjoyed an encounter with a GitHub Engineer who showed us all the cool things that Copilot could do, such as add context by selecting files and adding them to the conversation so that it answers questions more correctly, understands multiple languages (Chinese, Arabic, Spanish, and so on), and many other cool features including the ones that are working in progress!
Then came the talks! The talks I attended focused on LLMs, from Retrieval Augmented Generation (RAG) to minimize hallucinations (and a hands-on using Langchain) and improving model performance in terms of security and privacy.
Sécurité du GenAI & des LLM: Une nouvelle ère d’Hacking éthique
By Katarzyna, Nicolas, Romain & Renan
The presentation was delivered by a team of researchers from Thales who discussed their approach to evaluating the security of LLMs through a creative red team/blue team simulation. Their goal was to explore potential vulnerabilities in the usage of LLMs.
While the talk did not delve deeply into technical specifics, it outlined various potential sources of compromise when deploying LLMs. In summary, the researchers explained that every input to an LLM could potentially be an attack vector. As a precaution, they restricted inputs to text only in their internal LLMs.
One notable example highlighted during the talk was the ability to craft a string that could bypass any protection built into the LLM model, such as crafting instructions to build a bomb.
The speakers provided comprehensive coverage without overwhelming us with details, resulting in an excellent overview!
William Montaz
Devoxx had two floors in the Palais des Congres this year full of talks; that was a lot! I managed to attend some of them, highlighting the one about the Apollo Guidance Computer (AGC).
L’AGC : retour sur l’ordinateur qui a amené l’humanité sur la Lune
By Olivier Poncet & Romain Berthon
It was about the computer shipped in the astronaut capsule during the Apollo mission to the moon, the AGC (Apollo Guidance Computer).
It was four times less powerful than a Nokia 3310 and hundreds of times bigger, but still, it was a huge accomplishment in terms of miniaturization: the first transistors were invented 15 years before and were as big as a small kitchen appliance, the ones in the AGC were already in the microscopic domain.
There were no polyvalent operating systems like the ones we use daily nowadays, but the AGC still had to launch a lot of different tasks (we could not really call them processes) and how those tasks would share the limited power. If tasks piled up, the astronauts would see a blinking red light in their control panel.
Talking of which… yes, very far from material design and user experience, the requirement was not to take too much place on a control board already filled with other buttons. And the result is not very appealing. A lot of effort was put into allowing errors and allowing the system to be as robust as possible and work in the most degraded ways. That effort paid off: during the moon landing, one captor led to scheduling a particular task a lot more than necessary, flooding the task queue, preventing the AGC from correcting the trajectory, and making the red button blink. They had to relaunch the AGC in a particular mode, and it made it nonresponsive for more than 30 sec, all that while the capsule was about to land on the mon; what a stress it must have been for the astronauts!
One thing that really sticks in my mind is how the programs were physically stored. We all have heard about tapes and even perforated cards, but they used something else. The speakers did not exactly explain why, but I guess that reading a tape was maybe too long, and the size of the program would not fit in erasable memory. So they used ferrite torus with wires going through. To optimize space, the ferrite torus could be reused many times (up to forty times), and all that was crafted by hand. Think about that next time you debug your program step by step 😅
Emmanuel Guérin
This year was my second time participating at Devoxx France, and I’m pretty pleased with my time there.
First, the venue. It is the same (Palais des Congrès in Paris) as a year ago, but the organizing team could open a second floor for this edition, and this made a huge difference. Even though there were a lot of visitors, it felt quite a bit roomier and less crowded. The short break between sessions was also slightly lengthened, giving a bit more time for going from one room to the next and making the overall experience more pleasant.
I attended quite a few talks and had a hard time picking out favorites, as many of them brought a few insights or discoveries that were worth the time invested. I was also pretty happy to see quite a few of them featured examples in Kotlin (a language I became really fond of in the last few years), even when the topic was not directly about it.
Model Mitosis : ne plus se tromper entre les microservices et le monolithe
By Julien Topcu & Josian Chevalier
Special kudos to Julien and Josian for their architecture talk, Model Mitosis. A live example of code refactoring and clever use of humor helped me understand how to detect that a particular project becomes too large. After a short debate, the duo went on to demonstrate how it can progressively be separated into individual modules that provide better modularity.
Cloud Native apps with Micronaut 4 and GraalVM
By Cédric Champeau & Graeme Rocher
I also followed the deep dive on Micronaut, which was presented by Cédric and Graeme (the creator). Micronaut is a Java development framework focusing on performance and developer friendliness. It can be used to develop various projects, from microservices to command-line interfaces. One of its design principles is to do as much work as possible at build time. For example, its powerful dependency injection system is designed for compile-time resolution. When combined with the possibility to build a native executable with GraalVM, service startup times can go down to milliseconds.
Programming’s Greatest Mistakes
By Mark Rendle
On the fun side, Mark gave a hilarious account of 60 years of programming mistakes and their costs.
Arnaud Perin
After many prior participation in Devoxx France, I was excited to return to this conference. Indeed, I remembered the diverse content, the excellent organization, and the global energy. And I was not deceived this year! The particularity this year was that I moved from developer to engineering manager since the last participation, and my focus has slightly moved away from pure development considerations.
I attended for three days. First feedback: AI was everywhere! Many talks were about its societal impact, use cases, ecosystem decryption, or live demos. It started with an excellent keynote from Jean-Emmanuel Bibault about AI in medicine, and I encourage you to read Florian Riche’s notes about it.
I learned more about the fundamentals of LLM and RAG with Arnaud Pichery and Aurelien Coquard from Dataiku on what happens behind the scenes. Finally, the talk asking the question of whether developers would be replaced by AI by Matthieu Vincent and Yann Gloriau, both tech veterans, detailed with a lot of fun that AI is an excellent tool for pairing, nothing more (at least today!).
Moving to architecture and design, Cyril Martraire reminded us of the 15 years of software craftsmanship, the evolution of the methodologies, the importance of remaining agile in its simplest form, and always valuing team benefits over the tooling. As usual, his talk was objective.
I also followed the presentation made by Damien Lucas about different documentation templates. Different templates here, and particularly Arc42, to organize architecture diagrams, ADRs, specifications, and different views.
Florian RICHE
This year marked my first attendance at DEVOXX, and I was there for just one day. It was my first conference in many years, and I was impressed by the organization. Despite the large number of attendees and the event’s vast scale, everything ran smoothly — from the signage directing us to different sessions and keynotes to the logistics of lunch and other activities.
The competition to draw attendees to the booths was lively and engaging, with companies employing various strategies to attract interest. For example, Thales hosted an interactive Overboard game at their booth, which was a particular highlight.
Additionally, booths set up by various associations, such as those dedicated to retro-computing, showcased the depth of passion among conference participants. These associations not only provided a nostalgic glimpse into the history of computing but also emphasized the vibrant community spirit that permeates the tech world. The enthusiasm and knowledge exchange at these booths added a rich layer to the overall conference experience, reinforcing the diverse interests and expertise present in the tech community.
As others have mentioned, generative AI and its applications were the highlight of this edition. I understand that this was also a key theme last year, but it seems the field has evolved significantly. The sessions I attended focused more on the real-world implications of AI and strategies for its deployment rather than delving deeply into the technical aspects of implementation. The discussions centered on practical use cases for AI and the challenges involved in deploying these technologies. As is often the case, the human element presents the greatest limitation, whether it concerns mitigating risks from malicious actors or optimizing the models’ usage.
Keynote: Status of AI in medicine
By Jean-Emmanuel Bibault
The speaker, an oncologist, and AI researcher had a notably impressive resume, underscoring the caliber of speakers at the conference. During his presentation, he provided an overview of AI’s achievements in medicine without delving deeply into the technical specifics of machine learning. This approach surprised me, as I hadn’t expected the audience to be so familiar with the topic. It seems that the numerous promises of machine learning have made it a must-know for all engineers. Alternatively, it could be that machine learning has become ubiquitous, now a standard part of every tech stack.
While I can’t detail all the examples he provided, he discussed how AI is already capable of analyzing radiological images, preparing radiotherapy configurations, and predicting ten-year life expectancy. He also noted that with just a smartphone app, it’s possible to take pictures of the skin and obtain diagnostic results that could potentially replace traditional dermatological assessments. He mentioned that a large language model (LLM) has proven to be a more accurate diagnostician than the average physician, achieving approximately 70% accuracy compared to physicians’ 50%.
The speaker then posed a question about the future role of physicians. He predicted that their work would evolve to become less technical and more focused on compassion. However, he acknowledged that there’s still a long way to go, as LLMs are currently perceived as more empathetic than many physicians.
After outlining the potential of these technologies, the speaker discussed the barriers to transferring them from the lab to real-world applications. The primary concerns involve the security risks associated with the models used. We’ve already seen instances where hospitals have been hacked in recent months. An attacker could potentially hack into a system and tamper with the models or their inputs, leading to dire consequences. This represents a significant risk of relying too heavily on models, and it underscores why human oversight remains essential.
Another risk is the potential degradation of physicians’ skills, as reliance on technology might reduce the need for them to perform certain tasks regularly. One proposed mitigation strategy is to periodically require physicians to manually perform these tasks to maintain their expertise. However, the optimal approach remains a topic of debate.
The keynote concluded with a question-and-answer session, where the audience posed thoughtful questions, once again demonstrating their high level of expertise. One notable question concerned whether insurance companies would be able to access model results to adjust their pricing. The speaker indicated that this would likely not be the case, especially in Europe.
Du Clic à la Conversation : remplaçons boutons et formulaires par un LLM!
By Marie-Alice Blete
The presentation aimed to explore whether it was possible to replace traditional forms with LLMs integrated via an API. The speaker, an author of a book on developing applications using LLMs, suggested that LLMs could revolutionize human-machine interfaces, akin to the introduction of the mouse.
The bulk of the talk featured a comprehensive demonstration of using LLMs to substitute for a form. The author employed three approaches:
- A ‘naive’ use of LLMs, simply responding to prompts.
- An LLM functioning as a ‘state machine,’ where the prompt changes based on the current status.
- An LLM acting as an ‘agent.’
The speaker conducted tests with both OpenAI’s GPT-3.5 and GPT-4, highlighting significant differences between the two models.
The key takeaway from this session is the non-deterministic nature of LLMs, meaning they cannot always guarantee precise outcomes. This lack of certainty is critical, particularly in scenarios requiring 100% accuracy, such as form submissions and registrations.
Despite these challenges, the speaker remained optimistic about future advancements, suggesting that techniques to enhance the robustness of these systems are on the horizon, though yet to be realized.
Pierre Sudron
Good vibes at Devoxx France this year. I was pretty busy at the booth, so I only went to see one presentation. I guess it’s going to be an easy pick, right?
Without further ado, here is my writeup of the best talk I attended at DevoXX 2024!
Make your own virtual machine with Just-In-Time compilation! (for dummies)
By Olivier Poncet
Compilers and VMs are an old pet peeve of mine, and with this talk, Olivier gave an enticing premise: can we really showcase a fully operational JIT runtime in under 40 minutes? Without LLVM or any library to help out? I was curious to find out how he would make it.
But why does any of this matter? What is JIT, and why does it matter? Well, JIT, or Just-In-Time compilation, is basically steroids for interpreted languages. It is basically what made Javascript into the powerhouse we know today. It is what makes virtual machines (JVMs, .NET, and so many others) sing!
The idea is quite simple:
- You have source code; you can transform its tokens into a simpler grammar designed to be executed by another program.
- We call this type of grammar a bytecode, because it decomposes the program into basic instruction, and each instruction starts with a byte-long “opcode” describing the kind of instruction. This grammar is portable, but you need a program to execute it.
- The program executing the bytecode is called a virtual machine. Deep down, it probably looks like a BIG
switchstatement, mapping opcodes with the desired behavior. - If you stare at it long enough, you’ll notice that the bytecode is actually pretty close to the assembly language that your computer understands.
- Just-In-Time compilation makes this translation on the fly, turning the most-used parts of the bytecode into real assembly.
- While keeping portability, JIT brings interpreted languages closer to their fully compiled counterparts and even gives opportunities for novel context-aware optimizations!
Olivier shared his recipe in about 40 frantic minutes. His secret sauce? Start with the simplest language you can think of, a calculator. It is not even Turing-complete (ie. you cannot build any algorithm with it, just do some basic arithmetic), but it does not matter to demonstrate what JIT is about.
1 1 +The simple grammar gets us quickly through parsing and building the bytecode. We’re half way through the allotted time, will it be enough for Olivier to get us there?
OP_I64 1
OP_I64 1
OP_ADD 1Next, we get a glimpse of what computers really understand: assembly language (or symbolic machine code, if you wish to sound pedantic). Olivier outlines the similarities between the bytecode he designed and assembly: we can trivially morph the former into the latter! Only a couple of minutes until the end of the presentation, and I’m at the edge of my seat.
mov rax, 1
mov rdi, 1
add rax, rdxThe final twist in our journey! Put our crafted assembly into an executable buffer and make it accessible to our VM by conforming to the C-ABI. This gives us a pointer to our compiled code that we can use as if it were any other function!
And with just a few moments remaining, Olivier wings it! Before our bewildered eyes, we see JIT happening:
- Arithmetic expression gets turned into bytecode.
- Bytecode is turned into machine code.
- Machine code is executed.
- The machine code is re-used if we need to call the same expression again!
1 + 1 = 2. As Bertrand Russell famously put it: «[this] proposition is occasionally useful.»
Good job, Olivier! If you want to know more, check the following resources:
- Source code of the interpreter (c++ ahoy!): Olivier PONCET / rpn-calculator-with-jit · GitLab
- Slides for the presentation (in french, s’il vous plait): Olivier PONCET / creer-sa-propre-vm-avec-compilation-jit-pour-les-nuls · GitLab
- There is a TON of literature on the subject, but if you’re willing to learn more − as a hobby or side project − I can’t give enough praise to Robert Nystrom’s gentle introduction to crafting interpreters (which, incidentally, does NOT cover just-in-time compilation): Crafting Interpreters − it has a free online version.
Marco Casadei
During Devoxx France 2024, I had the opportunity to engage with people at Criteo’s booth and attended some talks.
At the booth, I was able to talk with about a couple dozen people, and it was quite interesting to see the variety of reasons why people stopped at our stand. I always made sure that people understand what we do and why we do it before showcasing all the technologies and staggering stats that we have (e.g., number of clients, daily ads that we serve, size of our Hadoop cluster, etc.). Pretty much everyone was surprised by the scale and complexity of our technical solution after hearing these details, which made me realize that what we do is still very impressive within our industry, especially for France and even Europe, I would say.
From the talks, I would like to highlight two of them:
Les équipes distribuées, ça peut marcher?
By Bertrand Delacrétaz
The first one is Les équipes distribuées, ça peut marcher? by Bertrand Delacrétaz. He has a lot of experience in the open-source world, having worked within teams composed of people in different timezones, languages, cultures, and habits without an actual chef.
He explained how such an organization can work based on the principle of Asynchronous Decision Making. He described this pattern, which follows these steps:
- Brainstorm: The first part of each problem-solving technique should be based on formulating as many ideas as possible. Such an activity benefits a lot from having a heterogeneous group of people, as there will be several points of view and approaches.
- Define a few options: Coming up with a limited set of feasible options is necessary to make a choice. The number should be relatively small (between 3 and 7, according to the problem), as a big choice can reduce the focus and increase the risk of overchoice.
- Find a consensus: At this point, there can be some debates used to determine the best choice among the available ones. If the majority of participants agree on a single option, a consensus is found.
- Make a decision: In any case, a decision must ultimately be made. In case a consensus is not found, there needs to be a mechanism that prevents a deadlock, and several alternatives can be used (e.g. voting by main stakeholders).
This process requires effective tools to be maintained, and in this case, the presenter mentioned two particular ones:
- Shared communication channel: needed by the team members to stay up to date and be able to see everything that is being discussed. Public Slack channels fit this needs, but the speaker preferred the use of Mailing Lists, with a clear semantic tagging system used to help people easily differentiate between topics (for example, the message title could look something like this “[R&D][ElasticSearch][Migration] …”).
- Ticket/document system to manage the decision process: No particular mention of a tool, but what we use in Criteo (JIA) seems to correspond to this need. It is very important to be clear and concise in this written form of communication, which can quickly become overwhelming given the size of most organizations.
This is the main gist of the presentation, which presents other elements to keep in mind about distributed teams, like the difficulty of having to deal with different cultures (whose differences can go way beyond the language barrier), as well as the hidden cost of meetings, especially when a consequent number of participants is invited and involved.
Overall, this was an interesting presentation of an alternative way of dealing with a very relevant problem at Criteo.
Beyond Estimates
By Woody Zuill
This was a deep-dive, three-hour presentation in which Woody raised questions concerning the use and abuse of estimations within the word of software engineers.
The main argument of his thesis is that estimates in our domain are not needed to accomplish a good job (which can be traced back to writing good software), and we can instead use the main principles provided by Agile and Lean software development processes.
Here are the main points of the presentation:
- What exactly is an estimate? Several definitions somehow valid or related to this notion can be used to convey its meaning (guess, prediction, cost, dream, wish, …), but we used the following definition:
- The difference between asking for an estimate (usually done by managers), making an estimate (which is usually done by developers), and using an estimate (can be done by both devs and managers).
- The main objective of an estimate should be to make a decision about something to help with planning, prioritizing, and scheduling. However, and this is the next point…
- (Software) Estimates are HARD to make and very imprecise by nature, even by experienced people. We did an exercise during the conference, estimating the duration of a seemingly easy task (draw a tic-tac-toe grid, fill it with numbers 1–9, and get it validated by another person in the room). The estimates were somehow off, but we repeated the exercise with additional constraints, updating the predictions, which became increasingly imprecise.
- Why are we using estimates to make decisions if they are imprecise and often not very reliable? Is it worth making a choice based on unreliable statements (e.g. if you use estimates to choose between alternative projects based on their presumed value/cost ratio, imprecise estimates can alter this factor quite a lot, changing the relative priority of the alternatives).
The alternative he proposes consists of using a quick iterative cycle to do software development, allowing developers to quickly deploy part of a solution and get prompt feedback on its use/value/client perception. This allows us to be flexible and capable of shifting priorities when needed. Basically, it is a diluted and simplified way of doing Agile process development.
The important part here is finding the right part of the project to start working on, and he argues that usually completing part of an original specification often allows one to get most of the benefit from it without having to deliver the whole initial plan. He calls it the 80/20 80/20 rule (double Pareto).
I do not necessarily agree with the fact that his process is the most appropriate for every software development. Still, it has the merit of asking pertinent questions about a tool (estimates) that we all use at some point.
Vivek Claver
This was the first time I attended Devoxx — the first time I attended any tech conference, in fact! Over these three days, I attended many talks on various topics, but AI was everywhere.
The AI Hype
And by AI, I mean Large Language Models, aka LLMs. The first keynote was about AI in the medical field, and other keynotes also often indirectly referred to AI, such as a keynote about the future geopolitical consequences of the struggle over rare metals (which are used to create hardware, such as the GPUs on which AI models are trained). However, the weight of AI was most felt at the talks and workshops. I would estimate that a solid 1/3rd of them were on that topic. More specifically, there was a great focus on using LLMs to create Retrieval Augmented Search or RAGs.
The idea behind RAGs is to leverage LLMs to improve the way you search for information contained in an “information database”, both in the efficiency of search and quality of search results, but also in the way the search output is formatted. Basically, imagine ChatGPT using your own data. The value proposition is clear: it greatly increases the efficiency of finding information in a large organization. I think we have all suffered when trying to find an obscure confluence page you remember exists and contains the information you’re looking for, but you forgot where it’s located (and good luck finding it with Confluence search!) The idea of having a chatbot who could serve you this information sounds fantastic (and whoever figures out how to do this well first has a good chance of ending up on the Forbes billionaire list).
RAGs work by treating the LLM as a black box. After all, it’s hard to train an LLM — you need a team of highly skilled engineers and a few million euros to spare. However, using an LLM is easy: just download it or connect to an API serving the model. Over the past year, there has been a huge increase in the availability of LLMs, both open-source and pay-per-request. The downside of these publicly available LLMs is that they’re not trained on your own “information database”.
The trick behind RAGs is two-fold: first, they calculate embeddings of the documents (or snippets of documents) of your own “information database”. Embeddings are a vector representation of your documents and can be thought of as a set of numbers that characterize the semantic content of your document. These embeddings are themselves obtained through the use of LLMs. Then, whenever a user enters a query, the query also gets translated into an embedding. Finally, the query’s embedding is compared to the document embeddings, and the closest document embeddings are marked as “probably containing the answer”. Finally, a special query is constructed by copying and pasting the contents of these selected documents, and a prompt for the form “find the answer to [user’s original query] in the following documents” is constructed. This final prompt is piped into a chatbot-like LLM to yield the final answer.
The concept is (relatively) simple, but the implementation is tricky. The contents of the various conferences & workshops about RAGs were the presentation of tools and frameworks to implement the RAG concept, using different tricks to build the final prompt to feed into the LLM — essentially automating the new (and soon dead?) field of prompt engineering. I was amazed by how developed the ecosystem already is and how easy it is to build a custom RAG using a library such as LangChain in a very short amount of time. The field is rapidly evolving, and if one thing is for sure, it is that next year’s RAGs will make this year’s look primitive and clunky.
Le Grand Braquage: Hacker une machine pour ensuite mieux défendre
By Adam Bertrand
I really enjoyed this three-hour workshop. It was a pen-testing hands-on lab, where, after a brief overview of various hacking techniques, you had to hack into a fake website to find hidden text files. This kind of event is called: “capture the flag”. It was my first time, and not only did I learn a lot, but it was also entertaining. I personally think it would be great to organize such pen-testing hackathons at Criteo, as it serves the dual purpose of sensitizing engineers to common vulnerabilities as well as helping to uncover vulnerabilities in Criteo’s services.
Sense of Community
It was amusing to see all the different companies represented by people wearing their company’s swag: it made you aware of the different “tribes” of the software engineering world. A person who entered the workforce during the tumultuous Covid years has perhaps never realized that he is part of a broader community of like-minded software engineers. This is why I think sending junior engineers to tech conferences such as Devoxx is vital to make them aware of the broader community and culture they belong to.
Jiawen ZHU
I had an amazing time at Devoxx France, my first tech conference. The venue had a cool vibe, and seeing all the different booths featuring the latest tech and innovations was awesome. I enjoyed networking and chatting with folks at Criteo’s booth and visiting other company booths. It was a fantastic opportunity to connect and learn from industry professionals.
In the midst of exploring the booths and networking, I managed to catch a few talks that provided valuable insights and knowledge.
Instrumenter vos applications natives Spring Boot et Quarkus avec OpenTelemetry
By Sandra, Bruno, and Jean
One insight session is Instrumenter vos applications natives Spring Boot et Quarkus avec OpenTelemetry. The blend of explanations and live coding was helpful in understanding how to enable OpenTelemetry features for GraalVM native images on Azure.
Elasticsearch data streams, un condensé de bonnes pratiques pour vos données temporelles
By Maxime Odye
Another interesting topic is Elasticsearch data streams, un condensé de bonnes pratiques pour vos données temporelles. Managing daily indexing for large amounts of data can be tricky, but Elastic’s APIs make it simpler. They offer tools like reindexing and lifecycle policies to streamline cluster operations. Plus, with features like datastreams introduced in 7.9, centralizing best practices is even easier. I’m excited to start implementing what I’ve learned.
Have you been able to read until the end? 😅Thank you! Now you’ve got a pretty good overview of Devoxx France’s latest edition. We encourage you to check all the videos on their YouTube Channel.
However, this review wouldn’t be complete without mentioning the new live transcription system that provided subtitles for all talks during the three days of the conference. It did generate a few memorable confusions and jokes that you should be able to discover in the episode of the Cast Codeurs (in French 🇫🇷) that was recorded, as is traditional, at the end of the conference.
See you at Devoxx France 2025! 🚀
