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
After 102 entries, we stopped managing translation backlog and made bilingual content the default
Translating the full Worklog showed that deferred localization is technical debt. After reaching 102/102, we changed the workflow so every new entry is written in Hungarian and English together and verified by the same QA chain.
Open entry →
WebP optimization moved from a site task into an Engine build feature
The same image problem kept reappearing in PageSpeed reports. Instead of writing another per-site script, Engine alpha.10 gained an automatic responsive WebP pipeline.
Open entry →alpha.10 broke the site-upgrade CLI — so a regression test protects it now
After the new image feature, a lifecycle import regression broke `site-upgrade`. The fix did not stop at restoring the code: it added a regression test that executes a real upgrade path.
Open entry →Documentation, fleet upgrades and the CI supply chain all got stricter on the same day
The platform did not mature because of a new frontend feature, but because of three less visible layers: bilingual documentation parity, rollback-safe fleet upgrades and pinned release infrastructure.
Open entry →The portfolio gained a Worklog: the finished system does not tell enough of the story
Project cards show what I built. The Worklog also shows how: wrong turns, regressions, deployment decisions, security constraints and the details that do not fit into a CV.
Open entry →
Gödi Sittes: the Dzsoni design stayed, the legacy runtime went
The migration was not a redesign. The distinctive visual identity, HU/EN/DE content and working lead flow stayed in place while the old build and management layers were replaced by native KampányMűvek Engine v4.
Open entry →
Madmasel: we changed the platform before changing the site
For the Engine v4 migration of a live automotive site, the first requirement was a byte-preserving migration proof. The development system, CI/CD and rollback changed; the customer-facing artifact did not.
Open entry →We did not keep an entire mail backend alive for one contact form
The old Namecheap/PrivateEmail-based PHP mail flow had lost the service it depended on. For a static site, FormSubmit proved to be a simpler and better-fitting replacement, with a dedicated thank-you page and CAPTCHA.
Open entry →One command had to tell the truth about five sites
`fleet-status` could not be just another version list. Local source state, Engine commit, release, deployment and live-QA status had to appear together without reporting false success.
Open entry →The Engine and each site finally got separate lifecycles
KampányMűvek became a real platform when the shared Engine, generators and QA moved into their own repository, leaving each site with only its own content, templates, images and site-specific checks.
Open entry →Consent Mode v2: a cookie banner is not a measurement strategy
For a live Google Ads campaign, a polished consent UI was not enough. Measurement commands had to follow the actual consent state, including phone-click and page-view conversions.
Open entry →
We did not want to copy 32,000 product images onto every developer laptop
Local CCM development needed real legacy catalogue images without mirroring the entire production media library. An allowlisted live-media proxy, local cache, patient image mode and detached warmup made that practical.
Open entry →Live QA has to test the SHA that is actually running
Post-deploy QA was tied to the exact production SHA, with a local Lighthouse fallback for PageSpeed API quota failures. A third-party service limit could no longer make a release effectively blind.
Open entry →A CCM deploy should not restart everything just because there was a commit
The production pipeline became migration-aware and incremental: database, runtime, web and SEO changes are detected separately so only the parts that actually need work are rebuilt or refreshed.
Open entry →The backfill was fast. Too bad the schema had to exist first.
For the library-history migration, schema creation and backfill became an explicit dependency. Unordered variants were removed and versioned migration IDs recorded the only valid execution order.
Open entry →The database backup belongs immediately before the migration, not sometime that day
The production migration runner gained a database backup taken at migration time, plus retention rules. A nightly backup can be far too old to serve as the recovery point for a release that changes live data.
Open entry →We moved deployment logic out of GitHub YAML so it could finally be tested properly
The production workflow had accumulated too much inline shell logic. Deployment decisions moved into a versioned, self-tested server script, leaving the GitHub workflow as a thin SSH orchestration layer.
Open entry →The latest deploy is not necessarily the latest good deploy
Change detection and recovery were too willing to treat the most recently attempted production SHA as a valid baseline. The fix was to model the last successful runtime SHA as a separate piece of state.
Open entry →No matching entry in the complete worklog.