Resourcing

Péter írt egy postot az IT resourcinggal kapcsolatos nehézségekről, érdemes elolvasni. Csak egy pár gondolatot osztanék meg saját kiegészítésként.

Én két oldaláról ismertem meg az IT resourcing témát. Elösször több IT resourcing cégnél dolgoztam Magyarországon, aztán dolgoztam olyan cégnél is, amelyik bár eleinte inkább a saját szoftverfejlesztőire épített, az idő haladtával egyre inkább a külső beszállítókra helyezte a hangsúlyt. És igen, egy idő után már hiába vadásztam magamnak projectet a munkahelyemen, az IT resourcing cég, amelynek előzőleg én is dolgoztam, mindent vitt. Én meg szedtem a sátorfámat. Talán cifrán hangzik (pedig az igazán tréfás részt direkt lehagytam), de ismerve pár történetet, én talán inkább tipikusnak nevezném.

Szóval pár megfigyelésemet szeretném megosztani. Tessék itt jönnek.

Szoftverminőség

A belső csapatok kötelező módon egy szerintem egész profi és összeszokott tesztelő csapat engedélyével pakolta ki a szoftververziókat. Az elsőtől kezdve az utolsóig, mindig. Ez az egyszerű pipeline mintha nem létezett volna a külső csapatok esetében, így sok szoftver és frissítés a QA csapat megkerülésével került élesbe, azt feltételezve, hogy a másik oldalon elegendő tesztelést végeztek.
Ez nem mindig volt így. Nem akarom hibáztatni a külső csapatokat, hibát mindenki követ el. Nyilván magamat is beleértve, de had tegyem hozzá még ezt is hogy egyértelmű legyen :-D
Viszont egyszerűen muszáj hogy legyen valaki, aki ellenőriz. Mellesleg nem árt, ha az illető valamennyire konzisztensen teszi ezt. Szóval a QA-t én talán hagynám odabent.

Kinek a QA-ja

Amikor néha évekig ülsz "resource"-olva valahol, az kb olyan, mintha te is ott dolgoznál. Annyi a különbség, hogy nem az. Bármilyen kérdésben ugyanis első sorban a munkaadód érdekeit kell figyelembe venned. Kicsit skizofrén dolog, nodehát a skizofrénia népbetegség. Te hogy vagy ezzel, Laci? Ja, nekem semmi bajom az egésszel!

Csatamező

Régebben ezt nem értettem, de ma már én is úgy látom, hogy az IT resourcing emberek megjelenése figyelmeztető jel a cég saját alkalmazottainak. Láttam már olyat, hogy ez komoly rivalizáláshoz vezetett. A rivalizálás az egészséges kapitalizmus törvényei szerint elvileg jobb minőséghez vezetne a versengésen keresztül. Versengő projectek között talán így is lenne, de egy projecten belül nem. Az a baj, hogy a riválisától kapott információkat az ember agya másként kezeli. A bizalom hiánya. Először csak vélten, majd később esetleg ténylegesen, de szóban mindenképpen megpróbálnak egymásnak keresztbe tenni. Ilyesmi.

Szegregáció vagy integráció

Néha egy cégen belül is elakadnak az információk, más emberek más eszközöket és módszereket használnak. A diverzitást a biológiában jó dolognak tartjuk, az informatikában nem mindig. Például kaptunk resource-olt csapattól groovy-ban írt cókot. Semmi baj a groovy-val, de se az üzemeltetők, se a cég saját fejlesztői nem is hallottak addig róla. Bármilyen probléma esetén eleve tanácstalan gúglizással kezdődött a kutatás, probléma pedig volt pár, mert a cucc egyszerűen csak nem passzolt a többi darab közé.

Az mindenesetre fontos, hogy a resourcing cég ne egy beszállítóként működjön. Pedig ha elvágod őket a cég többi részétől, akkor csak olyan lesz. Az IT élettere az információ, ha a távoli resource-ok nem kapnak információt, akkor értetlenül fogod nézni azt, amit kaptál tőlük.

Szóval...

Szóval mint ahogy az általában a legtöbb dologra igaz, ha agyatlanul használják, az IT resourcing lehet egy elcseszett öngól is.

ApacheCon Budapest - második nap

Mint mindennel, ezzel a konferencia-naplóval is lemaradtam, de megígértem és behozom, még ha senki nem is olvassa el :)

