Drools, Planner

Mostanában eltöltöttem egy kis időt egy prototipus projecten ami a drools planner integrációját késziti elő az oVirt-be. Ez még nem azt jelenti, hogy valaha benne is lesz, csak azt, hogy megpróbálom feltakarítani a környéket és beintegrálni. Gondoltam pár tapasztalatot megosztanék vele kapcsolatban.

Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)

IDE

Szóval a szabályokat egy speciális nyelven írod le, erre van több opciód is. Ez végül sima plain java bytecode-dá fog lefordulni. Szóval ez forráskód, ha tetszik, ha nem. A forráskód, amit írnod kell java-jellegű. Éppenséggel én nem szeretnék ilyeneket írni vim-ben, szóval az IDE támogatásnak utánna kellett járnom.
Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezei hazugság marketing, nincsen benne :-) A drools csomagok közűl kellett letölteni egy lefordított verziót és felinstallálni. Pár varázslót és egy editort kapsz, az editorban van syntax highlighting és egy kevés code completion. A vim-élménynél azért lényegesen jobb, de el tudnék képzelni barátságosabbat.

Pár tapasztalat

Első alapszabály a drools-hoz általában: bármilyen szabályt írsz is, ne legyen benne hálózati/adatbázis interakció! A drools kegyetlenül elkapja és nagyon lassú lesz vagy agyonterheli az adatbázisod. Valószinűleg mindkettő. Csinálj szépen in-memory modelt. Elösször tölt, aztán kiértékel. Sajnos ez nem mindig egyszerű.

Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.


Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.

A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.

Planner

No nézzük mi ez a planner. A planner optimalizációs feladatokra segít adni valamilyen megoldást, a drools expertre építve. Ez konkrétan úgy történik, hogy pontozási szabályokat írhatsz le drools szabályokkal, írsz hozzá pár sor XML konfigurációt (ne aggódj, java config is van ha még nagyobbat akarsz szívni) és ráengeded a megoldó algoritmust. Visszakapsz egy megoldást jó esetben, és a hozzá tartozó elért pontszámot.

A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.

Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)

Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.

Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint

• maximumUnimprovedStepCount, azaz ha egy ideig nem talál jobb megoldást, akkor itt hagyjuk abba.
• scoreAttained, azaz egy bizonyos minimális szintnél tovább már nem kell tovább menni.

Azért a terminációs szabályokhoz én el tudnék képzelni jobb döntési logikát is, legalábbis az adott feladathoz én valami pontosabbat szeretnék. Majd bizonyíthatom, hogy tényleg van jobb ötletem, mert a drools planner-rel megetethetem a saját implementációmat.

Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.

Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.

Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)

Indigo - eddig

Nagyjából átálltam az új eclipse release-re minden projectemmel, pár észrevétel eddig:

• Mi a szösznek van még mindig benne a CVS kliens? Ki használ CVS-t 2011-ben?
• Viszont defaultból benne volt az egit, az szép.
• Szintén az alap csomagban benne volt a maven plugin is (m2eclipse) - na végre, csókolom, 2011 van!
• Megintcsak az alapcsomag része google által bedobott GUI designer, amit a heliosba is belegyömöszöltem, de ebben alapból benne van. Öszintén szólva az egyetlen dolog amiért hajlandó voltam átbóklászni néha netbeans-re az a GUI designer volt, viszont ez jobban tetszik. Végre egy használható GUI designer swinghez, SWT-hez és azt hiszem GWT-hez is működik.
• Egy csomó szép új plugint felfedeztem. Ilyenkor néha elszáll az agyam és próbálgatok, de az igazat megvallva nagyon kevés plugin éli túl nálam az első hónapot. Meglátjuk hogy lesz most.
• Egyes pluginokat nagyon nehezen sikerült beszerezni. Pl a google web toolkit plugint égen földön kerestem a marketplace-ben, aztán a GWT UI létrehozásakor felajánlotta hogy letölti.
• A legtöbben az eclispe marketplace-t használják (én is preferálom) pluginok beszerzéséhez. Hát ez az utóbbi időben a legváltozatosabb hibákat generálja a szerver oldalán.

Szóval 2011-ben is, eclipse az IDE.

Sonar eclipse plugin (FYI)

