2008. május 30., péntek

négyrétegű architektúra

A manageability blogban olvastam egy érdekes postot a rétegelt architektúrákról. A szerző a két vagy háromrétegű architektúra helyett négyrétegűt ajánl (lásd ábra). Az értelmét ennek az egésznek a SOA adja. Vannak régi rendszereink, amiket webszolgáltatásokba, vagy webes interfészekbe csomagoltunk. Ezektől adatokat igényelünk, de mindegyik más rendszer, így más a sebessége. Emiatt (a szerző szerint) szükség van a késleltetéseket kezelő Latency Engine-re. Ez hangolja össze az adatokat, és türelmesen vár, amíg minden beérkezik.
A késleltetés kezelésére többek közt azért sincs más módunk, mert a régi, működő rendszerekbe nem nyúlhatunk bele.
Az eredeti post egyébként Mark Nottingham Leveraging the Web for Services at Yahoo előadásából született. Én inkábbb a postot ajánlanám kezdetnek, mivel sokkal rövidebb.

2008. május 27., kedd

rémi forax a parametrizált típusokról

ő itt remi foraxRémi Forax blogjában arról ír, hogy mi a probléma a típusparaméteres tömbökkel, és miért nem megengedett a definíciójuk. De nem csak a problémát veti fel: leírja, hogy a későbbiekben a nyelvi specifikációt hohyan lehetne átírni, hogy minden jó legyen.
Érdekes és rövid post.

2008. május 21., szerda

újgenerációs java plugin technology

Pár napja az RSS olvasóm a next-generation java plugin technology bejegyzésektől volt hangos, utánenéztem hát, hogy mi is ez pontosan. Természetesen a JavaSE 6 legújabb update-jéről volt szó, vagyis arról, hogy milyen új funkciókat hozott magával. A release notes elolvasása után ezeket találtam a legfontosabbnak (illetve a leglátványosabbnak):

  • Az appletek az új pluginnel kiemelhetők a browser ablakból, azaz egy kólön ablakot kaphatnak. Túlzottan nem mennék bele, azt ki lehet próbálni. Akit érdekel, hogy mi történik a sessionnel, az olvashat róla a java.net fórumon.
  • Az appletek betöltése alatt látható kép lecserélhető (bár kinek ne tetszene a narancssárga kávé...). Ehhez az applet elem új paraméterét (centerimage) használhatjuk (ugyanúgy, mint a többbit: egy param elemben).
  • JNLP támogatás. Az appleteket közvetlenül JNLP állományokból futtathatjuk - azaz az appletekből úgymond Java webstart alkalmazás lesz.
Az új lehetőségeket kitűnően bemutatják a NASA World Wind Java oldalon található appletek.

2008. május 17., szombat

pénzdíjas Sun verseny diákoknak - érdemes

A Sun pénzdíjas versenyt indított diákoknak. A feladat egyszerű: véleményt alkotni az OpenSolarisról vagy a NetBeans 6.1-ről, és közzétenni (természetesen angol nyelven). A határidő június 6.
A díjak: 250 dollár nagydíj, illetve 5*100 dollár kisdíj. Erre rájön még a saját blog/honlap megnövekedett forgalma, ugyanis minden beadott művet a Sun honlapján közzé tesznek. Ráadásul ha nagyon jól sikerül, fel is figyelhetnek Rád.
A téma gyakorlatilag bármi lehet: tipp, pluginfejlesztés, benchmark stb. Csak a fantázia szab határt az ötleteknek.
Mindenkinek érdemes megpróbálni, aki viszonylag jól ír angolul. Én biztosan megpróbálom. Ha meg nem is gazdagszom, veszíteni biztos nem fogok.
A verseny szabályai.

2008. május 15., csütörtök

mi várható a Java7-ben?

