Progmat

Megjelent az Eclipse legújabb, 3.6-os, Helios kódnevű verziója. A hír már elég régi, de a neten annyira alul volt reprezentálva, hogy nem volt nehéz elsikkadni felette.

Az átlagos Java fejlesző számára nem sok érdekesség van az új verzióban. Talán a legnayobb újdonság, hogy a Debug nézet kiírja az adott típusú objektum példányainak számát. Ezért az információért nem kell profilert indítani legközelebb. Ezen kívül szinte csak apróbb javítgatások kaptak helyett a Heliosban. Semmi egetrengető.

Eclipse szinten is lett a divatnak megfelelően App Store. Itt Eclipse Marketplace-nek hívják és az általános plugin kezeléshez hasonlóan picit nehézkesen használhatónak éreztem. Első pillantásra nem derült kis számomra, hogy egy plugin ingyenes-e vagy csak egy 30 napos próbaverzió amit később 1000 dollárért kell megvásárolni. Kicsit többet kellett volna másolni az ötletadótól :D.

A modern verziókezelők között a Mercurial után végre a Git is kapott rendes Eclipse plugint. Ha valaki szeretné a CVS/SVN után valamelyik trónkövetelőt kipróbálni, akkor mostmár mindkettőhöz elérhető a grafikus felült, nem kell a parancssorban bűvészkedni. Szerenécse a grafikus felület mögött nem a parancssoros verzió szerencsétlenkedik, rendesen implementálták Java alatt a git protokollt.

Az új verzió pár napos használata után úgy érzem ez a verzió nagyon kevés újdonságot tartalmaz. Szinte még letölteni is alig éri meg. Remélem ez azt jelenti, hogy a fejlesztők már a következő nagy ugrásra, az Eclipse 4-re koncentrálnak. Az Eclipse 4.0 egyébként hamarosan, július utolsó hetében érkezik. Kíváncsian várjuk.

Egy remek cikket olvastam az egyik konzultációs cég magazinjában. A cikk India egyik kis bankjáról (ICICI) szól, amelyik a semmiből nőtt ki pusztán a technológiai innovációra építve. Az innováció alapeleme a folyamatos fejlődés, a gyorsaság. A bankoknál ez gyakran az ezer éves rendszerek, hatalmas monolitikus mainframe gépek, több évig nyújtózó projektek miatt szinte lehetetlennek tűnik. A kis indiai banknál ennek elkerülésére vezették be a 90 napos projekt szabályt. Ez azt jelenti, hogy egyetlen projekt sem lehet hosszabb 90 napnál. Egyik sem.

A lepusztult Indiában a technológiára építeni furának hangzik. Ez a bank például 1000 ATM telepítését célozta meg az első évben, miközben összesen körülbelül 100 volt az egész országban. Az ATM-ek a megbízható működés miatt hagyományos telefon, bérelt vonal és műholdas kapcsolatban is állnak a központtal. Meddig tartott volna ezt kifejleszteni egy "hagyományos" technikai nézetekkel rendeklező banknak? 3 év? Biztos, hogy ők sem 90 nap alatt hozták össze az egészet, de 90 nap alatt valamit letettek az asztalra amire lehetett építeni a későbbiekben.

Gondolj a legutolsó projektedre. Elhúzódó specifikációs időszak? Technológiák cserélgetése? Semmire sem jó funkciók tömkelegének implementálása? Mi lett volna, ha csak 90 napot kap az egész projekt? Sok-sok problémával biztos nem kellett volna foglalkozni. Nincs hosszú specifikációs időszak. Végtelenbe nyúló megbeszélések az OK gomb szinéről és formájáról. A "funkciók burjánzása" lényegében ismeretlen. Ha pedig teljesen rossz az irány akkor legkésőbb 90 nap múlva kiderül.

Én egy picit úgy érzem, hogy ez a 90 napos projekt kritérium a manapság nagyon divatos agile (Scrum, Kanban) tervezés és programozás egyik könnyített formája. Ezek a módszerek a mindennapi munkavégzés menetét próbálják javítani. Gyors visszacsatolás, fókusz a lényegre, rövid iterációk. Ha 90 nap van egy projektre akkor nem is lehet másképp csinálni.

A te legutolsó projekted hány napig tartott?

