2007-12-21

C# delegate-ek


Év vége előtti vincseszter-gyomtalanításnál találtam egy fájlot, amibe a C# delegate-jairól véstem fel pár gondolatot valamikor. Egyébként kicsit bánom hogy nem mentem a Javapolisra. Legközelebb -főleg ha ilyen lehetőség lesz- az asztalra csapok, félreteszem az aktuális (sz*rból kihúzandó) projektet és megcsinálom amit akarok.



A delegate a C-ben és C++-ban megszokott függvénypointerekre hasonlít legjobban.
Magának a szónak a jelentése: kiküldött követ, meghatalmazott, képviselő.



A delegate egy olyan adatstruktúra ami egy vagy több metódusra mutat, példánymetódusok esetében egyben az azokhoz tartozó objektumokra is. Mondhatnánk azt is, hogy a delegate, mint deklaráció egy metódus szignatúráját írja le. Azokkal a metódusokkal kompatibilis, amelyeknek a paraméterlistája és a visszatérési értéke megegyezik a delegate paraméterlistájával és visszatérési értékével.


Delegate-t így kell deklarálni:


delegate int op(int a, int b);


Ha osztályon kívül deklaráljuk akkor a namespace-n belül lehet elérni, de ha osztályon belül deklaráljuk (static kulcszó nem megengedett), akkor az osztály nevén keresztül kell hivatkozni rá. Ilyenkor tehát a delegate nem a példányhoz hanem az osztályhoz tartozik.


A delegate a System.Delegate osztályból származik, viszont ezt az öröklődést csak a rendszer és a compiler-ek használják, mert maga az osztály sealed, tehát a programozáskor mi csak a delegate kulcsszóval találkozunk.


Delegate példányosítása a következőképpen történik:


op x = new op(add);


Ahol az add metódusnak kompatibilisnak kell lennie a delegate-tel, különben fordítási hiba jelentkezik.


Egy delegate-hez újabb metódusokat is hozzá lehet adni:


x += new op(sub);

x = new op(add) + new op(sub);


stb. Ha új értéket rendelünk a delegate-hez, a régi elveszik, mint a referenciáknál megszokott.



A delegate meghívása egyszerűen így történik:


x(1, 2);


Ilyenkor az összes metódus végrehajtódik szépen sorban szinkronban ugyanazokkal a paraméterekkel. Ha egyik metódus változtat valamit, azt a változást a sorban utána következo metódusok mind látni fogják. A legutolsó visszatérési érték fogja képezni a delegate visszatérési értékét. Ha exception következik be a hívások során és az nincs elkapva a híváslistában meghívott metódusban, akkor ez az exception a delegate-et hívó kódban fog jelentkezni, mintha a delegate hívása során keletkezett volna. Az exception keletkezése után a híváslistában szereplő többi metódus nem kerül meghívásra.



A delegate-bol el is lehet venni metódusokat a - és a -= operátorral. Ha olyan metódust próbálunk elvenni belőle ami előzőleg nem volt benne, nem történik változás.


Delegate-ek összehasonlítása



A delegate-ekre alkalmazható az egyenlőséget ill. az egyenlőtlenséget vizsgáló összehasonlító operátor (==,!=). Két delegate példány egyenlőnek tekinthető, ha mindkettő értéke null, vagy egyenlő híváslistával bírnak, tehát a híváslistákban szereplő metódusok ugyanazokra a statikus metódusokra és ugyanazon objektumpéldányok ugyanazon metódusaira mutatnak ugyanabban a sorrendben a két delegate esetében. A delegate-ek típusa nem számít, tehát két különböző típusú delegate (amik persze ugyanazt a szignatúrát képviselik) lehet egyenlő.


Event-ek



A delegate int op(int a, int b) tehát egy delegate-nek a deklarációja és már látható volt, hogyan lehet lokális változóként létrehozni. (Miért van külön event, ezt nem értem...)


public event Click EventHandler;


Így néz ki tehát egy event deklarációja. Az event kulcsszó, aztán az esemény neve (érdemes valami igeként elnevezni) aztán a típusa. Így egy delegate típus könnyen hozzárendelhető többféle eseményhez.


A delegate-ek és event-ek kiválóan használhatóak eseménykezelésre, ahogy ez meg is van valósítva a System.EventHandler esetében. Egy gombhoz például a következőképpen rendelhetünk egy eseménykezelőt:


button.Click += new EventHandler(this.buttonClick);


Ahol a Click egy event amihez EventHandler típusú metódusokat lehet kapcsolni. Az osztályon belül így történik az eseménykezelő hívása:


Click(this, null);


A megfelelő paraméterekkel természetesen.


Java vs. .net



A java 1.4-gyel szemben gyakorlatilag beépítették a nyelvbe az eseménykezelést. A jávás megoldásnak több hátránya is van a C#-hoz képest:


  • Meg kell írni vagy örökölni kell valahonnan a listenereket kezelő metódusokat. (add, remove, notify) Az örökléssel az a probléma hogy kizárja a máshonnan való öröklést, a logika megírása pedig a plusz hibalehetőségekkel járó ujjgyakorlat. Elvileg lehet írni egyedi implementációkat (pl. Chain of Responsibility), de az alkalmazott listener minta nem egy olyan dolog amit túlzottan meg lehetne fűszerezni.

  • C#-ban meg lehet csinálni, hogy az eseménykezelő metódusok nem ugyanabban az osztályban foglalnak helyet. A java-ban a Listener interfészek csokorba gyűjtik a metódusokat, amiket egy adott osztálynak implementálnia kell. (Billentyűeseményeknél lehet hogy csak a leütésre akarok figyelni, de az alkalmazandó interfész miatt a felengedésre is meg kell csinálnom az üres metódust.) Erre be is vezették az Adapter-osztályokat, amikben eleve benne van az összes metódus üres törzzsel, de ezek szintén öröklődést igényelnek.

  • Kissé antipattern az a megoldás, hogy egy meglévő -valamilyen célra már felhasznált osztályt- hirtelen kiegészítünk valami Listener logikával, mert éppen kell. Pl. public class MyForm extends JPanel implements ActionListener. Így az osztályban definiált public void actionPerformed(ActionEvent) metódust boldog boldogtalan hívogathatja. C#-ban egyszerűen lehet csinálni olyan eseménykezelő metódusokat amelyek az adott osztályon kívülről nem hozzáférhetőek. Ehhez jávában befoglalt osztályok kellenek, amik persze hosszabb távon egész jól megszokhatóak.

  • Már meglévő osztályok metódusait is fel lehet használni, anélkül hogy bele kellene nyúlnunk a kódjukba és implementálnunk kellene mégegy interfészt. Ezt java-ban wrapper osztállyal lehet megvalósítani, ami delegálja a metódushívást.


A fentiek ellenére nem hiányolom a delegate-eket a java-ból, főleg a hozzáadásos, összehasonlításos dolgait. Gyakorlatilag kis kerülőúttal mindent meg lehet oldani delegate-ek nélkül, ezenkívül több kérdést felvet, mint amennyit megold.



Mire jó még?



Kb. ugyanarra mint a C-s, függvénypointerek, tehát callback függvények megjelölésére, függvénytáblák létrehozására, stb. Egy példa függvénytábla létrehozására és használatára:


public op[] operations = new operations[10];

...

op[0] = new op(add);

...

operations[0](2, 3);

2007-12-06

Bp nt mUp, December

Csak röviden tegnap estéről:

Simon - Humanoid Robot, Pécskai Balázs (logintsys)


A srác egy humanoid roboton dolgozgat pár éve. Először ablaktörlő motorokkal építette, majd szervómotorokkal, amik még mindig nem elég erősek (pl. nem triviális hogy a robot fel tud-e állni). Delphi-ben programozza és egy külső PC-ről irányítja. Egyelőre csak vezérlése van, nem beszélünk szabályozásról. (Nincs visszacsatolás.) A statikus járás az amikor előre minden ki van számolva, a dinamikus pedig amikor mozgás közben derülnek ki dolgok. Vagy talán a statikus járás az, amikor a mozgás minden pillanatában a robot statikus egyensúlyi helyzetben van? Ott ült a robot statikusan mikulás sapkában. Elvileg az előadások után mozgott is, de addigra már eljöttem.

Google Android, Kis Gergely (EU Edge)

Főleg a Linux szemszögéből foglalkoztak a témával. Annyival lettem okosabb, hogy az SDK-ban található emulátor hardvert emulál (biztos azért ilyen lassú) és emiatt viszonylag jó közelítést ad a valós hardverekhez. Láthattunk képen egy eszközt, amin valóban fut az Android.

Keressük a peer-t a szénakazalban, Tóth Benedek

A P2P hálózatok lelkivilágát érintette az előadó, de ennyibe nagyon kevés fér bele. Főleg a fájlcserélőkről volt szó. Vannak "node"-ok vagy pedig a szomszédaikat ismerik a kliensek.

Milenia Grafter - a 64 kilobyteos flash media server, Tóth Milán (milgra.com)

Flash animációk kiszolgálására alkalmas szerver jávában, 64k-ban. Megkérdeztem volna, hogy obfuszkálva-e ennyi és NIO-t használ-e, de végülis nem kérdeztem. A tippem: nem, igen. Közben elgondolkodtam hogy mennyivel fizetnék többet, hogy ha egy szerver alkalmazás 6.4mega helyett 64k lenne. Valószínűleg semennyivel. Továbbá nagy különbség, hogy valamit nem kell, vagy nem lehet konfigurálni. Megcsodálhattuk a MacBook grafikai lehetőségeit.

Bölcsészettudomány Informatikai Önálló Program, Vaskó Péter

Kicsit messziről indulva a szemantikus webnél kötöttünk ki. Dolgoznak egy megvalósításon, amivel január környékén fognak jelentkezni élőben, erről láthattunk egy 1 percet demót. Jó kis sodró előadás volt. (iGlue a projekt neve ha jól értelmeztem.)

A hacker kép alakulása Nick Haflingertől Neo-ig, Szedlák Ádám

Mielőtt napi 8-12 órát ültem gép előtt, már akkor is próbáltam úgy válogatni az elolvasandó könyveimet, hogy minél kevesebb szó legyen benne számítógépről, kibertérről, ezért igencsak műveletlen vagyok a műfajban. A srác szakdolgozatának ez a témája, úgyhogy ha egyszer publikus lesz, biztos sokan elolvassák majd.

A buzzword bingót nem követtem, de szépen csendben elvitték az 5 pólót.
Ikszelgetés helyett inkább forraltboroztam.

2007-12-02

JUnit 4

