Java build eszközök

Jelenleg "kisebb" projektekhez Ant-ot, "nagyobbakhoz" Maven-t használunk. Itt a "kisebb" azt jelenti, hogy a projekt outcome-ja viszonylag egyszerű, -pl. egy darab jar fájl-, valamint a függőségi gráf nem túl szövevényes. A függőségeket paraszt módon betesszük verzió kontrollba, mert ezeken a projekteken olyan emberek is dolgoznak, akik nem feltétlenül vérbeli fejlesztők és könnyebb volt így csinálni, mint elmagyarázni a Maven vagy Ivy filozófiáját. Ezek a projektek egyébként főleg kísérletezések, kódkezdemények. Halkan megsúgom hogy olyan projekt is van, amit egy DOS vagy *n*x batch script rak össze.

A nagyobb projekt ott kezdődik, ahol a függőségek mérete megabájtos nagyságrendben mérhető és/vagy az outcome-ba felfedezhető valami hierarchikus szerkezet. Pl. a webalkalmazások tipikusan ilyenek. Itt a Maven jobban bevált.

Egyébként nem vagyok sem Ant sem Maven hívő. Olyan a kettőt összehasonlítani mint a vonalzót és a tolómérőt. Mind a kettő egy eszköz, ami nagyjából ugyanarra, de mégis kicsit másra jó. Van egyébként a Blog Subject Queue-mban egy Maven firkálmány abból az időből amikor ismerkedni kezdtem vele, de hosszú lett és csapongó, nem tetszik - nem publikáltam. Az egyik JUM-mal kapcsolatban viszont egyszer írtam róla. Az egyik probléma a Maven-nel, hogy elég magas a belépési küszöb. Nem lehet lépésről lépésre megismerni. Csak akkor kezdi az ember megérteni a lényegét, ha elolvasott párszor tíz oldalt. A hivatalos weboldalon található irományok engem elég nehezen vittek közel a tudáshoz, viszont a Better Builds With Maven még mindig egy viszonylag jól összeszedett letölthető dokumentum. Háromszáz oldalas.

A javalistán lévő márciusi OSS című thread-ban felfigyeltem néhány alternatív megoldásra. Egyik a Maven-hez készülő Polyglot, ami arról szól, hogy a projekt leírót nem csak XML-ben, hanem egyéb divatos nyelveken (Scala, Groovy, Clojure, Ruby) is össze lehet rakosgatni. Ha divatos nyelvek, akkor már lehet hogy érdemesebb lenne a Gradle-be, vagy az SBT-be belenézegetni, amik nem csak skin-ek a pom.xml-re. Ezekben közös, hogy kölcsönveszik a függőségkezelést és az archetype-ok koncepcióját a Maven-től (vagy az Ivy-től), de több szabadságot próbálnak adni a projekt leírása terén.

A Gradle Groovy-ra épít. Őszintén szólva engem egy pár perces olvasgatás után nem győz meg maradéktalanul. A stackoverflow-on találtam még egy ezzel kapcsolatos kérdést és a hozzá tartozó válaszokat. (Why use Gradle instead of Ant or Maven?) Egyébként nem is tiszta teljesen, hogy ez most deklaratív vagy procedurális eszköz. Ha jól értem ugyanúgy deklaratíve task-ok közötti függőségeket kell megadni mint Ant-ban, csak a task-okon belül van procedurális végrehajtás. Nekem éppen az nem kényelmes, hogy explicite meg kell adnom, hogy egy task mitől függ.

Az SBT (Simple Build Tool) pedig Scala-ra épít. Ugyanúgy nem adja meg azt a késztetést, hogy erőt fektessek egy Ant-projektból való átlépésre vagy egy új projekt SBT-ben való elindítására. Röviden, de viszonylag körmönfontan kell leírni a build-eléshez szükséges információkat, akkor már inkább maradok az XML-nél. De a Brizzled blogban találtam egy érvelést és tapasztalatmegosztást, ami talán később vagy másnak bejön.

