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.