András hívta fel a figyelmem erre a pluginra, igazi frankó cucc :-) Amúgy nem szeretem pluginekkel telezsúfolni az eclipse-t, stabilabb biztosan nem lesz tőle, de ez egy értelmes ötlet: ahol hegesztek, ott nézhetem a hegesztés minőségét is és javíthatok rajta.

Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.

Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...

final paranoia

Az utóbbi években összeszedtem néhány furcsa programozási szokást, ezek közül az egyik a final kulcsszó agyonhasználata. Nem meggyőzni akarlak, de leírnám hogy mi vezetett ide, illetve miért maradt így a dolog.

A final kulcsszót általában illik mindig odaírni minden static mező (aka osztályváltozó, de hívjuk inkább konstansnak mert jobb ha nem változik :) ) mellé. Ezen elég rendesen túlléptem...

• final-ként kezdtem el deklarálni minden paramétert, mert olvashatatlannak tartom, amikor egy metódusban új értéket kap egy paraméter -és a környezetem bővelkedik ilyenekben. Persze aki belenyúl a metódusba, az a final-t is letörölheti, de az már plusz munka, lehet könnyebben talál rá más megoldást.
  Az eclipse clean-up parancsa gyönyörűszépen támogatja a paraméterek final-lé alakítását és utánna nagyon szépen látszik hogy ami nem lett final, az valahol értéket kap...
  
• Innen már csak kevés kellett ahhoz, hogy azokat a lokális változókat is final-nak deklaráljam, amik egyszer kapnak értéket és aztán csak olvasni kell őket. Úgy tűnik könnyebben olvasom a kódot ha nem kell azzal foglalkozzak, hogy egy változó tartalma hogyan változik pár kilóméterrel lejjebb.
  Az eclipse clean-up persze ezt is támogatja. Persze defaultból ki van kapcsolva, be szoktam kapcsolni.
  
• Még egy lépéssel később pedig egyes service beanekben final-nak kezdtem deklarálni egyes mezőket, pl egy DAO esetében egy DataSource vagy ilyesmi, ami nélkül teljesen semmi értelme nincs az életének és kár is lenne nélküle megszületnie. Na ezzel már nagyon csinján kell bánni, mert pl a spring a konstruktor argumentumok módosítását nem támogatja a talán leginkább elterjedt PropertyOverrideConfigurer-rel. Szóval csak olyan lehet, amit biztosan nem kell egy konfig file-ból módosítani.

Na, most jobb...

Közben 2 éves lett ez a blog, ez pedig pont a 200. bejegyzés. Köszi a 4.5-ös átlagot! Rosszabbra számítottam az XML-es posztjaim után. Ez után a post után lehet kiérdemeltem volna pár hármast is.

Egy kis BDD

Újra itthon, több mint egy hétig mászkáltam mindenfelé és közben tanulgattam dolgokat. A legtöbbnek ezek közül a világon semmi köze nincs programozáshoz a nevükön kívül.

Viszont akadt kis idő arra is, hogy beszélgessek emberekkel az integration test megoldásaikról. Én igazából erre is tök egyszerű junit 4.4-et használok és nem fáj különösebben. Valami fény végre derengeni kezdett viszont arról is, hogy akik fitnesse-t hajtanak, azok miért szeretik. Korábban ugyanis sikerült rendesen félreértenem a dolog lényegét, csak annyit láttam belőle hogy valami furcsa wiki engine-t kell felstartolni érdekesen összehaxolt classpath-szal és majd az lefuttatja a teszteket. Ez a pontja még most is rém ellenszenves, de ez csak esztétikai kérdés.
A lényeg az lenne inkáb, hogy program írása nélkül, wikiből editálva építheted az integrációs tesztjeidet. Ez a wiki nem kell hogy egy központi szerver komponens legyen, felstartolhatod magadnál is, vagy ha nem komállod a felületét, írhatod egy sima text editorból is (ami talán kicsit barátságosabb is mint maga a wiki). Így nem azt írod le, hogy hogyan kell a kódodat letesztelni másik kóddal, hanem egy felhasználói történetet. (Azaz story, csak magyarítok újabban) A történet táblázatokból és kommentekből áll, a táblázatokat úgy nevezett fixture-k mondják meg, hogy hogyan kell őket felhasználni. Például az utolsó oszlop az elvárt eredmény, az többi a paraméterek, legegyszerűbb esetben. Azaz a wiki tartalma a fixture-kkel együt mondja meg, hogy hogyan kell a kódodat letesztelni :-)
A fitnesse-maven integráció a srácok szerint akkora gebasz, hogy jobb róla nem is beszélni. Úgyhogy valami kis custom ant+maven dolog van belőve.

