I will work for food

Java Architekt - a gyakorlatban

2012-01-26T20:54:00.002+01:00

István múlt heti postjára szeretnék egy kicsit bővebben reagálni, mint ahogy kifér egy pár soros kommentben. Technikailag nagyon korrekt definíció egyébként, de egy két dolgot hiányolok belőle és pár dologban buktatót látok.

Szóval szerintem...

Elösször is azt tenném hozzá, hogy amennyiben valaki - az architekt pl - meghatározza a szoftver archiktetkúrát, amiben a szoftver-fejlesztők dolgozni fognak, akkor annak az embernek a felelőssége az is, hogy a szoftverfejlesztők mennyire tudják hatékonyan végezni a feladatukat. Amikor egy java architekt dolgozik, akkor arra kellene koncentrálnia, hogy minnél egyszerűbb és hatékonyabb eszközöket adjon a fejlesztőknek és minden komplexitást csak valami megfelelő haszonért cserébe (customer-value) engedjen be. Én ezzel szemben nagyon sok fejlesztésben láttam valami totálisan elszállt marhaságot. A 97 things - és István is - ezt javasolja architekteknek: ne az önéletrajzodat fejleszd. Persze nem ez az egyetlen oka annak, hogy egyes java projectek krónikusan halálcsillaggá nőnek, van a dologban némi buta ego-fejlesztés is.

Többmillió java szoftverfejlesztő nevében követelem, hogy amikor kiderül, hogy egy java rendszer elcseszett ökörség lett, az architekt szüleit legalább annyira emlegessék meg, mint a szoftverfejlesztőkét!
A hegesztőmunkás is el tudja cseszni, de általában ezek az hibák általában nagyon könnyen javíthatóak. Ellenben architektúrális hibák többnyire végigkisérik a szoftver életét.

A másik észrevételem az lenne, hogy István definíciója nehezen illeszthető össze egy akármilyen agilis, iteratív szoftverfejlesztéssel. Elösször is azért, mert az architekt a definícióban elvágja a fejlesztőket a klienstől. Láttam már olyan embert, aki egész jól játszotta az információfiltert, de ez nagyon ritka, valamennyi infót mindenki elszór, a delay pedig minden embernél nagyobb, mint a másfél másodperces csúszás a telefonvonalban. Másrészt az agilis szoftverfejlesztés nem különít el hosszú tervezési szakaszt. A tervezési szakasz nálam a waterfall modell szinonímája. Aki ezzel jön elő, az általában valami olyasmit forgat a fejében. Aztán tipikusan a fejlesztés alatt kiderül hogy jajj, az úgy finoman fogalmazva is szuboptimális lesz, de akkor már bukó van, mert implementálni köll.

Aztán a harmadik észrevétel: egy-egy cég szokásait és procedúráit kitanulni időnként évekig is eltart, de legalább hónapokig. Én ha nagycég lennék, inkáb a belső emberek között keresném a leendő architektek legalább egy részét. Persze nagyon jól jöhet a más cégtől érkező tapasztalat is, de annak még jó sok idő, amíg kitapasztalja, hogy mi működik és mi nem működik valójában az új helyén.

Aztán még egy utolsó észrevétel a tanulással kapcsolatban: Nagyon jó, ha valakinek volt rá pár milkája hogy meghallgassa az Oracle/IBM/SAP/RedHat/Anyámtyúkja kurzusát, de az katasztrófa, amikor ezek után a kurzusok után, a fenti cégek technológiáit és termékeit lenyomkodja a fejlesztők, a cég, a kliens és a felhasználók torkán, ha jó, ha nem jó. Ilyet pedig már mindannyian láttunk. Én inkáb olyan emberrel dolgoznék együtt szivesen, aki nem csak az Anyámtyúkja technológiáit és termékeit ismeri, nem nyalta be a marketinget, hanem gyakorlati tapasztalatai vannak, látott elcseszett és pöpec projecteket. És ha ez megvan, akkor az architekt kurzus valószinűleg nem éri meg a pénzét.

Ö... oszt ennyi, na kitomboltam magam :-)

selinux

2012-01-24T18:10:00.000+01:00

A selinux-szal kapcsolatban mindig volt egy olyan sejtésem, hogy az emberek többsége csak annyit tud róla, hogyan kell kikapcsolni. Erre utalt az is, hogy a gúglinak ha elkezded beírni, hogy selinux, felkínálja a népszerű keresések között a "selinux disable" lehetőséget. Ma hallgattam egy csákót aki a selinuxról beszélt és meglepetésemre tudott a problémáról. Az azért szimpatikus, hogy nincsenek illúziói... Aztán mutatott olyan selinux parancsokat, amiket 2 másodperccel később már nem tudtam volna leírni mert olyan rohadt hosszú volt.
Cifra szopatásnak vannak kitéve a desktop linux felhasználók, nem csoda hogy olyan ritka faj.

Fejlesztői napok februárban Brno-ban

2012-01-20T15:24:00.001+01:00

Brno-ban február 17-18.-án lesz a Fedora fejlesztői konferencia, péntek-szombat. Két track linux, egy track JBoss projektek. Kifejezetten érdekel a drools és a infinispan, mondjuk én hülye pont aznap leszek a szomszéd teremben kameraman de megpróbálom elcserélni.

Infók itt.

Ha jösz, szóljál és fussunk össze!

maven, java... és a linux!

2012-01-19T18:10:00.001+01:00

Ma tartottam egy prezentációt a Red Hat-nél a maven-ről. Jajj, már megint a maven, már vagy a negyedik vagy ötödik eddig életemben. Nekem már kicsit unalmas, de úgy gondoltam ezzel tudnék segíteni a legtöbbet a projectemnek. Persze megpróbáltam új nézőszögből, hátha úgy jobban átjön. Ugyanis maven-t használunk, de nem vagyunk egészen boldogok. Meg is érdemeljük szerintem, de ne aggódjatok értem, rajta vagyok!

Mindenesetre a srácok felének annyi köze van a java programozáshoz, mint nekem az ABAPhoz. "Aha, láttam már olyat!" A Red Hat csákók túlnyomó része nyilván kemény linuxer, égget scriptszag terjeng a levegőben, commandlineokban gondolkodnak, satöbbi. Na és a maven dependency resolution dolgára keményen beszólt egy srác, hogy nem akarnak jar fileokat letölteni a maven repositorykból, jöjjön szépen a buildhez a jar file egy szép csomagból az yum repositoryból. Oszt csókolom.
Elmondtuk neki -többen is-, hogy hát vannak még olyan srácok a világon, akik nem fedorát használnak. Ezzel nem akartam megsérteni de ők vannak azért többen, nekem oké a fedora. Is... akár... Szóval mit mondjunk a java fejlesztők és felhasználók többségének?

Sajnálom ez a java program nem fordul le Windows 7/OS-X/MyPetLinux operációs rendszeren, mert még nem csinálták meg a függő jar fileokat tartalmazó exe/msi/dll/rpm/deb/tgz/ fileokat az ő rendszerére.
(Osx-hez mi is a csomagolás? Na mindegy...)

Aztán meg mi java fejlesztők még mindig ott tartunk, hogy a java alkalmazás operációs rendszertől független amennyiben nem csesszük el ugye, és ezt előnyként értékeljük. Ugyanis bátran fel tudod upgradelni a linuxodat a legfrisebb linuxra, a java alkalamzásod még mindig ugyanazt fogja tenni. legalábbis jó eséllyel, de egy rendszer upgrade semmiképpen sem olyan seggfájás, mint ha OS-függő lenne. Ez egy üzleti alkalmazásnál szvsz rohadtul fontos. Míg ha a függűségeidet pl RPM-be csomagolod, a következő rendszer upgrade esetleg agyoncsapja az alkalmazásodat. Oszt csókolom.

Mit szólnál ha ezzel köszöntene reggel a rendszeradminod?

Hoppá, kicseréltem a hibernate-t az alkalmazásod alatt 4.x-re, maradhat?

Megijednél kicsit, nem? :-)

Azért egy pár sráccal beszéltem, azt hiszem még egy pár kört beszélgetnünk kell mielött azt mondjuk hogy oké értjük egymást, de rajta vagyok a témán.

Egyébként a prezi itt található. Sajnos a hangminőség csapnivaló volt, meg hát angolul se tudok. Ja meg beszélni se nagyon.

Alternatív nyelvek

2012-01-05T13:31:00.000+01:00

Érdekes az, hogy buzgón új nyelvet tanulnak az emberek, gondolva hogy azzal egyszerűbbek lesznek a kódsorok. Ezzel egyébként egyetértek, de a probléma nem annyira a kódsorokkal van, szerintem inkáb agyhalott architektúrákkal, agyonhízlalt rendszerekkel és az értelmetlen komplikációkkal. Aki most elbonyolított rendszert ír java-ban, az valószinűleg groovyban, scalaban vagy jruby-ban is ugyanazt fogja csinálni.

Valakitől még olyat is hallottam, hogy scala-ban gyorsabb lesz a rendszer. De és mitől lenne gyorsabb? Mondjuk ha nem ugyanazt a marhaságot írjuk bele, akkor elhiszem, de amúgy nem értem mitől lenne.

git

2012-01-04T14:53:00.002+01:00

Az utóbbi fél évben több időt töltöttem git parancsok kiadásával, mint tényleges java kód fejlesztésével. Ha így nézzük, a git nem valami hatékony eszköz. Persze könnyen lehet, hogy a leghatékonyabb eszköz arra, hogy patchetekt formázz, átrendezz újraírj, brancheket csinálj lokálisan, satöbbi satöbbi. Csak az a baj vele, hogy én pont ezzel nem akarok sok időt eltölteni. Java szoftverfejlesztő vagyok, java szoftvert fejlesztek és hibákat javítok, elég sok munkám akad és nekem ez a pöcsölés a gittel csak nyűg.
A tanulási idő is kicsit hosszabb. A subversionban mondjuk tudnod kell úgy 3-5 egyszerű parancsot ahhoz hogy egész jól elboldogulj vele. A gitben a duplájával se jutsz sokra, a paraméterezés pedig egészen elcseszett. Ennek megfelelően rengeteg embernek vannak vele nehézségei és úgy tűnik egy kicsi de nagyon elkötelezett rajongótábor nyomja.

Az, hogy teljesen decentralizált, kétségtelenül nagy előny lehet a linux kernel fejlesztésében, de nem hiszem hogy tényleg minden projectnek erre van szüksége. Azt hiszem pont ez a feature hozta azt a komplexítást, ami aztán kinyírta a hatékonyságot. Úgyhogy én a gitet már félig bepakoltam a 'technológiai maszturbáció' kategóriába.

Technológiai maszturbáció: amikor az ember valami nagyon szépre gondol, de valami nagyon csúnyát csinál :-)

One RSS to rule them all

2012-01-02T21:24:00.001+01:00

Csináltam egy yahoo pipe-ot, ami összeönti a magyar java blogok tartalmát egybe. Ez van most kint, oldalt, csak van belőle egy változat, amiben nincs benne a saját blogom RSS feedje. Nyilván azt minek ide kitenni :-)

pipe (ha esetleg clone-oznád)
rss - ha olvasnád vagy kitennéd valahova
twitter acc - ha az rss nem elég trendi

Ha valaki blogját kihagytam, szóljatok! Sajnos nem sok az aktívítás, sok blog vált inaktívvá az utóbbi 2-3 évben :-(

hype-görbék

2011-12-21T23:32:00.001+01:00

A múlt héten a google publikálta a google zeitgeist oldalt. Kiválogatott top keresések igazából a hirtelen emelkedések voltak, a folyamatosan nagy forgalmat generáló kulcsszavak mellett igazán jelentéktelennek tűnnek, ha összeméred őket. Tanulságok:

Bulvár témáknál egyetlen dolog érdekel több embert: a pornó.
Ezen belül nem tudom megállapítani hogy mi miért lett falkapott. Steve Jobs-on kívül ezekről az emberekről még az életben nem hallottam...

De hamár google trendsnél tartunk, pár másik trendet is akartam mutatni a szociális hálók világából.

iwiw: 3-4 év emelkedés után most már második évben zuhanórepülésben van az iwiw népszerűsége.

Nem hiszem hogy meg tudnák állítani ezt a bukást, pláne nem a döbbenetes mennyiségű bannerrel és egyre nehezebben átlátható felülettel. (legalábbis ha félévente egyszer bejelentkezek)

Myspace: Az elöregedés elörehaladottabb állapotában van.

És megintcsak valami kárörömet érzek a dolog miatt. A világ legrondább weboldalai tűnnek majd el, ha a myspace meghal egy napon. Ezt a dolgot az iwiw is megirígyelte a myspace-től, de szerencsére addigra már a kutyát nem érdekelt az egész.

Facebook: szintén 3-4 év nagyon komoly emelkedés után, de nekem úgy tűnik, hogy ez az első év stagnálás.

A facebook azért érdekes, mert mindenhova beintegrálta magát, és egészen ügyesen csinálták. Websiteok milliói építenek valamilyen facebook funkcióra. Pl a like. Vajon ez megakadályozza majd a bukást?
Vagy az hogy kiregisztrálni nehezebb mint egy kötélen egyensúlyozva adóbevallást kitölteni? (A szar nyomtatványkitöltővel akár.)
Nagyon kiváncsi vagyok, hogy mit látok majd ezen a görbén jövőre. Most azt tippelném, hogy esést. Valahogy most elérte a csúcsot, kaptak érte oszkárdijat, címlapcikket a times-ban meg pármilliárd dollárt és kész, leereszt a lufi.

Google plus: a forradalom érdeklődés hiányában elmarad

Ezt mondjuk most még korai temetni, de 1 év múlva már valószinűleg nem lesz az.

Ami nekem nem tetszik a szociális hálók világából az az együttműködés és nyíltság tökéletes hiánya. Ez a google-plusra is igaz. A buzz megtörte kicsit a jeget ezen a téren, de ez a projekt már alulról szagolja. A jelenlegi helyzet ugyanis az, hogy a google nem csak az apit gyalulta le és a gmail-ből szedte ki, de google plus oldalakról is eltüntette. Szóval valószinűleg a legtöbb a kisérleti szerverem merevlemezén maradt meg belőle. Majd megpróbálok valami tréfás grafikát kerekíteni belőle (illetve bárkit érdekelne egy ilyen project?)

Szóval úgy tűnik a "social web" végre a zuhanórepülés státuszba kerül. Ha hihetünk a hype görbének, most egy recesszió után a produktív fensíkra kerülhet a technológia. Vagy egyszerűen csak megdöglik és kész :-)

Java kétségek

2011-12-02T10:26:00.001+01:00

A múlt héten két ismertebb java podcast, elösször a basement coders, majd a java posse is azzal a kérdéssel foglalkozott, hogy vajon van-e jövő a java programozásban. A basement coders egyszerű választ adott, had fordítsam le magyarra:

Java programozással több pénzt lehet keresni, mint python vagy ruby programozással. Ebből a pénzből lehet piros ferrárit venni, ti meg python köcsögök biciklizzetek...

Söt -ezt is elmondta az arc- a legkirályabb cobol programozónak lenni mert abból már nemcsak ferrárit, de akár űrhajót is vehetsz, saját parkolóval az ISS-en. Szivesen pofánvertem volna, ha lehetne remoteból is, viszont sajnos jól mondta. A pénz jelentős motiváció ha munkáról van szó, és pedig munkáról van szó. Azt azért nagyon sajnálom, ha egyeseknek ez az egyetlen motivációjuk.
A java posse azért kicsit intelektuálisabban közelítette meg a kérdést, ennek megfelelően a véleményüket nem tudnám pár sorban összegezni.

De a lényeg elég pofonegyszerű. A java közösség nagyon elbizonytalanodott az utóbbi 2-3 évben. Ez nem is igazán most kezdődött:

Az utóbbi 2-3 évben elterjedt egy csomó alternatív JRE nyelv: groovy, scala, clojure. A groovy persze itt van már jó 6-7 éve.
Már korábban elterjedt egy alternatív alkalmazásfejlesztési módszer az Enterprise cimke nélkül. Ez a lightweight és az enterprise nem nagyon fér meg egy cimke alatt.
Az Oracle opensource stratégiája nem mindenkinek tetszik. Meg hát nem csak az opensource stratégiája nem, de a Sun alkalmazottak jó része is elmenekült az egyesülés után. Az Oracle pereket és jogvitákat hozott, nem valami olyasmit, ami nagyon hiányozna bárkinek is.
A java nyelv fejlődése nem a régi, a java 7-re 5 évet kellett várni (és még mennyit kell majd) és ami benne van az hát elég szerény. Azért remélem ezen a téren lesz még javulás, ha az Oracle nem vágott volna ki egyes speckókat a java 7-ből, még ennyi se lenne. 5 évig vártunk a clojure-kre és nem lett belőle semmi. Hatalmas meglepetés lesz ha valaha egyszer meglesz.

timetraktor

2011-12-01T13:20:00.001+01:00

Sajnos nem láttam még értelmes timetrackert, pedig láttam néhányat. Például a D-nél egy fél évre lehalt a timetracker szervere. Amikor visszajött, megint kérték mindenkitől, hogy visszamenőleg is írja be. Fél évre visszamenőleg :-) Az egyik tesztelősrác összeütött egy zseniális tesztet, ami kitöltötte autómatikusan. Innetől a bürokraták megint boldogok voltak. Ennyi kellett csak hozzá! Az üzemeltetőknek ennél sokkal durvább volt, nekik 10-15 percenként be kellett írniuk, hogy mivel foglalkoznak. Szintén bevetették a saját megoldásukat, az egyik csákó ott egy pythonos GUI-t dobott össze (egész profin nézett ki), ami bár felpopuppol neki időnként, de volt rajta egy gomb, hogy "The same as previous". Ez bemásolta az előzőt és el is tünt az ablak azonnal.
Klassz megoldások.
Volt egy saját megoldásom is. Nem klassz, csak vicces: egyszerűen csak abbahagytam a timesheet írását - ez amúgy jellemző rám, nekem tavasszal se az adóbevallás jut eszembe. Eredmény: semmi, a következő 2-3 évben senkinek sem tünt fel. Azaz valószinűleg ez egy riport volt régről, amit már senki sem olvasott el amikor ott dolgoztam. Pedig egész sok időm került elba...ra ott. Mellesleg a projectem se volt felvéve, szóval úgyis csak kamuzni tudtam volna benne.
A jelenlegi timetrackernek még kell valami hegesztés. Azt látom hogy sikítanak érte, ha nem töltöm ki, de akármi is lehet benne. Például egy irodán kívüli munkanapot beírtam, és szóltak hogy írjam be hogy mikor jöttem és mikor mentem. De hát nem jöttem be, nem mentem el, egyáltalán nem voltam itt. Akkor mit írjak be? :-) Akármit. Az jó, mert az nagyon könnyen automatizálható.

Én ezt tartanám értelmesnek:
Az idő nem számít, gazdálkodj vele úgy, ahogy tudsz. Csinálj valami értelmeset, vidd elöbbre a projectet.

A szoftverfejlesztés nem gyártási folyamat.

Java vs Oprendszer

2011-11-29T12:40:00.001+01:00

Ma a gerrit-ről volt szó ebéd elött egy megbeszélésen, az egyik srác itt keményen próbálja betolni a fedora fejlesztői infrastruktúrára, hogy lehessen használni, de nagyon nehéz dolga van. Az előadás második felében tulajdonképpen egy vita bontakozott ki, hogy miért ilyen rohadtul nehéz java szoftvereket a linux disztrókba bejuttatni. Annyit elmondtak, hogy nekik újra kell fordítaniuk a forrásból a szoftvert. Ugyanaz a jar/war file lesz a végeredmény, de nekik akkor is újra kell fordítaniuk. Ezzel eleve van problémájuk, mert a GWT-hez van valami speciális dependency, amit alig tudnak megoldani. - kicsi flame szál a gonosz gúgliról. Aztán meg a fedorának nincs is policy-je a java war fileok telepítésére. Szóval egyhamar nem is lesz ilyen.

No eddig az, hogy a linuxosoknak mi a problémájuk a java programokkal. Nézzük csak nekem mi bajom van a linux-szal, annak ellenére hogy önként évek óta semmi mást nem hajtok...
A linuxokba örökké idióta kiherélt java futáskörnyezeteket telepítenek. A gcj egy tragédia, körülbelül semmi sem működik korrekten vele, az icedtea kicsit jobb, de konkrétan pár jboss termék is anyázik rá, ha azon indítják el. Egy új gépet mindig úgy kezdek használni, hogy leszedek egy használható sün/oracle jdk-t és mavent. Az már nem is érdekel érdekel , hogy yum-mal vagy apt-tal telepítsek jetty-t.

A java úgy indult el, hogy egy teljesen oprendszertől föggetlen nyelv és futáskörnyezet. Persze a linuxos rendszergazdák jobb szeretnének oprendszerbe integrált csomagokkal foglalkozni. A java viszont még mindig oprendszerfüggetlen és a szoftverfejlesztők nem igazán foglakoznak azzal, hogy akármilyen operációs rendszer vagy disztribúcióhoz csomagolják a cuccukat. Valljuk be elég sok meló lenne solarisra, debianra, ubuntura, fedorára ésatöbbi linuxra is külön csomagokat legyártani.

Kicsit megpróbálok elmerülni a rpm/deb packagelés és a linuxerek lelki világába, hátha meglátom a fényt az alagút végén. Ehhez valószinűleg most vagyok a legjobb helyen :-)

Egyébként visszatérve a gerritre: hogy lehet hogy GWT-vel csinálják és mégis ilyen szarul néz ki?

VDay 2011 Budapest

2011-11-27T20:17:00.001+01:00

Pénteken Budapesten voltam a VDay konferencián. Ingyenes konferencia létére marha jó, minőségi konferencia volt. Nulla bullshitelés, live demók és valós tapasztalatok, nem pedig marketing-fényezés. Gondoltam röviden beszámolok azoknak, akiket érdekelt volna de nem tudtak eljönni.

Klock László - Amit tudni akartál a vShieldről de soha nem merted megkérdezni

A vShield architektúrális felépítéséről és történetéről, biztonsági hibáiról. Hát ami igaz az igaz, rendesen le lett szidva a vShield. A hibák súlyát átérzem, de nem nagyon tudok hozzászólni mert soha nem használtam. Na és persze nem jött meg a bátorságom az előadástól.

Zrubecz László - VmWare vCenter Server Applience - vCenter linuxon

Másik VmWare technológia, amivel soha nem foglalkoztam :) Ezt tudtam meg róla: már régebben volt egy ilyen szoftvere a VmWare-nek, de abbahagyták és Windows-on árulták inkáb. Most, hogy a Microsoft inkáb a Hyper-V-t szereti, a VmWare is újragondolhatta a stratégiáját és most előjöttek újra a linuxos termékkel. Ez tulajdonképpen egy java-s webapp tomcaten (szóval ha egy ici-pici időt rászántak volna, mehetett volna ez a termék egyébként) alatta DB2 adatbázissal. Na ezen nem csak én buktam ki, hanem kábé mindenki. A DB2-vel horror-élményeim vannak. Láttam már mindenféle adatbázis szerverből hardware meghibásodás nélkül hanyattfeküdt példányt, de DB2-ből láttam a legtöbbet ahhoz képest hogy mennyire ritka egyébként.
Nos emellett a vCenter linuxos verziójának volt pár elszúrt része: iptables üresen, install csomagok rajtahagyva, statikus méretű partíciók a lognak és idióta syslog setup az stunellel. Hát, elég sok munkát ad még egy embernek ez a cucc, mire tényleg használhatóvá válik. De legalább van, a következő verziókban remélhetőleg meghallgatják a felhasználók imáit.

Lajkó Attila - A Red Hat Enterprise Virtualization 3.0 újdonságai

Ez a prezentáció érdekelt a legjobban (ugyanis ezen a szoftveren dolgozok napi 8+ órát). Kicsit mosolyogtam magamban amíg Attila a screenshotokat mutogatta, mert tudtam hogy a windowsos (.Net-es) user interfaceről készült képeket látjuk, egy ponton Attila ezt meg is említette. Na ekkor egyszerre 3 különböző embertől hallottam valami olyasmit hogy "Pffff..." :-D Hát ez van, de persze jön a szép GWT-s felhasználói felület, a srácok ott írják elöttem. Amúgy az újdonságok: multi level administration, host hooks, rest api, satöbbi. Nekem kicsit hiányzott az oVirt az előadásból, de nem kellett arra se sokat várni.

Kunszt Árpád - IPv6 biztonsági kockázatok

Hát, mégegy előadás, amintől okosabb és boldogtalanabb lesz az ember. Pár demóval (pl hup.hu hijack) megfűszerezett beszámoló. Nem szivesen lennék hálózati rendszergazda, de tágult a tudatom.

Deim Ágoston - Futás a végtelenbe

Ago eredetileg egy munkatársával ketten akarta bemutatni linuxos és windowsos virtualizációs megoldásokat, kvm vs hyper-v. A kolléga viszont beteget jelentett, így csak kicsit lettem okosabb a Hyper-V-vel kapcsolatban (sebaj, úgyse veszek windowst) jópár élő demót láttunk viszont a kvm parancssori és grafikus felületeiről. Egy ponton Ago az oVirt-et is megemlítette (Köszi Ago!), mint érdeklődésünk potenciális célpontját, amennyiben elég bátrak és türelmesek vagyunk hozzá. Azért ne aggódjatok, nagyon dolgoznak rajta a srácok, lesz packagelve mindenféle distróra: ubunturól, gentoo-ról és suse-ról tudok. (a fedora _nyilván_ beleértendő :-) ) Szóval csak a nagyon egzotikus disztrókra kell sokat váni talán.
Ago előadása egyébként talán a legszórakoztatóbb volt pedig a többi előadó is jó szöveget nyomott. Például amikor su - után mégse kért jelszót a szerver, de Ago elkezdte begépelni a jelszóként használt trágár szót a kivetítőre párszáz ember elött, az elég tréfás volt :-)

Egyéb

Több előadó használta az "Enterprise" szót pejoratív értelemben. Ezt meg tudom érteni. Sajnos viszont a java programnyelvet is lenézően említették. Szomorú, nem kellene, hogy így legyen. Az hogy java-ban programozunk, nem jelnti azt hogy totál idióták vagyunk. Legalábbis azt még nem.

Volt gépmutogató asztal, az Inteles srác mutogatta a félelmetes virtualizációs célszervert, amibe egy unitba 16 core és 196 GB memória passzol, és persze 6 unit fér el benne. Közös SAS diskarray és beágyazott management rendszer. Szóval egy atomerőmű. Gondoljatok csak bele mennyi passziánsz futhat ezen, már alig pármillió forintért.

A szomszéd teremben esküvőipari konferencia zajlott. Gázul hangzik, remélem soha nem leszek az ügyfelük.

Valamint baró jó volt a hazai kaja. A csehek nagyon tudnak élni de én a szakácstudományukat nem tudom annyira értékelni :-) Ezt ne mondjátok meg nekik! :-D

Virtualizáció határok

2011-11-12T19:23:00.001+01:00

Mindenki virtualizál és szerverkonszolidál ésatöbbi ésatöbbi... Pár ötlet arra, hogy mit ne virtualizálj :-)

Olyan szolgáltatásokat, amikre a hostjaid építenek, azt elég rossz ötletnek tűnik virtualizálni. Igazából marha fontos, hogy a virtuális és a fizikai gépeken futó cuccaidat elkülönítsd egymástól és a fizikai gépek közül azok, amik a virtuális gépeket hajtják (hostok) sehogy se függjenek azoktól a szolgáltatásoktól, amiket a virtuális gépek adnak. Ez remélem logikusan hangzik.
Példák: DHCP, TFTP, DNS, Proxy, satöbbi.
Többnyire az IO-intentzív appok, adatbázisszerverek tipikusan, ftp, nfs szervereketet nincs nagyon sok értelme virtualizálni, mert az IO sebesség a virtuális szervereken nem különösebben jó. Amennyiben pl valami teszt instance a MS SQL Server leges-legújabb verziójának, akkor persze oké, csak hogy kipróbáld hogy műxik-e.
Ha nem nagyon számít, hogy milyen szoftver van azon a szerveren (ftp, nfs) vagy a kliens akármit tolerál (pl hibernate vagy más JPA esetében az adatbázisok is ilyesmik lesznek) akkor értelmesebb a fizikai vason futó akármit használni a virtuális szerveren futó űberspeciális verzió helyett.
Amennyiben van fizikai vason futó szolgáltatás persze.
A virtualizáció egy apró kamuról szól. Több memóriát, CPU-időt és merevlemez területet adunk el, mint amennyi tényleg van. Ez nem egészen új az informatika történetében, a virtuális memória is ilyen. Ez többnyire oké és senki sem jön rá, még boldog is hogy ilyen olcsón megkapta. Addig tart a boldogság, amíg egyszerre nem akarják kihasználni a nem létező részt is.
Emiatt olyan dolgokat, amik nagyon határidősek, nem hajthatunk veszély nélkül virtuális szervereken, mert a szomszédaink terheltségétől függünk. Ha éppen beakadt egy végtelenciklus a szomszédos virtuális gépben, akkor emiatt nekünk pl nem jut annyi, amennyit szeretnénk. A teljesítménytesztek meg összevissza mutatnak mindenfélét.
Ha kifejezetten olyan rendszered van, amivel totál lefoglalod előre láthatólag sokáig a szervereidet, a terhelés folyamatos és előre kiszámítható, vagy esetleg a rendszered maga generálja a terhelést (pl crawlerek vagy akár valami JMS sorból jövő feladatok, satöbbi), az app hibatűrő, akár több szervered kiesését is jól viseli, akkor nem tudom a virtualizáció milyen előnyökkel járna. Pl hadoop, cassandra szerverek, egyebek.

Szóval nekem ezek tünnek a virtualizáció jelenlegi határainak és ezek nem igazán múlandóak. De persze egy technológia akkor jó, ha a határait is ismeri az ember és nem csinál vele valami ökörséget.

