Jazoon or not Jazoon

Ha jól számolom 17 nap múlva kezdődik a Jazoon, ami a JavaPolis mellett a másik legnagyobb Java-s konferencia Európában. Azonban míg tavaly a munkahelyem hívott meg a TSS Symposium-ra, most ha mennék az utazást/szállást mindenképpen fizetnem kéne (a regisztrációra JUM révén lehetne kedvezmény kapni).

Úgy hogy most azon gondolkozom megérne-e nekem egy utazást egy ilyen esemény. Érdemes-e egyáltalán konferenciára járni? Mondanak ott olyat, amit nem lehet megtudni jóval előbb blog-okból és demókból (vagy utána a publikált fóliákból/videókból)?

A tapasztalatom az, hogy az ilyen eseményeken, általában általános bevezető jellegű előadásokat tartanak, ami akkor jó, ha még semmit nem hallottál a témáról, de továbbképzésnek sokkal kevésbé alkalmas. Persze nem jártam még olyan sok Java konferencián (az igazat megvalva még csak egyen voltam), nem tudom általában milyenek.

Nézzük előszőr is a programot, mire mennék el:

Első nap:

Az első előadás-körben nincs olyan, ami nagyon csábítana a pontos érkezésre. OpenID és GWT, de ezekről már túl sok előadást hallottam. A következő kör már többet ígér: szó lehet SAML-ról, amivel régóta szertnék részletesebben foglalkozni, de a buzzword gyanús Scala, Ruby, Erlang vs. Java tematikájú előadás is izgalmas lehet.

Aztán ismét nehéz választani. Jobb híján egy DSL vagy egy Comet előadásra ülnék be valószínűleg. Végül a nap zárásaként egy Swing Application Framework teljesen jó választásnak tűnik.

Második nap:

Itt már újra a bőség miatt nehéz a választás. A Parleys.com-os előadás (JavaFX, Flex, AIR) állítólag már a J1 en is nagyon jó volt, de az Agile Testing-en kívül mindegyik érdekel (Spring 2.5, JAX-RS, JBI ). Utána egy JCR 2.0 lenne a választott. Aztán megint jobb híján ülnék be a Glassfish v3 Integration Profile-ra. A következő lehet a WS-TX, és utána megint semmi. Esetleg a JavaFX vége.

Harmadik nap:

Az első két előadást azt hiszem a Grails-es duplával tudnám legkielégítőbben letudni.
A délután meg valószínű Java Puzzlers és eBay architectura lenne benne.

A választék tehát közepesen erős. És vannak még a BOF-ok, amikre azonban még mindig lehet jelentkezni, ezért semmit nem lehet róluk tudni, pedig azok még jók szoktak lenni.

Annyira azonban nem erős, hogy egyértelműen eldöntse a kérdést: megéri-e a pénzt és a fáradságot, vagy inkább vegyek ki helyette egy hét szabadságot, és csináljak meg végre néhány régen tervezett prototípust...

Toplink bug II.

Újabb szép Toplink Essentials bug vett el egy (eddig) egy napot a projektünkből. Prototípus projektet még nem sikerült csinálni, de jól reprodukálható, és ismét a leszármaztotott osztályok mint entitások körül van a gikszer, csak most a belső cache táján. A szépségét jól jelzi az, hogy ha a tesztelés két lépése között újraindítom a Glassfish-t, akkor minden megy, ha nem, akkor OptimisticLocking exceptiont kapok. Előtte mg utána csak persiste és find-van, de a find hol a szülő, hogy a gyerek entitásra keres rá.

A workaround egyelőre a Toplink level 2 cache-nek kikapcsolása:

<property name="eclipselink.cache.shared.default" value="false"/>

De most épp valami hasonló hiba néz ki a kódból, amit még nem derítettünk fel, úgyhogy lehet, hogy ez se segít. Egyébként EclipseLinke M7-tel a helyzett ugyanez. Lehet, hogy Hibernate JPA-val is ki kéne próbálni, de az meg a kissé bonyolult entitás struktúránkba hal bele (Bizonyos dolgokat annotációval, másokat XML-ből állítunk be).

