2015. április 22., szerda

reneszánsz vízesés

A munkahelyemen nyilvánvaló waterfall process alakult ki az utóbbi nagyjából egy évben az azt megelőző agile-féleségből. Ez egy nem túl motiváló, de nagyon tanulságos folyamat, úgyhogy gondoltam megosztom veletek ezt a gondolatot, hátha valaki valami hasznos következtetést von le belőle.

Szóval ugyanarra a problémára két ellentétes választ ad a waterfall és az agilis módszertan, mindkettő teljesen megalapozottnak látja a lépést.

Az ügyfél szeretne minél több hasznos dolgot kapni a szoftverébe. Az agile metódikában erre azzal válaszolunk, hogy gyakrabban adunk ki frissítést. A waterfall-ban az ügyfél ugyanazt akarta, de a fejlesztési folyamat végén a tesztelés során, amikor szegény csóri felhasználóim már tudják, hogy ezzel a cuccal ki kell bírni néhány hónapot onnantól kezdve hogy kibökték azt, hogy "OK". Nos emiatt félelmetes mennyiségű "last minute" feature-t kértek, még az utolsó percekben is. Szó szerint amikor beütöm az release parancsot, akkor még pár percet tengek-lengek, mert egész biztosan csörögni fog az email miután lefuttattam a parancsot.
Ennek nem csak minőségi következményei vannak, hanem oda vezetett, hogy az elég hosszú fejlesztési ciklust minden ciklus után megtoldottuk. A csóri felhasználók pedig mégtöbb "last minute"-t kértek, mert még többet kell majd várniuk a következőre.

Nagyon hasonlóan történik a specifikációval is, egyre hosszabb lesz, és amíg az alá nincs írva, addig egy bitet nem verünk be. Emiatt persze a felhasználó egyre többet ül rajta, nem merik aláírni, amíg a legapróbb részletig minden bele nem kerül. Persze munka közben kiderül, hogy ez nem sikerült, de a következő alkalommal még hosszabb specifikációs ciklus következik.

Ezt nem magamnak, meg a szerény létszámú olvasóközönségemnek mondom, nyilván elmondtam a project vezetőinek is, egyetértés megvolt, de valahogy semmi nem történt. Azt hiszem ugyanazokat a problémákat látjuk, csak más lámpák gyulladnak ki.

2015. március 1., vasárnap

java 1.8 hash

A java 1.8-ra egy egész halom érdekességet hoz, talán a legnagyobb változások a java 1.5 óta. Az emberek mégis igen lassan mozdulnak rá, a cégek meg még lassabban. Ez a szokásos dolog. Az Oracle, hogy kellemes pozitív motivációval noszogasson minket, fejbelövi a java 1.7-et, pár hónap múlva nem több lesz frissítés. A Fedora project fejlesztői kicsit erőszakosabban modernizálnak és a fedora 21 új feature-i közé betették azt, hogy nincs java 1.7 rajta. Micsoda spártai (és balfasz) feature. Akárhogy is, lassan mozdulni kell és az élő projecteket át kell rángatni java 1.8-ra.

Ez egy igazán naiv idealista szemében rohadtul egyszerű lehet: Csere, restart, jónapot.

A probléma, amibe többszörösen beleakadtam, tulajdonképpen egy nem különösebben nagy dobra vert újdonság: új hash algoritmus, amely egész szépen muzsikál. Király, jobb teljesítmény ingyen. Mi baj lehetne?
A probléma ott van, hogy bár nagyon nem jó ötlet arra fogadást kötni, hogy a HashMap-ba tuszkolt adatok milyen sorrendben fognak kijönni amikor iterálsz rajtuk, nos ennek ellenére explicit módon egy csomóan mégiscsak fogadást kötöttek rá, általában tudtukon kívül. Egész idáig mindig nyertek, mert mindig ugyanúgy jöttek ki az adatok. Most szépen kipukkan a lufi, de még nem igazán látom, hogy mekkora a lufi.

A probléma ott van, hogy:
  1. Nagyon sok helyen használunk HashMap-et vagy HashSet-et
  2. A hibás feltételezéseket nehéz megtalálni, nem holmi grep-pelés, hanem el kell a nyomorult kódot olvasni, tesztelni kell
  3. Nagyon sok kódot
  4. Nagyon kevés időnk van rá

Szóval jó kis meló lesz ez, hajrá :)

"Hash, alkoss, gyarapíts"

2015. február 15., vasárnap

Reggelitorna

A munkahelyemet a lakóhelyemtől egy nagyjából 15 perces vonatút választja el. (legalábbis télen, nyáron nyilván bringával megyek). Ezt az időt eleinte sudoku fejtéssel töltöttem, 15 perc nekem általában elég egy közepes erősségű rejtvény megoldásához. Később viszont rászoktam arra, hogy viszek laptopot magammal és 15 perc alatt valamibe beletúrok. Internet hozzáférés viszont nincs, így semmi nem zavar, nem tudom megnézni a twittert, a feedly-t, a leveleimet és keresgetni se tudok a neten.
Ez egy egészen klassz módja a munkának, mert az ember tudja hogy sietnie kell (ugyanis mindjárt megérkezik), nem sok látnivaló van útközben (többnyire gyárak, ipari területek) és nem vonja el a figyelmemet semmi.

Az eredmények:
  1. A saját kis hobbi-projecteim egész jól fejlődgetnek és ebből tanultam egész sokmindent.
  2. Talán ennél jelentősebb egy nagy rakás bugreport egy tucat különböző szoftvernek, és persze a megfelelő módon: POC programmal, leírással, satöbbi. Néhány nagyon jó tapasztalat is származott néhány ilyen hibabejelentésből, például a jetty fejlesztői villámgyorsan reagáltak és 1 héten alatt megoldották, a CXF fejlesztői pedig a bejelentéstől számított 24 órán belül ki is javították a hibát.
  3. Nem mindegyik project volt ennyire jól ellátva munkaerővel, így néhányszor elém is oda került a labda és pár projectbe vendégmunkáskodtam egy-egy patch erejéig.
  4. Nagyjából sikerült leszoknom a sudokuzásról.

Problémák:
  1. A reggel 7:47-es vonaton többnyire nincs ülőhely, ezért vagy a 7:17-es vagy a 7:10-es vonattal járok.
  2. Ez az egész nyilván nem túl szociális, bár körülöttem a sok iphone-zombi se az.
 

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.