Flash vs. AJAX

Kijött a photoshop webes verziója a Photoshop Express. Persze az Adobe-tól, tehát Flash az egész. De mi miatt érdekes ez egy Java-s blogban?

A kérdés az, hogy ha legkevesebb fájdalmat akarom, hogy tudok internetről elérhető használható klienst produkálni egy backendhez. Egyrészt ott van az AJAX és az arra épülő rendszerek, mint pl. a GWT, amit most már jó ideje gyűrök. A másik, hogy kihagyjuk az egész HTML/JavaScript szívást, és az egészet meg csináljuk Flashbe (illetve itt is valami ráépülő varázslattal: OpenLászló, Flex).

Egyrészt az a kérdés, hogy melyik végterméke a gyorsabb/használhatóbb, másrészt, hogy melyik fejlesztése a kényelmesebb, használhatóbb. Az első kérdésre izgalmas a fent belinkelt Photoshop-os oldal, mert eddig még nem használtam olyan full-flash oldalt, ami bonyolultságába a Google Docs-al összemérhető lenne. (Ez összemérhető, de azt kell mondanom, hogy élményben nem jobb, nem rosszabb).

A másik kérdésre nem tudom a választ. AJAX-os megoldást viszonylag kis fájdalommal GWT-n keresztül lehet csinálni Java fejlesztő eszközökkel (+debugolás, +unit testek). De mondjuk a Flex / OpenLászló világba nem tudom milyen ennek megfelelő eszközök vannak (Ingyen, OpenSource-ért.)

Glassfish optimalizáció

Gyorsan feljegyzem magamnak, hogy miket használtam a Glassfish tunninghoz.
A két gyorstalpaló Jean-Francois Arcand-tól itt és itt olvasható. Alap trükkök csak: a -server használata, GarbageCollector és memória hangolás, és persze a poolok megnövelése. Ezek összességében olyan 15%-os teljesítmény növekedést eredményeztek nálam.

Körülbelül ugyanilyen fontos, hogy az acceptor-threads paramétert (http-listener) annyira állítsuk, ahány processzorunk van (vagy magunk). Core 2 Duo esetén pl. a 2-es érték érezhetően gyorsít, de efelett persze már nem segít.

Kellemes meglepetés az is, hogy a Sun-nak mennyire jó tunning dokuja van a glassfishez (elérhető innen). Nagyon részletes és a triviális változtatások mellett leír egész szép trükköket , még oprendszer szintűeket is.

Ez meg csak egy rövid figyelmeztetés, hogy miért ne az apache ab-vel terheljünk.

Egyébként pedig átlagos Desktop gépeket terhelve (Core2Duo 2-3G ram) egy jsp + custom tag + statless session bean + 1 db JPA query alkalmazással, kb. 1800-2200 lekérés/sec-et sikerült elérni. Statikus html ennek a 2-3 szorosáig simán felmegy. És nagyon nem is foglalkoztam sokat vele, pl. egyáltalán nem néztem meg, hogy itt az adatbázis-e a szűk keresztmetszet.

Maven + Netbeans (6.1 Beta)

Maven kellett éppen, gondoltam majd a Netbeans-ben, és automatikuasan a Netbeans 6.1 beta-t indítottam. A plugin benne is volt a hivatalos plugin repo-ban, de a telepítés után elég kiábrándító volt. Olyan alap dolgok nem működtek mint pl. az importok automatikus rendbeszedése, arról nem is szólva, hogy a Web-es Maven projekt semmit sem tudott deployolásról vagy web.xml szerkesztésről. Gondoltam is, hogy erről ennyit.

Azért biztos ami biztos kipróbáltam 6.0-val is. Ugyanúgy felugrott, de láss csodát, egész más élmény. Importok működnek pöccre, minde szép és jó, sőt a beépített Tomcat-be és Glassfishbe is zokszó nélkül deployolt. Egész használható volt az egész. Ott volt csak kis szébséghiba, aminek nem értem a nyomára, hogy a checkstyle pluginnek Netbeansben teljesen más verziója (asszem 2.0-beta6) jött le mint command line mvn-nel (2.1). És persze más default beállításokkal dolgozik a kettő.