WTF: Interface Equinox módra

Sajnos az OSGi nem tartalmaz szabványos interface-t a konzol szolgáltatásokra. Konzolja azonban szinte minden OSGi frameworknek van, és általában ezeket valahogy ki is lehet terjeszteni, hogy saját parancsaiddal bővítsd a rendszert.

A Felix-ben pl. a SehllSerivce-t kell implementálni:

public interface ShellService
{
    public String[] getCommands();
    public String getCommandUsage(String name);
    public String getCommandDescription(String name);
    public ServiceReference getCommandReference(String name);
    public void executeCommand(
        String commandLine, PrintStream out, PrintStream err)
        throws Exception;
}

Ez a dokumentáció nélkül is körülbelül érhető. De hogy csinálja mindezt az Equinox?

Nos előszőr is implementálni kell egy CommandProvider interface-t. Ezek után pedig minden metódus, ahol a metódusnév _-al (aláhúzással) kezdődik automatikusa a konzolból is elérhető parancs lesz. Az én konzervatív OOP-s lelkemnek ez már határeset.
Jó, jó, legyen egyszerű, de nem gányolás ez kicsit?

Java PDF2HTML

A mai nap egy régi XSL-FO-s rendszert kellett volna újraéleszteni az új környezetbe, hogy HTML-t PDF-en keresztül tegyünk szépen nyomtathatóvá.

Biztos ami biztos előtte azért körbenéztem, és azt találtam, hogy létezik egyszerűbb megoldás is. Pl. az xhtmlrenderer pont tudja ezt iText-en keresztül.

Van hozzá egy jó részletes cikk, és azt kell mondanom, hogy tényleg működik. A prototípus probléma nélkül csinálja a dolgát (pedig még némi iText varázslattal meg van bonyolítva).

Szóval eddig jó, remélem a UseCase-ek implementálása közben is ugyanilyen elégedett leszek.

JUM számvetés

Egyéves a JUM: hazánk leg Java User Group-osabb Javas rendezvénysorozata. Egy év alatt hat alkalom, 21 előadás (ha jól számoltam): a mérleg pozitív. A továbbiakhoz azonban nekem mindeképp igényem lenne egy számvetésre, hogy hol mit kéne jobban csinálni. Vitaindítónak az alábbiakban foglalom össze saját észrevételeimet.

Helyszín: erre szerintem nem lehet panasz. Krisztiánnak sikerült mindig előre pontosan mindent elintézni, csak újfent megköszönni lehet a Sztakinak a támogatást.

Lebonyolítás: itt már van mit javítani. Szerintem nagyon hiányzott alkalmanként egy moderátor aki:

1. elmondja az elején a napirendet
2. utána betartatja (ne legyen túl hosszú szünet, esetleg ne legyen egyáltalán, maradjon feszes a program)
3. Az előadásokat is moderálja, leállítja, ha nagyon túlfut az időből stb.

Valahogy úgy alakult, hogy ilyen nem volt (eleinte aki csinálhatott volna ilyet, az elő is adott, később meg nem alakult ki). Szerintem szükség volna rá, akár úgy is, hogy minden alkalommal más válalja el.

Az hogy beálltunk a kéthavonta fix időpontra az mindenképpen okos dolog volt.

Előadások: ez szerintem az egyik legfontosabb kérdés. Az eredeti elképzelés valami unconference jellegű dolog volt, ahol:

1. mindenki előadhat, aki jelentkezik
2. hangsúlyosan saját tapasztalatokról kell beszélni (vér, verejték, izzadság)

Sajnos azonban a rendszer nem vált be teljesen. Egyrészt nehéz volt jelentkezőt találni. Aztán kiderült az is, hogy ha valakinek komoly tapasztalata van egy témában, az még nem biztos, hogy jól el is tudja mondani azt. Néha még az is eszembe jut, hogy olyan emberből akit én elképzeltem, talán nincs is olyan sok.