Csak hogy ne legyen az, hogy akármit bekajálok amit vendéglátóim adnak, átfutottam pár könyvet agile testing témakörben és szétnéztem hogy mi a helyzet más megoldásokkal, és a diszkóblogos srác easyb projectjébe már sokadszor botlottam bele, sikeresen túl is jutott az ingerküszöbömön végre és kipróbáltam hogyan műxik. A meséket itt körülbelül groovy-ban írod, ami elég egyszerű szintaxis, még eclipse plugin is van hozzá (bár nem sokat ér szvsz). A webes wikis dolog a fitnesse-ben szerintem nem különösebben nagy érték, ha érték egyáltalán, ugyanis a nem technikai project tagok azt sem fogják tudni csinálni helyettünk. Úgyhogy a maven-integráció (működik) és az IDE support azért egyelőre mégis inkáb ebbe az irányba terel.

Ennyi van most, aztán kiderül később, hogy hogyan és merre tovább. Csinálok pár prototype projectet és megpróbálom beilleszteni más projecteimbe.

SWT

Éppen mostanában átfutok egy SWT könyvet, hogy kicsit rendbetegyem a fejemben ami eddig az SWT-vel kapcsolatban bele került innen-onnan. Pár dolog, ami első nekifutásra nem tetszik...

• Az SWT konstans interface. Kusza mindenfélék halmaza. Widgetek attribútumai, eventek nevei, minden. Tudom, hogy a java 1.5 elött nincs enum, de akkor is szét lehetett volna robbantani pár kissebb osztályra. Használhatóbb lenne.
  
• A checkSubclass() metódus mindenképpen érdekes módja az örökldésen való akadékoskodásnak.
  

Kiváncsi vagyok mikor dobják el az 1.4-es java stílust és építenek kicsit más felületet.

Napfogyatkozás

Azt hiszem az ganymede usage data feltöltésre reflexből a legtöbb ember nemet kattint, viszont azok akik bekapcsolják, azok hasznos statisztikai infókkal látják el az eclipse alapítványt. Mellesleg ez publikus is, így megtudhatjuk mit használunk a legtöbbet az Eclipse-ből. Érdekes átnézni, nem meglepő módon a debug parancsok és nézetek igen előkelő helyezést értek el, viszont eléggé ott van a JEE perspektíva is.

IDE + csapatmunka

Nézegettem ma az ECF dolgait. Erre épül a cola, amiről a tréfás kis videó készült. Önmagában az ECF talán csak annyit tud mint egy instant messenger. XMPP, MSN, IRC protokolok, esetleg extra, hogy a saját szerverén keresztül tud screenshotokat küldözgetni, browsert meg view-kat indítani. Lassan feljönnek majd a rá épülő pluginok és valószinűleg lesznek érdekes dolgok köztük.

Nem tudom, hogy a piac mennyire mozdul rá az IDE-be ágyazott csapatmunka support témára, de lassanként a gyártók belelendülnek.

Megnéztem hogy mennyire free most a jazz.net. 1200 dolcsi fejenként :-) hát... a béta mindenesetre olcsóbb volt. Remélem a TEAM project hamar hoz valami használhatót ingyen, mert ez az ár teljesen esélytelen.

Off: lassan rendbejön a jobb vállam, ezt már félig jobb kézzel írtam, úgyhogy újra nekikezdek valami kalapálgatásnak hamarosan.

Eclipse Demo Camp log

Tegnap mindannyiunk legnagyobb örömére kijött az eclipse 3.4, amit ma Eclipse DemoCamp-pel ünnepeltünk meg. Én csak az első 3 prezentáción voltam bent, sajnos a hőmérséklet kint legalább 5 fokkal alacsonyabb volt mint bent, és nem volt mindegy az az 5 fok. Lássuk...

1. Bardy Szabolcs - Application model visualization using Eclipse GEF
   Nekem ez segített kicsit fellebbenteni a ködöt, ami az eclipse belső plugin rendszereit fedi. Magamfajta tucatprogramozókat nem érdekli az IDE infrastruktúrája, egész addig amíg valami lehetőséget nem látnak benne. Most már látok :) Volt demó is, ilyesmi. Kicsit az időben talán elcsúszott olyan dolgokon mint az MVC magyarázat, szerintem nincs ember aki nem tudná mi az.
   