Ismeri mindenki a Google Testing Blog-ot? A Google több-kevesebb gyakorisággal frissített blogja általános tesztelés és a "hogyan írjunk tesztelhető programot" témakörben tartalmaz pár remek írást. Az általános témák nem mindig túl érdekesek, de a technikai leírások Misko Hevery-től szerintem kifejezetten jók. Utálod a jUnit-ot? Sehogy se érted miért jó a Test-Driven-Development (TDD)? Olvass el pár írást tőle és lehet, hogy megváltozik a véleményed. A példák Java-ban íródtak, de a metodológia bármelyik OO nyelvre használható. A Misko-féle blog bejegyzések elérhetőek összegyűjtve egy PDF fájlban is Writing Testable Code címmel.

A legfrissebb bejegyzés valami nagy dobásról árulkodik a Google részéről tesztelés témában. Röviden összefoglalva azt írják, hogy az utóbbi 20 évben a tesztelés nem fejlődött sehova. A munka nagy része teljesen manuális, az automatikus teszteket minden apróbb változás után módosítani kell. Eközben a technológia óriási léptékkel fejlődött; 20 évvel ezelőtt még senki se hallott az internetről. Itt jön képbe a forradalmi Google teszteszköz ami végre nagyot lendít a tesztelés folyamatán.

"Imagine writing a single simple script that exercises your app, the browser and the OS at the same time and using the same language. Not enough for you? Imagine building an app and having it automatically download all applicable test suites and execute them on itself."

"Képzelj el egy olyan script nyelvet, amellyel egyszerre lehet a programodat, a böngészőt és az operációs rendszert tesztelni. Nem elég? Képzeld el, hogy fejlesztés közben az ekszköz letölti magának az összes alkalmazható teszt csomagot és le is futtatja magán." - a szerző szabad fordítása.

Elég vadul hangzik. Kíváncsi vagyok mit főztek ki a Google srácok. Így elsőre valami olyasmit tudnék elképzelni mint amit a GWT (Google Web Toolkit) tett a JavaScript-es AJAX fejlesztéssel. Az első részletekre mindenesetre nem kell már sokat várni, hisz már máricusban lesz róla konkrétum.

A Java egy viszonylag egyszerű és könnyen használható nyelv. Ennek ellenére programozás során könnyen bele lehet futni furcsa dolgokat produkáló kódba. A következő példa jól mutatja, hogy milyen veszélyeket rejt, ha nem minden esetben követjük a nyelv íratlan szabályait. A specifikáció apró részleteiről, illetve a fordító/futtató környezet apróságairól már jobb nem is beszélni.

A következő kódrészlet az int-Integer autoboxing-ot (dobozolás) mutatja be. Az int számok átkonvertálása Integer-ré elég költséges dolog. Amikor pedig többszörös konverziót hajtunk végre vagy egy hosszú ciklusban használunk ilyesmit akkor érezzük magunkat rosszul. A dobozolás egy lassú folyamat.

A következő kódrészlet egy egyszerű dobozolási példát mutat be. A kérdés, hogy mit ír ki?

Integer i1 = 100;
Integer i2 = 100;

Integer i3 = 2000;
Integer i4 = 2000;

if (i1 == i2) {
   System.out.println("i1 es i2 megegyezik.");
}

if (i3 == i4) {
   System.out.println("i3 es i4 megegyezik.");
}


A nyelv fejlesztői tisztában voltak azzal, hogy a dobozolás nincs ingyen; ezért is alkalmaztak gyorsítást. Ennek az a lényege, hogy -128 és alapesetben 127 között az int Integer-ré alakítása során már előre legyártott értékeket ad vissza a dobozoló. Így már érthető lesz a programrészlet fura kimenete. Tehát aki arra tippelt, hogy az "i1 es i2 megegyezik" jelenik meg a kimeneten az jutalmul megnézheti az anomáliát előidéző kódrészletet az Integer osztályból:

public static Integer valueOf(int i) {
   if(i >= -128 && i <= IntegerCache.high)
      return IntegerCache.cache[i + 128];
   else
      return new Integer(i);
}

Tanulság: két objektum egyezőségének vizsgálatára mindig az equals() függvényt használjuk, sose az objektumok esetében csak referenciák összehasonlítására szolgáló '==' jelet.

Megjelent az Eclipse legújabb, Galileo névvel fémjelzett kiadása (3.5). Lehet rohanni letölteni. (lnk) A régebbi verziót még érdemes megtartani, hisz az Eclipse megjelenésen kívüli pluginok kompatibilitásával még lehet gond.

Az összehangolt kiadást bármelyik IT projekt megirigyelheti. Egyszerre 33 projekt tucatnyi lusta fejlesztője volt képes összehangoltan, használható verziót kiadni.