Kormányzat VS informatika

2011-11-11T09:31:00.000+01:00

Ma reggel egy e-mailt kaptam az ügyfélkaputól, hogy az APEH dokumentumot küldött nekem. Szívroham és újraélesztés után keresni kezdtem a dokumentumot, sehol. Rájöttem, hogy a pontosan évente 1 alkalommal használt ügyfélkapunk kellene belépnem és ott találom meg a nagyon bizalmas dokumentumot. Nos nézzük, vajon mi is lehet a felhasználónevem... X próba után sikerült eltalálnom, még pár kör, amig lereseteltetem a jelszavam és végre hozzáférek a titokzatos dokumentumhoz, amellyben ez állt:

Tisztelt Adózó!
Ezúton tájékoztatjuk, hogy a 2010. évi személyi jövedelemadó meghatározott
részének 1%-áról szóló 2011. évi rendelkezésében megjelölt, az Szf. tv. 4. §-ába
sorolható (civil) kedvezményezett részére az átutalást az állami adóhatóság
teljesítette.
Nemzeti Adó- és Vámhivatal

Anyátokat.

2011 van, és annak is már kicsit a végefelé járunk! Közben elköltöztem Magyarországról, eltellt egy nyár, egy ősz, satöbbi. Már ötletem sincs, hogy milyen civil szervezet azonosítóját írtam a lapra.
Miért kell szívatni ilyenekkel a kedves adófizetőt? Nem lehetne egyszerűen csak csatolni az emailhez? Vagy akár beletenni az email szövegébe? Nem kötelező háromszor becsomagolni.
Az ügyfélkaput tényleg évente 1 alkalommal, adóbevalláshoz használja valószinűleg az emberek tólnyomó része. Másra ugyanis nem nagyon használható.
Ugyanakkor fantasztikus, hogy az APEH 2011 végére eljutott oda, hogy már képes emailben értesíteni az ügyfeleit. Még ha ilyen beteg módon is. Senki ne merje állítani, hogy nincs haladás!

A kormányzatnak még mindig rettenetes szüksége lenne egy usablity expertre. Igazából ezt az alábbit már régebben összeszedtem és itt várt hogy egyszer meggondoljam magam és mégis kitegyem.

A kormányzati informatika gubancai

Amikor a kormányzat kijön egy új informatikai projectjével, ilyen tipikus reakciók voltak az utóbbi tizenakárhány évben:

mit tud: semmi érdekes, semmi hasznos
kitudódik a költségvetése: döbbenet, botrány, klónok háborúja (ahol a klónok persze rendesen lealázzák az eredeti rendszert)
hosszú távon vissza az első ponthoz.
Van más dolgunk is, meg ezt a pénzt már akkor elbuktuk amikor befizettük az adót.

A saját reakcióm még az mellette, hogy leég a pofámról a bőr, amikor ezek történnek, mert én is dolgoztam ilyen kormányzati projecten. És ti is, legalábbis néhány volt kollégámról tudom, hogy néha beleolvas a blogomba.

Szóval arra gondoltam, hogy összeírnám azokat a javító szándékú ötleteimet. Amúgy a kódot Auth Gáborék csapata már régen lenyugdíjazta szerencsére, úgyhogy én semmi titkos információt nem tudok.

Szóval:

A célt az határozta meg, hogy mit szerentne a miniszterelnöki hivatal akármelyik illetékes bizottsága a weboldaltól. Semmi kapcsolatom nem volt soha az MEH illetékesekkel, de nekem nagyon úgy tűnt, hogy hétköznapi internetes járókelőket nem kérdeztek meg arról, hogy mit szeretnének a kedves kormányuktól. - Amúgy a megkérdezettek több mint fele azt mondta volna hogy csak rohadjon meg és kész, de a maradékból biztos le lehet szűrni valamit.
A választási ciklus diktálta a fejlesztés ütemét és ezt senki se titkolta. Szerintem ez már szar, de a szó technikai értelmében még lehetne tortát csinálni belőle, ha nem 3 hónappal a döntő ütközet elött kezded el a halálcsillagot építeni. Természetesen halálcsillag volt a terv, nehogymár szakadt szputnyikot csináljon egy komoly kormány. Halálcsillag építéséhez legalább 20 év kell a CERN szerint is és a Lucasfilm szerint is. Ha nem is 20 év, de azért 6-9 hónap biztosan kellett volna ahhoz a fejlesztéshez. És hát kellett is végül.
Integráció és integrálhatóság teljes hiánya. Pl a saját azonosítási rendszer (ügyfélkapu) amit csak a kormány használ de ők is csak nagyon limitáltan és jobbára nem tudsz vele semmit se csinálni azon kívül hogy feltöltöd az adóbevallásodat. Azzal a botrányosan szar swinges nyomtatványkitöltővel, ami ontja magából az érthetetlen hibakódokat és amibe saját XML parsert írt valaki!
Publikus webes programozó interface? Bármi érdekes, amivel lehet játszani annak, akit érdekel. Például a hivatalkeresőhöz akár? Hallottatok ti már ilyenről? Egyébként pl a hivatalkereső megbízható adatokat nem igazán szolgáltatott.
3 teljes újraíráson ment át a rendszer, egyik sem adott hozzá lényeges újdonságot az előzőhöz. Csak egyszerű from scratch, project reset. Talán még el is vettek, leszedték a kommentelhetőséget mert csak az anyázás ment, de még az is csak elhanyagolható mértékben. Alig maréknyi ember alkotta a közönséget.
A költségvetésről nekem úgy tűnt (konkrét számadatoknak szerencsére nem vagyok birtokában), hogy egyszer sikerült erre a projectre pénzt szerezni és gyorsan azt a pénzt el kell költeni, vagy különben vissza kell adni. Amiből egyrészt a jól ismert waterfall modell lett, másrészt meg ott lett hagyva a rendszer hogy na most "kész" és gondoskodjon önmagáról - ugyanis elfogyott a pénz.
Harmadrészt pedig pazarlás lett belőle. Az erre vonatkozó számokat úgy nagyságrendben mindenki jól ismeri. Ez olyan, mintha január elsején kapnád meg az egész éves fagyipénzed és január 30.-án lecsekkolnánk hogy mennyit költöttél belőle, látják hogy semmit és akkor visszavonják.
Összeszedetlen csapat. Csak ehhez az egy feladathoz szedték össze a csapatot és aztán szélnek is eresztették. A következő projecthez kerestek másikat. Forming, storming, performing... Jó ha az első pontig eljutottunk.

Nem az volt az oka, hogy rossz programozók csinálták.

oVirt @ Budapest

2011-11-09T08:56:00.000+01:00

November 25.-én (péntek) lesz Budapesten a vday konferencia, amin Lajkó Attila, az ULX embere fog beszélni a Red Hat Enterprise Virtualization 3 (ahogy mi ismerjük RHEVM, de ne lepődjetek meg rajta, ha nogah, vdc, rhev vagy egyébb elnevezéssel találkoztok bárhol benne) újdonságairól. Remélem nem lövöm le az előadó egyetlen poénját sem, de az egyik újdonság az, hogy most már nyílt forráskódú oVirt néven. Az IRC csatornákon komoly tevékenység zajlik, vannak akik más rendszerekre (pl debian) csomagolják, sokan tesztelnek, satöbbi-satöbbi.
Ingyen konferencia, de több nagy játékos lesz jelen: Vmware, Microsoft, Novel, Citrix - szóval remélem nem lesz marketing bullshot. Annyira bízok benne, hogy én már be is regeltem, és kaptam rá egy munkanapnak számító napot. Biztos móka lesz megnézni hogy más milyennek látja a rendszert.
Ha jöttök, majd fussunk össze!

Favicon

2011-11-07T12:05:00.000+01:00

A banános favicon tisztelgés 11 évvel ezelötti főnököm elött, akinek határozott véleménye volt, hogy a programozó egyfajta majom. Így is hívott minket, hogy majomcsapat. Messze túltett az én halálcsillagomon, a "törpök életén" meg a többi közhelyeimen, ő ha beszélt, percenként kétszer biztos bevágta. Körülbelül úgy használta, mint a mélyen művelt honfitársaink a B+-t. Bár nem hiszem, hogy mind személyesen találkoztatok vele, gondolom ez az elképzelés senkinek sem új.
Vita tárgya lehet viszont az, hogy milyen ok-okozati összefüggésben áll ez a termék minőségével. Persze nem jó, ha űbermenschnek képzeljük magunkat, de még ha szükséges is némi negatív 'feedback' a munkánkról a helyreigazítás céljából, abban biztos vagyok, hogy ez már kicsit túllő a célon.

Lásd:

Köszi a blogger.com programozóinak, hogy lecserélhetővé tették a favicont :-)

Egyébként az 'I will work for food' eredetileg nem akart utalás lenni a kódmajom életformára. Valami olyasmi volt, hogy az első Sárga-70 túra útvonalára mentem ki útvonalat mérni, toltam a rohadt sárban hegynek felfele a mérőkereket (mint a jól ismert filmben), marha éhes lettem és közben találtam ki ezt a blogot.

Cassandra: további kisérletek

2011-10-29T23:21:00.002+02:00

Tanulgatok. Már egy pár hete hajtom a cassandrát és igazából egészen elégedett voltam vele 1 node-on. Összetúrtam 30 GB adatot hozzá a netről, meg írtam egy kis crawler jellegű programot, ami folyamatosan túr további adatokat hozzá. Mondjuk napi 2-3 GB adattal nő. Szóval az adatbázisomat szorgalmas írásnak is és olvasásnak is alávetem. Gondoltam kihúzom az adatbázisomat 2 node-ra. Ez valami marha egyszerű dolog. Felstartolsz mégegy processzt mondjuk egy másik gépen, aminek azt mondod, hogy az elsőtől ismerkedjen a cluster topológiájával. Azonnal ránéztem nodetool ring-gel, láttam hogy cassandra úgy döntött, az adatbázisom 40%-át, 9 GB adatot átküld a másik node-ra. Villámsebesen átmásolta, gigabites hálózat van a kettő gép között, sajnos inkáb a vincsi volt a szűk keresztmetszet. Az első érdekes dolog az volt, hogy bár az második node-on létrejött 9 GB, az elsőn nem tünt el. Aztán lekapcsoltam a második node-ot nodetool decommission parnaccsal, elkezdett visszareplkálni az első node-ra. Pár perc alatt kész lett, de ahelyett, hogy az adatbázis mérete megmaradt volna 30 GB, megnőtt úgy 40 GB-ra. Mégegy ugyanilyen kör után már 50 GB körül volt, aztán 60 GB körül. Ami azért bosszantó, mert még mindig csak 30 GB adatot tartok benne :-) Itt már kicsit bosszús voltam és nem akartam tovább rontani a helyzetet, hagytam ott az adatbázist, ahol van. Közben a cassandra őrült módon tekerte a merevlemezt, a crawler futott tovább, én meg elslattyogtam egyet sétálni. Most nem mentem 50 kilómétert, csak a parkba mentünk le. Mire hazaértem az adatbázis mérete visszaesett 30 GB-ra. Akkor esett le, a cassandra gyorsan szedte át az adatokat a második node-ról, de aztán viszonylag sok időbe tellett neki újraoptimalizálni a saját adatstruktúráját. Szóval erre figyelni kell akkor, amikor a clustert buheráljuk.

A másik számomra bosszantó jelenség az az, hogy startkor valamiért végignyalogatja az összes adatfilet. 30 GB egy gépen az nem valami sok úgy egyébként, de azért nem szivesen várom meg amíg azt mind felolvassa arról az öreg sata vincsiről. Erre a dologra még nem találtam magyarázatot...

Ja és a cassandra nyithatott volna egy saját kis fejezetet a konfigurációs témánkban is, yaml konfig. Hogy szinesebb legyen a kép :-)

Amúgy idáig nagyon tréfás kis adatbázis, jó móka játszani vele. Vettem hozzá könyvet is, hogy jobban haladjak.

Lecseréltem a favicont. Hogy tetszik? :-)

multitenancy

2011-10-19T17:16:00.001+02:00

Egyik este miután a több munkatársamtól is okosodtam virtualizációról és cloudról, operációs rendszerekről, kicsit már kiégett aggyal ez a történet állt össze a fejemben (bár valószinűleg nem első alkalommal)

Úgy kezdődött, hogy célgép. Mint pl az IBM csodálatos lyukkártyás rendszere még az 1940-es években amivel (a Corporation cimű film, emlékeztek... és más források szerint) oly sok embert továbbítottak a másvilágra. Ezek csak erre az 1 dologra voltak jók, nem volt cserélhető programjuk. Ahhoz képest azért igazán drágák voltak, de még így is sok pénzt takarítottak meg.
Ahogy tellett az idő, az emberek szerettek volna jobb befektetést csinálni, azzal, hogy többféle dologra használják a gépet. Így született a program. Eleinte 1 program futott egy időben egy gépen, de cserélhető volt. Ennél nem nehéz jobbat elképzelni: szeretnénk, ha egy időben egy gépen több program is futhatna.
Hát rohadtul leegyszerűsítve valami ilyen igényből született az operációs rendszer. Persze az OS pár szép dologgal jön még: filerendszer, hogy ne kelljen a disk-kezeléssel a programnak foglalkoznia, felhasználók, I/O, hálózat, felhasználók, memóriakezelés, sorolhatnám... tök jó helyen vannak ott. Kell mind.

Amikor viszont már több felhasználó több programja fut az 1 szál drága vasunkon, akkor igen valószinűvé válik, hogy össze fognak veszni az erőforrásokon. A felhasználók is, de a programok még inkáb. Gondolom nem kell példákat hozni memória-zabáló programokra, vagy CPU-zabólókra. Ez még a kissebbik baj lenne, de a konfigurációjuk is igencsak elburjánzott. Itt példaként említeném a hosts filet, amibe mindenki mindenféle ocsmányságot beletol, amit a DNS admin nem akart megcsinálni. Aztán vannak a szoftver-függőségek, kifejezetten az enterprise genyákon pl az SAP-nek meg az Oracle-nek kötelező valami olyan oprendszert venni, ami tanúsított ésatöbbi. Az adminisztrációval is kezdtek bajok lenni. Szóval oda jutottunk, hogy majdnem minden nagyobb rendszerünkhöz mégiscsak külön szervert veszünk. Bár mostanra nem egetrengetően drága egy szerver, azért mégiscsak drága _minden_ szoftverünkhüz külön szervert venni. Valahogy tényleg egyre több és több szoftvert használunk ahogy egyre több dolgot próbálunk számítógéppel csinálni.

Kis kitérő: amit a java csinál több szoftver-rendszer békés együttélése címén egy VM-en belül az a gyakorlatban ritkán vezet boldogsághoz. Igen, nem nyúlhatsz bele immutable objektumokba, nem babrálhatsz bele másik webapp kódjába, de ennyi és kész. A másik app felzabálja a memóriát vagy agyonhajtja a GC-t, felstartol 1000 idióta szálat, beblokkolja az összes http listener szálat, elfelejti zárni a streameket és kifutsz a file handle-kből, sorolhatnám. Van még itt ez az extrémebb eset is a the daily WTF-ről, nagyon gonosz. Ezer módon lehet az együttélés két java webapp között zűrös. Persze a jó programokra ez nem vonatkozik, de azokkal nincs is semmi gebasz, most a hülyékről van szó. Nem tudom a hülyék többen vannak-e, de azok több időmet viszik el.

A kis kitérő után eljutottunk a virtualizációhoz, ami lehetővé tette, hogy egy vason több oprendszer is futhasson a saját agyontákolt konfigurációival, a összebuherált szoftvereivel és nem vesznek össze, nem is tudnak egymásról.
Egyvalami nagyon nem tetszik még ebben: Rohadt nagy, drága szerverek. Ellentétes az általam tapasztalt valósággal. Egy hazai Pince Programming Kft-nél, de akár a százmilliós kormányzati projecten is a következőképpen működik a fejlesztői infrastruktúra: a rendszergazditól elkunyizzátok azt a Juliska néni leselejtezett gépét, amit már odacsűrt a kukára de még nem vitték el. Kicsit köhög a vincsi de még megy. Toltok rá Kedvenc Linuxot, Jenkinst, subversiont, gitet, sonart vagy amit akartok, berúgjátok az asztal alá és hajtjátok. Néha a takinéni kirángatja belőle a drótot (miközben letörli a képernyődet vizes ronggyal, pl amivel felmosott), ilyenkor kicsit kurblizni kell. Néha a rendszergazdi ellopja és kidobja megint, a kukásoktól visszaszerzitek. Ez így nektek ismerősen hangzik?

A másik probléma a nagy szerverekkel: egyszer minden gép befosik. Én olyat még nem láttam, ami nem. Jöhettek a legendákkal a befalazott gépekről, amit a nagybátyád unokatestvérének régi munkatársa másodkézből hallott. Amikor a crash megtörténik, nem 1 rendszered fekszik hanyatt, hanem mind. Kellemetlen.

Szóval magánvélemény erről a sima virtualizációról:

Szerintem tipushiba 1 böszme nagy gépet venni és arra tenni az összes VM-et. Ez mainframe-szerű maszturbáció. Ott fog állni az összes engineer és fogdossák a nagy gépet hogy jajjdejó. Persze jó én is birom ezeket a nagy böszme dobozokat, de több kicsi géppel jobban jársz teljesítmény és biztonság szempontjából is.
Az nagyon fontos, hogy a virtuális gépek ne legyenek szerverhez kötve, mert amikor égnek, együtt megy füstbe a valódi vassal a virtuális géped.

Szóval végülis odajutottunk a cloud-hoz. A virtualizáció csak egy lépés volt és a következő lépés a cloud. Vannak publikus cloud-ok, amik egész olcsón rohadtul nagy számítási kapacitást árulnak. Vannak private cloud-ok, amik a saját vasadon lehetővé teszik, hogy a virtuális gépeidet futtasd.

Ami nekem az egészben furcsa, hogy pl egy virtuális gépen egy java VM-et futtatunk. A host OS is és a Guest OS is virtuális memóriát kezel. Hány layer virtualizáción mentünk keresztül? Meg mennyire is lett ez az egész komplex?

OFF: Döglött méhecske

2011-10-17T09:13:00.000+02:00

A múlt héten a google bejelentette, hogy leállítja a buzz-t és pár másik API-ját, mert nem termeltek elég forgalmat. Nem vagyok tisztában azzal, hogy mi az "elég" egy google-méretű galaktikus birodalomnak, de ez nem az első eset, hogy "így jártunk". Néhány példa, amiből tanulhatunk:

A wave programot leállították, azóta az apache incubatorban látható (nem akarom olvasgatni, nálam a trehány kód kategóriába tartozik)
A translate API fizetőssé vált. A translate nagyon igéretes dolog volt annak idején, de aztán sehova se fejlődött. Ma a google translate a félrefordítás szinonímája, nem olyasmi amiért az ember igazán szivesen fizetne is akár. A translate toolkit is évek óta gondozatlanul áll, pedig az is nagyon hasznos kis eszköz lenne.
Többezer feltöltött maplet után a google maps is egyszerűen kidobta azt a soksok időt amit a rá fejlesztők beleöltek, megtartottak pár layert.
A google books talán amazon-killer akart lenni. Hát, azt hiszem lecsúszott róla. A book preview azért klassz.
A google checkout szintén megragadt amerikában és a britteknél. Akkor meg a boltok nyilván inkáb paypal-hez integrálódnak, az van kb mindenhol. Nem szeretném megpróbálni visszatartani a lélegzetemet addig, amig Magyarországon használhatóvá válik.
A buzz-t twitter-killernek szánhatta talán a google. Ha annak szánta, akkor eleve bukásra volt itélve.
A google+, aminek a javára kinyírják a buzz-t, alighanem ott lesz valamelyik a jövő évi takarítás áldozatai között. Már most ha bemegyek, a legfrissebb új dolog amit látok talán pár hetes. Jó oké van benne egy-két jó ötlet, amiből tanulhat a lófacebook ha akar.

Szóval ha azt a célt tűzik ki minden új projectüknek, hogy csak akkor tartják életben, ha totálisan átforgatta a teljes internetet és kinyírta a facebook-ot és a twittert, akkor kát a gőzért, egy-két éves periódus után minden projectjüket le fogják állítani. A google+-t is, ez gondolom már most gyanús a legtöbb embernek.

Ebből mindenesetre azt a következtetést vontam le, hogy túlságosan is google-fan voltam idáig. Túl sokat építettem a google szolgáltatásaira és aztán ezeket a szolgáltatásokat a google szépen egyenként kihúzta. Az ember kicsit másra számít egy nagy cégtől. Az nagyon szimpi, hogy a google nem áll be a sorba, nagyon becsülöm érte, de én a jövőben N+1-szer meggondolom, mielött bármilyen API-jukra építek valamit.

Pillanatnyi ötlethiányban szenved az informatika. A social networkok kiábrándulási fázisba érkeztek, Steve Jobs, az apple mágusa meghalt. A microsoft úgy 10 éve nem jött elő semmi újjal. A google nem tud olyan ötlettel előállni, ami túlél egy telet. A sun behalt. Az Oracle képtelen foglalkozni a java közösséggel. Szerintem most kell keresni a következő hullámot. Vajon mi lesz az?

Platform

2011-10-11T15:10:00.000+02:00

Folyik a platform háború...

A platform filozófia kicsit más, mint a szolgáltatás filozófia. A szolgáltatód ha kifexik vagy nem sikerül egy vitás kérdésben egyetérteni, akkor szépen átmész egy másik szolgáltatóhoz, csókolom. Ilyen pl egy internet-szolgáltató, video-encoder, DNS-szolgáltató. Fáj, nyilván, de pótolható, csak egyetlen dolgot csinált neked, a többi ezret másikat valaki más. Mindenesetre amikor a platformot húzzák ki a lábad alól, akkor sokkal nagyobb gebaszban vagy. A platform egy rakás integrált szolgáltatás. A válogatás többnyire nagyon limitált lehetőség, egy csomagban kapod az egészet és boldogulj vele ahogy tudsz. Nekem ez az ellenszenves vele, én jobban szeretek válogatni.
Azért persze igérik, hogy minőségileg ezek a platformok jobbak, mint amiket összebuherálnak az emberek amúgy. Ez szerintem kb ezt jelenti: az általános problémákat (hálózat-kiesés, adatvesztés, session replikáció problémák, satöbbi) ami mindenkit érint, legnagyobb priorítással kezelik, míg a speciális esetekkel kapcsolatban jó eséllyel magadra maradsz. Ez érthető, ilyen egynek lenni a millóból. Nekem ez őszintén szólva szimpatikusabb is. Nem fognak a management éppen aktuális legmagasabb priorítású projectje miatt speciális httpd url rewrite-okat megcsinálni, senki sem kap külön gépeket, ahol csak az ő cókmókja fut, nem dobnak be egy külön JAR filet valakinek az appszerverbe, csak azért mert szerinte az kell. Mindenkire ugyanazok a szabályok vonatkoznak. A házi-platformok örökké halálra vannak hackolva. Izgalmas proxy beállítások és url-rewriteok, nem is beszélve a összepatchelt appszerverekről, amibe beledobálták a xerces tizezer évvel ezelötti verzióját, mert az jó volt valakinek, a többiek meg majd megszokják. Persze mindegyik PaaS-nak megvan a saját problémája, pl a cron cuccok a gúglinál.

Lényegében nincs más kifogásom a PaaS ellen, csak az a cefet-nagy bizalom és lelkesedés, amivel az emberek belemennek (hype). Ezt a platform kérdést mindenki úgy képzeli el, mint a bal oldali képen (ahol persze ő nem a sikoltozó tinilány a szinpad elött, hanem természetesen szólógitáros énekes rockmetálisten) aztán X hóbap eltelltével baromi sokan érzik úgy, hogy inkáb a jobb oldali képen látható objektumhoz hasonlít a platformjuk.

Platform

Uram, a ~~halálcsillag~~ platformja támadásra készen áll, várjuk az utasításait.

Átkeresztelés

2011-10-07T10:03:00.002+02:00

Amíg fordul a GWT-s csoda és újraindul az appszerver, de még nem feküdt meg totálisan a gépem, ezt a kis ötletemet osztanám veletek:

Jó, muszáj a termék nevét beleírni a packagekbe, de ne írd bele se osztályokba, se változókba, adatbázis táblák és view-k neveibe, konfigurációs paraméterekbe ha lehet. Semmibe, amit nem akartok majd átírni minden egyes installációban, amikor átnevezik a projectet. Minnél kevesebb, annál jobb :-)
Olyan projecten dolgozol, amit nem neveznek át? Jajj, dehogynem nevezik. Van, aki semmi mással nem foglalkozik. Majd meglátod! :-)

oVirt

2011-09-21T23:02:00.002+02:00

A melóhelyi főnököm éppen most jelentette be az oVirt projectet. Ezen dolgozok én is és hamarosan open source lesz. Csak ennyit akartam mondani, mert amúgy ilyen projecten még nem dolgoztam, hogy mindenkinek ott lesz és használhatjátok. Annyi biztos, hogy ebből a szempontból szórakoztatóbb meló. Szóval majd figyeljetek :-)

Átlag

2011-09-19T11:17:00.000+02:00

Egy csomó olyan programozóval volt dolgom, akik úgy építettek szoftvert, hogy egy rakás komplexítást toltak bele, amire mindenhol figyelni kellett. Persze ezerszer belebotlottak saját maguk is. A varázsige az volt, hogy a szoftverfejlesztő nagyon inteligens és egyáltalán nem felejtékeny. Legalábbis mindkét képessége az átlag-ember felett van. A botlások alkalmával pillanatra feélretették ezt a feltételezést, és aztán csavartak mégegyet az architektúrán, megint végígtúrták az egész kódot és közben megerősitették hitüket, hogy cefet jó programozók.

Ez a megfigyelés (ami igyekezett objektív lenni, de csak eddig a pontig), és most a magánvélemény. Én ezt kapcsolatba hozom ezeknek a szoftver-projectkenek a problémáival. Azt feltételezték magukról a programozók, hogy nagyon nagyon okosak. És hát kétségtelenül azok is, csak nem annyira, amennyire hiszik. Egészen biztosan feledékenyebb vagyok az átlagnál és talán butább is. Lustaság szempontjából nem tudom hogy állok, annyi biztos, hogy a repetatív munkát nagyon hamar megunom és akár pár perc múlva már sorozatban szúrom el, annak ellenére hogy hamar ráállt a kezem és az elején egész jól ment. Előfordulhat, hogy lusta is vagyok.Szóval én inkáb arra szavaznék, ne építs semmit arra a feltételezésre, hogy zseni vagy és a munkatársaid is mind legalább géniuszok.
És ez a lényeg: a sok magamfajta hülye karbantarthatóbb, átláthatóbb és megbízhatóbb rendszert fog csinálni, mint azok, akik zseniknek hiszik magukat, de nem annyira azok, mint amenyire hiszik. Természetesen ez az igazi zsenikre nem vonatkozik, de idáig a guru egy mitosznak tűnik, soha nem találkoztam guruval. Pedig már tolom egy ideje a szekeret.

Hozzáállás: Én vagyok Gipsz Jakab. Minden fán ilyen terem.

Kicsit emészthetőbb formában egy hasonló vélemény itt: http://97things.oreilly.com/wiki/index.php/Don%27t_Be_Clever
A 97 things nagyon kedves kis gyüjtemény, érdemes olvasgatni. Van pár extra is hozzá, ami a könyvben nincs benne. (Megvan otthon a nyomtatott könyv, példaként arra, hogy CC tartalmat is el lehet adni)

Még egy hasonló lelkületű alapozó itt :-)

Gyárlátogatás: Logging

2011-09-11T23:55:00.000+02:00

A logging megintcsak egy érdekes és gubancos kis szál a java történetben. Nagyon szerény elvárásaim ezek lennének:

Legfontosabb: Ha a logging el van csűrve, azért az alkalmazás még csak menjen!
Lehessen konfigurálni a logging szintet
Lehessen konfigurálni azt, hogy hova menjen a log - többnyire file, valami archiválós megoldással vagy méret vagy idő bontásban, fejlesztőknek stdout, had kapjuk az arcunkba :) Vannak egzotikusabb megoldások is
Az nagggyon jóóó, ha nem kell újraindítani az appot a logging konfigurálása után. Ugyanakkor belátom, hogy egy évben csak egyszer van karácsony.

Mostanra sikerült odáig is eljutni, hogy a Logger-t kb így deklaráljuk:
private final static Logger logger = ...kakukk...

Ezt várja el a checkstyle, a PMD és a satöbbi. Nem tűnik nagy dolognak, de pl az avalon framework implementációi még bedobálták volna a komponenseknek egy setLogger metóduson keresztül. Persze nem kötelező így használni :-D

Nekem igazából nagyon szimpatikus ez a private final static dolog. A logger legyen a kód számára elérhető mindig. Ne írhassa felül semmi és ne lehessen null se. Amennyiben sikerült az osztályt betölteni, alighanem loggered is van. Innentől már nagy baj ezzel nem lehet.

Mit kellene logolni?

Hát kicsit izlés-codestandard-hitvita tárgya az, hogy mit mikor és hogyan kell logolni. Én nem hiszek a policy-kben, azt hiszem a józan paraszti ész valami ilyesmit diktálna, ha kellene a parasztoknak bármi ilyesmivel foglalkoznia: logolni azt érdemes, ami érdekelni fog hibakeresés közben, és persze csak olyan szinten, amilyen szinten keresni fogsz. Minden más csak a helyet fogja zabálni a szerveren. A logging frameworkok között enyhe eltérés van a szintek tekintetében. Azt hiszem van, ahol nincs trace szint, hanem debugnál kezdődik. Nekem a nagyon sok szint használata nem tetszik, nem tűnik praktikusnak.

