Entropy.fi progress, July–December 2025 2

Earlier write-up (January–June 2025):
https://chiph.art/en/project/2025/elevating-entropy-fi-my-contributions-january-june-2025

This post covers July → December. It’s based mainly on the git history—but written for general portfolio readers (many of whom are also Entropy members): what changed, why it mattered, and what I learned while maintaining a real system that people use.

If I had to describe this half-year in one sentence:

I made Entropy.fi easier to maintain without making it feel “maintenance-only”: admin workflows improved, the foundation was modernized, and the project gained a real testing safety net for the first time.

What changed (for people who just use the site)#

• Admin work became less fragile, especially around volunteer scheduling (Nakkikone) and event-related tooling.
• Event pages and UI polish continued, including background effects that have been part of Entropy.fi for years—this period focused on making them more manageable and reliable, not “inventing effects”.
• The site got clearer structurally, with improvements that help readability, accessibility, and consistency.
• A lot of “invisible reliability” work happened: fixes for rare edge cases, upgrades, and—most importantly—introducing a testing system that didn’t really exist before.

1) Nakkikone: admin-side volunteer timetables that can be updated in real time#

Nakkikone is an admin tool used to build volunteer timetables for events. This half-year I removed a painful limitation: earlier, once someone took a shift, the timetable was basically “locked”, and updating it became awkward (adding was possible, but proper editing wasn’t). Now admins can keep adjusting the timetable even after signups. The next step is allowing organizers to move an already-taken shift while automatically notifying the member affected.

There’s a pattern here I keep running into with admin tools: they often work fine in a “perfect plan” scenario, but event organizing is rarely perfect. Timetables change. People cancel. Roles get reshuffled. So making the admin tool behave well under change is a bigger quality improvement than adding yet another feature checkbox.

2) A testing foundation (new for this project)#

The biggest structural change this half-year is that the project gained a proper testing foundation.

Before this, improvements were largely validated manually. That works up to a point, but it also means refactoring is risky: you either move slowly, or you accept that you might accidentally break something unrelated. This half-year I started building a safety net: tests around key routes and flows, admin areas, payments/shop logic, RSVP, and other parts that tend to break in subtle ways.

For readers who don’t write code: tests are basically “the project remembering what it’s supposed to do”. They don’t prevent all problems, but they change maintenance from “hope and manual checking” into “verify and adjust”.

This also explains why so many commits in this period are about stability: setting up the framework, fixing failures, getting the test environment reliable, and then tightening things once it works.

3) Background effects: not new, but made more manageable and reliable#

Entropy.fi has had animated event backgrounds for years. This period wasn’t about adding a gimmick—it was about making the system behind those effects easier to control and less fragile.

From the git history, the work falls into three kinds:

• Configuration: making it possible to define event-specific settings cleanly, with sensible defaults.
• Consistency: aligning presets and settings so they match the “legacy feel” where that matters (so old events don’t suddenly look wrong).
• Reliability during navigation: animations should keep behaving even when the site uses modern navigation patterns and partial page updates.

I like this category because it’s a good example of “member-visible polish” that still has real engineering constraints underneath: the goal is that it feels effortless.

4) UI structure and accessibility polish (small changes that add up)#

Some improvements aren’t about features—they’re about the site feeling more deliberate:

• Clearer structure (landmarks, semantic headings)
• More consistent page layouts (less “why is this page different?”)
• Template/markup cleanup (removing weird whitespace, simplifying headings, making pages easier to scan)

A specific SEO/structure example from December was adding a hidden frontpage H1. These are tiny changes individually, but together they improve how the site reads—both for humans and for tools.

5) Modernizing the foundation (so the project stays maintainable)#

This half-year included several significant upgrades and maintenance steps:

• Doctrine 4 upgrade (late November)
• Symfony 7.4 upgrade (early December), with follow-up work to ensure things still work correctly
• continuous dependency updates and cleanup

I treat this work as part of the product, not a distraction from it. If you postpone foundation upgrades long enough, they stop being “maintenance” and turn into “emergency migration”.

A rough timeline (for readers who like a narrative)#

July: sitemap and routing fixes, early polish (including rain animation, map/location work).
August: localization, calendar/location improvements, progressive image/placeholder work, and admin refinements.
September: continued UI/theme work and a big chunk of work around background effect configuration and behavior.
October: major push on testing + static-analysis cleanup and safer structure (also lots of shop/payment related correctness work).
November: Nakkikone groundwork → usability → “in use”, plus Doctrine 4 and config cleanup.
December: Symfony 7.4, a big UI/component organization push, semantic/SEO polish, and a strong finishing wave of tests and cleanup.

What I’m proud of in this period#

• Building a testing foundation where there effectively wasn’t one before.
• Making admin tools behave better under real-world change (especially Nakkikone timetables).
• Continuing to improve the look and feel of the site without turning it into something fragile.
• Keeping the project modern enough that future work remains feasible.

What’s next (my likely focus)#

• Nakkikone: moving already-taken shifts safely with notification to the affected member.
• Continue growing the safety net so larger refactors become low-risk.
• Keep polishing UI structure and “small friction” points that members notice.
• Iventory and rental system improvements.