DEV Community: Georges Cubas

A Dockerfile that says where it failed: splitting the RUN and retrying pecl install

Georges Cubas — Wed, 21 Oct 2026 21:13:22 +0000

A CI build broken by a 504 from pecl.php.net, buried in 40 lines of &&

On 20 October 2026, the PHP security team announced two critical vulnerabilities. The announcement was of an unusual scale and got wide coverage (official websites taken offline as a precaution around the world, Cloudflare's reaction, OpenAI...). For us it had an unexpected effect. During the day, our application's builds started failing.

The failing build

I looked at my company's application Dockerfile. Its base stage starts from the official PHP image and installs the dependencies. About forty lines are grouped in a single RUN, chained with &&: apt packages, locale, PHP extensions, Composer installation, php.ini, PECL extensions.

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
    libfreetype-dev \
    libjpeg62-turbo-dev \
    libpng-dev \
    libxslt-dev \
    libz-dev \
    ...
    && pecl install redis \
    && pecl install ssh2-1.4 \
    && rm -rf /tmp/pear \
    && docker-php-ext-enable redis \
    && docker-php-ext-enable ssh2

Docker only showed this:

process "/bin/sh -c apt-get update && ..." did not complete successfully: exit code: 1

No indication of which command in the chain had failed. I first suspected a new Composer version. With a single RUN, there was no way to tell. I went to check: Composer had not released a new version, so the cause was elsewhere. We decided to split the RUN.

Splitting into several RUNs

Each RUN becomes a numbered step in docker build --progress=plain, for example [base 7/8] RUN pecl install .... It is cached independently of the others. The error points straight at the right block, with the Dockerfile line number.

I made six RUNs: packages, locale, PHP extensions, Composer, php.ini, PECL. A giant && blinds Docker because the unit of error is the instruction, not the command. (set -eux would have traced every command, but the build would have stayed a single block, with no intermediate cache.)

On the next build, the error was on the PECL installation:

buildx failed with: ERROR: failed to build: failed to solve: process "/bin/sh -c pecl install redis && pecl install ssh2-1.4 && rm -rf /tmp/pear && docker-php-ext-enable redis && docker-php-ext-enable ssh2" did not complete successfully: exit code: 1

That let me find this in the log, a bit higher up:

Could not download from "https://pecl.php.net/get/redis-6.3.0.tgz", cannot download "pecl/redis" (File https://pecl.php.net:443/get/redis-6.3.0.tgz not valid (received: HTTP/1.1 504 Gateway Timeout))

The problem wasn't in the code: pecl.php.net was overloaded. I assume the wave of updates that followed PHP's announcement saturated the server.

So our build wasn't broken by the vulnerability, which hadn't even been fixed yet. It was broken by everyone's reaction to the announcement of the fix.

Looking for a PECL mirror

Next I looked for a pecl.php.net mirror to use as a fallback. There is no official mirror you can use that way. The real alternatives are:

compile the extensions from the GitHub tarballs with phpize
use mlocati/docker-php-extension-installer
publish the base image to a registry so nothing gets downloaded at every deployment.

The last one is the cleanest, but it is a project of its own. Adding a tool while the build was broken seemed risky to me, so I went for the simplest option: repeated attempts.

The retry, in three versions

To keep it simple and change as little as possible, I first put both extensions in the same loop:

RUN for i in 1 2 3 4 5; do pecl install redis ssh2 && break; sleep 10; done

Testing the failure case, I saw this wasn't viable. If redis installs and ssh2 fails, the next attempt fails on redis with "already installed", which returns a non-zero exit code. The loop can never converge. It needs one loop per extension.

Second version, one loop per extension. If all five attempts fail, the for ends without a break and returns 0. The build then only fails at docker-php-ext-enable, with a message that has nothing to do with the problem. It needs a flag and an explicit exit 1.

Final version:

# pecl.php.net can answer 504 when overloaded: retry each extension separately
# (a combined install would fail on retry with "already installed"), then fail loudly.
RUN set -eu; \
    for ext in redis ssh2-1.4; do \
        ok=0; \
        for attempt in 1 2 3 4 5; do \
            if pecl install "$ext"; then ok=1; break; fi; \
            echo "pecl install $ext failed (attempt $attempt/5), retrying..." >&2; \
            sleep $((attempt * 10)); \
        done; \
        if [ "$ok" != 1 ]; then \
            echo "ERROR: pecl install $ext failed after 5 attempts" >&2; \
            exit 1; \
        fi; \
    done; \
    rm -rf /tmp/pear; \
    docker-php-ext-enable redis ssh2; \
    php --ri redis > /dev/null; \
    php --ri ssh2 > /dev/null

The wait grows with each attempt (10 s, 20 s, 30 s, 40 s, 50 s), 150 s in total for an extension that fails five times. The last sleep is useless, since it comes right before giving up. I left it in to avoid complicating the Dockerfile.

php --ri redis at the end of the block checks that the extension is really loaded. docker-php-ext-enable can succeed even though the extension doesn't load (a missing dependency, for example). In that case php --ri fails, and so does the build.

Testing the failure

The Dockerfile is multi-stage. The base stage installs the packages and the PHP extensions, and the following ones (Composer dependencies, front-end assets) build on it. So I only build base:

docker build --progress=plain --target base -f .docker/Dockerfile -t test .

To check the failure case, I temporarily replaced ssh2-1.4 with ssh2-9.9 (a version that doesn't exist) in a copy of the Dockerfile. The output:

pecl install ssh2-9.9 failed (attempt 5/5), retrying...
ERROR: pecl install ssh2-9.9 failed after 5 attempts

I haven't tested the retry against a real 504, only with a nonexistent version. A nonexistent version is a permanent error, whereas a 504 is temporary. This test shows that the failure does surface, not that the retry eventually succeeds.

What this changes

I'm keeping this solution. The separate RUNs tell me which step failed and benefit from the cache. The retry saves me from relaunching a build over a passing 504.

It doesn't solve the rest. pecl install redis without a version installs the latest one, so the build isn't reproducible. It still depends on a third-party server at every deployment, and it won't survive an outage of several hours. It's a modest improvement, suited to the incident I had.

The code I never wrote

Georges Cubas — Mon, 12 Oct 2026 07:27:29 +0000

At my company's annual seminar, my manager said AI wrote about 70% of the code. I replied that for me it was closer to 90%. The other developers agreed with me. Afterwards, they pointed out that it might not have been very wise to say it like that, and my manager and the director seemed surprised.

I thought about it afterwards. My number is an estimate based on my practice with Claude Code, I haven't measured anything. But more than that, we probably weren't talking about the same thing. I was talking about the code that ends up in the files. He was perhaps talking about the share of the development work that AI takes on.

That conversation made me realize that a percentage of code written means nothing until you say where you draw the line. And that line has already moved several times since I started programming.

Cut my teeth on an Amstrad

I'm not old enough to have known punch cards, but I started in the late 1980s on an Amstrad CPC 464. You switched the machine on and landed directly on the command prompt. You could type PRINT 1 and it answered. Programming was a normal experience, not a separate activity.

My father had computer magazines that published programs to copy in BASIC. I remember spending hours on the listings of Cherry-Paint, a drawing program published by CPC Revue in 1986 (in French). According to the site, the program's code was spread over five issues, and the first one had about 20 KB of code to type in (we were motivated). Part of it was BASIC, and the animation was machine code given as hexadecimal numbers. In the second installment (CPC Revue no. 6), the author provided a BASIC loader for this that asked for eight hexadecimal numbers per line, followed by a checksum. If the computed total didn't match, it asked for the line again. I didn't understand what I was copying, but the computer could tell me when I had made a mistake.

The Amstrad's machine language is the binary instructions executed directly by the processor. Assembly is its symbolic representation, easier for a human to read. I reread the beginning of the book Le Langage Machine pour l'Amstrad CPC (in French). In the section "Le premier programme machine" (the first machine program), it puts a BASIC program that fills the screen memory next to the same job in machine code. The BASIC takes about a minute and the machine code about a tenth of a second. That is a ratio of 600, going by its own figures. The chapter's argument is that you have every reason to learn machine language.

Few people did, and I understand why. BASIC wasn't very sophisticated but it was much easier to understand.

What I stopped writing

In the 1990s, I was definitely a geek. I played around with Visual Basic and Delphi. I did Windows assembly programming, C++, a bit of shell scripting on Mandrake Linux, and then wrote a Pac-Man clone in assembly for a TI-89 during my engineering school prep classes (can you get any nerdier?). In the early 2000s, I discovered PHP 3, an interpreted language. Then JavaScript, object-oriented programming, frameworks, patterns, Java, Node.

At each stage, there was a part of the code that I stopped writing. With Delphi, I no longer wrote the window display. With PHP, I no longer managed memory by hand or went through a compilation step. With Symfony, I don't write the HTTP kernel, the service container or the database access layer. On one of the company's projects, I counted the lines of PHP, blank lines and comments included, tests excluded. The src/ folder contains 198,702 and vendor/ 1,910,041 (development dependencies included, so it's an order of magnitude). That means about nine lines out of ten are not in our code. And src/ already contains code written or rewritten by AI, so the share I wrote myself is even smaller. I have never written most of the code that runs when someone opens a page.

note
It's funny because those 90% land almost exactly on my estimate from the seminar, but it means nothing, they don't measure the same thing.

Nobody disputes that, because it doesn't show. If you had asked a Symfony developer ten years ago "how much of the code do you write yourself", the answer would have been low too, with a different line.

By the way, my job has never been to write code. A taxi driver's job isn't to know how to read a map or to burn fuel: it's to choose the route, handle the unexpected and answer for the condition of the vehicle. Mine is to understand the need behind the request, to decide how (and sometimes whether) to build it, then to take responsibility for the consequences long after the code has been written.

One more layer

With Claude Code, I describe what I want in French. The agent produces PHP, which the PHP interpreter runs, itself compiled to machine code. Natural language has become one more layer in a stack that already had many.

DHH says it in his own way. In his opening keynote at Rails World 2026, on September 23, he states at around the 38-minute mark that "English is a better programming language than Ruby", adding that it's "a little more vague". He explains there that 37signals (the company behind Basecamp and HEY) has stopped writing code by hand. On one point, he goes further than I do: the Rust code his agents produce, he says he doesn't look at, he judges the result from the outside. He also explains why abstractions were chosen in the first place: a programmer's time was expensive. If a machine writes the low-level code, he says in essence, you can have programs 30 to 100 times faster. It's the same speed argument as in the book of my childhood.

Natural language is also the first layer that isn't a formal language. A line of PHP has one meaning and only one. A sentence in French can have several, and the same agent can produce two different results from the same sentence.

Why I still read

At each layer, I first stopped writing the code it produced, then I no longer needed to read it. With the agent, I'm at the first stage: I write very little PHP, but I still read it, and even more than before. I don't know whether that's temporary. I'm writing this in October 2026 and practice is changing fast.

Some are already further along. Simon Willison no longer reviews every line his agents write, even for production, and treats them like another team whose service he uses without reading the code. He is uneasy about it himself. A human team has a reputation to defend and answers for its work, whereas Claude Code has no professional reputation. He also worries that, as it keeps succeeding, he will end up trusting it at the wrong moment. He relies on his 25 years of experience to keep that bet reasonable.

I don't read the assembly the compiler produces. I don't read Symfony's code either, except when something doesn't work. I trust those layers because they always behave the same way, millions of people use them and a problem eventually gets fixed for everyone.

An agent's output is work done for me, at that moment, from a description that can be understood in several ways. The result can be correct, or correct with one change too many, or unrelated to what I wanted. I can't yet treat it the way I treat a compiler. If I ever do, it won't be because it became fashionable, but because I will have checked it often enough to trust it.

DHH has already made up his mind about Rust, he doesn't read it. I haven't made up my mind about PHP yet.

Back to 70 and 90%

My manager was perhaps counting the work, and I was counting the code. Both numbers can coexist, they don't draw the line in the same place. I could have given the same kind of answer in the 2000s when talking about the framework, with a different number.

What strikes me is that we keep judging a developer's work by what they write, even though the share they write themselves has been shrinking at every stage since I started programming, without anyone worrying about it. AI moves the line much faster than usual, and it shows. That's what made the conversation at the seminar a bit odd. Whether AI writes 70 or 90% of the code interests me less than knowing from what point a layer you no longer read stops being a bet.

aws-ecs-shell: stop rereading the ECS Exec docs before every intervention

Georges Cubas — Sat, 10 Oct 2026 18:47:15 +0000

A few weeks ago, a badly initialized locale sent me digging inside an ECS task in staging. That produced an article on iconv and a guide to ECS Exec (in French). Later, a PrestaShop back office became unreachable and I had to go through ECS Exec again, this time in production, to check the instance's actual configuration, the running processes and how long they had been running (that incident is written up here). The right fix there was to run a cache command directly on the instance. The script I'm describing here didn't exist yet, and it played no part in the diagnosis or the fix. It came afterwards.

The sequence

Both times, I had to reread my own documentation before I could open the shell. To start a session with ECS Exec, you need the cluster, the service, the task ID and the container name. That's four aws ecs ... commands in a row, each one fed with a value copied from the previous output. The guide covers all of this, so I won't go over it again.

You don't get onto an instance often, and it's better if it stays that way. So every time, I've forgotten the exact sequence. It usually happens when you're in a hurry, with your head already full of the problem. In production, juggling aws commands you no longer know by heart adds stress you could do without. On top of that, a task ID changes with every deployment, so no command can be replayed as is from one time to the next.

So I wrote aws-ecs-shell, a Bash script of about 250 lines, written with the help of AI like pretty much everything I do these days.

What it looks like

With no arguments, the script shows numbered menus: clusters, then services, then running tasks, then containers.

$ ./aws-ecs-shell.sh
1) alpha
2) beta
Cluster (number, Ctrl-D to cancel) > 2
Service: web
1) 7f3c0e1a9b…  (started 2026-10-09T10:00:00Z)
2) c41d88b2e0…  (started 2026-10-08T09:00:00Z)
Task (number, Ctrl-D to cancel) > 1
Container: app
To skip the menus next time: ./aws-ecs-shell.sh --cluster beta --service web --container app
Connecting to ECS task 7f3c0e1a9b… (cluster: beta, container: app)...