Szóval reggel az Apache Brooklyn projecttel ismerkedtem meg, amit azóta el is kezdtem próbálgatni, bár még nem sikerült teljesen elhelyezni a fejemben hogy pontosan hova fog passzolni :) Mindenesetre komplex alkalmazásokat lehet vele telepíteni nagyon gyorsan és egyszerűen. Ez igazán tetszene, bár az MS-Word doksinál nekem majdnem bármi szimpatikusabb.

Szintén feltünt a radaron a newts, ami Cassandrára épített adatbázis kifejezetten olyan time-series adatok tárolására, a bemutató szerint az olvasási sebesség tűrhető, de az írási sebesség zseniális. Egy ilyennek igazán sok helyet lehet találni a hétköznapi életben. Az OpenNMS fejlesztői konkrétan a hálózat terhelésének követésére használják.

Az egyéb kategóriában a JClouds előadásokat hallgattam meg. Nekem mindig úgy tűnt, hogy a system developerek jobban szeretnek python-t hajtani, de nekem határozottan jól jön egy java absztrakciós réteg.

Este a CloudStack srácokkal és pár emberrel a CouchDB fejlesztők közül a Szimpla kertben lógtunk, az egyébként is gyanús CouchDB arcok főleg az alapítvány belügyeiről beszéltek, aminél akár még a szivárványmintás pónilovak legújabb kalandjai is jobban érdekel.

ApacheCon Budapest - első nap

A hétfő nagy részét a CXF előadásokon töltöttem. A Spring Websocket lecserélését CXF-re egyelőre nem tettem napirendre, de a JAX-RS 2.0 demók közben rájöttem, hogy sokkal jobban is kihasználhatnám a JAX-RS API-t a CXF-ben, különösen az async újdonságokat. Nagyon érdekel, hogy az asszinkron dolgokkal hogyan alakul a szerver teljesítménye ha összegyúrom az infinispan async API-jával. Sokat kellett várni arra, hogy felhasználható állapotba jöjjön a servlet async support, most a végén remélem meglátjuk hogy megérte :)

Rendkívül szociális nap volt a hétfői, egy csomó emberrel találkoztam személyesen, akivel eddig csak leveleztünk és azt se tudtam hogy néz ki. De azért nem voltak köztük se ufók, se alienek.

Kicsi statisztika:
Nagyon kevés magyar van, talán 10-15, szerintem kicsit borsos lehet az ár, a munkaadóink meg sóher stricik.
Ennél már csak nőből van kevesebb, talán 3 a résztvevők közül, még 3 szervező, 1-2 fejvadász. Nagyobb posztereken kellene reklámozni, hogy nem gyűlöljük az programozó lányokat.
...csak a programozókat úgy ahogy vannak egyébként :-)

Apache BP

Nem szeretném azt a látszatot kelteni, hogy bárki követné vagy érdeklődne iránta, vagy bárkit tájékoztatni szoktam volna arról hogy hol vagyok és mit csinálok, csak gondoltam szólok és igérek, hogy a jövő héten Budapesten leszek az Apache konferencián. Aki nem jön, annak írok beszámolót itt arról, ami engem érdekel és megragad a fejemben addig, amíg le nem írom, aki meg jön, azzal esetleg fussunk össze. Szocializálódjunk, vagy mi.

Egynemű házasság

Nemrég egy új főnökömnek (gyűjtöm a managereket) próbáltam elmagyarázni hogy mi a szituáció a projecten és valahogy ez a megnevezés jutott eszembe: egynemű házasság.

Az egynemű házasság alatt azt értem, hogy a projectre úgy helyeznek új munkaerőt, hogy az a projecten már meglévő fejlesztők képességeit nem kiegészíti, hanem azt lefedi.

A skálázhatóság témában szokás ezt X-axis-nak nevezni, és ott jól produkál, tipikusan webalkalmazásokat egész könnyű (ha nem csinált valaki valami turpisságot) X-axis mentén skálázni. A lényeges különbség viszont az, hogy a számítógépekkel összevetve az emberek lassan tanulnak és ráadásul sok hibával, azaz mind másként tanulnak meg valamit. Ez oda vezet, hogy kialakul pár vita és persze személyfüggő, hogy mennyi, de egyre több koordináció válik szükségessé. A problémán az sem segít, hogy az emberek természetes viselkedése a versenyzés, ez ugyanis nem minden eset válik a szoftver javára például gyakoribbá vállnak a túlmérnökölt megoldások.

Hát ennyit akartam megosztani ma, hogy én így gondolkodok erről nagy általánosságban véve, a többi bullshitet költsétek ti hozzá :)

Websüket