Haladni kell a korral (illetve nem szabad lemaradni), úgyhogy átnézegettem a JUnit 4 dolgait. Íme két hasznos olvasmány a témában -egyik az IBM-nél, másik DevX-en. A JUnit 4.X alapvetően a JUnit 3.X továbbgondolása olyan formában, ami a JDK5-ös új feature-jeit jól kihasználja. Jelenleg a 4.4-es verziónál tart, a www.junit.org -ról pedig letölthető (158kbyte a jar forrás nélkül). Mi változott?

  • Legalább 5-ös Java kell hozzá (bármilyen meglepő).
  • A package megváltozott junit.framework-ről org.junit-ra.
  • @Test annotációk használata névkonvenciók helyett. Továbbra is publicnak ill. void-nak kell lennie a visszatérési értékének és nem lehetnek paraméterei. Ha ezt nem tartjuk be, az alábbi kivételekre számíthatunk:
    java.lang.Exception: Method xxx should have no parameters
    java.lang.Exception: Method xxx should be void

  • Statikus import használata: import static org.junit.Assert.assertEquals; Így a kódban Assert.assertEquals(...); helyett írhatunk assertEquals(...);-t. (Persze JUnit 3.8-nál is használhatjuk a statikus import funkciót, ha 5-ös Javank van.)
  • Nem kell kiterjeszteni a TestCase osztályt, így lehetőve válik a protected metódusok tesztelése azáltal, hogy a teszt-osztállyal a tesztelendő osztályt terjesztjük ki.
  • setUp() metódus helyett a @Before annotációt használjuk, akár többet is. Kérdés hogy ezek milyen sorrendben hajtódnak végre - erre a sorrendre nincs explicit szabály, ezért véletlenszerűnek vehető.
  • A tearDown() párja pedig az @After, amiből szintén lehet több.
  • Ősosztályokban nem kell explicite meghívni a setUp()==@Before illetve tearDown()==@After metódusokat, mert azok hívása automatikusan történik: Először az ősosztályban lévő @Before-k hívódnak, aztán a leszármazott osztályokon belüliek. @After-nél pont fordítva, először a leszármazottaké, majd az ősosztályban lévők.
  • A @Before és @After minden teszteset előtt és után hívódik, akárcsak a setUp() és tearDown(). Lehetőség van @BeforeClass és @AfterClass metódusok megadására, amelyek az osztályban lévő összes teszteset előtt illetve után hívódnak meg. Ilyen feature JUnit 3.X-ben nincs.
  • Ha egy osztályban nincs egyetlen @Test annotáció sem, hibát fogunk kapni.
  • JUnit 3.X-ben a kivételek ellenőrzése úgy történt, hogy a catch blokkba beírtunk egy assert-et. Itt az annotációba írhatjuk be, hogy milyen kivételt várunk: @Test(expected=ArithmeticException.class). Ha nem dobódik kivétel, vagy más kivétel dobódik, a teszt elbukik. Ha további ellenőrzésekre van szükség a kivétel paramétereivel és szövegével kapcsolatban, továbbra is a try-catch módszert kell használni.
  • Ha valami tesztet mégsem akarunk futtatni, @Ignore annotációval kiüthetjük. (A @Test annotáció megmaradhat, elé és mögé is beírhatjuk az @Ignore-et.) Megadható neki egy String típusú paraméter, hogy miért hagyjuk ki. A teszt nem fog lefutni, viszont jelezve lesz hogy ki lett hagyva. Az egész osztályra is modhatunk @Ignore-t, de vigyázat, az nem ugyanaz mintha a metódusokra mondanánk, mert az utóbbi esetben még a @AfterClass és @BeforeClass lefut.
  • Általam nagyra értékelt feature, hogy a teszteseteknek timeout adható így: @Test(timeout=500) Milliszekundummal.
  • Van új assert, ami objektum tömböket hasonlít össze, viszont sok (12) assert metódus eltűnt az autoboxing feature miatt. Mindegyik az assertXXX(Object, Object)-et használja. Illetve a DevX szerint így történt, de én furcsa módon elérem ezeket a mindenféle paraméterű assert metódusokat továbbra is a TestCase osztályban.
  • Lehet használni az 1.4-ben bevezetett assert kulcsszót is, de akkor a tesztek futtatásánál meg kell adni az -ea kapcsolót a JVM-nek, különben az assert-ek nem kerülnek kiértékelésre. Ekkor viszont a JUnit-os assertException helyett a nyelvi java.lang.AssertionError-t fogjuk megkapni adott esetben.
  • JUnit4-ben nincs suite()
    metódus. Ehelyett lehet csinálni egy üres osztályt, aminek annotációban adjuk meg, hogy milyen más osztályokat futtasson:
    @RunWith(Suite.class)
    @Suite.SuiteClasses({My1Test.class, My2Test.class, My2Test.class})
    public class AllTests {
    }

  • @RunWith osztály annotáció megadásával saját futtatót is megadhatunk a tesztesetek futtatásához. Pl. a org.junit.runners.Parameterized-et, ami általunk megadott paraméterekkel küldi meg a tesztet. Egy @Parameters annotációval felturbózott publikus statikus metódusra van még szükség, ami egy Collection-t ad vissza és egy publikus konstruktorra, ami a Collection-ben lévő elemeket tudja fogadni. Pl. ha a Collection integer párokat tartalmaz, akkor a konstruktornak is két integer-t kell fogadnia. A futtató végigyalogol a Collection-ön, minden egyes esetben meghívja a konstruktort, majd végig a @Test-tel ellátott metódusokat. A DevX-es cikk harmadik oldalán van erről egy példa. (Listing 2.)
  • Ha ezt adjuk meg: @RunWith(TestClassRunner.class) ez nem okoz semmi különbséget ahhoz képest hogy nem adunk meg semmit, mivel a TestClassRunner a default runner.
  • JUnit4 nem különbözteti meg az előre várt hibákat a rosszul megírt tesztesetekből származő nem várt hibáktól -ez visszalépés! Ergó egy tesztesetnek a JUnit3.8 (passed/error/failure) eseteihez képest csak (passed/failure/(ignored)) esetei vannak.
  • java –ea org.junit.runner.JUnitCore paranccsal lehet futtatni a teszteket. Tud futtatni 3.8-as teszteket is a DevX cikk szerint, de a gyakorlatban 3.8-as tesztekben kell egy kis módosítás:
    public static junit.framework.Test suite() {
    return new JUnit4TestAdapter(MyTestClass.class);

    4.0-ás tesztek természetesen nem mennek 3.8-on. Ha régi és új JUnit is van a classpath-on, akkor pedig lehet hogy összebalhéznak. Nekem legalábbis securityException-nel leállt.
  • Hallottam már egy úgynevezett assertThat metódusról, elvileg van ilyen 4.4 óta, de még a junit.org-on aktuálisan fenn lévő javadoc-ban nem láttam.
  • Eclipse 3.3-ban van JUnit4.4 és JUnit3.8 támogatás.
  • Olyan szinten el*ja ez a szerkesztő a betűtípusokat és a formázást, hogy öröm nézni. Szörnyű. Update 2007.12.04: Megjavítottam direkt html szerkesztéssel.
Update 2008.11.20: JUnit3-ban szépen le lehetett kérdezni az éppen végrehajtott teszt nevét az örökölt getName() metódussal. Ez a lehetőség JUnit4-ben szépen elveszett. A mostani pillanatban nem tudok rá beépített megoldást, de ezt találtam a témában. Csúnya hosszú kód, nem próbáltam ki.

2007-11-23

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.

2007-11-13

OHA, Android, JavaFX

A csapból is az folyik az utóbbi napokban, hogy a Google beszáll a mobil telefonok megokosításába - ha már Google telefon nem lesz. Több céggel megalapította az Opean Handset Alliance -t, ami már benne van a Wikipediában is. Sok platform létezik, amin lehet(ne) ezeket a ketyeréket programozni (melyiket min...), de kinézem a G-ből, hogy nem csak egy újabb API-t tesz a Windows CE, Symbian, MIDP-s alkalmazások mellé. Android a platform neve. A riválisok nem félnek. Mellesleg még semmi technikai konkrétum nem volt nov 12-ig, viszont vannak a videón gyerekek meg kutya. Na ez már kicsit azért marketing shit. UP pedig megmondja a frankót. Valamelyik cikkben benne van, hogy kik csatlakoztak az OHA-hoz és kik nem. A HTC, LG, Motorola, Samsung, T-Mobile, Intel például igen. A Nokia, Microsoft, Apple például nem, de az Apple szimpatizál velük. A Nokia számomra nagyon kedves telefonokat készít, de a belbecset tekintve talán kicsit konzervatívak, legalábbis ami a középkategóriát illeti. Steve Ballmer azt mondja "Welcome to our World", rengeteg eszközre van Windows CE. A Symbian-os ember is hasonlóképpen vélekedik, bár néhány Symbian-t használó gyártó is belépett az OHA-ba. El ne felejtsem berakni a Webisztános linket a témában.

A wapforum-nak is sok tagja volt, mégsem jutott messzire, mert a mobil és az internetes technológia gyorsabban közelített egymáshoz mint gondolták. (Szerintem.) Az OHA is hasonló ehhez, meglátjuk mi lesz belőle. Végülis valami közös API kialakítása jó ötlet lenne, a G meg iszonyú vehemenciával vágja bele magát a témába. Például 10 millió dolláros összdíjazású "versennyel" Android alkalmazások írására.

Az iPhone közben kapható lett Európában, USA-hoz hasonlóan szolgáltatóhoz kötve. Jövőre mégiscsak kiadják az SDK-t, amivel nemcsak böngészőben futó alkalmazásokat lehet írni. A Greenpeace nekiment az Apple-nek, hogy nem környezetbarát anyagokat használ. (Na még ez is.) Nem pont mobil, de egy-két napja volt az iPod-ról és az Apple-ről, valamint Steve Jobbs-ról egy film a Discovery-n. Egyszer ez is megérne majd egy post-ot.

Gosling bácsi firkantott néhány gondolatot, hogy a Java ME és a Java SE egyre jobban közelít egymáshoz, egyébként meg nyomják a JavaFX mobile-t, aminek Linux kernel lesz az alapja, ugyanúgy mint az Androidnak (és a Wikipedia szerint az Android alapja Java...). Pár hónapja volt egy vicces kijelentés JavaFX-szel kapcsolatban. Valami olyasmi, hogy a cél a Flash lenyomása. Igazából az lenne a reális cél, hogy a zéró piaci részesedésről valahogy el kéne mozdulni.

A 142-es Javaposse -ben kis hazánkról is szó volt. Abban a kontextusban került szóba, hogy vannak olyan országok, ahol több a mobil mint az ember. Olaszország és Svédország került még szóba (talán még Kanada). Nálunk 10 millió emberre 13.2 millió mobiltelkó jut. Azon poénkodtak hogy ezekben az országokban biztos gyakran vesztik el a telefonjukat az emberek (egy-két ismerősöm beleillik ebbe a körbe), de igazából szerintem csak a nyilvántartás módja és a marketingpolitika miatt lehet ez a nagy szám.

Kíváncsi vagyok hogyan alakul a jövő. Ami biztos, hogy a mobilgyártók és a szolgáltatók most sem fognak legatyásodni.

Update 2008.11.15 Közben még páran beléptek az OHA-ba, köztük a Sony Ericson, Garmin, Vodafone, lehet venni Android-os mobilt (bár elég körülményes nálunk), stb.

2007-11-08

Novemberi meetup

Pár megjegyeznivaló tegnapról a Nefelejcs utcából:


Domain-specifikus nyelvek:

Ennyi idő alatt nem lehetett rendesen ráfókuszálni a problémára, de kb. arról volt szó, hogy manapság a "saját" nyelvek alkalmazása már nem túl nagy kunszt integrált fejlesztőkörnyezetben sem. Akár grafikusan is meg lehet határozni a nyelv szintaktikáját. Eclipse-nél a feltett kérdésre adott válasz alapján a Graphical Modeling Framework, mint ingyenes kiegészítés alkalmas erre. Update 2007.12.06: 5 perc++.

VSShell:

Igazából ez volt az első előadás, amelyen megmutatta egy srác egy Mac-en futó Windows ablakban, hogy Visual Studio segítségével a World of Warcraft saját nyelvében hogyan fejlesztenek add-on okat. Az eszköz az előző nap lett bemutatva a Microsoft TechEd keynote-on. Tanulság volt, hogy a Visual Studio alapváltozata ingyenesen is letölthető, valamint hogy a VS is követi azt a filozófiát, mint a Java-s tesói, azaz kiegészítéseket lehet hozzá pakolni bármilyen "domain-specifikus" nyelvhez, tehát egyfajta általános fejlesztőkörnyezetként viselkedik. A domain-specifikus nyelvekre visszatérve, az oké hogy ad némi szintax highlight támogatást és nem enged szintaktikailag rossz dolgokat beírni, de a magasabb szintű funkciókat, mint pl. a lehetőségek felajánlása, hibák automatikus javítása - azért még hosszú ideig kézzel kell majd implemetálni fáradságos munkával.

Választási térképek manipulatív újrarajzolása:

Nagyon jól érthető és érdekes előadás volt többféle szempontból is. A következő választásokon a választási körzetek határai lehet hogy át lesznek rajzolva, mert a mostani térkép kiegyensúlyozatlan, azaz egyes területeken több a szavazó. A projekt célja, hogy felhívja rá a figyelmet, hogy az előző választási eredmények alapján manipulatívan is el lehet készíteni az új felosztást úgy, hogy egy bizonyos pártnak kedvezzen. Ezekkel a manipulatív elosztásokkal kísérleteznek. A dolog matematikai szempontból is érdekes (Valamilyen hűtés algoritmust használnak. Talán véletlenszerű hűtés?) A technológiai része is előremutató, mert a Google Maps API-t használják a szoftverben. Ez a szoftver nyílt és mindenki számára elérhető lesz, de USA-ban állítólag kemény fizetős programok vannak ilyen és ehhez hasonló célokra.

Online sajtótájékoztató rendszer:

Ez egy netes sajtótájékoztató rendszer bemutatása volt. Prezentációt (flash) és egyéb anyagokat lehet mutogatni, közben látszik a mandró webkamerás feje. Lehet visszakérdezni, ha jól láttam billentyűzettel.

LinuxBIOS:

A lényeg a lényeg, hogy lassú a BIOS és a ők azon dolgoznak, hogy gyorsabb legyen. Engem kb. eddig érdekel a dolog. Még leragadtam annál a korszaknál, hogy egy BIOS 64k-s, de ma már pár megások, esetleg van bennük egy Linux kernel és adott esetben 10mp alatt felpattintanak egy gépet.Néha már a nagyobb teljesítményű HDD-k felpörgetése a szűk keresztmetszet. Külön nyelv van a BIOS-ok programozására.

Participatív kultúrafogyasztás konzolokkal:


Iszonyú pörgős és stílusos előadás volt. Azt látni kell, hogy ennek a dolognak -ja a Gitárhíróról van szó- semmi köze nincs a valódi zenéléshez. Fölöttébb primitív játék. Arra a Basic-ban írt programra emlékeztet, amikor egy síelővel kellett fenyőfákat kerülgetni vagy egy szöcskével gödröket átugrálni. Egyébként meg baromi jó buli, sokan kipróbálták, párosan is. Engem nagyon zavart, hogy a kivetített kép pár tizedmásodpercet késett a hanghoz képest, de az is lehet hogy félreértettem valamit. Sok lehetőség van benne, akár közelebb is lehetne vinni a valódi zenéléshez, más szabályokat kialakítani, stb. Más hangszerekkel is meg van valósítva, sőt teljes bandát is össze lehet rakni énekessel együtt. Az énekesnek természetesen énekelnie kell, az eszköz pedig figyel a fonémákra is. Azt már eddig is tudtam, hogy az efféle dolgok bölcsője Japán, de azt nem tudtam hogy a karaoke-t feltaláló fickó hülyeségnek tartotta és nem védette le (mármint a karaokét), így más gazdagodott meg belőle. Egyébként pedig ment az "18 and life" a Skid Row-tól. Tyű de rég hallottam már, régi szép nóta.

A hely most is jó volt -ugyanott mint múltkor- és Irsai Olivér a barátom.

2007-10-29

Körkép

A Wikipediában remek írás található a loggolás alapkoncepcióiról.

A két (három) fő versenyző a log4j, a java logging API == java.util.logging == JUL == JSR47 és a Java Commons Logging == JCL. Ez utóbbi nem valódi loggoló framework, hanem csak egy adapter, ami futási időben megkeresi és használja a rendelkezésre álló frameworköt. Hasznos lehet, ha nem akarunk egy modult hozzákötni a log4j-hez, JUL-hoz vagy akármihez. Viszont vannak teljesítménybeli és funkcionális hátrányai a használatának, amit ez cikk részletez: Think again before adopting the commons-logging API

Íme egy vélemény a log4j és a JUL közti különbségekről. Régen olvastam már, de mélyen egyetértek vele annyi kiegészítéssel, hogy a folyamatos kényelmetlenségek miatt én még rühellem is a Java Logging Api-t.

(A szerző, Ceki Gülcü a log4j egyik alapembere. Van egy blogja is, amiben rokonszenves dolgokat ír. Pl. megemlíti Linus Torvalds GIT vs SVN-es előadását. Hát igen, nekem sem tetszett az a stílus, erről már nem is beszélve.)

Mostanában mintha kicsit külön utakon járna az Apache csoporttól, mert egy ideje a log4j utódján, a LogBack-en és a SLF4J-n dolgozik, ami a JCL utódja. (A Wikipediás cikk nem említi még ezeket.) Az SLF4J-ben lesz log4j támogatás elvileg. Nem tudom mennyire lesz hatékony az SLF4J, de a JCL helyett gondolom azért kellett új adapter framework-öt kezdeni, mert valamit máshogy (jobban) akartak megcsinálni.

A log4j már Java 1.1 óta létezik, a JUL pedig az 1.4-es jávában jött be. Belenézve a log4j honlapjába hamar kiderül, hogy nem létezik az 5-ös java újításait kihasználó verzió. A log4j 2.0 lett volna hivatott ezt a feladatot betölteni, de nem túl sok aktivitás látható a témában. Update 2008.03.17: Időközben Google-osok csináltak egy aranyos log5j nevű cuccot, ami log4j alapokon kihasználja a java 5 feature-jeit. Ha jól emlékszem nagyjából egy osztály az egész.

A LogBack és a SLF4J viszont hamarosan használható állapotba kerül. 0.9.X verziónál tart mostanában a LogBack. A javafórumon volt egy szócsata a logBack-ról és az isDebugEnabled használatáról. Egyik fontos tanulság számomra az volt, hogy az emberek sokféle stílusban loggolnak, de ez nagyban függhet a fejlesztett alkalmazástól is. Van aki sokszor tudja használni a toString-et, van akinek nincs erre lehetősége. Az isDebugEnabled pedig valójában csak akkor elhagyható, ha a paraméterlistában nincsenek azonnal kiértékelendő kifejezések. A vararg használata loggolásnál mindenesetre nagyon hasznos lehet String kiértékelés helyett.

Mikor melyiket érdemes választani? Konzervatív moduloknál JCL-t, ha felmerülhet olyan igény, hogy a modult befoglaló környezet nem log4j alapú, egyébként log4j-t. Új projekteknél lehet hogy már LogBack-et vagy SLF4J-t választanék, de azért előtte tájékozódnék, hogy vannak-e olyan appenderek, amik nekem kellhetnek. log4j-hez (mivel már elég régi motoros a szakmában) például elég sokféle appender van.

2007-10-25

MDC

Nemrég egy szerveralkalmazás logjának minden egyes sorában fel kellett tüntetnem az éppen csatlakozott kliens IP-címét. Nagyon régen ezt úgy csináltuk, hogy bevezettünk egy kötött log message formátumot, amibe szeparátorokkal bele volt téve a szükséges információ. Tudom hogy ez ronda megoldás. Mivel most adatbázisba kellett loggolni, -ahol külön oszlop kellett az IP címre- ez nem lett volna (könnyen) járható út.

Szerencsére Java 1.2 óta használható a log4j MDC (Mapped Diagnostic Context) nevű megoldása, ami InheritableThreadLocal-ba teszi a kívánt információkat egy Hashtable-be. Ilyen egyszerűen lehet betenni az információt a java kódban:

MDC.put("ip", ipaddress);

Az InheritableThreadLocal lényege, hogy az adott szálból kreált szálak átveszik a szülő szálhoz ily módon csatolt változókat. Szerver alkalmazásoknál -főleg ahol egy szálcsoport szolgál ki egy klienst- eszményi megoldás. A konfigban a ConversionPattern-ben a %X{propname} kifejezéssel lehet kinyerni a betett információkat. Egy külső modul loggolásába is be lehet illeszteni ezeket az MDC-ket anélkül, hogy a külső modul kódjába beleírnánk. Ha pl. Hibernate-et használunk és megfelelően állítjuk be a konfigot, a belső Hibernate logokban is látszani fog az MDC, pl. hogy melyik kliensre vonatkozik az adott Hibernate művelet.

A múltkor idézett cikkben van példa az MDC és az NDC (Nested Diagnostic Context) használatára. Az NDC az MDC verem stílusú változata.

Azt írják ügyelni kell rá, hogy a szálak befejezésekor az MDC-k és NDC-k tartalmát töröljük, különben az így eltárolt információkat a GC nem tudja kilapátolni a memóriából. Swing-gel is használtam és nem működött teljesen zökkenőmentesen. Néha nem került bele a szükséges információ a logba, de ez annak a számlájára is írható, hogy nem mélyedtem még bele nagyon a Swing szálkezelésébe. (De már kéne.)

A logBack-ban is lesz MDC támogatás, bár a Google egyelőre Bug-okat ad ki első találatnak a témában. Az slf4j támogatja, viszont a JCL nem, ahogy ez az írás említi. A java logging api-ról most hirtelen nem sikerült kiderítenem hogy támogatja-e, de az iménti írás szerint valószínűleg nem.

2007-10-19

Breaking News

  • Nemrég kijött az Eclipse 3.4M2.
  • Jó kis meccs van az Index fórumon a Java topikban Checked vs Unchecked exception témában. A javafórumon is megvolt ez a téma június környékén, de nem ennyire intenzíven.
  • Van még mit írni a logokról, (MDC, log4j-logBack-Jsr47-JCL-jslf4j) csak most sok a meló.

2007-10-16

Nagy logok, Lognézegetők

Néhány program életében eljön az az időszak, amikor több megabájtos fájlokat kezd el okádni, amiket már elég nehéz kezelni notepad-del vagy tail paranccsal. Nálam a rekordot egy adatkonvertáló szoftver tartja, ami -minden adatot loggolva ami a rendszer határait átlépte- óránként többszáz megát hányt ki. Mellesleg a használt Windows NT szerver elég ijesztő hibajelenséget produkált, amikor pár nap után telepumpálódott az egész winchester-e. Távolról nem lehetett adminisztrálni, közelről pedig teljesen úgy nézett ki, mint valami hardverhiba, mivel a szerver az újraindítás után nem tudott rendesen felállni. (Ugyebár nem volt hely a vinyón.) Amíg rá nem jöttünk, hogy csak törölni kell a pár gigás log könyvtárat volt szaladgálás, pánik, minden.

Szóval amikor már lapátolni kell a log fájlokat, hasznos lehet egy lognézegető eszköz, pl. a Baretail nevezetű. Meg tud nyitni igazán nagy fájlokat, egyszerre akár többet is, követi a végét, jól működik a scrollbar, lehet színezni a sorok betűinek és hátterének színét minták alapján (error-ok pirosítása). Ez egy nagyon hasznos feature. A háttérszínt érdemesebb beállítani, mert az szembeötlőbb. Csapatmunkánál pedig érdemes ugyanazt a színezést használni mindenkinek. Lehet exportálni és importálni a színezési preferenciákat, talán valami XML formátumban. Az ingyenes verzió nem tud pár alapvető dolgot, pl. a keresést (regexp, egyéb), de a BareTail Pro-ban már benne van. Ez utóbbi letölthető trial-ban és komoly 25 dollárba kerül. Ja, fontos hogy ez egy Windows program.

Létezik még egy hasonló, de lényegesen kevesebb tudást felhalmozó, kissé kényelmetlen loggolós plugin Eclipse-re, de ez elég félbehagyott projektnek látszik: Graysky

A RollingFileAppenderek pedig az alapműveltséghez tartoznak. Tudnak naponta, óránként, percenként (?) új fájlot kezdeni konfigtól függően. Már amelyik logging framework-ben van ilyen.

Update 2008.07.21 A javalistán az elmúlt napokban Log4j file elemzese címmel megjelent egy kérdés, ami pont a logfájlok nézegetésével és az ahhoz használt eszközökkel foglalkozik. A következőket ajánlják: Mindtree Insight (végül ez lett a bejövős az kérdés feltevőjének), Chainsaw , Vigilog (ezzel valami gebasz volt), valamint Perl/Awk. Ha nagyon hiper-ultra-extra logcsoportosítások kellenének, akkor talán elkezdenék Perl-ben programozni, de egyébként -bármennyire is tisztelem a "víáj lovagokat"- command promptban elég nehéz versenyezni egy adott célra kihegyezett, valóban jó GUI-s eszközzel.

2007-10-15

log4j JDBCAppender

Összegyűlt néhány loggolós okosság, amiket nem kellene elfelejteni. Azokat fogom mostanában leírni többek között.

A log4j-ben van egy úgynevezett JDBCAppender, amivel adatbázisba lehet loggolni. A conversionPattern-nek lehet megmondani egy SQL utasítást így valahogy:

<param name="ConversionPattern" value="INSERT INTO log (level, name, message) VALUES ('%p','%c', '%m')">

És nagyjából működik. Itt leírják, hogyan kell property fájlban konfigurálni, itt pedig van példa az xml konfigurációjára. A javadoc-ban pirossal-vastaggal ki van emelve, hogy ne használd, mert gagyi és ki lesz szedve. És valóban: a connection-ökkel elég rosszul bánik, elhasal ha a message-ben aposztróf van, nem támogat tárolt eljárásokat, prepared statement-eket, exception-öket pedig egyszerűen nem loggol. De azért kezdetnek használható. Dankomannhauptnál van egy használhatóbb megvalósítás, de nem próbáltam ki.

2007-10-04

Budapest New Technology Meetup Október

http://newtech.meetup.com/42/

Szóval fogtam magam és lebattyogtam erre a Meetup-ra...

Kiss Róbert (SOTE): Virtuális Gyógyszerkutatás: Természetesen nem nagyon volt lövésem a dologhoz, de az lejött hogy a fehérjekutatáshoz iszonyat sok számítási kapacitás kell. 1000 PC 3 hónapig ment, hogy leteszteljen 255 kombinációt -ha jól értelmeztem- és ebből 25 lett használható, ezekből lehet majd egyszer gyógyszer. Le is patentolták a vegyületeket. Úgynevezett "dokkoló" szoftvert használtak. Gyakorlatilag ez a szimulációs szoftver.

Pécskai Balázs, Fischer Kristóf (Mimóza Kommunikációs Kft.): Nextwork robotépítő verseny. Lesz egy Legós robotépítő verseny jövőre, azt reklámozták. Egy alap robotlegó készlet 90 ropiba kerül. Nem veszek, úgysem lenne időm legózni.

Benedek Balázs (Magyar Villamosmérnök- és Informatikus-hallgatók Egyesülete): 24 órás programozó verseny. Pár mondat elhangzott a "24 órás" kulisszatitkairól. Nem is tudtam, hogy miskolciak a gyökerei, ott rendezték meg először, csak akkor még nem az volt a neve. Segítséget keresnek a szervezéshez, feladatkiírásokhoz. Merthogy a verseny csak 24 óra, de a feladatkiírással tovább kell szórakozni, az 72 óra. Hahh... egyáltalán nem 24 óra a verseny, komoly felkészülés kell hozzá. Össze kell reszelni a segédkönyvtárakat, algoritmusokat, hogy a versenyen már minél több dolgot csak ki kelljen venni a dobozból és használni. Elhangzott hogy egyre több külföldi csapat indul a megmérettetésen (akik rendre le is nyomják hazai csapatokat). Nem tudom mi lehet ennek az oka, de hajrá srácok, mutassátok meg!

Szalai Ferenc (AVAXIO Informatikai Kft.): Ata-over-Ethernet - adattárolás, egyszerűen és célratörően. Ez már nekem nagyon hardver volt, de az lejött hogy van élet az adatbázisok és fájlszerverek fölött (után/mögött/alatt) is. Gondolom komolyabb adattömeggel dolgozó szolgáltatások általában ehhez hasonló vagy épp ilyen architektúrákat használnak.

Kozman Bálint: Szoftver vizualizáció. Rövid volt az előadás ehhez a témához. Egy egyszerű példa lett bemutatva blokkok és egymásbaágyazások megjelenítésére egy forrásfájlon belül, de vannak még bőven felhasználási területek. Régebben volt is egy indexfórumos téma, ami a programsorok tömegét és a modulok kapcsolódásait térképezi fel különböző méretű buborékok formájában. A Team activity analysis-ben is igen jó szolgálatot tehet. Ez csak egy hirtelen talált példa. Láttam olyat is, hogy -szintén verziókontroll alapján- a kódsorok szaporodását és kicserélődését követi nyomon. Ha valamilyen szinten össze van kötve a verziókontroll egy bugtracking rendszerrel, az további hasznos ábrák rajzolására ad lehetőséget. Kicsit el lettek bagatelizálva az előadás utáni kérdések, pl. lehetne-e ezekből művészeti alkotásokat készíteni, de szerintem jócskán vannak hasznos aspektusai. Pl. ha egy idegen kódra kell ráugrani, hasznosabb ránézni "felülről" egy ilyen vizualizációval, mert maguk a kódsorok vagy esetleg az UML diagramok nyálazgatása nem ad átfogó képet, nem látni a fától az erdőt. Főleg ha nincsenek UML diagramok -mint általában. Kódreview-ekhez is segítség lehet a vizualizáció, mert kibújnak a zsákból a funkcionalitással túlzsúfolt osztályok, vagy a mindennel összekapcsolt modulok. Jó eszköz lehet ez egy vezető fejlesztőnek, ha tudja használni.

A helyet nehéz megtalálni, de nagyon hangulatos. Igazi underground stílusú építészklub csupasz fagerendákkal és vakolattal, de ami kell az nagyon rendben van tartva. Volt bárpult, 450 a sör (jófajta), 150 vagy 250 a bor decije. Az előadások után lehetett volna még cimbizni, de nekem el kellett húznom.

2007-09-19

JUM III. Shownotes

Mivel lettem okosabb a JUM III-on?

  • A Webservice-ek írásához többféle lehetőség létezik. Az egyik ilyen az Axis 1.x, aminek a használatához kicsit sokat kell java-t és xml-t gépelni, néha sztochasztikusan működik a meglepetésekre nem vágyó fejlesztő szemszögéből, viszont gyors. Az Axis 2 sokat változott az 1.x-hez képest. Kulcsszavak még: WSDL, SOAP. Webservice-ek nemcsak java-ban írhatóak. Elvileg van szabvány, gyakorlatilag vannak súrlódások.
  • Az XFire egy webszervice-es SOAP provider. Állítólag gyors és sokkal egyszerűbb mint az Axis 1.
  • A JMaki az N-edik webes framework, aminek a lényege, hogy mindenféle másik keretrendszerből (pl. Dojo) adoptálták a komponenseket és egy saját XHTML-ben, (JSF?) kell összedobálni a GUI-t mérsékelt Javascript, HTML és JSON tudást felhasználva. Netbeans plugin van hozzá. Ahogy sejthető, érhet meglepetés fejlesztés közben. Nem túl takarékosan bánik a kliensoldali erőforrásokkal sem. Pl. egy táblázat JSON-ban kapja meg az adatokat amiből még DOM-ot kell csinálni és ez párszáz soros táblázatoknál súlyos 10 másodpercekig eltarthat.
  • A Flash immáron valós konkurenciája vagy alternatívája a Javascript+HTML-nek bizonyos esetekben. Flex Openlaszlo . Kocka fel is teszi a kérdést, hogy mi az előnye a HTML-Javascript-nek a flash-sel szemben.
  • A MINA egy apache-os, NIO-val kapcsolatos framework, ami valamiféle vékony logikát tesz még a meglévő java szolgáltatások fölé. Ha NIO-val kell dolgoznom, mindenképpen meg kell nézni a MINA-t.
  • A NIO "egy nagyságrenddel" gyorsabb az IO-nál (InputStream) ha sok kliens folyamatosan nyomja az adatokat, mert a hagyományos IO-nál sok erőforrást igényelnek a szálak közti váltások.
  • Van egy JCRPG (?) nevű blog vagy ember, akinek érdemes lenne megnézni az írásait. Java 3D-ben munkálkodik. Azt hiszem ez lesz az.
  • Mostanság úgy is szoktak webes grafikákat, pl. táblázatokat rajzolni, hogy pixeles nagyságú színes div-eket tesznek ki pontosan pixelre pozícionálva. Pl. a G. grafikonjai is így működnek. Ez aztán a hányás nem mondom.
  • JUM-ot nem érdemes péntekre szervezni, viszont érdemes jobban, többször, több helyen meghirdetni, mert könnyen elkallódik az információ és az emberek.
  • Létezik egy Budapest New Technology Meetup Group ami szintén egy jópofa dolog lehet. Érdemes lenne benézni majd egyszer-kétszer-többször. A honlapon elvileg vannak régebbi videók, itt pedig egy előadó beszámolója van. A következő alkalom Október 3. Meglátjuk.
  • A Belga sörözőben a Vígszinház mögött sokféle egzotikus sör és étel kapható. Az árak nem túl diszkontjellegűek, de a hely hangulatos.

2007-09-17

Echo2 ismét

A JUM III.-on követtem el egy előadást az Echo2-ről. A szó elszáll, az írás marad:

Az Echo2 egy java webalkalmazások fejlesztéséhez használható prezentációs rétegbeli keretrendszer, amiről régebben már írtam egy-két keresetlen szót. Érdekessége, hogy Javascript és HTML ismerete nélkül lehet felépíteni igényes Web-es GUI-kat. A komponenseket Java-ban kell összerakni a Swing-hez nagyon hasonlóan. A Nextapp nevű amerikai cég fejlesztette ki LGPL / Mozilla Public License alatt. Az Echo2 továbbviszi az Echo (1) koncepcióit, de a 2-es verzióban bevezetett Ajax-ozás miatt a felhasználói élményben és a sebességben lényeges javulás tapasztalható. Szervlet alapú, bármilyen szervlet motorral használható a megfelelő verziószámot szem előtt tartva.

A kiindulóoldalról lényegében minden elérhető.
Demók: egy email-kliens és egy tarka-barka, minden komponenst bemutató demó tekinthető meg online.
Doksik: Van egy jól felépített -a lényeget leíró- lineáris Tutorial, a technikai részleteket bemutató doksi, Java API doc és egy Wiki, amibe első látásra máris sokmindent belebillentyűztek.
Közösség: Van egy pezsgő fórum pár száz topikkal. Régebben volt egy blog, amibe bekerült egy-két bejegyzés pár hónap alatt egy tűzközeli ember kezéből, de úgy látszik hamvába halt, mert nincs már kinn a link.

Mellesleg találtam a prog.hu-n egy topikkezdeményt a témában: http://www.prog.hu/tudastar/66971/Ajax-Echo2.html
Nem értem miért nem találtak doksit. Vagy lehet hogy magyar nyelvű doksira gondoltak?

Kiegészítések:

Echo2 alkalmazások fejlesztéséhez elég egy Java IDE, de a Nextapp biztosít egy Eclipse-hez kapcsolható grafikus szerkesztőt, ami viszont már pénzes: Egy egyfejlesztős disztribúció 100 ropiba kerül, több fejlesztőre ez az érték közel lineárisan növekszik. Ezért a pénzért support is jár, a szoftver pedig letölthető kipróbálásra 30 napra.

Az Echo1-hez egy független (vagy nem független) fejlesztőcsoport még készített különféle izgalmas kiterjesztéseket Echopoint néven. Echo2-höz is folytatódott ez a jó szokás EchopointNG néven, de nem látom hogy igazán messzire jutottak volna. Régebben már megemlítettem ezt.

Disztribúció letöltés, tartalma

A 2.0-ás stabil verzió már jó régi, még 2005 decemberéből való.
A 2.1.0-ás Release Candidate 2007 márciusi és egyébként ezt ajánlják letöltésre.
A disztribúció 5.2 megás zip, amiben vannak példaalkalmazások forrással együtt (sima war-ok, amik egy webszerverbe bepottyantva elvileg azonnal működőképesek - gyakorlatilag nem minden esetben), a keretrendszer bináris fájljai és forrásai, valamint API dokumentáció. A csili-vili online demó sajnos nincs benne a letölthető disztróban.

Aki a kíváncsiságból vezérelve belenéz valamelyik példaalkalmazás war-jába, tulajdonképpen semmi meghökkentőt nem fog látni:
index.html ami egy más sok helyről ismerős redirect oldal.
A META-INF csak egy szokásos manifest-et tartalmaz.
A WEB-INF tartalma:
web.xml: Egyszerűbb webalkalmazásnál egy egyszerű servlet definíciót tartalmaz.

Bonyolultabb alkalmazásoknál a szervletnek paraméterei is lehetnek, több szervlet illetve biztonsági beállítások is fellelhetőek.
lib könyvtár: 3 darab Echo2 jar-t tartalmaz. Nem túl nagyok, a legnagyobb 198kbyte.
classes: Az alkalmazás osztályait tartalmazza, amik tulajdonképpen maguk az oldalak. Az alkalmazásban normál esetben nincsenek JSP, JSF, HTML, XHTML fájlok. (Természetesen megvan a lehetőség HTML content beágyazására.)
Lehet még egyéb könyvtár ami a publikusan elérhető erőforrásokat tartalmazza, pl. images.

A példaalkalmazások projekt szerkezete

A példaalkalmazások forráskódja a SourceCode könyvtárban található. Az alkalmazások Ant-tal buildelhetőek. Minket leginkább a java könyvtárban lévő források érdekelnek. Ami a htdocs könyvtárban van az egy az egyben átkerül a webalkalmazás gyökerébe publikusan látható erőforrásként (index.html , images). A deploy könyvtárban pedig a web.xml kapott helyet, tehát ott kell keresni ha valaki bele akar matatni.

A forráskönyvtár nem követi semmilyen IDE projektszerkezetét és nem tartalmazza a fordításhoz szükséges Echo specifikus jar-okat, de ezeket könnyen el tudjuk érni a BinaryLibraries könyvtárból. Szükség van még egy servlet.jar -ra, ami viszont nincs a disztribúcióban.

Az Ant-tal való buildeléshez az ant.properties-nek megfelelően be kell állítgatni néhány környezeti változót. Én inkább az ant.properties-t írtam át a servlet.lib.jar és az echo2* változókat direkt hivaktozásokra. Nem tudom miféle verzióprobléma miatt, de az ant.properties-ben a dir.src.app, htdocs és deploy sorokat is át kellett írnom a ${ dir.src} hivatkozásról direkt hivatkozásra, különben elbukott a war target. A war könyvtárban keletkezik a becsomagolt alkalmazás.

Az alkalmazás szerkezete

Az ApplicationInstance egy felhasználó session-jét reprezentálja a szerveroldalon. Akkor inaktiválódik amikor a user kilép vagy timeout-ol a session. A felhasználóhoz tartozó tulajdonságokat nyugodtan lehet ebbe az osztályba pakolni.
Az ApplicationInstance init metódusa egy Window objektumot ad vissza. A Window objektumra lehet felpakolni különféle komponenseket (add metódus). Nehézzé teszi a dolgokat, hogy nem minden komponenst lehet hozzáadni bármelyik másik komponenshez és ez sokszor csak futási időben derül ki egy üres képernyő, egy javascript alert és egy loggolt exception formájában.

Az elhelyezkedési struktúrákat a LayoutData beállításával lehet kialakítani. Az Echo 1-es megoldások nekem jobban tetszettek, de ez is megszokható. Valószínűleg erre jobban lehet vizuális szerkesztőt készíteni.

Az eseménykezelés a Swing-hez nagyon hasonló: listenereket lehet hozzápakolgatni a komponensekhez. (Anonymous inner class és társai.) Az események és a válaszok így Ajax segítségével pattognak a kliens és a szerver között anélkül hogy különösebben sportolni kellene a szép működés kiharcolásáért.

A komponensekben megjelenítendő adatok szintén a Swing filozófia szerint Model-ekben kerülnek átadásra.

A komponensek látható tulajdonságait (színek, háttérképek) kódból és XML-ben leírt stylesheet-ekkel is meg lehet határozni.

A lokalizáció ugyanúgy történhet mint egy standalone java alkalmazásnál. A böngésző támogatott locale-ját ki lehet nyerni az alkalmazáson belül. Támogatott a jobbról balra való írásmód is.

Semmiképp sem használj Echo2-t ha:

  • Sok felhasználós internet alkalmazást kell csinálnod.
  • Profi vagy valami másik webes keretrendszerből.
Jó ötlet lehet az Echo2 használata, ha:
  • Nem értesz HTML-Javascript-JSP-JSF -hez és nincs is szándékodban megtanulni.
  • Gyorsan össze kell dobálni egy intranetes webes alkalmazást.
  • Nagyon dinamikus felületre van szükséged.
  • Swing-es vagy SWT-s alkalmazást kell portolnod web-re.

2007-09-03

Javagrund

Múltkor kaptam egy comment-et a Javagrund-dal kapcsolatban. Valóban, a Javagrund az egykor Javasite egyenes ági leszármazottja olyannyira, hogy a Javasite egy az egyben megvan az oldalon a listaarchívummal együtt.

A javagrund első látásra továbbra sem pörög túlzottan annak ellenére hogy a Sun szponzorálja vagy szponzorálta. Felkerült egy-két pdf a nyári konfról, kéthetente egy-egy hír felbukkan. A fórumon továbbra is hullaszag, az anyagokban a Javasite-ről ismerős írások lelhetők fel, amikkel az a baj, hogy kb. az 1.2-es Java idejéből valók. Az RMI-s írás például határozottan elavult. Na jó, akad azért 5-ös jáváról is írás.

A Wiki üres és a Linkek menüpont is.

Itt leírják hogy miért Liferay portált használnak és miért zárták be a regisztrációt. Azért, mert a "A magyarországi Java közösség hagyományosan a levelezési listához kötődik". Ez való igaz: 1997 vagy 96 óta létezik a Javalista, de azért egy fórum jóval több szolgáltatással bír manapság, főleg a topikozhatóság miatt. Jól lehet böngészgetni, láthatóak a pörgősebb témák, tematizáltabb, az érdekesebb témákról lehet emailes értesítést kérni.

Viszont, ahogy az archívumot nézegetem viszonylag sokan írogatnak a listára (havonta 10, 20 ember) és egész jól pörög. Végülis keresni is lehet benne. Azért el tudnék képzelni több funkciót.

Tehát a Javagrund-nak nagyjából a levlista a közepe per pillanat. Ez kívülről egyáltalán nem látszik, ráadásul abszolút nem triviális odatalálni a levlistához. (Főoldalon a segítség menüpont, aztán onnan már megtalálható. A Közösség menüpont alá is igazán betehetnék.)

Kíváncsi lennék, hogy a Javalist és a Javafórum közönsége mennyire diszjunkt. Esetleg lehet kommentezni, hogy ki melyiket követi figyelemmel.

Közben létrehozódott egy Google Group Java témában egyelőre kevés aktivitással.

Boldogabb lennék ha a magyar Java közösség inkább összetartana az elaprózódás helyett, persze megértem hogy mindenkinek a saját kezdeményezése a legkedvesebb. Nekem azok a kezdeményezések szimpatikusak, amik nem állnak le az oldal felhúzásával, hanem a tartalommal való megtöltéssel is folyamatosan foglalkoznak.

2007-08-21

Wiw, Webisztán

Még tavasszal fenn volt a Webisztánon (régebben Sztahanov) egy többrészes podcast, amiben a Wiw alapítóival, Cseh Gáborral és Gordon Ákossal beszélgetnek. Nagyon tanulságos, többek között kiderül -bár ezt eddig is tudtam- hogy a kezdeti időkben a wiw-et egyáltalán nem tervezték nagy terhelésre és az egész egy php programból indult. Aztán újragondolták és újraírták abban a szellemben, hogy nagyobb látogatottságot vonzzon, de ennyire nagy ugrásra nem számítottak. Emiatt voltak architektúrális problémáik. Van egy gépházblog a portálon, -ami azóta átköltözött kétszer. Lehet olvasgatni annak, akit érdekelnek a technikai részletek. Látható, hogy nem egyszerű az architektúra és elég sok java komponenst használnak.

http://webisztan.blog.hu/2007/05/13/az_iwiw_sztori_1_resz_2

Elmondja az egyik tag, hogy sokat filóztak különböző dolgokon, például hogy az új ismerős bejelölésekor küldjenek-e emailt vagy mit küldjenek, de végülis az email jó ötletnek és jó behúzóerőnek bizonyult. Az is szándékos, hogy az értesítő emailben nem írják ki a bejelölő ember teljes nevét, hanem csak a keresztnevét. Az eredeti wiw-ben nem lehetett megnézni az ismerősök ismerőseit. Ez is egy nagy behúzóerő, nagy interaktivitást eredményezett, viszont kezdetben sokan ellenezték és valószínűleg néhányakat el is tántorított a site használatától. Az üzenőfal szintén egy ilyen behúzónak lett kitalálva. "Jó érzés ha belépek valahova és ismerős emberek beszólásait látom."

http://webisztan.blog.hu/2007/05/14/az_iwiw_sztori_2_resz

Néhány kulcsmondat a második részből: "Sok jó ötlet van, de figyelembe kell venni az adottságokat is. Nem minden ötletet lehet felhasználni." Sok különböző kapcsolatépítő portált megnéztek és mérlegelték, mit tudnak jól beépíteni a iwiw-be. "Egy kaliforniai cég Törökországban iwiw méretű sikert ért el." "Ausztriában a partyphoto feature megy nagyon, mindent vivő dolog." "Horvátországban blogőrület van." "Húzni kellett egy vonalat, különben sosem lett volna kész a szoftver."

A harmadik részben elmondják, hogy 5-6-an barkácsolták az első időkben.

(Nem írogatom ide a többi linket. A Webisztán élénken foglalkozik a web2 és a kapcsolati hálók kérdésével.)

Negyedik rész: Már nem csinálnák újra akkor sem ha tehetnék, mert 15 versenyző van már, némelyik elég komoly -letisztult funkcionalitással rendelkezik. Mégis csak a myVip futott be rajtuk kívül. Remélik hogy a roma vonalon sikerül megcsinálniuk egy nemzetközi kapcsolati hálót, amit az iwiw-vel eredetileg is akartak.

A HVG-ben is megjelent egy cikk és a Szigeten iwiw világzenei színpad volt a világzenei színpad neve. A HVG-s cikkben inkább üzleti oldalról járják körbe a dolgokat, pl. hogy a vételár lassan megtérül vagy legalábbis biztosan meg fog, és hogy az eladás nem ment teljesen zökkenőmentesen, mert a tagok nem értettek mindig mindenben egyet.
http://hvg.hu/print/200720HVGFriss176.aspx

Megjegyzendő, hogy egy ilyen szociális háló vételi tranzakcióban valószínűleg nem a szoftverarchitektúra kerül sokba, -mert azt egy profi csapat pár hónap alatt sokkal jobban újra tudná írni- hanem a felhalmozott adattömeg és a kialakított napi több(száz)ezer klikkelés, másszóval az ismertség, a név.

Update: Az óriási ismertség ellenére / miatt a site elérhetősége a mai napig hagy kívánnivalót maga után. Szókimondóbban fogalmazva néha kinyílik a bicska a zsebemben böngészés közben.

2007-08-06

Wicket vs JSF

Az elmúlt hónapokban volt szerencsém megismerkedni a Wicket-tel és a JSF-fel, ami két java szervlet alapú Webtechnológia azonos elhelyezkedéssel, azonos célkitűzésekkel. A második javafórum-os összeröffenésen -amin sajnos nem tudtam részt venni- is volt egy Wicket előadás.

A JSF a J2EE szabvány része a Wicket pedig egy SourceForge-os projekt, ami éppen nemrég csatlakozott az Apache Foundation-höz. A Wicket magát a konkrét implementációt is jelenti egyben, míg a JSF csak egy specifikáció, amelynek létezik egy referencia implementációja és több valódi implementációja. A valódi implementációk közül a Tomahawk-kal találkoztam, ami szintén az Apache-hoz fűződik.

A Wicket egy HTML markup-ot használ, amibe wicket-es tag-eket kell beleírogatni, amit aztán renderelésnél kicserélget szerveroldalon igazi HTML komponensekre. (Hasonlóan a Dojo-hoz, csak az kliensoldalon cserélget.) A JSF pedig klasszikus taglib működésű.

A JSF-hez a Facelet-eket is használtuk, ami annyit tud, hogy modulonként lehet összeállítani az oldalakat. Emellett még a standard taglib-et használtuk ahol tudtuk.

Ahelyett hogy hosszasan értekeznék róla, inkább kiválasztok néhány kritériumot és azok szerint hasonlítom össze a két versenyzőt:

HTML Elemkészlet: Milyen előregyártott elemek vannak.
Wicket: Elég szegényes, csak az alapvető form komponensek vannak meg. Rendezhető táblázat, fa nincs. Update: viszont sokféle komponens található itt: Wicket extensions
JSF: A referencia implementáció elég szegényes, a Tomahawk-ban már valamivel több lehetőség van, de több implementációból talán össze lehet szedni értelmesebb komponenseket. Ha más nem, fizetős implementációkból. A Tomahawk megvalósításai hagynak kívánnivalót maguk után. Konkrétan a tree2-vel találkoztam, amiben pl. nem létező feature, hogy a megjelenítésnél a fa bizonyos ágai legyenek lenyitva. Programozni kell hozzá. Általában elég sokat kellett programozni használható komponensek kialakításához ami roppant időigényes és bizonyos esetekben -amikor a business logikával kellene igazából foglalkozni- elkeserítő feladat.

DHTML lehetőségek: Ez nagyjából annyiból áll, hogy lehet-e komponensekhez javascript-eket beszúrogatni, lehet-e a komponensekre hivatkozni.
Wicket: Lehet, bár néha kicsit trükkös a Javascriptek oldalba ágyazása.
JSF: Az alap implementációnál problémás, mert maga határozza meg a komponensek id-it. Tomahawk-nál létezik a forceId, amikor mi adhatjuk meg az id-t. Ez nagyjából elégséges a DHTML-ezéshez.

Logika bővíthetőség: Mennyire lehet beavatkozni a keretrendszer működésébe.
Wicket: Elég jól bele lehet, szükség esetén akár a keretrendszerbe is bele lehet matatni.
JSF: Nem nagyon lehet beavatkozni, mivel a JSF motor az alkalmazás hatáskörén kívül esik, ráadásul az oldal életciklusa merev és teljes gáz, bizonyos esetekben nem felel meg az elvárásoknak. Megvan a helye a validációknak, modellbe érték visszaírásoknak, ettől nem lehet eltérni.

AJAX: Mindkettő az Ajax előtti időkből gyökerezik, szóval az ezirányú támogatás elég toldozás-foldozás jellegű, bár állítólag a JSF-nek is van Ajax-os megvalósítása és a Wicket is úgy reklámozza magát, hogy Ajax-os. Who knows...
Wicket Update a kommentek közül tapasztalt Wicket-es embertől: "Szerintem iszonyat jól használható a beépített Ajax támogatás, gyakorlatilag 0 sor javascripttel lehet szép ajaxos működést írni."

Adatmodell-prezentáció híd: A modellt valahogy bele kell pumpálni a html elemekbe.
Wicket: Java-ban történik ami fölöttébb kényelmes, nagyban megkönnyíti pl. a hibakeresést. Sajnos követni kell az oldal hierarchikus felépítését. Pl. ha egy text input egy-két frame-en belül van, azt a modellben úgy kell felépíteni. Általában sok anonymous inner class-t használunk Wicket adatmodell leírásához. Viszonylag egyszerű a különböző validációs logikák beépítése.
JSF: XML-ben van leírva, és emellett java bean-eket kell gyártani hozzá. Az így gyártott modell némileg könnyebben leválasztható, de többet kell írni és ott van az a fránya köztes XML és a JSF életciklus ami néha bekavar... Ha sikerül az XML-t hibamentesen leírni és nincsenek extra igények akkor meglepően hamar és könnyen működnek az összetolt részek. Amint dinamikus működésre van szükség, pl. egy mező validációs szabályai függenek egy másik mező értékétől -csőstől jönnek a gondok.

Hibakeresés:
Wicket: Elég részletes hibaüzeneteket írogat ki és a java használat miatt is egyszerű a hibák megtalálása. Nehezebb hibázni, mert minden java IDE eleve kiszűr sok szintaktikai hibalehetőséget. Sok hiba a komponens hierarchia be nem tartásából adódik. Nem mellékes, hogy a Wicket oldalak alapjában véve egyszerű HTML-ek, amelyek kapásból megjeleníthetőek egy egyszerű HTML böngészőben mindenféle szerver nélkül.
JSF: Általában a hibák indirekciója jelentkezik, ha jelentkezik. Rosszabb esetben csak üresen jelenik meg a kontroll, vagy szétcsúszva jelenik meg az oldal. Lehet találgatni hogy hol volt egy esetleges elírás, hiányzó vessző az XML-ben.

Modularizáció, újrafelhasználhatóság: HTML oldalrészek újrafelhasználhatósága.
Wicket: A beépített fragment mechanizmus használható. Jóval többet várnék.
JSF: A facelet elég telitalálat, nagyon jól használható. Az egyik legjobb dolog a JSF-ben, bár nem a JSF része. Kicsit szószátyár, de megbocsátható.

Grafikus dizájnolhatóság:
Wicket: Mivel sima (X)HTML, céleszközökkel igen jól dizájnolható. CSS, képek használhatóak.
JSF: Nem sima HTML, viszont egyre több JSF céleszköz van amivel WYSWYG módon szerkeszthető. Ezekkel az eszközökkel nekem még csak drótmodellt sikerült eddig összeraknom. CSS, képek viszont szintén használhatóak.

I18n: Természetesen támogatott mindkét frameworknél.

Oldalakon vezérlő logika: Ha ismételgetni vagy opcionálisan akarunk megjeleníteni HTML részeket.
Wicket: Nem támogatja, mert alapelv, hogy az oldalon ne legyen B logika. (De mi újság a prezentációs logikához tartozó vezérlő szerkezetekkel?) Végülis meg lehet szokni nélküle. A fragment mechanizmust kell használni, ezenkívül van még egy egyszerű de elég jól használható iterator szolgáltatás.
JSF: Több szinten is támogatja, már a standard taglibek miatt is, de sajnos nem mindig jól működik együtt a többféle technológia, ami néha nagyon megnöveli a szopásfaktort.

Szerverterhelés: Ezt csak úgy érzésre tudom mondani, hogy kb ugyanott lehetnek ebben a kérdésben. A Wicket-nek inkább több memóriára van szüksége, mert fenn kell tartania a kérések során a memóriában a java komponens hierarchiát, a JSF pedig újraépíti az adatmodellt minden egyes kérésnél, ami fokozott számítási igénnyel jár, viszont elvileg kevesebb memóriát igényel. A wicket-nél ügyelni kell a szerializációra, mert egy rosszul felvett mező könnyen felránthat pár megabájtot a session-be. A Wicket-nél szintén ügyelni kell az inaktívvá vált kliensekre, akiknek a Java komponens hierarchiáját valamikor el kell dobni a memóriából. Mindkettő cluster-ezhető.

Dokumentáció:
Wicket: elég jó doksi van hozzá.
JSF: van hozzá mindenféle írás, de pl. a Tomahawk-hoz egy félig írt Wiki, amiben sokszor inkább a problémákat részletezik.

Melyiket használnám a következő projektben?
Nagyon enyhén a JSF felé dől a mérleg, de biztos hogy utánanéznék valami igen jól kidolgozott megvalósításnak. A Wicket sem rossz, úgy érzem kb. egy szinten vannak, de a JSF-ben -akkor is ha talán több vesződéssel jár- több a lehetőség. Viszont ha kevés lenne a dinamikus form-jellegű tartalom az oldalakon akkor Wicket-et használnék, mert az közelebb áll a HTML-hez, könnyebb dizájnolni. Ha sok a logika, egymásba ágyazódás, form elemek újrafelhasználása, akkor pedig a JSF-et választanám. Egyébként pedig messze nincs még ez a meccs lejátszva és ha valóban modern és dinamikus webalkalmazást kellene csinálni, akkor valószínűleg nem ezek közül választanám ki a keretrendszerét.

Update 2007.12.11: Találtam egy ilyet (wicketstuff.org) és egy elég kimerítőnek látszó összehasonlítást különböző webes framework-ökről. Ha majd lesz időm, átnézem ezeket. Addig is, aki beleolvasott, írjon róla.

2007-06-26

Netbeans 6 pre kipróba

Kipróbáltam a 6-os netbeans preview-jét, de előbb egy kis történelem.

Annak idején JBuilder-rel kezdtem, majd NetBeans-re váltottam, mert ingyenes, teljesen java, platformfüggetlen és frankó volt. Aztán a munkatársaim ajánlották az Eclipse-et, mert látták hogy a NetBeans-szel kicsit döcög a gépem és mindig egyszerűbb szoftvert cserélni, mint hardvert bővíteni. (Nem azért egyszerűbb szoftvert cserélni, mert nehéz beletenni a gépbe plusz X mega RAM-ot, hanem mert ezt meg is kell szerezni valahonnan, el kell menni érte, szét kell szedni a gépet (ami kockázat) és fennáll a veszély, hogy a többieknek is hirtelen szükségük lesz bővítésre.) Tehát igaz hogy az Eclipse nem full java és nem teljesen platformfüggetlen, de kevesebb memóriát igényelt és ezért az alkalmazásváltások nem okoztak nagy szürke képernyőket pár másodpercig. Döcögős volt az átállás, de most (pár évre rá) már teljesen megszoktam és megszerettem. Néhány projektben nem is tudnánk mást használni, mert erre vannak meg azok a pluginek amik nekünk kellenek.

Mostanában nagyon nyomják a Netbeans-t. A Sun konferencián is külön előadást kapott (Roumen volt az előadó). Minden elképzelhető dolgot beleintegrálnak a MIDP grafikus GUI szerkesztőtől kezdve a Ruby támogatáson és a JSF GUI szerkesztőn keresztül a JBI-ig. Csak azt nem tudom hogy a fejlesztők hány százalékának van ezekre így együtt szüksége. Valószínűleg 0, szóval a dolog inkább a marketingnek szól.

Ha megnézem a hamarosan megjelenő Eclipse 3.3-as feature listáját, akkor pedig csupa csip-csup dolgokat látok, amiket valószínűleg észre sem vennék egyébként, de kódolás közben igazán hasznos lehet egyik-másik.

Egy éve volt szerencsém a Sun Java Sun Enterprise 8-hoz ami a Netbeans-ra épül és nem dobtam hátast tőle -konkrétan egy nagy rakás szerencsétlenség volt, úgyhogy talán némi szkepticizmussal vágtam bele a 6-os preview kipróbálásába.

Az installálás és az indítás oké. Mellesleg közben kicseréltem alatta a Java-t 5-ösről 6-osra és ezután nem volt hajlandó elindulni, a beállítást pedig nem tudtam megtalálni, tehát gyorsan újrainstalláltam.

Úgy gondoltam hogy kipróbálom a MIDP alkalmazásfejlesztőt -úgyis most vettem egy frankó Nokia 6300-ast, csinálok rá valami kis progit. Első körben a flow diagram nagyon meggyőző, csak amikor szaporodnak a képernyők (4 fölé) akkor már nem nagyon lehet őket értelmesen elhelyezni. Az összekötő vonalak mindig a képernyő ugyanazon (jobb) oldaláról indulnak és ugyanazon (bal) oldalára érkeznek, ezért max egy wizard szerű képernyő flow-t lehetne belőle szépen összerakni. Bizonyos command-okhoz tartozó vonalak meg sem jelennek. A képernyőszerkesztő nagyjából oké. A generált kód -mint mindig- hagy maga után kívánnivalót. A NetBeans sajátossága, hogy a generált kódba nem enged belenyúlni, nem engedi szerkeszteni. Mindenhol lazy inicializálást használtam, ami azt jelenti hogy csak akkor hozza létre a kontrollt ha szükség van rá és ha már létrehozta, később azt a példányt használja (singleton pattern). Viszont nem tudtam berakni semmi közös részre azokat a kódrészeket, amik a kontroll egyéb tulajdonságait megváltoztatnák másodszori és többedszeri megjelenítéseknél. Tehát minden egyes helyre be kellett tenni a kontroll megjelenítés után, és ez csúnya. Pl. ha egy képernyőre öt helyről lehet bemenni, akkor öt helyre kellett betenni a képernyőt friss adatokkal feltöltő kódrész hívását.

A kódszerkesztő talán azért tűnik szokatlannak, mert nagyon a kezemben vannak már az Eclipse shortcut-jai, de néhány kódkiegészítés azért mellen ütött. Eclipse-ben statikus metódusba eleve nem lehet beírni a "this" referenciát, mert aláhúzza hibának. NB-ben be lehet írni, sőt felajánlja utána a statikus metódusokat is (ctrl+space), amiket ha kiválasztok persze már fordítási hibát jelez. Ha kivételt dobó kódrészt akarok try catch -csel körbevenni és többféle exception-t is el kell kapni, amelyek esetleg egymás leszármazottai, a catch blokkokat néha rossz sorrendben teszi ki, emiatt szintén fordítási hiba keletkezik. Közben a try catch-en belüli kódot is átírja úgy, hogy kiírja az osztályok nevét a teljes package névvel függetlenül attól, hogy az import megvan. Még egy refaktorolási diszkrepanciával találkoztam amikor véletlenül sikerült azonos nevű osztályokat kialakítanom különböző csomagban. Utána fél óráig kellett böngésznem a kódot hogy visszacsináljam. Tehát a kódszerkesztő, kódkiegészítő, refaktorolós rész leírta magát nálam.

Még a buildelésről pár szó: a MIDP projekt létrehozásánál a Netbeans megcsinált mindent ami egy ilyen projekthez kell, a buildelés pedig gyakorlatilag egy Ant script futtatásából áll. Ez szimpatikus. Az Ant script viszont nem fut valami gyorsan és az emulátor sem ugrik fel túl hirtelen (20 mp egy 2G RAM-os Centrinoval) de azért használhatónak titulálható.

Valamelyik Javaposse-ban hallgattam, hogy az Eclipse inkább hackelésre, kódvarázslásra jó, a Netbeans pedig prototípusok gyors összedobálására. Maximálisan egyetértek. Végszónak annyi, hogy ismét az a benyomásom mint az SJSE8-nál, hogy még mindig kicsit összetákolt dologgal találkoztam, de már sokkal jobb, és kíváncsian várom az igazi 6-os verziót. Hajrá Prága!

2007-05-09

Paláver (a.k.a Java User Meeting)

Volt egy összeröffenés a Victor Hugo utcában, amit a javaforum-on szerveztek össze. Néhány előadás 7-től 10-ig este, nagyon hasznos volt. Igazából leírták róla páran amit akartak és amivel nagyrészt egyet is értek, úgyhogy itt vannak a linkek:

Lesznek majd fóliák és talán videók is elvileg. Na és remélhetőleg lesz még paláver.

2007-04-04

jTDS JDBC Driver

Nemrégiben egy Microsoft SQL szerverrel üzemelő java webalkalmazásban belefutottam egy-két problémába. Eredetileg az MS-ről letöltött JDBC drivert használtam DataSource-ba ágyazva, ami nagyjából működött is. Az egyik nagy hiányosság volt, hogy ha a DataSource elvesztette a kapcsolatot az adatbázissal, nem állította helyre automatikusan.

Próbáltam letölteni egy frissebb verziót és kénytelen voltam installálni, (ami azt jelentette, hogy a Start menümbe is belepiszkított) de a frisebb verzió sem reconnect-ált.

Hosszas keresés után sem jutottam eredményre, nem találtam auto reconnect paraméterezhetőséget, vagy amit találtam az nem működött.

Valahol viszont találtam egy linket a jTDS-re, ami egy 100% javaban írt LGPL-es MS SQL szerverhez és Sybase-hez kapcsolható JDBC 3.0 driver. Nagyon jól használható a doksija, egyszerű a telepítése (nem kell telepíteni, csak a jar-t kell bepottyantani valahova).

Be is izzítottam és azóta boldogan fut a webalkalmazás a jTDS-sel, reconnect-ál ha az adatbázis szerver bukfencezik egyet.

2007-03-22

Oracle java tárolt eljárások, múltidézés: jdk1.3

Oracle-ben lehetséges az adatbázisszerverre feltöltött java programokat tárolt eljárásként futtatni. Ezzel a feature-rel, valamint az Oracle 10g és 9.2 ehhez kapcsolódó diszkrepanciáival találkoztam. A google-n "Oracle loadjava" kulcsszavakkal kitűnő cikkeket lehet keresni, amelyek elmagyarázzák a dolog lényegét, úgyhogy ezt nem részletezem, csak dióhéjban a lényeg:

Ha valami ok folytán olyan logika végrehajtására van szükség adatbázisban lévő adatokkal, amit tárolt eljárással nem lehet megoldani (pl. bonyolultabb számítások), a külső számítás használata pedig előnytelen, a java tárolt eljárás hívása egy jó módszer lehet. A felhasznált java osztályokat vagy jar fájlokat először be kell tölteni az adatbázisba az adatbázisszerver bin könyvtárában lévő loadjava parancssori eszközzel vagy máshogy (google). A java osztályokon belül a szokásos módon JDBC-n keresztül érhető el az adatbázis és a teljes standard java API használható, plusz azok a könyvtárak amiket feltöltünk. A java osztályok metódusai wrapper függvényeken keresztül érhetőek el, amiket ugyanúgy lehet hívni mint a tárolt eljárásokat, akár triggerből is. A wrapper függvény tartalmazza a hívandó java osztályt és a metódust a teljes szignatúrával. A metódusnak akár Clob-ok is átadhatóak paraméterként.

És most pár probléma / érdekesség amivel találkoztam:

  • Az Oracle 10g Express Edition nem támogatja ezt a feature-t, csak a Standard Edition vagy fölfelé.
  • Az Oracle 10g java1.4-et használ, az Oracle 9.2 pedig java1.3-at. Erre a fejlesztés során gondolni kell. Nem néztem utána hogy ezeket le lehet-e cserélni, de az Oracle elég érdekesen áll a jdk-khoz. Ha például installálok egy adatbázisszervert, a path-ot átírja a saját jdk-jára ami felülvágja az eddig használt (újabb) jdk-mat, ha esetleg volt olyan.
  • A loadjava parancssori eszköz az adatbázisszerverhez tartozik, tehát az adatbázisszervert tartalmazó gépen kell futtatni. (Jelenlegi tudásom szerint.)
  • Oracle 9.2-nél a loadjava -nál nem működik a -thin opció, bár ez a működést nem befolyásolja, csak a driver kiválasztásánál van szerepe.
  • Ha a loadjava-hoz megadjuk a -resolve opciót, a betöltés után végigellenőrzi a betöltött osztályokat. Ha nem adjuk meg ezt az opciót, az ellenőrzés az első futtatás során fog megtörténni. Amelyik osztályokkal gond van, vagy nem történt meg rájuk az ellenőrzés, azok invalidok: select dbms_java.longname(object_name),uo.* from user_objects uo where object_type='JAVA CLASS' and trunc(created) = trunc(sysdate) and status = 'INVALID'
  • Bizonyos osztályhibákat úgy kezel az Oracle, hogy lecseréli a bájtkódot egy exception dobásra. Ilyenkor egy warningot ad a konzolra (ORA-29552: verification warning), az osztályt viszont érvényesnek titulálja. Pl. ha olyan metódust akarunk hívni egy másik osztályból, ami nem létezik, akkor pontosan ez történik. A futáskor fog egy RuntimeException dobódni.
  • Itt van még egy átfogó írás a témában.
  • Az adatbázisszerveren belül tárolt eljárásokként a java kód párszor lassabban fut, mint normál módon, jre-vel futtatva. Ez nálam 4-5-szörös lassulást jelentett.
Ha nem gond a vendor lock-in, akkor hasznos dolog ez. Mivel 9.2-es Oracle-re kellett fejleszteni, jobbnak láttam felrakni egy ősrégi 1.3-as JDK-t, ami viszont a következő problémákat okozta az Eclipse-en belül, ha az egész projektre beállítottam az 1.3-as jre-t:
  • Nem tudta futtatni az Ant-ot, mert az már újabb jre-t igényel. Az ant-futtatáshoz explicite meg kellett adni egy újabb jre-t.
  • Ugyanígy a JUnit tesztesetekkel, meg kellett adni explicite egy újabb jre-t. Ez mégegy érv amellett, hogy a JUnit teszteket érdemes különálló projektbe rakni. Korántsem biztos, hogy a tesztesetek ugyanabban a környezetben futnak, mint a tesztelendő projekt.
  • A build.xml -ben a javac targetnél nem fogadta el a target="1.2", source="1.3" opciókat, hanem az executable megadásával tudtam megmondani, hogy melyik jdk-ból használja a javac-ot.
  • Találkoztam olyan kódrészekkel, amelyek 1.4-es és 1.3-as java-ban is értelmesen néznek ki, viszont az 1.4-es és 1.3-as fordító mást fordít belőle. Pl.:
    StringBuffer sb1 = new StringBuffer();
    StringBuffer sb2 = new StringBuffer();
    sb1.append(sb2);
    Java 1.4-ben van StringBuffer.append(StringBuffer) metódus, tehát egy 1.4-es fordító ezt fogja fordítani. Az 1.3-as java fordító viszont a StringBuffer.append(Object) metódust fogja alkalmazni. Hiába azonos a forráskód, 1.4-essel fordítva nem fog futni 1.3-as java-ban, mert nem fogja találni a StringBuffer.append(StringBuffer) metódust.
  • Azzal is szembesültem, hogy az 1.4-es java-ba már rengeteg dolgot beletettek az 1.3-hoz képest, pl. az XML-lel kapcsolatos csomagokat. Sokat kellett találgatni, hogy mi is nem volt még akkor benne? Szerencsére a jdom -nál amit használtam jól le volt írva, hogy a jdk1.3-ast és 1.4-et használóknak milyen könyvtárakat kell még feltölteniük.
A másik tanulság hogy ha lehet kerülni kell már ezeknek a régiségeknek a használatát.

2007-02-20

Spring MVC tapasztalatok

Megcsináltam egy teljes webalkalmazást Spring MVC-vel és Acegi Security-vel pár hét alatt. Az a véleményem, hogy ez a páros régi kérés-válasz alapú webalkalmazások készítésére nagyjából jó, de modernebb Ajax-os vastagkliensekre már nem. Ahogy ajax-os trükkök kerülnek kilátásba, egyre közelebb érzek egy komplexitásrobbanást, drótozások és hibalehetőségek tömkelegét. Nem jó hogy controllerekker és view-mappelésekkel kell szórakozni amikor a B logikával kellene foglalkozni.

Az Acegi Security mondhatni bevált, bár kicsit bonyolult a konfigurációja a Spring-en belül. (Bonyolult életet lehelni bele és megérteni. Amikor alapvetően működik, onnantól már oké.) A programozása viszont kifejezetten kényelmes. Jó ötlet a ThreadLocal változók használata. Mivel open source, nem gond bővítmények írása sem.

Mit is kell csinálnom, ha egy olyan alap funkciót akarok létrehozni, hogy egy combobox változása szerver interakció után változást okozzon a képernyőn a kliensben. Ez kb. egy kétsoros kód kéne hogy legyen. Ellenben:

  • Rá kell tenni a combobox onChange eseménykezelőjére egy javascript event-et. Célszerű dojo-val elküldeni a szervernek.
  • Controllert mappelni a http kérésre, megcsinálni a logikát ami a választ adja.
  • Megcsinálni a választ, ami lehet egy egyszerű jsp lap(részlet).
  • A képernyőn csinálni egy div-et ahova a választ be lehet illeszteni.
Ilyen és ehhez hasonló dolgokkal nem szeretnék találkozni, úgyhogy azt hiszem tovább kellene menni a JSF vagy valami másik magasabb szintű webes keretrendszer felé, hátha az jobb. A sima jsp, Dojo-s trükkökkel és saját komponensekkel felejtős.

Persze szép volt, jó volt, jó alkalmazás lett.

2007-02-16

javaforum.hu

Az utóbbi időben nagyon felfejlődött a javaforum Auth Gábornak köszönhetően. Értelmes hírek és értelmes fórumtémák jönnek elő. Valami tudásbázis is alakulgat, de az egyelőre elég halvány, valamint állásajánlatok, reklámok és cégtár is felbukkant az oldalon. A portál lényege, hogy minden teljesen magyar nyelven van és a nevével ellentétben nem csak egy fórumot takar. A fórumok kialakításán még lehetne agyalni, de ez egyébként folyamatban van.

Az Eclipse vs Netbeans versengésben a javaforum kicsit a Netbeans felé hajlik, de csak azért, mert a portál fenntartói az utóbbival vannak közelebbi kapcsolatban. Viszont szívesen vesznek bármiféle Eclipse-es segítőkész emberkét.

A javasite.hu pedig látszólag meghalt, de biztos van valami utódja, csak nem tudok róla.