Akinek van ezekről -vagy más egyéb build tool-okról- tapasztalata, az kalapálja be ide a kommentekhez bátran.

JUM XIV.

Most kicsivel kevesebben voltunk mint általában, ráadásul jópár régi arcot hiányoltam. Node nézzük az előadásokat.

Brillien
A brillien.org-on elég jó írásokat lehet róla találni angolul és magyarul is, de az igazat megvallva ez nem egy könnyű téma, főleg a Session Bean-ekre beszűkült agyú embereknek. Jó volt élőben is hallani róla. Felvettem a kipróbálandó dolgok listájára, de ahogy most állok lehet hogy az amerikaiak előbb érnek a Holdra (még így is), minthogy én eljussak odáig hogy valóban foglalkozni tudok a Brillien-nel.

Elég invazív egyébként a cucc, tehát eleve olyan osztályokat kell írni, amik Brillien-specifikus ősosztályokból öröklődnek és fel vannak annotálva. Megtudhattuk még, hogy valóban működik production környezetben, mégpedig telemetikai rendszereket szolgál ki, és szimpatikus BSD licenszelésű. Állítólag teljesítményben is jó, még akkor is ha sok JSON szerializációt csinál mélyen a belsejében. Akinek van ideje próbálja ki és írjon tapasztalatokat!

TodoMap

Itt lakik a TodoMap. Kocka nagyon ráment a politikai vonalra, pedig nincs rá szükség szerintem. Engem főleg a belső megoldások érdekeltek, és ebből kaphattunk is egy hosszú listát. JQuery UI-val pl. azok a tapasztalatok ha jól értettem, hogy az alap komponenskészlet nem túl bő, plugineket kell használni. Viszont ahány plugin, annyi verziójú JQuery-re van szüksége, de csak egyet lehet használni. Tehát annyira nem lett nyerő. Az authentikációhoz az OpenId-t használja, tehát nem csinál saját juzer adatbázist. Ez a megoldás engem is érdekelne egyik projektben. No a kormányzati informatikával való összedrótozással kapcsolatban igencsak szkeptikus vagyok. Esetleg kisebb falu vagy utca nagyságú közösségeket el tudom képzelni, hogy rácuppannak, de a kormányzati informatika más szint: Vetítések, baráti kézfogások, aprópénzek, asztal mellé leeső morzsák. És akkor a végén vagy működik a dolog vagy nem. Nem is írok semmit.

SameBug

Ők pedig kivételeket gyűjtenek. Még nem tudni mi lesz belőle pontosan, mert ez egy szakdoga téma, prototípus, proof of concept. Engem mindenesetre érdekelne valami megoldás, hogy ha kiböfög a programom egy stacktrace-t, adott esetben minél értelmesebb választ tudjak találni róla a neten. Erről még biztos hallunk majd. Talán én is írok még majd róla.

Videó ezúttal nem készült, de ha többszázan őrülten keresni fogják, akkor legközelebb nagyobb hangsúlyt fektetünk rá hogy készüljön.

Scala online olvasnivalók

Néhány angol nyelvű online olvasnivaló Scala-val kapcsolatban, hogy ne Neked kelljen összevadásznod:

• Az alap 15 oldalas Scala tutorial for Java programmers, amit a Google elsőre kihoz és a letöltött disztribúcióban is megtalálható. Gyors áttekintésnek jó, de csak a felszínt karcolja.
• A Scala By Example nekem kezdésnek bejött. Az interpreteres megközelítéstől indul, azaz amikor utasításokat írunk konzolra és a Scala válaszol rájuk. Ez már mélyebben belemegy a dolgokba 145 oldalon keresztül, de még mindig hiányoznak belőle részletek. (Névtelen függvények kompakt változata, XML kezelés, kivételek, ...) Egy eléggé friss változata szintén megtalálható a disztribúcióban.
• A harmadik pdf ami lejön a scala-install.jar -ral, a Scala Language Specification, amiben viszont természetesen minden benne van, csak nem földi halandók számára érthető módon. Mindenesetre annak kiderítésére alkalmas hogy milyen funkciók vannak a nyelvben, amikkel aztán valami könnyebben emészthető forrásból meg lehet ismerkedni.
• A letöltött Scala disztróban a doc/scala-devel-doc könyvtárban akadnak példakódok és API doc is. Az API doc-ban vannak linkek a forrásra is, ami egy online SVN repóra mutat.
  