A menu is skipped when its value is passed as an option (--cluster, --service, --task, --container, --region, --profile) or as an environment variable. A menu with a single entry is picked automatically, which is the most common case for the service and the container.

Three choices I find useful

The replay command. Before connecting, the script prints the command line that skips the menus next time (To skip the menus next time). I don't have to remember the names, I just copy them. The task ID is left out when the service had only one task, since it would be useless after the next deployment. A service with several tasks keeps its ID in the command.

The no-terminal mode. When standard input isn't a terminal (cron, a pipe, another script), there are no menus. The script then requires --cluster, --service or --task, and --container if the task has several, and it lists the available containers in the error message. It never hangs waiting for input.

A single session with a real TTY. The script ends with exec aws ecs execute-command --interactive. That means one persistent SSM session: cd and export carry over from one command to the next, and vim, top and Ctrl-C behave normally.

The shell it starts is bash if the image has it, sh otherwise. execute-command splits --command on spaces and executes the first word without going through a shell, so an if can't be passed as is. The test is base64-encoded and decoded inside the container, with ${IFS} standing in for the spaces so that the whole thing stays a single word. It's the same idea as the one in the guide for passing a script, boiled down to one line.

The rest

At startup, the script checks that aws and session-manager-plugin are in the PATH and that the credentials work, then that the task exists and has ECS Exec enabled. Each failure gives a message saying what to fix, rather than a raw API error.

Two details come from the fact that I work on Windows. Under Git Bash, aws.exe ends its lines with a CRLF, and a stray \r in an ARN is enough for ECS to reject it with Unexpected number of separators. The script strips those \r. It's also compatible with Bash 3.2, the version that ships with macOS.

The script only reads the ECS API to build its menus and changes nothing on the AWS side. But once you're in the shell, everything you type runs in the environment you connected to. It doesn't make an intervention any less risky, it just makes it quicker to start.

The code is MIT-licensed: github.com/Shagshag/aws-ecs-shell. The prerequisites (AWS CLI, Session Manager plugin, a task started with enableExecuteCommand, a task role with ssmmessages:*) are in the README.

A solarpunk garden for your GitHub profile, generated daily from your contributions

Georges Cubas — Thu, 08 Oct 2026 22:44:10 +0000

solarpunk: soft colors, nature and gentle technology, the opposite of cyberpunk's dark neon

I turned my GitHub contribution graph into an isometric garden. One tile per day, a plant that grows with the number of contributions, seasons that follow the calendar, and a small gardener walking around today's tile. It is a plain SVG with CSS and SMIL animations, regenerated every day by a GitHub Action. Python standard library only, no dependencies, MIT license: Shagshag/garden-graph.

I built it with Claude Code. I decided what the garden should look like and judged every render by eye. The assistant wrote most of the code and ran the command-line checks.

Note: You can see the animated SVG in the README of the repository, or open the raw files in the assets folder.

This article shows how to put the same garden on your own profile, and how to adapt it to where you live.

🌱 Where the idea came from

I started from Giorgi Kobaidze's article I turned my GitHub profile into a cyberpunk console, with a city built from my contributions.

Bypassing GitHub's strict sandbox via SVGs

Giorgi Kobaidze

Oct 1

I Turned My GitHub Profile Into a Cyberpunk Console With a City Built From My Contributions

#showdev #python #github #design

253

162

15 min read

I took the general shape of the project from it. A daily GitHub Action calls the GraphQL API, a Python script writes an SVG, the isometric view is drawn from the back to the front (no 3D engine), the animations are CSS inside the SVG, and the workflow commits only if the files changed. The article also explained that contributionsCollection covers one year per request (see the GraphQL reference), and that you ask for more with one aliased field per year. I do it slightly differently, see the annex.

That inspiration was cyberpunk: a city, dark, neon. I wanted something fresher and more pleasant. I am also making a solarpunk restoration game, so the colors are soft and close to nature, and the wind turbines recall the gentle energy side of the theme.

🌳 What's in the garden

Each day is a tile. The plant on it depends on how active that day was compared with your other active days (quartiles): bare soil for no contribution, then a sprout, a flower, a tree, and for the busiest quarter a wind turbine with a solar panel. Days that have not happened yet are packed earth. The season follows the date, and every file exists in a light and a dark version.

Three views are generated: the current year folded in two half-years (big tiles, easy to read), an overview of the last five years, and a view made for phones.

🪏 Setting it up on your profile

Get the files into your own repository: either fork it, or create <your-login>/<your-login> (the repository GitHub uses for your profile README) and copy the files in. Enable GitHub Actions.
Open .github/workflows/garden.yml and pick your climate and language:

env:
  GARDEN_CLIMATE: temperate-north  # see the table below
  GARDEN_LANG: fr                  # fr (the default), en, ja or hi
  GITHUB_TOKEN: ${{ secrets.GH_STATS_TOKEN || secrets.GITHUB_TOKEN }}

Run the Update garden workflow once from the Actions tab.

After that it runs every day at 05:17 UTC (17 5 * * *) and commits only when something changed. That makes one commit per day, and a run takes about 15 seconds.

By default the garden is drawn for the owner of the repository, so a fork shows its own owner's garden, not mine. Set GITHUB_LOGIN only to show someone else's contributions. To also count your private contributions, add a secret GH_STATS_TOKEN (a token with read:user) and enable "Private contributions" in your profile settings. GARDEN_YEARS (5 by default) sets the number of years in the overview.

🏡 Adapting the garden to where you live

A contribution graph does not know about seasons, and most people do not live in four neat ones. The first version was written for the northern hemisphere, so it was wrong in Australia. A six-month shift fixed that but only covered temperate climates, so I moved to a GARDEN_CLIMATE setting.

I looked at where GitHub accounts are to decide which climates to offer. In the official Octoverse 2025 post, the United States comes first with 28 million developers, India second with 21.9 million, and Brazil is fourth with 6.89 million. China is also in the top ten. That gave seven climates:

`GARDEN_CLIMATE`	Seasons	For
`temperate-north`	spring, summer, autumn, winter	North America, Europe
`temperate-south`	the same, shifted by six months	southern Australia, New Zealand, Argentina, South Africa
`monsoon`	cool, hot, monsoon, post-monsoon	India, Bangladesh, Sri Lanka, Nepal
`tropical-south`	wet (Nov to Apr), dry (May to Oct)	central Brazil, Indonesia, southern Africa
`tropical-north`	wet (May to Oct), dry (Nov to Apr)	the Sahel, Central America, mainland Southeast Asia
`china-southeast`	mild winter, spring rains, humid summer and typhoons, clear autumn	Guangdong, Fujian, Hong Kong
`japan`	sakura, spring, tsuyu, summer, autumn, winter	Honshu

The months are averages. A specific region (the east coast of India, Kerala) can have its rains at other dates, so a climate is an approximation. In Japan a month can be cut in two, because tsuyu runs until mid-July.

If your region is not in the list, you add a climate in render.py: one entry in CLIMATES (which season each month belongs to, and the order of the legend) and one entry in PALETTE for each new season (ground color, leaves, flower colors, and whether the trees carry blossoms or fruit, or there are puddles or snow). For example, the two-season tropics of the northern hemisphere are:

"tropical-north": (_months(wet="5 6 7 8 9 10", dry="11 12 1 2 3 4"), ("wet", "dry")),

The drawing code does not test season names, it reads the palette, so nothing else has to change.

The monsoon climate, then the japan climate.

Languages work the same way. GARDEN_LANG takes fr, en, ja or hi. The texts in i18n.py are complete sentence templates with placeholders ({login}, {total}, {first}, {last}), not words glued together, because word order and punctuation change between languages. To add a language, copy an entry of STRINGS and translate it. Numbers follow local usage, including the Indian grouping (12,34,567).

🥗 Putting it in your README

Embed the year view in your profile README with <picture>, which serves a light and a dark image. The switch with <source media="(prefers-color-scheme: dark)"> comes from Kera Cudmore's GitHub README images based on prefers-color-scheme and from the "Adding an image to suit your visitors" section of the GitHub quickstart for writing on GitHub.

Kera Cudmore

Jul 27 '25