A nagy örömre jutalmul ki is próbáltam Kocka Flex-es RPC-s prototípusát, és persze ment szépen, bár a kódban még nem volt időm elmélyülni.

Napi GWT

1. Az anonymous inner classokkal több baj is van:

• Nem szerializálhatóak GWT.RPC szerint.
• Ha egy ilyenbe egy másik anonymous innder class-t hozol létre, az életbe nem fogsz tudni bele debugolni hosted módban.

2. (vrg találmánya) Tömb rendezése nagy tömböknél iszonyat belassúl. Az a működő megoldás, ha a javascript natív sort-ot hívjuk meg. Valószínű alapból a GWT a Java SE nagyon rafinált de kicsit bonyolult megoldását próbálja javascriptre fordítani.

Challenge 24 tapasztalatok.

Tapasztalatok:

• Bámulatos mi mindent meg lehet oldani brute force-szal.
• Meglepő milyen nehéz még brute-force algoritmust is megfogalmazni, ha nem vagyunk járatosak algoritmus elméletben.
• Nem voltunk járatosok algoritmus elméletben.
• Abszolút felkészületlenek voltunk.
• Legközelebb fizikailag egy teremben leszünk, és rászánjuk az időt, hogy minden problémát jól átbeszélünk.
• Legközelebb úgy intézzük, hogy a 3 emberből ne csak 2 érjen rá az EC alatt.

Viszont egész lelkesek lettünk az algoritmus elmélet iránt, és most éppen jobbnál jobb megoldások után guglizunk, és utólag megírjuk magunknak a megoldásokat. Most pl. épp a suffix tree napi téma.

Kérdés: Vajon, ha elmélyedünk az algoritmus elméletben, akkor lesz olyan, hogy a napi munkánkban tudni fogjuk ezt használni? (Úgy mint pl. a tervezési mintákat, amik csak előbukkannak a fű alóll, itt-ott).

+1. A szervezőknek minden tisztelet. Teljesen jó volt.

Továbbra is GWT

A GWT a maga "correct level of abstraction"-jával, azért elég sok kérdést nyitva hagy. Bár lassan alakulnak a frameworkok hozzá, azért ezek még koránt sincsenek kiforva teljesen.

Nekünk most lassan 2-3 hónap projekt tapasztalat után kezdi kiforni magát a saját rendszerünk. Még 1-2 hónap és tényleg neki állhatunk újra írni az egészet, és akkor jó lesz.

A reflectionunkat pl. a gwittir-től loptuk bár egyik tanult kolegám még csavart rajta kicsit. A többi részt viszont nem használjuk belőle, mert bár nagyon jó MVC jellegű felépítése és binding-jai vannak, nekünk egy kicsit komponens alapúbb speciálisabb rendszer kellett. De kezd az látszani, hogy bár nyilván ennek is megvannak a korlátai, azért elég komoly rendszert lehet belőle építeni.

Kis színes

1. Egyrészt, még a hétvégén Sun Java System Web Server helyett Apache httpd + mod_jk + Glassfish került a szerverre. Ennek örömére rögtön fel is javítottam két régi ROME alkalmazást, és deployoltam. Ez az az napi névnapokat adja feedben. Ez pedig minden napra egy híres ember születés napját adja ki. (A születésnapokat még 5-6 éve gyűjtöttük egy barátommal abból a megfontolásból, hogy tudjuk, hogy melyik nap kire iszunk.)

2. Egy kicsit próbálom hírekkel élénkíteni a jhacks-et. Még nem tudom pontosan mi lesz belőle, mindenesetre a rövid hír jellegű postok ezentúl odamennek (Ha van valakinek jó külföldi/belföldi Java-s blog ajánlata az jöhet, mert nagyon nehéz naponta/kétnaponta értékelhető hírt összeszeni.) Aki még nem bookmarkolta a feedjet, annak ezt is csak ajánlani tudom.

3. Az utolsó pillanatban neveztünk a Challenge24-re a kollektívával. Nem tudom mi lesz belőlre, mert algoritmuselméletből elég támadható vagyok, ide meg az pl. erősen jól jön, de majd még meglátjuk. Még vasárnapig lehet nevezni.

Openfire + Pidgin

The solution: Use only the first part of your domain in the Domain field (Basic tab) eg. domain and the fully qualified domain name in the Connect Server field (Advanced tab) eg. domain.com.

