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.

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