Ja igen, bonyolult és anyázásig menő viták tárgya az is, hogy ha esetleg valami stringet hozunk létre a loggernek, amit logolunk, akkor csekkoljuk-e körülötte a debug szintet egy if-fel. Erre gondolok:

if(logger.isDebugEnabled()) {
logger.debug("Baromira fajt osszerakni ezt a stringet: "+getTerribleString());
}

Szerintem ezzel a legtöbb alkalmazásban nem lehet mérhető teljesítményjavulást elérni. Inkáb csak a kód komplexitásának növekedését. Illetve akinek tényleg már csak ez segített, annak had gratuláljak a kiválló termékhez.

System.[out|err].println()

Na ez a logging elötti logging volt. Már rég megástuk a sírját, már rég ott térdel a szélén, de még mindig nem húztuk meg a ravaszt. Nagyon sokan használnak még ma is ilyesmit. Ezt azt hiszem korrekt tudatlanságnak és/vagy igénytelenségnek nevezni.
Na jó, szóval ez trehányság, de akkor mit kellene használni helyette? A válasz erre kb 2-3 évente változik akár még egyetlen fejlesztő esetében is.

log4j.properties - köszi Bocinak a megosztásért :)

Log4j

Ha jól emlékszem a log4j volt az első komolyan elterjedt logging api.
A log4j-ről tudni érdemes dolgok 99 százalékát tudod, ha tudsz egy log4j.properties file-t írni. Na, ez az a dolog, ahol kiválló alkalmak adódnak a dolgok elcseszésére: illik nem belecsomagolni a log4j.properties file-t a csomagodba. Ezt azért a mainstream opensource libraryk tudják, de enterprise körökben frekventált elcseszés tárgya. Ez még mehetne a multkori konfigurációs kérdéskör boncolgatásához.

Ennyi: Igen, kell a log4j.properties file - pontosabban jó ha van. De ez a konfiguráció része, nem csomagolhatjuk a kódhoz.

Alternatív...

A log4j sikere után sok alternatív logging api jött. Az alternatívok közül legtöbbet a commons-logging projectet lehetett látni. Ha jól tudom a sikerének oka az, hogy az apache projectekben kötelező (volt?). Ez elég sovány ok :-) Mindenesetre a commons-logging már végülis facade jellegű. Azaz az API mögött végülis valamibe logol bele. Valamelyik másik logging frameworkbe.

java.util.logging

A java.util.logging így visszatekintve rá egy szomorú példa a JCP töketlenségére. Aki ragaszkodik a szabványokhoz, az biztosan használja is, de más okot nem is tudnék rá. Az az egy nagyon tetszett benne, hogy a jconsole-n keresztül lehet babrálni a logging szinteket. Még talán akkor veszi az ember használatba ha valamilyen oknál fogva nem akar semmilyen dependency-t. Ultra-minimalista cuccokhoz, aminek nem kell semmi, csak egy JRE, és megy.

slf4j

Simple Logging Facade for Java. Itt tart a történet. Ma kb mindenki slf4j-vel logol, én is. Egyszer valami podcastot hallgattam ennek az előnyeiről, és ilyeneket említett a csákó, hogy végre Loggernek hívják a loggert, nem Log-nak, mint a commons-logging. Hát ez elég sovány ok azért, ebben azt hiszem egyetértünk :)
A slf4j-nél tipikus elba, amikor valakinek az APIja nem csak a slf4j-api-n dependel, hanem berántja valamelyik logging rendszerhez kötő részét (pl tipikusan slf4j-log4j13-at amikor te már berángattad a slefn-log4j12-t). Ugyanis nem, ezek a dolgok nem férnek meg békésen egymással a classpathon. Természetesen ez egy gyógyítható betegség (pl maven dependency exclude), de néhány bosszús pillanatot sikeresen össze tud hozni.

...és végül: log4j :-)

Akárhogy is, de az összes konfigurációban, amit eddig láttam a facadeken keresztül a végén a logging üzeneteidet a log4j kapja meg, és file-be nyomja be. Az üzemeltető csapatok a log4.properties-t keresik, ha debugolni kell valamit. Ennyi.
Szóval ebből a szempontból a történet marha hosszúra nyúlt, de a lényege nagyon keveset változott.

A java elött

Nem tudom mennyire rendelkeznek a java elődei logging apival, amennyire emlékszem amit a CGI scriptekben stderr-re írtunk, na az volt a log, a stdout-ra, na az meg a kimenet. Nem túl kultúrált. A C kultúrám megintcsak félelmetesen alacsony, C/C++-ban úgy logoltunk, hogy precompiler direktívaként megadtuk a log szintet. Nyilván újrakonfignál újra kell fordítani, ezt nem nevezném valami baráti megoldásnak.

Update: átneveztem ezt a postot, hogy kicsit kiemeljem azt hogy nem arról szól, hogyan kell logolni, hanem arról, hogy miket láttam tényleg. Többi ilyen.

OFF: Red Hat és Brno

2011-09-02T11:34:00.000+02:00

Kicsit OFF. Nem szoktam fejvadászattal foglalkozni, de egyrészt sokan kérdeztetek emailben, linkedinen, satöbbin, hogy milyen itt és keresnek-e embereket, másrészt a HR-es lány is nagyon érdeklődik a magyar szakemberek iránt. Gondoltam akkor egy kicsit megpróbálok segíteni:

A brnoi Red Hat nagyon keres

JAVA programozókat, főleg GWT-s arcokat nagyon. (Itt mellettem dolgoznak a GWT-s arcok velem egy projecten, igyekszek kicsit ellesni tőlük valamit :)
QE pozíciók: rengeteg embert keresnek nagyon sokféle munkára és beosztásba script buherátorokat, bash, perl, python
Külön és kiemelten ruby arcokat

Ennyiről tudok én, de ez valószinűleg nem a teljes lista. Ha érdekel, akkor vagy dobj nekem egy emilt (firstname.lastname@gmail.com), vagy kérdezd közvetlenül a HR-es lányt, Tylert.

Kitelepülés: Nem vészes, de segítünk. A cég is segít, meg az itteni magyarok is segítettek egy csomót, szóval dobjatok levelet és megpróbálok segíteni én is!

Brno: Nekem tetszik, kellemes kisváros. Csendes, tiszta, baró jó közlekedéssel.

Halálcsillag Design Pattern - implementációk

2011-08-24T21:46:00.000+02:00

Halálcsillag Brno felett

Tényleg nagyon gyakran elmondhattam ezt a halálcsillag dolgot a régi munkahelyemen. Ezt kaptam ajándékba: egy kicsi halálcsillag. A képen éppen Brno felett lebeg.

Köszi :-)

Gyárlátogatás: konfiguráció

2011-08-24T10:56:00.002+02:00

A következő dolog, amit mindenki totál máshogy csinál a java/j2ee/jee környezetben az a szoftver konfigurációja. A téma sajnos nem annyira "egyszerű" mint az a képesség, hogy a verziószámot meg tudjad mondani, így hát igen szép számban van rá megoldás. Ezek a megoldások még csak nem is diszjunktak, simán átfedik egymást. Egészen biztos, hogy nincsen két ugyanúgy konfigurálható java szoftver. Illetve csak ha pont ugyanaz az ember írta mondjuk 1 héten belül. Szóval oltári buhera zajlik a téren. Mint mindig.

Elvárások a konfigurációval kapcsolatban

Ha én lennék az admin, most így fejből ezeket várnám el az appoktól és fejlesztőiktől:

Legalább az minor release-k között őrizze meg integrítását. Azaz a 1.0-hoz bütykölt konfig had menjen már el a 1.0.1-gyel is.
Ne az alkalmazásba legyen belebuherálva (WEB-INF/classes, satöbbi), hogy amikor az upgrade során rm -rf paranccsal kezeled a régi verziót (ja, backup, csókolom!) ne vesszen el a régi bugokkal együt a konfiguráció is. Legalább a környezet-specifikus konfiguráció ne az appban legyen!

Mint fejlesztő, nagyon szeretem azt, ha nem kell a fél életemet a fejlesztői környezet összebuherálásával töltenem. Értelmes alapértékek (akár pl egy beágyazott DB), könnyű felülcsűrhetőség.
Illetve ezt csak nagyon szeretném, baromi ritka az ilyen. Remélem nem úgy képzelitek el a halálcsillag építését, hogy kiszedik a dobozból, bekapcsolják és működik.

Plain Property file-ok

A property fileok ősi java feature és a legtöbb rendszer még mindig felhasználja a konfiguráció tárolására. Ezzel persze nem rossz dolog. Máig ez a legtöbb konfigurációs megoldás alapja, de persze a tiszta és legalapabb formája az, amikor pl a konstruktorban megkapod a Properties ojjektumot magát és bányásszad ke belőle azt, ami köll. Volt egy ennél kicsit szofisztikáltabb megoldás, ami csak a teljes konfig egy részét passzolta oda... lényegtelen. Ezek tipikusan az IoC-nélküli rendszerek.

Á igen, IoC

Az IoC egy olyan ötlet volt, amiért jópárszor leégettem magam azzal hogy próbáltam megmagyarázni a főnökeimnek valamikor régen, és néha még mostanában is. Ötlet: "Do not call me, I will call you!" Azaz az IoC konténer majd beállítja neked a konfigot, összekapcsolja az ojjektumaidat, elindítja az appod ha kész, illetve elhasal ha nem sikerült (ez esetben az jó, hogy hülyeséggel nem indult el). Ebből eleinte még két faj létezett, az intrusive (pl Avalon) és a non-intrusive, tipikusan POJO jellegű. Az elöbbit mára csak CVS-múzumokban találod. Az utóbbiból se a spring volt persze az első, csak a legnépszerűbb. Volt még elötte picocontainer, nanocontainer, és már a fene se emlékszik mik. Ma Spring, Guice, és az EJB is sok inspirációt kölcsönzött a téren ezektől a projectektől. Vitatkozhatnánk róla, hogy eleget-e vagy sem, de igazából nem érdekelne.

Még itt szeretném megemlíteni azokat a böszme nagy XML fileokat amiket írunk az IoC frameworknek és együt jönnek az appal szinte minden verzióban kicsit úthuzalozva és átkombinálva. Szerintem ne akarjátok, hogy az admin ebben matasson! Az merge-hell! Sírás-rívás, jajjveszék, rollback, cancel, és hasonló kulcsszavak jutnak róla eszembe. (Egy külsős fejlesztő szívatott ilyennel éveken át)

Spring, PropertyOverrideConfigurer és PropertyPlaceholderConfigurer

Ezt a két dolgot igazából nagyon szerettem a spring-ben. Ez megoldás arra, hogy az appcontext-ben összeállított konfigurációt felülcsűrd egy property file tartalmával. Tehát ide lehet tenni az X-et ennek én nagy rajongója vagyok még most is. A különbség a két dolog lehetőség között, hogy az override configurerrel mindent felül lehet csapni (söt, olyat is ami az appcontextben nem is volt benne), míg a placeholder configurer csak a placeholdereket helyettesíti be. Azért gyanús, hogy az előre kigondoltakon kívül jól jöhet, ha időnként más beállításokat is megváltoztathatsz. Természetesen az a placeholder configurerben viszont szimpatikus, hogy az éles rendszerektől megköveteli az előre definiált placeholderek értékének beállítását, különben nem indul el. Ugyanakkor még mindig jobban szeretem, ha a rendszer értelmes defaultokkal jön, és bármít felül lehet benne csapni.

Mindkettőnek van némi hiányossága. Pl listákat és map-eket nem kezelnek. Na erre mindenkitől láttam valami saját szintaxist és saját megoldást.

Jó, de hova?

Azt a kérdést, hogy hova tegye a rendszergizda a konfig fileokat, illetve az app hol keresse, az izlés és hitviták tárgya. Volt egy melóhelyem, ahol a unix filerendszerhez kellett igazítani a struktúrát. A konfig az etc-be, a program kód meg a usr-be (usr-be?!?!?!), felhasználókkal kapcsolatos dolgok talán a home-ba, adatok a var-ba. Igen, még mindig java szoftverfejlesztésről van szó. Vicces volt egész addig amíg rá nem jöttem hogy komolyan gondolják. Utánna már nem :-D

Mindenesetre a legtöbb program egyszerűen csak a classpath-on keresi a konfigját, többnyire {appnév}.properties alatt. Ez talán a legértelmesebb dolog, de minden appszerveren máshova kell dobni, hogy a classpath alatt legyen. Had sírjon aki migrálni merészel!

JMX!

A JMX még belerúg ebbe a témába kicsit. JMX-en keresztül beállíthatod az alkalmazásod konfigurációját, meghívhatsz rajta maintenance metódusokat, stb. A JMX király dolog, de arról nem gondoskodik, hogy a container újraindítása utánra is megmaradjanak ezek a beállítások. Az az app gondja. Valószinúleg ez lehet az oka annak, hogy hibakeresés közben láttam csak JMX-et, konfiguráció beállításhoz soha. Nevezhették volna inkább java debugging extensionnak.

JNDI?

Ha már a container szolgáltatásainál tartunk. Sokat tűnődtem rajta, hogy a JNDI miért csak annyi lett, amennyi lett. Semmi mást nem csinálsz vele, csak java.sql.Datasource és java.mail.Session objektumot halászol ki belőle, többnyire hardcode-olt címről. Az innen kihalászott objektumok előre fel vannak konfigolva a környezet beállításaival: hol az adatbázis, milyen adatbázis, hány kapcsolatot nyithatok rá, satöbbi, hasonlóan az smtp szerverrel. Na jó, még arra is használjuk néha, hogy a LDAP szervereken kurkásszunk valamit. Ennyi?
Tehát akkor az adatbázis és SMTP eléréssel kapcsolatos infókat akkor ott tartjuk. A többit miért nem? És ha a többit nem ott, akkor azt miért? Nem lenne jobb egybe tartani?
Kipróbáltam pár appszervert, a GUI/web-es felületeken keresztül egyik sem volt hajlandó a fenti kettőtől eltérő ojjektumot elhelyezni a JNDI fában. Kézzel be lehet haxolni.

Adatbázis

Remélem mindenki érzi, hogy egy komoly robosztus ACID-compliant replikált és backupolt nagy teljesítményű, 24/7 365 felügyelt RDBMS a legrojszrojszabb hely a világon, ahova a konfigját az ember berakhatja. Szóval legkevésbé sem ritka, hogy az appok az adatbázisban tartják a konfigjukat. Akkor már csak az a kérdés, hogyan éred el az adatbázist, de ezt többnyire a JNDI megválaszolja.

Én nem érzem a késztetést :-) Csupán technikai oldalról, nem értem mi haszna van az ACID viselkedésnek akkor, amikor olyan adatokról van szó, ami csak akkor változik, amikor éppen bütyküljük a rendszert. Sokkal hasznosabb ha gyorsan és egyszerűen hozzá lehet férni, mindig. Továbbá nagyon nagyon szép ha pl valami verziókövetőben tárolhatjuk, hogy tudjuk ki buherált rajta és mit, mikor hogy nézett ki. Egy text-file sokkal szimpatikusabb. Na ezt talán inkáb oda kellett volna írnom a propertyfile-hoz. Na mindegy, úgyis elcsesztem már pár helyen ezt a cikket.

Gyárlátogatás: verziószám

2011-08-17T17:33:00.003+02:00

Tipikus igény a szoftverekkel szemben, hogy meg tudják mondani a saját verziószámukat. Ez főleg azért kell, hogyha a kedves felhasználó meglát egy bogarat benne, meg tudja mondani, hogy melyik verzióban látta. Legalábbis hogy esélye legyen rá. Erre szedtem össze az általam eddig látott és használt megoldásokat, azzal együt hogy mi a tipikus elba**** velük kapcsolatban. Nemcsak hogy egyik sem tökéletes megoldás, de mindegyik szerintem elég töketlen. Persze a sajátját mindenki szereti :-)

Build script

Ez volt a leggyakoribb. Az ötlet annyi, hogy amikor buildelsz, akkor generáljon neked egy számot bele egy file-ba, amit valószinűleg besúvaszt utánna a classpath-ra. Ezt persze csak inkrementálgatni kell. Láttam olyat, hogy ez a file csak úgy "floating around" azaz akik release-t csináltak azok tudták a számozást, aztán volt olyan hogy visszakommitolták legalább időnként a verziókövetőbe. Ja még ezen belül is két különböző műfaj van, van aki verzió számot tart számon, van aki build számot. Szóval a kombinációk száma igen magas.
A tipikus elba:

Amikor nincs meg a file a classpathon, akkor valami törik
Elfelejted inkrementálni a build számot
Elfelejted a verziószámot bepakolni a verziókövetőbe, mielött tegelsz

Database, config

Olyat is láttam, hogy az emberek a konfigurációba, vagy gyakrabban az adatbázisba írják bele, hogy mennyi a szoftver verziószáma. Az egyébként tetszik, hogy az adatbázisban valahol benne legyen az, hogy milyen patcheket hajtottak végre rajta és milyen verzió satöbbi a jelenlegi schema, de akkor most az operátorra bíztuk, hogy felülbuherálja a verziószámot.
Elba:

Azon felül hogy anyukádat emlegetik közben, még rizikó tényező hogy az operátor valamikor visszacsinálja vagy átírja, vagy éppen ellenkezőleg: elfelejti átírni.
Az fenti elfelejtések simán ide is passzolnak

SVN-way

Ezt én találtam ki és hát primitív mint a szerzője: Csinálj egy osztályt pl Version néven, tegyél bele egy final static String mezőt, aminek az értéke legyen ennyi: "$HeadURL: http://svn.blf.hu/fubar/trunk/src/main/hu/blf/Version.java $", plusz egy metódust, ami fubar és az src közül kibányássza neked ami ott van: pl ennyi: StringUtils.substringBefore(StringUtils.substringAfter(version, "/fubar/"), "/src/"), ne felejtsd el a végén az svn property-k között a keywords-be beleírni azt hogy "HeadURL".
A build numebert nyilván hanyagolja. Csak azt adjuk oda bárkinek is, amit szépen betegeltünk.
Jó, a nyilvánvaló hátrányok elött felsorolnám hogy miért szerettem ezt:

Soha nem sikerült elszúrnom :) A Version osztály mindig valami értelmeset ad vissza. Pl azt hogy "trunk". A legdurvább elcseszés esetén semmit, de nem NullpointerException-t.
A release során simán meg lehet róla feledkezni. A release nálam ennyi: mvn release:prepare release:perform (így "howto release" manuált se írtam soha)
Ja és ez az egész substringes dolog csak a cicoma rajta, sima statikus text/html fileokkal is működhet, ha érti a felhasználód a HeadURL-t hogy mi az.

Akkor jöjjön a hátrány:

Totálisan SVN függő - azért volt ilyen a CVS-ben is, de arra már kiemlékszik
Az SVN-re meg most úgy fintorgunk mint a CVS-re úgy 6-7 évvel ezelött. Valahogy akkor jött ki az SVN, nem?

Még annyit a megoldás portolhatóságáról, hogy a git pl nemcsak hogy nem csinálja, de elvben is ellenzi. Linus Torvalds szerint írjál scriptet. Szerintem meg ... :-) Na mindegy, nekem ez nem tetszik, túlságosan könnyen elcseszhető. Meg bújja a git elba manuálját az, akinek nincs jobb szórakozása.

Ennyi... részemről

De kiváncsi lennék a ti tapasztalataitokra, linkeljétek vagy írjátok ide nyugodtan! Köszi előre is!

ping brno

2011-08-03T16:34:00.000+02:00

No, messzemenőbb tapasztalatokat nem tudok mesélni a Red Hat-ről, tekintve hogy pár napja vagyok csak itt. Szóval első impressziók:

Rövid eligazítás után egyből kezembe nyomták a gépemet, egy ThinkPad-ot, amit magamban csak TankPad-nak nevezek. Elég izmos gép, nagy ram, 4 core, nagy vincsi. Dokking sztésön, extra képernyő, egy angol billentyűzetet is sikerült kukáznom. Hardwer-ügyileg soha nem voltam ilyen jól elátva.
Az már az első látogatásomkor lejött, hogy a régi munkahelyeimhez képest baró csendes az iroda. Engem mondjuk a zaj nem nagyon zavart sehol sem, de jónéhány régi munkatársam mondott fel a zaj miatt. Itt inkáb ilyen könyvtár jellegű a hangulat.
Minden gépen linux van, én újabban az eddig gyűlölt Gnome 3-at hajtom, lassan megszokom.
Van Ingyen Ebéd! Hétfőn gyümölcsök, amúgy kb folyamatosan műzli. Az egészséges táplálkozáson túl pl tegnap esti release partin volt sülthús és sör is.
Na igen, a technikai témák jobban pörögnek mindenképpen. Örülök neki, mert ezért jöttem ide. Sajnos tegnap kicsit el voltam havazva (és ez folytatódni látszik) de volt egy JBoss AS 7 release party.
Ehhez kb hozzá lehetek szokva, de hiába költöztem ide, majdnem mindenki remote.
Vannak viszont magyarok, rajtam kívül hárman. Még nem volt időm megkeresni mindenkit :-( Eléggé el vagyok havazva.

Egyébként a város:

Egy része ugyanolyan koszos büdös, mint Budapest. Cejl bizonyos szempontból még Budapestet is alulmúlja, nyóckerszerű rohadó belváros. A város többi része tele van építkezésekkel, az egész nő mint a gomba.
Zseniális a villamoshálózat. Meg olcsó is. A legdrágább jegy forintba átszámolva 250-270 ft között lehet, ezért egy órán át utazhatsz a városon keresztül ha jól értettem akárhány átszállással. A legolcsóbb jegy 90 forint körül van (8 CZK), ez csak 10 perces utakra elég. Remélem nem értettem félre semmit, ellenőrrel még nem találkoztam.
Ez a része, ahol mi vagyunk (Královó Pole) egész csinos, parkos, tele van különféle egyetemekkel és van egy hatalmas infópark
A táj szerintem bejön azoknak, akik szeretnek túrázni (az IT szakmában tipikus)
10 évnyi Budapest után totálisan megdöbbentő, hogy ha a zebrához érek, megállnak az autók az úton, hogy átengedjenek.
A sör a legkevésbé sem érdekel, de amúgy a kaja, főleg a tejtermékek (ami az alap üzemanyagom) lényegesen olcsóbbak a hazainál.
A lakások és albérletek viszont marha drágák.

Gyárlátogatás: saját főztöm

2011-07-17T22:50:00.001+02:00

11 évvel ezelött landoltam egy új munkahelyen -azóta rég beszünt- , ahol valami tetűnagy rendszert fejlesztettünk C++-ban. Volt a dologban egy kis CORBA (béke poraira) és Oracle RDBMS, mert azt már akkor sem lehetett kihagyni semmiből. Érkezés után az űberführer mondta el, hogy mi is ez az egész. Egy chat szerver volt végülis, sok klienshez. Nem IRC protokol kompatibilis, hanem custom webes chat. Szóval az első reakcióm az volt, hogy "Klassz! Próbáljuk ki!", mire az űberführer már az első napomon korán reggel jól lecseszett: "Figyelj, nem érünk rá játszani, nagyon sok dolgunk van!"
Ez nekem ilyen tréfás emlék arról a cégről, mert végig ilyen volt, a termékeket soha nem próbálgattuk. Tellt-múlt az idő. Úgy kb 8-10 helyen dolgoztam azóta, ebből 2 helyen volt olyan ember, hogy "tesztelő". Igazából csak az egyik esetében jelentette ez azt, hogy az az ember automatizált teszteket programoz. Most már biztosan változott a kép, a sok kis magyar cég helyére többnyire multik jöttek, többszáz embert alkalmaznak és náluk nem az a QA, hogy "aha, kipróbáltam..."

A tesztelő mellett kiválló input lehet egy ügyfél (illetve a felhasználó, mert az nem ugyanaz) is, bár az kicsit változatosabb tud lenni minőségben. Például az egyik külföldi munkatársnő egyetlen hibajelzést tud leadni: "nem működik". Ilyenkor 10 email váltás, telefonon felhívom, satöbbi, fél óra amíg kiderül hogy a loginig el sem jutott, a browsere nem jut át a proxyn. Más felhasználókból egész értelmes dolgokat lehet kihúzni, mint például hogy nem értették hogy mire való az a gomb és nem merték megnyomni, nem találták a dokumentációban, pár kör levelezés után megegyezünk abban hogy hogyan tudunk segíteni.
Ez SCRUM-ban talán a product owner feladata lenne, de a személyes kapcsolat a felhasználóval azon túl hogy baromi sok időt emészt fel és néha még éjszaka is a munkahelyi leveleimet válaszolgatom meg, egyébként szerintem egyrészt sokat lehet belőle tanulni, másrészt pedig tényleg elhozza az egész problémakört oda. Ebben a problémakörben nem csak dolgozol, hanem ebben élsz. Azok, akikkel naponta spanolsz kint a konyhában vagy felhívnak valami problémájukkal, azok lesznek a társadalmi kapcsolataid, a te saját kicsi világod. Így egy kicsit más érzés egy problémán dolgozni. Nem azért csinálod, mert a managered azt mondta, vagy mert van egy jira issue rá és bekerült az iterációba, hanem azért, mert valakinek a környezetedből gubanc. Például volt egy hely, ahol ketten dolgoztunk 150 callcenteres nő között. Nekik az üzleti logikától nagyban fügött, hogy mennyi pénzt vihetnek haza hó végén, ezért munka végén volt aki bejött és megköszönte hogy jó munkát osztottunk neki (illetve a kód amit írtunk), vagy ránköntötte minden haragját amiért nem.

Csodálatos visszajelzés az üzemeltető csapat, amennyiben van ilyen :). Ők nem fogják megmondani neked a hiba okát, van ezer más bajuk, viszont nagyon precíz információkat tudnak adni arról hogy milyen hibajelenséget láttak és ez mennyire fáj. (rendszer outage, crash, túlterhelés, lassulás, memory leak, restart, satöbbi) Aztán persze tesznek rá, hogy a kód helyesen működik-e vagy sem, az már valaki más baja. Például az tök jó, hogy a vasműben minden nap többször is összefutok az üzemeltetőkkel. Másként nem tudok bemenni és kijönni. Szóval ha bármi gubanc volt, ők biztosan nem felejtik el.

Persze direktben a felhasználótól kapni vissza az élménybeszámolókat egy bizonyos mennyiségű felhasználó felett már nem szórakoztató, ilyenkor bejön a support, management, satöbbi. Csak szerintem annyira gyakran van az, hogy a management beáll középre a kommunikációt bonyolítani és nagyon lényeges információk vesznek el ezen a ponton.

No, ennyi jutott eszembe erről az eating your own dogfood témáról. Ja meg hogy csütörtökön palacsinta, az is a saját főztöm lesz :-)

Cassandra - eddig

2011-07-12T22:39:00.000+02:00

Mostanában szabad pillanataimban a Cassandra adatbáziskezelőt próbálgatom. Ez amolyan szakmai kirándulásféle nálam, mindenféle konkrét cél nélkül kipróbálok dolgokat. Nem jutottam még messzire vele, tényleg a bemelegítő gyakorlatok: működtetés, programozás, őszintén szólva nekem a thrift is teljesen új volt - bár nem újszerű, engem a dolog valahogy nagyon emlékeztet a CORBA-ra, de nem jutottam ezzel se olyan messzire, hogy elkezdjem osztani az észt két kézzel.

Eddigi olyan igazi járatlan út szaga van a Cassandrának. A dokumentáció felületes és jobbára törött, az API minden release-ben változik, programozni kicsit hosszadalmas és fapados érzés, a hibaüzeneteihez tolmácsra van szükség. A legtragikusabbnak az üzemeltetés tűnik.

Viszont amire kitalálták, arra ailghanem jó: nagy mennyiségű adat analízis jellegű feldolgozása. Majd ha befejeztem a teszteket akkor valószinűleg én is azt mondom majd, hogy baró és tetszik. De legtöbb embernek nincsen annyi adata, hogy ilyenekre legyen szüksége. Ez egy igencsak speciális eszköz. Kéremszépen legyenek szivesek megtekinteni a wikipédiát, ami kiválló példa arra, hogy a legtradícionálisabb LAMP architektúra is képes top 10 weboldalra jellemző terhelést elvinni. A lenézett és döglődő MySQL szolgálja ki.

Komolyan tartok tőle, hogy a NoSQL felhasználók jelentős része valójában csak a szép új technológia miatt nyomul az új generációs adatbáziskezelők körül.

Indigo - eddig

2011-07-07T21:49:00.000+02:00

Nagyjából átálltam az új eclipse release-re minden projectemmel, pár észrevétel eddig:

Mi a szösznek van még mindig benne a CVS kliens? Ki használ CVS-t 2011-ben?
Viszont defaultból benne volt az egit, az szép.
Szintén az alap csomagban benne volt a maven plugin is (m2eclipse) - na végre, csókolom, 2011 van!
Megintcsak az alapcsomag része google által bedobott GUI designer, amit a heliosba is belegyömöszöltem, de ebben alapból benne van. Öszintén szólva az egyetlen dolog amiért hajlandó voltam átbóklászni néha netbeans-re az a GUI designer volt, viszont ez jobban tetszik. Végre egy használható GUI designer swinghez, SWT-hez és azt hiszem GWT-hez is működik.
Egy csomó szép új plugint felfedeztem. Ilyenkor néha elszáll az agyam és próbálgatok, de az igazat megvallva nagyon kevés plugin éli túl nálam az első hónapot. Meglátjuk hogy lesz most.
Egyes pluginokat nagyon nehezen sikerült beszerezni. Pl a google web toolkit plugint égen földön kerestem a marketplace-ben, aztán a GWT UI létrehozásakor felajánlotta hogy letölti.
A legtöbben az eclispe marketplace-t használják (én is preferálom) pluginok beszerzéséhez. Hát ez az utóbbi időben a legváltozatosabb hibákat generálja a szerver oldalán.

Szóval 2011-ben is, eclipse az IDE.

