Szuper napom van. A hangulatomról a következő dalszöveg sokkal jobban beszél.

Summoning - Farewell. Lyrics:

Who can find you clear springs of waters, but I can!
Who can tell you the age of the moon, but I can!
Who can call the fish from the depths of the sea, yes I can!
Who can change the shapes of the hills and the headlands, I can!

I have been a sword in the hand,
I have been a shield in a fight,
I have been the string of a harp,
I can shift my shape like a god.

Farewell, leave the shore to an ocean wide and untamed
Hold your shield high, let the wind bring your enemy your nightmare
By the bane of my blade, a mighty spell is made and
Far beyond the battle blood shall fall like a hard rain.

Tekintve, hogy én a display marketingben dolgozom, most főleg arról lesz szó. Hogy valamelyest megmutassam mennyire fragmentált ez a piac, itt van egy slide a legtöbb szereplőről: http://www.lumapartners.com/lumascapes/display-ad-tech-lumascape/.

Nade hogyan is működik ez.

Amikor egy felhasználó (pl Mongúz) meglátogat egy honlapot (pápaszemes.hu) akkor bizony a Mongúz elé tárul nemcsak a honlap tartalma, hanem egy hirdetés távcsöves vadászpuskákról is, szépen oldal szélén.

Amikor a honlapra érkezik a felhasználó, a honlap (vagy mobil alkalmazás pl) elküld egy üzenetet egy aukciósháznak, miszerint a Mongúz meglátogatta a honlapot, és itt van egy 320x200-as hirdetésnek hely. Amelyik hirdető a legtöbbet kínálja annak eztet én el akarom adni.

Az aukciósházak továbbküldik úgynevezett DSP-knek (demand-side platform) az üzenetet. Ők képviselik ugyanis a hirdetőket. Ők tudják, hogy a hirdetők kiket akarnak megcélozni, és náluk vannak az adatok és algoritmusok, hogy megmondják mennyit érdemes fizetni a Mongúzért azon a honlapon.

Namost közel sincs az összes adat egy kézben. A hirdetőknek vannak saját, nem publikus adataik, vannak cégek akik arra specializálódnak, hogy megmondják a Mongúz nemét, keresetét, és szokásait, cégek akik adatokat tudnak a honlapról, másik cégek akik tudják, hogy a Mongúz tiltólistán van a repülőgép társaságoknál, úgyhogy olyan hirdetéseket ne is mutassanak, stb. Ezekkel egy jó DSP össze-vissza van integrálva, merthogy sok adat az jó adat.

Megvan, hogy a Mongúznak a legjobb eséllyel puskát lehet eladni, ezt a honlap is támogatná, irány az aukció. Aki nyer az nyer, aki nem az majd licitál újra. Csakhogy írjak számokat is a mesébe, az én cégem (amelyik mellesleg DSP főleg, meg picit néhány más dolog) az kb 500000 beérkező kérésnek válaszol. Másodpercenként. Jah, és a teljes aukció, hálózati kommunikációval együtt, kb 120-150ms alatt dől el. Szóval sok-sok dolog történik itt, kevés idő alatt.

Akkor most a vadászpuska hirdetés nyert.

Mi is kerül a honlapra?

Alapvetően a hirdetés. Meg kicsi pixelek, amiket nem vesz észre a felhasználó. Meg süti a böngészőbe. Szóval igazából abban a pillanatban, hogy az a hirdetés kikerül egy honlapra, a lap elkezd lövöldözni. Elküld néhány byte-ot nekünk, mert akkor tudjuk, hogy megjelent. Elküld néhány byte-ot jobbra, mert ők adták a felhasználóról az adatot (akiről máris több adat van), meg balra, ahol egy másik szolgáltató most már tudja, hogy mi milyen felhasználó azonosítóval láttuk el a Mongúzt. Aztán meg ha valaki erre ráklikkel, akkor aztán már azt is tudjuk, hogy ráklikkelt. Sőt, azt is hogy korábban milyen hirdetéseket látott, hátha az is befolyásolta a Mongúzt hogy erre klikkelt.