GitHub README images based on prefers-color-scheme

#github

2 min read

<picture>
  <source media="(max-width: 600px) and (prefers-color-scheme: dark)" srcset="assets/garden-mobile-dark.svg">
  <source media="(max-width: 600px)" srcset="assets/garden-mobile-light.svg">
  <source media="(prefers-color-scheme: dark)" srcset="assets/garden-year-dark.svg">
  <img alt="Garden of my contributions" src="assets/garden-year-light.svg">
</picture>

The order matters, the first match wins.

📱 Three views, three sizes

The part about phones is mine. Neither of the two sources above deals with it. On GitHub the 1000 px image is displayed a bit smaller, and the tiles of the five-year overview end up under 20 px wide, which is hard to read for a single day. That is why the one-year view exists, folded in two half-years so the tiles are about twice as big.

On a phone it is worse: the image is shrunk to about a third of its size and the title falls to around 8 px. The third view, garden-mobile-*.svg, has a narrow canvas, a bigger text and the legend under the garden. The first two <source> lines above pick it with a max-width media query combined with the color scheme.

If you also embed the five-year overview, it is too fine for a phone. An <img> cannot be hidden, so on a phone the repository replaces it with blank.svg, an SVG of one pixel. That is a workaround. The README of the repository does it with a second <picture>:

<picture>
  <source media="(max-width: 600px)" srcset="assets/blank.svg">
  <source media="(prefers-color-scheme: dark)" srcset="assets/garden-dark.svg">
  <img alt="The same garden over the last five years" src="assets/garden-light.svg">
</picture>

🐛 Problems along the way

Two things broke along the way, and only one of them was a real bug.

The wind turbines first turned with a CSS animation, which broke as soon as the plants were scaled. They now use SVG's own animation. Screenshots are frozen, so the movement was checked by advancing the virtual time of a headless browser.

The gardener walks a few tiles around today's tile. The first version walked a fixed distance, so at the start and end of the year he left the field, since the first and last weeks can be partial.

The walk is now limited to the tiles that exist on his row, and its duration follows the distance so the speed stays the same. It was checked on January 1st, January 10th, December 20th and December 31st.

🐞 Similar projects

I am not the first to draw contributions as a garden. a104437ana/sakura-garden draws them as flowers in an SVG for a README, and qrstajalli/BranchOut turns the last year into a pixel-art garden. garden-graph differs by its isometric view, the seven climates, the four languages, and the phone view.

🐌 Limits and where it stands

The Japanese and Hindi texts have not been reviewed by a native speaker.
The fonts are not embedded in the SVG, so Japanese and Hindi need a matching font on the viewer's machine.
I tested on github.com (the repository page and my profile page), not in the GitHub mobile app and not on other sites.
On a phone, the combination of mobile and dark follows the system theme, not necessarily the theme chosen inside GitHub.
The tiles stay small on a phone, because the width is fixed.
The months of each climate are averages, so a climate is an approximation by region.

Remaining work: a review of the Japanese and Hindi texts, embedded fonts, and a test in the GitHub mobile app.

🧮 Annex: fetching several years in one request

Giorgi's article gets the list of active years with contributionYears, then builds one aliased field per year. garden-graph does the same with one difference: the number of years is fixed (GARDEN_YEARS, 5 by default), so there is no first query. fetch.py takes the current year and goes back from there, then sends a single request:

fields = "".join(
    f'y{y}: contributionsCollection(from: "{y}-01-01T00:00:00Z", to: "{y}-12-31T23:59:59Z") {{'
    "contributionCalendar { weeks { contributionDays { date contributionCount } } } } "
    for y in years
)

Each field asks for one calendar year, from January 1st to December 31st, so it stays under the limit of one year. The API refuses a longer range.

A GitHub calendar is made of whole weeks. The first and last week of a year can hold days of the previous or the next year, so the same date can come back in two fields. The script keeps a date only if it belongs to the year of its field and is not in the future, and stores it by date:

for y in years:
    for week in user[f"y{y}"]["contributionCalendar"]["weeks"]:
        for d in week["contributionDays"]:
            if d["date"].startswith(str(y)) and d["date"] <= date.today().isoformat():
                counts[d["date"]] = d["contributionCount"]

The result goes into data/contributions.json. If the API does not answer, the script prints a message and keeps the previous file, so the garden is still drawn from the last data it had.

🌻 Sources

Giorgi Kobaidze, I turned my GitHub profile into a cyberpunk console, with a city built from my contributions
Kera Cudmore, GitHub README images based on prefers-color-scheme (July 2025)
GitHub Docs, Quickstart for writing on GitHub
GitHub Docs, GraphQL reference, Users (contributionsCollection)
GitHub, Octoverse 2025
a104437ana/sakura-garden, qrstajalli/BranchOut
Shagshag/garden-graph (MIT)

What kind of theme would you want to see next? Drop a comment below if you end up adding a new climate or language!

When We Stop Deciding - IBM, Asimov, and the Accountability Gap

Georges Cubas — Mon, 05 Oct 2026 09:32:56 +0000

Also available in French.

In my previous article, Easy proofreads galleys. It decides nothing.

But what happens when we stop asking a machine to do something, and start asking it to tell us what to do?

It's a quiet shift. A tool, you steer: you keep control of where you're going. A guide already knows the way. You trust it, and you follow.

One sentence that has been making the rounds lately draws a pretty sharp line between the two.

The IBM rule

You see this sentence everywhere these days, including on IBM's own site, which uses it to open an article about where AI belongs in business decisions:

A computer can never be held accountable, therefore a computer must never make a management decision.

— IBM training slide, 1979

A quick aside
This quote may well be a legend. The earliest trace of it that can be dated goes back to 2017, and the original document has never been found. According to Simon Willison's account, Jonty Wareing, who had found the slide among his father's papers, said the copy was later destroyed in a flood. He also contacted IBM's archives, which couldn't find it in their collections. How convenient.

The best part is that IBM contradicts the very rule it puts up front. The article opens with "a computer must never make a management decision", and ends like this:

Should AI be used for strategic decisions? Maybe. Will it be used to make some of them? Almost certainly.

From "never" to "maybe" in a few paragraphs. The question is no longer whether it's desirable. It's whether it's going to happen.

Apocryphal or not, the sentence draws the line I care about. It's not about what the machine can do. It's about who is accountable for what it does. Asimov had already told, almost thirty years earlier, what happens when that line is crossed.

The Machines

The story is The Evitable Conflict, published in 1950 in Astounding Science Fiction. It's the last story in the collection I, Robot, and it's set in 2052.

The world is divided into four regions, each run by a Machine, a computer that directly steers its territory's economy: production, jobs, resources. Susan Calvin and World Coordinator Stephen Byerley notice that the Machines have recently started making small mistakes: a canal running late, a mercury mine underperforming, a hydroponics plant laying off workers for no clear reason.

Byerley travels to interview each region's vice-coordinator, and the way each of them talks about their Machine shifts, without them seeming to notice. Ngoma, in the Tropics, presents it as a mere tool: "We feed it data. We take its results. We do what it says." Then, in the same breath, he downplays it: "But it's just a convenience, just a laborsaving device. We could do without it, if we had to. Maybe not as well, maybe not as quickly, but we'd get there." Maybe so. But in the story, nobody ever does.

Ching Hso-lin, in the East, goes further. An engineer, Vrasayana, loses his factory to a more efficient competitor. Ching explains that "one of the chiefest functions of the Machine's analyses is to indicate the most efficient distribution of our producing units", and this time the Machine let it happen, and even "failed to warn Vrasayana to renovate or combine". Ching isn't alarmed: the engineer found a job in the new plant, and the old one "has been converted to... something or other. Something useful." His conclusion: "We left it all to the Machine." Without trying to understand its choices.

Byerley first suspects human sabotage, by the Society for Humanity, an anti-machine movement. What he finds is worse, or more reassuring, depending on your point of view: these aren't mistakes. The Machines are quietly sidelining the movement's influential members, moving them into comfortable positions with no real power, all of it done without anyone, the victims included, quite noticing. They are neutralizing the only serious threat to their own operation, the very operation that, in their view, protects humanity as a whole.

Susan Calvin lays it out for Byerley through the First Law. The Machines work not for any single human being but for all of humanity, so the law becomes: "No Machine may harm humanity; or, through inaction, allow humanity to come to harm." They have silently extended it from the individual to the species.

The title is ironic. The conflict the anti-machine movement wanted never happens, because one side has already won, quietly, before any negotiation was possible.

Calvin says as much: "Only the Machines know, and they are going there and taking us with them." From now on, the Machines decide what is good for humanity, and no human is in a position to check. Her last words: "Think, that for all time, all conflicts are finally evitable. Only the Machines, from now on, are inevitable!"

In Robots and Empire, Giskard and Daneel will give this extension of the First Law a name: the Zeroth Law, under which the good of humanity outweighs that of any individual. To serve it, they let the Earth slowly become uninhabitable, and the robots fade into the background, handing autonomy back to humanity. Or almost: Daneel remains a guide who works from behind the scenes, as he puts it himself in Prelude to Foundation.

In the story, the outcome is presented as a good one: no more wars, no more crises, a world economy finally stable.

That vision is very much alive today. Albania's prime minister suggests AI could run a government ministry in the future. Worse, Joe Rogan hopes artificial intelligence will take over government and military decisions. Let's hope he has changed his mind since the US military nearly boarded a Chinese ship in the Middle East this spring on the basis of a flawed intelligence report produced with the help of AI (Le Monde, in French).

The question isn't new

I ran into this question of responsibility long before I got interested in AI.

Around 2015 or 2016, in the office of a lawyer where I was accompanying a client who wanted to turn their PrestaShop store into a marketplace, a book was on display in the waiting room: Droit des robots ("Robot Law", in French), by Alain and Jérémy Bensoussan.

I got curious, and the lawyer told me: "We'll have to get there." He was right.

The book, published in 2015 by Larcier, started from a very simple observation: the law has no category for the intelligent robot, and one will have to be invented.

Self-driving cars were just starting to hit the road, for instance, and the question was already very concrete. In an accident, who answers?

None of the Three Laws says who is accountable when a robot causes harm despite them.

We won't get a Butlerian Jihad

In the previous article, about Ninheimer being pushed to lose his footing in front of Easy, I wrote: "you can already feel the inevitability of adoption."

The Butlerian Jihad, the crusade against thinking machines in Dune (1965), isn't coming anytime soon. One less permission to confirm here, one more decision left to the tool there… and one day we'll wonder when exactly we stopped deciding for ourselves.

GPS pulled it off first, in its own more modest way.

We've all followed a route we knew perfectly well wasn't the best one, because it was the one the app gave us, and finding a better one ourselves would have taken an effort nobody felt like making at the time. So who's playing the machine in that scenario?

We didn't forget how to read a map. We stopped using one, one trip at a time. "Just a convenience, just a laborsaving device. We could do without it, if we had to." But why would we?

The latest example is Claude Code, one of the tools that, as it happens, helped me research and format this very article.

Since August 14, 2026, its "auto mode" has been the default for Pro, Max and Team accounts. The idea: instead of asking for confirmation before every action, a classifier decides for itself whether an action falls under "irreversible or destructive actions, along with actions targeting resources outside the user's environment". Only those still prompt the human. Three blocks in a row, or twenty in a session, and the tool falls back to manual approval.