A legfontosabb szerintem amin változtatni kell az az előadásól színvonala. Bármit is jaívtunk a többi pontnál, ha nincsenek színvonalas/profi előadásaink, akkor nem érdemes csinálni. Nem érdemes közönséget szerezni, stb.

Több út is van:

1. A JUG-ok szerte a világban általában egy hosszabb meghívott előadóval dolgoznak alkalmanként.
2. A mi eredeti célkitűzésünkhez, ami sokkal inkább unconference jellegű volt, jobban passzol a több rövidebb előadás.
3. Ennek a másik oldala a Meetup jellegű tízperces előadás, ami bizonyos esetekben adekvát lehet (ezt Kocka próbálta megjeleníteni), de egy ismeretlen technológia előnyeit, hátrányait, és a róla szerzett tapasztaltokat, szerintem nem lehet hatékonyan tíz perc alatt elmondani.

Nem látom igazán még megfelelő módszert. Volt olyan ötletem is, hogy a résztvevői, bemutató előadásokhoz kötelező legyen prototípust csinálni (Kocka legjobb előadása szerintem a legutóbbi Flex-es volt, amihez már előzőleg publikálta a prototípust). Ha van prototípus, sokkal könnyebb bemutatni, az egy biztos vezérfonal. De létezhetnek olyan elméletibb témák, amihez lehetetlen prototípust csinálni.

Szerintem azt is jó lenne, hogy ha megkeresnénk azokat a magyar fejlesztőket, akik nemzetközi OS projektekben dolgoznak, és őket meghívnánk, hogy beszéljenek a saját projektjükről (meglepően sok ilyen van).

Lehetne esetleg valami szavazás/feedback-et csinálni alkalmanként, de ha mondjuk a 20 résztvevő harmada kitölt egy kérdőívet, az már nem biztos, hogy számottevő minta.

(Itt azért megjegyezném, hogy voltak nagyon jó előadások is, és talán nem volt olyan alkalom, hogy ne lett volna olyan, ami miatt ne lett volna érdemes elmennem, de ez, úgy érzem, még kevés).

Infrastruktúra: A másik olyan pont, amit nem kezeltünk elég jól. Van egy honlap (jum.hu), de nem mindig frissült elég gyorsan. Van rajta hírlevlél, ami nem mindig ment ki időben. A fóliákat nem szedtük össze, a videók bár elkészültek, nem kerültek fel sehová, stb. Ezeken mindenképpen változtatni kell.

Marketing: Eddig azt hiszem javaforum-on, és a java listán volt hirdetve, és így körülbelül 15-20 ember jött el egy alkalomra (ritkán több, néha kevesebb). Kérdés, hogy fontos-e, hogy többen legyünk, kell-e a hirdetésre nagyobb energiákat fektetni.

• Egyrészt, ha a tapasztalatok megosztását önmagában hasznosnak tartjuk, akkor elvileg ha csak öten vagyunk az is jó.
• Másrészt ha akarunk hívni meghívott előadókat, akkor illik legalább valamennyi közönséget prezentálni. (Ajánlkozott előadó külföldről is, de 20 ember miatt talán kicsit túlzás idehívni).

Itt is lehetnek ötletek, pl. a Java fejlesztő bázissal rendelkező cégek vagy egyetemek megkeresése.

A javaslat: A következő alkalom (május 21) nem lennének Java-s előadások (itt nem részletezett szervezési okok miatt se), hanem helyette a fenti témákról lenne egy hogyantovább vita/beszélgetés/ötletelés. Ezt ugyanúgy meghirdetnénk, mint bármelyik más alkalmat (mindenki jöjjön, akit érdekel egy kicsit is a rendezvény/egy működő magyar JUG jövője). Viszont most vissza kell jelezni, mert a létszám függvényében szerzünk termet. Ha kevesen vagyunk, akkor esetleg vendéglátó ipari egység is szóbe kerül, de ott is az elején szigorú napirend szerinti megbeszélést tartunk a jövő évről. Tehát aki jönne, az íron egy levelet az info kukac jum pont hu-ra, és jövő hét elején kitaláljuk a helyszínt.

