2017. április 22., szombat

ki profitált a kerub-ból idáig...

Mivel intenzíven használok pár szoftvert, bugreportok és patchek formájában néhány project már profitált abból, hogy a vonaton munkába menet nem csak a tájat nézem. Pár közűlük, amikre emlékszem:
  • Jetty és CXF bugreportok, ezek a csákók igazán rendesek voltak és pár nap alatt kijavította mindkét csapat a hibákat.
  • Shiro bugfix
  • Kotlin - többnyire apróságok a stdlib-ben, egyszer egy apróság a compilerben, párszor az IDE-ben.
  • Infinispan bugreportok - bár utóbb rájöttem hogy nem érdemes sietni az infinispan upgradekkel mert a release után úgyis találnak pár hibát és kiadnak rá egy javítást. Egy kis türelem sok időt megtakarít.

Már csak azért is meg akartam ezeket a projekteket említeni pozitív példaként, mert negatív példa is akad bőven az OSS projectek között.

2017. április 10., hétfő

Sky job interview

Egyszer, amikor a brexit még a posztapokalpitikus sci-fi horrorpornókomédia kategóriába tartozott, voltam a Sky tévétársaságnál állásinterjún. Az jutott most eszembe, hogy ettől esetleg megmentselek titeket :-D
Elég nagyipari mennyiségben hívták be az embereket, délre kellett odaérni és a portán nyolcan ültünk az időpontban, azt hiszem 2 nő, voltak környékbeliek és távolabbról érkezők, fehérek és feketék, idősebbek fiatalabbak, ufók és alienek. Szerencsére azért jó arcok voltak és szendvicseket lehetett választani. Az elején gyorsan elmagyarázta a HR-es arc a szabályokat, aki nem teljesít úgy, ahogy elvárnák, annak szólnak és mehet. Ez kellemetlenül hangzik, de végülis jobb egy délutánt várostnézni Londonban, mint még pár órát kuksolni egy cég irodájában. Egyébként elég hosszú procedúra volt. Ilyen körök voltak, hogy:
  • pair programming egy önkéntes alkalmazottal
  • valami kis problémamegoldás
  • architektura design egy pár fazonnal whiteboard-nál
és így tovább, mindenesetre este 6-ra ketten maradtunk, mindenki másnak mondták hogy kezitcsókolom, ekkor véget ért a program és a túlélőket körbekisérték a studióban. Ez jó volt legalább, mert tv-studióban még soha nem jártam. Kicsit lepukkantnak tűnt, de oda se neki, láttam már rosszabbat.
Elbúcsúztam és igyekeztem elkapni az utolsó repülőgépet hazafelé, akkor úgy tünt, minden oké. De aztán soha nem hívtak. Pár héttel később írtam a HR-es csókának, hogy gondolom hogy "nem" a válasz, csak érdekelne hogy miért.
Azt válaszolta, hogy mert nincs tapasztalatom a pair programmingban. Ez egyébként tényleg így is van, sehol nincs ilyesmi a CV-ben, de ez a válasz volt az, ami nogo listára tette nálam a sky-t, mert ezt így értettem:

Kedves Izé,

Miután eljöttél az interview-ra, végre elolvastam a CV-d és akkor jövök rá: baszod te egyáltalán nem is vagy édzsájl! Valamiért azt hittem hogy na mindegy...
Dögölj meg,
HR

Szóval azért, hogy a HR-es végül elolvassa a CV-t az interview után, azért szerintem kár kidobni a pénzt repülőjegyre.

Az átlagos ember a maga hibáiból tanul, ezt remélem kipipálhatom, ti meg próbáljatok jobbat :)

2017. március 6., hétfő

kerub - a packaging frontról jelentjük

