Tarik Hireche

Resident.java

780 → 106 lines

The screens, an HTTP client, JSON parsing and the Scanner reads came out. What is left is a person's seven fields and the two operations that belong to them.

Menu.java

579 → 97 lines

Both sign-in screens, both registration screens, both post-sign-in menus and five input validators came out. It now picks between signing in and registering.

Test suite

9 → 35 tests

Across 6 files, from 3. The old suite needed a live third-party API to pass; mvn test now needs neither a network nor a terminal.

Duplication defects found

6

Each one surfaced while collapsing copies of the same code. Listed in the commit that removed them.

Three of us built this for a course and it worked fine on our machines. That was the problem. JUnit and Hamcrest were committed as jar files, and Gson came in through an IntelliJ setting that pointed at a folder on somebody's laptop. Anyone else who cloned it got a wall of errors. Moving it to Maven was the first thing I did.

The part I found most interesting was splitting up Resident.java. It was 780 lines and doing about five jobs at once: holding a person's details, drawing the screens, calling the city's API, parsing the JSON and reading the keyboard. I pulled the network and parsing code into its own package and the screens into another. Doing that turned up a bug I liked. The list of ten work categories existed in three separate copies that had drifted apart, so option 8 read "Travaux résidentiel" on one screen and "Travaux résidentiels" on another. A resident could file a request and then never find it again. It is one enum now, with a test that fails if the labels stop matching.

Most of the bugs I found came from the same cause: the same logic written out more than once. The other thing I took away is that separating the code that fetches from the code that parses is what let the tests run without a network. The old suite had one test that called the live city API, so the build failed on any machine that could not reach it.

Boards tracked

421

boards_known in the live health.json the sweep publishes. Read it yourself; the data repository is public.

Roles in the current feed

442

Across 268 distinct companies, after deduplication, scored and ranked. Counted from the live jobs.json.

Upstream postings scanned

3,331

last_count from the most recent sweep. Fetched with an ETag, so an unchanged source costs one 304 and no parsing.

Dashboard refresh

120 s

The page re-reads the feed on a timer. Every request is cache-busted, since the CDN sends max-age=300 and a five minute cache would undo the point of the tool.

I got tired of checking job boards by hand every morning, so I built something to do it on a schedule. I used AI-assisted coding for most of the implementation. What I did myself was decide how the pieces fit together, write a short spec for each one, and settle the JSON format they pass between them before any code existed. Then I reviewed what came back, tested it, and fixed what was wrong. Being able to read and debug that code is the part that matters to me.

It is in three parts. A private repo holds the schedule and my filters and runs the fetch. A public repo holds nothing but the JSON it produces. A static page reads that JSON straight from the browser. There is no server anywhere in it, which keeps it free to run and means there is nothing to keep alive.

The failure I did not anticipate is a scheduled job that quietly stops. It does not warn you. It keeps showing whatever it fetched last and looks completely normal, and you notice a week later. So every run now records when it ran and which sources answered, and the page shows how old the data is. I also learned how ETags work while building the fetch step: if a board has not changed since last time, it answers 304 and there is nothing to download or parse.

Shutdown after SIGTERM

2.5 to 3.1 ms

Seven runs against a worker supervised by sentinel, timed by waiting on the process. The same worker on its own was still alive at the ten second mark and had to be killed.

Child that ignores SIGTERM

5.003 s

Same setup with the worker deliberately ignoring the signal. Three runs, all within 1 ms of each other. That is the five second timeout doing its job.

Test suite

13 of 13

ctest on a release build, 33 s. CI runs build, test, shellcheck, docker and compose as separate jobs.

I wanted to understand what actually happens when a container is told to stop. Docker sends SIGTERM and waits ten seconds before killing it. Linux treats the first process in a container as a special case and will not deliver a signal to it unless that process has installed a handler, so a program sitting in that slot spends the whole ten seconds ignoring the request and then dies mid-work. sentinel takes that slot, passes the signal on to the real program, and gets out of the way.

The bug I spent the longest on was a gap between starting the child process and installing the handlers. A stop signal arriving in that window killed sentinel and left the child running loose, which is the exact thing the program exists to prevent. I knew about it for a while and left a TODO on it before working out that blocking those two signals across the start and unblocking them once the handlers were up closes the window.

A lot of this project was reading manual pages and then testing whether I had understood them. The thing that stuck: measuring is harder than it looks. My first shutdown number was ten times too high because I was checking in a polling loop and reading my own delay. Waiting on the process properly gave the real figure.