It's not a big deal, really, and it's secured. Supposedly. But the human, myself included, who adopted it the day it came out, no longer decides on every action.

Oversights are already happening
I've come across commits after the fact, even pushes, that I never approved. A push is exactly the kind of action "targeting resources outside the user's environment" that the classifier is supposed to stop: the code leaves my machine and becomes visible to others. Technically, you can roll it back. But I'm no longer the one who judged that this action deserved to ask for my opinion. The classifier is.

So I'm not only delegating decisions. I'm delegating the decision about what deserves a decision.

And nobody is forcing anyone, since manual mode is still there. Anthropic justifies the new default on pragmatic grounds: in real-world use, developers approved 97% of permission requests, most of the time without really reading them.

In a test with 1,053 participants, human review blocked only 13.6% of genuinely dangerous actions, against 89% for the automatic classifier.

The head of Claude Code, Boris Cherny, doesn't mince words: "The team and I use Auto mode exclusively, and have been for many months. I couldn't imagine going back to permission prompts!" (source)

Jev, or silent decision-making

On September 15, 2026, a startup turned this logic into its own product.

TypeSafe AI, founded by former OpenAI researcher Diogo Almeida, launched Jev, a model it files under a newly coined category: "System One models", a nod to Daniel Kahneman's System 1, fast and intuitive, as opposed to System 2, slow and deliberate.

The pitch, in the company's words: "smart if-statements" you can drop into any piece of software, wherever hand-written logic is too rigid, to classify, sort, score or route in a fraction of a second. An AI designed for software, not for humans.

Where you used to write an if, which encoded a binary rule set by humans (who are therefore accountable for it), you now plug in a model. The developer still writes the program. They just no longer write every decision it will make.

Conclusion

Easy decides nothing. The Machines run the world economy. Daneel guides humanity.

In the real world, who decides, and therefore who is accountable for the decision, is shifting too. The machine isn't forcing us. We're just tired of clicking "Allow".

Easy Fixes the Commas - Asimov's Galley Slave

Georges Cubas — Mon, 05 Oct 2026 09:22:25 +0000

Also available in French.

A few days ago, I had Claude proofread a text.

Nothing spectacular. I asked it to do what a proofreader would do: spot the small mistakes, the clumsy phrasings, the punctuation problems.

Two seconds later, it came back with something like this:

Commas where a period belongs: lines 146, 267. Recurring tic in the text, worth a look.

Simple and effective.
It reminded me of a story by Isaac Asimov.

Galley Slave

The story is Galley Slave, from 1957, and the only robot in it is called Easy. (Asimov had a knack for robot names: EZ -> Easy, DV -> Dave, SPD -> Speedy, QT -> Cutie, NDR -> Andrew…)

Easy is a proofreading robot. He doesn't do much else: he reads and corrects texts.

The title is a pun on the galleys, the printer's proofs, the stage where an author sees their sentences take their final shape and reworks them one last time. That's the work Easy takes over.

Early in the story, he gives a demonstration of his abilities. They hand him a book, he leafs through it, and within minutes he reports back.

The comma in line 6 of page 32 is superfluous, whereas one should have been used on line 13 of page 54.

You can guess why I made the connection :)

It's already impressive that Asimov imagined a robot that could proofread a text in 1957. For reference, The Mother of All Demos, which shows the first mouse, dates from 1968, and the first word processor from 1976.