Ez nem egy magyar blog

2011-07-01T15:39:00.000+02:00

Ma lépett életbe Magyarországon a sajtótörvény és aki valamennyire is ismer, az sejtheti rólam, hogy nem regisztráltam be ezt a blogot. Következő okokból:

Egyszerűen lusta vagyok hozzá. Még a postára se járok el, nyilván majd ugrok minden alkalomra ha valami jó kis nyomtatványkitöltésre nyílik kilátás :-)
A törvény szövegéből nem értek egy kukkot sem. Nem derül ki egyértelműen hogy rám és a blogomra vonatkozik-e vagy sem. A nagy általános érvényessége alapján a marslakókat is be lehetne perelni vele.
Persze a törvény nem ismerete közismerten nem ment fel, de viszont nem kellene egy tesztelő csapat a törvényekhez is? Hogy érthető és használható-e? Nem ad lehetőséget hatalommal való visszaélésre, stb?
A blogot nem Magyarországról szolgája ki a Google. Köszi Google!
Amúgy sem magyaroknak írtam, hanem csak úgy magamnak és az internet járókelőinek.
Pár héten belül befejezem a munkát Magyarországon és Csehországba költözök, Brno-ba. Az ismert médiacéget elcseréltem egy ismert technológiai cégre (Linux, Java, satöbbi, szóval nekem való helynek tűnik).
Mondta is valamelyik űberführer, hogy ha nem tetszik el lehet menni. Na, szóval én már megyek is.

Szóval úgy gondoltam, hogy ezek alapján rám biztosan nem vonatkozik, meg ha igen, akkor pár héten belül már nem. Nemsokára külföldi leszek...

A Halálcsillag Design Pattern

2011-05-27T00:13:00.000+02:00

A munkahelyemen valamennyire sikerült meghonosítanom a Halálcsillag kifejezést. 4 év alatt többször elmondtam, mint Palik a kegyetlent. Akkor most megmagyarázom, hogy mi is ez :) A következő a lényeg:

Évekig építik titokban akkora pénzekből, amennyi nincs is a földön.
De csak nagyon kevés ember használja, a többi max nézheti
Esetleg sikerül demonstrálni az erejét egy lényegtelen célponton, de egyből utánna jön gipszjakab meg kakukkjenő a kukacbombázóikkal és szétcsűrik. A kevésbé drámaibb végkimenet az, hogy egyszerűen csak elfogy a pénz és törlik a projectet.
A "2.0" projectet az első tragikus kudarca után lényegében ugyanúgy hajtják végre, lényegében ugyanazzal a végeredménnyel.
Az egész lényegesen több költséggel jár, mint haszonnal.
Ja és baromi lassú is, a Milenium Falcon simán rávert jó egy nap előnyt alig pár fényévnyi távolságon :)

A Halálcsillagra az előző nagyfejes azt mondta volna hogy böszmeség. Totálisan túlméretezték. Azon gondolkodtatok már, hogy mi lett volna, ha csak fele akkora Halálcsillagot építenek, de kettőt? Mondjuk nem tudja totál szétrobbantani a bolygót, csak egy pillanat alatt eltörölni minden életet a felszínéről? Az nem lett volna elég jó?

Pár informatikai projekt azok közül, amiket biztosan ismertek:

magyarorszag.hu - ennek valahanyadik 2.0-ás verzióján dolgoztam én is és hát nem esett messze az alma a fájától, de ez hosszú történet... azért volt pár egészen jó dolog is benne mindenkitől jól elrejtve
kormanyszovivo.hu - az például igazi gerillamozgalmat indított olcsó drupálos egyestés klónokkal

Ennyi a lényeg, biztosan értitek, minek is szaporítsuk a szót... Boldog pénteket mindenkinek!

Firewall vs JDBC

2011-04-29T22:52:00.000+02:00

Ma egy egész érdekes dologot találtunk meló közben. Érdekes egybeesésként ez ugyanaz a gubanc, mint amiről az egyik előadó is beszélt a 33degree konferencián, csak ő valami légiközlekedéssel foglalkozik. (hmmm, biztonságban érzitek magatokat?) A probléma alapja az, hogy a firewall-ok eltépkedik időnként a TCP kapcsolatokat. Egészen vicces, a szerver nem kapja meg a kérést, a kliens meg azt hiszi hogy elküldte, köztük a firewall röhög a markába, te meg nem érted miért áll a kliens, miért nem csinál semmit a szerver, és egyáltalán mi a rák történik. Ne tőlem kérdezzétek, hogy miért annyira fontos firewall-t telepíteni például az adatbázisod és az appszerver közé, szerintem ha valaki felhakkolta az appszervered és megvan az adatbázis kapcsolat akkor már régen rossz, de...
Ennek a problémának általában áldozatul esik néhány protokol, a lényegesebbeket említve RMI és valószinűleg minden adatbázis kapcsolat, általában a hosszú JMS kapcsolatok is, LDAP. Amit nem üt, az a HTTP nyilván, mert az bontódik amint lement a kérés és a válasz. Más most nem jut eszembe, ami jól működik vele :-)

Minden protokolra nem tudok orvosságot, de a commons-dbcp képes csekkolni az adatbázis kapcsolatot mielött odaadná a alkalmazás kódnak. Az 1.2-es verzió csak annyit tud, hogy elküld egy dummy kérdést a szervernek (tipikusan egy "select 1") és ha sikeresen válaszolt az adatbázis, akkor adja csak oda a kapcsolatot. Nem láttam még olyat, hogy a validation query elhasaljon, tulajdonképpen kicsit haszontalannak tűnik. Viszont amikor a fenti firewall gubanc beüt, akkor fentakadsz már a validation query-nél is, a kódod meg se kapja a vezérlést. Na erre a problémára ad megoldást a DBCP 1.3-tól kezdve a validationQueryTimeout paraméter. A DBCP 1.4 is már jó egy éve kint van, de amennyire látom még a legfrissebb cuccokban is az 1.2 van. Szóval egyéb hijján, akinek ez probléma, az kénytelen felülbuherálni.

Hát csak ennyi, remélem átérzitek :)

33 degree konferencia, Krakkó - II

2011-04-11T21:12:00.000+02:00

Folytatás tegnapról...

Jevgeni Kabanow: Do you really get memory?

Reggel máris kicsit meredeken kezdődött a nap, Jevgeni egy sajnát java-ban implementált virtuális gépről beszélt, szóval jó messziről futott neki a témának, mégis sikerült értelmes dolgot kihoznia. Például az Azul systems félelmetes garbage collectorát, ami a linux kernellel együtműködve egyszerűen kidobja azokat a page-eket, amiken már csak szemét van. Hoppá, erről ti is lemaradtatok? Én igen...

Házi feladat az egész, utánnanézni.

Brad Drysdale: HTML5 Websockets

Erről a témáról már írtam itt, túrkáltam a témát és... én sehogy se vagyok olyan optimista mint Brad a websocketekkel kapcsolatban. Egyetértek azzal, hogy hatalmas lépés a webapp architektúrában, de sehol se tartunk vele. Rövid helyzetjelentés: a chrome-on kívül minden böngészőből eltávolították a websocket támogatást, az IE-t leszámítva mert abban nem is volt soha. Semmilyen proxy-n nem megy át és azt hiszem a firewallok tevékenységét se fogja jól bírni a protokol. A servlet speckóban szó sincs róla, a mod_proxy nem engedi át... hát nem is tudom mennyi idő amíg ez a sok gubanc elmúlik. Azért megkérdeztem az előadót és kitérő választ adott, ami korrekt, én se mernék tippelni ennyi ember elött :-) Mindenesetre az ő munkaadójának, a Kaazing-nek van egy websocket gateway terméke. Szerencsére ezt csak említette, nem marketing-prezi volt, korrektül összefoglalta a technológiát.

A témában éppen most megint nyomulok és a elcsűrt prototipusomat írom újra, szorgalmi feladat ceruzás zöld kicsi egyesért.

Guy Korland: "Same data, any API", making sure your application scales

A szoftver architektúrák fejlődésének vicces bemutatása. Hát igen, ő pedig a Gigaspaces-től érkezett és az ő cuccuk tényleg elég jó trükköket tud. Annyi pénzért...

Nathaniel Schutta: HTML5 fact and fiction

Herr Schutta zseniálisan löki a rizsát a html5-ről is. Mint azt tavaly a w3c-s srácok kijelentették: a html5 nincs kész igazán. Hát most még mindig nem, de nem csak a IE miatt. Gyászosan áll a firefox is, még az Opera alakított a legszebben. És a kutya se használ operát. A video formátumokkal kapcsolatos háború meg csak nyúlik...
Viszont lassan tényleg változni látszik a web, lassan elveszti a jelentőségét a flash, stb...

Venkat Subranmiam: Programming Clojure

A Clojure veszedelmes. Igazi write-only nyelv, mint a perl, amit egy óra múlva már te se értessz. És hát volt is olyan, hogy Venkat kicsit elakadt, hogy vajon hol hiányzik rengeteg zárójel. Pedig a csóka elég rendesen pörög. De nem számít, egy pár dolog igazán zseniális volt a nyelvben és azt ki akarom próbálni. Komolyan, olyan rendszert, amit valakinek át kell adni, ami nem csak az én desktopomon fut, nem mernék írni benne, de ki fogom próbálni.

Házi feladat: prototípusok, nyelvtanulás, mérések.

33 degree konferencia, Krakkó

2011-04-11T00:03:00.002+02:00

A héten TVik-kel ketten elugrottunk a 33 degree java konferenciára Krakkóba. Csak mi ketten voltunk magyarok és talán egyéb külföldiből sem volt túl sok, ha leszámítjuk az előadókat. Viszont egy percre sem bántuk, hogy elmentünk, mert az előadók tényleg nagyon jók voltak. Nagy szükségem volt már egy ilyen pár napos cuccra, ahol kicsit távol a mindennapi munkámtól foglalkozhatok végülis a munkámmal :)
Az egész teljes költsége ha jól számoltam a végére úgy 80ezer forint lett utazással, szállással és regisztrációval együtt. Magyar fizetéshez kitalált összeg.

Alapelvek az előadások kiválasztásához: nem érdekel az "enterprise" és a "standard", ezek lejártak és beégtek. Más irányokban keresek tudattágítót.

Vettem pár papíros könyvet is:

Javascript Patterns - hát igen, sajnos szükség van arra, hogy rendre szoktassam magamat ezen a téren
The Myths of Innovation - a nálam szokásos tech-szkeptikus kategóriában
97 Things Every Software Architect should know - fogalmam sincs lesz-e ilyen szép címem valaha, túl nagy pofám van hozzá, de azért megpróbálok okosodni arról, hogy milyen egy jó architekt

No nézzük, előadások...

Linda Rising: Deception and Estimation

Linda Rising arról beszélt nekünk bemelegítőként, hogy az ember totálisan nem alkalmas hardver matematikailag pontos becslésekre. Egyszerűen az evolúciós multunkból adódóan.

Házi feladat nekem: A groupthink probléma megelőzését lökdösni a melóban, amíg nem működik.

Matt Raible: Comparing JVM web frameworks

A legfrissebb web-framework helyzetértékelés és összehasonlítás. Igazából, én nem használok web frameworköt, csak MVC-t és bár utálom kézzel hímezni a html-t, rájöttem arra, hogy ezekkel nem lehet ugyanazokat a trükköket megoldani, amiket a kézzel hímzett html-ben. A kedves ügyfél meg addig nem boldog, amíg pontosan az meg nincs, amit megbeszéltünk. Szóval ebből a szempontból ez a sok framework csak akkor érték, ha az ügyfelet le tudod beszélni a sok ökörségről és jópár értelmes dologról is.

Nathaniel Shutta: Hacking your brain for fun and profit

Rövid howto az emberi agyhoz, hogyan kell használni ahhoz, hogy optimális teljesítményt adjon egész hosszú időn át. Például érdemes aludni, esetleg egyet szunyókálni délután (amennyiben nem lép fel a kirúgás kockázata, de egyébként a legtöbb meeting pont ilyenkor van), sport, satöbbi.
Az ürégnek nagyon érdekes előadóstílusa van, biztos sokat gyakorol :)

Nathaniel Shutta: Going Mobile with JQuery

Ismét ugyanaz az előadó, de ezúttal valami hasznosabb dologgal. Ötlet: miért akarnál külön IPhone-ra, Windows7-re és Android-ra is külön klienst fejleszteni. Megtehetnéd ugyanezt szimpla HTML-lel is, és ebben segít a JQuery mobile. Úgy tűnik nagyon könnyen lehet vele összedobni kis webappokat és alighanem működni fog offline módban is...

Házi feladat: kipróbálni mit tud.

Shang Shin: Android Programming

Kemény 3 órás Android fejtágító, amin Tvik már majdnem elaludt (a vonaton alvás nem a legpihentetőbb dolog) de nekem nagyon jól jött, mert elég szegényes az android tudásom. Komolyan tetszett az egész. A csóka egyébként Sun-os volt, de az Orékülből nem kért, csinált inkáb egy saját kis java okosítócéget.

Ennyi volt az első napon, a többit megírom máskor mert holnap meló és addig még aludni is kellene, mint arra Schutta úr is rámutatott :-) Fogok is aludni, csak elöbb kipróbálok ezt-azt...

Új java blogom

2011-03-31T14:55:00.000+02:00

Gondoltam egyet és csináltam egy új blogot azokkal a dolgokkal kapcsolatban, amikre mostanában töredékidőmet rá tudtam szánni. A téma java teljesítmény mérések és ezúttal angolul írom. Rémes vagyok angolból, de majd belejövök. Had szokjam, had szokjátok :-)
Szóval itt van: http://dummywarhead.blogspot.com/

Persze ez a blog is megy tovább, de nem hiszem, hogy ezeket a tuningtémákat tényleg mindenki tudná értékelni.

Agile

2011-03-21T09:52:00.000+01:00

Az agile nem egy processz vagy fejlesztési metodika, hanem egy hozzáállás. Olyat lehet csinálni, hogy amúgy is agilis hozzáállású fejlesztők olyan metodikát választanak, ami passzol a stílusukhoz, de ha nem agilis fejlesztők választanak ilyen metodikát, akkor az csak nevében lesz agilis, egyébként inkáb az általuk megszokott munkastílushoz fog hasonlítani. Az ember nem gondolkodik mindig azon hogy most éppen milyen fejlesztési metodikával dolgozik.
Magánvélemény rovatunk jelentkezett, további boldog hétfőt! :-)

mod_cband, mod_bw

2011-02-27T09:54:00.000+01:00

A bandwidth throttling kiválló eszköz arra, hogy már a fejlesztőkörnzezetedben átélhesd a felhasználóid fájdalmát az alkalmazás nyomorult válaszidejével kapcsolatban. Hébe-hóba még egy-két bugot is segíthet megérteni. Amikor a localhostról jön a válasz, akkor irreálisan gyors válaszidőket kapsz, éles üzemben ilyen soha nem lesz és amikor párhuzamosan egymással több AJAX interakció is történik, akkor lehet, hogy valamit ráépítessz a válaszok sorrendjére. Pedig tök összevissza az egész. Szóval ajánlom figyelmetekbe a mod_bw és a mod_cband apache modulokat, ők segítenek olyan tré minőséget produkálni, mint amilyet az éles szerverek :-) Az egyik konfigurációban még két vmware-s virtualális szerverre épített clustert is bedobtam mögé, hogy az is igazán ótvar legyen.

process != progress

2011-02-16T19:45:00.001+01:00

A fejlesztők arra koncentrálnak, hogy minnél több és minnél frankóbb dolgot belepakoljanak a programjukba és sajnos néha ez buktatókkal jár. Úgy hívják a dolgot, hogy bug, defekt. Üzemzavarok, leállások, biztonsági hibák, kiskapuk, átgondolatlan UI, hiányos manuál, tákombákom, satöbbi. Ez ebből a fajta melóból kicsit adódik, de persze lehet koncentrálni a stabilításra, bugok persze akkor is lesznek amíg ember írja a kódot (meg szerintem utánna is, csak azt már senki se fogja átlátni)

Néhány súlyosabb probléma után aktiválódik a management és mindenféle metodikákat kezd bevezetni a probléma kezelésére. Kezdetben bár kisebb-nagyobb áldozatok árán de úgy tűnik sikerül megoldani a problémát (legalábbis lehet róla statisztikát hamisítani), de mivel egy-két csapat talál kiskaput, ezek a metodikák tovább nőnek és lassan kiterjednek a munka minden területére. Azon kapod magad, hogy a reggel vagy az egész délelött rámegy a standupra, esténként hosszú unalmas telefonkonferenciákon veszel részt, esetenként pedig beugrik egy-egy rendkívüli esemény is, "all hands meeting", satöbbi. Az iterációkat szinte lehetetlen összefogni, mert bár megvan a release, a deployment eltart hónapokig, ami szerintem ijesztő, de hát tényleg ez van. Mire valami kijut élesbe, már rég kész lennél a következő verzióval.

A folyamatnak ezen a végén megintcsak elkezdenek problémák jelentkezni, amik a process-ből adódnak. Páran (néha a többség) félreértették a processzt, nem igazodtak ki az eszközökön. Vannak tipikus problémák, például számítógépektől jogosan várjuk el, hogy nagyon sokáig emlékezzenek egy dologra és ha a feladat végrehajtásának két lépése között eltellik 2-3 hét, akkor is mintha az elöbb történt volna, tudják folytatni. Embereknél ez egészen viccesen nem működik, 2-3 hét alatt teljesen elfelejtik, hogy hol tartottak és amire ennyit kell várni, az egyszerűen ennél a lépésnél megakad és az emberünk totál elveszti a fonalat. Ez a dolog kellene a munkájához, szóval mit csináljon két hétig? Minden alkalommal menjen el nyaralni, amikor belefut egy ilyenbe? Egész életét havajon töltené.
Programozók ilyenkor szoktak jönni azzal, hogy "az én gépemen futott", a managerek pedig azzal védekeznek, hogy "nekem sikerült". Például a munkaadómnál a legrövidebb általam ismert SLA 10 munkanap, azaz két hét.

backend fail

2011-01-10T17:16:00.000+01:00

Mintha nálam tipushiba lenne a gubancos backend, amit integrálni kell a rendszerhez. Az egyik SOAP-os backend pl NPE-t vág az arcomba kiszámíthatóan minden alkalommal, amikor egy bizonyos metódust meghívok rajta teljesen tökmindegy milyen paraméterekkel. Állítja a szakember, hogy rosszul van telepítve és én hiszek is neki, csak akkor kérném hogy telepítsék fel jól, mert én akármit csinálok, mindig NPE lesz belőle.
A másik backend egy sima XML+http és a szerver oldalon mysql+php, de valami trükköt mégis csinálhattak rajta, a continuous integration szerver ugyanis egymás után kétszer is hibát jelzett a tesztben. Egyből éreztem kis motivációt utánnanézni és ez derült ki: két rekordot küldök át neki, a másodikban benne van az első ID-je, amit nyilván csak akkor kapok meg, ha az első sikeres volt. Általában működik is, de néha nem, néha azt van képe állítani, hogy az előző rekord nem létezik. Tipikus cluster hibának tünt elsőre, hátha aszinkron replikáció van adatbázisok közt, hogy az is "elég jó" és akkor kicsit várni kell, hogy szétreplikálódjon az első rekord, mielött becsapódik a második. Savanyú arccal a kettő közé tettem egy obj.wait(fubar)-t és lefuttattam újra a tesztet és ocsmány pofáraesés... megint elhalt. Úgyhogy kijött szépen az obj.wait és a helyére bement egy catch és retry. Most gondolj egy szóra... nekem is csúnya szó jutott eszembe.
Régebben meg volt a paypal történet, amit ha nem velem történik, nem hinném el senkinek és volt egy egész csinos rakás kis buhera a többi gubancos backendek kezelésére, azt gebaszos backendek egész hada idézte elő, az akkori projectem 9 backenddel tartott kapcsolatot. Mára azok szerencsére elmúltak de a helyükre újak jöttek.

A gubancos backendek megfigyelésére a múlt héten összeütöttem egy kis webappot és ez életem egyik leggyorsabban megtérülő befektetése lett :-) másnap reggel máris hibát jelzett és még a helyszinen elkaptam a merénylőt, aki buherálta az adott backendet.

Szóval a backendek az eddigi tapasztalatok szerint kulcsfontosságúak a szoftverhibák megvalósíŧásában. Ha csak egy mód van rá, használj inkáb beágyazható megoldást, legyen pár failover opciód, hogy ne menjen dőljön be az egész project, ha egy szolgáltató kifekszik.
A felhasználóidat ugyanis nem fogja érdekelni, hogy hol és miért volt gubanc, nekik áldozat kell majd és te vagy a legközelebb.

ERR_TEMPORARILY_THROTTLED

2011-01-06T21:05:00.000+01:00

ERR_TEMPORARILY_THROTTLED

A Chrome 9 bétájában van a fenti feature, ami egy kicsit halva született gyerek. Szóval ez azt csinálja, hogy ha 500-at, 404-et dob a webappod, akkor az érintett URLt nem kérei újra CTRL-R-re de még CTRL-SHIFT-R-re sem, hanem töröttként jeleníti meg, egészen újraindításig.

Gondolom az volt az ötlet, hogy a Chrome megpróbál nagyon jófiuként viselkedni a weben és nem piszkál olyan dolgokat, amik nem működnek. Viszont sajnos a web fejlesztés oltári szívás így, mert egy hiba után újra kell indítanod a böngésződet, hogy megint megpróbálhasd elérni az adott URL-t. Hát remélem ez elmúlik, mire lekerül a béta cimke, de nekem elég volt ahhoz, hogy fejvesztve visszameneküljek a stabli verzióra és firefoxra.

Google Ads vs Chrome Malware deffense

2010-12-30T21:22:00.000+01:00

Azon ritka pillanatok egyike volt, amikor érdekesnek találtam a gmailben oldalt a reklámozott terméket (az esetek messze túlnyomó részében észre se veszem) és rákattintottam, a chrome "Mailware Detected!" oldala ugrott be és figyelmeztetett, hogy valami nagyon csúnya dolgot akar csinálni a weboldal.

Közben Wax Tailortól a "There is Danger" cimű szám szólt :-) Ha már itt tartunk, holnapig biztosan nem találom fel a világmegváltó bitet és kisebb dologért miért is írnék ide, szóval legközelebb jövőre és addig is érezzétek jól magatokat és Boldog Buékot!

És bocs ezért a totálisan OFF postért! :)

web és videó séta

2010-12-29T22:09:00.000+01:00

Az utóbbi pár év körülbelül a webes videó forradalmaként írható le, annak ellenére, hogy szabványosítás igen kevés történt a téren. Nyílt szabványok pedig szinte semmi. A két világ teljesen két különböző irányból indult, a képfelvétel 100-éves történetre tekinthet vissza, hatalmas üzlet épült rá és kicsi tudományágak fejlődtek körülötte már akkor is, amikor az internetről meg a számítógépek a legelszálltabb fantáziákban se voltak. Körülbelül ennek a 100 évnek az áporodott, ügyvédszagú hangulata lengi körbe a videószabványokat is. Egy magamfajta webjunike-nak igazi fény az éjszakában egy-egy olyan formátum, mint az ogg video, pár olyan szoftver, mint az mplayer/mencoder és az ffmpeg. Ne legyenek illúzióitok velük kapcsolatban: házi technológiának teljesen oké, de amikor be akarod vetni a céges környezetben, akkor ismét ügyvédelésre kerül majd a sor elöbb vagy utóbb. (az "utóbb"-ot nem merném megkockáztatni) Én még arra se tudtam rájönni, hogy kinek a patentjeit kell megvenni, van rá ugyanis több jelentkező és csak egy dologban egyeznek: arany árban mérik a patent díjat. A patent díj természetesen nem a kód, ami működni fog, hanem az engedély arra, hogy megpróbálj működő kódot írni vagy megvegyél egy implementációt. Legalábbis ahogy ők képzelik. Jó mi? :-)

Flash Video

Jelenleg a felhasználók messze túlnyomó része a flash pluginon keresztül részesül a web vizuális élményeiből. Lehet utálni a flash-et (és én utálom is), de rendesen egy évtizeddel megelőzte a html-t ezen a téren. Persze az egész flash világ nem igazán nyílt, bár próbálkozott az Adobe de szerintem későn, keveset és úgy tűnik hamar feladták. A flash maga egy szőrös jeti, a linuxos webkamera támogatás talán már évek óta törött de 64-bites windows 7-en se sikerül bebuherálni, IPhone-on nincs és nem is tudom lesz-e, a nem nagyon mainstream felhasználókról valahogy mindig megfeledkeznek.
Szóval a flash videó felfelé RTMP protokolon csorog. Ez a protokol egy bináris horror, félig nyilt specifikációval. Azaz az RTMP specifikácó (vagy 20 oldal a licenszinfó nélkül) ami leírja a csomagformátumot elérhető publikusan, ez alapján viszont még nem tudsz összeütni egy streaming szolgáltatást.
Nyilván ez a marketing-hajtómű az Adobe Flash Media Streaming Server terméke mögött. Ingyen van a plugin, most már a fejlesztő SDK is ingyért van (söt open source), viszont a tényleg csili vili dolgok mögé muszáj szervert arany árban mérik, per proci licensz, satöbbi. Ez persze b...ta pár ember csőrét és megírták a Red 5-ot.

Red 5

Had kapjon egy kis külön bejegyzést, mert a Red5 egyszerre rajongásom és utálatom tárgya. Igazi ambivalens kapcsolatunk van (emlékeztek még ilyen kifejezésekre irodalom órákról). Nemcsakhogy -valószinűleg- a Flash Media Server vagy a flash reverse engineeringjéből nyert ihletést, de hozzá hasonlóan nem egy szimpla szottyadt jar file, hanem a Red5 maga az alkalmazás szerver, tulajdonképpen egy haxolt tomcat. Tomcated van? Geronimod van? Glassfish, Webklotyi, Web's Fear, egyéb ganaly? Dobhatod ki :-) A Red5 ezen kívül integrál pár ismertebb frameworköt: spring, hibernate, slf4j, groovy, jython. Szóval a Red5 platform, nem pedig library. Ezzel a következő a probléma: platformunk már van. Van logging cuccunk, van webszerverünk, van mindenféle (szvsz hajmeresztő) procedúra ennek a működtetésére, egyszerűen csak nem kell még egy platform.
A dokumentáció jelenlegi állapota soha nem volt jobb, ilyen jó és összeszedett Red5 doksit még nem látott a világ. Viszont az infrastruktóra többi része még mindig egészen félelmetesen szétszórt. A legjellegzetesebb eredmény a Red5 keresések közben a 404-es oldal. A Red5 egy buhera.
A platform vs library dologgal nem vagyok egyedül és találtam is jópár embeddable verziót, de mindet régen elhagyták 1 kiadott verzió után. Kis kalapálásba került a red5-ot lefeszegetni a tomcatről, minimálisan függetleníteni a saját spring megoldásaitól, maven artifactot építeni belőle és beágyazni egy webappba. Fáj, de járható, jónéhány kódmódosítás is kell hozzá.
És ha végigjártad, a Red5 szerethető, mert a fene se tudja miért és hogyan, de megcsinálja neked azt, amit semmi más: flash media streaming a java szerveredben, ingyen.

Még 2 dolog az RTMP-ről:

Az RTMP nem HTTP-n át utazik, szóval nézd meg a firewallt és a load ballancert hogy tudnak-e majd kezdeni vele valamit.
A RTMPT (http-wrappelt rtmp) lényegesen lassabb az RTMP-nél, de legalább átmegy proxy-n, firewallon, load ballanceren, satöbbin. (Vajon egy sticky bit érdemes oda?)

Html 5

Egy távli galaxisban. A HTML 5 két dolgot hoz majd egyszer a videó streaming világába:

video tag, aminek felsorolod az elérhető codeceket és a browser okosan kiválasztja az egyik érthetőt. Példul köztük lesz a theora codec is, ami nekem a reménysugár, mert gyűlölök licensz- és patentproblémákkal foglalkozni, azt hiszem jelenleg a firefox támogatja. Nyilván h264 a jelenleg legelterjedtebb ingyenesen használható (legalábbis kliens oldalon még kitudja hány évig) codec ami állítólag de facto standard lesz (rossz hír) bizonyos érdekelt felek nyomására.
A video tag mostanra kb minden browserben működik, a youtube-nak van is html5 teszt oldala.
device tag, és itt lesz a webkamera és a mikrofon. Hát erről kevesebbet sikerült összeszedni, mert egészen új még, működő példát sehol nem találtam, a browser támogatottsága talán még mindig 0.

Szóval ez az egész még (mindig) a holdban van, ha azt vesszük hogy csoda történik és a internet exploiter 10-ben már benne lesz, akkor már csak 2-3 év és valamennyire elterjed a neten.

Addig marad nekünk flash és egyéb pluginok, attól tartok. Titeket nem bosszant ez a tempó?

Egy szoftver három halálos ellensége

2010-12-08T13:46:00.000+01:00

Utálom azokat a postokat, amiknek a címében szám van, de egyszer voltam egy mocsokdrága NLP (ez kb olyan és talán pont ugyanaz mint a scientológia, annyi különbséggel, hogy ufókról nem esett szó) fejtágítón, ahol többek közt ezt tanultam:

Mindent ossz
fel hármas
csoportokra

Ez következik most. Szóval gondolkodtam rajta, hogy mi okozhatja egy szoftverfejlesztési project halálát, és az eddigi szoftverfejlesztéssel töltött kb 10 év után három dolog jutott eszembe különösebb fejtörés nélkül. Jöjjön hát a teljesen szubjektív listám:

Az ügyfél. Tipikusan halálos veszély a projectre nézve egy olyan ügyfél, akinek vagy nincsenek elképzelései a célról, vagy nagyon konkrét és hibás elképzelései vannak. Szerintem a legjobb a kicsit bizonytalan de nagyon együttműködő ügyfél. Na igen, on-site ügyfél.
Az ügyfél anyagi állapota valahogy soha nem volt összefüggésben a project sikerével vagy kudarcával, nyilván én már csak olyanokkal találkozok, akiknek van elég pénzük a projectre.
Kicsit pontosítanom kéne ezt a dolgot azzal kapcsoltaban, hogy az ügyfél egyenlő-e a felhasználóval és személy-e vagy szervezet :)
A management. A management ezer féle halálos veszélyt jelenthet egy szoftver projectre nézve. Nekem tipikusan az jut eszembe, hogy proxy-ként próbál játszani a szoftverfejlesztők és az ügyfél között. Kicsit felesleges szerepnek tűnik, de lehet jól is játszani. Ettől függetlenül az esetek többségében fontos információk elvesztek a fordítás során. A súlyosabb esetekben a management átviteli sebessége lezuhan 0-ra és elvesztessz minden kapcsolatot a project környezetét jelentő ügyféllel. Ez egyáltalán nem ritka eset. Ettől még lehet a fejlesztés sikeres a végén, ha magadtól is kitalálod a helyes utat, illetve ha akármelyik út helyes csak legyen valami.
A másik tipikus hiba a túl beszédes projectmanagement, ebben az esetben annyi meeting-re kell járnia a fejlesztőknek, hogy munkára nem marad idejük. Ez mondjuk a ritkább, de nem elég ritka :-)
Az is nagyon tipikus, hogy a fejlesztőcsapat több része között próbálnak proxy-t játszani. Na, olyat még nem láttam, hogy ez bárkinek is jól menjen. Bár ezen a szinten inkáb a szervezet fejlesztés a priorítás - úgy tűnik így hívják a végülis teljesen öncélú karrierépítést.
A fejlesztők is nagyon veszélyesek, konkrétan a kóderek is lehetnek lámák, de azok a projectek amiket eddig láttam, nem a fejlesztők kezén lettek végleg elcsűrve, hanem általában sokkal elöbb, az architekt kezében. A legsúlyosabb döntések ott születnek. Milyen adatbázist használsz, hogyan történik a kommunikáció a felhasználó (böngésző) és a szerver oldali komponensek között, hogyan lehet ezt az egészet fejleszteni, akár ilyenek is, hogy módosítás és teszt között mennyit kell várni az újratöltésre és mennyit kell kézzel kurblizni rajta... Tipikusan itt következnek be azok a hibák, amikról az előző postban írtam.
Komolyan, egy szoftverfejlesztő csinálhat bugokat, hülyeségeket, láthatsz a képernyőn stack traceket és törött html templateket, segmentation fault-ot, hibás eredményeket, ezek általában pár perc vagy maximum pár nap alatt javítható evidens problémák, amik általában el is múlnak a következő release-ben. Azok a problémák, amik nem múlnak esetleg az egész szoftver életciklus során sem, azok általában mélyebben gyökerező architektúra hibák.

A zárójeles negyedik a UI designer, aki megnehezítheti vagy megkönnyítheti a felhasználó életét HA a project eljut egyáltalán odáig. HA viszont eljut odáig, csodálatos módon a felhasználók a UI design alapján fogják leginkább megitélni a szoftvert. Három okból nem kapott a UI designer külön pontot:

Ritkán okoz tényleges project halált egy hülye UI terv, csak a nagyon nagy közönséget kiszolgáló top weboldalakra, operációs rendszerekre, stb jellemző. Persze attól még nem ritka.
Még nem is láttam olyat, hogy hülye UI ellenére ne vették volna használatba a rendszert egy cégen belül. Szét is lehet nézni a céges rendszerek között, kezdjük mondjuk az SAP-vel. Azokon a projecteken, amiket kapok, sajnos a UI a legkisebb fubar.
Nem fért volna bele 3 pontba

Cowboy Coding Manifesto - chapter two

2010-12-06T21:11:00.000+01:00

A komplexítás nekem nem haverom. Mindenfajta komplexításnak ára van és ha nem ad értéket, akkor kifejezetten rühellem. De még ha értéket ad is, sokkal jobban szeretném azt az akármilyen értéket a lehető legkisebb komplexitással.

Viszont a kód komplexítása szép a teremtője szemében, vagy akinek a nagyságát kifejezi. Konkrétan erre gondolok: Steve Talbott írta a Devices of the soul című könyvében egy olyan délamerikai törzsről, amelyik az 1950-es évekig a világ többi részétől elszigetelten élt. Kicsit agresszív nép, az első néhány évben senki nem élte túl a kapcsolatfelvételt velük, aztán sikerült velük békés kapcsolatot nyitni és "civilizálni" őket. Ez persze hatalmas változásokat hozott a népcsoport életében, például a köpőcsőről átszoktak a puska használatára. A szerző kiemeli, hogy mennyire rossz választás volt ez, ugyanis a puska ezen az éghajlaton hamar rozsdásodik, nehéz és költséges a lőszer beszerzése, a zajával elijeszt minden esetleges zsákmányt és az esőerdőben egyébként se lehet messzebb látni, mint amennyire a köpőcső elvisz. A benszülöttek azzal magyarázták a választásukat, hogy a puskának "olyan szép a hangja".

További ajánlott olvasmány Sean Hastings God Wants You Dead című irása - egyik kedvenc olvasmányom, ajánlom mindenki figyelmébe. Tulajdonképpen memetikáról szól egész bőven, API dokumentáció az emberi agy operációs rendszeréhez. Legálisan is le lehet torrentezni :-) Érdemelne egy magyar fordítást....

Nagyon gyakran fordul elő az, hogy nem a cél lebeg a fejlesztő/architekt szeme elött, hanem az eszköz: egy böszmenagy tankkal akar odamenni. Tökmindegy, hogy hova, de tankkal, egyszerű önkifejezés céljából. Ezt hívják úgy is, hogy a tisztelt engineeringnek elszállt az agya.

Annotation hell

2010-11-28T04:47:00.000+01:00

Gyorsan még az is eszembe jutott, hogy elmagyarázzam, miért gondolom azt, hogy az annotációkkal átestünk a ló túloldalára. Úgyis mindjárt reggel van, már jár a villamos.

A nagy XML konfigurációk helyett csodálatos dolog annotációt használni, amikor úgyis csak az az egy konfiguráció lett volna értelmes. Például JPA és más ORM annotációk. Még soha olyat nem láttam, hogy meggondolod magad és nem jó az a név annak a táblának. Kutyát nem érdekelnek a táblák nevei. Persze konkrétan a JPA lehetőséget ad arra, hogy felülbíráld XML konfigurációval az annotációkat.
Hasonlóan lelkesedek azokért az egyszerűsítésekért, amiket a JSR-181 REST annotációk, a JAXB annotációk ésatöbbi hoztak. Az így felannotált osztályokat és interfaceket az ember tipikusan egy pacakge-be dobálja. Igen, helyenként kicsit cifrán néznek ki az osztály-, metódus- és paraméterannotációk. Sebaj, az XML se lett volna kevesebb.

A másik esetben pont a szétszórtsággal van a probléma. Például a non intrusive IoC-nek pont az volt az előnye, hogy nem összeintegrált komponenseket gyártsunk, elég ha POJO, ennek megfelelően tradícionálisan szét lettek szórva a service osztályok, és nincs is nagyon remény a rendszerezésükre. Szóval ezért nem szeretem az annotált IoC-t, beleértve a spring annotációkat is, és tartok tőle hamarosan a servlet 3.0 annotációival is lesz problémám. Képzeld el így a problémát: átveszel valakitől egy spring annotált projektet, nem a dokumnetációtól működik a szoftver tehát dokumentáció nincs, a fejlesztőtől se várhatsz segítséget. Melyik projectet látod át hamarabb? Szerintem az XML-hell egy-két helyen jobb abból a szempontból ott legalább minden egy helyen van. Nyilván ettől lett hosszú. Attól, hogy szétkentük az XML file tartalmát csillió osztályba, attól nem lett se kevesebb, se átláthatóbb, csak az XML lett rövidebb. Sovány vígasz.

Log

2010-11-28T04:04:00.000+01:00

Ismétlés a tudásnak azannnya. Péntek délután az Egér Miklós Vasművekben beszámolót tartottam a websüketes túrkálásaimról és a servlet 3.0-ról. Nem sok új ahhoz képest amit már egyébként itt is leírtam pár postban és ott is elmondtam:

A Servlet 3.0 zseniális lépés a java szerver oldali technológiában. Na jó ez kicsit túlzás, de végre egy nagyon lényeges újdonság, ami komolyan növeli a java szerverek teherbírását azáltal, hogy egy hosszú és esetleg nem igazán CPU igényes kiszolgálásnak nem kell feltétlenül külön szálat fentartani. Adatbázis műveletek, JMS üzenetre várakozás, de például akár várakozás más erőforrásokra is, pl gondolom nem igazán szeretnél szerver oldalon párhuzamosan 10 db jóminőségű hubble űrteleszkóp képet feldolgozni kicsi heap memóriával. Ugye...
A Servlet 3.0 kifejezetten olyan dolgokra nagyon alkalmas, mint a long poll. Amit ugyebár a szerver push-kén használunk.
A Websocket API, ami már ott van a firefox 4-ben, chrome 7, IE 9 (jajj hát ki legyen mindig a legutolsó) satöbbi, szóval ez az API lehetővé teszi, hogy TCP socket-szerű tartós kapcsolatot építsünk fel a kliens és a http szerver között.
A Websocket API ha egyszer elterjed, komoly átalakítsok vállnak kézenfekvővé a szoftverfejlesztésben. Szerintem a legtöbb esetben maradnak a régi ajax hívások is, de jópár esetben a websocket le fogja helyettesíteni. A long poll biztos hogy menni fog.
Ennél vlószinűleg lényegesebb kihívásokkal kell az üzemeltetés terén szembenézni. A Websocket ugyebár HTTP 101 "Switching Protocol" státusszal kezdődik és innentől az egész kommunikáció nagyon más, mint egy szokásos HTTP kapcsolat során. Kell számítani nehézségekre a proxykon, load ballancereken, stb. Azóta kipróbáltam, hogy apache mod_proxy korrekten kezeli-e ezt a protokolt, de nem ment vele. Aztán lehet az apacs mágusok életre tudják kelteni, de nekem nem ment. Még ki kell próbálnom mod_ajp-vel is, valamiért én inkáb azt használom ha muszáj, nekem az egyszerűbb.
Viszont a másik kérdés: akarunk apacsot az egész elé? Amikor az kapcsolatonként 1 processzt de legalábbis egy szálat visz, míg a java szerver oldalon már nincs erre szükségünk? Lehet a httpd bottleneck lesz az architektúrában? Illetve most még nem az?
Még mindig kérdés, hogy szükség lesz-e a websocket témogatásához valami külön servlet engine kiegészítéshez, vagy belefér-e a sima servlet API-ba. Szerintem kifejezetten jobb lenne, ha a servlet API fürgén előjönne valami támogatással, én mindenesetre a jetty saját apiját használom. Ebből következőleg a kód nem fut pl tomcaten.
Ilyen módon mire tényleg használatba vesszük a Servlet 3.0 API-t, talán már nem is lesz rá szükségünk sokáig. Ugyanakkor az, hogy nem tartunk külön szálat minden kliens kapcsolatnak, még inkáb fontos lesz ha majd egyszer Websocket klienseket szolgálunk ki.
Ezzel kapcsolatban kicsit szorgoskodtam és dolgozok még mindig egy olyan prototipuson, ami a kliens elől eltakarja hogy long-pollt vagy websocket-et használ. Ennek egy működőképes változata itten-e van. Próbáljátok ki: svn co után mvn jetty:run. Ez a prototipus egyébként egy kicsit elvetemültebb koncepció és télleg csak kisérleti jellegű. Ha egyszer megnő, akkor meg fog érdemelni egy magyarázatot itt, addig még kalapálom és dumálunk róla.

Szóval mindez még nagyon messze van az éles bevetéstől.

Sonar eclipse plugin (FYI)

2010-11-17T18:10:00.000+01:00

András hívta fel a figyelmem erre a pluginra, igazi frankó cucc :-) Amúgy nem szeretem pluginekkel telezsúfolni az eclipse-t, stabilabb biztosan nem lesz tőle, de ez egy értelmes ötlet: ahol hegesztek, ott nézhetem a hegesztés minőségét is és javíthatok rajta.

Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.

Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...

retró

2010-10-29T10:54:00.000+02:00

Arra még emlékeztek, hogy valamikor régen CD-n és DVD-n terjesztettek szoftvereket? Pár levitézlett harcost bemutatnék a képről: IBM DB2 és Websphere, Rational, SAP gányolmány nagy mennyiségekben (hogy szerettem a német rövidítéseket az abapban...), Novell féle suse, Sun One appszerver (6 CD!!!) A kupca alján van valahol pár Oracle motyó is, tudom hogy valahol van benne Sybase is. Na meg a hardware-k kidobált windowsos driver CD-i. A microsoft termékek hiányoznak totál szőröstül bőröstül, mert azt itthon nem használok.

Szakmai önéletrajz helyett, mondjuk úgy 5-6 évvel ezelöttig :-)

ws://

2010-10-28T11:03:00.000+02:00

A héten kerítettem időt magamnak egy pár prototipus fejlesztésre és kifejezetten érdekelt a html5 (ezzel kapcsolatban szólt ki ugye nemrég a w3c-s csákó, hogy még sehol sem production quality, ezt egyébként tapasztaltam is) websocket. Amit összetúrtam, az tényleg csak a prototipus építés összegzése, ne vegyétek valami szakértői véleménynek :-)
Szóval nézzük mi ez az egész...

A hiper-szuper interaktív szines-szagos weblapok fejlesztésénél a jó öreg request-response megoldás már nem nyerő. A websocket tulajdonképpen egy socket szerű dolog. Küldözgethetsz rajta mindkét irányba üzeneteket, ahogy tetszik. Azt a problémát akarja megoldani, mint az adobe RTMP nevű szőrös gorillája. Konkrétan az is tud utazni http felett, de hát ezt a dolgot jobb nem eröltetni, ugyanis mocskosul lassú.

Nos hogy a rákba fér bele a socket-szerű működés a http protokolba? Nem egyszerűen. Eredetileg úgy volt, hogy a ws protokol nem a 80-as porton fog utazni, hanem 81-es. Aztán ezt az ötletet elvetették, rettegve a firewalloktól és a proxyktól, most ott tart az ötlet - és úgy tűnik ezen már nem változtatnak - hogy ez is a 80-as porton fog utazni. A wikipédia cikk tök jól leírja, hogy fog ez működni. Nem is tudom használták-e valamire idáig a http 101 státusz kódot.

Browser háború

A wikipédia cikk a mainstream broesereket is felsorolja, csak annyit jegyeznék meg ezzel kapcsolatban, hogy jelenleg a chromium az egyetlen browser, ami kint van mainstream elérhető több oprendszerre web socket támogatással. Annak mennyi a piaci részesedése? Nem sok. A Internet exploiter 9 tartalmaz majd websocket támogatást, ez jelenleg testdrive.
Szóval erről az oldaláról a dolog szerintem jelenleg nem bevethető állapotú.

Szerver háború

Aki a szerver oldalt akarja bütykülni, annak se lesz egyszerű dolga még egy jó ideig, a java servlet ugyanis semmi támogatást nem ad az egészhez. Két dolgot találtam a weben, amit fel lehet használni:

jwebsocket hát vele az a baj, hogy a protokolt implementálja kivállóan, csak nem fér rá a http portra mellé. Szóval muszáj neki alternatív portot meghatározni. Nem tudom mekkora gubanc a firewallok használata ebből a szempontból, pl már dolgoztam olyan helyen, ahol nem engedték ki az ismeretlen protokolokat. Pl ssh-val se lehetett kimenni. Hájli szikjúr... volt, amíg fel nem találták a pendrive-ot.
A jetty-s srácok csináltak egy nagyon szép kis apit a websocket kezelésére. És még ráadásul működik is, csodaszép és egyszerű. Egy baja van: totál jetty specifikus. Szóval hozzáberhelted az alkalmazásod a jetty containerhez. Amíg ki nem jön valami spec, addig jóban rosszban együt.

Etc háború

Hát az egészet azért bonyolították meg, hogy mehessen a 80-as porton. És megy is, de hogy ez mennyire van tesztelve az infrastruktúra többi részén... ilyenekre gondolok:

proxyk kifejezetten
http load ballancerek
firewall-ok

Szóval hogy ez mind boldog lesz vajon? Annyi már most biztosnak tűnik, hogy a servlet 3.0-nál is jobban át kell majd rendezni az architektúrát.

Kérdések

Ha egyszer ez végre teljesen oké lesz és működik, akkor vajon

Volt-e értelme a servlet 3.0-nak? :) Mert akkor csak úgy áttolnánk minden lassú interakciót websocketen, majd szól a szerver ha kész. (mondjuk a servlet 3.0 már itt van, a websocket meg mint kiderült még sehol)
Ez az ajax hívások túlnyomó részét át fogja venni? Amit cachelünk, azt gondolom jobb lesz mégis a régi módszerrel küldeni.
Nyugdíjba megy az ajax push? Nem fog hiányozni! :-)
Például a socketek kiszolgálását hogyan lehet majd loadballancelni? Egész végig 1 ugyanaz a szerver fogja kiszolgálni a socketet?

Hát ennyit túrtam fel, azt hiszem most még kicsit rugdosom de hagyom érni még egy ideig. Azért ennek a technológiának a bevetéséhez igen alaposan át kell majd forgatnunk pár dolgot, egy ideig attól tartok el fog tartani, és még sehol sem tartunk vele.

Az indiánok üldöztetése

2010-10-19T00:20:00.005+02:00

Egyik nap apache benchmarkkal méregettem az egyik webappom válaszidejét és terhelhetőségét és hát nem voltam igazán boldog. Gondoltam, hogy már nem sok mindent lehet húzni rajta, sima adatbázis cókmókot pakol bele xml-be oszt jónapot, az egész architektúra a dögunalomig menően szokványos.

A tuningolás egyébként izgalmas téma, ezer dologgal lehet húzni egy ilyen rendszert, adatbázis optimalizálás, cache réteg kidolgozása, a DAO réteg optimalizálása, profile-olás, garbage collector tuningolás, memóriaparaméterezés, jdbc connection pool buhera, threadpool buhera... és mindezen már túl voltam és az egész még mindig nem muzsikált úgy ahogy nekem tetszik. Azért éreztem nyekergésnek az egészet, mert ugyanezen a vason lemértem hogy a default apache installáció statikus html tartalommal mit tud kezdeni. Rendesen odacsűrt a procinak, de 5000 req/sec körül teljesített. Ez nyilván egy unfair összehasonlítás, mert az apacsnak semmi mást nem kellett csinálnia, csak kipumpálnia egy file-t a tcp socketen. Ez adta az ötletet, hogy ha az én rendszeremnek csak ennyit kellene csinálnia, akkor megcsíphetné az apacs tempóját.

És ezt a receptet főztem ki:

Végy egy filtert. Nevezd el ResponseCacheFilternek
Végy egy JCache (ez az oldal kiválló példája egy halott JCR-nek) implementációt, de ha nincs vagy bizonytalan vagy, jó lesz egy HashMap is, lehetőleg legalább az adatokat Ref-fel csomagold hogy OOM-et azért mégse okozzon
Fogd meg a HttpServletResponse-t és gondosan tekerd be egy HttpServletResponseWrapper-be. Itt van néhány trükk amit csinálni kell, de a lényeg hogy írj egy olyan ServletOutputStream-et, ami hasonlóan a apache commons io TeeOutputStream-jéhez (esetleg építhetsz is erre az osztályra) másolatot készít a kiírt adatból. Szerintem célszerű egy ByteArrayOutputStream-et használni ha az eredmény nem véresen nagy. Esetleg csinálhatsz köré egy limitált verziót, ami egy limit után már nem ír (mint pl a CountingInputstream)
A filtered egyszerűen csak dobja tovább a végrehajtást az adatbázisba matató kódnak, ami majd mégtovább dobja az adatbázisból kiberhelt adatokat kiszerializáló kódnak, satöbbi. A végén valahogy a vezérlés visszakerül a filterhez.
No ekkor kapjuk el a HttpServletResponseWrapperünk grabancát és követeljük tőle servlet output stream-re kiírt adatok másolatát, ez egy plain byte tömb ha minden igaz. Egyszerűen csak csináljunk egy kulcsot a request paramétereiből, és az értékként használva a response másolatát dobjuk be a cache-be
A következő requestek beérkezésekor a requestből összebütykölt kulccsal megnézheted, hogy van-e cachelt válasz, ha nincs lásd fenti pontok, ha pedig van, akkor boldogság, mert csak egy byte tömböt kell kidobnod.
Ezt a filtert applikáld rá a tipikusan csakis olvasást végző műveleteidre. Pl getCustomer, getLatestPosts, stb.
Lesz még itt bonyolítás: a módosítást végző kód kell hogy kérni tudja a fenti response cache egyes elemeinek kiürítését. Ide clusteres esetben szerintem egy jms topicon érdemes körbeküldeni egy ID-t vagy hasonlót, ha nincs igény culsterezésre, elég csak direktben törölgetni kulcsokat a cache-ből. (erre is lehet kultúráltnak látszó kódot írni, akármilyen bunkón is hangzik)
Kész! Elő a benchmark eszközzel!

Csak ennyivel még nem sikerült megszorongatni az apacsot, bár a teljesítmény igen látványosan megnőtt, de még most jön egy desszert.

A browserek (söt talán már az internet explorer is) képesek tömörített tartalmat kezelni. Az "Accept-Encoding" headerben küldik meg, hogy ők mit fogadnak el. Na ezt ki lehet használni. Általában azt szokták mondani, hogy hülye dolog generált tartalmat is gzippelni, mert sok időt visz. Talán így van, de ha csak egyszer generáljuk a tartalmat, és az eredményt becacheljük, akkor onnantól már nem kell újra és újra gzipelnünk a generált tartalmat. Ez lényegesen csökkenti a hálózati forgalmat. Egy gzippelt response törtrésze az eredeti tartalomnak. Példaként a jól ismert JQuery minified 76 K gzippelve csak 26 K. Ez most egy rossz példa volt, mert az alig a harmada, de az én teszt kimeneteim harmincadukra estek össze és ez tényleg sokat dobott rajta.

Ez az egész csak akkor hatásos, ha az alkalmazás az olvasások számához képest ritkán módisítja a kimenetet ÉS a pillanatnyi pontos állapot nem fontosabb, mint a jó válaszidő. A legtöbb webapp tipikusan ilyen szerintem. Az internet ilyen. Egy bank esetében atomkatasztrófával érne fel, de speciel egy blogger cikk esetében nem nagyon érdekel senkit sem, hogy publish után még akár fél másodpercig is a régi tartalom jelenik meg másoknak.

Itt most egy kicsit kénytelen vagyok ködösíteni, mert mégiscsak a konkrét alkalmazáson múlik, de a cucc teljesítménye így vetekedhet, söt verheti is az apache statikus oldalak sebességét -ami mégegyszer nagyon unfair összehasonlítás, hiszen az apacsot nem tuningoltuk és esetleg csinál egy rakás egyebet amit a jetty vagy tomcat nem, és fordítva.

A válaszidőkről még annyit, hogy amikor egy-egy kulcs (vagy egyszerre több is) kiesik a cache-ből TTL, GC vagy a fenti kódolt mechanizmus által, újra a régi és lényegesen lassabbnak mért kódunk lép működésbe és ilyenkor amíg a cache-ben meg nem jelenik újra az eredmény esetleg több kérés is a háttérlogika végrehajtásához kezd, ami például tökönrúgja az adatbázist. Egy mérésben ez meg is fog látszani, tipikus bemélyedések szabályos időközönként.

Már erre is volt megoldásom egyébként, csak még nem építettem bele ebbe a response cache megoldásba, nagyjáből annyi, hogy háttérszálon is frissítheted az eredményt, ha nem borzasztó sürgős és kritikus fontosságú mindig pontos eredményt adni, és addig visszaadhatod a régi eredményt. Persze ha a cache-d nem dobja ki a régi eredményt. Szóval ez egy kicsit gubancosabb történet, de végig lehet járni ha valaki ki akarja kalapálni a csorbákat a performace görbéjén.

Na ennyi, remélem valamennyire tanulságos volt. A francba kedd lett közben, akkor jöjjön még egy ilyen a teljesítmény tuningoláshoz:

Egyik nap azt találom ki

Hogy másnap százon én nyerek

És nő hegyek vesznek körül

De én nem szeretek egyet se

Még párszor győzök

De már csak megszokásból

JaSON is EVAL...

2010-10-13T09:56:00.000+02:00

Tegnap próbálgattam JQuery 1.4-gyel meghívni egy kézzel hímzett JSON-t gyártó ajax backendet és nagyon furcsa eredményeket kaptam. Egész pontosan a callback metódus nem került meghívásra, és pedig azért, mert nem tudta felparsoloni a json kimenetet. Néztük ketten is, hogy hol lehet a gubanc a kimenetben, és mint kiderült az idézőjelekkel volt a baj. Egyszeres idézőjel nem jó, dupla idézőjel jó.

A dolog egyébként azért volt meglepetés, mert nyilván erre a kézzel hímzett json kimenetre is írtunk validációt és a jávás json parser átengedte simán, mint ahogy a JQuery 1.3 is. Nekem kicsit a régi CORBA idők jutottak eszembe róla. Bár a probléma gyökere más, ami a felszinen van, az mégiscsak rémesen hasonlít :-(

egy üzenet magamnak

2010-09-23T21:29:00.000+02:00

Gyónás következik... Kicsit nehéz volt elmagyaráznom az operátoroknak is és végülis szerintem csak félig lett a vége megértés és a másik felében inkább napirendre térés, de mostanában számos JMS queue ütötte fel a fejét, aminek mindkét végén ugynanaz a webapp áll. JMS-t egyébént arra használja az ember, hogy más szolgáltatásokhoz üzeneteket küldjön és nem mellesleg biztos akar abban lenni hogy nem is alkalmatlankodik a kéréssel és egyszer ki is lesz szolgálva. Nos nekem ilyen nem áll rendelkezésre, nekem sima SOAP és egyéb http backendek vannak. Szóval amikor a webappom kiveszi a kérést a JMS-ből, akkor egy SOAP hívást küld tovább. Ha nem sikerült (pl network outage, server crash valahol, konfigurációs gubancok, satöbbi), akkor bátran és nagy magabiztossággal eldobom az exceptiont a message meg mehet a dead letter queue-ba vagy konfigtól függően újra besorolásra, legközelebb hátha több szerencséje lesz.

Szóval ez nekem olyan eccerű megoldásnak tűnik, JMS-SOAP bridge. Nem lesz ez mindig muszáj, már úton van a CXF-ben is a soap-over-jms cucc, más web service stackokban már talán ott is van.

Csak ennyit akartam mondani, köszönöm a figyelmet.

Servlet 3.0 első kör

2010-08-28T10:45:00.005+02:00

Nagyon érdekelt a servlet 3.0 és közismerten türelmetlen tipus vagyok, letéptem hát a legfrissebb specifikációt és kipróbáltam rajta pár dolgot. A kipróbált implementációk:

Jetty 8
glassfish 3.0
tomcat 7

Hát eléggé fej-fej mellett voltak, úgy tünt kb mind ugyanaddig jutott el. A kisérletsorozatnak nem sikerült kizökkentenie a jetty-pártiságomból. Továbbra is a jetty volt a fejlesztés során a legkönyebben használható. A 8-as verzióhoz is van maven plugin. Pedig próbálgattam a glassfish 3 embedded pluginjét, igazából pozitív meglepetés volt, de hot deployt nem csinált. Szóval minden eltévedésem után újra kellett startolni és packagelni. A tomcat 7.0 az meg maradt a maga kis bemásolom és újraindítom megoldással. Magad uram ha integrációd nincsen.

Servlet annotációk

Iiiigen... aki velem dolgozik, az tudja mennyire nem komállom azt, hogy mindent annotálunk. Az XML HELL sem volt jó, de most elmentünk egy még rosszabb irányba. XML konfigurációkkal még megvolt az esélye annak, hogy áttekinthető marad. Mindenesetre gyors prototype alkalmazásokat az ember biztosan szivesebben tol össze úgy, hogy csak ráannotál a szervletére. Működött is mindenhol.

Azt soha nem értettem egyébként hogy a servlet ikonja az mi akart lenni. Valami ősi dolog lehet a Delphis és Progress-es időkből.

Opcionális búcsú a web.xml-től

Hát igen, ha nincs benne semmi érdekes, akkor le is törölhetjük és a dolog megy nélküle is. Persze ha már egy adatbázis kapcsolat kellene a la JNDI (ami végülis egy hasznos dolog), akkor vissza is jön egyből. Oké, szóval marad, adatbázisa kb mindenkinek van és az operátorok akarják babrálni. (Vajon miért pont azt az egy resource-ot? Az összes többivel miért nem foglalkoznak?)

Asynchron servlet support

Ez talán a legűberebb dolog mióta gyáva programózó vagyok, de az utóbbi 5 évben biztosan a legfontosabb dolog számomra. Nagyon egyszerő, ez történik: amikor úgy véled, hogy sokáig tartó művelet közeledik (pl vársz egy JMS üzenetre) egyszerűen azt mondod, hogy ez a request innentől asszinkron fog kiszolgálódni. Így:

req.startAsync();

Ezután elkérheted a requesthez tartozó AsyncContext ojjektumot

AsyncContext asyncContext = req.getAsyncContext();

Ezt akár bedobhatod egy másik szál által kezelt listába, ahol a lassú műveletre váró összes többi kliens várakozik. Az az egy szál le fogja tudni kezelni minden requestedet. Például valahogy így

asyncContext.getResponse().getWriter().write("gedappa!\n");

Eddig csúcs :) Na akkor most jön a gubanc. Azt is biztosan szeretnénk tudni, hogy mikor kellene ezt a AsyncContext objektumot kidobnunk a listából. Erre tök jó lett volna az AsyncListener osztály. Ami meg is van, kiválló. Példányosul is szépen az implementáció, még mindig oké, de aztán NoSuchMethodError amikor regisztrálni próbáltam, mind a 3 servlet containerben. Ez vagy valami kis lemaradás a specifikációhoz képest, vagy valami szokásos sünös-orákulumos gányolmány.