A Java rajongók népes tábora izgatottan várja, milyen újdonságokat hoz majd a Java7. Nézzük meg, mikről hallottunk eddig.

  1. Mapekre alkalmazható for ciklus. A Java5 újdonsága volt a foreach szerű for ciklus. Ezzel egyszerűen járhatjuk be a kollekciókat, pontosabban az Iterable interfészt implementáló osztályokat. Sajnos a Map-re, mit speciális kollekcióra nem igazán lehet alkalmazni ezt a konstrukciót: vagy a kulcsok kollekcióját, vagy az elemekét járjuk be. A Java7-ben valószínűleg a for ciklust már Mapekre is használhatjuk, hasonlóan a PHP-hoz, valahogy így:

    for(String key, String elem: map){
    ...
    }

    Ezzel a ciklussal egyidejűleg járhatnánk be a kulcsokat és az elemeket, leegyszerűsítve a Map-ek bejárását.
  2. Típusfelismerő for ciklus. Ez az újítás szintén a foreach ciklushoz kapcsolódik. Egy kollekció bejárásához jelenleg szükségünk van egy változóra, amelyben az aktuális elemet tároljuk. Azaz mindig meg kell adnunk a változó nevét és típusát. Ez az újítás egy kicsivel leegyszerűsítené a dolgunk azzal, hogy a típusmegadást elhagynánk. Ezt a fordító találná ki helyettünk a kollekció objektum típusából.
  3. Szupercsomag. A szupercsomag egy teljesen új nyelvi konstrukció lenne. Lányege, hogy a csomagokat egy logikai egységbe szervezhetnénk, amelyen belül módosíthatnánk az egyes osztályok láthatóságát. Például megmondhatnánk, hogy egy adott csomag osztályait csak a szupercsomag többi csomagjának soztályai láthatják. Ezzel új lehetőségeket kapnánk az adatbezárás tökéletesebb kezelésére.
  4. A C# properyjeihez hasonló konstrukció. Ezzel sokkal természetesebben érhetnénk el az egyes adattagokat (get és set metódusok hívogatása helyett), de az osztályok belső állapotához sem kellene nagyobb hozzáférést biztosítanunk. x.getField() helyett x.field-et írhatnánk. Aki ismeri a C#-ot (vagy a groovyt), az sejtheti, mire számíthatunk.
  5. A dátum API cseréje. Erről korábban már írtam egy postot.
  6. A konkurencia kezelése a nyelv részévé válhat, azaz kulcsszavakat vezethetnek be a többszálúság kezelésére.
A fentieken kívül még rengeteg dologról hallani, viszont ezek még nem mind kiforrottak, csak egyszerű lehetőségek. A szóba kerülő újításokról bővebben ezen a linken lehet tájékozódni. Én a fentieket találtam a legérdekesebbnek.


2008. május 12., hétfő

joda time és a Java API

Régóta tudjuk, hogy a Java dátumkezelése javításra szorul (a java.util.Date osztály már mejdnem minden metódusa használaton kívül helyezett, nem véletlenül). Mikor komolyabb dátumkezelésre volt szükségem, akkor találkoztam a JodaTime nevű open source komponenssel. Most azért találkoztam vele újra, mert szóba került, hogy a Java7-be bekerül a dátum keretrendszer.
A JodaTime teljes egészében a dátumkezelésre összpontosít (bár vannak más joda szoftverek is). Természetesen mindent tud, amit a Java Date és különböző Calendar osztályai, és valamennyire kompatibilis is azokkal. A Date osztály akkor vált elavulttá, mikor a dátumkezelés nemzetköziesítése szükségessé vált. Ennek támogatására új osztályokat vezettek be. A dátumkezelés osztályainak a többszálúsággal is meg kellett küzdeniük, azaz nem módosítható objektumokra volt szükség. A JodaTime szintén felkészült ezekre a kihívásokra, de jóval többet is tud. Nézzük, mik ezek pontosan:

  • Dátumok kezelésének kifinomult támogatása. Erre a DateTime osztályt használhatjuk. Mindetn tud, ami a dátumkezeléshez szükséges. A dátumrengszeret (gregoriánus, juliánus stb.) egy másik osztály, a Chronology segítségével állíthatjuk be. Számos Chronology elkészült, illetve újak készíthetők. Mint majdnem minden osztály, a DateTime is nem módosítható, és hogy a leszármazottak se viselkedhessenek másképp, egyszerűen nem származtathatunk alosztályokat belőle.
  • Időtartamok kezelse. Egy időtartam valamennyi ezredmásodpercet jelent, ahogy a neve is mutatja. Kezelésére a Duration osztály használhatjuk.
  • Intervallumok beépített kezelése az Interval osztállyal.
  • Parciális dátumok kezelése. Egy parciális dátum olyan dátum, amelynek nem ismerjük minden részletét. Ha például nem ismerjük az időzónát, akkor lokális dátummal van dolgunk. Ha nem ismerjük a dátumkomponenst, akkor egy időt reprezentáló objektumunk van. A parciális dátumok kezelését a Partial osztállyal valósíthatjuk meg.
  • Több nap, hét, óra, perc stb. együttes kezelése. Ez hasznos lehet például akkor, ha öt napor (a munkanapokat) együttesen akarunk kezelni.
  • Előre elkészített Comparator a dátumok hasonlításához.