Kerub. Kicsit megint hanyagoltam a blogolást, de a munkára igyekeztem időt szorítani. A nagyobb dolgok amikbe belerúgtam mostanában:
  1. yum/dnf repok CentOS 7-hez és Fedora 23-hoz. yum (vagy dnf) install után a kerub elindul és megy ugyanúgy, mint a fejlesztőkörnyezetben. A házi jenkins buildjei fel is küldik minden változtatás után a friss RPM-eket.
    Készül az Ubuntu és a Debian csomagoló is.

    A csomagokról annyit el kell mondanom, hogy bár amennyire tudom, korrekt módon csomagolok (nem kell kikapcsolni a selinuxot, lecsapni a firewallt, stb), a disztrók csomagolási útmutatóját egyszerűen betarthatatlannak találom és figyelmen kívül hagyom. Konkrétan az, hogy az infinispant és a jgroups-ot is rpm csomagokból oldjam fel a WEB-INF/lib helyett, az esélytelen.
    Ezt alighanem más is így találta, mert a disztrók összesen 0 db java webalkalmazást tartalmaznak. A kerub se lesz benne soha.

    A csomagolás egyébként olyan, mintha az apolló űrhajót mamutbőrbe
  2. Egy teljesen új projectet kezdtem integrációs tesztekhez. Bár egész sok integrációs teszt található a fő projektben, ami simán a maven embedded jetty-jével elszalad, ezek nem képesek olyan eseteket lefedni, mint pl cluster, de akár még olyat sem, hogy virtuális gépben futó "host", mert futniuk kell jenkinsben, a linuxos desktopomon, travis-ban, meg a halál répáján.
    Az új projekt ilyen integrációs teszteket tartalmaz, csinál egy virtuális gépet, feltelepíti a kerub webappot, tesz elé load balancert, ad hozzá hostokat, feltölt egy virtuális merevlemez imaget, elindít egy virtuális gépet, satöbbi.
    Nyilván ez úgy magában is elég lassú lesz, úgyhogy karrier szempontokat szem elött tartva úgy gondoltam ez most had legyen groovy-ban. Grooovy!!!
  3. Már majdnem ott tartok, hogy a web**cket biztonsági teszteket befejezzem. Hozzá kell tennem persze hogy nem csak a tesztekről van szó hanem konkrétan az implementációról is :-D

Na jó, ennyi bőven sok, dolgozzunk!

2017. január 10., kedd

IT szegregáció

Középiskolában kb 20 fős osztályban volt 5 lány, ez talán még ma sem számítana egy döbbenetesen rossz aránynak egy informatikai középiskolában. Az 5 lányból 4 alkotta az osztályelsők csoportját, ők mindenből jók voltak. Ennek ellenére az utolsó év végén a szak egyik vezető tanára az értékelésben elmondta, hogy bár ez nagyon szép eredmény, ez egy "férfi szakma".
Ezt lehet úgy is nézni, hogy persze ez is egy vélemény, de ezek tizenéves lányok voltak és szerintem komolyan szivükre vették. Csak ültünk és kussoltunk, ahogy szoktuk, senki nem kérdezte hogy mire gondol, kell-e 50 kilós szervereket felcipelni a tizedikre gyalog, vagy tettlegességig elmenni a singleton pattern feletti vitában.

A másik iskolai élményem a témában az ELTE-ről Lakatos László tanárúr munkássága, aki matematika gyakorlatot tartott akkoriban. Ő egy ijesztően furcsa alak, az elejétől a végéig görcsösen vigyorgott órákon, szúrós megjegyzéseket tett a hallgatókra általában de a lányokra határozottan rászállt. Ribancnak és suttyónak nézett mindenkit és nem tartotta vissza a véleményét, én valamennyire megszoktam azokat, akik nincsenek magas véleménnyel rólam, de a lányok máshogy viszonyultak ehhez. Egész kemény csajok jártak az esti szakra, de az első félév második felére már egyetlen lány se járt be az óráira, kénytelen volt minket szórakoztatni olyan kérdésekkel, mint hogy biztosan százezreket fogunk keresni (höhh...), milyen fasza autónk lesz, mert a suttyókat mivel lehetne ugratni.
Nálam már messze túl lenne a határon az amit ő csinált, de az ELTE-nek ez a 2000-es évek elején még teljesen oké volt, meg ahogy nézem a kar dolgozóinak névsorát még most is az.

Azt hiszem ennyi elég is lenne ahhoz, hogy ne csodálkozzunk a helyzeten.