Elfelejtettem azzal kezdeni, hogy ennek mi értelme van. Talán már kiderült a fentiekből: megszabadulunk az millió kiszolgáló száltól, maradnak csak simán a TCP kapcsolatok. A NIO után végre a következő lépés.

Pár dolgot biztosan érdemes a async kedvéért átgondolni az üzemeltetésben is: például sokan használnak apache httpd-t a servlet container elött, mert példul még php és perl meg egyéb ingyombingyomokat is ezzel a szerverrel hajtanak. A httpd régebben single process per connection cucc volt, most már lehet külön szálakat is használni, de vicces hogy ott álnak majd a szálak, amig a java VM-ben megoldottuk hogy ne kelljen állniuk. Nekem nagyon gyanús, hogy ilyen esetekben sokkal érdemesebb lesz kihozni a servlet containert a httpd mögül. (és persze van, aki azt kérdezi: mit keresett ott addig, ha csak a java elött állt? kiválló kérdés...)

Hát ennyit akartam elmondani már jórég óta, csak mindig belémfolytották a szót. Egyébként komolyan gondolom, hogy ezt a lépést a java világ legnagyobb előrelépésének tartom az utóbbi 4-5 évre. Mondjuk nem kis lépés, de azért szivesen látnék nagyobb lépéseket is.

nyáriszünet

2010-07-23T13:51:00.003+02:00

Igen, nagyon meleg van, körülbelül ennyivel tudom magyarázni az elmúlt pár hónap inaktivítását. Kéktúrán voltam, néha egész hétvégén cuppogott és csámcsogott a cipőm a sárban, néha inkább forró mediterrán hangulatba hajlott, de végigcsináltam. Melóztam is elég sokat sajnos mindenki rámtolt mindenfélét és már nem csak fejlesztő vagyok hanem adminisztrátor is. Nem ideális, nagyon lefárasztanak, néha nem is marad időm haladni a fejlesztéssel. Holnap reggel elhúzok egy kicsit a tesóimmal tölteni az időt. Ők is le fognak fárasztani :)

Szóval ennek megfelelően lassan, de készül a todomap 0.6.0, és egy nagy rakás dolog már most is benne van. A héten akartam kitenni, de így nyaralás elött inkáb mégsem kapkodnék. Szóval ezek jönnek:

Van szabadszavas keresés. Elég bénácska, még valami szebb dizájn kellene neki :( A kinézettel mindig szívok.
Van integráció. A polgármesterek jobbára friss listáját használva üti a helyi hatóságokat. Még ki kellene őket listázni szépen a megfelelő oldalon.
Le lehet zárni a bugokat.
Pár új apróság, például egy térkép azokkala gebaszokkal, amiket te jelöltél be, saját RSS feedek. Ide még kell, hogy felhasználóknak is használhatóvá tegyem.

Szóval ez jön. Augusztus. A hőmérséklet lassan ismét csökkenni fog, a produktivítás fordított arányban nőni kezd.

Cowboy Coding Manifesto

2010-07-01T12:30:00.005+02:00

Annak ellenére hogy már másfél éve egyedül dolgozok (ami elég unalmas) és emiatt a scrum metodikát -vagy legalábbis jó részét- a sutba dobtam, a munkaadóm elküldött egy scrum trainingre. Azért nem volt tejesen haszontalan, nem írnék most róla részletes beszámolót, csak pár dolgot gondoltam vele kapcsolatban:

Kell-e egy scrum csapatnak dokumentálnia? - Erre nekem az lenne a válaszom, hogy HA a ügyfél kéri és csak azt amit kért. Amit senki sem fog elolvasni az ugyebár "waste". Például az OpenSSO-val hogy hogyan integrálódik a webalkalmazásom, nem hiszem hogy bárki elolvasná amit erről írok, de ha egy fejlesztő belenéz a kódba, szerintem értené (nagyon remélem :) ). Mindenki más állította hogy egy feladat akkor kész, ha dokumentálva van. Én ezt kivenném a kész definíciójából. A user doksin kívül egy ilyen feladathoz nem nagyon kell doko. Architektúra doko? Egy ennyire plain webapphoz?
Mondjuk azt meg is beszéltük, hogy ha nem adottak a feltételek (mint esetemben) akkor kár is erőltetni a scrumot. Szóval ennyiben maradtunk.
Egy processz nem hoz tavaszt. Az emberek visszazökkennek a megszokott munkatempójukhoz. Mondjuk ezért kell egy dedikált scrum master, de hát kinek van erre pénze?
Azért ahhoz bátorság kell, hogy idomítsd a munkaadód magas beosztású képviselőit. Pedig erre szükség van.
A scrum egy elég szigorú process és a training után már nem tartom annyira minimalistának. Szerintem ez már kicsit ellentétben áll az agile kiáltvány első pontjával.

JUM XV log

2010-06-04T12:48:00.003+02:00

Tegnap esti Java felhasználók találkozója. A democamphez hasonlóan viszonylag kevesen voltunk, erre az eseményre viszont sajnálhatja aki nem jött el, nekem nagyon tetszett a két előadás. Mindkét előadást szakmai bloggerek tartották, nekem is itt vannak a google reader végén.

Kovács Richárd: btrace

A btrace egy trace eszköz, olyan mint a dtrace solarison (ez a legtöbb embernek azért nem mond sokat, nem egy mainstream oprendszer még a szervereken sem). Egyszerű kis scripteket lehet rá írni annotációkkal és nagyon kevés kóddal, ami a hotspot vm-hez kapcsolódik és bizonyos esetekben meghívódik. Például csinálhasz egy scriptet, ami a DriverManager.getConnection() metódusra ráakaszkodik. Tipikusan olyan komponensek tuningolásánál jól jöhet, amik nem logolnak és nem mi írtuk. Őszintén szólva tegnap került csak a látőterembe a cucc és most már nem tudom hogy élhettem eddig nélküle :)

Marhefka István: Domain Driven Development

István egy hosszabb előadást tartott a Domain Driven Developmentről, ami egy nagyon elméleti téma de nagyon sok gyakorlati tapasztalat is volt benne. A DTO pattern körül a végén sok kérdés volt, azt hiszem az említett fintorgók tábora nagy számban volt jelen. Én csak akkor szoktam bevetni, ha már nincs más választásom.

Egyébként nem is tudtam hogy van még a munkaadómon kívül teamcity felhasználó itthon. Elég borsos ára van :-)

Ez volt most az időny utolsó jum-ja, szeptemberig szünetelünk és akkor újjult lendülettel :)

Eclipse Democamp 2010 Budapest

2010-06-02T23:26:00.004+02:00

Immár szokásosnak mondható éves eclipse democamp a b2international szervezésében. Kis újításként 15 perces előadások vannak, viszont több. Nekem tetszik ez a műfaj. A felratkozott 43 főnél némileg kevesebben lehettünk, szerintem úgy 30 fő lehetett jelen. Mindenki unja az esőt. Szóval annak, aki lemardt...

Nekem kifejezetten tetszett Nagy Gergely Pythonos előadása, aminek csak a kisebb részét szánta a pydev bemutatására, inkáb a python csodálatos képességeit mutatta be, ami perlhez hasonlatos write-only nyelvvé képes tenni.

Aztán Török Zsolt Eclipse Communication Framework-ös demója is érdekes volt. Én jobban szeretem nem teletömni pluginokkal az eclipse-t és csak a szükséges minimummal beérni. Volt régebben egy érdekes demó arról, hogy hogyan lehet egyszerre ketten dolgozni egy editoron ECF segítrségével. Na az konkrétan nagyon jó volt.

Oláh Bence: Developing GWT application using Eclipse IDE. Live demóval fűszerezett prezentáció. Valami forráskód formázáson emélkszem hogy 4-5 percre fentakadtunk. Hát igen, a sok anon inner class nem teszi mindig olvashatóbbá a kódot, főleg ha az anon inner classban van egy anon inner class.

Még az XText-et kiszúrtam, mint lehetséges érdeklődésem tárgyát, de alaposan utánna kell néznem a neten.

ingyen spamblockerek versenye

2010-06-02T00:34:00.003+02:00

Összedobtam egy nem túl fair ls tudománytalan tesztet, ami 3 publikus és ingyenes comment-spam szűrő szolgáltatást hasonlít össze a google címemre érkező spam segítségével.

Tessék hát...


[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.todomap.spamegg.AkismetSpamFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:230
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 282.074 sec
[INFO] Running org.todomap.spamegg.TypePadFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:213
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 313.741 sec
[INFO] Running org.todomap.spamegg.LinkSleeveSpamFilterTest
[INFO] Total messages:354
[INFO] gmail spam considered ham:0
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 196.878 sec

Szóval röviden összefoglalva az eredményt a linksleeve nemcsak a leggyorsabb, de a leghatékonyabb is. Elég gyanúsan lógott ki a sorból, ezért teszteltem kézzel beírt adatokra is, azokat nem szűrte ki. Szóval furcsa, de tényleg jónak tűnik. Az akismet és a typepad ugyanazt a interface-t használa, lehet hogy valami számukra nagyon fontos adatot nem postolok el, amitől javulna a teljesítményük.

névadási és verziózási hagyományok

2010-05-19T09:36:00.002+02:00

Egy érthető névadási és verziózási szabályrendszer szerintem nagyon nagy szerepet játszik egy technológia használhatóságában. Néhány eset...

Az egykori SÜN! Microsystems termékei minden kanyarban más nevet kaptak. Az első javás történet maga a java verziói és nevei. A java 1.2-t elnevezték java 2-nek és átnevezték j2se-nek, de aztán senki sem hívta 2.0-nak és a 1.3-at és 1.4-et kiadták a régi konvencióval, míg a név megmaradt j2se és j2ee, majd a java 5.0 jött és a j2se-bé eltönt végre a "2", de ezt azért zárójelben 1.5-nek hívtuk és ugyanez igaz az 1.6-ra is. Vajon hogy lesz ez a 1.7-tel, az oracle marketingesei mit szeretnének? És vajon mi lesz akkor, ha egyszer tényleg akkora dolgot csinálnak a java nyelven (bár ennek valószinűsége most már igen alacsony) ami nem férne bele az 1.x-be? Pl kompatibilitás törés és szakítás régi paradigmákkal...

A Sun más termékeinek névadási stílisa néha még ennél is cifrább, például a mai Metro web services stack legalább 3 másik néven volt már fejlesztve. A glassfish is valami minden verzió után más nevű termékből származik ha jól emlékszem. Tök jó, hogy most már 3 verzió óta ugyanúgy hívják.

Néha a saját verziózási és névadási konvencióim se túl egyszerűek. Csomagot átnevezni nem szoktam, de néha olyan neveket adok, amit nem hiszem hogy egyszerű lenne kitalálni. Például a todomap.org-ot egy o29 nevű szoftver hajtja. Azt hiszem jár egy sör a helyes megfejtőnek :-) Más csomagok neve kicsit érthetőbb, pl spameggspam nyilván spam szűrő.

Viszont soha egyetlen egyszer nem neveztem egy szoftveremet 1.0-nak. Három decimális verzió, az első a 0.0.1, így van elég helyem :)

Még a verziókról jut eszembe az a munkatárs (aki hála jehovának nem magyar és ezt soha nem fogja elolvasni) aki szerint a maven SNAPSHOT verziói egy gusztustalan gány. Soha nem használ snapshotokat. Ennek következtében a fejlesztési verziói a végleges verziószámmal "floating around the network", és mindben más van. Ezért egyébként a neki dedikált build agenteken egy időben meg kellett osztani a maven filerendszerét a gépek között. Húúúhhh....
Csak magyarázatként ant júzereknek: a maven a snapshot verziókat időnként felfrissíti (lásd maven paraméterek és settings.xml), míg a nem snapshot verziókat ha egyszer leszedte, örökre ott is marad.

Gyanús dolog az is, amikor az első publikus verzió arra enged következtetni, hogy nem ő az első. Például hogy 2.0-ként adják ki. Ez teljesen igaz arra a szoftverre, amit munkában fejlesztek. Eléggé összetákolt dolog, párszor beszakadt, úgyhogy eldöntöttük hogy from scratch újra. Már egy ideje dolgoztam rajta, amikor mondták hogy ez lesz akkor a BLF 2.0. Mondom BLF 2.0 nem lehet, az fut most a live rendszeren. De akkor már késő volt és most ott járunk hogy két ugyanolyan nevű és verzió számú, de totálisan más kinézetű és funkcionalítású rendszert fejlesztünk. Egy csomó extra munka nekem az, hogy a felhasználóknak elmagyarázzam hogy mi micsoda, ezzel például kivállóan lábon lövöm magam.

Szóval összegzésként csak ennyit szeretnék mondani: marketingesek, politikusok, humoristák, el a kezekkel a szoftveripartól!

Todomap 0.5.15

2010-04-14T22:47:00.006+02:00

Hali, boldog szerdát!

Sok sok újítással kikerült a szerverre a todomap 0.5.15. Gondolkodtam rajta, hogy ne legyen inkáb 0.6, de lusta voltam. Szóval újdonságok:

Összehúzott design. A régiben böszme nagy volt minden. Összehúztam az ablakok fejlécét, a tabokat és az accordionokat (akárhogy is hívják őket magyarul) Hogy tetszik?
Immár a negyedik, és remélem az utolsó tooltip megoldás került be. Nem össze vissza mindenfelé jelenik meg, hanem adott helye van. A térképen babrálás közben bosszantó volt. Ez a tooltip megoldás lehetne az ugródeszka a segítséghez, lenne benne pár link bővebb leírásokhoz.
Búcsú a jobbklikktől! Mostantól nem jobbklikkel lehet gubancot felírni, hanem van rá gomb. Ha megnyomod, az egér mutató célkereszt lesz, egész addig amig meg nem határoztad a gubanc helyét.
Bemutatkozó ablak, csak hogy tudd hogy mi ez és téged miért érdekelhet. Az első látogatásod alkalmával fogod látni, aztán csak ha megkeresed.
Diagramok: egyelőre csak a beágyazott anon szavazáshoz van, de ha kattintassz, kapod a grafikont. Kattints bátran :)
Egy nagy belső rendrakás a rendszerintegrációhoz. Igen, ezzel le vagyok maradva mint a borravaló, de meglesz és szép lesz, tényleg :)
Pár belső nagyon technikai dolog: sitemap a robotoknak és ilyesmi

Todomap 0.5.14

2010-03-30T22:15:00.005+02:00

Sok tökölés után tessék: todomap 0.5.14 Azért tartott el ennyi ideig, mert letéptem a dizájnt a részletes leírásról és nagyon puritán lett az egész. És hát ég a pofám miatta :-D

No lényegesebb újítások:

Anon szavazás - külön számolva a rendes felhasználóktól, akik bejelentkeznek...
Más weboldalakra beágyazható anon szavazódoboz. Így néz ki épp pillanatnyilag (szóval ez nem képernyőlövés, hanem maga a cucc és aki buzz-ban vagy google reader-ben nézi az nem lát belőle semmit):
A részletes információk többé nem feltétlenül új böngésző ablakon jelennek meg (ami idegesítő), hanem belső ablakon. Persze a régi módszer is elérhető, ehhez a kis link ikonra kell kattintani.

JUM_XIV.log

2010-03-18T09:30:00.003+01:00

Érdekes JUM volt tegnap este, de sajnos webkamera és hangrögzítés nem volt, így aki nem jött, az be kell érje a prezentációkkal.

Fazekas Imre kedte a Brillien rendszerrel. Érdekes alapötletei vannak és az már most látszik hogy legalább akkora gondolkozásbeli változás kell hozzá, mint a scala-hoz :-) Érdekes, ebbe bele fogok olvasni. Brillien doksi -> ebook reader. (még a scala könyvek is olvasásra várnak sajnos)

Szünet után rövid Todomap. Hááááttt... rá kellett jönnöm, hogy teljesen tökéletesen mindegy mennyit készülök, úgyis teljesen más sorrendben és felépítésben fogom kiszerializálni amikor kell. Nem tudom mennyire volt érthető az alapötlet, vagy hogy hogyan néz ki ez az egész, mi a célja az egész projectnek, de ha szétnéztem nem láttam homlokráncolást.

Tulajdonképpen kicsit új fogalmat építek, ilyen szoftver még nincs, amikor azt mondod hogy email kliens vagy issue tracker, akkor azért mégiscsak vágja az ember, hogy miról van szó. A todomap-re azz mondanám hogy 'social bugtracker', erről nem tudom kinek mi jutna eszébe, talán kevés embernek a térkép.

A második hosszabb előadást Pató Bálint és Tamási Árpád tartotta a SameBug nevű fejlesztésről, ami java exception-ök tárháza és keresője (szintén valami új dolog abban a kategórióban, ahol a stackoverflow is van). A kereső és a felhasználói felülete mocsok jó. Hibákhoz vezető utak gráfon ábrázolva. Egy valami nem szimpatikus benne, és ez a licenszelése. Nem nyílt kódú cucc, hanem szolgáltatásként szeretnék értékesíteni. Vehetnénk úgy is, hogy az tök jó, legalább nem kell installálni ilyen rendszert. A todomap stack traceit szivesen megosztanám (bár elég kevés keletkezik, tényleg), mivel majdnem semmi titkos információt nem tárol. Majdnem, és mi van a maradékkal: e-mail cím, openid azonosító, talán még IP címek is a geoip cuccból. Hogy garantálhatom, hogy nem adok ki ilyen információt? Inkáb manuálisan tömném be egy ilyen szolgáltatásba a logokat, vagy valami adatbázisba tenném, hogy aztán kézzel még átválogassam.

A munkahelyen további nehézségekkel kellene szembenéznem. Hallottatok már a PCI-ról?

Még érdekelne vele az is, hogy a különböző szoftvervetrziókat hogyan tudja tolerálni. Pl hogy hibernate 3.1.x-ben 10 sorral lejjebb keletkezik ugyanaz a hiba, ami hibernate 3.2.x-ben.

todomap - ötletek a felületre

2010-03-16T13:04:00.003+01:00

Hali!

Három új ötlettel jönnék elő a todomap felületéhez és a vélményeteket kérném!

Anon szavazás. Ugyanazzal a fel és le nyilakkal működne az anonkáknak is, de nekik külön számolnánk (azaz a bejelentkezett szavazók eredményeibe nem számolnánk bele) és csak captcha kitöltés után fogadnánk el. Vagy persze B lehetőségként bejelentkezhet az ember.
Részletek oldal áttervezés. Az accordion (hogy hívják ezt magyarul? mind1 legyenek gurulós fülek) elmenne a jófenébe és egy oldalra költözne szépen minden információ.
(Pedig mennyit szívtam a google maps és az accordion inkompatibilításával, mire sikerült rávenni őket, hogy működjenek együt!)
Részletek a térképen. Nem lenne muszáj új böngésző ablakban megnyitni a részletes leírást, feljöhetne egy iframe-ben is, illetve mellette lenne a link a régi módszerre is.

Egyéb hírek a project házatájáról:

Holnap a JUM-on lesz egy tizperces todomap beszámoló is. Nem túl technikai, inkáb csak pihentető jelleggel két erősen technikai beszámoló között.
"Kicsit" el voltam havazva mostanában, tipikus tavaszi pörgés. Ennek megfelelően nem sikerült annyi időt spórolnom a projectnek, mint szerettem volna. Elcsúsztam a kb mostanra tervezett külső rendszerintegrációval, de akkor is meglesz :-) Azt szép lenne eléreni, hogy az önkormányzati választások friss nyerteseit már egy napra kész listával láthassuk el arról hogy mit várunk tőlük.

néhány pénzátutalási megoldás

2010-03-10T00:37:00.003+01:00

Paypal tranzakció díj: 3.4% + egy kis zs hogy biztosan ne járjon rosszul.

noba.hu tranzakció díj (foundraising projectekhez): 2% - barátibb! :-)

moneybookers tranzakciós díj: 1% - hmmmm... Ezzel kapcsolatban van valakinek tapasztalata, véleménye?

todomap 0.5.12

2010-03-10T00:14:00.004+01:00

0.5.12 két apró javítással:

cimkék láthatóak a gebaszokon, a meglévő gebaszok is cimkézhetőek (140)
a cimkékből készül keywords meta, hogy értse a google is, hogy miről van szó (141)

Törölni egyelőre nem lehet. Kicsit okosabbra csinálom a törlő logikát, ha nem maradt gebasz egy cimkéhez, akkor a cimkét letörli.

todomap 0.5.11

2010-03-08T22:06:00.003+01:00

Todomap 0.5.11 frissen a szerveren. Két UI frissítés:

Cimkézés (139) Miután új gubancot jelöltél be, felugrik egy kisablak, ahol egyből cimkézni is tudod. 2 dolog van rá, válogathatsz a cimke-felhőből, vagy beírhatod magad. Autómatikus kiegészítés felugrik alul és rá lehet kattintani ha ráismertél. Mindig csak a 50 leggyakrabban használt cimke lesz fent a felhóben, ami remélem a trágár kifejezéseket eltakarja, mert erre még nincs filter.
Ennek akkor lesz jelentősége, amikor a szerver logikának el kell döntenie, hogy kit értesít a problémáról ha eljön az ideje.
Képek csatolása a térképről. (99)

Még nagyon kellene az, hogy lehessen cimkézni a már meglévő gebaszokat is. Ugyanis azokat még nem lehet... de a héten meglesz, söt talán még ma.

File upload tesztelés

2010-02-26T08:29:00.002+01:00

Csak egy gyors recept.

Tegnap este a file upload funkciót tuningolgattam* egy munkahelyi projecten és azon gondolkodtam hogy ezt hogyan teszteljem. Gyorsan ezt sütöttem ki: wireshar-kal felvettem, ahogy curl-lal elküldöm a postot, kivágtam belőle a http headereket és lementettem a teszt resources könyvtárba. A teszt kiolvassa, betölti a spring-test (régebben spring-mock) csomagban található MockHttpServletRequest tartalmába, valahogy felépíti a servletet (vagy controller spring esetén és akkor pl már inkáb unitils-szel inicializáltatom), egyszerűen csak meghívom a service metódust rajta és innentől a kód teljesen azt is heheti, hogy tényleg egy appserver-ben fut.

*: igen, úgy tűnik a szokásos fileupload-on van mit tuningolni, egy streaming megoldástól lényegesen jobb futást várok, mint sima tutorial-os cucctól, még ha nehezebb is használni.

todomap 0.5.10

2010-02-22T21:45:00.004+01:00

Te szavaztál már? :-)

Szóval, ez a verzió csak kevés újdonságot hoz a kliens oldalon:

Szavazatösszesítés a TODO kisablakában, így már kicsit egyértelműbb talán, hogy a fel és le nyil nem lapozgatás, hanem értékelés. Még az lenne jó, ha mondjuk a lefelé nyil piros lenne. Vagy nem is nyil talán hanem hüvelykőj fel vagy le.
Kicseréltem a upload plugint. A különbség az, hogy most ez nem csak firefoxban működik :) Viszont benne hagytam a javascript alertet :( Következő lépésben megcsinálom Dani ötletét és a térképről is lehet majd képet csatolni.
Még egy chrome gubanc javítása: a rich text editor hajlamos volt újra előmászni, miután lelőttem. Most kicsit hatékonyan lövöm le és nem mászik elő újra.

Az integrációs frontról jelentjük:

Írtam egy kis AOP kódot arra, hogy a szerver oldali adatmódosító hívások (törlés, új adat, módosítás) után elküldje egy sorba (JMS) a módosult adatot. Így aki majd figyel a drót végén, az kapja az arcába az infókat. Nos egyelőre nem figyel ott senki, de arra sem kell sokáig várni, remélem.
Összetúrkáltam egy külön API-t is a magyarorszag.hu hivatalkeresőjének gépi hasznosítására, ez a kód egy darabja lesz annak a nagyobb rendszernek, ami az imént említett drót végén figyelni fog. Lásd előző bejegyzés...
És hogy pontosan mi lesz a drót másik végén, arról még nincs pontos elképzelésem. Csak megyek előre, aztán majdcsak lesz valahogy. Tanulgatom az camel frameworkot, servicemix-szel ismerkedek, mindenféle ESB-k után szaglászom, ilyesmi. Ez jön most egy ideig.
Ismerkedek sok más technológiával is, pubsubhubbub, opensocial, social search, undroid...

Az első verzió, amit a szép új desktopomon csináltam. Az új gép egy 64 bites dual core AMD Athlon II x2, 2 GB 1600 mhz memóriával. Ezt a nevet kapta: dummywarhead. Döbbenetesen gyorsabb rajta a todomap, mint az előző gépen. Mondjuk mert több mint négyszer annyi a számítási teljesítménye... Még 3D-gyorsítós videókártyát is pakoltam bele, pedig amúgy nem szoktam játszani. Egy este alatt meg is untam az összes linux-szal jövö 3D játékot. Ideje újra kpróbálni Pali processzorgyilkosát.

Hóhérakasztó

2010-02-19T11:05:00.003+01:00

Todomap integrációs körök, bevetésen a wireshark.

Tegnap este összekalapáltam egy java API-t arra, hogy a magyarország.hu hivatalkeresőjéből kiturkálja egy település polgármesteri hivatalának elérhetőségeit. Szóval kicsit a saját főztömet kellett megennem, bár nem én csináltam a keresőt. Viszont ráment az egész estém, furcsa dolgokon kellett átverekednem magam. A hivatalkeresőt egyáltalán nem úgy tervezték, hogy emberi felhasználón kívül bárki is hozzányúljon.

Ha elötte nem jön létre a session és emiatt nincsen cookie-d, akkor nem működik a kereső. Innentől már sima URLConnection osztállyal sem sikerült elboldogulni, be kellett rángatni egy commons-httpclient-et.
Az irányítószámot körülbelül le is lehetne szedni az egészről, teljesen figyelmen kívül hagyja. Például ha azt mondod, hogy Sopron polgármesteri hivatalát keresed, és arra a Sopronra gondolsz, amelynek irányítószáma 9400, akkor még rákérdez hogy nem Sopronkövesdre gondoltál-e, aminek már 9483 az irányítószáma.
És az ilyen találgatásoknál úgy tűnik a szerver oldalon hagyja hogy mit kerestem, mert azt nem kell újra elpostolni.
Néha a szerver nem elérhető. Remélem nem csináltam valami rosszat, végülis csak http requesteket küldök.
Néhány városnál igazán mókás adatok is lejönnek, mindenféle freemailes, t-emailes, monornetes, email címek. Minden hivatal onnan szerzi az "informatikai megoldásait", ahonnan éppen tudja. Kiváncsi vagyok mennyire lesz ez hatékony módszer az integrációra, biztosan van közte néhány döglött cím is.

kis- és nagybetűs tuskó

2010-02-16T11:25:00.002+01:00

Azért nem tudta a JIRA összekötni a issue-kat az SVN változásokkal, mert

windows-on fut és
valaki az SVN szerveren ravasz módon csinált egy TRUNK könyvtárat a trunk könyvtár mellé :-)

Tisztára mint a repülésirányításban, legalább 2 marhaság kell hozzá, hogy gebasz legyen.

todomap 0.5.9 - tákombákom

2010-02-09T22:14:00.005+01:00

Todomap 0.5.9 még mindig javítgatásokkal a felületen:

Frekventáltan (másodpercenként néhányszor) előforduló javascript hiba (124) Az egész a jquery tooltip pluginből ömlött. Lecseréltem q-tip-re. Köszi Móninak a tippért! Most így néz ki a tooltip:
Lokalizáció takarítgatás: a login ablakon a kis csekkboksz és a például néhány metainformáció nem volt lemagyarítva, a google ezért így vette fel. Most még így néz ki:
Félig medig be lett kötve a szavazás a felületre. Hát ezen még kell alakítani, de a szerveren végülis kikötnek a szavazatok.

todomap 0.5.7 és 0.5.8

2010-02-04T08:51:00.007+01:00

Ja még elötte: kütyük témakörben ha megszánnátok szavazataitokkal itt a blogon oldalt látható az a kis szavazódoboz! Köszi!

Vasárnap kitettem a szerverre a 0.5.7 verziót:

Spamfilter integráción dolgoztam. Ez szerintem egész jó lett. Bár mocsok egyszerű, akár újrafelhasználható más projectekben. Még dolgozok rajta. (13)
Á, igen, login hibák most már megjelennek. (68) Hát nem mondanám hogy ember-baráti üzenetet küld, meg még csak szépet sem.
Kicsi szépítés a koordináta visszafejtő dobozoknak.
A könyvjelzők be lettek kötve a backendre. Szóval most már nem csak kattintgatsz, tényleg történik is valami :-)

A 0.5.7-es verzió jól kitolt azokkal, akiknek a google nem oldja fel az IP címét, csináltam bele egy javascript hibát, ami otthon soha nem jött ki. Így hát jött tegnap este a 0.5.8-as hibajavító kiadás:

apróbb SEO, keywords meta lokalizáció. (129)
Letéptem pár dolgot a felületről ami nem működött és még csak ki sem találtam hogy mit csináljon.
pár lépés a 'remember me' funkció felé, nem lett kész mert ez a jelenleg használt spring security verzióban törött. Az a jó, hogy ilyen sok minőségi komponenst pakoltam a szoftverbe.... (59)
visszatérés a térkép megadott pontjára bejelentkezés után (128) Persze ez csak opcionálisan. A bejelentkező ablakon a kis csekkbokszot be kell kattintani. És persze elfelejtettem lefordítani magyarra.