• A HUP fórumban találtam linket egy ingyenes online OReilly könyvre: Dean Wampler, Programming Scala. Sokminden benne van, de az a tapasztalatom, hogy néha (ritkán!) nincsenek teljesen kifejtve a bonyolultabb témák, főleg a különböző funkciók kombinálása terén. Érdemes letölteni lokálisra, mert eléggé lassan jönnek be az oldalai. Olvasói kommentek is vannak az online anyagban. Talán ez a legjobb a felsoroltak közül.
  
• First steps to Scala az Artimánál a kályhától indulva, valamint sok más egyéb komoly írás a Scalazine-ban.
  
• James Strachan blogbejegyzése, ami magát a nyelvet nem részletezi, de tartalmaz néhány érvet és hasznos linket.
• A Tour of Scala nem lineáris online olvasmányt is James linkjei között találtam, ami a scala-lang.org -on, a hivatalos Scala oldalon van. Ez átfutja a nyelv jellemzőit.
  
• Szintén a scala-lang.org -on található a Reference Manuals oldal, ahonnan már az előzőekben is említettem egy-két írást. Ugyanitt papírkönyvek is fel vannak tüntetve.
• Írások az IBM-nél elfoglalt java programozóknak.
• CodeCommit: Scala java-soknak, ami egész jó. Valamint Java Scala együttműködés ugyanitt.

• Topik a jhacks-on, ami egyelőre még eléggé csonk. -Ez magyar.

Más magyar nyelvű bővebb írásokkal nem találkoztam még, halott fa formátumú angol anyagokat pedig még nem vettem a kezembe eddig.

JUM XIII.

Egy-két gondolat lóhalálában szerda estéről:

Verhás Péter Maven plugin írási bemutatója engem meggyőzött. Lehet hogy Maven-ben könnyebb plugin-t írni, mint bekonfigurálni egy projektet? Amire magát a plugin-t írták - statikus weboldalak összerakása - arra én is csak akkor vetemednék ha sajátról lenne szó. Nekik ez a saját céges honlapjuk generáló motorja. A prezi.com ismét jól szuperált.

A JBoss ESB bemutatónál egy régi sztori jutott eszembe a JMS-ről, amit el is mesélek:

6-7 éves csináltunk egy szoftvert, aminek a specifikáció szerint az volt a célja, hogy megbízhatatlan kapcsolaton lógó vastag kliensek között létesítsen kapcsolatot megbízható módon. A vastag kliensek "időnként" lekapcsolódhattak a rendszerről és alapvetően naponta "néhány", "pár kilobájtos" adattömböt küldtek a szerverre, amit el kellett juttatni a címzett másik kliens(ek)nek.

JBoss-t és JMS-t választott erre az akkori architekt ember, mert skálázható, tranzakcionális stb.

Ezzel szemben az éles rendszer valódi karakterisztikája kb. a következőképpen nézett ki: A vastag kliensek nem "néha lekapcsolódtak", hanem hetente egyszer rákapcsolódtak a szerverre, de ekkor már több ezer darab, 10-200 kilobájtos adattömb várt rájuk kiküldésre. Ez persze egyenlő volt egy fejlövéssel a JBoss-nak és a JMS-nek. Kiderítettük például, hogy a JMS válaszideje nagyjából lineárisan nő attól függően hogy mennyi üzenet van a globális queue-ban. A tanulság persze az volt, hogy "a JBoss sz*r", "a jáva lassú" és megoldásként valaki újraírta az egészet mondjuk C++-ban két nap alatt, skálázhatóság és igazi tranzakcionalitás nélkül.

