Nah, hát akkor adjunk a rendszerhez egy új funkcionalitást. Ebben a konkrét esetben szeretnék hordozható dolgokra hirdetéseket pakolni. Pl szeretnék a hirdetők megcélozni azokat az androidos tableteket, amiket a Samsung gyárt. Hogy miért? Mert hosszú piackutatások után azt találták, hogy ez a réteg nagy valószínűséggel veszi meg a termékeiket. Vagy valami ilyesmi.

Namármost a feladat jól van definiálva. Egy harmadik féllel van is megállapodás, ami szolgáltat mindenfajta információt useragent-ek alapján a készülékről. Nekem csak annyi a dolgom, hogy lekérjem.

Itt kezdődnek a problémák. Egy lekérés mondjuk a szolgáltatott XML file-ból túl sok idő. Meg kell nyitni, be kell parse-olni, és akkor még ha szerencsésen csinálom akkor is valszin lineáris. Szóval amikor a rendszer indul, be kell rakni az egészet a memóriába. Nade csak úgy simán nem elég, mert mivan ha valaki operációs rendszer szerint akar szűrni, más meg valami más kombinacióra. Akkor hogy elég gyors legyen (ez még csak előszűrés, igazából a teljes hirdetéskiválasztáshoz van kb 3-5 milisec) sok különböző kulcsokra és hashtáblákra van szükség. Van kb 8k telefonfajta, nemtomhány oprendszer és gyártó... mondjuk azt hogy kb 10-12k kulcsos táblám lesz. Miltikey for the rescue, fingerprint a kulcsokról, máris csak 8 byte-osak a kulcsaim. Persze az adatok amire mutatnak az másik 16-24 byte, de sajnos ezt nem tudom elkerülni. Szóval 10k kulcs, 24 byte adat, 5 szerverparkban, összesen kb 600 szerveren... még nem csináltam semmit és máris 137MB adatot pakoltam memóriába a teljes rendszeren.

Ennél sokkal szebb, amikor tényleg adatokat kell összehasonlítani. Tegyük fel hogy minden hirdető rájön, hogy ez egy jó kis funkcionalitás. Kiválasztanak 1-2 oprendszert és 5-6 nagyobb márkát. Most hogy milyen a típusa az végülis mindegy, meg legyen bármilyen verzió. Azért mondjuk minimum os verziót megadnak. Szóval ez 2*8 byte oprendszer adat (igen itt lehet még optimalizálni, elvben nem kellene long id, de a harmadik fél csak közepesen konzisztens), kell 6*8 byte a márkákra, meg mondjuk 2*2*8 byte a verzióra. 96 byte. Még néhány byte hogy a többi adatot null-ázuk. Szóval >100 byte adat, de jelenleg 200k ilyen halmaz van a rendszerben. 20 MB adat a memóriába per szerver.

Akkor még le kell kérnem a mit sem sejtő böngésző adatait (500k-szor másodpercenként), user agent-eket parsolni (1M ua parse-olásnál átlagosan 0.0178ms per ua) és azt veszem észre, hogy kicsinként hozzápakoltam 100MB adatot szerverenként a memóriába, úgyhogy heap-et kell növelni. Megnöveltem a kiválasztást kb 0.3ms-al, ami épphogy még elfogadhatóan benne van a 3-5ms kiválasztásba (igen, draga hashelni). És én még azt hittem ez nagyon optimalizált kód egy nagyon egyszerű feladatra. Jah, és ez főleg még csak az USA, ázsiában ez sokkal több lesz.

Namármost ez csak 4-5 új adat volt és kb négy nap munkám. Jelenleg kb 1000 paramétert használunk egy felhasználónál. Van még mit tanulnom.

Alapvetően már programozgatok egy ideje. Csináltam kisebb programokat, egyetemi házikat, gyűjtöttem statisztikákat pókerezésről a UPinak, dolgoztam cégnél és ilyenek. Namármost mind amit csináltam, azt kb újra kellett gondolnom és újra kellett tanulnom. Szerintem leginkább azért, mert a környezet amiben dolgozom megváltozott.

