MUNKANAPLÓ / WORKLOG
Not a case study. An engineering worklog.
Finished systems hide most of the engineering work behind them. This log keeps the problems, wrong turns, fixes, trade-offs and verification steps that do not fit on a portfolio card.
103 of 103 entries are currently available in English. The remaining entries stay in Hungarian while translations are reviewed in batches.
18 entries ezen az pageon · 103 total
A localized rulebook is correct only if it proves the same rule
Multilingual rulebooks were not treated as simple translations. Their meaning was audited and had to remain consistent with the behaviour implemented in the digital game.
Open entry →The PDF would not render because the worker 'was there' — it was just being served incorrectly
The rulebook PDF-worker failure was misleading because the file existed. The browser needed a JavaScript worker with the correct MIME type, while an older broken copy could still return from cache.
Open entry →
The first playtest showed that a correct rule can still produce poor UX
The first real player feedback found several places where the system followed the rules correctly, yet the player still could not tell why something happened or what to do next.
Open entry →The terrain map and property artwork became functional visuals, not decoration
Adding artwork was not simply about making the game prettier. The map and cards needed to carry visually some of the information that had previously existed only as text.
Open entry →DigitalOcean deployment: the game server never entered a manual-SCP era
Production launch started with an automated DigitalOcean deployment pipeline. From the first real release, the goal was to use one repeatable and provable path to production.
Open entry →The first TLS certificate is not the same task as the hundredth renewal
Production TLS needed two distinct states: bootstrap certificate issuance and normal renewal. On the first run there is no certificate yet, so the assumptions of the steady-state system do not apply.
Open entry →The multiplayer smoke test was green — until we tested it like a browser
The WebSocket smoke test was missing the production Origin header, so it exercised a connection under different conditions from the real browser client. The test had to move closer to actual production traffic.
Open entry →Digitizing a board game is not a UI task: the rule engine had to come first
The first publishable version of The Last Spike quickly showed that the visual board was only the surface. The real product was a deterministic rules engine with a multilingual client built on top of it.
Open entry →The game barely existed, but it already had reproducible development and release workflows
Deployment was not postponed until the end of The Last Spike project. Development and release Docker workflows were introduced early so every later feature would travel through the same path to production.
Open entry →A local Docker port is not local just because we call it that
Development container port publishing had to be tightened because a convenient default can expose a service on every network interface even when it was intended to be reachable only from the developer machine.
Open entry →In an online board game, the browser cannot be the referee
The key multiplayer decision was to make the server authoritative over game state. Clients send intent; they do not send finished truth.
Open entry →We localized multiplayer text and made rule sources mandatory at the same time
Multilingual multiplayer needed more than translation keys. Rule and behaviour changes also required source documentation so the digital game could not quietly invent its own rulebook.
Open entry →A backup plugin is a production dependency
Updating BackWPup was not a maintenance detail. If the backup chain is unhealthy, the risk of the next upgrade increases immediately.
Open entry →WPCache: a faster site came with a new layer of state
Caching improved delivery performance, but it immediately introduced a new question: what must be invalidated, and when, so the site does not serve stale content faster.
Open entry →
WordPress 7: the core update was only the surface
The major core upgrade had to be handled together with theme and plugin compatibility. The goal was not to make the admin show a new version number, but to prove that the same site still worked afterwards.
Open entry →An old theme on a new core: compatibility is more than whether the layout breaks
Theme compatibility could not stop at a visual homepage check. Template hooks, widgets, admin options and legacy PHP patterns carried just as much upgrade risk.
Open entry →Updating ten plugins at once is fast; finding the broken one afterwards is not
Plugin updates were grouped so that cause and effect remained traceable when something failed. The goal was a diagnosable release, not the shortest possible batch update.
Open entry →A 200 OK on the homepage proves almost nothing about WordPress admin after an upgrade
Post-upgrade smoke checks were split across business and admin paths. A healthy homepage can still coexist with broken uploads, cron, login or plugin configuration.
Open entry →No matching entry in the complete worklog.