Szoftver integrációs harcvonal

Amikor hogy különböző dependecy-jeim dependency-jei összevesznek egymással mert használják ugyanannak a szoftvernek két egymással teljesen inkompatibilis verzióját (például az asm verziói közül mindegyik mindegyikkel inkompatibilis) engem arra az esetre emlékeztet amikor az ember a barátnőjét próbálja kibékíteni az nagyanyjával. Nem egyszerű eset.
Megoldási alternatívák:

• dependency-k dobása, más alkalmazásba helyezése, sajnos remote-ban minden lassúbb és a telepítés is bonyolultabb
• verzió visszaváltás, ez meg többnyire csak fokozza a problámát
  

A függőség függőségének a függősége

Na ez tényleg bosszantó. Hardcore ant fanok, ezt hímezzétek a zászlótokra :) Szóval miután megírtam a red5-hoz a maven pom-ot, a következő szituáció derült ki:

• Nekem szükségem van a red5-ra
• red5-nak kell mina-spring
• mina-springnek kell spring 1.2.8
• nekem nem kell spring 1.2.8, mert én már spring 2.0-t hajtok

Na, ez a szitu, az exclude tag nem gyógyítja.
Konklúzió: a törpök élete se csak játék és mese. Majd megoldom, vagy idővel elmúlik :)

Hétvégül had lökjek ide egy félig OFF gondolatot:
Kurt Vonnegut, talán a legmeghatározóbb ma is élő író Börleszk című regényében említi hogy az embereknél az egyetértés az amolyan barátkozás-féle, az egyet-nem-értés pedig a konflikuts kiélzésére szolgál. (Lehet ezen intellektuális vitát nyitni, de nem vagyunk mi bölcsészek, én legalábbis nem, egyszerűen 26 év tapasztalatából frappáns kis igazságnak minősítettem.) Itt ugye van egy kis gáz, mert ez a szoftver iparág egy szegmensen belül is egyszerűen túl komplex ahhoz hogy az emberek tök jól egyetértsenek és zökkenőmentesen együtt tudjanak működni. Pedig ez az egész csapatsport, a csapatjátékhoz meg kell valami összetartás.
A legnagyobb kihívás talán az, hogy hogyan kezelje az ember az eltérő véleményeket úgy, hogy ne legyen az konflikuts forrása és mégis legyen haladás, transzformálódjon az architektúra. Olyan haladás amit mindenki haladásnak tart. Az ilyesmihez többet kell beszélni mint a billentyűzetet kalapálni, és legalább annyira politikusnak* kell lenni mint hegesztőmunkásnak.

*: nem a parlamenti meg általában a magyar izékre gondoltam

5letelős percek - maven POM generáló ant projectekhez

Ezt leírom amíg meg nem jön az ebédem. Mélyen hívő és gyakorló maven felhasználóként szeretnék egy toolt, ami segít ant projectekhez POM-ot generálni. Következőképpen:

• megnézi a jar file-okat, vagy a filenévből, vagy a manifest-ből kideríti hogy milyen verzió, milyen groupid és artifactid
• aztán megnézi hogy van-e olyan a maven repository-ban
• ha nincsen akkor van-e valami hasonló
• plussz hogy a jar az a project dependency-je vagy egy tranzitiv dependency
• esetleg a forrásból is lehet deríteni kifele
  

Ennyi. Júliusban van a születésnapom, akkorra :) Az ebédem meg még mindig nem jött meg...

Minden kód bűnös amíg az ellenkezőjét be nem bizonyítja

Betettem a tesztelendő eszközök sorába a guantanamo nevű ultra-radikális XP eszközt. Kitörli a teszteletlen kódot. Mondtam hogy ultra-radikális :) Mondjuk egy maven plugin még akkor is kellene belőle.
Egy csomó kérdést felvet a dolog, pl bean-ek gettereit settereit soha senki nem teszteli, és minek is tesztelné... private metódusok tesztelendőek-e vagy test against public interface?

100%-os test coverage? Örülök ha vannak junit tesztek :)

OpenLaszlo 4.0.0

Nocsak, ma jött ki az OpenLaszlo 4.0.0. Tovább nem is bíbelődök a 3.x-es szériával talán.

CAFEBABE

Remélem a jó programozó definícijóában nincs benne az hogy szereti a kávét.
(Lásd: igazi programózó (definíció), önmarcangolós percek első és második rész.)