A 33 projekten összesen 380 ember dolgozott 44 különböző cégnél. Ez azt is jelenti, hogy átlagosan egy projekten alig dolgozik több mint 10 ember. A munka nagy részét pedig valószínűleg még kevesebben végzik.

Hamarosan kanyarítok egy rövid írást az ujdonságokról. Annyi már most jól látszik, hogy ez a kiadás inkább apróbb változtatásokat tartalmaz csak. Első indításra az új Welcome screen kivételével szinte lehetetlen változást találni. A nagy változások a már készülő 4.0-ra várnak.

Az IDE-k nagy hátránya, hogy egy viszonylag egyszerű funkció eléréséhez is sokszor menük mélyére kell túrni tucatnyi klikkeléssel. Ez megszakítja a "flow"-t, csökkenti a hatékonyságot, és a 115.-dik alkalommal borzasztóan unalmas is lesz. (Copy-paste menüből, valaki?)

A programozó legjobb barátja a billentyűzet. A szerkesztőkben vagy IDE-ben pedig a a különböző billentyűkombinációk.

Egyik nagyon hasznos billentyűkombó az Eclipse-ben a 3.3 óta elérhető Quick Access (Ctrl+3) az az "gyors elérés". Ennek segítségével az Eclipse összes elemét (menüpontok, beállítások, nézetek, stb.) elérhetjük egy gyorskereső funkció segítségével (lásd kép). A camel case is támogatott. Tehát PE-re a Pacakge Explorer és a Project Explorer is előjön.

Másik hasznos billentyűkombináció a Quick Switch Editor (Ctrl+E). Ez a megnyitott szerkesztő (tabok) közötti váltogatást könnyíti meg. Aki sok ilyet szokott megnyitni az örülni fog ennek a funkciónak.

Mostmár csak az kell, hogy valaki tényleg rendesen megvalósítsa a funkciót. Egy valódi, bővíthető Eclipse command line-ra lenne szükség. Elég legyen olyat beírni, hogy "run project1" a project1 futtatásához vagy "new class JavaClass1" egy új osztály léterhozásához az aktuális projektben. Mint az Ubiquity a Firefox-hoz.

Eclipse alatt dolgozó Java fejlesztők bizonyára már tapasztalták, hogy mennyire lassú tud lenni az Eclipse, különösen induláskor illetve több plugin használatakor. Csodák nincsenek, som múlik a processzoron vagy merevlemezen és egy hibás vagy lassú pluginen se lehet segíteni, de jól megválasztott JVM paraméterek sokat tudnak javítani a teljes környezet tempóján. (Ez egyébként bármilyen nagyobb méretű Java programra igaz.)

Az alábbi paramétereket az eclipse.ini fájlba kell beírni a -vmargs sor után, soronként egyet. Az ini fájl az Eclipse telepítés könyvtárában található (legalábbis Windows alatt). Amennyiben nincs -vmargs sor a fájlban, akkor hozzunk egyet létre és ez után írkáluk be a megadott paramétereket. 

-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=256mEzek a paraméterek a JVM által felhasználható memóriát állítják be. Az "512m" 512 MByte-ot jelöl, ha valaki úszik a memóriában akkor nyugodtan írhat 1024-et is (~1500 fölött már csak 64-bites JVM-mel és 64-bites Eclipse-vel érdemes próbálkozni.)

-Xverify:nonea rendelkezésre álló memória bővítése mellett nem árt megadni, hogy a JVM ne ellenőrize a bytecode-ot, ez gyorsítja az osztályok, így az egész rendszer betöltését.

-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

 Ezek a beállítások a Garbage Collector működését módosítják. Ezek kifejezetten rendszerfüggő paraméterek (lásd források). Aki nem biztos a dolgában az csak az első két blokkban ajánlott paramétereket állíts

Egy fejlesztő (mérnök) teljesítményre vonatkozó igéreteket csak teszteléssel hajlandó elfogadni. A változtatásokat egy frissen telepített Eclipse 3.4.2 + Aptana Studio (RadRails és Python) alatt teszteltem. Tesztelés előtt párszor elindítottam az Eclipse-t, és fix Workspace-t állítottam be, hogy minimalizáljam a változó dolgokat. A tesztgép egy Core 2 Quad (2.5Ghz), 8 GByte memóriával. Az eredmény:

A különbség jelentős ezen a gépen. Nem csak számokban, hanem érzetre is. A beállítások eddig nem okoztak problémát.

Olvasnivaló a témában: Forrás, Netbeans.org: JVM performance switches, Java 5 Garbage Collection Tuning.