Small is beautiful

Lassanként minden a felhőben szalad, mert az (többnyire, eleinte, állítólag, stb) olcsóbb, és persze a felhőben fogyasztás alapján számláznak. Azaz megkapod havonta a memória fogyasztásodról a számlát minden hónapban újra és újra. Nem csak akkor, amikor leslattyogsz a boltba megvenni a RAM-ot a gépbe.

Szóval vajon ez az újra és újra megjelenő kiadás elegendő motiváció-e arra, hogy kisebb memóriaigényű szoftvereket fejlesszünk és futtassunk?

Például a jetty elfut 256 MB memórián. Még egy DB-nek is akad hely, azaz a legkisebb VM-en is simán elszalad. Egy JBoss-t vagy Glassfish-t nem inditasz el azért 1 GB alatti memórián. Illetve ha megveszed minden hónapban a memóriát, nem-e inkáb valami hasznosra használnád? Még az I/O cache is sokkal hasznosabb, mint egy tucat teljesen kihasználatlan feature a kedvenc JEE szerveredben.

csapatszétszórás

Arra a melóra, amit én csinálok, 4 földrészen lehet jelentkezni. Ennek ellenére a szűkebb csapatból én vagyok az egyetlen, aki nem Tel Avivban dolgozik. A tágabb csapatból se sokan. Néha úgy tűnik, akár maradhattam volna Budapesten is. Egyszer megkérdeztem, hogy miért jó az hogy egy pár ember így a világban elszórva van, de a legtöbb (talán úgy 100 ember) egy városban. Hát, erre nem kaptam kielégítő választ :-) de gondoltam megosztanám mindenkivel a véleményemet erről a csapatszétszórásról általában:

A földrajzilag szétszórt csapatot sokan trendi dolognak tartják, pedig kommunikációs problémák lehetséges forrása. Nem cél, hanem egy probléma.

Például a gerriten, ircen keresztül pötyögni soha nem lesz olyan hatékony, mint odamenni valakihez és ledumálni  az egész problémát. Kicsit olyan, mintha a szervereidet plip-pel kötnéd össze, meg még egy csomót is kötsz rá, aztán csodálkozol hogy lassú meg rossz.

Amúgy ezt is lehet jobban csinálni, de pl az irc elég rendesen múlt századi technológia. Soha nem is irceztem mielött itt dolgoztam volna.

code review

A közhiedelem az, hogy a code review során a problémák nagy részét elkapjuk és kitekerjük a nyakát. Ez igaz is lehet egy bizonyos mértékig, de csak egy bizonyos mértékig. Nekem úgy tűnik, hogy a code review során gyakran új bugokat hozunk létre, az alábbi okokból:

• A reviewer személye mindig más. A mindig más személynek mindig mások a szempontjai. Például van olyan, aki azért dobja vissza a patch-et, mert nem final egy változód benne, van aki azért mert az és neki nem tetszik. "ha van kalapod, azért, ha nincs kalapod, akkor meg azért". Valljuk be, ez a final dolog még bölcsészek között is baszakodásnak számítana.
• A patch-ek szétválasztása és egyesítése tulajdonképpen kódolási tevékenység (azaz idővel és kockázatokkal jár) míg a végeredményhez semmilyen értéket nem tesz hozzá.
• Teljesen beteg vagyok attól, amikor valamit kétszer kell megcsináljak. Na és az még a jó eset :-) Ha elsőre jó volt, másodszor biztosan elcseszem.

Szóval a lefikázás után valami konstruktívat arról, hogy szerintem hogyan kellene használni a gerrit-et:

• Ha egy patch jobb állapotot hagy maga után, mint elötte, akkor had menjen. Lépjünk tovább, ne szarozzunk!
• Ha hiányzik belőle valami (de ugyanakkor attól még jó), akkor esetleg a reviewer hozzáírhat egy patchet és beküldheti, megmutathatja az eredeti patch szerzőjének, hogy ő még ilyesmire gondolt. Lehet vitatkozni, vagy örülni hogy "gyá télleg, köszi!"
• A fast forward policy csak több munkát hoz, gyakorlatban nem védett meg minket semmilyen hibától. Ezt a funkciót egyszerűen kijátszuk, mert nincs más választásunk.

Szóval én inkáb piacnak képzelnék el egy jól működő dolgot, mint vizsgabizottságnak. Lehet ezt is jól csinálni, csak mi nem úgy csináljuk. Megpróbáltam demózni az ötletet és egy pár hétig egy-egy embernek végignéztem a patch-setét egyenként ellenőriztem és ha jó volt egyből be is mergeltem. Szépen haladtunk. Mindenki örült, de aztán senki sem kezdte utánozni a módszert :-(

Amúgy a gerritet továbbra sem komállom, mert:

• A gerrit üzenetei suttyók - pl ezért én soha senkinek nem adok -1-et, mert az olyan bunkó szöveg, hogy inkáb fogalmazok valami barátibbat levélben.
• A felhasználói felülete ótvar. Ki hitte volna hogy GWT-ben is lehet ocsmány weboldalakat szerkeszteni? :-)
• A használhatósága csekély, pl keresés nagyon hiányzik belőle, de a saját lezárt patcheimet sem tudom átnézni benne.

Java Fight Club, Kanban, Smartphone

A JUM-ot sajnos úgy tűnik nem sikerült újraéleszteni.  Elek Márton, az eredeti ötletgazda és szervező twitjeit Svájcból lehet hallani hébe-hóba, sokan mások is elköltöztek és végül ennyi lett. Sajnálom, mert egyébként egy nagyon hasznos dolog volt. Mindenesetre köszi azoknak, akik csinálták!
Nekem csak kérnem kellett, és ti megcsináltátok, bárcsak mindig ilyen könnyen menne.

Nekem azért hiányzott a klub és nekiláttam egy hasonló találkozónak Brno-ban Java Fight Club néven az iroda csodaszép 5. emeletén. Szóval az alapötlet az annyi, hogy aki van olyan jóarc, hogy valamivel felkészül, azt segítsük meg annyival, hogy nem neki kell az időpontot, helyet, kivetítőt és egyéb technikai dolgokat megoldania, a közönséget ne untassuk azzal, hogy valami marha elkezd kötöszködni az előadóval, kezdjük el idejében a prezentációt satöbbi. Nem voltunk nagyon sokan, úgy nyolcan, az az első alkalomra egész jó.

Első prezentációként Jelinek Tamás beszélt a Kanban-ról. Egész idáig nem jött át nekem miért jó a kanban, a termelésleállások az egészen hajmeresztőnek hangzanak, a legtöbb munkahelyemen a managerem szerintem leszarta volna a termelésleállás okát, inkáb kirúgtak volna csak ne kelljen foglalkozni azzal hogy mi a gebasz.

A második prezit Szöcs Vojtech nyomta Smartphone fejlesztésről, ugyanis szeretne egy mobil klienst az oVirt-hez (én is nagyon szeretnék) Piaci összehasonlítás android vs ios, alkalmazásfejleszés költégei, illetve html5 appok.

Egyébként egészen jó szakmai élet van a Vörös Satyesz Vasgyárban, legalábbis ami a linuxereket illeti, de én nem vagyok igazán linuxer. Nekem a linux csak egy az operációs rendszerek között.

iwiw must die

Ma kitudja mennyi idő után elösször jelentkeztem be az iwiw-be, de most is csak hogy megkeressem a regisztráció törlése gombot. (Ugyanis nekiláttak spamelni.) Elszüttyögtem egy kicsit rajta, jól elrejtették a gombot, de nem annyira, mint a faszbook. Ez a kis howto segített, mert totál nem igazodtam ki rajta, hogy mi merre van: http://www.evenorbert.net/2010/10/iwiw-profil-torlese/