Ennyi a történet. Elvileg az új JMS motor, a HornetQ gyors, nem muszáj adatbázissal használni és nem feltétlenül kell hozzá appszerver. Meglátjuk.

Scala: kíváncsi vagyok hogy valójában mennyire sikerült kedvcsinálónak az előadás, vagy mik voltak a legelrettentőbb részek. Pár dolog kimaradt, de talán a lényeg átjött.

A prezik illetve a scala példakódok elérhetőek lesznek, az előadásokat pedig meg lehet nézni az Ustream-en a JUM oldalról ügyesen odanavigálva. De a felvételeket inkább csak hallani lehet, mert a vetítő képe egyáltalán nem látszik. Erre még ki kellene találni valamit. Ötletek, megoldások welcome.

Archiver wanted

Időnként backup-ot szoktam csinálni a notebook-om vinyójáról, de -hogy is mondjam- elég kezdetleges módszerrel: Simán átmásolom a partíciókat egy külső USB-s HDD-re. Illetve most már csináltam egy kezdetleges szoftvert, ami nem akad el ékezetes fájloknál (mint a windows vagy a Total Commander néha), normálisan előre összegyűjti a különbségeket amiket másolni kell, viszonylag értelmesen kiírja hogy mennyi van még hátra, nem zabálja a procit és a memóriát és tudom hogy mi van ha a művelet közben leállítom. Viszont még nagyon sok funkció hiányzik belőle. Talán érdemesebb lenne választanom a meglévő archiváló szoftverek közül, minthogy ezzel pepecselek, de semmi ingerenciám használhatatlan programokkal való szíváshoz és (un)installálgatáshoz. Megmondom őszintén, a legkevésbé kedvelt elfoglaltságaim közé tartozik Google alapján találomra letöltött programok kipróbálgatása, úgyhogy inkább megkérdezem: Tudtok jó archiváló/másolat készítő szoftvert ami teljesíti az alábbiakat?

• Fusson Windows XP-n és Vista-n, de ne akarjon nagyon beépülni a rendszerbe. Ne másszon bele a registrybe, ne indítson service-t, ne rakjon bele új menüpontokat a könyvtár explorerbe. Nem gond ha Java.
• Értelmes GUI-ja legyen, amihez nem kell pilótavizsga.
• Tudjon külső USB-s vinyóra archiválni. (Ez nem egy nagy igény.)
• Meg lehessen mondani neki, hogy mely könyvtárakat archiválja, melyeket hagyja ki.
• Természetesen támogassa az incremental backup-ot. A régi fájlokat felülírhatja, nem gond.
• Legyen nagyon reszponzív: Mindig tudjam hogy hol tart. Normálisan írja ki hogy mennyi idő és hány kilobájt van hátra a másolásból. Az sem árt ha az átviteli sebességet kiírná.
• Bármikor para nélkül le lehessen állítani. Archiválás közben is lehessen használni a gépet.
• Jó lenne ha tudna olyat, hogy eleve titkosítva írja ki az archívot, és akkor kellene egy olyan szoftverkomponens is, amivel ebbe a titkosított archívba bele tudok nézni. Ezt a szoftverkomponenst jó lenne ha nem kellene installálni, hanem akárhova bepottyantva működne. (Tipikusan az archív mellé tenném be a külső vinyóra és onnan futtatnám.)
• Ha jelszó alapú titkosítást tud már az is jó, de szuper lenne ha valami kulcsos megoldást is támogatna.
• Legyen ingyenesen letölthető, korlátozás- és köcsögségmentes.

Ezek az igényeim. Tudtok valami olyan szoftvert ami ezeket biztosítja? Vagy kénytelen leszek tovább reszelgetni a sajátot?