További OSGi tapasztalatok

OSGi-val való további ismerkedés keretében csináltam egy remek Jabber / XMPP OSGI kozol bundle-t. A lényege, hogy nem csak op rendsze parancssorából indított OSGi framework konzoljából pásztorolhatjuk a framework konzolját, hanem Jabberen keresztül is. (Bundle-k listázása, leállítása, stb.)

Egy érdekes dolog, hogy konzolos parancsokhoz nincs szabványos OSGi interface, ezért az összes framework külön talált rá megoldást (én eddig a Felix és az Equinox alá implementáltam a bundlet). Ebben az a szép, hogy a pluginem kódja, az Equinox és a Felix bizonyos osztályaitól is függ fordítás szinten, de futás szinten csak akkor fog ráfutni olyan kódra, ahol Felix specifikus osztályokat használok, ha létezik olyan beregisztrált service (a servicek String névre vannak regisztrálva, a létezés az osztály nélkül is ellenőrizhető). Azt kell mondjam, az OSGi koncepció működik.

Fejlesztéshez a pax-construct maven plugint használtam (Ami használja a Felix bundle plugin-t is). Viszonylag kis szívás volt vele, csak egyszer kezdtem el debugolni, de akkor is kiderült, hogy felesleges volt, a Felix bundle dokumentációját kellett volna jobban átnyálazni. A fenti Classloader-es trükhöz kell ugyanis finomhangolt Import-Package leírót gyártatni, hogy a framework függőségek csak opcionálisak legyenek.

(Zárójeles megjegyzés: amilyen csapnivaló volt a NetBeans 6.1 Beta Maven pluginje, a végleges annyira meggyőző. Pl. most már olyat is tud, hogy ha egy ismeretlen osztályt lát, akkor egy klikkre felajánlja a központi repository-ból azokat az artifactokat, amik tartalmaznak ilyen nevű osztályokat. És mivel már a Glassfish 3 TP és az OpenESB 3 fejlesztés is Maven-be megy, úgy hogy a NetBeans Maven támogatás csak jobb lesz ennél.)

Szóval jó kis játék volt, lehet hogy feltolom Google Code alá. Szinte ugyanannyi ott projektet létrehozni, mint a saját szerveren belőni SVN-t.

Testablility Explorer

A testability explorer (nem meglepő módon) egy kód tesztelhetőségét hivatott vizsgálni. Van egy publikus demó oldal is, ahol néhány OS projekt tesztelhetőségét publikálják. (pl. itt az ANT 1.7-é).

Első látásra teljesen elvarászolt, de aztán kiderült, hogy igazából semmi új, csak a Cyclomatic Compexity-t viszgálja, plusz az írható globális mezők értékét (Counts the number of fields which are globally reachable by the class under test and which are mutable.)

A Cyclomatic Compexity egy mérőszám, ami megmondja, hogy mennyi különböző lefutása lehet egy metódusnak. Ha pl. van benne egy darab if, ami vagy igen vagy nem, az már két lefutás. Minnél több lefutása lehetséges, annál nehezebb tesztelni. Nem nagy truváj, a PMD is mér ilyet. Most már inkább az érdekel, hogy hogy méri mindezt az ASM segítségével. Ha lesz időm játszanom kell majd vele egy kicsit.

(Via: Az eszközre Alex Miller bejegyzésén keresztül találtam rá amit Eugene Kuleshov BOF sessionjéről írt. )

Java One messziről

Nem tudom miért pont idén, de valahogy a JavaOne résztvevői most kattantak rá a Twitterre, és jó nagy zajjal tudósítanak is róla. Már maga az vicces, hogy ilyen commenteket olvashatok:

(stevegio): I think I'm going to avoid all javaone sessions whose descriptions begin with the letters 'JSR'