Ez a fenti csak azok kedvéért, akik a gugliból jönnek a kulcsszóra. Csak, hogy ők se csalódjanak. Egyénként az Openfire nagyon kezes Jabber szerver. Letölt, elindít, és megy. (Csak arra kell vigyázni, hogy ha 8080-as porton valaki figyel, akkor a defaultból bekapcsolt HTTP bind-del összeakad). Van hozzá enterprise is, de az Open Source változat is mindent tud. Van hozzá szép webes admin felület is, kattintgatós.

Sajnos a Pidginnek egy kicsit imádkoni kellett, hogy menjen vele (lásd felül), nem volt időm még tetten érni, de vagy a Pidgin, vagy az Openfire valamelyik hash (talán MD5?) implementációja különbözik.

Hudson

Szóval ez igazán egy pazar cucc. (Egyébként egy Continous integration eszköz) Régebben (egy két éve) még a Continuum-ot nézegettem, akkor az még csak standalone-ként volt hajlandó futni nekem, és rengeteg adatbázis mütyürészést kellett véghez vinni, hogy elinduljon (azóta talán az is fejlődött). Ellenben ez csupán egy war, amit bedeployolok és megy.

Nálunk így megy: 5 percenként svn update-et nyom és ha változik valami fordít újra egy release-build-et és lefuttatja rajta a unit teszteket (Unitils rulez, ha változik a séma definíció a repositoryban, automatikusan felépít egy új adatbázist).

A Hudson-nak valami olyasmi a filozófiája, hogy én elvégzem a piszkos munkát (Ant-tal, Maven-nel, shell scripttel, bármivel), és ő az eredményt szépen megmutatja. Pl. megmondom neki, hogy az ANT task végén hol lesz az artifact, és ő azt szépen archiválja (nálunk a legutóbbi 10-et), ezek közül meg lehet jelölni bármelyiket hogy ne rotálódjon ki (tipikusan nálunk mindig a legutóbbi 10 build van fent, meg megjelölve az a régebbi, ami épp a megrendelőnél van). És persze, ha szar kerül a palacsintába, akkor email-t ír, telefonál, kárt ment, stb.

A fejlesztője nagyon nyomni akarja, ezért nagyon sűrün vannak belőle release-ek, és az egész interface kellemes hangulatot áraszt. Pl. értelmes hibaüzeneteket ír, és elmondja, hogy mikor mi a baj.

Szóval nem próbáltam végig az összes CI toolt, de ez elsőre nagyon használhatónak tűnt.

Generics + reflecion

Tegnap ígértemhez híven: a generic típusok a bytecodeban benne vannak a deklarációs részben, csak a utasításoknál nincsenek. Reflecionnal tehát lekérdezhetőek.(Pontos speckó linket most nincs időm keresni, helyette itt a példakód.)

public class Main {

    public List<Double> list;

    public static void main(String[] args) throws Exception {
        Field field = Main.class.getDeclaredField("list");
        ParameterizedType ptype = (ParameterizedType) field.getGenericType();
        Type[] types = ptype.getActualTypeArguments();
        System.out.println(types[0]);
    }
}

Toplink JPA bug

Mindig öröm, ha egy komoly termékben néhány órás szívással izolálni tudunk egy hibát, és végre kiderül, hogy nem mi voltunk a hibásak. Most az történt, hogy Joined table inheritance strategyt használtunk és left joint és a Toplink Essential a discriminator value-t inner join-nal kezelte. Magyarul nem lehet left joint csinálni, hiába írom be a querybe.. Ki próbáltam Hibernate JPA-val is (ugye milyen jó, hogy hipp-hopp váltogatni lehet a providerek között?), és azzal rendesen ment.

Akkor most bugreport és native queryk használata a bugfixig.

Unitils tapasztalatok

Régóta nem írtam már ide, pedig jócskán felgyűltek a témák. Az egyik ilyen az Unitils bevezetése az egyik projektünkbe. Az Unitilsnek Kocka egyik blogbejegyzése nyomán kezdem utána nézni.