A JodaTime mögött több éves fejlesztés áll. Ebből köetkezően egy nagyon kiforrott API-val van dolgunk, ami tényleg megérett arra, hogy a Java API részévé váljon. Kezelése nagyon egyszerű, ebben sokat segít a jó dokumentáció is. Nem kell attól sem tartanunk, hogy a jelenlegi Java dátumkezelés buktatóival találkozunk. Összességében érdemes már most áttérni a JodaTime használatára, ha komoly dátumkezelésre van szükségünk.
A komponens honlapján több bemutató példa is található, érdemes átnézni őket. Az API használatát viszonylag gyorsan el lehet sajátítani.

2008. május 10., szombat

open source a JavaOne-on

Egy nappal az open source hibát boncsolgató bejegyzésem után Simon Phipps and Patrick Finch JavaOne előadásának összefglalója megjelent a Sun blogoldalán. Írnak benne az open source történetéről, természetesen a sunos ősőkre nagyon büszkék. Ezután áttérnek a jelenre, de a jövő a legérdekesebb. Megemlítik ugyanis, hogy a Gartner előrejelzése szerint 2010-re a szoftverek 90%-a open source alapokon fog állni (azaz pl. open source komponensekből építik fel). Remélhetőleg a fennmaradó 2 év alatt javul a nyíltforrású színvonal. A cikk végén beszélnek a jövőbeli khívásokról (licenszing stb.)
Érdekes cikk, hiteles szerzők. Érdemes elolvasni.

2008. május 6., kedd

mi a baj a open source-szal?

Az open source szoftver alapvetően egy kedves ötlet, és lehet jól csinálni. Magam is nagyon szeretem az ingyenes, forrásböngészhető dolgokat - főleg az ingyenesség miatt (de ha éppen nincs kedvem a forrást bogarászni, akkor már sokszor bajban vagyok - és ennek később még fontos szerepe lesz). Szép dolog az, hogy valakik akár lelkesedésből összeraknak egy alkalmazást és minden juttatás nélkül átadják azt másoknak, és még azt is megengedik (amit sok programozó nehezen visel), hogy idegenek piszkáljanak a kódjukba - de sajnos néha a lelkesedés is elfogy. Ebben a postban azt nézem meg, mitől rossz egy open source komponens.

  1. Elhaló projektek. Sok open source projekt az idő előrehaladtával egyszerűen elhal. Nem mondom, hogy ez pénzes szoftverekkel nem esik meg, de ott más a helyzet. Ha egy fizetős dolgot kezdek használni, előtte jól megnézem: vannak-e bugok; várható-e, hogy kijavítják őket; lesz-e a problémáimmal kihez fordulnom. Megnézem, mire költöm a pénzt. Az ingyenes dolgokkal más a helyzet. Azokra könnyebb ráállni. Persze felteszem ilyenkor is a fenti kérdéseket, de a válaszoknál megengedőbb vagyok. Ráadásul az open source projektek ezekre a dolgokra akkora hangsúlyt nem is fektetnek. Gyakran csak az oldalfrissítésük idejéből derül ki, hogy a projekt már meghalt.
  2. Hiányos dokumentáció. Ez a legkényesebb kérdés. Nagyon sok open projektből egyszerűen kifelejtik még a kommenteket is, talán szándékosan, és semmilyen más dokumentációt nem készítenek. Egyszer találkoztam a JasperReposts-szal. Semmiféle leírást nem sikerült találnom - csak pénzért. És ez a legmocskosabb az egészben. Mintha azt mondanák: "Ingyen megkapod, de használni úgysem tudod." Sajnos rengeteg projekttel van ez így (lásd még axis2 doksi stb.). "A simple truth is that writing documentation does not make endorphins flow."
  3. Vállalati rettegés. Sok vállalat egyszerűen fél az open source komponensek bevetésétől. Részben ezért is a komponens fejlesztői a felelősek: a hiányos dokumentációk csak erősítik ezt a félelmet. A másik ok a tapasztalatok hiánya. Sokszor azok a fejlesztők sem írják le a tapasztalataikat, akiknek sikerült valamit kihozniu egy adott eszközből. Próbálj csak a hibernate és az axis2 kapcsolatáról megtudni valamit! mindenhol ugyanazok a kérdések fogadnak - válaszok nélkül. A válaszok tudói egyszerűen elbújnak a vilá elől.