De persze a legértékesebbek a linkek, már vagy 3-4 jó independent Java blogot találtam, meg pl. egy Java-ba írt Quake implementációt.

Amúgy az még nem jött le, hogy lett volna nagy bejelentés. Állítólag ugyan van JavaFX roadmap, de még nem találtam meg.

UPDATE: Google bácsi kisegített.
Sun set forth a road map for JavaFX:

* In July, Sun will open the JavaFX Desktop SDK Early Access Program
* In the fall, JavaFX Desktop 1.0 ships.
* In the spring of 2009, the JavaFX Mobile and TV 1.0 variants will ship.

web.conf.hu 2008

Tavaly még az volt a stratégiám, hogy beüljek az összes Java-s előadásra, ez mára megváltozott. A Java-s témákról általában hallottam/tudtam már, gondoltam szétnézek a maradék részben, találok-e érdekeset.

1. Szalai Ferenc: Felhaszáló központú és föderatív azonosítási megoldások web alkalmazásokban
Ehelyett még JavaFX demókat nézhettem volna, de a szervezés ide kötött (innen szereztem laptopot). Alapvetően jól összeszedett előadás volt, bár most is felmerült bennem, hogy miért szükségszerű, hogy minden OpenID-s előadás Dick Hardt: Identity 2.0-s előadásának a stílusát akarja másolni. Ráadásul, amikor lényegi részekről volt szó, akkor vissza is váltottunk hagyományos stílusra.

Sajnos a Liberty Alliance-ről esett a legkevesebb szó, ami a leginkább érdekelt volna, de amúgy rendben volt.

2. Szentiványi Gábor: Mysql adatbázis technikák. (Még a mikroformátumok felé hajlottam, de belehallgatva a folyosóról, inkább alapozó előadásnak tűnt, nekem kicsit lassú volt).

A Mysql előadás alapvetően Mysql Enterprise/support/oktatás reklám volt. Az előadó stílusa pedig jó lett volna, de engem jobban meggyőztek volna, ha több technikai részletet hallottam volna a Mysql-ről magáról.

3. Sun open source technológiái (Zsemlye Tamás, Boros Péter) Na, gondoltam, ez lesz a másik nagy reklámos előadás, de azért jobb hiján ide ültem be, és akkor se változotak meg az elvárásaim, amikor meghallottam, hogy az előadás második felében az OpenSolarisról fogunk hallani.

Az első részben Zsemlye Tamás sorolta fel a Sun hoz kötődő OpenSource projekteket, majd átadta a a szót Boros Péternek. Kb. tudtam mi fog jönni, ZFS, Zone-ok, stb., láttam már ilyet is. És valóban fóliák helyett két konzol a kivetítőre és elindult a varázslás.

És teljesen elvarázsolt.

Semmi töketlenkedés, csak a parancsok, világosan kommentálva, hogy mi történik, komoly dramaturgiai hátérrel. A kérdéseknél a végén, meg egy jó insider felvetésre olyan precíz és pontos választ kaptunk, hogy csak ülni tudtam és élvezni a fanatizmust és hozzáértést.

Tudom, hogy web konf meg minden, de számomra mégis ez volt a legjobb előadás.

3. Grániz Ádám: Robosztus Webalkalmazás Fejlesztés F#-al Funkcionális programozás. Persze a rövid előadás időbe belezsúfolva, ezért épp csak felvillannak dolgok, számomra nem is nagyon derült ki egy világos példán, hogy mi a különbés és az OOP.

Látszott, hogy az előadó fejében mennyire bent van minden a C#-tól kezdve, viszont úgy tűnt, hogy ez a nagy tudás teljesen diszjunkt a Java világával szemben.

Egyébként a végén valami olyasmi rendszerről volt szó, mint a GWT, csak itt konkrétan egy kódba lehet írni a kliens és szerver oldalt. Meg F#, ami funkcionális, és ahogy írtam nem derült ki számomra benne a truváj, de valószínű utána kéne olvasni.