2006 körül minden az AJAX-ról szólt. Mindenki dinamikusan generált HTML-ből állított kezdett weboldalakat összeállítani, de azért még jónéhány full-page reload volt benne. A kommunikáció többnyire tényleg XML volt, néha jöttek-mentek html darabok is.

2010 körülre már megint mosogatószert meg focicsapatot jelentett az AJAX. Az XML látványosan veszített népszerűségéből, elkezdték egyéb formátumok átvenni a helyét, főleg JSON de láttunk már olyan perverziókat is mint a BSON és társai. A formátumok káoszában a REST homályos útmutatásai teremtettek hébe-hóba rendet.


Itt a történelemórát had szakítsam félbe, hogy azt is elmondhassam közben, hogy milyen elégedett voltam azzal, hogy a rémesen túlbonyolított és szemellenzős szerveroldali MVC rendszereket itt ezen a ponton jórészt elavulttá tették az egyoldalas webalkalmazások. Ez nem azt jelenti, hogy nincs többé aki használja őket, hanem csak egyszerűen COBOL-völgyi bányászoknak tartja őket a sok nagyvárosi okostojás.
De nem csak ez okozott kárörömet rothadó lelkemben, hanem az is, hogy a javascript programozók komoly lehetőségeket kaptak arra, hogy bizonyítsák, nagyon egyszerű, könnyű és stabil rendszereket tudnak építeni kedvenc platformjukra, a böngészőkre. A pofáraesésen csak azért nem tudtam szívből derülni, mert nekem is fájt.Ez egy nagy adag komplexítást levett a java backendről és tulajdonképpen ma egy java backend fejlesztő élete akár rettentő egyszerű is lehetne egy végletekig idealizált esetben. Csak olyasmikkel kellene foglalkoznia, mint megbízhatóság, kiválló válaszidők, skálázhatóság és mindenek elött persze (hmm...) egyszerűség. Hát azért nem egészen itt állunk, de őszintén úgy gondolom, hogy ez a lehetőség adott. Csak hát elkú ugye, már megint.

Nade félre ezekkel.

2014 van és miután évekig vártunk hogy leülepedjen és letisztuljon a webfejlesztés, végre ovisokra és nyugdíjasokra bízhassuk amíg mi szebb kihívásokat keresünk magunknak, tartok tőle hogy ismét csalódás fog érni. Bár már évekkel ezelött is írtam a websüket szabványról, azóta kidobták, mégis visszaengedték, megszületett végre a java api, satöbbi. Szóval úgy tűnik, végre itt van a websocket, nagyon lassan de elhárulnak az akadályok előle. (Nem tudom miről beszélnek amikor gyors fejlődést emlegetnek az emberek, szerintem tüttyögésről meg pöcsölésről lehetne beszélni.)
De nekem felmerül a kérdés: ha van egy folyamatos full duplex kapcsolatod a szerverrel, ugyan mi a fenének akarnál REST-et használni. A webalkalmazások egy jelentős részének új paradigmára, új eszközkészletre van szüksége.

No ennyi. Vár a gyár.

Hron, remélem megválaszoltam a kérdésedet legalább részben :)

kotlin helyzet

Csak egy gyors véleményösszegzés arról, hogy hol tarhat most a kotlin programnyelv fejlesztése. A project célkitűzésein végigfutva:

• Legalább olyan gyors compiler legyen, mint a javac
  Ezt jelenleg alulmúlja a kotlin. Állítólag hónapokon belül érkezik az incremental compiler, de még nem jött meg. Nyomai persze már vannak a forráskódban. Szerintem jelenleg elég lassú. (fordítás közben az ember végigvizslatja az I7-es processzorral szállított laptopok árait)
• Java kompatibilis
  Ezen a téren viszont egészen jó, teljesen normálisan használható a kotlin kód java kódból és fordítva. Az extension funkciók szerintem jól eltalált dolog, a null protection is transzparens a java felől nézve.
• Biztonságos
  A designt nézve elég biztonságos, de nekem hiányoznak az olyan eszközök, mint a findbugs, amivel gyorsan automatikusan végig lehet túrni a kódot tipikus hibák után. Fejben már elkezdtem összeszedni egy listát azokról a dolgokról, hogy hogyan lehet magadat lábon lőni kotlinban egész könnyen.
• Kifejező
  Ez passzol. Közel sem olyan cifra, mint a scala, de az egyszerűségével nekem tetszik.