2. Szentiványi Gábor - Advances in TEAM
   
   Azzal az alcímmel, hogy hogyan fűzzük szorosabbra a földrajzilag elosztott fejlesztőcsapatunk kommunikációját. Ismerős probléma, aki ezt megoldaná nekem, az megcsinálná a munkám felét :-) Ez valami olyasmi lesz, mint az IBM jazz cucca. Eddig a jó hírek. Rossz hír, hogy a fejlesztés még csak most kezdődget, a weboldal például totálisan semmitmondó és volt itt valami kanyar a .net-tel és a visual studioval.
   
   Azt hiszem az IBM jazz már ingyér van, érdemes talán azzal kezdeni ismerkedni. Az IBM szoftverektől ments meg uram minket.
3. Szántó Iván - Introduction to JBoss tools
   A JBoss eclipse-alapú fejlesztőkörnyezete. Régebben próbálgattam, a hibernate tools csodajó, de mióta JPA-t használunk már az sem rulz, a többi pedig szerintem csupa olyan dolog volt, ami benne van egy mezei eclipse-ben is. (Az "Eclipse for JEE developers" dologban). Viszont láttunk valamit a JBoss Seam-ból, ami első ránézésre handy kis RAD, szép IDE support is volt, viszont azok után hogy Iván cetliről átmásolt egy URL-t egy ajaxos komponensben valahova, nem biztos hogy bele mernék vágni. Nincsenek ilyen varázscetlieim :(
   

Továbbá megtudtam azt, hogy van aki kipróbálta a flexclipse-t :-) Köszi minden visszajelzésért mindenkinek, nagyon örültem, és amint normálisan rendbejön a jobb kezem és a közérzetem, folytatom a hegesztést.
Találkoztam eclipse gurukkal egészen nagy mennyiségben, például egy srác mesélt egy ötletéről amin dolgozik: egy pluginnal méri az időt, amit a kódod bizonyos részein töltöttél, és az alapján logol. Egész hasznos lehet ebből valamilyen riportot csinálni.

Holnap valószinűleg kicsit hittérítek WTP ügyben céges keretek között. Mi még mindig ant-tal buildelünk, a turnaruond nálam úgy 3 perc. Ezen szeretnék kicsit javítani. Például 3 másodperccel kibékülnék.

Ja és köszi a B2I srácoknak a szervezést, nagyon jó volt. Remélem legközelebb is lesz.

Flexclipse update site

Eszembe jutott, hogy van egy szerver accountom még valahol Ámerikában, úgyhogy gyorsan reggel feldobtam rá a flexclipse update site-ot. És itt van:

http://ghoul.fastcrypt.com/~lazlo/flexclipse-update-site/

Az URL egyébként remek példája annak amit mondtam JUM-on a Flex vs Openlackó ügyében. Azaz hogy ezt a László nevet nem igazán tudják leírni külföldiek.

Hétfő. Azaz kedd...

A hétvégi C++ agyeldobás közben tartottam egy kis szünetet és helyreráztam a flexclipse-ben a pluginek közti függőséget. Happy utalt rá hogy nem lesz egyszerű menet. Nem volt az :) sok helyen el lehet szúrni a dolgot. Még mielött elszúrnám valami új dolog kiépítésével, betageltem 0.1.4 verzióval. A 0.1.5 már túl lesz a belső átalakításokon és lesz hozzá update site. Aztán végre lendítek valamit a funkcionalításon. Hétfőn már ennek nem láttam neki, 7 nap gányolás (munkahelyi ganajazás és ELTE-féle C++) után a legkevesebb kedvem sem volt a szabadnapot gép elött tölteni. OKT, Börzsöny...

Egyébként, ajánlom mindenkinek ezt a kis jME izelítőt, amiben Pali gorillái is ott feszítenek :)

Flexclipse 0.1.3 - araszolós

Remélem jól tellett a hétvégétek, az enyém egész sűrű volt. Nem volt sokmindenre időm, de azt sikerült beledobni a flexclipse-be hogy egy saját file-ba dobálja be a konfigurációját. Eddig a project metaadatokat használtam erre. A project metaadatokat az eclipse a workspace-ben, de a project directory-n kívül tartja (a .metadata könyvtár, gondolom ismerős :) ) Most ez azért jobb, mert verziókezelőben meg lehet osztani, esetleg lehet generálni mondjuk maven pomból. Fel is tettem egy gyors howto-t az egész cuccról. Simán látszik belőle mennyire kezdetleges az egész :)

