Laurent Kloetzer's blog

Author: Laurent

  • Imagination as the recomposition of reality

    Image by irenhorrors on deviantArt.

    (this post is the sequel of that one, please read it before to get the context)

    The house with the chicken feet is an image associated with Russian fairy tales and the witch Baba Yaga. It’s an image I really like, and my co-author and I used it in one of our fantasy novels (it’s the house of the faceless witch). We took it from the stories of Fritz Leiber, who took it from Russian fairy tales, or perhaps from the prologue to Ruslan and Ludmila, by Pushkin.
    Which brings us back to Russia, the home of Lev Vygotsky, one of the great thinkers in psychology and one of the great theoretical resources of L.L. Kloetzer’s other L. (aside: Vygotsky is a kind of rock-star scientist, who took advantage of the Bolshevik revolution to think and innovate in many fields and died tragically at the age of 37, at the start of Stalinism).

    Lev Semyonovich Vygotsky


    Vygotsky was interested in imagination as a relation to experience. (Please beware: Laurent is the one doing the explaining here – anything that isn’t true is my own). The house with the chicken feet (which he cites as an example) illustrates the fact that our imagination works by recombining images from reality. Our capacity for imagination, he says, depends on our experiences.

    But these experiences don’t have to be direct (having seen a hut, a chicken, and pasted them together). They can also be based on experiences passed on by culture, the imaginations of others (Fritz Leiber’s or Russian storytellers), and in this way, imagination is based on experience, which is based… on imagination. But an imagination crystallised in a cultural product.

    Our small study enabled us to look at the ‘how’ of this process of composing experience in an exercise in imagining the future. By focusing on a particular exercise (imagining a future within a given timeframe, about a given place), we were able to work on a collection of similar narratives dealing with the same imaginative constraints.
    From our corpus of 88 positive and 88 negative narratives, we found recombining elements of biographical origin, fictional elements and elements linked to the ZeitGeist, current events, illustrating Vygotsky’s theory on the different experiential sources of imagination: the person’s historical experience, immediate experience and cultural experiences.
    Cool, isn’t it?

    Of course, our audience is very small – students from a small, wealthy country are not representative of anything other than themselves – but our process, our ‘telescope to the future’, enabled us to illustrate in a vivid way the very social, anchored and marvellous way in which our imagination works.
    In another article, I could talk about the difficulties of imagining a positive future.

    Another house with chicken feet, illustration of an old edition of Ruslan & Ludmila

  • Publishing a text for a contemporary art exhibition

    One of the advantages of having already published in a field is that you may receive interesting offers. For example, creating a science fiction short story for a book associated with a contemporary art exhibition.

    The MUDAC (Musée cantonal de design et d’arts appliqués contemporains) is one of Lausanne’s cultural institutions. It used to be housed in a big house next to the cathedral, but for the past few years it has settled in a rather attractive concrete cube on the concrete-concrete site of Platforme 10, just next to themain station.

    This year the museum is hosting the Solar Biennial, an exhibition organised as part of the Solar Movement, an initiative to promote the artistic and design aspects of solar-related technologies. As the MUDAC has a small publishing department, the curators proposed to accompany the exhibition with the publication of a collection of science fiction short stories by international authors on the theme of solar energy and the sun. As this collection was coordinated by the publisher La Volte, my co-author and I were asked to submit a text.

    The request was for a text about a positive future, linked to the theme of the sun. SF writers are often asked to write about happy futures in these complicated times, because the future we’re facing isn’t very bright. It’s not an easy exercise: it’s easier to talk about our fears and what scares us.

    The result of our work is a text entitled ‘Le champ de la Mi-été’, which is now in a book alongside prestigious neighbours such as Nnedi Okorafor, luvan, Sabrina Calvo, Michael Roch… Our participation in this collection also enabled us to be invited to the opening of the exhibition.

    An exhibition opening in the Museum of Contemporary Art of the fourth largest city in Switzerland (a small city by European standards) is not exactly my usual milieu. So who comes? Basically people from the cultural bourgeoisie. Artists of all kinds, university professors, quite a few young, fluid people and some well-dressed older ones. I’d put on my best hat.

    The opening began with a talk by the Dutch women behind the Solar Biennale, which had already taken place in Rotterdam. The speech was in international English, and as I was quite far behind, I didn’t understand a word of it.

    Then Scott Longfellow (curator of the exhibition with Rafaël Santianez) gave four talks in French by people involved in the exhibition.

    First of all, Professor Christophe Ballif from EPFL, a specialist in solar panels at the Neuchâtel Institute of Microtechnology. He’s a huge fan of solar panel technology. He says that we’ll be able to produce just about all the energy humanity needs with this technology, that China is way ahead in this field, and that we’ll find the materials we need to do it. (I’m summarising with a hammer)

    Then there’s the great solar lab duo https://mudac.ch/designers/solar-lab/ / Studio Lemercier, whose exhibition showcases their DIY solar projects and their desire to create imaginary worlds that are at once technical, poetic and beautiful, spurred on by the opening of the world’s largest open-cast brown coal mine, in Germany, not far from where they live.

    Then there was Professor Marilyne Andersen from the EPFL again (this institution is everywhere in Switzerland) https://people.epfl.ch/marilyne.andersen?lang=en who talked about those receptors at the back of the eye that aren’t used to see, but just to adjust our circadian rhythms, and about the fact that, indoors in the city, we had 100 times less light than outdoors (even if the brain is good at making us believe the opposite). All this is to introduce the cool installation in the exhibition: the Cantonal Office of Daylight, a fictional administration that ensures that everyone has access to the daylight they need.

    IMG_0268.jpg

    And finally, the dancer Rocio Berenguer https://rocioberenguer.com/info.php who talked about interspecies dance (with weeds) and issued a joyous bad weeds manifesto (you can see her/their work on video in the exhibition).

    IMG_0259.jpg
    IMG_0260.jpg

    And finally, the exhibition opens.

    It’s very tech/design oriented, with a shift towards the imaginary and SF.

    Some of the highlights:

    • a time capsule that allows plants to travel into the future (it artificially creates the conditions for plants to grow where the glaciers have retreated – there are plants inside);
      IMG_0276.jpg IMG_0256.jpg IMG_0278.jpg
    • a sun-yurt lounge where you can read the book of SF short stories published to coincide with the exhibition
      IMG_0258.jpg
    • a screening of a film about giant-SF-machines, in which an artist imagines the huge machines that will be used to decarbonise the atmosphere;
      IMG_0265.jpgIMG_0266.jpg
      IMG_0277.jpg
    • the interior of a house where a designer has removed everything that wasn’t absolutely necessary (I forgot to take the photo), resulting in an über-Japanese interior;
    • full of solar crafts, HEAD creations, magazine covers on the theme of the sun, and an open skylight in the ceiling so that, yeah, the sun can come into this room.
      IMG_0262.jpg
      IMG_0255.jpg

    Afterwards, there was a lot of official blah-blah, followed by plenty of red and white wine and boxer beer, and apple juice for those of you in a sober period. And then I left, because it had been a long day.

    End of transmissions, come and visit the exhibition if you get the chance, it’s well worth it!

    IMG_0254.jpg
    IMG_0279.jpg

  • Integrating systems

    I’d like to put together a few notes on the subject of integration between systems (one system talks to another). This is a very well-trodden path in our field and I run the risk of saying some obvious things.


    The team I work with at SECUTIX deals with integrations between our in-house applications and “the rest of the world”, for example ERPs, CRMs, accounting systems, resellers, institutional sites, data analysis systems, etc. There are two ways to build those integrations:

    1. By deploying public APIs that other systems can consume, essentially endpoints and webhooks, which are documented here: https://platform.secutix.com
    2. By (rarely) building connectors, deployed in the company’s applications, which call third-party public APIs.

    Public APIs

    What are we talking about when we say ‘public APIs’?
    Of course, our applications are modular and expose all sorts of internal webservices that are called from one brick to another. These APIs are more or less standardised and bear the mark of the evolutionary history of our systems. (a jolly phrase to say that we have tons of technical debts)

    In what follows, when we talk about public APIs, we mean that the API:

    • is accessible from outside our systems
    • has a documented contract, in whatever form, that is publicly accessible,
    • has textual documentation describing use cases, authentication protocols, etc.

    These public APIs can take various forms:

    • Webservices
    • Webhooks
    • SSO integrations
    • Widgets
    • Exchanged flat files
    • etc.

    Connectors

    Connectors are components deployed as part of our internal applications. They have access to the application’s internal resources (database, internal webservices) and can connect to the application’s external resources.
    The development pattern for a connector is always the same and generally comprises three building blocks, whose names we try to standardise:

    • the connector: a class that encapsulates all the plumbing for communicating with the external system. (Yes, I know, it’s the same name as the concept above – I don’t have so many names in my “names pool”). The connector, in Java, exposes an interface taking as parameters only the DTOs exposed by the remote system.
    • the transformer: a class responsible for transforming our internal DTOs into external DTOs or vice versa
    • the processor: this orchestrates the calls to the connector and the transformer, depending on the needs of the integration.

    In IT, we generally read data from A, transform it and store it or send it to B. You wonder why some people think this job is complicated.

    In one or more future posts, I’ll expand a little on the question of public APIs and connectors.

  • Extreme Carpaccio

    I’m continuing with the theme of cool activities with my excellent colleagues in Granada, in addition to our classics like playing board games and going out to eat together in good restaurants.
    The time before last, I suggested a coding game.

    On the advice of my friend @riduidel/Nicolas Delsaux, and because I’m not familiar with this sort of thing, I chose the extreme carpaccio game.
    You can find all the details here:
    https://github.com/dlresende/extreme-carpaccio

    I’d encourage you to read the description of the game, at least from the players’ point of view, if you intend to play it. When I say ‘play’, yes, it sounds like a kind of TTRPG with code. It’s a fun, competitive game in which several teams compete by delivering code and trying to score points.


    That day, five developers were present, plus the monitoring supervisor, the quality supervisor, a PO and the support supervisor. I asked them to get together in 4 groups (3 groups of two, one group of three), each containing at least one dev, the other being a ‘manager’. Each group represents a small IT company to which the Big Client (me) orders an e-commerce system.


    The game is available on the github repo above and is very well done. The GM deploys a server that sends orders to the players’ systems. The players have to accept the commands, do a little calculation on them according to the specs and send back the result of the calculation. If they get it right, they score the amount of the order in points. If it’s wrong, they lose half the amount in points. If the answer is 404, no gain, no loss.

    We were in a large room, reserved for two hours. With the result, in points, displayed on a big screen.
    The game is very well prepared. If you’re planning to run it, allow one or two hours for preparation at home, just long enough to master the technical tools (the only thing I missed was knowing that a NodeJs app deploys by default on port 3000), plus half an hour at the game venue to test the network config (basically, deploy the server on one machine, the clients on another, play with ipConfig, and check that it’s working).

    First thing’s first, it’s great fun. If you’re feeling a bit like a storyteller, this is for you. You can play characters, do big voices, bang on the table, wave your arms… And the players can play the smooth-talking manager who appeases the customer, make impossible promises and so on. It’s a great way to let off steam and have a good laugh. The screen that displays the points immediately shows whether it’s working or not. I’d set up 10-minute ‘sprints’, so that I could count the time in the game (‘at what sprint are you going to deliver in production?’), which isn’t included in the scenario.

    All the teams delivered, delivered late and lost points before recovering them.
    At the end, we spent around twenty minutes debriefing. Each team will learn its own lessons (ours are below, beware of spoilers).
    I’d recommend this game, everyone had fun (devs and non-devs), we were really able to laugh about what sometimes makes us stressed and say things we wouldn’t have been able to say before.

    SPOILERS

    DON’T READ THIS BEFORE PLAYING THIS GAME

    • The code to write is simple, the specs are clear
    • but the stress, noise and pressure make many good practices go out the window
    • the ‘manager’ of each team has more or less played the role of intermediary with the Big Client (the GM, who scolds and grumbles)
    • obvious elements were ignored, resulting in lost points (return 404 when you don’t know where there is an error)
    • experienced devs have made rookie mistakes
    • no team wrote a single unit test. (some didn’t even realise that the proposed code skeleton contained tests) even though this is an established dev practice and the specs propose test data
    • everyone was psychologically fooled by the big time counter on the screen without realising that the division into ‘sprints’ was purely artificial and didn’t correspond to anything real.

    All this enabled us to see, outside the game, how the evolution of the open space (the team now works in a less quiet environment) and the more frequent interruptions linked to production (and to unplanned requests from management) have a major impact on quality and production, despite an increasingly experienced team.

  • Werewolves and silver bullets – reading together

    I’m the manager of a great team, based 1,588 km from where I work. I can see the Alps through my office windows, they’re in Andalusia and can see the Sierra Nevada. So I spend a lot of time chatting to them via Teams, a sad avatar of modernity. At least we talk to each other and see each other every day.

    Fortunately, once or twice a year we’re lucky enough to spend a week together. We then try to organise or create group activities, which take us out of the rhythm of sprints and deliveries.
    Last time, following my visit to Snowcamp where a speaker recommended it, we did an hour of collective reading of Brooks’ classic chapter, “No Silver Bullet: Essence and Accidents of Software Engineering” (1986). I wondered if this old text would speak to a team none of whose members were born when it was written (apart from me…).

    I was just discovering the text and found it incredible. Almost forty years old and still relevant reflections to answer the question: why is it so difficult to carry out IT development projects, and why is it that, while computers are becoming ever more powerful, IT projects are always lagging behind?


    The title compares a development project to a werewolf. Innocent at first glance, a project like any other, which sometimes, often, turns into an uncontrollable monster that eats up budgets and deadlines. And Brooks demonstrates that there is no silver bullet that can put an end to it.


    The text is short and dense, and I won’t insult you by summarising it. If you’re intrigued by the subject and don’t already know about it, read it.


    Collectively, here’s what we did: I asked those who wanted to to read the text in advance (everybody did). Then, on the same day, I gave a brief introduction to the author, werewolves and the question posed by the text. Then I asked the team members to identify the main ideas in the text, which we put together collectively, and we discussed some old points (time-sharing) and some more recent ones (AI & expert systems).

    Rather than listing our summary here, I’ll just quote a few extracts that I really liked.

    Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).


    I really like this idea of a human construct, so vast and complex that it has thousands of parts, all different.

    [Software] is pure thought-stuff, infinitely malleable

    There’s something that links my two great professional passions: writing novels and writing software. As a teenager, I loved touching my first word processor and discovering that I could change everything infinitely. In fact, I think the term ‘infinitely’ is a bit misleading. Eventually you get tired of changing everything and programmes, like novels, crystallise.

    Software is invisible and invisualizable

    This idea also makes you dizzy. Our team is responsible for half a million lines of code, it’s our domain. We have no way of seeing all the details at a glance. Even our diagrams and plans are only partial indications. We are responsible for a labyrinth in which we are constantly laying down guidelines for the programmers of the future who will pass through it.

    The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide_perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important.

    Very good vision of the impact of Copilot-like tools, even if Brookes didn’t anticipate the negative consequences…

    What would you recommend for future team reading? Extracts from Clean Code or Pragmatic Programmer? The passage from Jurassic Park describing the bug in the surveillance system? All ideas are welcome!

  • Instant Futures

    I’ve been publishing fiction professionally (that means getting paid for it) since 1997. But one of the informal goals I’ve set myself as an author is to try to publish texts in as wide a variety of media as possible. For example, I’ve published a role-playing scenario and two articles in the now defunct magazine Casus Belli, written a children’s text for Bayard Presse… and co-signed a scientific article this January.
    Like all self-respecting articles, it has a super duper long title:

    Instant Futures: an experimental study of the imagination of alternative near futures thanks to science fiction

    The title of the journal is Integrative Psychological and Behavioral Science and, unlike Casus Belli, I don’t regularly read it. But the other L. of L.L.Kloetzer, the one who does scientific research, knows it well.
    In this paper, we describe research carried out over the last five years during the Environmental Psychology course taught by L.K. (the other one) at the University of Neuchâtel. In this course, the teacher uses protokools from Zanzibar [fr] to get students thinking about the future.

    With the permission of the people involved, we studied the stories produced, which enabled us 1) to link the construction of the stories with the mechanisms of imagination described by Lev Vygotski, the coolest and most Marxist of psychology researchers.

    The protokool used is a ‘classic’ that we have played on many occasions with our zanzi-friends.

    In the first phase, people are asked to describe a familiar place in a future that they do not want to happen.


    In the second phase, they were asked to describe the same place in a future they thought desirable.


    We then asked ourselves what imaginary resources, whether personal, current affairs or fictional, were mobilised to construct these ‘snapshots of the future’ (I didn’t say it, but the students had 10 minutes each time to draw up their texts).

    To focus on fictional resources, we asked ourselves whether the stories produced in 1.1 were more ‘Wall-E’ (dead world, piles of rubbish), more ‘Mad Max’ (looters and violence), more ‘The Road’ (nuclear or climatic apocalypse), more ‘Brave New World’, and so on.
    Or if the stories produced in 1.2 (positive) were more like ‘Green World’ (that’s what I call the current minimalist ecological ideal: recycling, permaculture, short cycles, etc.), more like ‘Snow White’ (we live happily in the forest with the animals), more like ‘Nausicaa’ (hard-working, isolated country communities with a bit of tech), more like ‘Star Trek’ (super tech helps us overcome problems)…

    It was I (LK) who named the fictional categories, throw me some stones if you find them silly 😅.
    I’ll comment on the results of the study in a future post, but if you’re impatient, you can read the paper!

  • Snowcamp 2025 #4 Friday & remarks

    Friday 9am

    Keynote: Debug your salary! My winning strategies for successful salary negotiations, by Shirley Almosni Chiche (BUILD RH)
    A very good conference, funny, energetic, full of jokes of all kinds to make people laugh about a stressful subject: salary negotiation. Shirley presents a number of strategies for setting out your expectations (know how much you want, how much leeway you’re giving yourself and, in general, don’t feel pressured to justify your request) and counter-arguments to the elements usually given to justify a low offer (the salary scale, equity in the team, ‘we don’t have the finances’, you’re not at the level we expect…).
    The entire conference can be viewed here (presented at Devoxx):

    Friday 10am

    The Hive pattern: a modularisation strategy for your modular monolith or microservices. by Thomas Pierrain (Agicap) and Julien Topçu (Shodo)
    A talk on why you need to break down a big thing into smaller things that are easier to refactor, deploy and grow. A solid and entertaining presentation, very well delivered.
    The presentation is mainly aimed at consultants who need to structure ideas to convince a client to adopt a different system structure.
    Take-away
    No surprises for me, apart from the vocabulary. At SECUTIX we are well aware of the problems shown and have adopted a sort of Hive pattern without realising it, particularly in the Platform team. I’ve taken a few names from it to designate some of our practices (API, SPI, adapters, etc.).

    I had to leave after that meeting and could not attend the talks of the afternoon.

    Mixed notes

    I found the attitude of the people attending the conference very pleasant and not showy. Thank you to those with whom I was able to discuss our practices, team structure, deployment or quality processes, etc. The atmosphere was really pleasant.
    Three small notes in bulk:

    Thanks to Nicolas D for his interesting thoughts on the evolution of the market of IT Service in France, and on the role of the architect: someone capable of going from the cellar of the application to the floors and understanding what’s going on, and capable of communicating with customers and users, of understanding the market.
    Philippe Charrière, in addition to his thoughts on non-alcoholic gins, recommended that I see the interesting use of AI made by docker for technical support.
    Yu Ling Cheng encouraged me to take an interest in the Playwright testing framework (to do what we do with our old Selenium). Thanks to her also for the very interesting discussions on UX components and their interface, and on the automatic testability of front-end code.
    Finally, thanks to the organisers, the conference was a very pleasant experience, in good conditions. IT development is a very cool profession, and I’m happy to be able to practice it! It makes me want to propose a talk for next year

  • Snowcamp 2025 #3 Thursday afternoon

    Thursday 2pm

    10 useful web features you don’t know about, by Olivier Leplus (AWS) and Yohan Lasorsa (Microsoft)
    Interesting presentation on the evolution process of the javascrit language.
    As for the rest, I should have read the presentation better: the talk wasn’t for me.

    Thursday 3pm

    Defying entropy: rewriting applications or regaining control? Alexandre Jeambrun, Octo
    A very good talk on the classic theme of our field: should we rewrite? Spoiler: no, not really. We all have to work on old (legacy) systems that are still useful because they’re in production.
    Main ideas:
    There are three types of complexity: complexity of the business (there’s nothing we can do about it), complexity of the technological layer used (it’s there, it won’t be easy to replace, there’s barely nothing we can do about it), accidental complexity (bad practices resulting from the emergency code fixes, replicated bad design, etc.). We can do something about it).
    The entropy of systems is increasing, because people are changing, technology is changing, the environment is changing. No choice, it’s going to get more complex.


    Dealing with human change: delegate, give people autonomy and decision-making power over an area, give the people involved space to develop their skills, make the team resilient (turnover is a non-event, people WILL leave), give people interesting things to do.

    Coping with technological change: accepting that the design of the system must evolve continuously, that patterns will emerge from production. Have modular systems. Refactoring all the time, and delivering small increments in production.
    (I didn’t notice the slides on changes in the environment, other than that it was important to focus on the parts of the system that are differentiating in the economic environment in which it is evolving).
    My main takeaway is the need to read the article No Silver Bullet (1986, by Fred Brook).

    Thursday 4pm

    ‘34% of our employees are women, come and join us, we’ll do things for you’, Anaïs Moulin, from Onepoint
    A talk by a very young PO on positive discrimination policies in recruitment, placed in their historical context, and on their positive and negative effects as felt by those most affected. Feelings of injustice, imposter syndrome, etc.

    In particular, Anaïs encourages people to express their doubts and questions and to make these processes visible, for example by questioning HR departments directly about them, while hoping that these policies will disappear as a result of a future and hoped-for change in mentality, which will make them no longer necessary.

  • Snowcamp 2025 #2 Thursday morning

    Thursday, 9am

    Keynote: Anatomy of a Backdoor: XZ Utils. by Quentin Dunand and Wassim Ahmed-Belkacem, from Viseo
    Pure thriller entertainment. The story of the XY backdoor, its discovery and consequences (I knew the story well) and, above all, a technical presentation of the backdoor, how it works, how the code is obfuscated, which layers have been affected, and so on. Wassim went into great detail (pre-compilation, corruption of the makefile, injection of malicious code via the test files, etc.) in a very educational and comprehensive way. Very interesting.
    Take-away
    Sense of wonder.


    Thursday 10am

    Stories of vulnerabilities (Paul Molin, from Theodo)
    Paul is CISO at Theodo. This talk presented a number of security flaws in different systems (including an amusing story about how to send a letter free of charge in France by hacking the postal system), but above all stressed the importance of recounting flaws and challenges in order to create a culture (in this case, of security). Paul has also written a book called ‘Il était une faille’, with Marine du Mesnil.
    Take-away
    The importance of communicating, internally, the life of the company and the challenges it faces, in order to create a shared culture and a better understanding of the business and the issues involved.

    Thursday 11am

    High-performance testing thanks to a realistic dataset 🧪Martin Choraine, Hyperweb.
    A detailed and interesting talk on the datasets used to test applications. The importance of realistic data for testing your system.

    • for limit case testing (creation of valid and invalid data)
    • for non-regression
    • for load testing. (creation of a mass of consistent and realistic data)

    Reminder of the importance of anonymising data from production. (personal data, bank details)
    Martin spoke about his (fairly satisfactory) use of tools for generating test data (information about people, or bank details). He recommends Faker https://fakerjs.dev/
    Of course, he mentioned his rather satisfactory experience with data generated via LLMs, but is reluctant to use this technique on a massive scale. The future would some LLMs dedicated to a particular field.
    Take-away
    To generate a massive set of test data for one of our products based on production in order to validate performance.

    Thursday, noon

    Short talk: Let’s integrate young devs, help them grow and progress: Best practices and feedback for (old) devs. by Alexandre Touret, at Worldline
    A very important subject for me. Transforming an experienced dev into a mentor for younger people is neither easy nor straightforward. Not everyone knows how to mentor a junior dev.
    I’ve come away with a few ideas: the first few weeks are very important, and you need to optimise them. The mentor has to be very careful about his attitude and his interpersonal skills. They need to set aside time in their diary (30′, daily) for coaching. Practise peer programming with the junior (essential, for me: see how he/she clicks in the IDE…), base the construction of knowledge on real and immediate problems (empirical acquisition of knowledge). Start with simple, even very simple tasks. Use PR, JIRA, etc. for what they are: communication tools.
    Encourage young people to keep up to date, read articles and go to conferences. Remind them that this is part of their job.
    And get them to read Clean Code by Robert Martin (I agree).
    Take-away
    Get the team to read Clean Code.

  • Snowcamp 2025 #1 presentation and workshops

    In the next blog spots, I’ll share a recap of this technical conference.

    Snowcamp is a technical conference on IT development that has been held in Grenoble in winter for the past ten years. Most (if not all?) of the talks are in French.

    Snowcamp title


    It’s been a very long time since I’ve been to a conference like this: lack of time, urgent production work and, to some extent, family life. What prompted me to go? One of my Internet buddies, Nicolas Delsaux (senior dev at Zenika in Lille), with whom I share an interest in the profession and a taste for science fiction. ‘You should come to Snowcamp, it’s not far from where you live’. Thanks for the suggestion, mate!


    I spent three very cool days there, meeting interesting people and attending relevant talks that gave me ideas for my practice.


    Here’s a little recap: what I’m taking away from the conference, and how it could help me/us in my/our day-to-day work at SECUTIX.
    (no, I’m not shouting, our official typeface is in CapsLock mode)

    Context and organisation of the conference:

    Snowcamp takes place at Grenoble’s WTC, a convenient conference centre (located near the train station and right next to the hotel, 15′ from the city centre).

    The conference is organised as follows:
    Wednesday: universities. Two three-hour workshops, subject to prior registration.
    Thursday and Friday: in the morning, a full keynote, then two talks, a 1.5-hour lunch break on site (very good) and three other talks in the afternoon. A Meet & Greet on Thursday evening.
    Saturday: optional outing to the snow, skiing (not included in the conference price).

    Workshops

    Wednesday, 9.30am-12.30pm:
    Python royal, by Julien Lenormand and Jonathan Gaffiot, from Kaizen solutions.


    This was an excellent hands-on workshop, the aim of which was to present a suite of tools for industrial Python development. In the first hour, we installed the tools and created a very simple mini-application. Then you deploy and activate the code analysis tools, style checker, typing checker, test executions, packaging, and so on.
    For me, who has been in the java world for one or two millennia, this is like discovering the equivalent of IntelliJ (=PyCharm, JetBrains), maven (more or less UV), Sonar(Qube), CheckStyle, etc. in the python world.
    The keys to this python world are PyCharm and UV, an orchestrator that manages dependencies and environments (like maven, but more modern).
    The workshop was very well put together, and the presenters were very approachable, with a wealth of experience of python in production.
    Take-away
    My team has an internal API overlay project that needs to be written in Python. I’m going to explore the PyCharm+UV options with fastapi to develop them robustly.

    Wednesday 14h30-17h30
    You too can give style to your data with Grafana, by Thomas Jouve, from Sopra.
    Hands-on workshop on using Grafana and discovering its inner workings, its logic and its dashboard-building capabilities. It gave me the opportunity to configure things in Grafana for the first time.
    Take-away
    A little knowledge of Grafana and ideas for modifying our monitoring dashboards.