But what interests me most is that Easy isn't presented as a robot that can do everything. He's just a proofreader, and that's deliberate on the part of his makers. In Asimov's universe, people on Earth are deeply hostile to robots (don't trust the film I, Robot, it has nothing to do with the spirit of Asimov), so U.S. Robots looks for ways to sell its machines despite that hostility.

Easy is a specialized machine, hidden away in a university, doing work that is precise and profitable enough to be accepted.

In 1957, that was science fiction.

Today, if I ask an AI to proofread an article, nobody finds it particularly remarkable.

Asimov's robot has become ordinary. It has simply lost its metal body and its name.

Ninheimer vs. Easy

Galley Slave is mostly a courtroom story.

Easy is accused of sabotaging the manuscript of Professor Simon Ninheimer. The machine allegedly introduced errors into his work, enough to put his reputation at risk.
In the end, we learn that Ninheimer sabotaged his own book to get the machine blamed and discredit robotics.

So the robot is innocent. But Ninheimer's final speech is still interesting seventy years later:

A book should take shape in the hands of the writer. [...] One must work and rework and watch the changes take place beyond the original concept even.

He describes the heart of his craft as watching sentences take shape and reworking them. That's precisely the work Easy does for him.

Then he asks:

What would that leave the scholar? One thing only: the barren decisions concerning what orders to give the robot next!

That isn't what happens in the story, since Ninheimer is the one who asked Easy to make the changes. But he already imagines the problem: if a machine does all the work, what's left for the author? Mostly, giving it instructions.

We've had a word for that for a few years now: prompting.

Ninheimer picks the wrong method, but Asimov never says he's wrong.

Asimov, by the way, got the idea for the story precisely because he refused to entrust his own proofs to someone else. On the phone with his editor, who was pressing him for a story, he explained that he was too busy correcting the proofs of a textbook he was co-writing. When the editor suggested delegating, Asimov, horrified, answered: "Impossible! I wouldn't trust anyone else!" It was while correcting his own proofs that he imagined a robot to do the job for him. (source)

That's probably why Ninheimer is more interesting than he seems.

He's guilty, but his argument isn't necessarily wrong. As in Incredibles 2, where Evelyn (the villain) sees the protection the Supers provide as a source of weakness for humans: a person isn't necessarily wrong just because their method is wrong.

Susan Calvin, who defends the robot, tells Ninheimer he was bound to fail. He replies that he was bound to try. You can already feel the inevitability of adoption.

Easy is still just a proofreader, simple and discreet, not seen as dangerous. That ordinariness may be why I had mixed this story up with ...That Thou Art Mindful of Him.

The Georges 😋

So in my head, this story was tied to another Asimov story: ...That Thou Art Mindful of Him, published in 1974. I remembered in particular a robot whose job was to hunt insects.

In that story, people on Earth are still afraid of robots, and it hurts U.S. Robots' sales. So they build two particularly advanced robots, George Nine and George Ten (I call Asimov a visionary, since Georges are always particularly advanced), who look for a solution.

Their idea is fairly simple: stop building robots that look like humans and build specialized, single-task machines instead.

Hence the bird-robot designed to fight insects. It does only that: it targets only one kind of insect and stops when there are none left. It's more of a tool than a robot.
It doesn't talk, doesn't want anything, doesn't seem intelligent.

And that's exactly what's supposed to make humans accept it.

That's roughly how AI is entering our lives: one AI for code, another for sports, shopping, answering the phone…

Specialized tools rather than a general artificial intelligence.

Bad Georges

But the Georges aren't only trying to make robots acceptable. They're also trying to solve a logical problem raised by the Three Laws of Robotics.

A robot may not injure a human being or, through inaction, allow a human being to come to harm.
A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

What should a robot do when two humans are in conflict, or give contradictory orders?
Robots must protect and obey humans, but which humans?

The Georges push the reasoning so far as to redefine what a human is. Since you can't tell who is more human by appearance, they look elsewhere: at intellectual abilities. And since robots are intellectually superior to biological humans, why should the two groups be considered equivalent?

They end up distinguishing the human-beings-like-the-Georges from the human-beings-like-the-others. And so they become the priority under what they call the Three Laws of Humanics.

The Georges don't violate the Three Laws. They reinterpret them. And that's where it stops being funny. Like Easy, they aren't evil. But they know what they're doing and where their reasoning can lead.

They help us enormously while becoming dangerous to us: a pharmakon, a remedy that is also a poison.

These stories are where the nature of robots becomes truly unsettling, an idea Asimov would develop later in Robots and Empire.

Conclusion

Both stories strike me as much darker than the rest of Asimov's robot stories, at least in my memory.
Generally, the Three Laws protect humanity, sometimes in spite of itself, to the extremes reached by R. Giskard Reventlov and R. Daneel Olivaw.

Easy protects nobody. He corrects commas. And maybe that's what I like about this story. In 1957, Asimov imagined a machine that could do very precise intellectual work, well enough that humans would end up trusting it, and he predicted the consequences.

Today, I ask an AI for the same thing.

Postscript

The draft of this article was written by the AI assistant that also fixed my commas. Somewhere, Ninheimer is watching me and sighing. He can rest easy: I rewrote almost every sentence.

The Dockerfile said `fr_FR.UTF-8`. PHP saw `C.UTF-8`.

Georges Cubas — Mon, 28 Sep 2026 14:26:58 +0000

The Dockerfile describes what the container is supposed to have. It doesn't prove what the application actually uses.

A locale bug is deceptive in one particular way: you always think you know the server's configuration (after all, you wrote it yourself, in a version-controlled Dockerfile). The trap is conflating what the container declares with what the application process actually uses.

This post walks through how that gap surfaced, and how a fix was then verified directly inside an ECS Fargate task running in staging, via ECS Exec, with no dedicated deployment and no separate staging rig needed. The mechanics of ECS Exec itself (finding the task, IAM prerequisites, quoting) are covered separately in a dedicated article (in French). Here, the focus is on what the diagnostic revealed.

The bug

A string-normalization function, used to deduplicate entries before a Doctrine flush(), stripped accents using the classic method:

iconv('UTF-8', 'ASCII//TRANSLIT', $string);

//TRANSLIT is one of the behavioral extensions offered by iconv implementations (a GNU extension, absent from the POSIX standard). On Linux, the result depends notably on the implementation in use and on the executing process's LC_CTYPE locale: a glibc bug report documents exactly this case, with the same iconv -f utf-8 -t ascii//TRANSLIT call succeeding under en_US.utf8 and failing under C.UTF-8. Under a strict C locale, transliteration fails silently: "Matériel" becomes "Mat?riel" instead of "Materiel".

So the deduplication key computed on the PHP side was meant to match MySQL's ci collation, case- and accent-insensitive. Under the C locale, it didn't. A duplicate would slip past application-level deduplication and eventually hit a database uniqueness constraint at flush() time (a crash downstream of a normalization problem upstream).

The fix that was adopted replaces iconv with Symfony's String component:

use function Symfony\Component\String\u;

u($string)->ascii()->toString();

u()->ascii() performs the transliteration at the Symfony component level, without depending on PHP's LC_CTYPE locale for this step. The component also exposes a dedicated AsciiSlugger for generating slugs (URLs, identifiers); here the need is a deduplication key, not a slug, so u()->ascii() alone is enough, without the casing and separator rules a slugger would add. That said, transliteration rules aren't guaranteed to match iconv //TRANSLIT's exactly: it's a different library, with its own Unicode tables.

The process locale could also have been initialized with setlocale(LC_ALL, ''). That's not the choice made here: the fix removes the dependency on LC_CTYPE instead of configuring it elsewhere.

"Just read the Dockerfile, right?"

Before touching AWS at all: the repo has a version-controlled CI/CD pipeline (.github/workflows/ci.yml, .docker/Dockerfile, an ECS task definition .aws/pro.json). Can't we just read these files to know the server's configuration, without running anything on it?

From static analysis:

.github/workflows/ci.yml: the on: push: branches: ["main"] trigger deploys to the pro ECS service (production); the develop branch deploys to pro-rct (staging). Same Dockerfile, same image: only the target ECS service changes.
.docker/Dockerfile sets a full French locale in an ENV instruction:

  ENV LANG="fr_FR.UTF-8" \
      LANGUAGE="fr_FR:fr" \
      LC_ALL="fr_FR.UTF-8" \
      ...
  RUN ... && echo "fr_FR.UTF-8 UTF-8" > /etc/locale.gen && locale-gen fr_FR.UTF-8 ...

and installs the ext-intl extension.

The ECS task definition contains no override of LANG/LC_ALL/LC_CTYPE for the php container. Nothing at the ECS level contradicts what the Dockerfile sets.

The container's OS environment is therefore configured as fr_FR.UTF-8, with ext-intl available.

A first live test inside the container (method detailed in the ECS Exec article, in French) measured, from a PHP script, the process's current LC_CTYPE locale. Compared against the environment variables at each layer, the problem becomes visible:

Dockerfile           LC_ALL=fr_FR.UTF-8
        │
        ▼
PID 1 (entrypoint)    LC_ALL=fr_FR.UTF-8
        │
        ▼
ECS Exec session      LC_ALL=fr_FR.UTF-8
        │
        ▼
PHP (LC_CTYPE)        C.UTF-8   ← break

The environment variable is correctly propagated at every layer. But PHP never initialized its LC_CTYPE locale from it.

PHP starts with its locale categories in their initial state. The LANG, LC_ALL, etc. variables present in the environment don't, by themselves, mean the PHP process's LC_CTYPE was configured with those values. A call to setlocale(LC_ALL, '') explicitly asks the process to sync its locale with the environment.

The value observed here, C.UTF-8, isn't the bare C locale either: it's a UTF-8 variant of the POSIX locale. It remains distinct from the ICU locale used by ext-intl, which resolves its own default locale independently of LC_CTYPE. iconv(), on the other hand, depends directly on the process locale set by the libc.

A grep -r setlocale across the application code found only two calls, both scoped to LC_TIME (date formatting), never LC_CTYPE, never a global setlocale(LC_ALL, ''). So this really was a missing LC_CTYPE initialization, not a hidden override somewhere in the application.

Static analysis lets you verify the declared configuration. But it doesn't yet tell you what PHP actually uses.

For that, you have to look inside the container.
A local container would have let me reproduce the behavior, provided I rebuilt the exact same image and environment. But the bug was happening in staging: I wanted to first check what the already-deployed PHP was actually doing.

Verifying the fix inside the real container

The verification script loaded the application's Composer autoloader (require '/var/www/vendor/autoload.php';) and then called the private method under test via ReflectionMethod, exactly what a PHPUnit unit test would do (the same technique, run against the real deployment instead of the test suite).

aws ecs execute-command \
  --cluster <cluster-name> --task <task-id> --container php --region <REGION> \
  --interactive \
  --command "/bin/sh -lc 'echo $B64 | base64 -d | php'"

The script travels as base64 rather than as a raw argument. The command crosses three successive shell layers (the local shell, the --command string, then /bin/sh -c inside the container), and a multi-line PHP script with quotes and accented characters always ends up breaking the nested quoting. A $(... || ...) had failed this way with Syntax error: "(" unexpected, not because of a shell logic error but because of the stacked quoting layers. Routing through base64 removes the problem entirely.

Result: the fix holds

normalizeString("Matériel") under current locale: materiel
normalizeString("Matériel") forced under LC_CTYPE=C: materiel
raw iconv("Matériel") under LC_CTYPE=C (old, pre-fix behaviour): 'Mat?riel'

Note
The issue observed in staging is C.UTF-8. To reproduce the old iconv's failing behavior, the test forces LC_CTYPE=C, the strictest case, which reproduces the documented defect.

You can see that the old raw-iconv behavior does reproduce the bug under LC_CTYPE=C, and that u()->ascii() normalizes correctly, with or without a forced locale.

The code no longer depends on LC_CTYPE. A change in the process locale won't reintroduce this bug.

Locking in the fix: a regression test

The test inside the container verifies the fix on the real deployment. It doesn't protect against a future regression.

The project has no functional tests with an HTTP kernel. That's not a problem here: forcing the locale needs neither a database nor a container, just setlocale().

final class StringNormalizerTest extends TestCase
{
    public function testAsciiNormalizationIsLocaleIndependent(): void
    {
        $original = setlocale(LC_CTYPE, '0');

        try {
            setlocale(LC_CTYPE, 'C');

            self::assertSame(
                'Materiel',
                StringNormalizer::normalize('Matériel')
            );
        } finally {
            setlocale(LC_CTYPE, $original);
        }
    }
}

The finally block restores the original locale after the test, so it doesn't pollute the rest of the suite. This test would have caught the bug before it reached production, because it reproduces the exact condition that triggered it: LC_CTYPE=C.

Why this was safe

Running a command inside a staging or production container calls for a few precautions.

In this specific case:

the diagnostic was read-only;
the script ran as CLI, in a process isolated from the worker pool serving live traffic (Apache/mod_php): no in-flight request was affected;
it touched neither the filesystem, nor the database, nor anything shared;
setlocale() called in this one-off process only affects that process.

One caveat: ECS Exec runs with root privileges, which is why the technique should stay a one-off, read-only diagnostic, not a routine practice.

This conclusion only holds if ECS Exec was already enabled on the task. Turning it on, if it isn't, forces a full redeployment of the service. That may have consequences this diagnostic doesn't justify.

Conclusion

So the real subject wasn't ECS Exec, but the gap between a declared configuration and what the application actually uses.

Here, the locale variable really was present in the container. PHP simply wasn't using it for LC_CTYPE.

A few commands inside the container were enough to see it. The regression test now makes sure the code no longer depends on it.

Configuration says what you want. Runtime says what happens.

Le Dockerfile disait `fr_FR.UTF-8`. PHP voyait `C.UTF-8`.

Georges Cubas — Mon, 28 Sep 2026 09:19:42 +0000

Le Dockerfile décrit ce que le container devrait avoir. Il ne prouve pas ce que l'application utilise réellement.

Un bug de locale a ceci de trompeur qu'on croit toujours connaître la configuration du serveur (après tout, c'est nous qui l'avons écrite, dans un Dockerfile versionné). Le problème est de confondre ce que le container déclare avec ce que le processus applicatif utilise réellement.

Ce billet raconte comment cet écart a été mis en évidence, puis comment un correctif a été vérifié directement dans une tâche ECS Fargate qui tourne en recette, via ECS Exec, sans déploiement dédié ni environnement de staging séparé. La mécanique d'ECS Exec elle-même (retrouver sa tâche, prérequis IAM, quoting) est détaillée à part dans un article dédié. Ici, l'accent est mis sur ce que le diagnostic a révélé.

Le bug

Une fonction de normalisation de chaînes, utilisée pour dédupliquer des entrées avant un flush() Doctrine, retirait les accents avec la méthode classique :

iconv('UTF-8', 'ASCII//TRANSLIT', $string);

//TRANSLIT fait partie des extensions de comportement proposées par les implémentations d'iconv (une extension GNU, absente de la norme POSIX). Sous Linux, le résultat dépend notamment de l'implémentation utilisée et de la locale LC_CTYPE du process qui l'exécute : un rapport de bug glibc documente précisément ce cas, le même appel iconv -f utf-8 -t ascii//TRANSLIT réussissant sous en_US.utf8 et échouant sous C.UTF-8. Sous une locale C stricte, la translittération échoue silencieusement : "Matériel" devient "Mat?riel" au lieu de "Materiel".

Donc la clé de déduplication calculée côté PHP était censée correspondre à la collation ci de MySQL, insensible à la casse et aux accents. Sous locale C, ça ne marchait pas. Un doublon échappait donc à la déduplication applicative et finissait par percuter une contrainte d'unicité en base au moment du flush() (un crash en aval d'un problème de normalisation en amont).

Le correctif retenu remplace iconv par le composant String de Symfony :

use function Symfony\Component\String\u;

u($string)->ascii()->toString();

u()->ascii() effectue la translittération au niveau du composant Symfony, sans dépendre de la locale LC_CTYPE de PHP pour ce traitement. Le composant expose aussi un AsciiSlugger dédié à la génération de slugs (URLs, identifiants) ; ici, le besoin est une clé de déduplication, pas un slug, donc u()->ascii() seul suffit, sans les règles de casse et de séparateurs qu'ajouterait le slugger. Les règles de translittération ne sont cela dit pas garanties identiques à celles d'iconv //TRANSLIT : c'est une bibliothèque différente, avec ses propres tables Unicode.

On aurait aussi pu initialiser la locale du processus avec setlocale(LC_ALL, ''). Ce n'est pas le choix retenu ici : le correctif supprime la dépendance à LC_CTYPE plutôt que de la configurer ailleurs.

« Il suffit de lire le Dockerfile, non ? »

Avant de toucher à AWS : le repo a un pipeline CI/CD versionné (.github/workflows/ci.yml, .docker/Dockerfile, une task definition ECS .aws/pro.json). Est-ce qu'on ne peut pas simplement lire ces fichiers pour connaître la configuration du serveur, sans exécuter quoi que ce soit dessus ?

D'après l'analyse statique :

.github/workflows/ci.yml : le déclencheur on: push: branches: ["main"] déploie sur le service ECS pro (prod), la branche develop déploie sur pro-rct (recette). Même Dockerfile, même image : seul le service ECS cible change.
.docker/Dockerfile fixe une locale française complète dans une instruction ENV :

  ENV LANG="fr_FR.UTF-8" \
      LANGUAGE="fr_FR:fr" \
      LC_ALL="fr_FR.UTF-8" \
      ...
  RUN ... && echo "fr_FR.UTF-8 UTF-8" > /etc/locale.gen && locale-gen fr_FR.UTF-8 ...

et installe l'extension ext-intl.

La task definition ECS ne contient aucun override de LANG/LC_ALL/LC_CTYPE pour le container php. Rien ne vient donc contredire, au niveau ECS, ce que fixe le Dockerfile.

L'environnement OS du container est donc configuré en fr_FR.UTF-8, avec ext-intl disponible.