Mostanában sereg érdekes új technológiát találok a neten, de ilyen ZH és leadandó dolgaim miatt csak kapkodok össze-vissza.
A leadandók egyetlen tanulsággal szolgálnak: általában nem a tulajdonképpeni munka viszi el az időt hanem az apró új techológiákkal vívott csata. Esetemben ez a TEX formátum, amiben a doksit írom.

A nem leadandó queue-ban legelöl:
- Az openlaszlo 3.4 audio/video streaming supportja es a red5
- struts 2 migracio
- appfuse meg mindig

Whisky in the jar

Mostanában JBoss-szal hegesztgetek a gyárban, némileg gyorsabb mint a másik lehetőség, hogy weblogic. Csodás amikor nincs egy app ráhegesztve félmillió helyen egy bizonyos alkalmazásszerverre, imádom, ezt a J2EE alkalmazás fejlesztést ezt mindig így kéne csinálni és akkor béke és szeretet honolna a földön.

A JBoss viszont tartalmaz saját log4j-t, ami király, de valami furcsa oknál fogva a webappok classloaderei is megkapják. Rejtett függőség. Hoppá, a JBoss csak most, a 4.2 verziónál fog oda eljutni hogy a classloaderei korrekten működnek?

Honnan tudhatod ha nem vagy jó programozó? II.

A tudományos megközelítés után most a legőszintébb magánvéleményemet teszem közzé:

Aki nem szereti a CSÉt, az biztosan nem jó programozó.*

*: nem ám komolyan venni

static import nyűgök szombaton

Szombati meló közben azon gondolkodom hogy szeretem-e a static importokat, ami új feature a java 1.5-től.
Hát nagyon handy feature, ha az IDE amit használsz például VIM. Szado-mazo, ultraminimlista és retrós kóderekről most feledkezzünk meg mert ők nagyon kissebbség.
Nézzük a dolgot egy gyakoribb esettel: eclipse példul. írogathatom fel az importok közé kézzel hogy mit importáljon statikusan (de rég nem írtam ilyeneket kézzel), és a kód bár rövidebb lett, nem lett olvashatóbb. Ha a rövidség olvashatóságot jelentene akkor mindenki perl-ben tolná :)

Mindegy szóval úgy döntöttem hogy így kipróbálva én ezt annyira nem tartom jó dolognak. Nyilván nyomsz egy CTRL-t és katt, és ott vagy ahol deklarálva lett a dolog, de nem igazán lehet jobban megtámogatni egy IDE-vel.

Ha húszas vagyok, az a baj, ha nincs code completion, az a baj.

Random ötletek a CI-ről

mi lenne akkor
-na jó, ez csak elmélet-
ha sokkal hosszabbra
nőne a kezem...

Kicsit aktívabb együttműködés lehetne a CI és a teszt frameworkok között. Például a project életciklusa alatti teszt-eredmény változások, futásidő, ilyesmi, ezt valahogy a CI-nek kellene megjegyeznie. Legalábbis a build résztvevők közűl leginkább rá tartozik az ilyesmi. Erről már nyűglődtem azt hiszem.
Aztán konkrétan a continuum esetében, ha már maven-t hajtunk, ha egy projectnek van SNAPSHOT dependency-je, akkor szerintem az tűnik logikusnak hogy akkor is újra kell buildelni teljesen, ha nem történt változás a forráskódban. Ugyanis a dependency-ben attól még lehet hogy történt változás. Pont erről szólna a mese. Ennek utánakérdeztem és Brett azt mondja az 1.1 már így csinálja. Frankó, csak győzzem kivárni.
Meg esetleg egy egységes felület eléjük jó lenne, mint a Cargo a J2EE szervereknek. Erre lehetne falazni a IDE integrációkat, és akkor nem kéne mindegyikhez külön plugin. Mint a JDBC driverek-nél.

Ennyi jutott hirtelen eszembe. Egyébként nyilván ha annyit használnánk mint ami már megvan, akkor is sokkal közelebb lennénk.

Bocsi a kaoitkus postolásért, ma kicsit kiégett az agyam.

Continuous Integration és az IDE közelebbi kapcsolatáról

Aki nézte a TeamCity demót, annak valószinűleg van arról ötlete hogy egy IDE (ott konkrétan IDEA) és egy CI szerver (ami az ő esetükben a TeamCity) hogyan tud igazán királyul együttműködni.

• Az IDE jelez ha a a project build fail fázisban van
• A build log böngészhető az IDE egy ablakában
• A tesztek amik elfeküdtek fel vannak sorolva, hozzá stack trace, katt és máris a megfelelő helyen vagy
• Helyből újraindítható a build
• Ilyesmi...
  

