Openlaszlo 4.0 béta bekukkantás

Még jó hogy csak béta, mert nálam tökre nem ugyanaz történik a flash-es runtimeban mint a dhtml-esben. Fedora 6, firefox. Mondjuk linuxon ez a flash plugin is büntet időnként egy memory leakkel.

Az ajaxosok élete se csak játék és mese, mást nem tudok mondani biztatót. Kérem kapcsolja ki.

TeamCity

Megnéztem a Teamcity CI szerver demóját, hát tényleg hajmeresztő, nagyon jó koncepciói vannak bár kipróbálnám hogy vajon mit tud maven projectekkel, na meg hogy testNG-t nem tud menni, a modernebb teszt koncepciók valószinűleg nincsenek benne. Viszont az a koncepció hogy a CI szerver maga tartsa számon a teszt eredményeket és a analízis eredményeit, hogy aztán onnan lehessen riportolni, hát... pont ilyenről álmodtam. Még 11 hónap karácsonyig :) 200 dolcsi fejenként, ehh, a per seat licenszelés az mindig szívás, nem is kell inkáb.

Egyszer kicsit hasonló IDE integrációt csináltam a continuumhoz és eclipse-hez, életem első és azóta is egyetlen eclipse pluginja :-D Aztán átpasszoltam egy indiai srácnak aki átírta egyébként elég frankón, kiadott egy snapshotot aztán ennyi jó ideje. Így megy ez.

Beágyazott ESB egy springes webalkalmazáshoz

A webappba beágyazott dolgoknak mókás kis kultúrája fejlődött ki az utúbbi néhány évben. Kell adatbázis, de nem akarjuk hogy a felhasználó babráljon vele, bedobunk egy Derby-t, kell esetleg MQ is, de az még babrásabb mint egy adatbázis, na jó, akkor bedobunk egy ActiveMQ-t. Kellene kimenő és bejövő adatokat kezelni, integrálni más rendszereinkkel (tipikusan open source cuccokkal).
Erre az igényre tervezem bevetni a Mule ESB-t, konkrétan a yikulju opcionális spring context-darabkáival, és ehhez jön nagyon kapóra a Mule AutowireUMOManagerFactoryBean osztálya. Az a ApplicationContextAware cucc automatikusan megkeresi az inicializáció során a mule objektumokat a context-ben, így opcionálisan be tudjuk válogatni a különböző ki/bemeneti rendszereket, paraméterezés a már leírt módon, megint semmi máshoz nem kell nyúlnia normál esetben a deployernek, csak a web.xml-hez. Én azt se szeressem, de tényleg nem találtam még ennél kevésbé szívatós megoldást :)

Na, ez a terv.

Hogy válik az ember architect-té

Na erre nekem is van egy változatom :)

A munkahelyén robot, otthon pedig éjfélig vakít az ívfény. Ez ilyen magyaros betyáros undergroundos dolog, magam tapasztalataiból.

Meghatódós percek

Előkerült egy cipősdobozból egy 6 évvel ezelötti merevlemezem. Te jó ég hogy ezen mik vannak... például egy korabeli debian aminek tizedik nekifutásra eszembejutott a jelszava, egy PostgreSQL FAQ fordítás, valószinűleg az első amit írtam mert befejezetlen, java cuccok béta kiadásban amiknek mára még a koncepicói is elavultak.
6 év alatt annyi minden elmúlik, néhány dolog viszont 10 év alatt sem :)

TestNG apocalEclipse

Szóval az eclipse support gyógyítása: eclipse restart. Érdekes. A teszt paraméterezés is megyeget, de ezt még nem igazán találtam ki hogy hogyan kellene használni. Azt szeretném, ha a Continuous Integration szerveremen (continuum konkrétan) be lehetne paraméterezni hogy milyen adatbázis szerverek vannak installálva például és azokon minden végrehajtani a DAO implementációk tesztjeit, és persze minden implementáción. Ha már egyszer elvetemült idealista vagyok akkor abban már nyugodtan lehetek szélsőséges fajta :)