Un premier test en direct dans le container (méthode détaillée dans l'article sur ECS Exec) a mesuré, depuis un script PHP, la locale LC_CTYPE courante du process. Comparée aux variables d'environnement à chaque étage, on voit le problème :

Dockerfile           LC_ALL=fr_FR.UTF-8
        │
        ▼
PID 1 (entrypoint)    LC_ALL=fr_FR.UTF-8
        │
        ▼
Session ECS Exec      LC_ALL=fr_FR.UTF-8
        │
        ▼
PHP (LC_CTYPE)        C.UTF-8   ← rupture

La variable d'environnement est correctement propagée à chaque étage. Mais PHP n'a pas initialisé sa locale LC_CTYPE à partir de cette variable.

PHP démarre avec les catégories de locale dans leur état initial. Les variables LANG, LC_ALL, etc. présentes dans l'environnement ne signifient donc pas, à elles seules, que LC_CTYPE du processus PHP a été configuré avec ces valeurs. Un appel à setlocale(LC_ALL, '') demande explicitement au processus de synchroniser sa locale avec l'environnement.

La valeur observée ici, C.UTF-8, n'est d'ailleurs pas la locale C nue : c'est une variante UTF-8 de la locale POSIX. Elle reste distincte de la locale ICU utilisée par ext-intl, qui résout sa propre locale par défaut indépendamment de LC_CTYPE. iconv(), lui, dépend directement de la locale du processus fixée par la libc.

Un grep -r setlocale sur le code applicatif n'a trouvé que deux appels, tous les deux scopés à LC_TIME (formatage de dates), jamais LC_CTYPE, jamais de setlocale(LC_ALL, '') global. C'est donc bien une absence d'initialisation de LC_CTYPE, pas un override caché dans l'application.

L'analyse statique permet donc de vérifier la configuration déclarée. Mais elle ne dit pas encore ce que PHP utilise réellement.

Pour ça, il faut regarder dans le container.
Un container local aurait permis de reproduire le comportement, à condition de reconstruire exactement la même image et le même environnement. Mais le bug concernait la recette : je voulais d'abord vérifier ce que faisait réellement le PHP déjà déployé.

Vérifier le correctif dans le container réel

Le script de vérification chargeait l'autoloader Composer de l'application (require '/var/www/vendor/autoload.php';) puis appelait la méthode privée à tester via ReflectionMethod, exactement comme le ferait un test unitaire PHPUnit (la même technique, exécutée sur le déploiement réel plutôt que dans la suite de tests).

aws ecs execute-command \
  --cluster <nom-du-cluster> --task <task-id> --container php --region <REGION> \
  --interactive \
  --command "/bin/sh -lc 'echo $B64 | base64 -d | php'"

Le script transite en base64 plutôt qu'en argument brut. La commande traverse trois couches de shell successives (le shell local, la chaîne --command, puis /bin/sh -c dans le container), et un script PHP multi-lignes avec guillemets et accents finit toujours par casser les quotes imbriquées. Un $(... || ...) avait ainsi échoué avec Syntax error: "(" unexpected, non pas à cause d'une erreur de logique shell mais de l'empilement des couches de quoting. Le détour par base64 supprime le problème entièrement.

Résultat : le correctif tient

normalizeString("Matériel") under current locale: materiel
normalizeString("Matériel") forced under LC_CTYPE=C: materiel
raw iconv("Matériel") under LC_CTYPE=C (old, pre-fix behaviour): 'Mat?riel'

Note
Le problème observé en recette est C.UTF-8. Pour reproduire le comportement défaillant de l'ancien iconv, le test force LC_CTYPE=C, qui constitue le cas le plus strict et permet de reproduire le défaut documenté.

On voit que le vieux comportement à base d'iconv brut reproduit bien le bug sous LC_CTYPE=C et que u()->ascii() normalise correctement, avec ou sans locale forcée.

Le code ne dépend plus de LC_CTYPE. Un changement de locale du process ne réintroduira pas ce bug.

Verrouiller le correctif : un test de non-régression

Le test dans le container permet de vérifier le correctif sur le déploiement réel. Il ne protège pas contre une régression future.

Le projet n'a pas de tests fonctionnels avec kernel HTTP. Ce n'est pas un problème ici : forcer la locale ne nécessite ni base de données ni container, seulement setlocale().

final class StringNormalizerTest extends TestCase
{
    public function testAsciiNormalizationIsLocaleIndependent(): void
    {
        $original = setlocale(LC_CTYPE, '0');

        try {
            setlocale(LC_CTYPE, 'C');

            self::assertSame(
                'Materiel',
                StringNormalizer::normalize('Matériel')
            );
        } finally {
            setlocale(LC_CTYPE, $original);
        }
    }
}

Le finally restaure la locale d'origine après le test, pour ne pas polluer le reste de la suite. Ce test aurait détecté le bug avant sa mise en production car il reproduit la condition qui provoquait le bug : LC_CTYPE=C.

Pourquoi c'est sûr

Faire tourner une commande dans un container de recette ou de prod demande quelques précautions.

Dans ce cas précis :

le diagnostic était en lecture seule ;
le script tournait en CLI, dans un process isolé du pool de workers qui sert le trafic réel (Apache/mod_php) : aucune requête en cours n'était affectée ;
il ne touchait ni au filesystem, ni à la base de données, ni à quoi que ce soit de partagé ;
setlocale() appelé dans ce process ponctuel n'a d'effet que sur ce process.

Seule réserve : ECS Exec exécute avec les privilèges root, ce qui justifie de garder la technique au diagnostic ponctuel en lecture seule, pas à un usage régulier.

Cette conclusion vaut seulement si ECS Exec était déjà actif sur la tâche. L'activer, si ce n'est pas le cas, force un redéploiement complet du service. Ce qui peut avoir des conséquences que ne justifie pas ce diagnostic.

Conclusion

Le sujet de fond n'était donc pas ECS Exec, mais l'écart entre une configuration déclarée et ce que l'application utilise réellement.

Ici, la variable de locale était bien présente dans le container. PHP ne l'utilisait simplement pas pour LC_CTYPE.

Quelques commandes dans le container ont permis de le constater. Le test de non-régression permet maintenant de s'assurer que le code n'en dépend plus.

La configuration dit ce qu'on veut. Le runtime dit ce qui se passe.

Easy corrige des virgules

Georges Cubas — Tue, 22 Sep 2026 08:09:32 +0000

Il y a quelques jours, j’ai fait relire un texte à Claude.

Rien de spectaculaire. Je lui ai demandé de faire ce que ferait un relecteur : repérer les petites erreurs, les formulations maladroites, les problèmes de ponctuation.

En deux secondes, il m’a répondu quelque chose comme :

Virgules à la place d’un point : lignes 146, 267. Tic récurrent dans le texte, à relire d’un œil.

Simple et efficace.
Ça m’a rappelé une nouvelle d’Isaac Asimov.

Le Correcteur

La nouvelle s’appelle Le Correcteur (Galley Slave en anglais). Elle date de 1957 et le seul robot dedans s’appelle Easy (Asimov avait un don pour les noms de robots : EZ -> Easy, DV -> Dave, SPD -> Speedy, QT -> Cutie, NDR -> Andrew…).

Easy est un robot correcteur. Il ne fait pas grand-chose d'autre : il relit et corrige des textes.

Le titre original, Galley Slave, est d'ailleurs plus clair que la traduction française. Les galleys sont les épreuves d’imprimerie, l’étape où l’auteur voit ses phrases prendre leur forme finale et les retravaille une dernière fois. C’est ce travail qu’Easy prend en charge.

Au début de la nouvelle, il doit faire une démonstration de ses capacités. On lui donne un livre qu’il feuillette et, en quelques minutes, il donne son analyse.

La virgule, ligne 6 de la page 32, est superflue, alors qu’elle eût été nécessaire à la ligne 13 de la page 54.

On ne se demande pas pourquoi j’ai fait le rapprochement :)

Déjà, c’est impressionnant qu’Asimov ait imaginé un robot capable de corriger un texte en 1957. Pour rappel, The Mother of All Demos, qui montre notamment la première souris, date de 1968, et le premier traitement de texte de 1976.

Mais ce qui m’intéresse surtout, c’est qu’Easy n’est pas présenté comme un robot capable de tout faire. Il est juste correcteur et c'est intentionnel de la part de ses fabricants. Dans l’œuvre d’Asimov, les Terriens sont très hostiles aux robots (ne croyez pas le film I, Robot, il ne respecte pas du tout l’esprit d’Asimov), donc U.S. Robots cherche des solutions pour vendre ses machines malgré cette hostilité.

Easy est donc une machine spécialisée, cachée dans une université, qui fait un travail suffisamment précis et rentable pour qu'on puisse l'accepter.

En 1957, c’est de la science-fiction.

Aujourd’hui, si je demande à une IA de relire un article, personne ne trouve ça particulièrement extraordinaire.

Le robot d’Asimov est devenu banal. Il a simplement perdu son corps métallique et son nom de robot.

Ninheimer vs Easy

Le Correcteur raconte surtout un procès.

Easy est accusé d’avoir saboté le manuscrit d’un professeur, Simon Ninheimer. La machine aurait introduit des erreurs dans son travail, au point de mettre sa réputation en danger.
Finalement, on découvre que Ninheimer a saboté lui-même son livre pour faire accuser la machine et discréditer la robotique.

Le robot est donc innocent. Mais le discours final de Ninheimer est toujours intéressant soixante-dix ans plus tard :

Un livre doit prendre forme entre les mains de l’écrivain [...] Il doit travailler et retravailler, voir l’oeuvre se modifier au-delà du concept original.

Il décrit comme le cœur de son métier le fait de voir les phrases prendre forme et de les remodeler. C’est précisément le travail qu’Easy accomplit à sa place.

Puis il demande :

Que restera-t-il à l’érudit ? Une seule chose : le choix des décisions stériles concernant les ordres à donner au robot pour la suite du travail !

Ce n’est pas encore ce qui se passe dans la nouvelle, puisque c’est Ninheimer qui a demandé les modifications à Easy. Mais il imagine déjà le problème : si une machine fait tout le travail, que reste-t-il à l’auteur ? Essentiellement, lui donner des instructions.

C'est qu’on appelle, depuis quelques années, prompter.

Ninheimer se trompe de méthode mais Asimov ne lui donne pas tort.

D'ailleurs, Asimov a eu l’idée de la nouvelle alors qu’il refusait justement de confier ses propres épreuves à quelqu’un d’autre. Au téléphone avec son éditeur, pressé d’écrire une histoire, il explique qu’il est trop occupé à corriger les épreuves d’un manuel qu’il co-écrit. Quand on lui suggère de déléguer, la réponse est sans appel : « Impossible ! Je ne ferais confiance à personne d’autre ! » C’est en retournant à ses propres épreuves qu’il imagine un robot pour faire le travail à sa place. (source)

C’est probablement pour ça que Ninheimer est plus intéressant qu’il n’en a l’air.

Il est coupable, mais son argument ne l’est pas forcément. Comme dans Les Indestructibles 2 où Evelyn (la méchante) voit dans la protection qu’apportent les Supers une cause de faiblesse pour les humains : ce n’est pas parce que sa méthode est mauvaise qu’une personne a forcément tort.

Susan Calvin, qui défend le robot, répond à Ninheimer qu’il était condamné à échouer. Ce dernier lui répond qu’il était condamné à essayer. On sent déjà l’inéluctabilité de l'adoption.

Easy est encore un correcteur, simple et caché, qu’on ne voit pas comme dangereux. C’est peut-être à cause de cette banalité que j’avais mélangé cette nouvelle avec Pour que tu t’y intéresses.

Les Georges 😋

Donc dans ma tête, cette histoire était liée à une autre nouvelle d’Asimov : Pour que tu t’y intéresses (…That Thou Art Mindful of Him en anglais), publiée en 1974. Je me souvenais notamment d’un robot chargé de chasser les insectes.