Az open source legnagyobb problémáit a fentiekben látom.
A kedvenc open source postom: i hate open source, a sort of.

2008. május 1., csütörtök

forráskód keresők párbaja

A forráskód keresők olyan szolgáltatások, amelyekkel más programozók kódjai közt kereshetünk a nekünk fontos szempontok szerint. Azért találták ki őket, hogy felgyorsítsák a szoftverfejlesztést. Ugyanis ha egy programozó könnyen megnézheti más kódját abban a témakörben, amiben dolgozik, abból ötleteket meríthet, kevesebbet kell agyalnia és gyorsabban halad. Open source kódokat akár teljes egészében át is vehet.
Manapság több ilyen szolgáltatást is találhatunk. Ebben a postban azt tekintem át, hogy melyik kereső támogatja leginkább a fejlesztés hatékonyabbá tételét. Ehhez az szükséges, hogy minél több nyelven, minél több kód között lehessen keresni, és a találatok a lehető legpontosabbak legyenek. A szolgáltatásokat ezek szerint hasonlítom össze.

google code searchGoogle Code: A google hozza a szokásos minőséget. Azt mondják, a megszokott felület vonzza az embereket - ha ez igaz, akkor mindenki ezt a keresőt használja. De nem csak emiatt. A keresőben szinte az összes fontosabb nyelvet kiválaszthatjuk. A kereshető kódsorok mennyisége sem elhanyagolható, valószínűleg több milliárd. Az egyszerű kereséseken kívül (amikben használhatunk reguláris kifejezéseket) bonyolultabbakat is írhatunk. Megmondhatjuk, milyen legyen a licensz (ez akkor fontos, ha a kódot fel akarjuk használni úgy, ahogy van), mi legyen a csomagnév stb. Ez a kereső ennyit tud, de ez tökéletesen elég is. Ha valaki ráadásul google rajongó is, akkor biztosan ezt választja.krugle public kódkereső
Krugle Public: A nevéből gondolom egyértelmű, hogy ez a kereső nem a teljes változat, csak az enterprise edition kicsit lebutított testvére. De hogy miben butították le, az már jó kérdés. 2,5 milliárd kódsor közt kereshetünk 50 programozási nyelven. Megadhatjuk, hogy a kód melyik részében (komment, definíció stb.) akarunk keresni, és azt is, hogy milyen projektben. Egyszóval ez a kereső mindent tud, amit kell. De itt még nincs vége: egyidejűleg kereshetünk kapcsolódó szakmai cikkek, és projektek között. Azaz többet kapunk, mint amit kértünk. A felület is tetszetős, egyszóval érdemes ezt használni. Ha nem vagy google rajongó, talán ezt fogod választani.
koders open source kódkeresőKoders: Egyik személyes kedvencem a blackducksoftware keresője. Amikor hibernate-l dolgoztam, és a hiányos dokumentáció miatt nem tudtam semmit, itt néztem meg a forráskódot. Ebben a keresőben is rengeteg nyelv között kereshetünk, a kódsorok száma majdnem 800 millió. A nyitóoldal szerint naponta 30000 programozó használja, valószínűleg nem véletlenül. Itt is megadhatjuk a licenszet, és kereshetünk a kód különböző pontjain. Viszont ehhez speciális formulákat kell használnunk. Például osztálydefinícióban kereséshez: cdef:Shape. A formulák viszont adják magukat, így egy perc alatt megtanulhatók. A kereső gyors (sebességben nem marad el a google-től), felülete egyszerű és szép.
A fentiek alapján a győztes a Krugle kereső, de mindenki döntse el magának, hogy neki melyik tetszik a legjobban. Az én személyes kedvencem a Koders (azaz nálam a google nem került a top 2-be).

2008. április 29., kedd

cyvis - szoftver komplexitás elemző