Munkahelyen nagyon ritkán dolgozok együtt szoftverfejlesztő nőkkel. Legutóbb az előző munkahelyemen ült mellettem egy lány néhány hónapig. Ő szándékán kívül a külsejével nagy figyelmet vont magára. Illetve hagyjuk ezt az érthetetlen hiper-korrektséget, egyszerűen nagy mellei voltak, ez egyszerűen matematikai tény. Érdekes volt, hogy mennyi hülyét vonzott oda. Persze voltak normálisan barátai is, de jöttek rá a hülyék, és bár egyébként barátságos nő volt, időnként határozottan el kellett küldenie valakit a halál farkára. Úgy tűnik, ez a képesség nőknek alapfeltétel a túléléshez a szakmában.

Szóval annyira nem lehet frankó nőként ezt a szakmát hajtani, de lehet másikat se könnyebb.


Ötletek a korrekcióra...

Szerintem nem csak a nők kedvéért, hanem a magunkért is, visszább kellene venni a munka kocsmai verekedés jellegéből. Nekem sincs hozzá semmi kedvem.

Talán már iskolákban tisztázni kellene, hogy a munkahelyi csajozás nem annyira pöpec ötlet.

Az, hogy külön közösségeket és cégeket hozzanak létre nőknek, az nekem teljesen abszurd.

2017. január 1., vasárnap

lights out

Lights Out Management. Ezt túrom mostanában amikor van kis időm, érdekes téma egy régi, de nem elfelejtett ötletemmel kapcsolatban.

A desktop-gagyi

A legtöbb PC, még a nyomi kis NUC is tartalmaz egy Wake ON Lan nevű feature-t. Ez elég egyszerű, egy UDP broadcastot kell küldeni a hálózatra, legyen benne egy speciális header és utánna 6-szor megismételve Csipkerózsika MAC address-e. Lássanak csodát, Csipkerozmária felébred és bootolni kezd... ha engedélyezve van ez a BIOS-ában persze.
A nyilvánvaló hátrányok:
  • akárki megcsinálhatja, semmilyen azonosítás nem kell hozzá
  • csak a helyi hálózaton működik mert a router valószinűleg eldobja
  • semmilyen választ nem kapsz róla
  • megbízhatatlan, pl ha kihúzod a dugót és visszadugod, lehet hogy nem kapcsol be újra egészen egy teljes indításig
Célszerű kikapcsolni :)

A gáz...

Szervereknél elterjedt szabvány az IPMI. Ez majdnem minden szerverben megvan - illetve a OpenCompute minimalista cuccokban alighanem nincs, de olyan senkinek sincs.
Az IPMI nem csak arra jó, hogy ki-be kapcsolgasd a szervert, tudsz vele:
  • konzolhoz csatlakozni
  • sensor információkat olvasni
  • akár boot médiumot is feltölteni - például erről már szivesen lemondanék
A problémák pedig:
  • UDP - vajon miért?
  • Sajnos nem biztonságos, és a világon mindent meg lehet vele csinálni (lásd fent)
  • A legtöbb vendor egy kis java applettel teszi hozzáférhetővé - ne tessék... java applet 2017-ben!!!
Előnye: könnyen beszerezhető a használtas boltokból, fillérekért.

A trendi

Az IPMI trónfosztására készül egy RedFish nevű specifikáció. Ez egy REST, http + JSON alapú dolog, amihez egyszerű akármilyen klienst fabrikálni. Elég érdekes, például lehet vele blade szervereket is buherálni, egyetlen management felület ad hozzáférést az összes blade-hez. A hátrányait még senki sem ismeri, annyira új, de nyilván emiatt csak újonnan lehet beszerezni, tesztelésre és fejlesztésre ez kicsit talán drága nekem. Az az ötlet, hogy egy szoftveres megoldással helyettesítem, egy vagy több VM-et indítana el libvirt-en keresztül, de végül úgyis igazi hardverrel kellene tesztelni. Sebaj, majdcsak megszán valaki...

Helyzet