Amúgy ma miközben az itthoni miniclusteremet pofozgattam elszállt a másfél éves maxtor vincsim, amin egyébként a home partíciót is tartom, de kimenekítettem. Vegyetek ti is sok maxtor vinyót, nagyon jó hangja van amikor azt mondja hogy "nyekkk"!

N-edik visszapattanás a TestNG-ről

Ma ismét megpróbáltam átportolni egy projectemet TestNG-re, mert nagyon megtetszett hogy jobbára már működik az eclipse TestNG pluginja a 3.2-es eclipsemmel. Hoz pár olyan dolgot ami frankó lenne végre bevetni, test grouping, paraméterezés, ilyesmi.
Aztán rájöttem hogy az eclipse pluginja is csak jobbára működik, a maven-nel a 5.1-es verzió pedig egyáltalán nem. Kb ugyanez áll a Junit 4.1 verziójára, annyi kivétellel hogy az eclipse alapból tartalmaz már egy "junit 4" futtatókörnyezetet, ami konkrétan junit 4.1-gyel megy. Tökre nem mindegy hogy 4 vagy 4.1, de stablinak tünik. Már csak maven support nincs hozzá.
A surefire SVN-beli verzióján is látszik hogy 5.1-es testNG-vel tesztelik, úgyhogy lehet figyelni a surefire 2.3-as verzióját, vagy átnyergelni a SNAPSHOT-ra és lőni mozgó célpontra.

A törpök élete se csak játék és mese. Mint azt közismert :)

Spring context xml-es okoskodás

Visszatérve kicsit a hiperkorrekt maven rad-os gondolathoz (de nem csak azzal kapcsolatban), hogy ugye előre definiált datasource-ok és ilyesmi, csak most kicsit több aspektus. Konkrétan a yikulju kódjában próbálok valami végleges és nagyon pöpec rendet teremteni a unit tesztek közt, és itt jutott eszembe az hogy ha már lehetőség van a tesztek paraméterezésére, akkor megoldhatjuk azt hogy a például egy DAO teszt lefusson a fejlesztő környezetétől függően Derby-n vagy PostgreSQL-en. Mióta O/R mappinget használ az ember felületesen fölöslegesnek tünhet mindez, de azért van pár kivétel amire jó elég korán rádöbbenni, ha nem kerül túl nagy erőfeszítésbe.

Na, megint elkóboroltam a kiszemelt témától. Szóval a spring context XML-t hogyan robbantsuk fel darabokra úgy, hogy az elég rugalmas legyen és ne kelljen beleírkálni egynál több file-ba a végfelhasználóknak. Ezzel jól célozza az ember a the long tail-ben található felhasználóbázist, de még nem zárja ki a nagyhalakat sem :)

Na és valami ilyesmit találtam ki erre:

• Az adatbázis connection pool kerül külün context xml-be, ilyen elnevezési tradícióval mint pool-...xml. Ennek konkrétan két implementációja lehetséges, az ultralusta végfelhasználók és minimalista futáskörnyezetek számra beágyazott commons-dbcp és a szabványos JNDI lookupos akármi. Mindkettő implementáció persze ugyolyan nevű beant definiál, pl "dataSource"
  
• Adatbázis függő adatok számára külőn XML-ek. Ez olyanokat tartalmaz mint a JDBC driver osztály neve (amire java 1.6-ban már nincs sokáig szükség, de most még kell ha senki más nem tudja), hibernate dialect, esetleg a compass dialect.
• Külső konfigurációs adatokat a kontextusba ágyazó BeanFactoryPostProcessor, ez idáig az egyetlen Spring-függő dolog benne, de ilyet talán máshol is lehet implementálni. A unit tesztek egyszerűen csak importálnak egy másik ilyen preprocesszort definiáló XML-t ami például a System.properties alapján helyetesít be konfigurációs adatokat és mehet is a műsor. Nem kellett copy-pastelni a konfigot alkalmazás és tesztek közt.
  Például amikor webappot hegesztesz, a webapp egyszerűen csak a web.xml-ben definiálja context változóként a kellő konfig adatokat és megmondja hogy a teljes alkalmazás melyik XML-ekben található bean-ekből áll össze. Emberi módon felsorolva, JNDI, postgresql, webapp, opcionális bean-ek.
  

