MUNKANAPLÓ / WORKLOG
A kész rendszer önmagában keveset mond arról, hogyan dolgozunk. Itt a problémák, rossz irányok, javítások, kompromisszumok és ellenőrzések vannak időrendben — azok a részek is, amelyek egy szép portfólió-kártyáról lemaradnak.
100 bejegyzés
A PageSpeedben újra és újra ugyanaz a képprobléma jelent meg. Ahelyett, hogy minden oldalon külön scriptet írnánk, az Engine alpha.10 automatikus responsive WebP pipeline-t kapott.
Naplóbejegyzés megnyitása →Az új image feature után egy lifecycle import regresszió miatt a site-upgrade nem működött. A javítás nem állt meg a kód visszaállításánál: valódi upgrade folyamatot futtató regressziós teszt került mellé.
Naplóbejegyzés megnyitása →A platform érettségét nem egy új frontend feature adta, hanem három kevésbé látványos réteg: kétnyelvű docs parity, visszagörgethető fleet upgrade és pinelt release-infrastruktúra.
Naplóbejegyzés megnyitása →A projektkártyák megmutatják, mit építettem. A Munkanapló azt is, hogyan: hibás irányokkal, regressziókkal, deploydöntésekkel, biztonsági korlátokkal és azokkal a részletekkel, amelyek egy CV-ből kimaradnak.
Naplóbejegyzés megnyitása →
A migráció célja nem egy újratervezett oldal volt. A karakteres vizuál, a HU/EN/DE tartalom és a működő lead flow maradt, miközben a régi build- és management réteget natív KampányMűvek Engine v4 váltotta.
Naplóbejegyzés megnyitása →
A működő autós oldal Engine v4 migrációjánál először byte-megőrző átállási bizonyíték kellett. A fejlesztői rendszer, CI/CD és rollback változott, nem az ügyfél által látott artifact.
Naplóbejegyzés megnyitása →A régi Namecheap/PrivateEmail alapú PHP mail flow elvesztette az alapját. A statikus oldalhoz végül egyszerűbb és jobban illeszkedő FormSubmit megoldás került, saját köszönőoldallal és CAPTCHA-val.
Naplóbejegyzés megnyitása →A fleet-status nem egyszerű verziólista lett. Local source, Engine commit, release, deploy és live-QA állapotot kellett egymás mellé tenni úgy, hogy ne jelezzen hamis sikert.
Naplóbejegyzés megnyitása →A KampányMűvek akkor vált valódi platformmá, amikor a közös motor, generátorok és QA külön repóba kerültek, az oldalakban pedig csak a saját tartalom, template, kép és egyedi ellenőrzés maradt.
Naplóbejegyzés megnyitása →A futó Google Ads kampánynál nem volt elég egy látványos consent UI. A mérési parancsoknak ténylegesen a hozzájárulási állapot szerint kellett viselkedniük, telefonos és oldalmegtekintési konverziókkal együtt.
Naplóbejegyzés megnyitása →
A lokális CCM fejlesztéshez live legacy media proxy, cache, patient image mode és háttér warmup készült. A cél valós képek használata volt anélkül, hogy startupkor letöltenénk a teljes médiakészletet.
Naplóbejegyzés megnyitása →A post-deploy QA-t exact production SHA-hoz kötöttük, és PageSpeed API quota esetére helyi Lighthouse fallbacket adtunk. Így a külső szolgáltatás limitje nem tette vakká a release-t.
Naplóbejegyzés megnyitása →A production pipeline migration-aware és incremental lett: külön felismeri az adatbázis-, runtime-, web- és SEO változást, és csak azt a részt mozgatja, amelynek tényleg kell.
Naplóbejegyzés megnyitása →A library history migrációnál a schema és backfill sorrendje explicit dependency lett. Az unordered változatokat eltávolítottuk, majd verziózott, rendezett migration ID-k rögzítették a helyes utat.
Naplóbejegyzés megnyitása →A production migration runner közvetlen migration-time adatbázis-mentést és retentiont kapott, mert az éjszakai backup túl távoli állapot lehet egy adatot módosító release rollbackjéhez.
Naplóbejegyzés megnyitása →A production workflow túl sok shell logikát hordozott inline YAML-ban. A tényleges deploy döntések verziózott, self-testelt szerver scriptbe kerültek, a workflow pedig vékony SSH launcher lett.
Naplóbejegyzés megnyitása →A change detection és recovery korábban túl könnyen tekintett egy megpróbált production SHA-t jó alapnak. Ezt a last successful runtime SHA fogalmával kellett helyretenni.
Naplóbejegyzés megnyitása →A morning digest akkor lett valóban használható, amikor keresés, ranking, CRM állapot és utánkövetési teendő egyetlen idempotens munkafolyamatba került.
Naplóbejegyzés megnyitása →Az agent egyik nagy fordulata az volt, amikor a jelentkezési folyamat saját CRM ledgert kapott Gmail- és Calendar-watcherrel, Telegram értesítéssel és következő teendőkkel.
Naplóbejegyzés megnyitása →A ranking egyik fontos hibája az volt, amikor a földrajzi jogosultság és a szakmai illeszkedés ugyanabba a pontszámba kezdett belefolyni. A kettőt szét kellett választani.
Naplóbejegyzés megnyitása →A ranking v2 azért született, mert a naiv kulcsszavas pontozás magasra rakott olyan hirdetéseket is, amelyek sok ismert technológiát említettek, de a szerepkör lényege teljesen más volt.
Naplóbejegyzés megnyitása →A rangsorolási hibák egy része nem scoring bug volt, hanem adatminőségi probléma: aggregátor navigáció, több listing és oldalszöveg keveredett egy rekordba.
Naplóbejegyzés megnyitása →A grounded AI requirement review szándékosan a determinisztikus ranking után futott, korlátozott mennyiségű jelölten. Így az LLM review kiegészítette, nem helyettesítette a kiszámítható rendszert.
Naplóbejegyzés megnyitása →A requirement review egyik regressziója megmutatta, hogy a modell hajlamos egy feladatleírást kötelező követelménnyé emelni. Explicit evidence guard és determinisztikus fallback kellett köré.
Naplóbejegyzés megnyitása →Az Ollama requirement review túl sok latencyt kapott a modellindításból és felesleges reasoningből. Warmup, retry és strukturált no-thinking fast path tette használhatóvá.
Naplóbejegyzés megnyitása →A ranking finomhangolás közben külön diagnosztikai export és AI health eszköz készült. Nem volt elég a végső pontszám; reprodukálni kellett a döntés inputjait és köztes jeleit.
Naplóbejegyzés megnyitása →
A MonsterInsights és Google Site Kit frissítése látszólag rutin plugin maintenance volt. Valójában a tracking lánc miatt külön ellenőrzést igényelt, mert egy csendes mérési hiba napokig észrevétlen maradhat.
Naplóbejegyzés megnyitása →A guided gameplay visszajelzésnél finom határt kellett tartani: a rendszer mutassa, miért nem érvényes egy lépés és mi a következő lehetőség, de ne vegye el a döntést.
Naplóbejegyzés megnyitása →A board highlight és latest-track marker stabilitásához ki kellett venni a lokalizált szövegre és egy böngésző-specifikus viselkedésre épülő azonosítást.
Naplóbejegyzés megnyitása →Az országonként külön kezelt táblakoordináták egyre több speciális kódot követeltek. Egységes geometriára és validált koordináta-adatokra váltottunk.
Naplóbejegyzés megnyitása →Egy tisztának szánt USA board backgroundról gyorsan kiderült, hogy hiányos. Nem építettünk rá újabb kompenzáló kódot: visszavontuk, majd réteges artwork rendszerrel oldottuk meg.
Naplóbejegyzés megnyitása →Az USA tile-ok pozícióját a hivatalos track scheme-hez igazítottuk, majd a fontos SVG metszéspontokat automata tesztben rögzítettük, hogy egy későbbi layout-refaktor ne mozdítsa el őket csendben.
Naplóbejegyzés megnyitása →A pályák, körök és kanadai kiadás finomításánál az volt a cél, hogy a különbségeket adatként kezeljük, ne országonként másolt szabályágakkal.
Naplóbejegyzés megnyitása →A többnyelvű rulebookokat nem egyszerű fordításként kezeltük. Auditáltuk a tartalmat és a digitális játék viselkedésével együtt kellett konzisztensnek maradniuk.
Naplóbejegyzés megnyitása →A szabálykönyv PDF worker hibájánál a fájl jelenléte félrevezető volt. A böngésző JavaScript workert várt megfelelő MIME-mal, majd a régi példány cache-ből is visszatért.
Naplóbejegyzés megnyitása →
Az első valódi játékos-visszajelzés több olyan pontot talált, ahol a rendszer szabály szerint helyesen működött, a játékos mégsem értette, miért történt valami vagy mi a következő lépés.
Naplóbejegyzés megnyitása →A grafika hozzáadásánál nem egyszerűen szebbé tettük a játékot. A cél az volt, hogy a térkép és a kártya vizuálisan is hordozza azt az információt, amit addig csak szöveg mondott el.
Naplóbejegyzés megnyitása →A production bevezetésnél rögtön automatizált DigitalOcean deployment készült. A cél az volt, hogy az első valódi release-től kezdve ugyanaz a bizonyítható út menjen végig.
Naplóbejegyzés megnyitása →A production TLS-nél külön kezeltük a bootstrap cert-kiadást és a későbbi normál megújítást. Az első körben még nincs cert, ezért a kész rendszer feltételeit nem lehet rá alkalmazni.
Naplóbejegyzés megnyitása →A WebSocket smoke tesztből hiányzott a production Origin header. Emiatt olyan kapcsolatot próbáltunk, amelyet a valódi böngésző más feltételekkel hoz létre. A tesztet közelebb kellett vinni a valós forgalomhoz.
Naplóbejegyzés megnyitása →A The Last Spike első publikálható verziójánál gyorsan kiderült, hogy a látványos tábla csak a felszín. A valódi termék a determinisztikus játékszabály és az arra épülő többnyelvű kliens volt.
Naplóbejegyzés megnyitása →A Last Spike-nál nem hagytuk a deploymentet a projekt végére. A fejlesztői és release Docker workflow már a korai verziónál bekerült, hogy minden későbbi funkció ugyanazon a pályán menjen productionig.
Naplóbejegyzés megnyitása →A fejlesztői container port publishingját szigorítani kellett, mert egy kényelmes alapbeállítás könnyen minden hálózati interfészre kinyitja azt, amit csak a gépről akartunk elérni.
Naplóbejegyzés megnyitása →A multiplayer átállásnál a legfontosabb döntés az volt, hogy a szerver legyen az autoritatív játékállapot gazdája. A kliensek szándékot küldenek, nem kész igazságot.
Naplóbejegyzés megnyitása →A többnyelvű multiplayer során nem csak fordítási kulcsokat adtunk. A szabály- és viselkedésváltozásokhoz forrásdokumentációt is kértünk, hogy a digitális játék ne kezdjen önálló szabálykönyvet írni.
Naplóbejegyzés megnyitása →A BackWPup frissítése nem „karbantartási apróság” volt. Ha a mentési lánc hibás, a következő upgrade kockázata azonnal nagyobb lesz.
Naplóbejegyzés megnyitása →A cache bekapcsolása javította a kiszolgálást, de azonnal megjelent egy új kérdés: mikor és mit kell invalidálni, hogy ne gyorsan szolgáljunk ki régi tartalmat.
Naplóbejegyzés megnyitása →A nagy core-frissítést theme- és plugin-kompatibilitással együtt kellett kezelni. A cél nem az volt, hogy az admin kiírja az új verziót, hanem hogy ugyanaz az oldal tényleg működjön utána.
Naplóbejegyzés megnyitása →A theme-kompatibilitás vizsgálata nem állhatott meg a kezdőlap vizuális ellenőrzésénél. Template hookok, widgetek, admin opciók és régi PHP-konstrukciók ugyanúgy kockázatot jelentettek.
Naplóbejegyzés megnyitása →A pluginfrissítéseket úgy csoportosítottuk, hogy hiba esetén megmaradjon az ok-okozati kapcsolat. A gyors batch update helyett diagnosztizálható release kellett.
Naplóbejegyzés megnyitása →A frissítési smoke-ot üzleti és admin útvonalakra bontottuk. Egy zöld homepage mellett ugyanúgy lehet törött feltöltés, cron, login vagy plugin konfiguráció.
Naplóbejegyzés megnyitása →A különböző keretrendszerek sokszor ugyanazt a működést kérdezik más nyelven. A cél az lett, hogy a közös kontrollhoz közös evidence forrás tartozzon, ne három párhuzamos mappa.
Naplóbejegyzés megnyitása →A több hónapos governance munka végén az egyik legfontosabb teszt az volt, hogy a nyilvántartás és riportolás más számára is követhető-e szóbeli magyarázat nélkül.
Naplóbejegyzés megnyitása →A vezetői idővonalat úgy kellett felépíteni, hogy ne csak határidőket mutasson, hanem azt is, mely döntés vagy evidence blokkolja a következő lépést.
Naplóbejegyzés megnyitása →A WordPress upgrade és az auditmunka látszólag távoli feladat volt, mégis ugyanazokat az alapelveket használta: source of truth, reprodukció, ellenőrzés és visszaállítás.
Naplóbejegyzés megnyitása →A reprodukálható Docker-környezet nem jelentheti azt, hogy az adatbázis-jelszó és más érzékeny értékek verziókövetésbe kerülnek. A configot environment-alapúvá tettük.
Naplóbejegyzés megnyitása →A WordPress oldal betöltött, ezért a stack késznek látszott, de médiafeltöltésnél előjött a host és container közötti fájljogosultság-probléma.
Naplóbejegyzés megnyitása →Egy frissítés utáni furcsa routing viselkedésnél a kézenfekvő plugin-gyanú helyett a webszerver-konfiguráció bizonyult hiányosnak.
Naplóbejegyzés megnyitása →A legacy WordPress fejlesztői környezet Dockerbe költözött. A valódi munka az volt, hogy a szerveren felhalmozódott implicit feltételeket explicit, reprodukálható konfigurációvá alakítsuk.
Naplóbejegyzés megnyitása →A custom Docker image gyorsan szemétlerakóvá válhat. Szét kellett választani a runtime-függőséget, a projektfájlt és a fejlesztői kényelmi eszközt.
Naplóbejegyzés megnyitása →A Dockeres WordPress alapértékei nem tükrözték a valódi oldal használatát. A feltöltési és memória limiteket a production működéshez kellett igazítani, nem véletlenszerűen megemelni.
Naplóbejegyzés megnyitása →A host gépen telepített WP-CLI verzió és PHP környezet újabb eltérést hozott volna. Az eszközt ezért ugyanabba a container runtime-ba tettem, amelyet ténylegesen teszteltünk.
Naplóbejegyzés megnyitása →A container HTTP-t látott, a böngésző HTTPS-t. Ha ezt a WordPress nem tudja, redirect loop és hibás asset URL a jutalom. A proxyhatárt explicit kezelni kellett.
Naplóbejegyzés megnyitása →A productionból származó adatbázis helyben a live domainre akart visszairányítani. A fejlesztői indulás része lett a biztonságos URL-normalizálás.
Naplóbejegyzés megnyitása →A helyi WordPress indítást scriptbe szerveztük, de a valódi minőségét az adta, hogy ellenőrizte az előfeltételeket és érthető hibával állt meg félkész állapot helyett.
Naplóbejegyzés megnyitása →Nem próbáltuk minden production részletet egy az egyben lemásolni Dockerbe. Inkább tudatosan rögzítettük, mi azonos, mi eltér, és melyik eltérés számít tesztelési kockázatnak.
Naplóbejegyzés megnyitása →A közelgő core- és theme-frissítés előtt a mentés megléte kevés volt. Azt kellett tudni, hogy a fájlok és adatbázis együtt, értelmes restore-folyamattal állnak rendelkezésre.
Naplóbejegyzés megnyitása →A hónap legnagyobb eredménye nem egy új funkció volt, hanem az, hogy a legacy oldalnak lett reprodukálható helyi runtime-ja, eszköztára és visszaállítható története.
Naplóbejegyzés megnyitása →Több nyitott tételről kiderült, hogy technikailag már elég információnk van, de a lezáráshoz audit- vagy jogi döntés kell. Fontos volt nem fejlesztési problémává alakítani mindent.
Naplóbejegyzés megnyitása →A riportlogikát és a fejlődést szerettem volna újrahasznosíthatóan bemutatni, de a mögöttes security adatok nem kerülhettek ki. Az anonimizálás ezért nem kozmetika volt.
Naplóbejegyzés megnyitása →Support közben többször az bizonyult a leggyorsabb útnak, hogy előbb összegyűjtöttük a tényleges futási bizonyítékot, és csak utána nyúltunk a kódhoz.
Naplóbejegyzés megnyitása →Drupal supportban a cache rebuild gyakran megszünteti a tünetet, de attól még nem tudjuk, miért került rossz állapotba a rendszer. Ezt nem akartam lezárt hibának tekinteni.
Naplóbejegyzés megnyitása →Az upgrade audit sok figyelmeztetést hozott. A hasznos munka nem az volt, hogy darabra eltüntessük őket, hanem hogy futási út és jövőbeli blokkolás szerint rangsoroljuk.
Naplóbejegyzés megnyitása →A prezentáció kézi igazgatása helyett a riport mögötti kategóriákat és számításokat kellett stabilizálni. A vizuális réteg csak ezután lett megbízható.
Naplóbejegyzés megnyitása →A support ticketek akkor kezdtek hosszú távon is értéket termelni, amikor minden komolyabb diagnózisból visszakerült valami a deploy-, config- vagy upgrade-folyamatba.
Naplóbejegyzés megnyitása →A Columbia Games WordPress kódja márciusban külön repóba került. Az első cél nem az upgrade volt, hanem hogy pontosan tudjuk, mihez nyúlunk és mi számít kiinduló állapotnak.
Naplóbejegyzés megnyitása →A Drupal 10→11 felkészítésnél újra kiderült, hogy az upgrade nem egy composer update, hanem contrib modulok, custom kód, PHP-korlátok és környezeti függőségek közös gráfja.
Naplóbejegyzés megnyitása →Egy dependency-problémánál nem az volt a kérdés, hogy „felmegy-e a csomag”, hanem hogy ugyanaz a dependency graph reprodukálható-e fejlesztői, CI és production környezetben.
Naplóbejegyzés megnyitása →Egy tipikus enterprise hibánál a lokális és tesztkörnyezet rendben viselkedett, miközben production közelében eltért az eredmény. A nyom végül konfigurációs drifthez vezetett.
Naplóbejegyzés megnyitása →A CR/CAB folyamat akkor lett hasznos, amikor nem formális leírásként kezeltük, hanem a változtatás, kockázat, validáció és rollback technikai szerződéseként.
Naplóbejegyzés megnyitása →Külső integrációnál ugyanaz az érték több transzformáción mehet át. A hibát csak úgy lehetett stabilan megfogni, ha végigkövettük a forrástól a kiküldött payloadig.
Naplóbejegyzés megnyitása →A napi support nem áll meg azért, mert közben upgrade-et tervezünk. Márciusban a legfontosabb szervezési feladat a sürgős hibák és a hosszabb távú technikai adósság szétválasztása volt.
Naplóbejegyzés megnyitása →A governance nyilvántartás annyi logikát, függőséget és kézi műveletet gyűjtött magába, hogy már rendszerként kellett kezelni: verzióval, szabályokkal és hibalehetőségekkel.
Naplóbejegyzés megnyitása →Egy macro security probléma elsőre felhasználói kényelmetlenségnek látszott, valójában azt mutatta meg, mennyi működés függ futtatható kódtól egy irodai dokumentumban.
Naplóbejegyzés megnyitása →Volt olyan ismétlődő Office-folyamat, ahol egy célzott VBS segédprogram gyorsabban és kisebb kockázattal szedte ki a kézi munkát, mint egy teljes rendszerátépítés.
Naplóbejegyzés megnyitása →Régi Office-objektumok és vezérlők kiváltásánál nem a cserekomponens volt a legnehezebb, hanem annak felderítése, hogy mi minden támaszkodik a régi viselkedésre.
Naplóbejegyzés megnyitása →Egy feladat lehet technikailag majdnem kész és mégis magas kockázatú, vagy lehet nyitott úgy, hogy üzleti szempontból alig jelent veszélyt. Ezt a két tengelyt külön kellett kezelni.
Naplóbejegyzés megnyitása →A bizonyíték felelősségét sok helyen azzal azonosították, aki legutóbb elküldte a dokumentumot. Ez működésileg téves volt, ezért szerepkörre és forrásrendszerre bontottuk a felelősséget.
Naplóbejegyzés megnyitása →A vezetői mutatók mögé visszakövethető adatút kellett. Nem elég, hogy egy szám jól néz ki; később meg kell tudni mondani, mely tételekből és milyen szabály szerint állt elő.
Naplóbejegyzés megnyitása →A hónap során nem egyetlen nagy rendszert építettünk, hanem sok apró ponton csökkentettük a kézi működést és tettük láthatóvá a forrásokat, felelősségeket és szabályokat.
Naplóbejegyzés megnyitása →Az első nehézség nem technikai volt: a jogi követelményeket olyan működési feladatokká kellett fordítani, amelyekhez tényleges bizonyíték, felelős és ellenőrizhető állapot tartozik.
Naplóbejegyzés megnyitása →Egy hosszú Excel-lista azt mutatta, hogy valami hiányzik, de nem mondta meg, hogyan jutunk el a hiánytól az auditálható állapotig. Ezt kellett feladatrendszerré alakítani.
Naplóbejegyzés megnyitása →A technikai állapotot úgy kellett vezetői szintre emelni, hogy közben ne tűnjön el belőle a bizonytalanság, a függőség és az a rész, amely tényleges döntést igényel.
Naplóbejegyzés megnyitása →Ugyanarra a kontrollra több fájlnév, mappa és emberi megnevezés létezett. A valódi kérdés nem az volt, hogyan nevezzük el, hanem hogyan bizonyítjuk, hogy melyik az aktuális.
Naplóbejegyzés megnyitása →Több kérdésnél a technikai csapat már bizonyítani tudta a rendszer működését, de az még nem jelentette automatikusan azt, hogy az auditkövetelmény értelmezése is lezárt.
Naplóbejegyzés megnyitása →A sok feltöltött fájl látványos előrehaladást mutathat, de auditnál az számít, hogy a kontroll tényleg működik-e, és a bizonyíték kapcsolódik-e hozzá.
Naplóbejegyzés megnyitása →Egy tavalyi képernyőkép vagy export lehet tartalmilag helyes, mégsem bizonyítja a jelenlegi működést. Külön kellett kezelni a meglétet és a frissességet.
Naplóbejegyzés megnyitása →A státusz százalékosítása csábító volt, de több esetben a forrásadat nem volt elég stabil ahhoz, hogy egyetlen szám valódi pontosságot jelentsen.
Naplóbejegyzés megnyitása →A kézzel összerakott auditcsomag helyett egyre fontosabb lett, hogy a bizonyíték útja megismételhető legyen: ugyanabból a forrásból ugyanazzal a logikával újra előálljon.
Naplóbejegyzés megnyitása →A hónap végére egyértelmű lett, hogy a munka legnagyobb része nem új kontrollok kitalálása, hanem a már létező technikai állapot értelmezhetővé és ellenőrizhetővé tétele.
Naplóbejegyzés megnyitása →Nincs találat erre a szűrésre.