Szóval a következő években érkező új szerver típusok többnyire redfish-sel érkeznek majd, de ott lesz rajtuk az IPMI is, mert azt mindenki ismeri és támogatja. Gyanús, hogy nem lehet választani, hogy csak redfish legyen vagy IPMI. Van az alaplapon egy jumper, azzal lehet kikapcsolni a teljes BMC-t, akkor nem lesz egyik se.

Az oVirt-ben például ez úgy történik, hogy a management szerver egy host-ot kér meg, hogy az ébressze fel a másik hostot. Nyilván legalább egy hostot mindig ébren kell tartani, de nem ez a kifogásom ellene. Nem tetszik az at ötlet, hogy a hostok számára elérhetővé teszik a management interface-t, túl nagy felületet ad a támadásra.

A kerub-ban inkáb a kontrollert akarom használni erre a célra, ehhez viszont írnom kell egy minimalista IPMI klienst, valamint a fenti redfish dev env szintén nagyon jó lenne... Jó sok meló lesz, lássunk hát hozzá :)
 Boldog buékot.

2016. december 24., szombat

planner - scheduler kerub módra

Ebben az iparban olyan factory-k vannak, amiknek nincs kéményük, managerek, akik nem járnak meetingre és engine-k, amik nem vontatnak semmit. Nyilván kicsit lököttek is vagyunk. Ebbe fog most az alábbi is passzolni egy kicsit, elég absztrakt lesz és annyi időt szánok rá a magyarázatra, amíg a managerem fel nem ébred.

Az előző bejegyzésekben már említettem a 2000es évek IaaS architektúrájának egy tipikus elemét, a schedulert.
A különbség az oVirt, a Cloudstack és más IaaS platformok schedulere és a kerub plannere között az, hogy míg a schedulereket akkor hívja meg a rendszer, amikor be kell ütemezni egy új virtuális gépet, a planner minden eseményt megkap. Minden eseménynél értékeli, hogy az új helyzet minden expectationt (azaz SLA contract) kielégít-e. Például a virtuális gép, aminek futnia kell, az tényleg fut, és olyan környezetben és hardweren amit kért a felhasználó.

Minden event az tényleg minden eventet jelent, amikor a szerver jelenti az éppen aktuális terheltségét az egy event, amikor a VM módosult, az szintén egy event.

Amikor az expectation nem teljesül, akkor a planner lépéseket gyárt le lépés-factory-k segítségével. A factory egyetlen dolgot kap: a jelenlegi helyzetet, ami magába foglalja a VM-ek, virtuális merevlemezek satöbbi, valamint a fizikai eszközök statikus (nem változó), dinamikus (állapot) és konfigurációs adatait. Ez alapján egyetlen dolgot csinálnak: listát a lehetséges lépésekből. A factory-k teljes mértékben tesznek arra, hogy van-e valami értelme a műveletnek, csak legyártják a lépéseket és kész.

Minden legenerált lépés az aktuális állapotot transzformálja egy másik állapotra. A progmatos állapottér-model elkötelezett hívei azonnal vegyék le a kezüket a farkukról, fúj gusztustalan! Szóval például egy bizonyos fajta lépés az egyik hostról átpakolja a másik hostra az egyik VM-et (nevezzük migrációnak), egy másik egy hostot kapcsol ki, (nevezhetjük power managementnek, de bug is lehet)

A lépéseknek persze van költsége, különböző költségtípusok, például idő, számítási és IO igény, vagy akár a kockázat, hogy valami gixer üt be, az is egyfajta költség.

Ezen kívül a lépéseknek vannak erőforrás igényei is, például egy host osztott vagy kizárólagos használata, tárhely vagy számítási kapacítás, illetve a virtuális erőforrások, amit használnak. Ez a feladatok koordinálásához kell, pl hogy ne tervezzen keresztbe már folyamatban lévő ügyek végrehajtásával, ne kapcsoljuk ki azt a hostot amit egy másik terv éppen bekapcsolt valamilyen célból, ilyesmi.

Nyilván minden lépéshez kell egy végrehajtó kód is, mert a lépés önmagában olyan absztrakt hogy fingja nincs melyik lábbal induljon el, csak az állapotteret transzformálja. A végrehajtónak viszont van kapcsolata a konkrét anyagi világgal, ez többnyire egy ssh kapcsolat egy vagy több kiszolgálóhoz.

