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
How do you show real KPI logic without leaking confidential data?
I wanted to present the reporting model and its evolution as reusable professional work, but the underlying security data could not leave the client context. Anonymization therefore had to preserve the pattern without exposing the state.
Open entry →In a production incident, the most useful first commit is often the one you do not write
During support work, the fastest route was repeatedly to collect reliable runtime evidence first and modify code only after the failing layer had been narrowed down.
Open entry →'It worked after clearing cache' is not a root cause
A Drupal cache rebuild can remove the symptom, but it does not explain why the system entered the wrong state. I did not want recovery commands to become a substitute for diagnosis.
Open entry →Not every deprecation deserves the same urgency
The upgrade audit produced many warnings. The useful work was not driving the count to zero, but ranking them by runtime exposure and whether they could block the next platform step.
Open entry →Data model first, slides second: how management reporting became stable
Instead of manually adjusting the presentation every week, the categories and calculations behind the report had to become stable. Only then could the visual layer be trusted.
Open entry →April lesson: good troubleshooting should leave the system better than it found it
Support tickets started creating long-term value when serious diagnoses fed something back into deployment, configuration, observability or the upgrade process.
Open entry →
The first step with an old WordPress site: create a reproducible snapshot
The Columbia Games WordPress code moved into its own repository in March. The first goal was not upgrading it, but establishing exactly what we were changing and what counted as the baseline.
Open entry →A Drupal upgrade is mostly not about changing the core version number
Preparing Drupal 10 for Drupal 11 again showed that an upgrade is not a Composer update. It is a dependency graph spanning contrib modules, custom code, PHP constraints and environment assumptions.
Open entry →`composer.lock` is not an administrative by-product
With dependency problems, the relevant question was not simply whether a package could be installed. The same resolved graph had to be reproducible across development, CI and production.
Open entry →The code was correct. The configuration was not the same.
In a classic enterprise failure, local and test environments behaved correctly while production-adjacent behaviour differed. The investigation eventually led to configuration drift.
Open entry →A change request is not paperwork when it is written as a technical contract
The CR/CAB process became useful when it described the change, risk, validation and rollback as one technical contract instead of a formal narrative.
Open entry →With API failures, the first question is not the JSON — it is the path the data took
In an external integration, the same value can pass through several transformations. Stable diagnosis required tracing it from its original source all the way to the outgoing payload.
Open entry →Production support and modernization run at different speeds inside the same system
Daily support does not stop because an upgrade is being planned. The important organizational task in March was separating urgent incidents from longer-term modernization without disconnecting the lessons between them.
Open entry →When Excel stops being a spreadsheet and becomes a critical system
The governance workbook accumulated enough logic, dependencies and manual operation that it had to be treated like a system: with versions, rules and failure modes.
Open entry →The macro-security warning was really an architectural signal
A macro security problem looked like user inconvenience at first, but it exposed how much operational behaviour depended on executable code embedded in an Office document.
Open entry →Not every automation needs a new platform — sometimes a small VBS bridge is the right tool
For one repetitive Office workflow, a focused VBS helper removed manual work faster and with less risk than rebuilding the process as a new application during an active audit cycle.
Open entry →ActiveX migration: invisible dependencies are always the expensive part
Replacing old Office controls was not mainly about finding substitute components. The difficult work was discovering everything that depended on the old behaviour.
Open entry →Status and risk do not belong in the same column
A task can be almost finished and still carry high risk, or remain open while representing little business exposure. Those two dimensions had to be modeled separately.
Open entry →No matching entry in the complete worklog.