És itt most az a kérdés vetődik fel hogy ez vajon tényleg elég egyszerű-e a fejlesztőknek és a felhasználóknak, valamint elegendő plusszt nyújt-e ahhoz hogy ezzel érdemes legyen egy konkrét fejlesztés során babrálni. Kiderül.

Esti gyorsjelentés

Na, egy kicsit egyedi megoldás került be a yikulju SVNbe, amiről kicsit magyarázkodnék.
Kicsit gáz volt az hogy az alkalmazás mindenféle konfigurációja mindenfele a webappban megtalálható, hibernate konfig file, applicationcontext, web.xml, satöbbi. Az applicationContext-ből kikaptam pár dolgot amire több lehetséges implemntáció van.

1. Adatbázis connection pool. Beágyazott DBCP a lustáknak, vagy JNDI lookup-os csilivili a mazohistáknak, és persze más-más adatbázis típusokkal. (ezek kerültek a db package alá)
   
2. Index megoldások. Kicsit elbizonytalanodtam a compass frameworktől, ezért a Directory implementációkat kitettem egy-egy külső xml-be.
3. Opcionális szolgáltatások (jelenleg az egyetlen az IRC robot) az opt package alatti xml-ekben.

Na és ezeket vállogatja össze az alkalmazás integrátor (ami csak egy role és tudjuk hogy magunkat kell érteni alatta mert minden role mi vagyunk amit kitalálunk) a web.xml-ben, valamint context paramétereket passzolgat hozzá ahol szükséges. Például ha behúzta az IRC robot szolgáltatást akkor a irc szerver nevét context paramként. Ezeket a spring ServletContextPlaceholderConfigurer osztályával beillesztjük a applicationContextbe inicializációkor. Iletbve ezt még kicsit kiegészítettem mert nem tudta megmondani hol van a WEB-INF, és én oda be akartam tenni a derby adatbázist.
A lényeg az hogy a web.xml az egyetlen file a webapp-ban amit módosítania kell bárkinek is. A mégjobb az lenne ha még azt se kéne :) Nade ne legyek mohó, holnap is legyen új a sun alatt.

Java 1.7 fejlesztőbosszantó

A java.net-en már a sokadik kérdés van szavazáson a jdk 1.7 (vagy marketingeseknek 7.0) újításairól. Az eddigi eredményből a Language-level XML support népszerűtlenségét emelném ki. A closures (vajon ezt magyarul hogy fogjuk mondani) viszont jól szerepel. A groovy biztosan bejött pár embernek :)
Izzik parázs vita a javaforumon is a dologról.

Compass vs Lucene

Vajon illik-e a másik project package struktúráját felvenni azért hogy hozzáférhessünk a package-protectred dolgokhoz benne? Aki kapott már olyan hogy "sealing violation", az valószinűleg azt mondja erre hogy nem igazán. Én már kaptam ilyet az arcomba, ott egy ravasz srác hekkelte meg az Oracle Advanced Queue package strukturát ahhoz hogy menjen Bea Weblogic alatt mint JMS. Jajj, azok a régi szép gyári hegesztőmunkás napok.