Most erről a verziókontrol dologról eszembe jutott hogy holnap reggel megint egy perverz verziókövetőt kell rugdalnom. Minden héten háború.

Update: Közben Happy kijavította egy elvetemült dolgomat a kódban, azaz megvan az első contributor :-) mégfontosabb hogy sok hasznos tanácsot kaptam. Hétközben remélem akadgat majd időm javítani a cucc kinézetét, és akkor lesz update site...

Flexclipse 0.1.2 @ googlecode

A flexclipse kódját átmozgattam az otthoni svn-ből a googlecode-ra, és megvan az első tag (0.1.2) is azóta. Ha akad időm ma este, össze ütök egy kis howto-t hozzá. Azok vannak benne amiket eddig felsoroltam, még estére talán ad valami támogatást a skinezéshez (CSS) is.

Meg keresek még helyet update site-nak...

Flexclipse még mindig...

Tegnap este még maradt időm két dologra a Flexclipse prototype projectben:

1. Belerúgtam egyet a project icon decoratorba. Most a flex projecteken gyönyörű (soha ilyen szépet nem rajzoltam) ikon ragyog.
2. Összekötöttem a flex compiler progressmonitorát az eclipse progressmonitorával. Hát értelmes eredményt nem sikerült ezen a téren látni, még utánna kell nézzek hogy vajon jó hívásokat küldök az eclipse felé.

Ennyi ami késznek mondható most. További félkészületek:

1. Átbogarásztam az ASDT-t és próbáltam kitalálni hogy hogyan tudok belőle kiszedni valami hasznosat.
2. Megcsináltam az Outline adaptert a ASDT-hez, legalábbis a dummy implementációt. Most frankón nem látszik az egészben semmi.
3. Elkezdtam utánnanézni az XML editornak. Alapvetően ez az egész csak XML, az lenne frankó, ha egy XML editor kiterjesztésével tudnám az egészet hajtani.
4. Leszedtem a spring IDE forráskódját, hátha abból megvilágosulok az XML editorokkal kapcsolatban. A spring IDE tényleg frankó módon tudja editálni a context XML-eket. Van benne code completion is, hiba highlight, szóval a lehető legjobb dolog ihlet beszerzésére.

Ennyi. Ezek még lassan befutnak, aztán meglátjuk...

Flexclipse helyzet

Nagyon elment az idő sajnos minden mással, de most sikerült egy kicsit összeszednem annyi szabadidőt, hogy kicsit kipofoztam pár hibát a Flex 3 eclipse pluginben (amit időközben elneveztem Flexclipse-nek).
Átkalapáltam a compiler api hívásait, így egy tetszőleges file módsítása után kb 1 - 5 másodperc alatt generálódik ki a SWF. Hmm, hát közelébe sem ér sajnos a java compiler sebességének, de nem annyira sok mint mavennel lefordítani. Most már a hibák is korrekt helyen jelennek meg a fileokon és persze a Problems nézetben is.

Most az jön ezen a szálon, hogy az elhagyott ASDT-ből kiguberált kódot beleépítem, és akkor a mx:Script tageken belül lesz actionscript szinezés és code completion.
Szükség lesz majd idővel egy libraries properties oldalra is, ahol be lehet kattintani a SWC függőségeket.
Meg ki kellene kutatnom azt is hogy milyen formában lehetne publikálni a meglévő kódot.

Ezek a TODO listák olyanok sajnos, hogy csak nyúlnak, mint a régi jó "elszánt vércsiga vs gonosz manó" analízispéldában a kötél. Inkáb taszkot váltok, hátha úgy elmúlik.

Az eclipse útvesztőiben

Nézzük, mi az ábra a flex3 eclipse tákolással...

• Nagyjából megy a builder, igaz nem inkrementális, de hát ez van egyelőre.
  
• Pár ikon-dekoráció megtalálta a helyét. Én rajzoltam az ikonokat, mind az eggyet. Esztétikára nem adunk.
  
• Van kettő wizard is, ebből csak az egyik működik :-D

Ami még minimálisan szükséges lenne a használhatósághoz:

• Maven-hez flex3 mojo. Csak flex2-es van jelenleg
• És persze rendesen gatyábarázni
  