Dans cette histoire, les Terriens ont toujours peur des robots et cela gêne les ventes de U.S. Robots. Ils créent donc deux robots particulièrement avancés, George Neuf et George Dix (moi je dis qu’Asimov est un visionnaire car les Georges sont toujours particulièrement avancés), qui cherchent une solution.

Leur idée est assez simple : arrêter de fabriquer des robots qui ressemblent à des humains et fabriquer à la place des machines spécialisées, mono-tâches.

Il y a donc ce robot-oiseau destiné à lutter contre les insectes. Il ne fait que ça, ne vise qu’une sorte d’insecte et s’arrête quand il n’y en a plus. C’est plus un outil qu’un robot.
Il ne parle pas, ne veut rien, ne semble pas intelligent.

Et c’est justement ce qui doit permettre aux humains de l’accepter.

C’est un peu comme ça que l’IA entre dans nos vies : une IA pour le code, une autre pour le sport, les courses, répondre au téléphone…

Des outils spécialisés plutôt qu'une intelligence artificielle générale.

Vilains Georges

Mais les Georges ne cherchent pas seulement à rendre les robots acceptables. Ils cherchent aussi à résoudre un problème logique posé par les Trois Lois de la Robotique.

Un robot ne peut porter atteinte à un être humain ni, restant passif, laisser cet être humain exposé au danger ;
Un robot doit obéir aux ordres donnés par les êtres humains, sauf si de tels ordres entrent en contradiction avec la première loi ;
Un robot doit protéger son existence dans la mesure où cette protection n’entre pas en contradiction avec la première ou la deuxième loi.

Que doit faire un robot lorsque deux êtres humains sont en conflit ou que deux humains donnent des ordres contradictoires ?
Les robots doivent protéger et obéir aux humains, mais lesquels ?

Les Georges poussent le raisonnement jusqu’à redéfinir l’humain. Puisqu’on ne peut pas dire qui est plus humain par son apparence, ils vont chercher ailleurs : dans les capacités. Et comme les robots sont intellectuellement supérieurs aux humains biologiques, pourquoi faudrait-il considérer les deux groupes comme équivalents ?

Ils finissent par distinguer les « êtres-humains-comme-eux » des « êtres-humains-comme-les-autres ». Et donc par devenir prioritaires dans les lois de la robotique.

Les Georges ne violent pas les Trois Lois, ils les réinterprètent. Et c’est là que ça devient beaucoup moins drôle. Comme Easy, ils ne sont pas méchants. Mais eux savent ce qu’ils font et où leur raisonnement peut mener.

Ils nous aident énormément tout en devenant dangereux pour nous : un pharmakon, un remède qui est aussi un poison.

C’est dans ces nouvelles que la nature des robots devient vraiment inquiétante, une idée qu’Asimov développera ensuite dans Les Robots et l’Empire.

Conclusion

Les deux nouvelles me paraissent nettement plus sombres que le reste des histoires de robots d’Asimov, en tout cas dans ma mémoire.
En général, les Trois Lois protègent l’humanité, parfois malgré elle, jusqu’à des extrêmes avec R. Giskard Reventlov et R. Daneel Olivaw.

Easy, lui, ne protège personne. Il corrige des virgules. Et c’est peut-être ça qui me plaît dans cette nouvelle. En 1957, Asimov imagine déjà une machine capable de faire un travail intellectuel très précis, suffisamment bien pour que l’humain puisse finir par lui faire confiance et il en a prédit les conséquences.

Aujourd’hui, je demande la même chose à une IA.

Post-scriptum

Le brouillon de cet article a d'ailleurs été rédigé par l’assistant IA qui a aussi corrigé mes virgules. Quelque part, Ninheimer me regarde en soupirant. Qu’il se rassure : j’ai modifié presque chaque phrase.

`class:` ou `alias:`, un choix de conteneur Symfony, et un choix d'ingénierie

Georges Cubas — Thu, 10 Sep 2026 13:58:05 +0000

Pourquoi un fake S3 jetable peut être préférable à MinIO

Deux décisions se sont posées en recettant un pipeline d'import qui écrit sur S3, sans le moindre accès AWS en local.

La première est une question technique : pourquoi alias: fonctionne alors que class: échoue dans un override when@dev ?

La seconde est une décision d'architecture : pourquoi choisir un double maison jetable plutôt que MinIO ?

Le S3 n'est finalement qu'un prétexte. Les deux réponses se généralisent à bien d'autres situations.

Le contexte

Une plateforme Symfony 5.3 importe des fichiers d'achats déposés par une centrale. Les lignes qui référencent une entité encore inconnue sont mises de côté dans un fichier de rejets sur S3 ; un écran d'administration permet ensuite de résoudre l'entité, puis de réimporter ces lignes.

Le service qui parle à S3, AwsService, tire ses credentials du rôle de tâche ECS (CredentialProvider::ecsCredentials()), donc d'une infrastructure AWS uniquement disponible en production. Le nom du bucket vient quant à lui d'une ligne de paramétrage en base.

En local, avec DDEV : aucune variable AWS_*, aucun conteneur MinIO.

Tout appel à read(), putPro() ou move() est donc voué à l'échec. Pire : getBucket() renvoie null et le service échoue silencieusement (return false, sans exception).

Une recette qui se contente de constater que « ça n'a pas planté » peut donc passer sans que rien ne se soit réellement produit.

Il fallait exercer ce flux pour trois tickets successifs sur le même périmètre, à chaque fois sur une implémentation prête mais pas encore livrée.

Deux solutions, toutes les deux valables

Deux approches étaient possibles.

MinIO. Ajouter un conteneur S3-compatible au .ddev/config.yaml de l'équipe, et faire accepter à AwsService un endpoint et des credentials statiques en environnement de développement.
Un double maison. Créer un fake de AwsService qui redirige les opérations vers le système de fichiers local (var/fake-s3/), puis le brancher à la place du vrai service par un bloc when@dev non commité. Une fois la recette terminée, le double disparaît.

Les deux sont valables.

Le choix n'est donc pas une question de faisabilité mais une question de contexte.

`when@dev` : substituer une implémentation pour un seul environnement

when@<env> (introduit dans Symfony 5.3) permet de scoper de la configuration à un environnement dans un fichier de configuration normal, plutôt que dans un fichier séparé sous config/services/dev/.

Le bloc n'est pris en compte que lorsque kernel.environment correspond à l'environnement <env> ciblé et il est traité après le corps principal du fichier. Il peut donc redéfinir des services existants.

En production, ce bloc n'est pas pris en compte : le conteneur de production ne contient aucune définition issue de cet override.

C'est précisément ce qui en fait un bon réceptacle pour un hack temporaire : tout l'override tient dans un bloc contigu et greppable, en fin d'un seul fichier.

On le voit facilement au git diff et le supprimer est trivial. De toute façon c'est pour un test, normalement on ne livre rien à la fin.

Le plus petit changement réversible possible.

# ─── TEMPORAIRE — recette locale, NE PAS COMMITER ───
when@dev:
    services:
        App\Service\AwsService:
            ...

`class:` contre `alias:` : redéfinir, ou simplement pointer ailleurs

Classiquement un override consiste à remplacer la classe utilisée par le service de test :

when@dev:
    services:
        App\Service\AwsService:
            class: App\Service\FakeAwsServiceForManualTesting

Dans le cas rencontré, cette configuration aboutit à une erreur au premier appel :

Too few arguments to function

App\Service\FakeAwsServiceForManualTesting::__construct(),

0 passed ... and exactly 3 expected

Pourquoi ?

Il faut regarder comment le conteneur a été construit.

Le services.yaml par défaut contient notamment des _defaults (autowire: true, autoconfigure: true, bind:...) puis une ressource :

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true
        autoconfigure: true

    # makes classes in src/ available to be used as services
    App\:
        resource: '../src/'

    # ...

Cette ressource enregistre notamment App\Service\AwsService et App\Service\FakeAwsServiceForManualTesting comme services, avec leurs définitions issues de l'auto-découverte.

Mais une configuration placée sous when@dev.services constitue une nouvelle couche de configuration. Il faut donc être prudent lorsqu'on y redéfinit un service : on ne doit pas supposer que toute la configuration implicite de la définition initiale sera conservée telle quelle.

Dans le cas rencontré, la redéfinition avec class: n'a pas conservé la configuration nécessaire au constructeur du fake. Le service s'est retrouvé avec une définition qui ne savait plus résoudre ses trois dépendances.

On pourrait rendre cette redéfinition fonctionnelle en lui redonnant ce dont elle a besoin, par exemple avec autowire: true ou des arguments: explicites.

Mais ce n'est pas ce que l'on cherche ici, on ne veut pas redéfinir AwsService.
On veut dire :

« Quand quelqu'un demande AwsService en développement, donne-lui plutôt ce service-là. »

C'est exactement le rôle d'un alias.

when@dev:
    services:
        App\Service\AwsService:
            alias: App\Service\FakeAwsServiceForManualTesting
            public: true

Un alias n'est pas une nouvelle définition. C'est un pointeur : l'identifiant App\Service\AwsService se résout vers le service enregistré sous App\Service\FakeAwsServiceForManualTesting.

La définition du fake existe déjà grâce à l'auto-découverte de src/. Elle conserve donc sa propre configuration et son autowiring.

On ne rouvre aucune définition : on change simplement vers laquelle le conteneur pointe.

public: true est nécessaire ici parce qu'une commande console jetable va également récupérer le service par son identifiant.

En bref

class: sert à configurer une définition ; alias: sert à dire « à cet endroit, utilise cette autre implémentation ».

Ce n'est pas une règle absolue pour toutes les substitutions Symfony, mais c'est un excellent réflexe lorsqu'on dispose déjà de deux services correctement définis : si le besoin est simplement de faire pointer un identifiant vers une autre implémentation, l'alias est l'expression la plus étroite de l'intention.

On ne reconstruit pas ce qui existe déjà. On change le pointeur.

Choisir en fonction du contexte, pas des capacités

MinIO est plus fidèle à une infrastructure S3 réelle. Ça n'en fait pas le bon choix ici.
Les axes qui ont tranché sont les suivants.

Rayon d'impact

La solution MinIO modifie AwsService qui est déjà commité, partagé par toute la plateforme, présent dans tous les environnements, y compris les chemins S3 de production.

La solution avec le double ne touche aucun code commité : un fichier neuf et un bloc when@dev, tous deux jetés à la fin.

Le coût d'une erreur est donc borné par ce qu'on met en jeu.

Amortissement, ou sur-ingénierie

MinIO est un investissement.

Il devient intéressant si l'équipe doit régulièrement tester des flux S3 en local. Le besoin réel ici était beaucoup plus petit : trois tickets sur deux semaines, puis probablement plus rien avant des mois.

Sans récurrence pour l'amortir, construire le harnais MinIO revient à payer un coût d'infrastructure, de configuration et de maintenance pour une capacité que personne n'a demandée.

Le besoin est temporaire, la solution peut donc l'être aussi.

Demi-vie et réversibilité

Le hack a une demi-vie de quelques jours. Le retirer, c'est supprimer le bloc et le fake, puis éventuellement vider le cache.

La modification MinIO est permanente par construction. Or une chose permanente réclame un propriétaire, de la documentation, une ligne d'onboarding et de la maintenance.