hmm mi hiányzik még... ja persze, hogy ez mitől kezdene működni... Az már egyszerű, csak egy kereső algoritmus. Egy depth-first backtrack-et csináltam rá, ezt nevezhetjük átmeneti megoldásnak, mert valószinűleg más keresés gyorsabb lenne, de ez is tűrhetően párhuzamosítható.

Ennek az eredménye az, hogy a kerub keres egy módot arra, hogy a kéréseknek megfelelően futtassa a virtuális gépeket, merevlemezeket, hálózatot, satöbbi. A többi IaaS megnézi, hogy van-e passzoló host és ha nincs akkor pl nem indul a vm, csókolom.

Az biztosan gyanús már az elejétől, hogy a planner elég rendesen busy-box, mert minnél több a VM és a host, annál több event érkezik és annál több expectation-t kell ellenőrizni. Másrészt az egyre több factory egyre több lépést generál az egyre több VM-re. Ezek sajnos problémák, bár van rá ötletem, a keresési probléma egyébként is exponenciálisan növekedik. Jelenleg egy pár szűkítés van érvényben a factory-kra a kielégítetlen elvárások típusa alapján, de sokat az érne, ha nem kellene minden elvárást mindig kiértékelni, ha a factory-k listája lazy módon értékelődne ki.
Meglátjuk meddig jutok el vele, de a cél egyébként nem matematikai értelemben vett optimális állapot hanem csak egy egész jó :)

2016. december 4., vasárnap

final code-review-review

Vannak érvek a codereview mellett és ellene is. Kellett hozzá néhány év türelem, had gyűljenek az élmények. Ragyogó elméletek kontra szőrös valóság. Legyenek akkor elöbb a pro, mert az egyszerűbb, és sajnos sokkal rövidebb is.

Pro - ami működött


Egyik régi munkaadómnál a külső beszállítók gyakorlatilag review nélkül, és a management nyomására nem elég ritkán tesztelés nélkül is élesbe állították a rendszereiket. Mindenki boldog volt, amíg el nem szállt. És akkor jött a körkérdés: "Ért itt valaki groovy-hoz?" mire a legtöbben: "Mihez?"
Élesben fut egy rendszer, azt se tudtuk hogy mit csinál és ki használja, de elhasalt és fel kell támasztani.

Ugyanitt önként és meghívásos alapon elkezdtünk egymás között egy code-review szerűséget. Tea vagy narancslé, két szék, egy képernyő, együtt átnéztük a szoftver egy részét. Az ötlet az volt, hogy a review-er egyúttal backup ember is lehet, ha az eredeti fejlesztő nem elérhető, mert mondjuk elütötte egy autó. Például ez meg is történt velem.
A review során a review-erek inkáb csak ötleteket adtak, nem kötelező jellegű utasításokat. Jópár nagyon jó és hasznos ötletet kaptam és ezeket a review-ket úgy tünt mindkét oldalon pozitívan értékeltük. Mindkét fél ott ült, mindenki csak erre figyelt, elég gyorsan ment. A pár-hetente pár óra aligha lassította a fejlesztést, ugyanakkor viszont arra nem volt jó hogy konkrét hibát találjon.

Kontra


A szorosabb review process ötlete főleg, de nem kizárólag az open source projektek jellemzője. Mondjuk egy open source projekten tényleg át kell nézni az akárkiktől érkező patcheket, de ezzel sok probléma akadt:


Elösször is léteznie kellene egy alap kritérium listának, ami alapján elindul az ember, amolyan checklist. Ilyesmiket, mint kódformázással kapcsolatos szabályok. Ilyen többnyire nincs és helyette olyanokat szoktak mondani, mint "common sense", "well known traditions". Ez nem működik, ami az egyik kultúrában értelmes, az a másikban nem. Pl ami a spring-ben normális, az Java EE-ben nem az.
A helyzetet súlyosbítja, ha több reviewer is lehet, ugyanis többnyire ők sem értenek egymással, ami átmegy az egyiken fennakad a másiknál és fordítva.