Régen belőttem az éppen használatos szerkesztőmet, legyen az turbo/borland pascal, visual studio, emacs vagy eclipse, megírtam a kódot ami helyesnek gondoltam, kicsit debuggoltam a hibákat, futtattam és nézegettem, és amikor meg voltam elégedve, akkor kész volt. Ez már nem megy. Igazából már a szerkesztő programnál gondokba szoktam ütközni.

Most főleg Java-ban kódolok, hát az eclipse jónak tűnik. Dehát git-et használok, úgyhogy felnyomok rá egy eGit-et. De hát nagyon sokáig tart újraindexelni a 2-3 millió sok kódon végzett változtatásokat. Meg kihal heap/GC/memória okokból, és build-elni is 5-6 perc. De végülis ez nem baj, mert most amin dolgozom annak úgysincs user interface-e, ahol látnám mit változtattam. Jah, de még adatbázis sincs igazán. Igazából teljesen esélytelen, hogy a szimpla kis gépem (64bit linux box, 8GB memória) kibírja azt a rendszert, ami 2000 szerveren fut, a világ különböző pontjain, és másodpercenként 500k kérést dolgoz fel.

Szóval akkor vissza vi/emacs szerkesztőkhöz (most nézem a CodeMirror-t), háttérben fut a headless jvm, és közben nézem hogy hogyan használhatnám a google protobuffer-jét adatkommunikációra, főleg a primitív könyvtárakkal teleoptimalizált kódjaimhoz. Közben bevezettem egy dinamikus adatstruktúrát, mert egy benchmarkból kiderült, hogy 50 elem alatt a bináris keresés egy listában gyorsabb mint egy hash-elés. (Hehe, igen a hash túl drága nálunk, ha lehet bitmask-elni vagy bináris keresni az jobb, de ha túl nagy az adathalmaz implementálnom kell bloom filter-t). Nézem hogyan tudok szimulálni adatforgalmat (mégha hdfs-t nem is), és közben mint állat írogatom a unitteszteket... különben ötletem sincs mit változtattam amíg a QA környezetébe be nem kerül a dolog. Bár a unit tesztek amúgy is alap. Főleg hamár óránként néhány másik változtatás amúgy is bekerül másik fejlesztőktől abba részbe, amit én is fejlesztek. Meg lássuk be, azért a continuous integration és regressziós tesztelés azért már nem újdonság sehol.

Mi a nagy változás? Két érdekes dolog van, egyrészt a fejlesztés fókusza megváltozott. A tradicionális fejlesztéstől eltértem, nem terméket fejlesztek, hanem platformot. És mint egy dolog ami megfelelő ecosystem nélkül nem működik, hátbizony mások a játékszabályok. Másrészt meg a technológia és a fejlesztési folyamatok megváltoztak. Teljesen mindegy, hogy éppen mit fejlesztesz, érdemes megnézni és tudni, hogy milyen technológiák vannak. Weblapot akarok fejleszteni? Node.js, css, html5, webGL, kávé és js, rails vagy django, wp, joomla vagy drupal, és a többi és a többi. Adatokat kell feldolgozni? Mennyit és hogyan? SQL vagy noSQL, MangoDB, hive, spark, zookeper és oozie, sok-sok más technológia. És érdemes ismerni, mert kevésszer van két teljesen ugyanolyan probléma, és még kevesebbszer van hogy nincs valami közeli megoldás már valahol.

Szóval megváltozott, hogy hogyan fejlesztek, és nem csak mert nagyobb cégnél vagyok és több emberrel fejlesztek mint eddig bármikor. Nem csak azért, mert a szokványos fejlesztőkörnyezetem már nem működik a problémák mérete miatt. Hanem mert megváltoztak a játékszabályok, megváltozott, hogy mi számít egy technológiai cégben és mert olyan ütemben fejlődik a világ, amivel nehéz lépést tartani, de érdemes. Szóval sebességre és méretre optimalizálok platformot. Mostmár mindent tudtok.

Elézést annak, aki eljutott idáig a cikkben, és nem technikai beállítottságú. A másik dolog amiért elnézést kell kérnem az a hunglish része a cikknek. Biztos vagyok benne, hogy mindenre van szép magyar kifejezés, de ezt azt hiszem már bebuktam.