JUM IV.

20-30 fős társaság gyűlt össze a novemberi paláveren. Szerintem ez nem kevés, illetve nem lenne rossz, ha a következőn is lennének ennyien. Érdemes eljönni, nem messze van a Lehel tértől. Bp-n, persze.

Android: Rövid, pörgős előadást terveztem, éppen ezért kissé felületes lett. A végén a kérdezős-vitázós-beszélgetős részben viszont elhangzottak azok a fontos részletek is (mástól), amelyek a prezentációba nem kerültek bele. Az előző postban már sokmindent leírtam az Androidos témával kapcsolatban, de még annyi, hogy Midorinál is van néhány hasznos link. A decemberi Budapest Tech Meetup-on pedig szintén lesz egy előadás erről a csodáról.

Glassfish: Megtudhattam, hogy a GF a szabványt maximálisan követő appszerver a JBoss-sal és egyebekkel ellentétben. (A JBoss nem kapta meg a minősítést.) Kommerciális verziója a Sun Java System Application Server. Szép és ingyenes, JSF-en alapuló management konzolja van. Még nem a GFv2, hanem csak a GFv3 lesz a mikrokerneles, gyorsan induló változat. Elhangzott, hogy mégis elég sok helyen JBoss-t használnak. Mi is, viszont én szívesen kipróbálnám a GF-et fejlesztésre. Nem tudom, hogy támogatja-e a következő dolgokat:

• robbantott ear és war fájlok hot deployolása.
• van egy log4j.xml amit szerkesztgetve könnyen befolyásolható a loggolás.

(Tipp: nyilván tudja ezeket.)
Ennyi nagyjából elég is lenne a fejlesztéshez. Az előadás közben elgondolkodtam rajta, hogy mennyire más igények merülnek fel fejlesztés és üzemeltetés közben. Fejlesztés közben nem érdekel a fürtözhetőség, a grafikus konzol felület, hanem inkább az, hogy az iterációs körök minél rövidebbek legyenek. Erre nagy segítség, ha nem kell becsomagolni az ear-t, (hogy az appszerver aztán kicsomagolja magának egy munkakönyvtárba). Esetleg az appszerver csak a valóban megváltoztatott komponenseket nyalja fel újra. Ez még akár azt is jelentheti, hogy a fejlesztés közben nem kell kilépnünk a webes vagy egyéb kliens alkalmazásból, mert megmaradnak a session-ök. Ha jól értettem a Glassfish-Netbeans páros nagyon szépen tudja ezt. Nem hátrány az sem, ha a szervert lehet rángatni Ant taskokkal.

MDA: Azt hittem, hogy az AndroMDA -ban benne foglaltatik az UML diagramok megrajzolása is, de nem. Arról van szó, hogy szabványos UML rajzoló eszközzel megrajzolunk valamit, amiből ez a program különféle sémák alapján legenerálja a programkódot. Sémákat (vagy cartridge-eket) mi is gyárthatunk (Velocity ), viszont mindenkinek megvannak a saját jól bejáratott sémái a fiókjában, amit nem oszt meg másokkal. Mint kiderült, kevés a jó és szabványos UML generáló eszköz. Felmerült az OmondoUML Eclipse plugin, amivel már régen találkoztam, de annó annyira nem tett rám mély benyomást, hogy huzamosabb ideig használjam. Az AndroMDA végső soron egy konzolos eszköz, amit Maven -nel lehet működtetni. A kódgenerálás utáni változtatások itt is problémát jelentenek, mint mindenhol. Ha átírjuk a kódot, ő új kódgenerálás után szépen felülírja. Persze vannak olyan részek, amiket elvileg nem ír felül. Java mellett bármilyen nyelvre tud fordítani, ami a sémáktól függ -ennyivel több az integrált eszközöknél. Eclipse-szel, Hibernate-tel és JBoss-sal a legérdemesebb használni de a demó során éppen Netbeans-Glassfish-Toplink(?) használatot láthattunk -akadtak is emiatt kisebb gondok. A javakocsma, avagy a javaforum2.0 is ezzel az eszközzel és az imént említett technológiákkal készül. (A Glassfish-nek gondot okoz a javaforum2.0.ear fájlnév.) Az a véleményem is megerősödött, hogy hatékony UML szerkesztéshez iszonyat nagy monitor kell.

Szóba jött még, hogy mi itt egymás között szépen pajzsra emeljük a szimpatikus java-s eszközöket, miközben a "nagyok" hazai terjesztői többnyire arra törekszenek az általuk avanzsált termékek népszerűsítésénél, hogy minél kevesebb munkabefektetéssel megszabaduljanak a feladattól -legalábbis néha úgy tűnik.