Az Unitils a Junit3,Junit4 és a TestNG keretrendszerek mindegyikével házasítható, ezeknek a teszt környezeteknek funkcióihoz adnak hozzá a moduljai. A Unitils moduláris felépítésű, mi három modulját használjuk:

database
A database modul egy adott környvtárban található sql szkripteket sasolja. Ha valami is vátozik, akkor az adatbázis teljes sémáját bedarálja, és újra futtatja a szkripteket. Nagyon praktikus olyankor, amikor a sémát SVN-be tároljuk, de többen is szerkesztgetjük.

dbunit
Ez igazából a dbunit-ra egy wrapper modul. a @DataSet és @ExpectedDataSet annotációkkal jelölhetjük meg a teszteinket, és ezekkel adhatnk meg egyszerű XML-eket, amikben a teszthez szükséges adatbázis tartalom van. Pl.

ServiceOneTest.xml
<dataset>
<customer id="1" name="asd">
</dataset>

ServiceOneTest.testOne-result.xml
<dataset>
<customer id="1" name="changed">
</dataset>

Elég kényelmes dolog, de van egy fontos tulajdonsága. Az előző modul a séma létrehozása után alapból az összes constraint-et disabled-re állítja. Ez egyfelől kényelmes, mert az XML-ekben tényleg csak azt az adatot kell beleírni, amit tesztelünk (esetünkben a customer name tulajdonságát), és pl. a company mezőt nem, mégha elvileg foreign key lenne is rá. Persze ez azt is jelenti, hogy a constraint-eket ilyenkor nem teszteljük.
(Megadhatjuk azonban azt is, hogy a constraintek maradjanak).

ejb3
Ez a harmadik modul amit használunk, saját fejlesztés (nagyon egyszerű új modulokkal kiegészíteni a Unitils-t). Ha talál egy @EJB annotacíót a unit tesztünkbe, akkor oda injektálja az EJB-t, és az EJB-be is ellenőrzi az annotációkat és oda is injektál mindent (pl. EntityManager). Nagyon kényelmes, mert gyakorlatilag az egész EJB oldalt standalone unit tesztekkel tudjuk tesztelni. Ha igény van rá, talán majd publikáljuk is.

Ezenkívül van még Spring, Hibernate és EasyMock-ot támogató modulja is, azokat mi nem használtuk. Viszont standalone alkalmazáshoz is viszonylag kis fájdalommal hozzá lehetett gyógyítani (egy migráló szkript használja a Unitils database modulját arra, hogy ő is mindig az aktuális adatbázis sémán dolgozzon). A forrása is szép, mindenütt interface-k vannak, sok helyen lehet változtatni az implementációt.

Nyilván ezzel is előfordulnak szívások, de összességében csak ajánlani tudom. Használata Junit 4.4-től csak annyi, hogy a tesztet meg kell annotálni egy @RunWith(UnitilsJUnit4TestClassRunner.class) annotációval.

Java 7 újdonság szavazás

A Whiteboard játék úgy néz ki, hogy kitesznek a konferencia előterében néhány táblát, amin néhány kedvcsináló kérdés van, és aztán mindenki firkál oda. A TSSJS Europe-on, ahol voltam nyáron, ott három ilyen tábla volt, és a közönség nem is nagyon kapott rá. A JavaPolis-on a fotó alapján más a helyzet. (De majd Kocka remélem beszámol részletesen is).

Az egyik ilyen táblázaton a Java 7 néhány javasolt nyelvi újdonságára lehette szavazni, az eredmények itt. Vicces végignézni, hogy milyen vad dolgokat találnak ki, és néha milyen bután szavaznak az emberek egész értelmes ötletekre. Mintha mindenki rákapott volna, hogy Java7 proposalokat csináljon. Mindegy, felőlem jöhet akármi, de a nulláról Java-t tanulók dolga egyre nehezebb lesz.

JSPWiki

Vegyesek az érzéseim:

Egyrészt iit van a XXI. század hajnalán egy alkalmazás, ami ha nem is csupán JSP-be van írva, de azért úgy tűnik (a kódba nem néztem bele) elmegy minden mellett ami manapság divatos (ORM, Component Based Web Frameworks, stb.), alapból pl. fájlrendszerbe tárolja az adatokat. Tomcat6/Java6-ra telepítés közben elszáll, és mindenféle hekkeléssel lehet csak életet lehelni bele (a legutolsó log4j1.3alpha kell neki, és a properties fájlba a dir-eket be kell állítani.).