Aztán a másik dolog ami a code review igéretei közűl megmaradt igéretnek az a párbeszéd. Egy webappon keresztül akarunk beszélgetni? Ne tessék viccelni, már a shared desktop + skype is elég szűkös néha, mert nincs hova rajzolni, lag-el a vonal, nem értjük elég jól egymást, esetleg a nálam már hajnalodik, a másik fél viszont még nem ebédelt.
Itt egy kicsit a kultúrális különbségek bejátszottak. Például sok izraelli munkatársam még mindig aktív katonai szolgáltaban állt, ők a command chain-hez voltak hozzászokva, az ő napi megszokásuk az volt, hogy a besztottak végrehajtják a parancsot. Abból lesz ám fasza dolog :)
Más kultúrákban is van így, például sok indiai is ha egyszer mondott valamit, akkor nagyon nehezen, vagy egyáltalán sehogy se tud kihátrálni. Persze ismerek kivételeket köztük is, de ez a rugalmatlanság amerikaiaknál és európaiaknál ritkábban fordul elő.

Harmadik beteljesítetlen igéret a kevesebb bug a kódban. A probléma talán onnan jön, hogy egy webappon keresztül nézegetik a reviewerek a kódot. Az hogy letöltsék és ki is próbálják, az opcionális, és mivel sok időt vesz igénybe, úgy látom többnyire nem is történik meg. Ezt a legtöbben be is vallották és azt mondták, a patch fejlesztőjének a felelőssége a tesztelés. Ebben nem értek egyet, teszt nélkül szerintem a review teljesen irreleváns.
Egy esetben pl 5 hónapig pöckölgettünk egymásnak patcheket, a végén a management nyomására lett vége a sztorinak. Bár egy délután alatt bőven le lehetett volna tesztelni a kódot, sajnos ez alatt az idő alatt én voltam az egyetlen aki kipróbálta.

A negyedik elmaradt igéret a tisztább kód. Bár a code review elvileg kivállóan betartatná a konvenciókat, a valóságban gyakran ez sem így történt. A már meglévő kód takarítása gyakorlatilag megvalósíthatatlanná vállt. Nem maradt rá idő. Amikor mégis beküldessz egy kis patchet, akkor a review gudelines hiánya miatti félreértések következnek: vedd még mást is hozzá illetve már így is túl sok, várj még a patch-csel illetve elavult és légyszi rebaseld.


Az ötödik probléma a review-val a határidő. Sajnos a reviewerek a gyakorlatban teljesen leszarták a határidőket. Ez már management hiba, de meg is tehették, mert rajtuk senki sem kérte számon. Gyakran hetekig vagy akár hónapokig is eltartott egy review, közben nem történik semmi. Ez két további problémát vet fel:
  • Nagyon gyakori task-switching. Ebben a gépek a nyerők, az embernek sok időbe tellik és a párhuzamos taszkok számával exponenciálisan nő a valószinűsége annak, hogy elcseszi. Csinálj egy dolgot, csináld addig, kész nem lesz!
  • Ha nem tudok igéretet kapni a reviewerektől a határidőkre, akkor hogyan tudnék én igéretet adni határidőkre? Ez a legsúlyosabb probléma a code review-vel a hétköznapi életben.

Szóval...

A code review mögötti ötlet érthető, csak a gyakorlati megvalósítása elött van egy pár akadály, amit a projekt vezetők gyakran figyelmen kívül hagynak. Nem tartom elképzelhetetlennek azt, hogy működjön, csak valószinűtlennek. Túl könnyű szarba lépni, mint egy gyanútlan túristának a nyóckerben.
Mindenesetre a tavalyi év végére eldöntöttem, hogy olyan munkát akarok, ahol ezt veszélyt kiküszöböltük. Az elműlt egy évben ilyen helyen dolgoztam. Nyugodt volt a hangulat, bár pár alkalommal rendesen bele kellett húzni, végül mégis kényelmesen elértük a határidőket, az ügyfél boldog és nagyon jó fej velünk. Nekem ez bevállt és megtartom ezt az irányelvet: amíg találok olyan munkát ahol nincs potenciális probléma, addig olyat vállalok!

Code Review: Good Bye!