A jelenlegi eset az a Lucene és a Compass framework.
A compass framework sok hasznos dolgot adna, imádnám érte. A JDBCDirectory-n keresztül együtt tarthatjuk az indexet az adattal, ugyanaz a hely, ugyanaz a tranzakció. A Lucene helyett meg nincs más.
Szóval ezen is van mit kalapálni.
Mindenesetre a Yikulju-ban a lucene index directoryt is kipakolom külső context xmlekbe, legalább had legyen választása a felhasználónak még ha minden választás rossz is :(

Spring context és a java.util.Properties osztály érdekességei

Ez a probléma mindig előjön amikor spring contextekben java.util.Properties objektumot kell passzolni valamelyik objektumnak. A probléma az az, hogy a spring ilyan Properties objektumokat csinál:

Na és ez piszok mód statikus. Ebbe a properties-be senki nem szól bele. Többnyire ez nem baj, csak vegyük példának egy olyan esetet, hogy van egy hibernate-re épülő szoftverünk, amihez külön kontextusba kipakoltuk a hibernate különböző beállításait és az DataSource konfigot. Ebben az esetben azt szeretném, ha abban a külső XML-ben legyenek definiálva egyes tulajdonságok. Például a hibernate.dialect.
És akkor jön a gonosz Copy-Past Coding, mert ezt minden springes projectben ahol felmerül ennek az igénye ezt beletúrom.

public class PropertiesFactory implements FactoryBean {

 private Map properties;

 public Object getObject() throws Exception {
     Properties props = new Properties();
     props.putAll(properties);
     return props;
 }

 public Class getObjectType() {
     return Properties.class;
 }

 public boolean isSingleton() {
     return true;
 }

 public Map getProperties() {
     return properties;
 }

 public void setProperties(Map properties) {
     this.properties = properties;
 }

}

És innentől már lehet Map-ból csináni a Properties-t ezzel a factory bean-nel.
Na, erre szivesen megnéznék egyszer valami más megoldást :) Is there anybody out there?

Ötletelős percek - Maven RAD

Csináltam egy friss blogot, konkrétan ezt olvasod, írogatok majd ide mindenfélét technikai dolgokról. Java főleg, linux, clusterezés, open source projectek, villanydemokrácia, meg ami jön. Utálni fogtok érte :) Na, vágjunk egy "in medias res"-t a lovak közé!

Elmentem ma mérni, és mivel ez különösebben nem egy intellektuális tevékenység, azon gondolkodtam hogy összeállítani egy korrekt architektúrát web alkalmazásokhoz igencsak időigényes dolog, de vannak dolgok amivel meg lehet gyorsítani a fejlesztést.

Itt van például a grails. Beírod hogy ant create-project, ott is vagy, megvan a projected. Az acegit mondjuk kicsit kalapálni kellett, de legalább jobban képbekerültem groovy-ban meg acegiben. A friss grailsben viszont ott van az amin én is mennyit vacakoltam, openlaszlo integráció. Szóval közelebb hozza az álmot hogy a webapp-fejlesztés gyorsan elstartolható, meg ilyesmi. Feketemágia akad az ilyen *rails dolgokban bőven, nem csak a fejlesztőkörnyezetbe veszi be magát, hanem a futási környezetbe is, kiszedni meg nehezebb mint teljesen újraírni az egész cuccot.

Egy érdekes próba lenne maven alapra tenni egy RAD projectet, ami két részből állna.

1. Egy maven archetype, amivel gyorsan létre lehet hozni egy hiperkorrekt, bár üres projectet
2. Egy plug-in amivel gyorsan le lehetne generálni DAO interface-ket és implementációkat, valamint a view oldalból is létrehozna egy templatet.

És akkor definiálom hogy mi a hiperkorrektség nálam mostanság.

• külön projectekre elválasztva a modell, az alkalmazáslogika és a különböző felhasználói felületek (webes felület, web service, swing, portlet, ilyesmi), integrációs projectek
  
• deklaratív tranzakciókezelés alapból, mert tranzakciókezelés úgyis mindenhova kell, ha meg nem akkor úgyis könnyebb kivenni mint beletenni :)
  
• Azonosítás, dettó, bár ezen még azért érdemes lenne okoskodni
• Persze mindez korlátokkal, mert a tökéletes ember és szoftver még amerikai szuperhősfilmben sincs. Acegi, spring, alapból JPA-ra generált DAO-k. JPA mögé persze Hibernate, mert úgyis boldog boldogtala lecserélni meg elméletileg könnyű. Nem próbáltam még.
• Generált tesztek a DAO objektumokhoz, alapból például Derby-n, de persze opcionálisan bármi máson.
• Alapból beleintegrált riportok minden alprojecthez,
  

Az hogy a view dolgokat milyen framework-re generálja, azt nevezhetjük lényegi kérdésnek. Ezt jó lenne pluginelni.

Szóval elbonyolítani már sikerült, mindenesetre teszek egy próbafúrást a területen, hátha feltör az olaj és én leszek a Bobi Juing. Vagy a Dzsoki inkább, mer` ő gonosz.