Új front: integráció

A UI hekkelésekkel még elleszek egy darabig. Sajnos ehhez még csak most gyűjtöm a tapasztalatokat. Most egy új dolgot is elkezdek, amiből sokkal kevesebb látható eredmény lesz: integráció külső rendszerekkel. Itt van a halál-listám. Tulajdonképpen itt kezd majd különbözni egy panaszgyüjteménytől.

todomap todo-list

2010-01-27T22:18:00.004+01:00

A múlt hét elégrázósra sikeredett sajnos, 2 szerverleállás (az egyik 31 órán át) és 1 hálózatkiesés, munkahelyi túlórák és még egy otthoni gép-crash is nehezítette a munkát. A végére nem is lett belőle verzió és frissítés, nem is voltam itthon vasárnap.

No, most azóta rendberántottam az itthoni gépemet. Félelmetes, reiserfs volt a home partícióm! Legaláb 5 éve így lehetett, Hans Reiser legalábbis már 4 éve nem szívott szabad levegőt és még úgy 11 évig valószinűleg nem is fog. Én meg ilyen lusta vagyok, ennyi ideig rá se néztem, merevlemez csere alkalmával is talán csak dd...

Todomap: Egy kis tucat fejlesztés van készülőben:

Elkezdtem foglalkozni a külső rendszerek integrációjával. Hát ebből még nem sok látszik.
Spam-filter beépítéssel foglalkoztam, ingyenes akismet, írtam hozzá egy új API-t. Majd lesz később egyéb is integrálva, ezzel túlélem egy darabig.
Normálisan fog működni végre a könyvjelző funkció és a szavazás.
És dolgozok a tooltip plugin lehelyettesítésén, ami a nagy rakás javascript hibát csinálja.

Ennyi, nem sok.

JUM XIII

2010-01-21T09:16:00.003+01:00

Öregszik a JUM, már a 13. alkalmat tartottuk tegnap este.

Tvik: Scala

Érdekes összefoglaló volt a scala lehetőségeiről, nekem valahogy az volt az érzésem hogy minden említett dolga érdemelne egy külön előadást. A scala-ban egyszerűen túl sokminden van. Magánvélemény, de én kicsit zavarosnak tartom a kulcsszavait, egészen onnantól hogy object, ami egy olyan class, aminek nem lesz példánya, mert csak static metódusok vannak benne. Pedig az object az az osztály egy példánya lenne úgy általánosan OOP-ben, nem? Mindegy, még az olvasásra szánt könyvek sorában várakozik a scala kupac, remélem én is hamarosan többet fogok érteni belőle.

Verhás Péter: Velocitoro maven plugin

Ötlet maven pluginra. Maven plugint hébe-hóba hegesztek én is, (pl a kis jetty-gzip tákolmányom), tényleg majdnem olyan egyszerű, mint ant taskokat írni :-) A velocitoro statikus weboldalak generálására szolgál és így nagyon kevés (kb 0) tapasztalatom van ilyen projectekben, így csak az első impressziómat tudom megosztani: az nem igazán tetszett hogy a java és a groovy kód egybe van a html kódokkal és a velocity templatekkel. Az olyan kis rumli hangulatú dolog.

Auth Gábor: JBoss ESB

Legfőbbképpen ez érdekelt, szó volt a JBoss csodálatos új MQ-járól, ami 5x* lenyomja az ActiveMQ-t, a hiper-optimalizált ESB-jükről, amiben van minden, BPEL és mindenféle. Nem tudom mennyire értem jól a dolgot, üssetek ha marhaságokat hordok össze, de tipikusan arra használja az ember az ESB-t, hogy független rendszereket kössön össze velük. Akkor engem nem annyira a cucc sebessége érdekelne.

Én az ilyen vendor-binding dolgokból szeretek egy kicsit kimaradni. Jó stratégiának tűnik, ha meg akarod úszni a portolást miután az Oracle megvette a JBoss-t :)

*: bizonyos esetekben :-) másokban lehet még lassabb is, gondolom...

Long live the VHOST!

2010-01-19T07:42:00.004+01:00

Tegnap még annyira volt időm hogy találjak egy javascript hibát a kódban ebédidő körül. Csak pár ritka IP-ről észlelhető hiba (mint a munkahelyemé), a többi kliensről nem lenne semmi baj. Viszont 16:20-kor a szerver eltünt a netről és azóta se kép se ping. A teljesn szolgáltató (vpsplant.com) eltünt, valami súlyos problémájuk lehet. A hup fórumon se tud senki semmit. (Azért néha meglep hogy mennyit tudnak írni arról is hogy nem tudnak semmit :-) )

Szóval per pillanat ez a helyzet. A VPSPlant.com-ot azért kedvel[t]em, mert tulajdonképpen egy ebédem (kell nekem bankban ebédelni, na mind1) árából kijött a havi szerverbérlet. Szétnéztem, hogy mi a kínálat ha esetleg a vpsplant búcsút int. Nem túl tetszetős a kínálat, azért elég drága mind ahhoz képest hogy mégiscsak közös lóról van szó.

Az Amazon EC2-n 11.000 körül havonta, ráadásul ámerikában hostolva, Írországban drágább ha jól értettem.
Ebben az árkategóriában már dedikált szervert is bérelhetek 15.000 körül és akkor annak rendesen van memóriája, 2 proci mag, bőven merevlemez is és itthon van. Egy ilyenen például elmenne pár kedvenc kütyüm is, pl sonar
5-6000 körül láttam colocation ajánlatot, ha összevakargatok az itthoni hardware kupacokból egy gépet. Inkáb nem, hardware témában mindig nagyon le vagyok pusztulva. Legalább 4 éves a legújabb gépem is :-D
A google app engine ennél lényegesen olcsóbb, talán a VPSplant-nál is olcsóbb lenne, hiszen a todomap nem valami CPU-intenzív alkalmazás a szerver oldalon. Viszont egy nagy rakás kódot ét kell hozzá írnom, az adatokat átmigrálni, és akkor megint csak ámerikában vagyunk, amit nem akarok. Plusz kicsit kemény megkötései vannak a környezetnek.
Valakinek valami ötlete?

todomap 0.5.6 - über

2010-01-17T11:50:00.004+01:00

A QA hiánya ide vezet: csodaszépen kipublikáltam egy javascript hibás todomap-et. Szóval most totál hulla szegény. Ilyenek ezek az alfás szoftverek, meg sajnos én is így összecsaptam a cuccot este.

Ismét eltellt egy vasárnap, itt van hát a friss todomap a hét fejlesztéseivel.

Felület:

Anon felhasználótól kérünk bejelentkezést mielött zászlót tűzhetne ki (101)
Búcsú az Atlanti óceántól: ha se a google jsapi, se a todomap saját geoip szolgáltatása nem tudja megmondani hogy hol vagy, akkor a lokalizáció. Azaz a hu.todomap.org magyarországra irányít az Atlanti óceán helyett, ami a régi megoldás volt.
Lokalizált térkép (119)
Csoport infowindow kinézet javítás
Mindegyik fül becsukható a részletes leírásban. És már a google térkép se esik szét, ha minden igaz.
Néhány egyéb javítás a lokalizáció körül

Technikai:

Frissítettem Spring 3.0-ra és Spring Security 3.0.1-re (amit tegnap adtak ki). Nem azért mert az jobb, de az OpenID AX egyáltalán nem működik a 2.x szérián. Hát ezzel megyeget...
Az infowindow-ban lecseréltem a kinézetet CSS alapúra az img tag helyett. Most már valamennyire látszik hogy ez egy interaktív játék lesz, de még nincsen teljesen behuzalozva. Csak a design kedvéért teszem ki, érdekel hogy mennyire tetszik.

A hétre még tervezek egy frissítést a következő vasárnapi elött, ha kész leszek pár további javítással és a szavazás/bookmark behuzalozásával.

todomap 0.5.5 - kozmetika

2010-01-10T22:45:00.005+01:00

Szokásos vasárnapi verzió még mindig a 0.5 szériából:

nagyító ikon a csoportok ablakában (103) ha rákattintassz, közelebb visz annyira, hogy a csoport szétessen darabjaira, meg persze középre is veszi.
404 és 500-as oldal azoknak, akik megilyednek egy stack trace-től. (105, 106)
A gubanc részletes leírásánál nem a térképet mutatja elsőnek, hanem a leírást (113) nyilván haszontalan a megint térképet nézni ha pont onnan jöttél
Postai cím visszafejtés kezdőcím és probléma hely meghatározásánál (109, 110) Ez kicsit talán még kiforratlan és félreérthető, rá is húztam egy tooltipet (remélem valaki észreveszi egyszer). A címet a címet nem küldi el a szervernek, csak annyira jó, hogy a kliens oldalon a google geocoderrel kiszámoljuk vele a koordinátákat. Például ide még kellene egy autocomplete is, többek közt...

Köszi mindenkinek a visszajelzéseket, nagyon sok építő kritikát kaptam! Még egy ideig el leszek látva munkával, de meglesznek!

A virtuális szerver IO sebessége alulmúl mindent. Csak ennek köszönhető, hogy nem töröltem le mindent véletlenül amikor az új verziót installáltam. Hihetetlen, de sikerült ctrl-c-t nyomni még mielött bármit is letörölt volna. Persze van napi backup is. Legalább 20 perc volt, amíg a servlet container újraindult :-(

Maven 404-ek

2010-01-05T20:17:00.004+01:00

A todomap.org maven repoját úgy tűnik nem csak én használom, hanem páran mások is, nem tudom kik, az IP címet leszámítva, úgy látszik nálam találták meg amit kerestek. Nem baj, azért tettem oda hogy megtalálják... Viszont ez kiválló alkalmat ad arra, hogy megpróbáljam kielégíteni kiváncsiságomat: vajon mennyi 404-et generál a maven a repository szervereknek?

Az összes request a maven-től:

grep Java *.request.log | wc -l

3796

És ebből a 404:

grep 404.*Java *.request.log | wc -l

3618

Ez legtöbbször azért van, mert egyes artifactokhoz nem talál a maven pom file-t, ezért minden egyes alkalommal megpróbálja beszerezni hozzá, hogy feloldhassa a dependency-ket (hacsak nem -o opcióval hajtjuk éppen, de például continuous integration szerveren tipikusan nem).

Azt is megnéztem hogy szemre mi lehet a leggyakoribb oka a 404-nek: oracle jdbc driver :-) Érdekes listát kaphatnánk a nem maven-barát projectekből, ha nagyobb ismert repo szerverek logjaiba belenéznénk. Talán összeállíthatnánk egy fontossági listát arról hogy mihez lenne érdemes pom-ot hímezni akár kézzel is.

Egyébként nem tudom jól emlékeszem-e, valamikor még a maven 1.x alpha idején volt az ibiblio.org-nak egy félelmetesen hosszú 404 üzenete, amiben többszáz nyelv szlengjében elmondták azt, hogy "nem találom". Magyarul is persze. Hát nem csoda hogy eltünt :-)

todomap 0.5.4 - nemzetközösülés

2010-01-03T17:22:00.004+01:00

Ma délután becimkéztem a 0.5.4-es verziót, és most már a szerveren is fent van. Ez történt a 0.5.3 óta:

#24 - i18n. Már csak egy DNS módosítás kell és tesztelhető lesz a magyar TodoMap. update: kész is. úgy tűnik az interware-nél korán kezdődik a műszak
Tegeződni fog, remélem ez senkinek nem lesz ellenszenves.
Valamint sikerült egy hibát bele is tennem: #104 Nagyon egyszerű kis gubanc, de ilyenből nagyon sokat lehet csinálni.
#92 - IE ocsmányságok. Ebbe csak belerúgtam, már nem annyira vészes, de még mindig nem jó.
#102 - Delete. Szintén félkész állapotban ment ki :-( A szerver tudja, a kliensre is behuzaloztam de úgy megborította a kinézetet, hogy inkáb kikommenteztem.

És hát ez a 0.5.x iteráció igen rendesen kicsúszott a decemberből, így kénytelen vagyok egy pár hátramaradt tennivalót deprioritizálni és befejezni a 0.5-ből megmaradt rutinfeladatokat. Tapasztalatok ebből a körből:

A szoftver-lokalizáció agyhalál
A karácsony mégsem jó hegesztésre, meg a szilveszter sem

TodoMap

2010-01-01T15:29:00.004+01:00

Hali és boldog új évet!

Szóval tartoztam az előző évtizedből egy magyarázattal hogy mi az ötlet a todomap.org kisérlet mögött. A todomap.org egy olyan kis project, amiben térképen bejelölheted azokat a dolgokat, amik bántják a szemed. Legányolt vasútállomás, koszos utca, betört utcai lámpák, úthibák, elhagyott és lepusztult épületek, közlekedési vagy parkolási gondok, illegális hulladéklerakók, falfirkák, mocskos aluljárók, közbiztonság, zaj, szmog, kutyabajok és más higéniai problémák... hosszú lehetne a felsorolás és persze mindegyikre fel tudnék sorolni példákat néhány kilóméteres körzeten belül. Gondolom ezzel nem vagyok egyedül.

Viszont az egészet nem egy panasz-oldalnak szánom, éppen eleget (vagy túl sokat is) panaszkodunk már így is.
Elösször is, ezeknek hibáknak többnyire van hivatalos felelőse, akit értesíthetünk a dologról, és remélhetőleg örömmel fogadja. Bármilyen rendszer-integráció működhet, akár az old-school FTP-s filetransfer, e-mail, web service (az ennyire korszerű megoldásokon meglepődnék, de persze örülnék neki).

Másodszor pedig akit érdekel a dolog, az indíthat akár saját projectet is. Pl találsz egy rozsdás korlátot a környékeden és beregisztrálsz rá egy projectet, valaki felajánlhat hozzá festéket és higítót, más talán a rozsdamarót, harmadik ember talán a segítségét fogja felajánlani. Idealizált eset nyilván, de az még nem jelenti azt hogy ez nem működhet.

Ha te egy közmű felelőse vagy, a todomap.org szeretne téged összekötni azokkal akik az általad üzemltetett infrastruktúrát használják. Nem csak azt fogod tudni hogy hol vannak a problémák, de azt is hogy a felhasználóknak ez mennyire fáj számszerűleg.

Ha te vagy az állam (illetőleg egy párt), képet kaphatsz arról, hogy a polgárok mit tartanának fontosnak a környezetükben, jó esetben egészen pontos képet. A kommunikáció költségét lecsökkentjük, így sok olcsó input jön be, ami ráadásul már rangsorolva is van.

Ha te egy sima állampolgár vagy, mint én, akkor a todomap.org-on meg tudod osztani a többi állampolgárral a környéketek problémáit, tudod őket rangsorolni, RSS feedeken, e-mail-en stb-n keresztül értesítést kaphatsz arról hogy mi történik ezekkel a problémákkal, mi történik a környékeden egyáltalán. Ha kész vagy arra, hogy tegyél valamit a tágabb értelemben vett lakóhelyedért, akkor szintén számíthatsz némi informatikai támogatásra hozzá.

Ez a terv. Hogy állok ezzel... nem rosszul, de még nagyon sok van hátra. Sokat küzdök a UI dolgokkal, kevés érzékem van a 'usablity'-hoz és az esztétikához, viszont tucatnyi visszajelzést kaptam több tesztelőtől (akiknek +1x köszi!) Internet explorer-ben például csak a múlt héten volt lehetőségem megnézni és elképedni rajta mennyire szét van esve (köszi azoknak is, akik nem használnak internet explorer-t!) Az infrastruktúra egy részét kunyiztam, a másik része olcsó bér-virtual-host.

És szóval ez megy majd idén, a szokásos ganajlapátolás mellett :-) Meglátjuk mire lesz időm és erőm.

Évvégi offtopic

2009-12-30T18:00:00.005+01:00

Sziasztok!

Hát ha valami rendkívüli közbe nem jön, akkor ennek az évnek is vége lesz határidőre és gondoltam pár rendezetlen gondolatot kidumpolok ide arról, hogy mi volt idén és mi lesz jövőre.

Jövőre 3 éves lesz ez a blog. Az utóbbi 1 évben rettenetesen megritkultak a postok. Mondjuk nem csak itt, hanem nekem az az érzésem hogy a többi magyar java blogban is sajnos. Bele fogok húzni! Sőt már el is kezdtem, csak amivel fogalkozok mostanában, az szoftverfejlesztés szempontjából nem valami izgalmas.

Szerintem kapcsolódó probléma (illetve jelenség, amennyiben nem probléma), hogy a JUM-okon nem sikerült meghonosítani a quickie-ket. Teljesen ki is haltak és a hagyományos előadások vették át a helyét. Hát erre van igény, akkor ez van. A melóhelyem hasonló funkciójú "kb havi rendszerességű" összejövetelén próbálom most, szerintem kicsit több sikerrel. Az interaktívabb, mondjuk talán azért mert eleve lazább hangulatú az egész. Péntek délután, tea, süti, üdítő, kivetítő...

Szabadidőmben (ezt az előző postból biztosan kihámoztátok) a todomap projecttel foglalkozom. Ez érdemelne egy kis magyarázatot a jelenlegi állapotában, de mondjuk szóljon inkáb majd erről az új év első postja. Addig "What you see is WTF" :-). Itthon megtartottam pár kisérleti állapotából screenshot-ot amit mostanában nézegettem és úgy tűnik, az ötlet is, az implementáció is fejlődgetett elég sokat, közben kicsit képbe kerültem néhány technológiával. Az új évben ezt a projectet szeretném elvinni addig ameddig tudom.

Egyébként ezen kívül az történik, hogy egy nagyon fertőző gondolat-vírus született az agytekervényeimen, ami szerint a 30. születésnapra frankó befejezni az Országos Kéktúrát. Jópár barátomra átterjedt ez a vírus, így mostanában ennek engedemleskedve tapossuk a kilómétereket. Aki esetleg túl van a 30-on az használja nyugodtana gondolat-vírus 40. születésnapra vonatkozó mutációját :-)

JUM 12

2009-11-20T19:27:00.004+01:00

Tvik már beszámolt, de én is beszámolnék, csak hogy szinesítsem a képet és a visszajelzések számát.

Viczián István: JAX-WS

A végén rá is kérdeztem, bár kicsit hülyén, szóval az előadás a JAX-WS és a reference implementációjának problémáit ölelte fel. Azaz nem feltétlenül szívja meg az ember pont így. Igen, elég ijesztő volt. Contract first WS. Nem tudom, én ezekkel nem szivatom magam, felannotálom a web service interfaceket alaposan :-D és ha az interface marad ugyanaz, akkor a kigenerált WSDL is, sőt a SOAP üzenetek tartalma is. Szóval innentől én kevés motivációt érzek a dologra, persze ha bankot vagy atomreaktort kellene ezzel hajtani, akkor biztosan óvatosabb lennék. Még egy saját horror-élményt hozzáfűznék: CXF és jettison, ha ugyanaz a neve egy property-nek és a property property-jének, hát akkor a jettison ott elcsűri a json objektumot. A tréfa az, hogy a többi részét is kiteszi, csak elötte lezárja a tömböt. Atomreaktort már csak az ilyenekért sem hajtanék vele, ez a bug akármilyen egyszerűnek is hangzik, elég rég óta vár javításra.

Csutorás Zoltán: Agile, SCRUM, Lean

Igen, volt szó a SCRUM-ról is, de a végén az a modell, aminél a gyártósor leállások voltak és mindenki le volt rajta döbbenve, na az nem a SCRUM volt már, hanem valami más aminek a ~~nevére nem emlékszem~~. Update: KANBAN. Az előadó stílusából azt a következtetést vontam le hogy neki alighanem vannak hozzá acéldrótokkal erősített idegei, hogy a felvázolt módszertant keresztülvigye. És akkor gondolom működik is. Annyi biztos, hogy én ehhez gyáva vagyok.

Kis Gergely: Andriod és Hundriod

Az elején kicsit gyanakvóan figyeltem, hogy miért indítja furcsa paraméterekkel parancssorból az openoffice-t, mi az a pythonos trükk, amit még elstartol hozzá... Viszont hamar kiderült, hogy innetől az androidos telefonnal irányíta a prezentációt. Onnantól kezdve nagyon tetszett, bár nem egy felhasználóbarát megoldás per pillanat, de nagyon látványos demó volt. Én továbbra is beérem az kötelező mutatvánnyal amúgy, én a telefonomat tényleg csak telefonként (és fényképezőként és pendrive-ként és walkman-ként) használom.

Mosatanában elkövetett mini-projecteim

2009-11-07T23:37:00.003+01:00

Kicsit elhanyagoltam mostanában ezt a blogot és inkább otthon hegesztgetek. Pár némileg újrafelhasználható dolgot is összekopácsoltam az utóbbi pár hétben.

MiniGeoIP

Szóval próbálkoztam azzal, hogyan tudom bemérni a kliens földrajzi helyét. Nem holmi öncélú marketingdolog miatt, hanem egyszerűen hogy az alkalmazás számára releváns infóval tudjon indítani. Egyébként a IP-blokkolás szerintem rasszizmus. Próbálkoztam a Google JSAPI-jával, a tapasztalatok viszont azt mutatták, hogy a Google vagy megmondja hogy hol vagy, vagy nem... Ami azért bár nagyon baráti, de mégsem 100%-os telitalálat. Söt, sajnos úgy tűnt az ismerőseim többségének IP címére nem mond semmit. Keresgetni kezdtem szerver oldalra beágyazható IP feloldást de nem sok használható dolgot találtam, úgyhogy a felgyűlt ihletből gyorsan összedobtam egyet. Ez az implementáció egy 100.000 soros adatbázist épít fel magának. Az még a memóriában is elférne talán, viszont én JPA-n keresztül keresem. Sajnos kényelmes voltam és spring JpaDaoSupport-ra építettem, szóval most totál spring-függő, de ez most még nem fáj nekem. Cucc. Ja és itt ki is lehet próbálni, hogy jó országba tesz-e.

GeoCoder

Hasonlóan föcis téma, egy adott koordinátából szeretnénk megkapni a postai címet amennyire lehet. Unalmas. Google reverse geocoder. Köszi gúgli. Cucc.

Jetty-gzip-plugin

Ez szerintem vicces téma, a jetty default servlete tud olyat (és alapból be is van kapcsolva), hogy ha egy statikus file mellett ott van a .gz tömörített változata, ÉS a kliens nem IE :-D, akkor a tömörített változatot küldi el, ezzel megtakarítva sávszélességet és egy kis időt is. Pl a javascript library-k egészen hatalmasra nőttek. Ez a kis maven plugin egyszerűen packageléskor létrehozza a .gz fileokat. Akár kézzel is megcsinálhatná az ember, ha nem felejtené el mindig. Nekem kicsit több mint 100Kb-t takarít meg egy oldalmegjelenéskor, ennyiért úgy gondoltam, hogy már megéri. Cucc...

Google Translate Java kliens

Hát ez annyit tud, hogy megmondja, milyen nyelven van a szöveg. Teljesen minimalista, de ennyivel beérem. Ismét köszi gúgli. Kicsit már zavar hogy mennyi mindent ráépítek google szolgáltatásokra. Cucc...

Ennyi, köszi ha eddig eljutottál, akkor most megint pár hét lapátolás...

Az ajax file upload és a gonosz flash

2009-10-26T22:03:00.004+01:00

Próbálgattam AJAX-os file upload cuccokat JQuery-hez és elsőre majdnem bedőltem az uploadify-nak. Egy kis időt eltöltöttem azzal, hogy a file feltöltés miért nem látja a szerver oldali session-t, teljesen azt hittem egy ideig, hogy a szerver oldalon szúrtam el valamit. Pedig nem: az uploadify flash-t használ feltöltéshez és a flash figyelmen kívül hagyja a cookie-kat. Ezt már hallottam mástól is, csak nem jutott át az ingerküszöbön.

Gyorsan át is gyergeltem erre a másik ajax upload cuccra, ez teljesen jól működik idáig, nincs benne flash, bár a skineléssel akadt problémám de az valószinűleg inkáb abból származik, hogy CSS-ből még mindig kettes alát érdemelnék.

@Autowired és társai

2009-09-08T15:37:00.005+02:00

Mostanában gyakran beleakadok a spring framework @Autowired annotációjába, amit kifejezetten private mezőkre húztak rá, amin nincs setter sem. Pl...

@Autowired

private Datasource datasource;

Az a kifogásom ellene, hogy:

besettelni sem lehet neki valami mást
springen kívül nem lehet inicializálni
elég sok időbe tellik kibogarászni hogy vajon mi lesz ide besettelve

Nem olyan, mint a JdbcTemplate, amit szerintem simán más framework-re is bele lehet tuszkolni, és ráadásul nagyon hasznos. Sikerült portolhatatlanná tenni a kódot, pedig a spring úgy indult annak idején, hogy non-intrusive IoC framework. Másrészt ez olyan, mintha service lookup-ot használnánk, annyi előnnyel, hogy a boilerplate kódot átvette a spring. Viszont akkor már ilyet is csinálhatnánk:

@JndiLookup("jdbc/MyDS")

private Datasource datasource;

A megoldás: TestNG

2009-09-08T08:56:00.001+02:00

N alkalommal futottam neki a TestNG használatának eddig, mindig nagyon boldog voltam magával a TestNG-vel, de az IDE integrációjával soha nem tudtam kibékülni és végül inkáb maradtam junit-nál. Az 'új' projectem pár artifact-jába viszont valamiért belecsomagolták a junit egy matuzsálemi verzióját, ami teszt alatt ütközésbe kerül az új verzióval, így nem maradt más választásom, mint testng-t használni.

RIA kalandok

2009-08-24T14:35:00.006+02:00

Hát igen, jó hosszú történet, ugyanis a kliens oldaltól mindig próbáltam magam távol tartani. Nyilván a CV-ben sem áll jól, ha valaki nem pöpec a teljes alkalmazás stack minden apró elemében, meg elkezdett érdekelni is a téma.

Szóval a hosszú történet...

OpenLackó

Úgy kezdődött, hogy OpenLackó. Az OpenLaszlo volt nálam az első és eleinte marhára bejött, hogy én is tudok olyanokat csinálni benne, mint a UI guruk.

Előnyök:

Tényleg marha gyorsan össze lehet dobni a felületet.
Alapértelmezésben is szép.

Hátrányok:

Szőrös RPC megoldások. Például minden hívást a laszlo szerveren keresztül akar végrehajtani. Minek? "Java RPC" - public static metódusokat lehet vele hívni. Csúnya dolgokat kényszerített ki a szerver oldalon.
Horrorisztikus fejlesztési menet. Dobáljuk be a lzx fileokat a laszlo szerverbe? Miért nem lehet inkáb beágyazni az egészet?
Nem igazán indult be a komponens-piac, talán éppen a fentiek miatt.

Flex + BlazeDS vagy amit akarsz

A flex-ben amit elsőre megszerettem, az az hogy végre normálisan néz ki a RPC. Hívhatunk teljesen szabványos SOAP hívásokat, vagy kicsit cifrább mulatságba is belemehetünk BlazeDS-sel. Extra a lackóhoz képest az is, hogy nem kell a runtime környezetbe beletolnunk semmi flex specifikus dolgot. Egyből 40 megával kissebb a war file, hoppá.
Előnyök:

Sokféle és használható RPC. Akár szerver data push is.
A data binding szerintem király.
Nem feltétlenül akar valami spécit a szerver oldalra.
Kiválló maven plugin :)
Sokféle free UI komponens és library a neten.

Hátrányok:

Pokolian lassú fordító.
Hát van a flexbuilder, ami pénzes windowsos, akkor már egy új gépet is kellene vennem... Valamint összedobtam egy gyors plugint régebben, ami semmi mást nem csinál, csak lefordítja minden módosításra a flex kódot. Ezek nélkül azért meg lehet lenni.

ZK

Erre egy volt munkatárs hívta fel a figyelmemet és nagyon örültem is neki. A zk király... bizonyos dolgokra.
Előnyök:

Nem kell IDE :) Simán eclipse-ből editálva a zul fileokat háttérbe futó jetty-vel ment minden mint karikacsapás. Nagyon gyorsan lehet vele haladni. Módosítás esetén is villám gyorsan újrafordít.
Tiszta html.
Nagyon egyszerű és működő spring integráció.
Akadnak hozzá hasznos kis extra komponensek, egész könnyűnek tűnik sajátot írni. Az alap csomag is rengeteget tartalmaz.

Hátrányok:

Nekem úgy tűnik, borzasztó sokat nyúl a szerverhez. Nem tudom róla leszoktatni. Mindenért a szerverhez szalad.
Szerver oldali session-t nyit, egész nagyot. Skálázhatósággal nem tudom hogy állhat.

Szóval bekategorizáltam, hogyha egyszer valami csili-vili intranetes dolgot kell majd csinálni, akkor új lehetőségeket kap.

Google Web Toolkit

Hát ezzel odáig jutottam, hogy végigcsináltam egy tutoriált, és amikor oda jutottam hogy lefordít, akkor olyan botrányosan lassú volt, hogy fejvesztett menekülésbe kezdtem és azóta nem merészkedtem vissza. További információk így nem derültek ki.

HTML + JS + jQuery

Végülis feladtam és elfogadtam, hogy meg kell tanulnom javascriptet használni. Kicsit új eszközöket kellett keresgetnem ehhez, tényleg olyan érzés volt, mint gimi után C-ben kalapálni. A jQuery-t egy munkatársamtól lestem el, ő egekig magasztalta.
Előnyök:

Még csak nem is jsp. Statikus html. Akármilyen IDE elegendő támogatást ad hozzá. Jó, mondjuk az eclipse javascript képességei tényleg nem tűnik valami nagy pukknak
A SOAP-ot nem próbáltam, de a REST hívások simán mennek. Csak az megy át a dróton, amit az ember programoz. Alacsony szintű ajax megszelídítve.

Hátrányok:

Még felfedezés alatt áll, de a UI library nem olyan nagyon frankó még.
Alacsony szintű összeakadások. Például beleraktam egy google map-et egy dialog-ba, és hát voltak vele bajok, kicsit elcsúszott a google map. Nem tudom miért, kicsit erősítenem kell még javascrptből.
Szerintem az olvashatósággal vannak problémák, de lehet hogy csak nekem kell még megtanulnom olvasni.

Ez a helyzet idáig. A véleményeteket és útmutatásaitokat természetesen örömmel látom.

JAX-RS és JAX-WS

2009-07-08T15:23:00.009+02:00

Köszi a hozzászólásaitokat az előző postra, egész sok inspirációt kaptunk ahhoz hogy hogy írjuk át a teszteket!

Igazából most is a véleményetekre lennék kiváncsi.

Szintén munkahelyi projectben azon mesterkedtem, hogy SOAP-os REST-es web service-t is meghagyom egészen addig, amíg teljesen világossá nem válik hogy az adott környezetben melyik a nyerő megoldás. Természetesen spring-gel inicializálom a service bean-eket, CXF-fel exportálom ki, JSR 181 web services és JSR 311 rest annotációkkal látom el a service metódusokat és a beaneket még JAXB annotációval is helyenként. Sikerült is, bár szerintem kicsit szőrös a dolog.

Elösször is a JAX-RS a beanjeid Collection (list, map) mezőire megköveteli, hogy legyen mindnek alapértéke és csak gettere. Azaz ne lehessen null soha, legfejebb üres. Viszont a JAX-WS elvárja hogy mindenkinek legyen szép gettere és settere, különben nem számít proprtynek. Ez a kettő nem feltétlenül zárja ki egymást, csak kicsit megcsúfítja a bean-eket.

Például így fog kinézni egy bean:
```
/**
* Szerintem gáz, amikor magyar neve van egy osztálynak :)
* Majdnem mint amikor a javadoc is magyar.
*/
@XmlRootElement(name="csirke")
public class Csirke {
boolean isKopaszNyaku;
boolean isKendermagos;
List<Tojas> tojasok = new ArrayList<Tojas>();
@XmlTransient // Nem ezt a property-t hasznaljuk a rest apival
public List<Tojas> getTojasok() {return tojasok;}
public void setTojasok(List<Tojas> tojasok) {this.tojasok = tojasok;}
@XmlElement(name="tojas")
@XmlElementWrapper(name="tojasok")
public List<Tojas> getTojasLista(){ return getTojasok();}
}
```
Szóval szerintem kicsit összetúrkáltuk az alkalmazás legérzékenyebb részét: az adatmodellt. Ha az adatmodell csúnya, az mindennek rossz alaphangulatot ad.
A CXF-nek kicsit nehéz volt megmagyarázni, hogy ha pl a /services/ alá mappeltem a CXFServlet-et, akkor mit kell csinálnia akkor, amikor kap a /services/-re egy kérést. Azt hiszem az lehetett a baj, hogy nem állítottam be at address-t.
```
<jaxrs:server name="jaxrs-server" bus="rest" address="/rest">
<jaxrs:servicebeans>
<ref bean="csirkefarm">
</jaxrs:serviceBeans>
</jaxrs:server>
```

A service interfacekre raktam az annotációkat, hogy ha lecserélem az implementációt, akkor az új service-re már ne kelljen másolgatnom. Hát elég cifrán meg lett annotálva egy-egy ilyen metódus.


@WebService(name = "csirekFarm")
@Path("/csirkeFarm/")
public interface CsirkeDAO {
@WebMethod(operationName = "getCsirke")
@WebResult(name = "getCsirkeResult")
@GET
@Path("/csirke/{csirkeId}")
public void Csirke getCsirkeById(@Webparam(name="csirkeId") Long id);

Most, hogy az annotációk legyőzték az XML konfigurációkat, a kódunk tele van konfigurációval :-) A hétvégén összedobok hozzá egy archetype-ot, ha elég időm marad rá.

Logging

2009-06-25T08:20:00.003+02:00

Belekeveredtem egy problémába a OpenJPA unenhanced osztályaival és úgy döntöttem hogy inkább visszatérek kicsit Hibernate-re. Nos magában a visszatérés nem lett volna nagy ügy: kiszedni az OpenJPA-t a pom.xml-ből, betenni a hibernate-entitymanagert, kicsit módosítani a jpa konfiguráción és kész is lenne...
Viszont a hibernate időközben nagyon szépen áttért a log4j logolásról a slf4j logolásra. Őszintén szólva teljesen lusta voltam egész idáig akár belenézni is, hogy mit kínál az új logging api. Nos a Simple Logging Facade 4 Java azt találta ki, hogy az régi logging apik helyére tesz egyetlen loging rendszert. Azaz kidobtak egy halom jar file-t, amiben például benne lehet a jó öreg org.apache.log4j.Logger, és emiatt nem tűri meg maga mellett az eredeti log4j-t. Dependency hell. Akármelyik csomagom is hozott be log4j függőséget, azonnal ki kell vadásznom a teljes dependency fából. Most még be kell dobálni a slf4j api-t, majd a log4j-over-slf4j csomagot...

A végeredmény az, hogy a JPA implementáció cseréje sokkal kevesebb időt vett igénybe mint a logging api cseréje. A logging az a dolog amitől azt várnám hogy nem zavarhat semmit, nem romolhat el és nem okoz semmiképpen sem futási hibát.

"Lassan haladunk, de nem baj, mert rossz irányba"

Rémálom a JPA utcában

2009-06-21T20:43:00.004+02:00

Ezt a problémát próbáltam felvázolni Tvik-nek a eclipse democamp elött, de azt hiszem túl alacsonyan volt akkor még az agytevékenységem hogy sikerrel járjak. Meg talán viccnek túl hosszú ez az egész.

Szóval egyik nap áthívott az egyik srác egy másik projecttől, hogy segítsek elindulni a JPA persistence tesztek fejlesztésével a projecthez. Eléggé félfüllel követtem a project életét, szóval igazából csak nagyon kevés ötletem van arról hogy mi miért jutott oda ahol van az architektúra fejlődése során, de ehhez a feladathoz ezen a ponton rendelkezésünkre állt:

Netbeans-ben kigenerált JPA controller kód (ahogy én értettem ez ugyanaz mint a DAO pattern)
persistence.xml kitöltve a production környezethez (JNDI datasource inside)
Azt hiszem szintén generált perzisztens osztályok
Maven-es build

Feladat: A kódot teszteljük úgy, hogy használjuk fel hozzá kigenerált kódot is. Szóval sima DAO tesztelés.
A generált kód nemnyúkapiszka tárgya.

Első nekifutásra egyszerűen azt javasoltam a kollégámnak, hogy egyszerűen dobjon be egy új persistence.xml-t a teszteknek, és használja azt a tesztekből. Biztosan lehet valahogy, mert a spring és a unitils is meg tudja mondani a persistence layernek, hogy melyik persistence.xml-t használjuk fel. Mondani könnyű persze.
Párhuzamosan én is elkezdtem keresni, hogy vajon a JPA-nak hogy is kell ezt megmondani, de látványosan sehol semmit nem találtam, csak akkor nem foglalkoztam vele tovább mert persze én másik projecten vagyok és azt kell hegeszteni.

Második nekifutás: Be kellett látnunk hogy kicsit alaposabban kell foglalkozzunk a JPA kérdéssel ahhoz hogy a teszteket élesbe állítsuk. Összeültünk egy eredetileg rövidre tervezett pair programming sessionre és nekiláttunk átnézni a teszt menetet. Hamarosan kiderült hogy a spring valami nagyon hosszú tréfát használ arra, hogy a persistence.xml-t más néven keresse meg és ezt nem akartuk átmásolni tőlük, inkáb az volt az alapötlet, hogy a spring-gel inicializáltatunk egy JPA EntityManager-t és azt odaadjuk az érintett DAO objektumoknak. A JPA init ment is mint a karikacsapás, de amikor odaértünk, hogy beletömjük a DAO objektumokba az eredményt, akkor elmúlt a jókedv: a generált osztályok konstruktora inicializálta és private mezőként tartotta az EntityManagert. Azaz szépen udvariasan nem tudunk hozzányúlni. Ráadásul a kódba bele van generálva a persistence unit neve is. Ezt az egészet úgy látszik úgy találták ki, hogy a végleges környezeten kívül máshol ne lehessen futtatni. Azaz nem tesztelő-barát.

Harmadik nekifutás: Override-oljuk a konstruktort. Ja, de az ősosztály default konstruktora akkor is meghívódik. Rövid roham, fejvesztett menekülés.

Negyedik nekifutás: Jó, akkor használjuk a production-ra szánt persistence.xml-t és mielött mindezt felstartoljuk, dobjunk össze egy JNDI contextet a teszt DataSource objektummal. Ez tűnt vagy fél órán keresztül a nagy és tökéletes ördögi tervnek, én teljesen hittem a sikerben amíg a tesztbe drótoztam a spring-test csomag JNDI mock csomagját és startnál elmondtam a varázsigét is, hogy "Fuss QA!!!".... és nem működött. Azért nem, mert a spring JNDI mock csomaga pár metódust nem implementált a JNDI standardból, amit a JPA implementáció akkor is meg akart hívni. Na igen, régen használtam a spring JNDI implementációját és fogalmam nem volt a korlátairól.

Ötödik nekifutás: diplomáciai tárgyalások az ellenséggel. Ekkor kitaláltuk, hogy akkor a build eszközzel etetjük meg azt, amit a szőrös apikkal nem tudtunk. Nos a maven esetében ha két ugyanolyan nevű resource van a src/test/resources és src/main/resources alatt, akkor úgy tűnik kb véletlenszerűen fogja egyiket vagy másikat megtalálni. Nincs más választás, külön profile-ba kell tenni az éleset és a tesztet.
Ant-tal pofátlanul egyszerű lenne a junitnak odalökni egy másik classloadert. Rettenetes mellékhatások: nem futhat egy buildben a deploy és a teszt. A CI konfiguráció se lesz persze egyszerűbb.

Tanulságok:

Rájöttem hogy eddig soha nem próbáltam spring nélkül JPA apit használni
És valószinűleg ez az oka annak, hogy nem utáltam meg már az elején a JPA-t. A JEE architektúra csak kicsit lett kevésbé toldott-foldott mint a jó öreg EJB 2.1 időkben.
A generált kódoktól nagyon udvariatlan dolog, hogy ők akarják inicializálni a persistencemanagert és erről nem lehet lebeszélni őket.
A JPA-ban már az elején nem tetszett, hogy a META-INF/persistence.xml-hez ennyire ragaszkodik, de nem gondoltam, hogy nincs is szabványos megoldás ennek a felülbírálására.
A netbeans generált kódjaitól ments meg uram mintket!
Amikor ilyen kavar a kód, a maven szigorú struktúrája is akadállyá válik.

Eclipse DemoCamp frissen

2009-06-18T23:03:00.004+02:00

Ma este betértem az Eclipse DemoCamp 2009 rendezvényre, szocializálódni és telepakolni a szatyromat információkkal. A hely egy kellemes kis teázó a vár aljában, a hőmérséklet és a népsűrűség is sokkal kellemesebb volt mint tavaly. Persze nem azért, mert kevesebben voltunk :) Kicsit lassan rázódtam bele a hangulatba, inkáb már csak az első előadás után kezdtem kommunikálni emberekkel.

Előadások...

Bocsi, még mielött nekivágok... Nem próbálom hitelesen visszaadni az előadások tartalmát, az biztosan elérhető lesz majd valahol, a saját reakcióimat írnám le ide velük kapcsolatban.

Nagy Gergely: Dependency Management with Ivy and IvyDE
Demókkal megtűzdelt előadás volt arról, hogy az Ivy-t hogyan lehet fejlesztőbarátabbá tenni egy eclipse plugin segítségével. Volt is benne apróbb bug, egyszerű javítással. Ahol kicsit nekem elakadt a lélegzetem, az a repository modell volt. Miért lett ez ilyen bonyolult?
Feltettem az a kérdést, hogy ha "csak például :)" én mavent használok, de a cég egy másik csapata ivy-t és ant-ot, tudnak-e ők nekem olyan mavenes descriptort generálni a ivy dependency-kből, amivel az én mavenes projecteim tudják használni az ivy+ant kombinációval buildelt cuccot. Gergely mondta, hogy nincs ilyen megoldás és Jason hozzátette hogy igazából nem is lehet, a két project classloader rendszere teljesen más és összeegyeztethetetlen.

Kövekeztetés: a Cégen belül ha valaki ilyet használ, az nekem nem segítség. Továbbra is hímezhetem kézzel a pomokat.
Jason van Zyl: Next Generation Enterprise Builds: Maven, Mercury and Tycho
Külföldi sztárelőadóval folytatódott a build eszközök harca :)

Szóval Jason elegánsan átsiklott a maven 3.0 téma felett, ahol én meglepődtem, mert a maven 3.0-ról most hallottam elösször és nagyon érdekelt volna erről minnél több infó, de ennyit kaptunk: minden működni fog a maven 2.x-ből 3.0-on is.
A m2eclipse alias Tycho igazán meggyőző demó volt. Persze volt benne pár apróbb hiba, mint minden live demóban, de talán végre eljött az ideje, hogy beálljak a sorba és elfelejtsem az 'mvn eclipse:eclipse' parancsot. Amúgy is túl geek-es volt, windowson meg rettenetes.
A nexusról nem sok újat tudtam meg, mondjuk azon amennyire tudtam rajta tartottam a szemem. Az első pár feature requestet én dobtam be rá és igazából elégedett vagyok azzal amit kaptam ingyen :) A kérdésem az volt hogy mi az, ami kiemeli a nexus-t a maven repository managerek versenyéből. Jason alapvetően a stabilítást és a teszteltséget emelte ki, valamint hogy az archiva igazából bebukóban van.
További információmorzsa: a nexus a jsecurity-t használja azonosításra és csak 1 hét volt beintegrálni, ami jobb mint a spring-security. Volt nekem is pár problémám a spring-security-vel, de soha nem szúrtam el rá 1 hetet. A rekord egy régi grails-es projectemen volt 2 estényi gubancolás, mert akkor még a grails is gyerekcipőben járt, meg groovy-ban is az volt az első dolog amit írtam. Házi feladat: jsecurity

Félig meddig ide tartozik, és a következő blog postom arról fog szólni hogy milyen torkos szívás volt generált JPA kódra írt teszteket futtatni mavennel. Pff, a kódgenerálás a múlt század. Nekem az idl compilerek jutnak róla eszembe.
Bánfai Balázs, Török Zsolt: Transition from classroom to real-life software engineering
Nos ebből a szempontból az én karrierem - ha beszéljetünk ilyenről- nem a szokásos dolog. Soha semmi hasznosat nem tanultam iskolában főleg nem informatikáról, és bár jártam egyetemre, úgy érzem hogy -persze csak intellektuális- pofonokon kívül mást nem kaptam. Persze kell a karó a virág mellé, de hát... kéne a virág a karó mellé.
Úgyhogy erről kimentem dumálni a teázó elé, aztán pedig hazatekertem.

Köszi a szervezésért és a kajáért a B2 International-os arcoknak!

Sziasztok, boldog csütörtököt!

easyb próbakör

2009-05-29T22:49:00.005+02:00

A CÉG másik fele (nem az amelyikben én működök, hanem a gonosz fele) nagyon kedveli a fitnesse-ben írt teszteket. Az első alkalomtól kezdve nekem nem volt szimpatikus ötlet az, hogy a programomat browserből teszteljem, wiki-ben editáljam a teszteket és ráadásul összelőni a builddel is egy borzalom (ebben a legfőbb gonoszok is egyetértettek). Másoknak se jött át az ötlet. Elkezdtem hát más, kicsit elterjedtebb megoldást keresni.
Kipróbáltam mennyire tud fájni a easyb-vel történő tesztelés és megosztanám veletek:

A teszt tulajdonképpen groovy forráskód. Editálhatja az ember eclipse-ből -ha van groovy pluginja-, vagy alighanem netbeans-ből is (nem próblátam ki). Valamennyi highlight-olást kapunk hozzá, meg egy kics code-completiont-t is. Nem sokat egyikből sem.
Futtatni ezt így eclipse-ből is lehetséges, de kicsit fapados (mondjuk a fitnesse-hez képest még mindig sci-fi)
Maven-ből hajtva kicsit lassú, de rendesen fut.

A példa kimenet szerintem viszonylag jól öndokumentáló (fájjon csak az angoloknak amit csinálunk a nyelvükkel):

3 scenarios executed, but status is failure! Total failures: 1

  Story: situation

    scenario normal everyday life
      given a normal situation
      when there are some problems
      then that is just usual

Példa projectet ide pakoltam fel.

JUM 2009-05-20

2009-05-20T21:46:00.003+02:00

Ma végre összespóroltam rá időt és elhúztam a JUM találkozóra.
Ezek voltak sorrendben:

Révész Tamás: Groovy és Java használata SOA projectekben.
Cobol backend elé bármit is építeni nem lehet móka. Az előadó nem volt szerintem igazán ellazulva az előadáshoz, kapkodott, amitől nekem kicsit nehezen jött át pár infó, de megpróbálom visszaadni.
Szóval valamiért cefet sok XSLT-t kell generálniuk, néha egészen nagyokat is, és ezt automatizálták groovy-val. Utánna még kézzel meg kell igazítani (robotok sportja). Szóval csak a build processz és fejlesztés támogatásához használnak groovy-t, élesben nem fut. Gondolom nem tennék szivesen élesbe az 1600 soros scriptet.
Cursin Decurtins: Rapid prototyping with object-oriented databases
Nyilvánvalóan szívás, amikor egy project elstartolásakor napokig elbíbelődik az ember az architektúra összekalapálásán. Főleg ha csak demó vagy prototype project. Adatbázis, mapping, miegymás. Persze segít valamit, hogy ma már elterjedtek beágyazott relációs adatbázis motorok, mint a derby, de alapvetően sokkal kevesebb meló lehet, ha nem kell mappinget írni. Az objektum adatbázis egyetlen közvetlenül elérhető layer. Példaként a db4o-t mutatta be az előadó. Valóban nagyon egyszerűnek tűnik a lekérdezés, bár volt egy pár példa, ami mögött én csúnya apikat sejtettem. Standard api nincs hozzá, ami talán annyira nem fáj egy prototype-nál. Viszont a mock-os meg a fake-k miért nem jók? Production használatra a szerző nem igazán javasolta egyik terméket sem.
Szóval ha jól értettem, mitán megcsináltad az egyszerű objektum adatbázison a prototype-t, meg kell írnod relációs adatbázis kezelőre is.
Elek Márton: Amazon WS
Ez elég pöpec volt. Azt hiszem ideje végre komolyan utánnanézni a témának, bár a bankszámlám számát nem szivesen adnám meg az amazonnak. Mint kiderült az kell nekik, nekem viszont borzasztó rossz tapasztalataim vannak a netes fizetőeszközök megbízhatóságával kapcsolatban.

python kitérő

2009-05-13T18:25:00.006+02:00

Rövidebb időre átkényszerültem python használatára 3d alkalmazást kalapálni. Nem első ütközés a pythonnal (például itt egy scriptem ami Oracle[TM] MySQL dumpformátumát tömi be PostgreSQL-be... Hmm, lehet ez még hasznos lesz egyszer....), de munkában talán most használtam elösször úgy, hogy nem csak valami gyors egyszeri hegesztés, hanem élesben kell mennie és futnia, ügyfelek nézik majd az eredményeit.
És hát rendesen megszívatott a httplib-bel. Az az alapfelállás, hogy ez a progi egy queue-t polloz melóért, renderel valamit a saját kis 3D enginén és az eredményt szépen visszateszi az queue-ba. Mivel persze az eredmény egy szép nagy kép, gondoltam file uploaddal elpostolom. A probléma már itt elkezdődött, ugyanis a httplib ilyet nem tud. Az urllib sem tud, a későbbi python verziókban megtalálható ezeknek a libraryknak a 2-es verziója (httplib2, nagyon elegáns), de azok sem tudnak ilyesmit.
Valahol megtaláltam, hogy mikorra igérték ennek a javítását, de ezzel inkáb nem keltenék pánikot, nekem amúgy sem volt adott lehetőség, hogy felűbereljek kevésbé régi python verzióra.
Mindenesetre itt van egy nagyon egyszerű és működő megoldás file uploadra. Kis módosítás után már működött is, és boldog voltam hogy ezt is elfelejthetem. Érdemes még ezen a lapon megnézni hányan jöttek alternatív megoldásokkal.
Egészen addig tartott a boldogság, amíg a CI rendszer fel nem kapta a változtatásokat és ki nem próbálta. Az úgy 2-3 perc. Ami a localhoston működött, az valamiért mocsokul nem akart menni a tesztkörnyezeten, legmeglepőbb módon 404-et dobott az MQ, amikor vissza próbálta küldeni a eredményt. Eltartott egy ideig, amíg végigkotorásztam a tesztrendszer konfigurációit, nézegettem a logfilejait, míg végül már wireshark-ot rántottam, és ott is jó ideig néznem kellett míg végre észrevettem: http 1.0-át használt a file uploadhoz. A http 1.0 egy matuzsálem, nem voltak virtuális hostok benne, így az apache-nek végig fogalma sem volt hogy kinek postol a kliens progi.
Innentől még egy szép nagy kalapálás volt, mire sikerült végre rávennem, hogy http 1.1-et használjon a file uploadhoz is.
Úgyhogy a fenti linken látható alternatív megoldásokhoz hozzátenném a saját mégalternatívabb megoldásomat. Még szerencse, hogy mindent tesztelünk, a publikus tesztoldalakon már sokkal nehezebb lett volna kideríteni az igazságot.

Kiváncsi vagyok a profi python programozók ezt hogyan használják. Például a google a legnagyobb python felhasználó. Vajon nekik ez nem fájt?

Apache ftpserver próbakör...

2009-04-07T20:45:00.005+02:00

Elösször is szerintem az FTP filetransfer-es rendszerintegráció egy agyhalál, idejétmúlt, matuzsálem, őskövület, stb, de úgy tünik távoli munkatársaim egész hadai nem értenek ezzel egyet, és miután beláttam, hogy nem tudom másra rávenni őket, eltöltöttem egy kis időt káromkodással persze, aztán lekódoltam a cuccot és oda jutottam, hogy unit tesztel kellene körbetámasztgatni a dolgot. Jobb későn, mint soha :-)
És hamár unit-tesztelünk, de szép lenne ezt az egészet úgy csinálni, hogy ne kelljen neki valami ftp szerver valahol, felhasználóval, satöbbi, hanem ahogy van a project kicheckoutolás után már úgy magában is le tudja tesztelni önmagát. Arra gondoltam, hogy az ftp file-transzert kezelő kód teszteléséhez felstartolok egy beágyazott FTP servert, konkrétan a nemrég megjelent, MINA alapú Apache Ftpserver akadt a kezembe. Igazából az hogy NIO-s az ebben az esetben semmit sem ér, de a virtuális file-rendszere, "ftplet" api... szép kis cucc.

Hmm, hát tényleg beágyazható és nagyon jól megy, de a pársoros kis izé helyett 20-30 sorosra hízott inicializációt kellett írnom hozzá, ami azért szerintem sok egy tesztben. Plusz az enyémhez hozzá kell venni a filerendszer kurkászást és az azonosítási rendszer inicializációját is. Szóval kis egyszerűsítéssel szerintem jó fájdalomcsillapító lehetne.

Agyhalott AOP svájcibicska

2009-04-03T21:43:00.004+02:00

Pár AOP-os cuccom mostanában, ami szerintem egy jól működő rendszerben nem, vagy csak ritkán tudnék elképzelni...

Cache interceptor: főleg távoli metódushívások elé. Ez talán még nem olyan vészes. Egy akármilyen jcache megteszi neki, vagy egy map is. Újabban adatbázisba perzisztált map-en kisérletezek, annyi adatot kell cachelni és a backend olyan gyenge, hogy a memória + frissítgetés nem lenne jó megoldás.
Ennek még látném valami hasznát egyébként, de azért érdemes odafigyelni a példaértékűen halott spring-modules cache projectjére.
Timeout intercetor: ha a metódus nem tér vissza X idő alatt (lassú backend), akkor hagyja futni és egy bekonfigurált értéket ad vissza helyette, vagy hibát. Ezt nyilván úgy csinálja, hogy külön szálat indít neki.
re-try interceptor: Szerintem ez a legbetegebb :) Van pár dolog, ami elsőre néha nem sikerül, és ilyenkor simán lehet hogy másodszorra vagy harmadszorra igen. Talán. Szerintem ez botrány, de ez van. Ez az interceptor elkap bizonyos bekonfigurált hibákat és újrapróbálja a hívást. Például egy bankkártya művelet tipikus példa arra, hogy hol nem merném bevetni :-) Persze azok is besz@rnak hébe-hóba.
Logging interceptor: a lassan válaszoló hívásokat logolja. Nem mintha utánna tudnék javítani a lassú backendeken...

Ez így egy április elsejei bejegyzésnek is elment volna, de nem az :-)

maven release plugin

2009-03-23T06:59:00.004+01:00

Úgy egy éve áttértünk a melóban is maven-re. Igazából ennek nem holmi technikai "megvilágosodás" állt a hátterében, egyszerűen annyi, hogy a főnököm magasabb pozícióba lépett és a technikai jellegű feladatait átadta nekem, én pedig a magam módján folytattam. Bocsi ezért a kitérőért, csak a honi csillagászat fejlődéséről olvastam egy nagyon jó könyvet nemrég, ami számos helyen megemlítette, hogy a paradigmaváltásokhoz egyszerűen csak generációváltás kellett a csillagászok között is. Na, ennyit megtettem ennek a mém-nek a túléléséért.

Nemrég egy másik projecttel kapcsolatban mégiscsak kiváncsiak lettek a többiek hogy hogyan csinálok egy release-t ebből az egészből. Elkezdtem hát elmutogatni a maven release plugin hogyan működik és azt hiszem volt pár dolog amin jogosan ráncolták a homlokukat.

Ennyi, amit csinálok: mvn release:clean release:prepare release:perform

Ezt csinálja helyetted a release plugin "release:prepare":

Megnézi, hogy szinkronban vagy-e a verziókövetőddel
Igen, itt például svn parancsot akar futtatni az operációs rendszereden keresztül. A $PATH-on rajta kell legyen. Itt kezd macerássá vállni a dolog a windows felhasználóknak.
Lefuttatja a teszteket.
A pom.xml-ben módosítja a verziót akármi-SNAPSHOT-ról simán akármi-re. Ezzel a SNAPSHOT dologgal is keresztben vannak páran nálunk, én nagyon bírom. Ezután bekommitolja a pom.xml-t, és egyből létre is hoz neki egy tag-et. Azaz létrejött egy tag, amihez nem is kell hozzányúlni, hogy a pom-ban a korrekt információk benne legyenek a verziójáról és persze ay SCM tag is a megfelelő információt tartalmazza.
Átírja a pom.xml-t a legfrissebb fejlesztési verzióra és a scm url-t trunk-ra (illetve arra a branch-ra, ahol vagy) és bekommitolja. Szóval szépen elindított téged a következő verzió felé.

Majd a release:perform:

Az éppen az "elöbb" betagelt verziót kicsekooutolja a target dir alá akárhova...
A release:perform onnan tudja, hogy mi lett tagelve az elöbb, hogy hagy magának egy file-t a pom.xml mellett. Ezt a file-t a release:clean parancs törli le, ezért ezt is a biztonság kedvéért (azaz hogy ezen se kelljen gondolkodnom) a release parancs elejére oda szoktam írni, nehogy ott legyen az előző futásból és valami hülyeséget csináljak.
Lefuttatja rajta a unit-teszteket, csak hogy biztos legyen a dolgában :-)
Itt az a trükk, hogy igazából egy új mvn processzt indít el, azaz ha nincs az mvn parancs a $PATH-ban, akkor megint problémák következnek.
Amikor kész, packagel, majd a distributionManagement tag információit felhasználva bedobja a csomagot a maven repo-ba.
Ez nyilván csak egy sima deploy, nem release plugin spec a dolog, de el lehet tévedni. Például hogy ha scp-t használ az ember deploy-hoz, akkor kell neki egy scp. Windows felhasználóknak megint fejtörés, linuxon azért mindig ott van.
A szervered nevére szükség van egy server bejegyzésre a settings.xml fileodban.

Kiválló lehetőségek elcsúszásra:

első számú ok, hogy az SVN hozzáférésed nincs korrekten beállítva (nálam tipikusan a megbízhatatlan DNS szolgáltatás okozott bajokat régebben) és bár már módosította pom.xml-t, nem tudta bekommitolni. A dolog persze itt leáll, de nem csinálja ám vissza a változtatást. Ilyenkor futtatni kell egy svn revert-et a módosított file-okon.
Ha nincs a setting.xml-ben megadva a maven repod eléréséhez a jelszó.
És még egy pár dolog ami most nekem se jut eszembe :-D

Szóval a dolog legkevésbé sem golyóálló, de ha egyszer belőtted, akkor gyorsan kész lehetsz a release csomagolás unalmas feladatával, a kockázatokat és a mellékhatásokat is minimalizáltad. Ideális a release often release early gondolatvilágához. :)

Maven. Lustáknak, butáknak és nemtörődömöknek egyaránt tudom ajánlani.

A JUM-on megint nem voltam. Nagy megkönnyebbüléssel vettem tudomásul hogy nem került schedule-ra az a scrum kedvcsináló quickie, amit többen kértek tőlem, és inkáb a lemaradásaim csökkentésével foglalkoztam. Sajnos ki se látszom mostanában, például a fenti okokból.

Időközben pedig a scrum-ot kivégeztem, azaz alaposan átfaragtam a munkahelyi projectemen.

Ennyi a helyzet nálam. Boldog hétfőt, sziasztok!