Amúgy egy kicsit olyan feelingem volt, mint amikor a JRuby és Groovy előadásokat hallgatok, hogy van a stabil nagy testvér, és az agilis ifjú titánok.

4. Varga Péter: Ajaxos fejlesztés NetBeansben jMakival Aztán még hallgattam jMaki-t is barátságból. Szép minták vannak benne, de azért nem győzött meg, hogy a GWT-nél jobb megoldás lenne.

Még elmenetben láttam, hogy a PHP, ahogy nem csináltam előadás tartalmában FastCGI és IIS szavak szerepelnek, de aztán inkább csak tekertem haza (fájós térddel, mivel odafelé csúnyán szétcsúsztam egy villamos sínen.)

Webconf

Szolgáltai közlemény: Holnap webconf, és én még egyelőre keresek olyan embert, aki ott lesz délelőtt, és egy prezentáció erejéig (meg előtte kipróbálásra) kölcsön tud adni egy laptopot, hogy vetítsek vele. OpenOffice Presentation meg Firefox kéne, esetleg az utóbbiba Firebug. (Köszi, megoldódott).

OSGi első lépések

A hétvégén volt egy rövid köröm az OSGi-vel. A tapasztalatok címszavakban.

Az apache Felix OSGi konténerével kezdtem, pöccre indul, kicsi, gyors.

Szintén a Felix Maven pluginjével buildeltem az OSGi Bundleket (=modulokat), a plugin igazából csak a Manifest-et tölti ki az OSGi specifikus adatokkal. Nem volt vele különös szívás.

Azt viszont nem sikerült megvalósítani, hogy legyen valami olyan run plugin, ami buildelés után rögtön bedeployolja és futtatja egy futó OSGi rendszerbe a lefordított modult.

Rátaláltam viszont a Pax-Runner-re. Ami szintén egy kicsi és könnyen használható tool OSGi konténer és benne egy modul indítására. Paraméterezhető, hogy melyik konténert indítsa (Felix, Equinox, Knopflerfish, első alkalmmal letölti azt, ami kell), továbbá, hogy honnan vegye a modult, amit indítani kell benne (polloz könyvtárat, leszed modult OSGi repoból, vagy akár Maven repóból). Én ez utóbbit használtam. Installoztam a Maven projectet, majd

pax-runner mvn:net.anzix.osgi/helloworld

Sajnos következő futtatáskor a pax-runner cache-t üríteni kell, hogy újra a Maven repository-ból töltse le az aktuális modult.

Kedvenc Hudson pluginjeIm

Már lassan több mint három hónapja használjuk nap mint nap a Hudson-t mint CI szervert, és továbbra is meg vagyok elégedve vele. Igazából lehet, hogy más ugyanilyen kényelmes CI szerver is van, én ezzel kezdtem, és ennél maradtam. Az egyik legnagyobb előnye, hogy jól bővíthető, van is hozzá egy rakás plugin. Mi most az alábbiakat használjuk:

• Jabber plugin, aki szól nekem rögtön, ha valami nem kóser (emelett persze emailt is küld).
• Violations plugin egyelőre csak a PMD eredményeit mutatja grafikonon (meg persze a részletes hibajegyzéket is meglehet nézni). Ha nem is olyan szép design mint a Sonar, de azért elég jól megteszi, és legalább a CI-ben vannak ezek az adatok is.
• SCP plugin: a kész artifactokat tolja fel a publikus szerverre (így egy belső gépen buildelhetünk, és az interneten kint lévőn csak az eredmény van.
• +1 Nem használjuk, de van még egy említésre méltó plugin az Emotional, ami azt a hasznos funkciót valósítja meg, hogy ha eltörik a build, akkor a Hudson logója (bajszos bácsi) nagyon mogorván néz a háttérben. KIhagyhatatlan :-)

Egyébként a harmadik pontot a Glassfish még viccesebben oldja meg. Ott van egy belső fordító gép park, és az a belső Hudson összes eredményét egy pluginon keresztül egy külső Hudson-ra nyomja ki. Öröm és boldogság.

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.