esti mese: kicsi mock és a memory leakek

Hol volt, hol nem volt...
Az oVirt engine-ben egészen félelmetes mennyiségű statikus kódunk van, statikus változókkal. Ez önmagában még nem lenne baj, persze egy tipikus Util osztály csak statikus metódusokból áll, ilyet kb mindenki csinál. A gubanc talán ott kezdődött, hogy IoC helyett is statikus metódusokat használunk. Pl ha szükséged van egy Dao objektumra, akkor így kéred el: DbFacade.getKakukkDao(), ami egy statikus metódus. Na most mi van akkor, amikor egy olyan kódot tesztelnél, ami ilyen módon szeretne egy DAO-t használni?
Mondjuk egy dummy DAO-t gyorsan összemockolsz easymock-kal, de hogyan tömöd bele abba a statikus metódusba, amit a tesztelendő kódod meg fog hívni? A válasz általában az az lenne, hogy sehogy, dögöljön meg aki írta.
No itt jön a képbe a PowerMock, ami arra az elvetemültségre képes, hogy a classloadered buherációjával lecseréli a statikus metódust. Ez a dolog tette lehetővé azt, hogy az egyébként tesztelhetetlen kódot módosítás nélkül mégiscsak tesztelni tudjuk unit-tesztekkel. Majdnem mindenki boldog volt, amíg N-nél több tesztig el nem jutottunk. Azt hiszem én vettem észre elsőként, mert én buheráltam a sonar-t az oVirt-en. Erről jut eszembe hogy kitettem egy openshift-es gépre a fél évig gyüjtött kódanalízist, ha kedved szottyan olvasgatni elalvás elött. Csak aztán ne nekem panaszkodj, ha rosszat álmodsz :-)
Szóval a Powermock-nak van egy nagyon rossz szokása: rettenetes memory leak-eket csinál a permgen space-ben. Párat talán kijavítottak a srácok, pár új meg talán jött útközben, de akármire is próbáltam felűberelni a Powermock + Mockito párost, mindi maradt egy szép nagy leak. Én viszont akkor is le akartam futtatni a teszteket, szóval a következőket heggesztettem rá a maven buildre:

• A surefire plugin startolja el a teszteket úgy, hogy mindhez külön VM-et futtasson (forkmode: always)
• A forkolt VM extra paraméterek között kapjon 2.5 GB memóriát, ebből 2 GB a permgen - na ez agyhalott, de kevesebbel nem futott le

Nos, ez idáig gondolom egy kicsit zavaró volt, de még koránt sincs vége :-D Pár munkatárs arról kezdett panaszkodni, hogy a fejlesztőkörnyezetükben nem megy le a teszt, pedig junkins-ban igen, illetve fordítva, ráadásul hol sikerül, hol nem. Totál összevisszaság :) Nos erről az derült ki, hogy a úgy hozzászokott a drága nép a forkmode=always beállításhoz, hogy egyes tesztek összemocskolták más tesztek futás környezetét, ja és persze a surefire alapbeállítása az, hogy a ahogy felszedte a filerendszerről a teszteket, abban a sorrendben fogja végrehajtani. Ez kicsit hülyébb a random sorrendnél :-)

A jelenlegi helyzet az, hogy az embereknek lerúgta az agya a láncot és visszadobják a teszt patcheket, ha powermock van benne. Szopódás, egyre nehezebb patcheket átverni a bürokrácián.

A tanulság: írj tesztelhető kódot, csínján a statikus dolgokkal.

No... itt a vége, fuss el véle. Aludjatok jól, álmodjatok EJB-ket. (vagy mi a f.szt)

komplexitás - röviden

A komplexitás nem az érték része, hanem az áré.

Szerintem. Csak ennyit akartam mondani, kérem kapcsolja ki. Boldog pénteket!