A cyvis egy Java alapú open source szoftver komplexitás elemző. A hivatalos oldalon ezt írják róla:
"CyVis collects data from java class or jar files. Once the raw data is collected, certain metrics like number of lines, statements, methods, classes and packages are obtained. Other metrics like cyclomatic complexity etc. are also be deducted."
Azaz: az alkalmazás különböző szoftver metrikákat számít ki, például: ciklomatikus komplexitás (ez aegyjából azt méri, hogy mennyire összetett a kód a vezérlési szerkezetek mélységének, egymásban ágyazásának stb. szempontjából). Ezekből aztán lehet következtetni a szoftver minőségére. A fontosabb metrikákat a kód alaptulajdonságaiból számítja ki (sorok száma, metódusok száma, metódushívások száma) a fontosabb metrikákat.

A cyvis.jar-t futtathatjuk önállóan, és kódból is. Ha önállóan futtatjuk, akkor létre kel hoznunk egy új projektet, majd ahhoz hozáadni jar, illetve class fájlokat. A cyvis ezután elvégzi az elemzért, amit grafikusan megjelenít. Az eredményben egyszerűen böngészhetünk, és a színkódok egyérteművé teszik, hol kell javítani a kódon. Pontosabban nem kell, de tanácsos, mivel a rossz metrika értékek valamilyen hibát jeleznek.
Összességében a programot megéri használni, mivel egyszerű, és érdekes tancsokat ad. Én többször is felhasználtam, és sokkal egyszerűbb. átláthatóbb és könnyebben változtatható kódot kaptam - viszonylag nagy projektben. Csak ajánlani tudom. Nálam ötös.

2008. április 25., péntek

java tippek blogja

www.java-tips.org:
Ahogy a címéből is látszik, a blogon Javával kapcsolatos tippeket olvashattok (természetesen angolul). Ami tetszik a blogban, az az, hogy a postokon látszik, hogy Wendigo33 mennyire ért a nyelvhez. Ezen kívül előnyös az, hogy a postok rövidek, tömörek, de mégis szájbarágósak. Minden bejegyzés nagy részét egy példa adja. Ezek a tulajdonságok megkönnyítik a nyelv megtanulását. Mindig egy témára összpontosítanak, zavaró tényezők nélkül. A blog ráadásul gyakran frissül, szinte minden nap új tartalom kerül fel.
A hátrányok: a postok rss feedjében a postoknak csak a bevezetője érhető el, a többi csak a weben; az egyes témakörök általában (kivéve a nagyon egyszerűeket) több bejegyzésben jelennek meg, pedig bőven elférnének egyben is (úgy látszik, a szerző ügyel arra, hogy megfelelő hosszúságúak legyenek a postjai).
A felület szép és egyszerű (én ezeket szeretem), nem vonja el a figyelmet a tartalomról, segíti az olvasást.
Összességében érdemes feliratkozni rá.
Kedvenc bejegyzésem a blogról (mégpedig azért, mert röviden és tömören elmagyaráz egy fontos konstrukciót): Using static and final attributes

2008. április 20., vasárnap

javablogs közösség

www.javablogs.com:
Egy blog aggregátor, a Java technológiával kapcsolatos blogok gyűjtője. Bárki regisztrálhatja a saját blogját, de ha nem vág témába, eltávolítják. A főoldalon megjelenő bejegyzéseket a közösség moderálja - erről pontosabban semmit nem mondanak. Valószínűleg magyarnyelvű postok nem kerülnek a főoldalra.
Bugok is vannak még benne rendesen. Például nem kell megijedni, ha egy post linkjére kattintasz, és nem a post töltődik be, hanem a javablogs főoldala.
A felület egyszerű, de tetszetős, viszont az aloldalak kinézete néha eltér, ami nem tú szerencsés. Firefoxban a szövegek néha szétcsúsznak, de ez valószínűleg css hiba.
A hibáin felül nagyon jó oldal, a főoldalon (valahogyan) tényleg jó tartalmak jelennek meg, azonnal feliratkoztam rá. Kezdők és haladók is sokat okulhatnak belőle. Jelennek meg dolgok a Java nyelv alapjairól, és mélyebb tudásról is. A keresésekkel viszont vigyázni kell: néha halott linkeket ad (például keress rá a hibernate szóra). Ha ezt is megszokod, már semmi nem akadályozhat meg a felhőtlen tanulásban.
A kedvenc blogom innen: java-tips.org