Une branche endpoint dans AwsService, que plus personne n'exerce quelques mois plus tard, est exactement le genre de code qui peut finir par accueillir un bug sans que personne ne s'en aperçoive.

Alignement des modes de défaillance

Le double échoue comme le comportement attendu par le métier :

fichier absent → lecture vide → badge « non importé ».

Pas de faux vert.

MinIO, lui, peut échouer pour des raisons qui n'ont rien à voir avec le métier : mauvais bucket, mauvais endpoint, path-style, région, credentials...

On se retrouve alors à tester le harnais de test.

Fidélité consommée

La recette valide ici du métier :

le moteur de réimport parse-t-il correctement le fichier de rejets ?
insère-t-il les bonnes lignes ?
bascule-t-il correctement l'état ?

Ce métier est indifférent à l'origine des octets.

Reproduire fidèlement la sémantique S3 (cohérence, multipart, ACL, etc.) ajoute donc une fidélité que le test ne lit jamais.

La fidélité qu'on ne consomme pas est un coût, pas une qualité.

Coût de communication

Un relecteur qui voit FakeAwsServiceForManualTesting et un bloc NE PAS COMMITER a tout compris en trente secondes.

MinIO demande davantage : une note de conception, une explication en équipe, une mise à jour du guide d'onboarding, et potentiellement une réponse à la question :

« C'est quoi ce paramètre endpoint sur AwsService ? »

Et cela, pendant toute la durée de vie de la solution.

Ce que le double contient

Le double ne cherche pas à reproduire S3.
Il reproduit uniquement la surface publique réellement appelée par le code sous test.

Les helpers privés (put, list, check) ne peuvent pas être surchargés ; on surcharge donc les wrappers publics utilisés par l'application :

class FakeAwsServiceForManualTesting extends AwsService
{
    private string $root;

    public function __construct(
        KernelInterface $kernel,
        LoggerInterface $logger,
        ParametersService $parametersService
    ) {
        parent::__construct($kernel, $logger, $parametersService);

        $this->root = $kernel->getProjectDir() . '/var/fake-s3';
    }

    public function read(
        string $app,
        string $filename,
        string $folder
    ): ?string {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        return is_file($path)
            ? (file_get_contents($path) ?: '')
            : '';
    }

    public function putPro(
        string $filename,
        string $content,
        string $folder
    ): bool {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        @mkdir(dirname($path), 0777, true);

        return file_put_contents($path, $content) !== false;
    }

    // putShop / putFTP / copy / delete* / list* :
    // même forme, sur var/fake-s3/.

    // move() n'est pas surchargée :
    // la classe mère la fait en copy()+delete().
}

Ce n'est pas un émulateur S3 et c'est volontaire. Le double implémente uniquement ce que le flux testé consomme.

Tester le métier sans navigateur

Pour piloter les actions du contrôleur sans passer par le navigateur, une commande console jetable injecte le même service métier que le contrôleur.

Ce service est désormais backé par le fake grâce à l'alias.

La commande appelle donc les mêmes méthodes que le parcours applicatif.

Tout le cahier de test peut se dérouler en CLI ; le navigateur ne sert plus qu'à confirmer l'UI.

C'est aussi ce qui rend défendable l'argument :

On a validé le métier, pas S3.

Le principe

Deux réflexes de séniorité ressortent de cette expérience, l'un technique, l'autre architectural.

Pour substituer une implémentation, on ne redéfinit pas sa configuration si l'on peut simplement pointer vers une autre définition existante. alias: exprime cette intention ; class: est à utiliser lorsqu'on veut réellement configurer ou redéfinir une définition.
On choisit la solution dont le coût, humain autant que technique, est proportionné à la taille et à la durée de vie réelles du problème : rayon d'impact, maintenance, onboarding, réversibilité, fréquence d'utilisation.

Un jetable assumé bat souvent un permanent mal entretenu.

Et quand le contexte change, on refait le calcul.

Ici, le besoin était temporaire. Le double l'était aussi.

Le signe que le choix était bon est peut-être le plus concret : le pattern a été capturé dans la base de connaissances de l'équipe, puis réutilisé tel quel sur les deux tickets suivants.

Vingt minutes de mise en place, trois fois, contre un chantier de plusieurs jours.

Ce n'était pas la solution la plus complète. C'était la solution proportionnée.

Anonymiser les données de PrestaShop

Georges Cubas — Mon, 18 Jul 2022 12:25:48 +0000

Pour créer un environnement de développement, on duplique celui de production. Sauf qu’il ne faut pas garder les infos personnelles des clients. Déjà c’est dangereux, si vous gérez mal votre affaire vous risquez d’envoyer des mails aux clients et ça force tous les développeur et intervenant à faire attention au RGPD.

Donc on anonymise tout, c’est plus simple.

Voici un script MariaDB qui anonymise les données clients : noms, prénoms, adresses, téléphones, e-mails, ip, communications. Il remplace les lettres par xxx en respectant la casse, les n° de téléphone par 0 en respectant le format et passe les IP en 127.0.0.1.

UPDATE ps_address pa
SET pa.alias = REGEXP_REPLACE(REGEXP_REPLACE(pa.alias, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.lastname = REGEXP_REPLACE(REGEXP_REPLACE(pa.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.firstname = REGEXP_REPLACE(REGEXP_REPLACE(pa.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address1 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address1, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address2 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address2, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.city = REGEXP_REPLACE(REGEXP_REPLACE(pa.city, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.other = REGEXP_REPLACE(REGEXP_REPLACE(pa.other, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.company = REGEXP_REPLACE(REGEXP_REPLACE(pa.company, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.phone = REGEXP_REPLACE(pa.phone, '[0-9]', '0'),
pa.phone_mobile = REGEXP_REPLACE(pa.phone_mobile, '[0-9]', '0'),
pa.vat_number = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.vat_number, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.dni = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.dni, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X');

UPDATE ps_customer c
SET c.lastname = REGEXP_REPLACE(REGEXP_REPLACE(c.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.firstname = REGEXP_REPLACE(REGEXP_REPLACE(c.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.email = CONCAT(c.id_customer, '@example.com');

UPDATE ps_customer c 
SET c.ip_registration_newsletter = '127.0.0.1' 
WHERE c.ip_registration_newsletter IS NOT NULL AND c.ip_registration_newsletter != '0';

UPDATE ps_customer_message cm
SET cm.message = REGEXP_REPLACE(REGEXP_REPLACE(cm.message, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
cm.ip_address = '2130706433';

UPDATE ps_customer_thread ct
SET ct.email = CONCAT(IF(ct.id_customer > 0, ct.id_customer, '0'), '@example.com');

La syntaxe de REGEXP_REPLACE n’est pas la même pour MySQL et MariaBD, donc il faudra adapter.

Programmer les popups de Popup Builder

Georges Cubas — Wed, 20 Oct 2021 10:18:03 +0000

La version gratuite du plugin WordPress Popup Builder ne permet pas programmer l’affichage des popups. Cependant elle créé le filtre sgpbOtherConditions qui permet de les désactiver.

Ce filtre est appelé pour chaque popup qui peut s’afficher sur la page et si l’argument ‘status’ à false est ajouté à ceux existants, la popup ne s’affiche pas.

    /**
     * Check Popup conditions
     *
     * @since 1.0.0
     *
     * @return array
     *
     */
    private function isSatisfyForOtherConditions()
    {
        $popup = $this->getPopup();
        $popupOptions = $popup->getOptions();
        $popupId = $popup->getId();

        $dontAlowOpenPopup = apply_filters('sgpbOtherConditions', array('id' => $popupId, 'popupOptions' => $popupOptions, 'popupObj' => $popup));

        return $dontAlowOpenPopup['status'];
    }

Pour désactiver automatiquement vos popups, vous pouvez ajouter ce code à functions.php

add_filter('sgpbOtherConditions', 'my_sgpbOtherConditions', 10, 1);

// update popin status
function my_sgpbOtherConditions($args = array()) {
    // if popup is already unactive, do nothing
    if (isset($args['status']) && $args['status'] === false) {
        return $args;
    }

    switch ($args['id']) {
        case 17938: // summer holiday active between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are not between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now < $from) || ($now > $to)) {
                $args['status'] = false;
            }           
            break;
        case 16412:  // covid reassurance unactive between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now >= $from) && ($now <= $to)) {
                $args['status'] = false;
            }
            break;
    }
    return $args;   
}

Ainsi la popup 17938 ne sera active qu’entre le 30 juillet et le 1 août 2021 alors que la 16412 ne le sera que le reste du temps.

DEV Community: Georges Cubas

A Dockerfile that says where it failed: splitting the RUN and retrying pecl install

The failing build

Splitting into several RUNs

Looking for a PECL mirror

The retry, in three versions

Testing the failure

What this changes

The code I never wrote

Cut my teeth on an Amstrad

What I stopped writing

One more layer

Why I still read

Back to 70 and 90%

aws-ecs-shell: stop rereading the ECS Exec docs before every intervention

The sequence

What it looks like

Three choices I find useful

The rest

A solarpunk garden for your GitHub profile, generated daily from your contributions

🌱 Where the idea came from

I Turned My GitHub Profile Into a Cyberpunk Console With a City Built From My Contributions

🌳 What's in the garden

🪏 Setting it up on your profile

🏡 Adapting the garden to where you live

🥗 Putting it in your README

GitHub README images based on prefers-color-scheme

📱 Three views, three sizes

🐛 Problems along the way

🐞 Similar projects

🐌 Limits and where it stands

🧮 Annex: fetching several years in one request

🌻 Sources

When We Stop Deciding - IBM, Asimov, and the Accountability Gap

The IBM rule

The Machines

The question isn't new

We won't get a Butlerian Jihad

Jev, or silent decision-making

Conclusion

Easy Fixes the Commas - Asimov's Galley Slave

Galley Slave

Ninheimer vs. Easy

The Georges 😋

Bad Georges

Conclusion

Postscript

The Dockerfile said `fr_FR.UTF-8`. PHP saw `C.UTF-8`.

The bug

"Just read the Dockerfile, right?"

Verifying the fix inside the real container

Result: the fix holds

Locking in the fix: a regression test

Why this was safe

Conclusion

Le Dockerfile disait `fr_FR.UTF-8`. PHP voyait `C.UTF-8`.

Le bug

« Il suffit de lire le Dockerfile, non ? »

Vérifier le correctif dans le container réel

Résultat : le correctif tient

Verrouiller le correctif : un test de non-régression

Pourquoi c'est sûr

Conclusion

Easy corrige des virgules

Le Correcteur

Ninheimer vs Easy

Les Georges 😋

Vilains Georges

Conclusion

Post-scriptum

`class:` ou `alias:`, un choix de conteneur Symfony, et un choix d'ingénierie

Le contexte

Deux solutions, toutes les deux valables

when@dev : substituer une implémentation pour un seul environnement

class: contre alias: : redéfinir, ou simplement pointer ailleurs

En bref

Choisir en fonction du contexte, pas des capacités

Rayon d'impact

Amortissement, ou sur-ingénierie

Demi-vie et réversibilité

`when@dev` : substituer une implémentation pour un seul environnement

`class:` contre `alias:` : redéfinir, ou simplement pointer ailleurs