• Milyen főbb lépések vannak hátra
  Ezt megkérdeztem a fejlesztőktől és válaszoltak. Igen pont abból a párbeszédből kiderül, hogy visszafelé nem kompatibilis. Ezért library jellegű dolgot írni kotlinra még kissé bosszantó. Le is mondtam az egyébként csinos spek BDD toolról a jbehave javára.

Hát ennyi. Kérem kapcsolja ki.

Heti hype: Akka

Mostanában igen gyakran jártam mindenféle meetupokra és igazán pofátlanság tőlem hogy nem számoltam be egyetlen egyről sem, mert igazán jók is voltak köztük. Konkrétan az egyik, ami egészen jó volt, a zürichi scala buherátorok Akka meetupja volt. Nem számítom magam az aktív scala felhasználók közé, de az Akka érdekelt egy projecthez.

Az Akka egy actor-based concurrency framework, amit scala-ban írtak, de van egészen jó API-ja java-hoz is. (A magyar szakmai szókincsem hanyatlását kivállóan demonstrálja az előző mondat) Az actor rendszerekben minden folyamatot egy actor jelképez. Ezek az actorok létrehozhatnak további actorokat és üzeneteket küldözgethetnek egymásnak. Az üzenetek stílusát tekintve inkább a "megmondás" a jó ötlet mint a kérdés. A kérdés is lehetséges, visszakapsz egy Future-t, nekem gyanús hogy ott lehetséges deadlock, de mindegy, ennyi az alapötlet.
Az actor nem egy szál. Nem tudni, hogy melyik szálon, melyik processzoron (illetve cluster esetében: melyik gépen) fog futni és hogy mikor és milyen sorrendben kapja meg az üzeneteket. Igazából nem is feltétlenül garantált, hogy valaha megkapja, ez bizonyos esetekben elfogadható.

Bár én is csak gyüjtögetem a tapasztalatokat az Akka háza tájáról, nem tűnik univerzálisan minden többszállú feldolgozásra hasznosnak vagy akár csak alkalmasnak is. Ennek ellenére:

• Az akka meetupon az egyik közbekiabáló például azt találta ki, hogy Oracle tárolt eljárásokba integrálná az Akka-t, azért mert lehetséges. Kétségtelenül némi emberáldozat árán lehetséges, de minek?
• Az egyik stack overflow felhasználó JDBC connection pool-t csinált Akka-ból. Nem is tünt fel neki semmi, csak az, hogy lassú.
• Szintén a stack overflow-on az egyik leggyakoribb kérdés az Akka-val kapcsolatban, hogy egyáltalán mire használható.

Szóval javaslat mindenkinek, aki Akka-t használ illetve tanulgat (magamat is beleértve): gondolkodjunk el azon, hogy nem-e valami technológiai maszturbációt követünk el. Pár dologra jó az Akka, de nem mindenre.

A tiéd mekkora?

Hú, de régen nem írtam semmit. Mostanában valami rettenetesen sokféle dologgal foglalkoztam a melón kívül, most éppen fordítóprogramot javítok, mostanában agenteket buherálok, még mindig dolgozok a cloudstack körül is dolgozgatok, tanulok eztazt és persze írok a wikipédián. Ennek eredményeként nem kicsit lehet elhanyagolva ez a szegény blog. Köszi mindenkinek aki ennyi idő után se törölte az RSS olvasójáról. Gondoltam visszaszokásként tesztelés témakört rúgnám tökön.

Anekdota bemelegítésnek: Az első napon a kb első munkahelyemen súlyos hibát követtem el. Belenéztem a forráskódba és azt mondtam: próbáljuk ki! Erre az über-führer egyből az első napon lecseszett: "Laci, nincs időnk játszani, dolgozni kell!" Ilyen súlyos hajótöréssel kezdődött az IT "karrierem", most már mindent értetek.

Az embernek kicsit bizonytalannak kell lennie saját képességeiben ahhoz, hogy nekilásson minden egyes csavart megvizsgálni. A tesztelés az a dolog, ami zseniknek nem való. Zsenit viszont nagyon keveset láttam eddig, önmagát zseninek tartó hülyét viszont nagyon sokat.

Unit tesztek

A unit tesztelésnél az szokik az első kérdés lenni, hogy mit teszteljünk. Nekem általában véve az a véleményem a dologról, hogy minden mozgó alkatrészt érdemes kipróbálni. Na és mi a fészkes lehet az a mozgó alkatrész? Néhány példát felsorolnék:

• A java kód, az nyilvánvalóan, de nem itt ér véget a lista
• MyBatis nevű rémálomban az SQL utasításokat kipakolhatod egy XML-be. Ami abban az XML-ben van, az mozgó alkatrész.
• JPA-ban tipikusan annotációkat tesznek a perzisztens osztályokra. Ezek az annotációk határozzák meg, hogy melyik táblába, melyik oszlopba kerül az adat, tehát az is mozgó alkatrész.
• El ne felejtsük: adatbázis séma, tárolt eljárások
• A HTML kód és benne a sok-sok juvaszkript
• ... satöbbi

A unit tesztek annyira elég, hogy tudd, az a pár sor amit leírtál, annak úgy a kontextusból elkülönítve képes megcsinálni azt, amire számítottál a teszt írásakor. Ez olyan, mint ha biciklid egy alkatrészét vizsgálnád meg, pl hogy nem ereszt-e a belső, nincs megrepedve a váz, nincs nyolcas a kerékben, satöbbi.

Én szeretem úgy számon tartani a mozgó alkatrészeket, hogy ha ránézek egy ilyen alkatrészre, akkor meg tudjam mondani hogy melyik unit teszt fog elfeküdni ha elszúrom és néha ki is szoktam próbálni, hogy igazam volt-e. Ezt általában az olyan projecteknél lehet megcsinálni, amelyiken az elejétől kezdve írtak teszteket a kedves emberek.

Az összes unit teszt sikere együttesen sem jelenti azt, hogy az alkalmazás valami értelmeset fog csinálni, vagy hogy egyáltalán el fog tudni indulni.

Talán emiatt is, de sokan tagadják, hogy a unit teszteknek lenne elegendő haszna illetve bármi értelme is. A unit teszt ugyanis néha nehéz. Pár példát említenék:

• Van olyan kód, ami nem tesztelhető könnyen automatikusan. Tipikusan akkor, amikor a kód kicsi darabja nincs egészen elkülönítve a többitől. Ilyen amikor egy globális változón múlik a számítás eredménye vagy egyáltalán a működőképessége.
• Környezeti beállításokra épül, például az operációs rendszerre feltelepített csomagokra vagy beállításokra. Ezt a Linuxerek éppen olyan gyakran követik el, mint a Windowserek.
• Hálózati erőforrásokat használ, például muszáj hozzá egy X adatbázis, Y MQ vagy Z webservice, vagy egyáltalán csak be van hardkódolva egy hostnév.

A szoftvert tehát úgy kell felépíteni és a kódot úgy kell megírni, hogy tesztelhető legyen, amennyiben ez cél. Ezek néha nehezen leküzdhető akadályok, de (magánvélemény) nem annyira nehezek, mint amennyire ritkán fordul elő. A fenti nehézségeken kívül például az a pszichológiai oka, hogy triviálisnak tűnik a kód. Már volt velem olyan többször, hogy nekiláttam megírni a tesztet egy triviálisnak tűnő kódon, aztán a teszt futtatása közben jöttem rá hogy elszúrtam.

Ha a tesz nem megy át, akkor vagy nem jó a kód, vagy nem jó a teszt, vagy esetleg mindkettő rossz.
Ha átmegy a teszt, akkor vagy mindkettő jó, vagy mindkettő rossz. :-)

Mi mekkora?

A unit teszteknél szokás mérni a tesztek lefedettségét is és ebben a kérdésben szokott felvetődni, hogy mekkora a teszt lefedettsége egy adott projektnek vagy hogy mennyinek kell/kellene lennie. Ez egy nagyon nehéz vallás-politikai és etikai kérdés, tele morális csapdákkal és elméleti buktatókkal, a különböző ideológiai irányzatok és etnikai csoportok ellentéteiről nem is beszélve.
A lefedettség olyan technikai korlátokba ütközik, mint pl a java checked exceptions. Egyes kivételeket hiába kell levédeni, tulajdonképpen vagy soha nem jönnek, vagy csak extrém esetekben. Másik példa lehet Util osztályok akár default, akár implicit és levédett konstruktora: soha nem fog futni, mert Util osztályt soha nem példányosít az ember. Ilyen módon amikor valaki 100 százalékot makkan, akkor az hmmm... felveti a kérdést hogy hogyan érti. Nekem úgy tűnik, 70-80 százalék között van általában a unit tesztek számára kényelmesen elérhető ágak száma.

Na ettől azért általában rendesen távol állunk, ha szétnézel open source projektek között, viszonylag ritka a jelentősebb (akár 10% feletti) lefedettség. Izgi.

No, legközelebb majd az integrációs tesztekről valamit.