2014. december 17., szerda

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.

2014. november 23., vasárnap

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.

2014. november 18., kedd

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 :-)

2014. november 13., csütörtök

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.

2014. október 21., kedd

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á :)

2014. szeptember 8., hétfő

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 :)

2014. augusztus 19., kedd

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.