Szóval adatgyűjtés történik ezerrel. Ebből azért keveset lehet látni. Akit ezek jobban érdekelnek picit, nézzek hirdetések kódjait és használjon dolgokat (http://www.ghostery.com/)

Szóval aki nem találta volna még ki, én a marketing iparban dolgozom. Konkrétabban digitális hirdetésekkel foglalkozom, és azon belül is az úgynevezett display marketing-el.

Alapvetően digitális hirdetésekből három fajta létezik:

• Search advertisement: amikor is a felhasználó egy kereséssel pontosan megmondja, hogy mit is akar csinálni egy adott helyen. Például ha az Amazon-on beírod, hogy asztali lámpát akarsz nézegetni, jó eséllyel te egy asztali lámpát akarsz venni.
• Social advertisement: amikor is a felhasználó megmondja hogy kicsoda, mik érdeklik, kik a barátai, őket mik érdeklik, és alapvetően lehet tudni, hogy mit csinálsz és mi érdekel. Például ha a Facebook-on tagja vagy vagy "like"-oltad az összes környékbeli gyúró helyet, ne csodálkozz ha protein port akar neked eladni egy hirdetés.
• Display advertisement: amikor egy felhasználó meglátogat egy oldalt. Pl felmész a cnn.com-ra, és oldal megjelenik neked valami hirdetés.

Azt hiszem most már mindenki látja, hogy Google és Facebook miből él meg és miért. Bizony, a felhasználóik vannak olyan kedvesek, hogy mindent elmondanak magukról. Semmi gond amúgy, a display esetében is mindent tudunk a felhasználókról (csak azt nem, hogy pontosan kik, de az senkit sem érdekel).

Namost a hirdetések céljai is többfélék lehetnek.

• Targeting: amikor azt akarja a hirdető, hogy valamit csináljon a felhasználó. Például klikkeljen egy hirdetésre (impression), vagy vásároljon valamit amire a hirdetés mutat.
• Branding: amikor az a lényeg, hogy sok releváns felhasználó lásson egy hirdetést. Mert ha 10-szer látod a BMW-t, akkor biztos meg akarod venni majd jobban. De ha nem is, akkor is tudod, hogy mi a BMW és hogy mi az új termékük.
• Retargeting: ez messze a legokosabb. Ha pl meglátogatsz egy konyhabútor boltot, akkor más oldalakon is észreveheted, hogy annak a boltnak a hirdetéseit fogod látni. Mertha ott voltál, akkor akartál is valamit ott csinálni. Akkor most más oldalakon is kapod a motivációt, hogy visszamenj.

Ennyit mára az áttekintésből.

Akkor kicsit más téma. Gondoltam leírom a véleményemet arról, hogy mit is jelent a technológia manapság, és mennyiben látom másként a Magyarországon tapasztalt klasszikus informatikai struktúrát.

Szóval általában ha számítógépekkel foglalkozó emberekről van szó, akkor viszonylag kevés pozícióról beszélnek általában az emberek. Vannak programozók akik ülnek a gép előtt és kódolnak, vannak rendszergazdák vagy ITsek, akik a nyomtatót javítják, meg vannak a menedzserek. És ha valaki ezt mondja, akkor már felvilágosult embernek minősül. Mindenesetre egy valami közös ezekben az emberekben, konkrétan mindannyian cégek egyéb funkcióit támogatják. A nyomtató kell a titkárnőknek, a program az eladóknak. Még ha honlapot is tervez valaki, hát az is megrendelésre csinálja legfeljebb.

Ilyenkor kerülök bajba. Már háromszor próbáltam elmagyarázni, hogy ez egy technológiai cégnél nem így működik, és én igazából ebbe nem nagyon tudom magamat sorolni, de mindháromszor elbuktam.

Szóval a számítógépekkel és technológiákkal foglalkozó emberek nagyrésze egyik dobozba sem fér bele. Merthogy például a legtöbb velem dolgozó ember tud programozgatni, de közel sem mondanám, hogy bármilyen szinten is jó kódot írnának. Mégis nagyon jól értenek mondjuk az adatbányászathoz, és képesek irányítani 1 petabyte adatot minden nap. Vagy eszméletlen jó géptanulásos modelleket programoznak le, ami miatt nagyon pontosan meg tudjuk mondani, hogy kinek érdemes milyen hirdetéseket megmutatni. De vannak akik nagyon jó UI teszteket tudnak csinálni, és vannak akik hatékonyan tudnak nagy mennyiségű adatokat vizualizálni a felhasználóinknak. Namost egyik sem tud nyomtatót javítani, és azt se mondanám hogy olyan jól programoznának. Menedzsernek meg végképp nem mondanám őket.

Naszóval ez egy probléma. A másik, hogy nem igazán írok programok más cégeknek, vagy segítek a cégemen belül más funkciókat. Amúgy igen, csak nem nagyon. Nekünk alapvetően a termékünk maga a szoftver. De nem eladjuk, hogy installálják CDn, hanem mint platform lehet hasznosítani. Konkrétan cégek előfizetnek ránk, felállítanak a szoftverünk segítségével egy teljes marketing kampányt, és figyelgetik, módosítgatják, és kapják róla a jelentéseket. Persze van egy halom sales-ünk, sok-sok tanácsadó, de alapvetően a szoftver használatát veszik meg. Meg az eszméletlen mennyiségű adatot, amit szolgáltatunk elemzésekre.

Na itt jön még egy sor mérnök, akiket nehéz elmagyarázni, mert legtöbben csak legfeljebb a telefonos szupportról hallottak. Nekünk három adagnyi emberünk van akik foglalkoznak problémákkal, attól függően hogy kinek milyen problémái vannak. Vannak akik elemzéssel foglalkoznak, és arról bizonyosodnak meg, hogy az adatok helyesek. Vannak, akik technológia problémákat oldanak meg, azaz ha valami nem úgy működik ahogy kellene, akkor ők nagyrészt meg tudják oldani (ehhez elég jó problémamegoldó képességek kellenek, nagyon-nagyon kevés probléma jut el a szoftver mérnökökhöz). És van egy harmadik réteg, akik pedig az üzleti problémákat oldják meg. Egy részük a klienseinkkel foglalkozik, a másik pedig a partnereinkkel.

Van még ezenkívül egy csoport akik a termék leírásokat csinálják és szedik össze mindazt ami kell a projekthez (ők állnak a klasszikus menedzserekhez a legközelebb, de nem dirigálnak hanem összedolgoznak másokkal hogy sikeres legyen egy projekt), van egy IT részlegünk (igen, outsource-oltuk), és van egy hatalmas operációs csapatunk. Hamár van kb 2000 szerverünk 5 különböző szerverparkban szerte a világon, akkor azért nem árt.

Ezek azok, akik valamilyen módon technológia pozíciókban vannak. Nincs olyan üzleti operációs emberünk (biz ops), aki ne tudna PIG-szerű (SQL megfelelője) lekérdezéseket indítani egy Hadoop cluster-en. Nincs olyan termék menedzserünk, aki ne értené mi a különbség egy string-et vagy egy long-ot hozzáadni az adatbányászatunkhoz. Ezek a technológiával foglalkozó emberek a cégben.

Szóval amikor valaki megkérdezi, hogy én ugye valami programozó informatikus vagyok, akkor igyekszem azt mondani, hogy nem, én szoftver mérnők vagyok és egy terméket/platformot gyártok. Ezt meg persze senki nem érti.

Jah, és én mit is csinálok... én egy olyan szoftver mérnök csapatba tartozom, akik a szoftver termékünk skálázható infrastruktúráját fejlesztik, hogy kellően gyors legyen és robusztus. Magyarul, hogy nagyon sokan tudják használni, nagyon sok hirdetési tranzakciót tudjunk lefolytatni, és ezeket mind nagyon gyorsan csináljuk. A következő cikk asszem a marketing iparról kell hogy szóljon.

Nincs már az Ulmarnak versblogja be kell érnetek silány utánzatokkal. Ez a vers remélem kárpótol mert nagyon megérintett és az tényleg őrült április volt.

Az április megőrült,
még nem sütött a nap,
egy hétig folyton ittam,
így lettem józanabb.
 
Az április megőrült,
fagyot suhint ma rád,
egy író ír s hetente
eladja a hazát.
 
Az április megőrült,
csikorgó hó esett,
sokan már elfutottak
s a szívük megreped.

Az április megőrült,
vonít a fagy felett,
három barátom elment
s mindhárom elveszett.
 
Az április megőrült,
vad zápor hullt időnként,
az egyik él, bolond,
s nem sejti, hogy mi történt.
 
Az április megőrült,
s kiöntött sok folyó,
a másik az nem él már,
agyában két golyó.
 
Négy napja, hogy megölték.
A harmadik fogoly.
Gyümölcseink lefagynak.
Szájam körül mosoly.
 
Vigyázz magadra, - hallom,
hogy mindent megtorolj!

Következő érdekesség.

Teszem azt változtatok valamit a kódón. Namost a kód úgy működik, hogy nagyrészt az adatok betöltődnek egy szerveren (nevezzük PSnek), aztán kinyomjuk nehány másik szerverre (nevezzük Distro-nak), majd szépen él sok-sok szerveren ahol a döntéseket csináljuk (legyen AS). Szóval változtatok valamit a kódon, és szeretném ha az a változás úgy megtörténne mindenhol. Mondjuk betöltésnél véletlenül rossz adatot töltök valahova (teljesen fikció, ez persze ma biztos nem történt meg), és azt most valaki a kódban kijavította.

Szóval az ember berakja gyártásba a kódot, és örül neki hogy kijavította a hibát. Vagy mégsem. Merthogy ezek a szerverek a gyors felállásra vannak beállva, tehát ha nem változott meg az adat valahol, akkor az AS leállásnál csak lementi az egész memóriáját ahogy van, majd újraindulásnál betölti. A rossz adattal. Tekintve, hogy neki még senki sem mondta, hogy az adat hibás.

Tehát vissza kell nyúlni a PSre, és megmondani az adatnak, hogy akkor most frissüljön. PS-en frissül, Distro megkapja, AS-ek átveszik, minden rendben. Pontosabban lenne, ha nem eszméletlen mennyiségű adatról lenne szó. Tehát amikor minden adathalmazhoz hozzányúl az ember, akkor a szerverek túlterheltek lesznek, a hálózat belassul, mi meg pénzt vesztünk. Szóval egyszer csak részhalmazt lehet frissíteni. Egy kis elírás, regresszión átesett valahogy (ilyen jó képzelt hibát csináltam... lett is belőle sok-sok megbeszélés hogy hogy esett ez át QAn), és a következő pillanatban 4-ember dolgozik másfél órát, hogy helyreálljon minden. Áhhh, az elírások szépségei.

Legalább megtanultam gyártásban debuggolni. Eszméletlen milyen érdekes kapcsolók vannak beépítve a rendszerbe. Meg lehet jelölni egyes adathalmazokat debugra, és olyan információkat gyűjtünk, amire nem is gondoltam volna. Pl mindent.

Kicsit véresen komollyá vált hirtelen ez a blog.

http://hu.wikipedia.org/wiki/Turul_%28mad%C3%A1r%29

Fentebb a turul a wikipediáról, semmi vicces.

Legalábbis számomra ti, hogy vagytok vele?

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.