Air on linux (Alpha) gyorsteszt

Van Air runtime linuxra is végre, az internet magamfajta, másodosztályú állampolgárainak örömére. Vasárnap fel is húztam az itthoni gépemre hogy megnézzem mit tud.

• A telepítőcsomag mérete tűrhető (16M)
• Alpha létére eddig még nem hasalt el egyszer sem
• Viszont szembetűnően zabálja a processzoridőt. Ezt windowson nem csinálta. Valószinűleg a friss fedorám valami csúnyát csinált a grafikus driverrel, mert más is izzad vele, azt hiszem különösebben ezzel nem lesz gebasz.
• Az határozottan nem tetszik hogy a saját és pedig a air csomagok felinstallálásához is root jelszót kér. Hát ideiglenesen megbíztam ennyire az Adobe-ban, de ebből nem csinálnék rendszert.
  

Lassan, ahogy akad időm kipróbálom hogy mennyire jó dolog rá alkalmazást írni.

Közben lökdöstem tovább a Flex nature implementációmat eclipse-hez, beleakadtam az első eclipse specifikus problémákba is, de azért haladgatok...

Eclipse WTP furcsaság

Mivel csak munkában használok ant-ot, eddig a maven megkímélt attól, hogy saját magamnak kelljen beállítani a WTP webalkalmazás projecteim másik projecten való függőségeivel járó .

• Első lépés: webalkalmazás magában, egyszerűen csak megy, könnyed és gyors, mellesleg ez az emberek túlnyomó részének meg is felel
• Második lépés: valami egyszerű project dependency, mondjuk egy Foo osztály statikus metódusát meghívni jsp-ből. Ez is megy, a Foo módosulásaira újradeployol az eclipse, frankó.
• Harmadik lépés: legyenek a utility projectben a jar-ok. Atomkatasztrófa. Hol a classpath-szal lesz baj, hol a deploymenttel.
  

Elég kiábrándító :( Na mondjuk olyan is a fejlesztési processzünk, hogy az embernek lenne kedve elmenni messzire birkákat legeltetni. Ant, vár, ant mégegyszer máshol, megint vár, aztán tomi újraindít mert nem sikerült felnyalnia a friss jarokat, megint vár, aztán böngészővel vakarászik mert persze állapotfüggő az egész.

• Alternatív harmadik lépés (gányolás szerintem), átmásolom a WEB-INF/lib könyvtába a utility project jar filejait. Ilyenkor megyeget a dolog az utolsó manuális lépés kivételével persze.
  

Netbeans 6 beta2 testdrive hétvége

Az eclipse-em lehalt valami furcsa oknál fogva, valószinűleg egy fedore update lehetett a ludas, mert az alap eclipse is meghal fél óra alatt. Mivel nem volt kedvem kidebugolni, lehúztam egy netbeanst.
Nos a netbeans 6 béta vicces módon egyszer se szállt el, egyetlen érthetetlen hibaüzenetet nem tolt az arcomba, teljesen jófiú. A maven pluginja zseniális, editálod a pom.xml-t, és ő meg közben lehúzza a jar-okat. Jobb klikk, szedd le a forrást is. Ez csak majdnem jó, mert egyszer összebarmolt nekem jarokat és kénytelen voltam letörölni őket. Ebben persze lehet hogy megint nem a maven plugin volt a ludas, de ki mászik ebbe bele...
Viszont van az egész netbeans-nek pár számomra furcsa dolga.

• Ami eclipse-ben source -> generate getters + setters, az netbeans-ban insert code -> getters VAGY setters. Miért nem lehet a kettőt együt?
• Ctrl-space, és felhozza nekem azt az 1 választási lehetőséget amit ő gondolt, aztán mégegy ctrl-space és akkor a többit is ami van. Hmm, ez vajon miért...
• Code completion-nál behelyettesíti azt a változót, amit megfelelő típusúnak talál. Na ez hiába handy néha, ezt ha megtalálom hol kell, azonnal kikapcsolom, mert olyan tréfás dolgokat írt a kódba mint assertEquals(obj, obj) (ami tautologikusan igaz, ezért kár lenne hajtani a procit) Írhatná oda inkáb a paraméter nevét, majd átírom.
  

Végülis frankó ez a netbeans, de kérem vissza az eclipset mindenféle plugin nélkül.