Másrészt meglepően kényelmesen és gyorsan lehet használni: mi most egy projekt belső dokumentumait írjuk rajta, és nagyon jól megy. Ráadásul jól kiterjeszthető, pluginelhető, elvileg kis munkával nagyon jó projekt kezdőlapot lehetne fabrikálni benne, ahol együtt látszódnak az aznapi SVN commit-ok és a Bugzillába felvitt tételek. Kiterjeszthető a mögötte lévő tárolási eljárás is, pl. SVN-t is tud használni elvileg perzisztens tárolónak. Ha meg nem akarunk semmi extrát, akkor (ha sikerült deployolni) onnantól tényleg zero config.

GWT widget library

A GWT-hez keresek csilli-villi Widget készletet, ami könnyen kezelhető, és főleg nagyon szép, úgy hogy ha a megrendelő megnézi higyje azt, hogy valami nagyon profi oldalt lát.

Első körben a MyGWT-re és a GWT-EXT-re találtam rá. A demója mindkettőnek (mygwt, gwt-ext) nagyon hasonló. Gugli barátunk viszont azt mondta, hogy a gwt-ext csak egy wrapper csomag, ami natív hívásokkal az ext.js nevű függvénykönyvtárat hívogatja, a MyGWT viszont full Java-ban implementált (és GWT-vel js-re fordított) csoda. Ráadásul a MyGWT-ben vannak olyan containerek (pl. WidgetContainer), amik a Swing-ben megszokott Layout-okat is tudják kezelni, és ezek alapvatően sima Widget leszármazotta, úgy hogy elvileg sima GWT kóddal is jól integrálhatóak.

Szóval egyelőre MyGWT-re áll a zászló, megpróbálom integrálni, és megáltom mi lesz belőle.

Java Café I.

Szóval ott voltam ma délelőtt. Tehát---

Előszőr is a disclaimer: rendszeres és lelkes látogatója vagyok a JUM-nak, ami szintén egy hasonló elvek mentén szerveződő, viszont alulról jövő megmozdulás, tehát akaratlanul is hozzá hasonlítom. Például rögtön első látásra is látszott, hogy a rendezés a szokásos Sun Tech Day-es színvolalon zajolott: elegáns terem, büfé, jegyzetfüzet, toll stb. Körülbelül 40-50 résztvető lehetett becsléseim szerint (mivel volt regisztráció a Sun biztos pontosabb számokat is tud). Az elhangzó kérdésekből úgy tűnt, hogy ezek egy része (mondjuk 10-20 fő) tényleg fejlesztő munkás, és nem csak a managerek jöttek el.

Az előadást Molnár István tartotta, egy szabadon elérhető prezentáció mentén. A szünetig viszonylag általános alapvetés volt (mi is az alkalmazás szerver, miért olyan fasza a Glassfish stb), ezen a részen én egy kicsit bóbiskoltam, (vegyük számításba, hogy az alapvetés engem már kevésbé hoz lázba, illetve, hogy 3 órát aludtam éjjel.) A szünet után már kicsit részletesebb infók is voltak, meg egy hosszabb demó, hogy hogyan is működik a clusterezés. Ez már elég jó volt, már régóta ki akartam próbálni, hogy feltelepítek egy clustert, de valahogy sose volt rá idő, és Molnár István tényleg élvezhetően és profin vezette az előadást, és szolíd marketing mellett sok technikai részlet is elhangzott. Teljesen rendben volt.

A bevezetőből megtudtuk, hogy tényleg egy hosszabb rendezvénysorozatra készülnek, és előreláthatóan továbbra is Sun-os OS termékekről lesz szó (JAX-WS, OpenESB, NetBeans).

Szóval volt, aki rögtön a JUM-hoz hasonlította, ahol persze nincs büfé, nincs póló osztás, és talán az előadók se mind olyan profik és rutinosak mint itt, de valahogy én mégsem érzem, hogy ezeknek most egymás ellen kéne versengeniük. Az egyik ugye délelőtt van munkaidőben, ahová a talpasok csak bonyolult elkéredzkedés útján juthatnak el, a másik meg este, bizonyos pozíciótól felfelé valószínűleg már kevésbé áldozzák fel a szabadidejüket rá az emberek. Viszont szakmaiság azért itt is ott is megtalálható, ehhez az egyik helyen egy felülről jövő céges íz, a másik helyen egy alúról jövő néha kissé amatőr/civil felhang jön hozzá.