Ennyit konkrétan a Continuumal is meg lehetne csinálni. Hmm, na igen, a Continuum közel sem annyira full-feature mint a Teamcity :( Ilyen take responsibility, meg ilyesmi nincsen. Sebaj. Az a lényeg, hogy szorosabb, pörgősebb csapatmunkát segít összehozni, miközben odafigyel arra is hogy a junit tesztek lassanként ne haljanak meg a project életciklusa során. Mert azok olyanok hogy lassan meghalnak :( Ismerős szitu, nem?

Szóval még mielött erről a teamcity dologról hallottam volna, írtam ezt a continuum-eclipse-plugin cuccot, kezdeménynek szerintem jó. Egy ilyen projectre pályáztak a google SOC-on. Nem tudom hogy lenne-e rá időm megcsinálni, főleg hogy már van rá pár jelentkező. Remélem megcsinálják frankón hogy pörögjön, mert ez a dolog tényleg számítana.
A távoli jövőben. Ki használ ma (még) CI-t?
Az epamon kívül? :)

SOC

Karenin blogjából indulva kicsit végignéztem mit kínálnak a Google SOC 2007-re az ASF-nél. Na az kicsit bosszant hogy olyan taszkot is kiadtak amit én már megcsináltam :-D Nade a törpök életéről tudjátok milyen mondás járja. Mindegy, reggelig ha a C++ beadandóimmal elkészülök, kipofozom talán ezt is.

Mindenesetre nagyon érdekelnek a projectek, főleg a james, a maven és a continuum körül. Ha esetleg valaki diákként meg akarná csinálni, amennyit tudok segítenék...
...miután visszajöttem a sarkkörről :) amúgy itthon leszek egész nyáron.

Csak egy kis szájtépésbe kerül

Megjött a sztornó számla a ultrwaweb kft-től a majdnem háromszázezer forintra. Azt észrevettem én is hogy a google felkapta és a cég nevére keresve előkelő helyen szerepelt az előző bejegyzésem, gondolom az is motiválta őket kicsit.

Másik ex-szolgáltatóm, a vodafone szintén megindult a fejlődés útján, bár tétován és lassan. Ők decemberben 26.000 forinot számláztak ki nekem (miután 1 éve nem vagyunk szerződésben), majd érdeklődésemre rájöttek hogy valójában túlfizettem és visszautaltak 2.000 forintot, ennek ellenére februárban megint kiszámláztak 25.000 forintot. Hát velük többet kéne foglalkozzak. A mission critical enterprise összeadó rendszer, amit csakis és kizárólag diplomás programozók fejlesztenek náluk, az ilyen.

Következtetések:

• aki a számlázással tölti az idejét, annak nincs ideje tényleges munkát végezni. (programozni, hegeszteni, szántani, akármi)
• a diploma és a programozási képességek között nem látok semmi kapcsolatot, hiába mondják az egyetemen, hiába követelik meg egyes üzletemberek. Az elvárások 50 évvel ezelötti valósághoz igazodnak a jelek szerint.
  

maven surefire 2.3

Nyilván megirta a fejlesztő is, meg oldalt ott látszik a maven repo legfrissebb cuccai között, csak szeretném kiemelni. Ezzel a cuccal már lehet testng teszteket futtatni, mégpedig úgy maradhatnak junit tesztek is. Eddig snapshot repositoryból használtam.

Random gondolatok

Megnéztem a szép tapestry5-ös screencast-okat, amiről pár észrevétel:

• Ha a tapestry 3.x - tapestry 4.x migráció PITA, akkor a tapestry 4.x - tapestry 5 totális agyhalál. Mintha nem is lenne köze az előző verziókhoz. Lehet ez a tapestry 5 egyébként nekem is tetszeni fog, de nem szivesen migrálnék.
  
• Maven-nel buildelt az egész. Egy éve nem gondoltam volna hogy ennyire be fog futni a maven. Akkoriban szokás volt engem fikázni azért mert maven-t használok ha nincs megkötés.
  
• Java 1.5-ön ment. Az új fejlesztések könnyen elindultak a java 1.5 platformon, a tomcat és a jetty is ugyanúgy mennek vele, de alkalmazás szerverek csak úgy fél éve kezdtek kiadni verziókat amik már képesek futni a java 1.5-tel. Valamit nagyon elkavartak (a JMX volt az a valami konkrétan), az üzleti szféra durván túlnyomó része még mindig 1.4-en fut, pedig már itt a java 1.6.