Szóval én örülök, hogy újabb alkalom van, ahol Java-ról esik szó, a szakmai színvonalra nem lehet panasz, és látszik, hogy a Sun is tényleg komolyan gondolja. Várom a következő részeket.

Highlight autoboxing

Annó még egy régi interjún nyomták kezemben ezt a kérdést: Milyen i és j értéket tudnál beállítani, hogy végtelen ciklust csinálj:

while (i <= j && j <= i && i!= j) { ... }

A kérdés persze annyira nem bonyolult annak, aki hallott már az autoboxingról, és talán az interjúztató még hintelt is, hogy 1.5-ös Java-ról van szó. Most is csak azért jutott eszembe, mert a NetBeans hírlevél kiemelte ezt a NetBeans plugint, és én meg elgondolkoztam, hogy talán tényleg nem teljesen haszontalan valami szolid highlight-tal jelölni az Unboxing/Boxing eseteket. Különben is egyre szinesebb az IDE-m, szinte öröm leülni elé, akkor már had legyen benne ez is.

ps: a rejtvény egyébként a 2006-is JavaOne TODAY című újságjában jelent meg Neal Gafter and Joshua Bloch cikkében, akik a Java Puzzlers-nek is az írói. A cikk részleteiben és megoldás magyarázattal itt.

ProGuard

Úgy esett, hogy hirtelen java obfuscator kellett volna, és a gugli a ProGuard-ot ajánlott. Teljesen korrekt ajánlat volt.

Az alap obfusator opciók mellett kódot is optimalizál és tömörít is. Hívható ANT taskból, van egy kedves gui felület-e is, ahol az opciókat bizergálhatjuk, majd a beállításokat egy config filbe menthetjük. Tartalmaz egy csomó példát, pl. hogy hogyan lehet egyszerűen megoldani, hogy az obfuscálásból kimaradó osztályokat (pl. public api) annotációkkal adjuk meg, vagy hogy hogyan vegyük a változók neveit a Shakespear összesből. A GUI továbbá tartalmaz egy kedves eszközt, amivel config alapján a stacktrace-t visszaalakítja emberileg olvashatóvá.

Szóval mégcsak egy órája játszok vele, de minden szempontból úri cuccnak tűnik. (Most éppen azt játszom, hogy az Android decompilolásnál is bevált JAD decompilerrel fordítgatom vissza az obfuscált kódot.)

Android a házban

Talán már több mint egy hete jelentte be a Google az Android-ot, ami egy ingyenes mobil platform lesz. (Előtte már régóta találgattak GPhone-ról, de kiderült, hogy hardvert ők nem, csak OP-t csinálnak).

Viszont mától le is tölthető az SDK innen.

Ami miatt lázba jöttem tőle, hogy az SDK full Java alakúnak tűnik. Még nem nagyon szórakoztam vele, de vagy Eclipse pluginnel vagy ant-tal lehet buildelni, van hozzá egy emulator, elég korrekt rendszernek tűnik. Szép Java API. Majd jönnek részletek.

Elhavazva (TopLink kapcsolók)

(Lassan már álmomban is implementálok, de van remény, nem sokára enyhűlni fog a helyzet. És akkor majd...)

Itt viszont egy remek összefoglaló a Toplink JPA suttyom kapcsolóiról. Persze egy része Oracle specifikus, olyan annotációkat meg mégsem akarhatunk látni tiszta JPA forrásban, de egy másik rész pedig szép kiterjesztés, ami kifejezetten belefér a JPA-ba. Pl. vannak plusz propertyk a persistence.xml-be, amik kiloggolják az SQL lekéréseket, vagy hogy induláskor nem az adatbázisba rakja újra a táblákat, hanem elmenti a CREATE SQL parancsokat egy DLL szkriptbe bárhová.

Ha minden jól megy, most úgy is alkalmam lesz mélyebben megismerni a TopLink lelkivilágát.