Javapolis 2007

A konferencia lényege az, mint a neurológiában amikor a neuronok véletlen új kapcsolatokat hoznak létre, és idővel ha ezek a kapcsolatok nem kerülnek felhasználásra, akkor megszünnek. Valahogy legalábbis így foglaltam össze a dolgot hazafelé.

Lustáknak, a hype-témák:

1. Offline webapps és RIA. Leginkáb flex és AIR, a JavaFX-et is teljesen elnyomta a Flex téma. Elég sok prezentációt csináltak belőle, látszott hogy raktak mögé pénzt, de volt szinvonala is a prezentációknak és pozitív kép körvonalazódott a flex képeségeiről. Meglátjuk majd a Parleys.com v2-ben. bér engem méginkáb a forrás érdekelne és a tényleges projecttapasztalat, hogy mennyire fájt ezt összerakni.
   
2. OpenSource java és a nyelvi változtatások, különös tekintettel a Closures témára. Ezen a téren hatalmas viták voltak.
3. SOA és házatája. Még mindig felkapott téma.
4. Hát... Glassfish és Netbeans, de most tegyük a kezünket a szivünkre és valljuk be őszintén hogy ez már nem a konferencia közönség nagy érdeklődése miatt, hanem a Sun támogatásáért cserébe.

Amúgy a policy ez volt: a munkaadóm állta a számlát, viszonzásként igyekeztem úgy összeválogatni a témákat amiket a munkában felhasználhatónak tartok.


Első nap

• James Gosling: The state of the java universe
  Megmondom őszintén, tőle nem azt vártam hogy jó sun-os módjára az idejének felében a Netbeans-ról és a glassfishről beszéljen. De így történt. A másik felében azért beszélt a javaFX-ről is, fel is tették neki a kérdést a közönségből hogy miért kellene JavaFX-et használni Flex helyett. A sebességet hozta fel válaszként, na itt kellett volna párbajt vívniuk a adobe-s srácokkal mert ők is hoztak érdekes eredményeket később. Az androidról annyit mondott hogy ennyi idő után az android még mindig egy köd. Az android mögé felsorakozott gyártők semmi másra nem vállalkoztak mint hogy felsorakoznak az android mögé. Így igaz. Na a JavaFX állapotáról akkor most ne kezdjünk el...
  Nem szólt semmit a closures vitáról, pedig kiváncsi lettem volna mit lép rá.
• Bruce Eckel: Open Spaces
  Az antikonferenciáról beszélt, mint új közösségi formáról és annak működéséről. Ebből lehetne szerintem fontolgatni a JUM-hoz.
• Guillame Laforge: Groovy update
  Ez egy szimpi srác volt, beszélt a groovy szépségeiről, különös tekintettel a closures szintaktikáról, ami annyira hiányzik a java-ból és annyira kusza minden lehestéges implementációja
  
• Leading Opensource Midleware in Action
  Ezek a srácok nem voltak vérprofi előadók, viszont az objectweb szoftverek, amiket bemutattak, azok érdemesnek tünnek némi megfigyelésre, márminthogy amit még nem ismerek közűlük.
  
• Robert Chinnici: JEE 1.6 specification
  Tréfás egy ember. Bemutatta az annotációkat, amiket majd hasznájhatunk, hogy web.xml-t már ne is kelljen írni, REST apit, ilyeneket.
• Scrum in action for non-belivers
  Egy kis metódika, hátha valamit meg tudok belőle honosítani a pusztában. Érdekes kis scrum praktikákra is kitértek mint a póker. Az előadás végén lementem beszélni az előadóval, elmondtam a szituációt, hogy nekem olyan a csapatom hogy időzónákban is szét van osztva. Erre ő sem tudott nagy ötletet, de mondta, hogy van olyan csapatuk ami egy kontinensen szétosztva és ők wikivel tolják. Wikink nekünk is van, eddig úgy 20 installációt láttam, egyiket se használta igazán senki :-)
• The future of computing panel
  Politika.
• Adobe Open Source: Vega, Flex, Tamarin
  Az Adobe körüli Open Source szféra, volt egy bejelentés is, hogy az AMF (Action Message Format, mutatta a srác szép ábrákon hogy ez mennyivel gyorsabb mint bármilyen XML-alapú RPC vagy JSON, impresszív, de azért kipróbálásra vár részemről) implementációja mostantól Open Source. Ez remélem majd ad lökést dolgoknak.
• Neal Gafter: The Closures Sage continues
  Már vagy két éve pörög a vita a Closures kérdésről, ennek a legfrissebb fejleményeiről kaphattunk beszámolót, valamint a nehézségeiről. Itt kezdődött a vita.

Második nap

• Bruce Eckel: Think in flex
  Ezt hívom én értelmes marketingnek, Bruce Eckel kérdéseket tett fel, az Adobe-s srác pedig megmutatta, hogy hogyan oldják meg ezt Flex-szel.
• Stephann Janssen: Parleys.com V2
  A konferencia főszervezője mutatta be a parleys.com (egyik kedvenc java oldalam) második verziójának fejlesztését. Ez ilyen tréfás srác, végig azzal jött hogy ettől majd mindenkinek erekciója lesz. Tényleg valószinűleg több földönkívüli volt köztünk mint nő. Mindenesetre ezt is Flex-re írták át és AIR-en is bemutatták. Elég jól néz ki, bár nekem nem állt fel tőle semmim.
• JavaFX Keynote
  Meglátjuk mi sül ki ebből, de nem most.
• JPA 2.0
  Ez nem volt az a magasröptű dolog, de kicsit képbe kerültem azzal kapcsolatban, hogy mi következik a JPA következő verziójában.
  
• Joshua Bloch: The Closures Controversy
  Eredetileg az Effective Java Reloaded című előadását mondta volna el, ezt viszont korábban elmondta és fel is került a google videóira, így inkáb egy erősebb kiszólást tett (kicsit elkeverte a saját slideshow-ját) a closures javaslatok ellen, és pedig onnan kezdte, hogy alaposan lehordta a generics feature-t. Hmm, én azért szeretem a generics-et, csak nem szabad persze túlhasználni.
• Emanuel Bernard: Hibernate Search
  Ez egész meggyőző volt. Lucene hibernate-be integrálva. Mondjuk én jobban szeretném JPA alatt látni az egészet, de egy prototype projectet megér hogy megtudjam hátha mégis lehet...
• SOA using java Web Service
  Ezt mégegyszer nem nézném meg, JAX-WS, de nem látszott a felvázolt dolog egyszerűbbnek a nálam bevállt XFire + JSR181 + JPA + Spring felállásnál.
• Dion Almaer: Offline webapps with Google Gears
  Talán azért mert én nem szeretek javascripttel ügyködni, de a Google Gears nekem nem tünt annak a sima ügynek, szóval ha offlien webapp irányba kell menni, akkor előbb még Flex és Air.

Harmadik nap

• Location Based services
  Gondold meg kétszer mielött elmész egy partner slotra :(
• Geert Bevin: Exploring Terracotta
  Ez egy jobbfajta partner slot volt. Alapvetően a clustering témakört teljesen a terracotta uralta a konferencián. Persze ésszel kell vele bánni, és nagyon oda kell figyelni a konfigurációra, ebből is láttunk demót élőben - konkrétan a srác elszúrta a konfigot és keresnie kellett hogy mi a gebasz.
  
• Harold Carr: Project Tango
  A minden kanyarban másként nevezett SUN projectek. Reliable messaging és WS-AtomicTransactions. Főleg munkahelyi bevetésre gondolva hallgattam végig, már el is kezdtem egy kis prototype projectet rá, aztán meglátjuk meg akarom-e próbálni behurcolbni a munkehelyemre.
• Filip Neven: Unitils - easy and maintainable unit testing
  Ez nagyon szimpatikus prezentáció volt, végre valamivel kiválthatom a saját junit ragacs-projecteimet. Legalábbis megpróbálhatom kiváltani.

Ennyi, még folyt köv...

Awaylable

Holnap reggel elhúzok a Javapolis-ra, csupa fül és csupa szem leszek. Hazajövök pénteken és hangulatjelentést teszek.

SOA, WS, ilyesmi...

Olvastam a múlt héten egy olyan véleményt, hogy a SOA-ban egyszerűen nem kellenek tranzakciók, mert azok amúgy is csak üzlet-specifikus dolgok, úgyhogy legyek szives re-eninerelni a teljes rendszerünket. Ezzel vagyok jól kisegítve, egyrészt a rendszer tervezése még annyira sem az én hatásköröm mint beleszólni a mások rendszereinek implementációs részleteibe, másrészt a tranzakciók annyira természetes kis keretet adtak a programozáshoz, hogy az ember nem szivesen mond le róluk.

Most úgy néz ki, van végre olyan webservices stack, ami ismeri az ide vonatkozó WS-Coordination és WS-AtomicTransaction szabványokat, mégpedig a Sun Metro nevű cucca. Ezzel kapcsolatban megvan minden, amit a Sun cuccaiban nagyon nem szeretek:

• Zavaros névadási konvenció, minden kanyarban másképp hívják a gyereket.
  
• A dokumnetációban mindenhol más Sun termékekre hivatkozik, pl Netbeans és Glasfish. Nekem nem kell a netbeans, én azt szeretném tudni, hogy az XML-be hol kell beletúrni, és arra is fel kell készülni hogy a cuccaink soha nem fognak glasfish-en futni.
  
• A furi licensz miatt nem lehet felpakolni a maven repository-ba.
  

Szóval túlélhető, de kemény menetnek igérkezik a most indított prototype project, most még mindenki optimista. Aztán majd meglátjuk.

Az enterprise dinoszaurusz

Találtam egy nagyon érdekes prezentációt, ami érdekes oldaláról közelíti meg a szoftver-komplexitás és evolúció kérdését. Ezt szivesen megmutatnám azoknak a távoli ismeretlen kollégáknak, akik fejéből az olyan architektúrák kipattantak, mint a 31 virtuális gépen futó csodaalkalmazásunk - ami megdöbbentő módon mégiscsak egyetlen weboldal.

Ari Zilka a pojo-król

Ezt a mai nap szög-fejentalálásának minősítem.

I am not saying clustering APIs are bad, I am just saying that people when presented with the opportunity to use Java primitives will go back to the Java primitives over big enterprise-y type architectures.

Infoq interview.

JUM 2007-11-21

Most a létszám lényegesen magasabb volt, nem számoltam, szerintem úgy 20 fő lehetett.

1. Tvik: Android - Rövid és hatékony betekintés az Android világába azoknak akik nem lógtak a témán az utóbbi két hétben. Jó volt kicsit a hype nélkül hallani a dologról, így már van elképzelésem van arról hogy hol fog a technológia elhelyezkedni.
2. Czimmermann Gábor: Glassfish - Hát nekem ez az alkalmazás szerver téma mindig marad ott, hogy használjuk azt ami elég kényelmes fejlesztésnél és megbízható üzemeltetésnél.
3. Auth Gábor: MDA - Gábor megint hajmeresztő dolgokat mesélt és mutatott be. Gázos UML eszközök, kicsit keverős fejlesztési menet, ilyesmi. Van értelme ennek az MDA dolognak, de nem így, úgyhogy csak óvatosan ezen az aknamezőn.
   

Végül nem kaptam választ arra, hogy kivel futhatok össze a JavaPolis-on, úgy tűnik senki ismerőssel. Sebaj, akkor most nem klikkesednek a magyarok, majd próbálok kapcsolatépíteni.
Valaki még feljött azzal, hogy kevesen jelentkeznek előadni. Én a legkevésbé sem érzem magam hibásnak, ajánlottam a flex+xfire+spring+JPA ötpercest, csak senkit sem érdekelt :)

Egy kis konstruktívnak szánt kritikát idetolnák még a végére. Elmondja X az előadását, felmerülnek kérdések, az odáig oké, csak az Y szofter nagyon mély dolgai engem már nem érdekelnek, láttam ott a jobbszélen is embereket akik másról beszélgettek már. Valamilyen korlátot kellene szabni ennek a kérdezős időnek, erősíteni a sörözést. Igen, ez most newtech-es koppintás, de hát ha egyszer jól csinálják, akkor nem szégyen tőlük tanulni...

Enterprise software development process

Rövid, kicsit szúrós mese a policy-k kialakulásáról, egy munkatársamtól, aki azt hiszem már nem itt dolgozik...

Vegyél egy tucat majmot, zárd őket egy ketrecbe, a ketrec közepére tegyél egy banánt és tegyél rá egy automatikát, ami hidegvizes zuhannyal árasztja el a majmokat ha megmozdíjtják a banánt.
Az első néhány kellemetlen élmény után a majmok felfogják az összefüggést a zuhany és a banán között, és megverik azt a társukat, amelyik megpróbál hozzányúlni a ketrec közepén lévő banánhoz.
Lassan cseréljük le a majmokat. Az újonnan jövő majmok nem kaptak a zuhanyból, de őket is megverték akkor amikor próbálkoztak, később pedig ők is részt vettek a mégújabb majmok megnevelésében.
Lassan akár ki is iktathatjuk a hidegzuhanyt, már talán egy majom se tudja hogy mi lesz akkor ha hozzányúl a banánhoz, de fentmaradt a policy.

Nyilván az a mese egyik éle hogy az ember nem szereti ha majomhoz hasonlítják.

A másik viszont az, hogy sajnos tényleg így megy a dolog egy nagyvállalatnál. Nem majmokkal hanem emberekkel , mégpedig a szoftverfejlesztő részlegen is. A körülöttem lévő emberek közűl senki se tudja megmondani hogy miért úgy csináljuk, ahogy csináljuk, söt egyetértenek abban hogy egy talicska .... az egész. Viszont amikor azt mondom hogy akkor ma jön az óberhé, beszéljünk vele, hogy a rendszer, amit írt vagy csak bevezetett, amikor még szoftverfejlesztő volt -na az se ma volt-, az nekünk nem kell, mert mi már nem is JSP-ket írunk és nem egyenként akarjuk kitenni a módosult file-okat, akkor persze csendben szeretne mindenki egyetérteni.

Hát így soha nem fog kiderülni hogy a hidegvizes zuhany automatika működik-e még. De ha működik is, nem inkáb azt kellene kiiiktatnunk?

Felkelt a nap

Ez landolt a postaládámban az elöbb...

Kedves Partnerünk!

Ezúton szeretnénk meghívni a “Sun Java Café” rendezvényünkre.

A rendezvény célja, hogy a fejlesztői konferenciához hasonlóan naprakész, korszerű, a fejlesztők áltak közvetlenül is használható tudást adjon át a résztvevőknek. A Sun Java Café-t szeretnénk rendszeresen (2-3 havonta) megrendezni, ahol az ismeretátadás mellett célunk egy valódi fejlesztői közösség létrehozása. Terveink között szerepel a Sunos eszközökön túl általános, a Java mint platform újdonságainak bemutatása is hazai és külföldi előadók bevonásával. Hosszú távú célként szeretnénk, ha az így kialakuló fejlesztői közösség egy magyarországi Java Felhasználói Kör (Java Users Group) alapját tudná adni.

Úgy látszik a Sun-nál is rájöttek arra, hogy van igény itthon is java életre. Szerintem egészen jó blogok mennek, a JUM is megy, a javalista is... Magyarországon általában minden megy, amiért nem kell fizetni.
Szerintem lehetett valami ihlető erővel a JUM, olyan JUM-osan hangzik, csak SUN-módra fűszerezve :)

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.

Wanted

A legjobb tréfa, amikor a saját munkaadóm legeslegfelső képvieslőjének levelét spam-nak minősíti a céges levelezőrendszer.

Na viszont...

Mostanában írtam egy rakás kis progit, amik amolyan apró állandóan futó scriptféleségek. Különböző szolgáltatásokkal (wikipedia, rss feedek, satöbbisatöbbi) kommunikálnak és ezek a külső szolgáltatások természetesen időnként magukba zuhannak. Ilyenkor persze mit tehetet az ember, lelövi a kis szkriptet, majd ha felszállt a remote rendszer, újra felstartolja. A többi persze megy tovább, the show must go on.
Na, erre a fajta dologra régen ott volt a loom, meg a többi avalonos szerver. Egyetlen VM, több alkalmazás benne és JMX-en keresztül lehetett bütykölni őket. Pontosabban ezek még most is itt vannak, csak azért meggongolandó hogy kellenek-e. Mert például bizonyos dolgokat nem tudnak, amik amolyan nice to have dolgok, például shared erőforrások, például JDBC DataSource, JMS, ilyenek.

Egyrészt fel kellene kutatni a létező megoldásokat:

• GBean a Geronimoból
  
• Plexus a mavenből, de ez fut a continuum alatt is

Másrészt idefelé bóklászva kitaláltam egy saját megoldást is, persze utálok programozni, úgyhogy erre nem szivesen fanyalodnék, de egy saját megoldást könnyen össze lehetne hozni springgel, és POMStrap-pal, mivel persze maven-t használok úgy is minden fusi cuccomra. Tulajdonképpen pár classloaderrel kellene kiegészíteni, meg egy management felülettel, a többi elég evidens.

Ez kavarog most a fejemben. Meg egy mocskosul durva MSSQL-szívás erről a hétről, igazi enterprsie mese.

Térkép hoppá

Nem csak a webappoké a világ. Átfutva a java.net cikkét a JXMapView-ről, lehet hogy nem is akarok javascript-et haxolni a térképmegjelnítéshez. Kiderül. Alapvetően jobb teljesítményt várok tőle a térképre rajzolt ákombákomaim megjelenítésében.

Gyagyascript korlátok

A kis kutatóprojectemben miután párszáz földrajzi objektumot feltérképeztem (az immár nagyon kezes geo-google segítségével :) ), majd a köztük lévő 4-5000 kapcsolatot is összeszedtem, tegnap este eljött a várva várt pillanat hogy a Google Maps rémegyszerű apiján keresztül megjelenítsem.
Nos, ha a párszáz földrajzi pont nem is lett volna fájó pontja a kérdésnek, akkor a néhányezer kapcsolat köztük biztosan, és itt fényes bizonyítékára akadtam annak, amiről Auth Gábor mesélt a legutóbbi JUM-on: a javascript-re nem lehet ekkora adatokat bízni. A párezer vonal berajzolása a térképre teljesen megfogta a processzoromat pár percre és a firefox felzabált egy tonna memóriát.
Mivel ekkora mennyiséget igazából csak tesztadatnak szántam, most az az ötlet, hogy ajaxosítom a pontok és kapcsolatok felhozatalát és a térképnek csak azokat a pontjait és kapcsolatait szedem fel az adatbázisból, amik a megjelenített részen találhatóak, azt is csak valamekkora limittel, mondjuk a legnagyobb súlyú kapcsolatokból úgy százat. Azt sajnos már most látom hogy ez viszont elég szűk korlátokat ad a használhatóságnak.

Mivel lehetne jobbá tenni a jhacks-t?

XWiki-re migrálni	4 (57%)
Engedélyezni a regisztrációt	0 (0%)
Új témák (komment plíz)	0 (0%)
Korrektebb tartalom	0 (0%)
Több tartalom	3 (42%)
Egyéb (komment plííz)	1 (14%)

Összes szavazat: 7

Akkor most ezt a pollt leszedem...

Exception-kezelés alapozó PayPal-fejlesztőknek

Most mérgesen rúgok még egyet az eheti kedvencembe, a paypal-ba.

Ha van egy változónk, amit null-ra inicializálunk, majd egy try-blokkban adunk neki normális értéket, akkor a finally blockban számítani kell arra, hogy az értéke még mindig null. Ami ilyenkor ultra-ciki, a finally block elöbb fut le mint a catch blokk (ha van ilyen egyáltalán), az itt keletkező exception frankón lehelyettesíti az eredetit.

Hát így jár az ember, ha olyanok kódját használja, akik nem használnak findbugs-t.

Pár tapasztalat PayPal integrációval

Ha a PayPal sandox éppen megy, ha amerikai vagy, ha éppen a hálózati kapcsolatod is működik, ha neked nem fáj az az API amit a PayPal ad javahoz, ha reagálnak a supportosok a leveleidre, na, akkor a PayPal főnyeremény. Egyébként meg...

Rágcsálnivaló - Mátrixok, Térképek

• Jama, elég elhanyagolt szegény, mint majdnem minden ami java és matek, de nekem úgy is csak inspirációnak kell
  
• Google Map API, ezzel valószinűleg nem lesz sok meló, esetleg talán nagyon lassú, mert gyávascript, vizualizációhoz tökéletes
  
• Google Geocoder Java API, barátságosnak látszik, ha még működik is, akkor főnyeremény :)
  

Ezek jönnek most...

Emésztenivaló - gráfok

• JGraphT, gráf adatszerkezetek java-hoz, néhány algoritmussal
• Gráf megjelenítési módszerek
• Jung, szintén gráf témában, kicsit kevésbé trendi, de mintha többet tudna
  

Flexbuilder for Linux alpha

Kipróbáltam gyorsan a Flexbuilder linuxos verzióját, eddig jóbbára ártalmatlan, nem dobált hajmeresztő hibákat, viszont nem is az nagy pukk. Biztosan nem fizetnék érte párszázezer forintot. A codecompletion persze nagyon candy, de ilyet szerintem meg lehetne csinálni egy mezei eclipse xml editorral is, ha van hozzá XSD. Ha lenne hozzá.

A unit-teszt, ami évi 364 napon jó...

Aztán a 365. napon elfekszik, akkor viszont szerencsére úgyse dolgozunk, mióta a munkaadók rendelkeznek a szabadságon töltött napok felével... Ez viszont nem elég boldogító nekem, mert én szeretnék rendelkezni a 100 százalékával és nem szeretném ha pont aznap kellene ilyesmivel foglalkozni.
Felebarátaim: soha ne írjatok bean-be (azaz adatreprezentációba) olyan metódust ami időtől függően ad vissza értéket. Aki akár csak félig barátom, vagy még esetleg szeretne az lenni, az ne toljon ki velem ennyire! Mocsok nehéz rá unit-teszteket írni.
Mi lenne például ha egyáltalán semmit sem írnánk az adatreprezentációba a gettereken és settereken kívül, még származtatott property-ket sem?

Perversion of Control

Mostanában fizetett kalapálás közben gyakran találkozom azzal, hogy az emberek a spring-et éppenséggel használják az alkalmazásukban (mert hát hype, ugyebár), de nem nem úgy hogy az alkalmazást teljesen összeállítsa elstartolja, és aztán lesz ahogy lesz, hanem maguk a bean-ek startolják fel az ApplicationContext-et, mindegyik saját magának egyet-egyet, és aztán ki-lookup-olják belőle azt ami kell, például egy DataSource-ot. Onnantól meg standalone-ként gubancol tovább.
A patternt elneveztem Perversion of Control-nak.

Egyébként, feltettem próbaként oldalra egy kis szavazást, hogy mivel lehetne hasznosabbá tenni a jhacks-t. Your feedback is wellcome!

Szélességi gráf-túrázás enterprise módra

Influenza, tompa fejfájás, otthonülés, ezek mennek mostanában, úgyhogy szabadídőmben kalapáltam egy szélességi gráfbejárás algoritmuson alapuló gráfbejáró komponenst, ami viszont perzisztens táron működik és a sor is perzisztens. Konkrétan hibernate és ActiveMQ, persze tranzakcionális is, így az algoritmus bármikor elszáll, a következő indításkor újra tudja kezdeni ott, ahol legutóbb sikerült befejeznie. A szabványos BFS algoritmushoz képest ez az algoritmus egyszerre több processzen is futhat, amennyiben az elérés sorrendje nem lényeges persze.
Ez az egész akkor jó, ha távoli fa-szerkezetet szeretnél replikálni helyi adatbázisba. Például wikipédia snippekből mindmap építés, social network analízis, pagerank jellegű számítások, ilyesmi.

JUM 2007-09-14

Igen, a javaforum.hu-n elmondottaknak megfelelően azt lehet mondani hogy szinte senki nem jött el. Erről majd még kiderül hogy miért történt, de valószinűleg 1-2 ilyen megölheti a kezdeményezést :-( Na majd meglássuk. Az én tippem:

• Péntek. Péntek party-nap, randi-nap, "hazamegyek és punnyadok"-nap, "összepakolok a holnapi túrára"-nap, ilyenek. Én is lemondtam egy fontos programot miatta ám...
  
• Kicsit lehet hosszasra sikerednek az előadások, nagyon mélyre mennek egyeseknek, másoknak meg felületesek. Szóval nem elég pörgős talán.
  

Ezek voltak:

• K: web services Axis 1.3-mal. K sebesség alapján választotta az Axis 1.3-at, kiváncsi lettem volna hogy milyen az XFire-ral összehasonlítva, de az nem futott a versenyben. Szerintem nagyon nem praktikus az, ahogy az axis-t használta. Ezer bebütykölendő XML file, hosszas deployment egy axis war-ba, én még ilyet soha nem csináltam, pedig írtam már néhány web service-t, axison is meg xfire-on is. Persze a sebességet nem tudom igazán lemérni a házi gépeimen, munkában meg senkit sem érdekel ilyesmi hogy erőforrásigény.
  
• /me: Annak örülök, hogy a villámelőadás ötletével együtt belesűrítettem 7 percbe, de igazából csak 1 ember szemében láttam az érdeklődés fényét, mint kiderült ő is használja... Majd gyakorlok a szobanövényeim elött, ha lesznek egyszer.
  
• Auth Gábor: jMaki Yet another Ajax Framework. Tetszett nagyon a IDE integráció, de nem vágnék bele egy jMaki-s projectbe, valahogy úgy tűnt hogy hiába a javascript-et rejti el az ember elől, akkor is csak javascript-gurunak kell hozzá lenni.
  
• Tvik: Echo2 live demó nem volt, de jobban átjött a lényeg, én betettem a millstone mellé a echo2-t. Mondjuk itt az érdeklődésem kicsit le is csökken, szívtam én eleget a millstone-nal, intranetes webappokat pedig mostanában -hála jehovának- nem kell írnom.
  

Kérdés

A mai JUM-on, az N-edik ajax-szal kapcsolatos frameworknél felmerült bennem egy kérdés: Vajon mi az előnye a HTML+javascript megoldásnak a flash-hel szemben? K elmondott egy pár okot, de én valahogy nem éreztem az érvek súlyát, se üzleti, se technológiai szempontból. Szóval aki tudja, az ne kíméljen, komment plíííz!!!

Beszámolót írok, ha hazaértem...

JUM III

A JUM következő időpontja: 2007 szeptember 14. 18 óra.
Aki nem csak napi 8 órában foglalkozik fejlesztéssel, annak kiválló esti program.

Most az is kiderül, hogy mennyire életképes az 5perces villámelőadás ötlet. A MINA-val mondjuk már 1 hónapja nem foglalkoztam, mert egyszerűen csak működik és az ember miért is foglalkozna olyasmivel ami működik, amikor olyan sok dolog van ami viszont nem. Lehet hogy a villámelőadásokat sokkal inkáb rögtönzésszerűen kellene, 1 héttel JUM elött KB még simán van értelme, míg egy hosszabb, 20-30 perces előadáshoz 1 hét alatt aligha lehet elegendő infót összeszedni.

Leading the way

Szoftverfejlesztők státusza és tipikus hozzászólásai egy tákolócégnél...

Leading the way - "It works for me"
Moving ahead - "Well, I will fix it later"
Right on track - "I know it's wrong, but there is no time right now"

Puzzler reggelire

Amikor a java 1.5 jött, mindenki nagyon sejtette hogy milyen gebaszok következnek majd belőle. Lettek is, de azért sikerült megszoknunk a dolgot :-) Reggel bukkantam egy érdekes java puzzlerre, ami a java generics, az autoboxing és a számkifejezések kiértékelésének logikai ütközéséből jön. Persze logikus az egész.

Set s = new HashSet();
...
s.remove(i-1);

Az teljesen okés hogy az i-1 kifejezés int-re értékelődik ki, ezért Integer-re autoboxolódik, de ezt lehet tudni és ha azt is tudjuk hogy a s setben Short-okat tartunk, akkor ott nem kellene Integer-t keresni. De kipróbáltam eclipse-ben (3.3), nem mond rá semmit, az is teljesen logikus hogy miért nem. Azért mert a Set.remove metódus argumentuma Object, nem pedig a paraméterezett típus. Ha nem így lenne, lehetne errorozni és warningolni rá, de mégis így van, teljesen logikus okból: azért mert akkor törli ha az equals metódus azt mondja, az pedig fogadhat bármit, régi mese.
Azért vicces, szerintem. Valahogy az IDE-knek mégis warningolnia kellene ilyen eseteken, bár a metódusok paraméterezése helyes, talán warningolni kellene ha Set-ből nem a paraméterezett típusú objektumot próbálja a kód törölni. Csak néha feleslegesen warningolna és ezért mindenki figyelmen kívül hagyná :-(

Wikipédia ajánló

Ezt olvastam reggel, azt hiszem van némi mondanivalója az informatikai projektekre nézve is...

setPoolable - early optimization?

JDBC 4 dokó így szól:

Requests that a Statement be pooled or not pooled. The value specified is a hint to the statement pool implementation indicating whether the applicaiton wants the statement to be pooled. It is up to the statement pool manager as to whether the hint is used.

Szerintem ez egyszerűen Rossz Ötlet [TM], a pool az csak tuning, a tuningot pedig a konfigurációban jobb tartani, az alkalmazáslogikában nem, mert attól környezetfüggővé válik a kód.

Kisérletezgetés opcionális függőségekkel

Hát célba ért a jdbc-wrapper mini-project. A tartalmáról már korábban írtam, nem is nagyon érdekes, a projekt struktúra viszont kicsit kisérleti jellegű volt, és ezt most szépen le is rajzoltam, hogy majd jól megmagyarázom mindenkinek hogy ilyet milyen elegánsan lehet maven alatt és nem kell kódot generálni, úgy mint a PostgreSQL JDBC projectben. Tessék:Szerintem ez elég vizuális, és a pom.xml-ekből is elég könnyen kiolvashatóak az összefüggések, ha valaki érti a profile-okat. Jó móka a maven profile-ok.

GSD

A Google Singleton Detector igazi frankó dolognak tűnik, valami olyasmi amit szivesen látnék a maven reportok között. Egy maven report plugint összeütni annyire nem vészes, viszont a cuccos kimenete GraphML. Ahhoz hogy GraphML-ből képet csináljunk, szerintem nem lesz elég egy rémprimitív XSLT, valami okosabb dolog kellene még hozzá, mert el kell rendezni szegény node-okat. Lehet hogy mégiscsak bevetésre kerül a Chinese Junk valahol?

Mai tipp: Hogyan demotiváljuk a fejlesztőcsapatot még a projekt tényleges indulása elött?
Egyszerűen elég berángatni őket pár management meetingre hetente egyszer.

GPL?

Q: Doesn't GPL v2 + Classpath exception offer very similar licensing terms to the LGPL? Why not use LGPL instead?
A: Yes, from a practical perspective the Classpath exception establishes similar terms to LGPL. However, the Free software Java technology communities haven't chosen to use LGPL, and so we at Sun decided to follow their lead and use the Classpath exception.

FAQ itt.
Ezt azért kerestem meg, mert a reggeli hírekben a netbeans GPL with Classpath Exception alatti kibocsájtásában én is pont ezen a kérdésen kezdtem el gondolkodni. Ez azért meglep... a Java közösség legnépszerűbb licenszelési formája a GPL lenne? Mindenesetre van pár hely ahol kifejezetten száműzve van, például a codehaus, az apache-nál meg pláne.
Az is érdekes pont a képben, hogy a FSF régebben kidobta az ablakon az LGPL licenszt, átnevezte Library-GPL-ről Lesser General Public License-re, ami talán nem valami szép húzás azokkal szemben, akik addig használták.

Nem lehet hogy a napocska most a hardcore GPL-fan linuxerekre szeretne jobban sütni?

QALab felhasználóknak

A üzemeltetés elfelejtett szólni hogy elrakják a kissé perverz verziókövető rendszerűnket máshova, ennek következtében a continuum érintett pluginje letörölte a teljes forrásfát egy pillanatra. Nem lenne érdekes, de benne voltak az utóbbi 3 hónap alatt összegyüjtöt teszteredmények.
Aki QALab-ot vagy ilyesmit integrál a build környezetébe, annak javaslom hogy tegye ki a qalab.xml-t a forrásfán kívülre, esetleg backupolni is lehet...

Flex előadás

2007.08.30. 09:00 - 11:00 Adobe Flex alkalmazások fejlesztése
Ingyér. Tehát kötelező. Én viszont nem biztos hogy Pesten leszek.

Köszi Viktornak a linkért!

Hungarian Notation

Változónév konvenciók.

Az ex-magyar májkroszoftos űrtúristától származó Hungarian Notation-nak éppenséggel lehet valami értelme nem típusos nyelvek esetén. Java esetén azt hiszem nem sok, ha meg használ az ember bármilyen IDE-t, akkor végképp semmi. Egy billentyűkombináció és látod a deklarációt. Lehet hogy nem kellene már arra készülni hogy bárki is nano-val vagy vim-mel, ne adj isten notepad-del akarja majd szerkeszteni a kódot. Igazából én jobban örülnék neki ha valami frankó dologot neveztek volna el így, még valami negatív kép alakul ki rólunk...

Tegnap volt életem körülbelül első összeütközése a fortran nyelvvel. Ez egy típusos nyelv, viszont az az arc aki írta a progit a saját hangulatáról nevezte el a változókat "shit" és "fuck" névre. A szintaxis is teljesen új volt, egy ideig eltűnődtem rajta hogy vajon mi célt szolgálhatnak ezek a változók :)

Szerintem kötelezővé kellene tenni a minden projecten a kódstílus ellenőrzéseket mint pl checkstyle, mégpedig rendszeresen, a continuous rendszerben például, és a violation-ök változásait projekt-vezetői szinten figyelemmel kisérni. Mondjuk a magányos fortran cowboyok még így is lelövik pár agysejtemet, de a legtöbb megmenekül.

JDBC build (kisérlet) mavennel

No, most gyakorlatban is kiderül, hogy mennyire jó az a build séma amit ihletett a PostgreSQL JDBC driver -szerintem kicsit nehézkes- build rendszere.
Eddig így ment: az ant-os build.xml megnézi hogy milyen JDK verzió van, ebből nyilván lehet tudni hogy milyen JDBC verzió érhető el. Minden funkcionalítás absztrakt osztályokban van implementálva, ami packagelve van jdbc verziónként, nyilván az új verziók a régieket subclassolják. Minden jdbcX csomagban benne vannak a konkrét osztályok is, ezek konkrétan semmit nem tartalmaznak, csak nem absztraktak. Ezeket kell csak kizárni a buildből, a konkrét osztályokat amik nem az aktuális JDBC verzióhoz tartoznak.
Ja még van egy teljesen plén kódgenerálás, hogy a Driver is tudja hogy miről van szó.
Ami fáj ebben, az az amikor Eclipse-ben a forrást editálni kell, meg kicsit nekem túl procedurálisnak tűnik az egész.

Ami most jön az leírva nem biztos hogy egyszerűbb. Egy JDBC project mavenesítve, a fenti követelményekkel... Ezt találtam ki:

• A JDBC verziók szerint absztrakt és konkrét projectek.
• Minden projekt egy nagy projektben modul.
• A fő projekt profile-ok alkalmazásával belefoglalaja a buildbe azokat a projekteket amik az adott JDBC verzióhoz tartoznak
• A projektek közt persze megfelelő függőségek

Nyitott kérdések:

• A profile-okkal hogy lesz amikor a release, vagy az eclipse targetek futnak? Olyankor lehet nem kellene profile-ozni.
• A tesztek egymásból kellene hogy öröklődjenek, csak akkor vajon hova kellene tennem őket...
  

Persze levegőbe-beszéd, majd lesz forráskód és szines ábrák, akkor egyszerre érthető lesz minden. Nem lesz több hibám, tévém is megjavul. Szóval érdekes tapasztalatok jönnek a következő pár napban.

CI könyv

Az InfoQ publikált egy fejezetet a diszkós srác könyvéből, érdemes elolvasni, nagyon jó a gondolat a komponensek megbízhatóságának kihatásáról az egész rendszerre. 3 darab 90%-os megbízhatóságú komponensből összeállított rendszer megbízhatósága csak 73% kürül van. Azt hiszem kicsit másként kéne kiszámolni ezt, de az eredmény nem lesz sokkal szebb.

Newtech meetup 2007-08-01

Nyári punnyadás ide vagy oda, a tegnapi egy nagyon jól sikerült meetup volt. Mondjuk a hardcore és extrém informatikától kicsit távolabbi témák jöttek, de aki otthon punnyadt helyette az sajnálhatja. Ez volt:

• Trencséni Márton: SDSS. Csillagászok amikor programoznak, 10 TB-s adatbázisok, meg időnként kicsit akadozó vizualizációs rendszerek. Nagyon összeszedett kis előadás volt, el is húzódott mert mindenkit érdekelt.
• Bácsi László: Multitouch-screen olcsón otthon. Szintén nagyon szinvonalas előadás volt, jól összefoglalta, azt hiszem ez a technológia komolyan be fog ütni idővel, ha addig le nem vadásznak az ufók vagy a terroristák.
• Bártházi András: miner.hu. Mókás kis hobbiprojekt, enyhe ták izzel, de azért még jó. Persze, nem nekem kell tákolnom, felindexeli az I Will Work For Food-ot, tökéletes.
• Várkonyi Péter: Ez nem volt annyira újdonság nekem, régebben olvastam a népszabiban róla egy cikket. Nagy ritkán ott is írnak érdekes dolgokat :) Mindenesetre jó volt végighalgatni mégegyszer a történetet kicsit részletesebben. Szerintem egy hardcore matematikus biztosan nem fordulna a természethez példákért, legalábbis azok akik nekem eddig előadást tartottak, nem hiszem hogy bármikor is felnéztek volna a könyvből az utóbbi 6milliárd évben, de ezzel is szimpatikusabb a gömbőc.
  

Öntömjénezős

Jó ideje nem írtam ide, ennek pedig két oka van: a nyár és a lerohadt merevlemezem. Hála jehovának sikerült a vinyóról lekalapálni a cuccaimat egy másikra, így most ismét kicsit hegeszthetek. Bezzeg Pali éjt nappallá téve nyomja a JCRPG-t, és marha jól alakul a cucc. Ajánlom figyelmetekbe, bár én nem vagyok egy nagy gamer, de akkor is java a javából.
Mostanra az én kis patch-em is bejutott a PostgreSQL JDBC projectbe, amikor írtam róla igértem, (meg a benchmarkot is felpostoltam később) hogy majd éljenzem önmagam egy kicsit, hát tessék :) A nagyemberek is írtak róla pár szót.

Holnap a szokásos newtech meetup, majd beszámolok ha lesz valami. Egy valami biztos: nyár lesz még mindig. Az a punnyadással egyenlő.
Na, gyerünk, menjen a műsor...

Otthoni vagy munkahelyi cowboy coding

A java.net jelenlegi szavazása egész érdekes kérdést vet fel, bár az eredményei legkevésbé sem meglepőek :) A válaszolók 41 százaléka határozottan jobbnak tartja azt a kódot amit otthon, szabadidejében írt. Ennek egyrészt az az oka hogy persze annak nem kell a bonyolult üzleti környezetnek megfelelnie és lehet szabadon csak a minőségre és tisztaságra figyelve hegeszteni, viszont szerintem van egy kommunikációs oldala is. Meg hát a tudományok is, a kevésbé tudományos szakmák is (pl informatika) és a teljesen pórias munkakörök mind tekintélyelven alapulnak.
A baj az egészben az, hogy minden agymunkához kell az, hogy a melós valamennyire frankó dolognak tartsa azt amit csinál. Különben indiai szoftvergyárak futószallagai, meg a hasonló rémképek...

DAO dolgok

Ma is gondolok valamit: DAO fölé cache-kezelést kódolni egészen biztos hogy gonosz^TM dolog. A cache csak teljestmény javítás, nem pedig architekturális kérdés, úgyhogy ilyesmivel szigorú értelemben véve nem is kell programozónak foglalkoznia, majd a deployoláskor vagy az alkalmazás integrációs fázisában.
A cache-interceptor kell hogy legyen a jó irány. Már amennyiben nincs valami extrém érdekesség a DAO-val magával.
Ez se új dolog. Holnap gondolhatnék valami teljesen újat és merészet.

do... while (learned_from_mistakes);

Egy elosztott rendszerben a funkciók elosztása a node-ok között magában hordozza a bottleneck létrejöttétnek igen magas valószinűségét. Valamennyire persze mindig szét vannak osztva a feladatok, pl adatbázis szervert pakolni az alkalmazás szerverre az nem túl jó, de az alkalmazás komponensek szétpakolása dedikált node-okra, na az gyakran vezet bottleneck-hez, amellett hogy a TCP interakciók számát is jórészt indokolatlanul növeli. Lásd régi EJB.
Pontosabban ezt már nem most kezdtem el sejteni, hanem úgy 7 éve, a majdnem-első IT-állásomban. Akkor még C++ kalapáló voltam. Most itt az ideje levonni a tanulságokat technikai és kommunikációs téren egyaránt, mert a régi rossz idők könnyen visszatérnek.

Megölni Lacit egy Flex-szel...

Túl vagyok az első gyors hegesztésen FLEX-szel, igazából azt kell mondanom hogy így elsőre sokkal jobban passzol a képbe mint az OpenLaszlo. Nagyon tréfás kis dolog, és doko is akad hozzá. 600 oldalas nyomtatott könyv, hogy a nem-IT-emberek azt hihessék hogy komoly tudomány az amit csinálunk.
Hát a UI nem lett olyan csili-vili mint OpenLaszlo-val, engem kb ez érdekel a legkevésbé, viszont felmerülnek további érdekes kérdések. Szóval van még merre bóklászni.

Alapanyagok: maven, xfire, flex
Egy alap-recept: itt

WW II

Úgy tűnik én is rászabadulok egy közösségi oldal fejlesztésére. Persze minden szentnek maga felé hajlik a keze, ez is olyan "közösségi" lesz mint az akármilyen autóvásárlók baráti társasága, de hát ma minden cég a saját logóját próbálja rásütni a társadalom bőrére minnél nagyobb felületen.
A szerver specifikációk helyenként még a IWIW arányain is túltesznek, persze ez nem magyar cucc.

Na most majd megtapasztalom hogy mik a rohadt nagy terheléssel kapcsolatos matematikai alapfogalmak. Vagy nem, de azért remélem.

Az enterprise szó forditása magyarra: böszme.

JUM 2007-07-11

Sajnos közbejött egy nyilván rendkívül fontos, hasznos és érdekes telefonos megbeszélés este 6-ra, így majdnem két óra késéssel jutottam el a JUM-ra. Akkor mát a wicket közepén járt az előadás. Érdekes első benyomás a wicket-ről, valahogy semmi sem új benne, minden olyan mint valamelyik másik frameworkben, tapestry, struts, akármi. Tulajdonképpen lehet hogy mára már lefutottuk a web framework köröket és már csak az van hátra hogy mindenki magának generálhasson olyan frameworköt ami megfelel az elképzeléseinek, bekattint párszáz checkboxot és hajrá... "Na jó, ez csak elmélet" :)
Az érdekes volt hogy amikor János kérdést tett fel a maven-nel kapcsolatban, akkor az összes ex-munkatárs felém fordult, ezt láttam is, de nem tudom milyen arcot vágtam épp akkor. Biztos hangyák háborúja arcot.
Mindenesetre várom hogy felkerüljenek a videók a netre. Idén még nem tudtam normálisan az elejétől a végéig résztvenni egy szakmai konferencián, valamit át kellene paraméterezni, mert ez nem jó így.
Kicsit le is lassult a dolog menete, fél órás előadást biztosan nem vállalnék be, nem vagyok akkora showman, meg nekem hiányzik a dologból az hogy az emberek gyorsan pár szóban előadják hogy éppen mi forog a fejükben, mit hegesztenek éjszakánként, vagy mi az ami felkeltette a figyelmüket, merre jártak és milyen akadályokba ütköztek, hogyan oldották meg, milyen következtetéseket vontak le. Mint egy standup meetingen.
Meg fogok próbálni kicsit gyakoribb, talán minden JUM-ra, de rövidebb, 5-10 perces előadásokat csinálni. Vagy hát inkáb valami villám ötlet, mint előadás. Aztán meglátjuk milyen a dolog fogadtatása.

Blogot kellene írnia minden ismerősömnek, akkor csak azt kellene olvasnom :)

A nem elfelejtendő dolgok listájára

Már csak két nap a júliusi JUM-ig.
Szerencsére most nem kell mondjak semmit csak azt hogy: helló. Más most úgyse sikerülne :)

A tudomány elefántcsont tornyából jelentjük

A java.net highlights blogbejegyzése terelte egy pillanatra a figyelmemet egy érdekes specifikáció és egy szintén érdekes API felé, betettem a queue-ba.

• JScience
• JSR-275

Amennyire láttam, a Chinese Junk mélyebbre megy az algebrai alapokba. Haszontalanul mélyre, ezt persze én is tudom, igazi eltés dolog :) Na többek között az ilyenekért hagyom ott egy időre az eltét, ideje hogy valami értelmes dologgal foglalkozzak.

IWIW

Ma a meetup-on a IWIW embere fog beszélni az architektúrájukról. Erre kifejezetten kiváncsi vagyok, mert valahogy mindig az volt a sejtésem hogy valami piszokul el van szúrva az egész rendszerben pont a teljesítmény szempontjából. Történelemóra vagy fizikai kisérletek meglepő eredményekkel.
Ez ma kiderül. Vagy nem derül ki.
Kiderül hogy megtudunk-e bármit is erről.

Mit miért hogyan.

Tegnap este az elvetemültségben odáig mentem hogy meg is írtam egy célirányos SAX api prototípusát. Rendkívül primitív, de működget. Java regexpekkel :) Na, ezen még biztosan lenne mit javítani sebességben, de prototípusnak biztos elég lesz. Amíg nem találok valami mást...

NIO és XML különös kapcsolatáról

Egy vér-lassú verziókövető rendszer rejtett előnyei között van az is, hogy a reggeli update lefutása alatt simán van ideje az embernek leírnia hogy mi volt hétvégén...

Szóval ez volt: visszatértem a MINA frontra és olyan megoldásokat kerestem amivel a byte-tömbönként bejövő adatokból XML-t parsolhatok fel. Az evidens megoldás az az, hogy startolok egy új thread-et és annak átpipeolom a cuccot, ott már nem baj az hogy az ott figyelő akármilyen XML api blocking hívásokkal operál. Viszont kihasználom így a MINA architektúrájának előnyeit?
Idealista gondolat, kevésbé szabadelvű országokban lincselés járhat ilyesmiért, de szerintem egy olyan SAX api lenne jó ide, aminek megmondom hogy bejött ennyi byte az inputról, amit tud eddig azt hívja meg a handleren amit adtam neki. És úgy lészen.
Kutattam hogy valakinek van-e ilyesmi, de nem igazán. Akkor ez biztos valami perverz ötlet. Mindenesetre teljesen biztos vagyok benne hogy amennyiben persze a speci XML api nincs elfúrva, ezzel a megoldással gyorsabb fürgébb az XML üzenetek fogadása.

A speci SAX apihoz talán még annyit hogy lehet egy áthegesztett régi is jó. Csak az IO rétegét kell áthegeszteni. Szóval háború lesz, de hát a törpök élete se csak játék és mese.

WS-Transactions

Második nekifutás WS-Transactions a falnak.
Vagy nagyon advanced dolgot akarok, vagy nagyon nagy hülyeséget, ez remélem hamar kiderül, mindenesetre az élet tranzakciók nélkül piszok nehéz tud lenni, még akkor is ha web servicekről van szó. Persze egyszerű esetekben (örüljön az akinek a munkája egy egyszerű eset) egy tranzakcióban egy WS hívás van, ha sikerül akkor azt lehet mondani hogy oké, ha meg elfekszik akkor rollback és megpróbáljuk később esetleg. Nem ilyen ideális az élete azoknak akik kénytelenek egynél több hívást indítani egy tranzakcióban, főleg ha adat módosításáról van szó.
Kicsit utánnanéztem a WS-AtomicTransaction speckónak, találtam hozzá egy WSDL-t is, szóval akár implementálni is lehetne, csak elöbb gondol, mert annyira azért mégsem sürgős. A saját implementáció azért merül fel lehetőségként, mert még mindig senki sem csinálta meg. Pedig már nem annyira új a dolog, kiváncsi vagyok mi lehet az oka.
Mindenesetre egyelőre egy implementáció lehetőségét keresem, nem túl bonyolult, a kliens oldara kell egy tranzakció interceptor ami a kliens oldalon figyeli hogy létezik-e tranzakció, a hívott WS támogatja-e a tranzakciókat, meghívja a WS-Transactions api megfelelő hívásait, aztán prepare és commit esetén ilyesmi. A szerver oldalon pedig a transaction-managerrel kell összehuzalozni.
Húú, ha csak ilyen igazságosztásból kellene megélnem biztos rohadt könnyű lenne. A gond például a prepare hivásnál van, ahhoz programozói szintről vajon hogy lehet hozzáférni... Sehogy, mi?
Ilyenek lesznek...

Pár link..

• Guy Pardon előadása a Javapolison
• WSDL (Lényeg)
• Speckó, ezt is el lehet olvasni...
  

OpenLaci @ jhacks

Igazából nem lehet panaszkodni az OpenLaszlo dokumentációjára, opensource project létére egész jó :) Persze az is meglátszik a doksi határain hogy a supportból és az oktatásból él a cég. Na ez az, amire egy jó magyar munkásembernek soha nincsen pénze, még ha szoftverfejlesztő is.
Amire igazán kiváncsi lennék az inkáb valós életbeli példák, hogy ki hogyan integrálja spring frameworkkel, hogy használja a data bindinget, hogy ír benne formokat, ilyesmi.
Az első openlaszlo felhasználói találkozón sikerült pár PHP-s sráccal gondolatokat cserélni, bár az nekem kicsit távoli, de semmiképp sem haszontalan. Azóta csend van, mondhatni a magyar OpenLaszlo közösség szép start után elpárolgott.

Úgyhogy elkezdtem a jhacks-on összeírni az OpenLaszlo-ról amit eddig kibányásztam belőle. Majd haladgatok ahogy van időm. Na igen, mostantól kicsit több időm lesz mint eddig. Ha valakinek van kedve nyugodtan szóljon, adok accot és lehet belenyúlni.

Mennyi az annyi...

A JDBC tuningolós bejegyzésben említettem hogy elég impresszív sebességnövekedést lehet elérni olyan dologgal amihez a kliens kódon semmit nem kell változtatni, na itt van egy mérési eredmény.

• AMD 1600-as postgres 8.1 szerver
• AMD 2400-as java kliens, sun jdk 1.6, default VM opciók
  
• persze linux mindkettő
  
• 10/100-as ethernet

Szóval átlagos cucc.
Prepared statement cache nélkül a teszt kód 647 ms
Prepared statement cache használatával a teszt kód 550 ms
A teszt kód egyébként insertekből és deletekből áll, selectekkel valószniűleg nagyobb a különbség mert nem játszik annyit a lassú merevlemez, vm-tuninggal meg méginkáb, mert nem játszik annyit egy rosszul paraméterezett VM. Csak most mindehhez fáradt vagyok.

A kettő között annyi a különbség tehát hogy az első mindig újra létrehozza a PreparedStatement objektumot és újra átküldi a SQL stringet a szervernek, a második eredmény pedig enélkül, csak kis pool logikát használva.

Ez így olyasminek tűnik aminek érdemes utánnanézni holmi tuning esetén, nem?

OSFlash konferencia neten

Akinek van ideje ilyesmire egy deathmatch-pénteken (konkrétan holnap), az ugorjon be bátran egy OSFlash konferenciára, webes persze. Olyan dolgokról beszélnek majd mint flex, red5 és openlaszlo, többek közt.
Lesz róla felvétel is persze, így legalább én is meghallgathatom egy hullaszombaton.

Június Newtech Meetup

Kicsit dotnetes volt, ami nekem ugyanolyan távoli volt mint 2 éve vagy 3 éve, meg teljesen elvetemülten marginális ufótechnológiák. Az előadások mégrövidebbek lettek, és mégkeményebben betarttatták az előadókkal az időkorlátot. Szerintem kicsit túl rövid is lett, mindenesetre annyi biztos hogy ilyen rövid időbe nem fér bele az hogy az előadó bemutatkozzon, azon túl hogy elmondja a nevét persze.
Pazmandi Tamás: Űrhajósok dózisterhelésének meghatározása. Űrtechnológia, a híres magyar fejlesztés, Farkas Bertalan, űrsiklók, arányok és ilyesmi. Tetszett, aki bővebben akar ilyesmiről hallani annak ajánlom az epret.
Kisko Attila: Silverlight Az erő gonosz oldaláról. Még nincs kész a dolog, de valami olyasmiről szól mint nekünk az openlaszlo+red5 meg esetleg flex. Náluk is vannak még problémák, de több pénz és fejlesztő, valószinűleg hamar meglátjuk mi lesz belőle.
Gránicz Ádám: Funkcionális programozás és F# Ádám a vicces nevű funkcionális programozási nyelvről beszélt ugyanazzal a magabiztossággal és lendülettel amivel a nőkről beszélt szinte megállás nélkül amikor még egy csapatban dolgoztunk. Matematikusok a matematikusokért, l'art pour l'art. Ádám egyébként akkoriban eclipse plugint hegesztett OKML-hez, szóval nem lehet azt mondani hogy nem ismeri az erő jó oldalát. Ja, mert ez az egész dotnet.
Marosi István: Karakterfelismerés Ex-Recognitás arc, rövid elméleti összefoglaló a karakterfelismerési technológiákról. Birtam a recognitát, az utódait meg nem igazán.
Németh Ádám: Egységes Instant Messaging hálózat Magyarországon? Jabberről és a köré halmozott dolgokról. Azt hiszem nem is annyira technológiai ismertető volt mint inkáb egy terv és problémás terület ismertetése. A probléma az hogy a szolgáltatók nem akarnak együtműködni, a terv az hogy de mégis kéne, valahogy így, na és a nagy szabvány az a jabber ezen a téren. Jó is a jabber :) Az nekem nem derült ki hogy kinek vagy milyen szervezet a képviseletében beszélt, de szimpatikus ötlet.

Bénázások MINA-val

Kifejezetten szimpi dolog volt a SEDA, és a különböző feldolgozási fázisok bepakolása pipeline-ba, akár IoC-ből is összedobható, mint egy álom :) Szóval első látásra szerelem volt a MINA, a próbahegesztések is jól mentek vele, de aztán furcsa dolgok jöttek elő vele. Egy primitív XML-alapú protokolt akartam összedobni, gondoltam pár perc XStream-mel. Na nem egészen, ugyanis itt szépen szétaprítva kapod az üzeneteket, nem ám holmi stream-ként. Azt meg nem eteted meg egyetlen XML parserrel sem, stream kell és kész. Ehhez találtam a StreamIoHandler-t, ami ugyan nem filter, hanem handler, így csak a pipeline végére passzol, sebaj, na ezzel jöttek aztán a bajok, elnyelt adatok, blokkolt stream, úgyhogy kicsit rákerestem hogy hogy is kéne megfelelően használni, és azt az egy javaslatot találtam hogy leginkáb sehogy :-(
Feltekertem hát Normafára, legurultam, de a problémát ez sem oldotta meg, szívós egy probléma. Esetleg valaki futott már bele ilyesmibe?

Kis JDBC tuning...

Ezt az egészet eddig is tudtam persze csak nem ennyire jól :) Egy éjszakai debug-party alaposan beleverte a fejembe.

Szóval JDBC prepared statementek használatában az a szép, hogy a JDBC Driver -persze paraméterezéstől és implementációtól függően- akár létrehozhatja az adatbázis szerveren a query plan-t, és ezután már csak a paramétereket küldözgeti át. Ez persze csak akkor hatékony, ha sokat használjuk a prepared statementet.
Na és hogy tényleg hatékonyan tudjuk használni, ahhoz például pool-ozhatjuk. Ezt a pool-ozást megvalósíthatja maga a JDBC driver, de a legtöbb alkalmazásszerver is a datasource-okban csinál ilyesmit, azt hiszem a DBCP is például. Ez azért fontos pont, mert nekünk, tudatlan végfelhasználóknak nem kell azzal foglalkoznunk hogy a PreparedStatement-jeink akkor legyenek lezárva ha már tényleg nem akarjuk használni.

A sebességnövekedés egyébként elég impresszív, nem csak a GC-t kíméli hanem az adatbázis szervert is, ami ultrakritikus pontja minden információs rendszernek, valamint a hálózati terhelést is csökkenti kicsit.

A bibliát is jobban tudja
A nőkkel is jobban durva

Járt útat járatlanért

Munkaadómnál, a HumanBrainProgramming Inc-nél a VeryBigCompanyOfAmerica OurOwnVersionControlThatRunsOnlyOnOurSoftware verziókontrol rendszeréről átmigrálunk lassan a CompletelyUnknownCompany VerySpecialProductWithANiceName termékére. A migráció első szárnypróbálgatásai sikeresnek tűnnek, az infrastruktúránkba behelyettesíteni viszont rémálom. A continuous integration rendszerek közül tegnap óta már 4-et kipróbáltam hogy melyik hajlandó vele együttműködni. Eddig egyik se. Az előző megoldást is csak egy continuum SNAPSHOT verzió (pre-alfa) tudta elvinni.

A relációs adatbázisoknál az SQL nyelv azért annyit ért hogy a leggyakrabban használt objektumokat (táblák, tárolt eljárások, triggerek, kütyük és izék) minden termékben ugyanazt a nevet kapták, nagyjából ezek mind ugyanazt csinálják.
A verziókezelőknél ezt a harmóniát még nem sikerült megközelíteni, persze mind kb ugyanazt tudja, de teljesen másként nevezi. Írhatnánk egy SVN-VSS szótárat azoknak akik még nem láttak VSS-t. Bár remélhetőleg már nem is fognak, ha eddig megúszták.
A continuous integration szerverek teljesen a technológiai görbe elején vannak, nemcsak hogy mindent másként hívnak bennük, de a koncepciók is egészen hajmeresztően eltérnek egymástól időnként.

HttpSession használati útmutató

A "felhasználói ülésszak", magyar szakfordításban, ha valaki még nem ismerné.

Szóval arra jöttem rá, hogy cache-nek használni a HttpSessiont közvetlenül, az nem vezet sok jóra. Az actionokban minden tele lesz a cache maintenance logikával, pedig nagyon nem oda való. Viszont könnyen be lehet húzni egy cache implementációt interceptorral a DAO réteg alá, ami backendként használhatja a HttpSession-t is (ha nincs más), így ha az adathozzáférési réteggel nincs semmi gubanc, egyszerűsödhet az adatkezelés tényleges holtprimitív DAO hívásokra. Többnyire. De azért az interceptor logikájával megizzadtam kicsit.

Mostanság erre a nem odavaló dologra jó példákat hoz az élet, például a pornófilmforgatás a munkahelyi ablakom alatt...
Valamint véletlenül átmentem matekból így ebből is kell szóbeliznem. Csupa zavaró dolog.

Zavar az adásban

Azt hiszem a PMD-hez és általában az összes kód-ellenörző szoftverhez hasznos lenne egy extra prioritás paraméter ami egy ruleset-hez megmondja hogy mennyire komolyan kell venni. Például a cyclomatic complexity dolgokat komolyan kéne venni, az pedig hogy egy paraméter nem final pedig lehetne final az is hasznos, de akkora mennyiségben fordul elő, hogy eltakarja az egyébként ennél sokkal komolyabb problémákat.

Jhacks újra elérhető

A JHacks (Java Bütykölő Bázis) visszatért, ismét új domain címen. Régi tartalom, majd ahogy van időm kalapálgatom.
A snipsnap igazán nullfeature wiki, a nagy előrelépés az lenne ha le tudnám váltani, például egy xwiki tetszene.

Mégegyszer köszi Attilának és Kareninnek a segítségért!

A napos oldalon

Nos, rövid lesz mert csak 12:30 körül estem be. Abban a másfél órában amíg ott voltam, semmi marketing nem volt. A sun-os arcok opensource feliratos pólóval (hacker-divat :) népszerűsítették a Sun új stratégiáját. Mindegy, ami szabad, azt szeressem. Nézzük.
Netbeans: Jól beszélt a srác. Az élő demó során persze bugok is előugrottak a rejtekhelyükről, hiszen még csak nem is RC, de kellemes előadást tartott. A GUI editor még mindig veri az eclipse VE-t, viszont a netbeans-nál nekem sokkal jobban tetszett az a kis open source beszéd szintetizáló cucc, amivel a srác demózott, imádnivaló :) A Netbeans Profiler is szép demót kapott persze, bár sok újat nem tudtam meg róla.
OpenESB: Kicsit gyakorlatlanabb előadóval, de amúgy szerintem egy jó áttekintést kaptunk az ESBről és a Netbeans képességeit és láthattuk egy-egy screenshot alkalmával.
És itt el kellett rohannom jegyet beíratni. Nagyon nem jó hogy nem tudok egy szakmai konferencián végig ott lenni, pedig voltam ma 1 órán át olyan meetingen amin fogalmam nem volt hogy mit keresek...
A szünetben összefutottam régi munkatárs arcokkal, persze pont azzal nem tudtam beszélni akivel akartam,

A SUN-nak jár egy köszi, fincsi volt az üdítő, jó volt a hangosítás, én nem láttam marketinget, az előadók pedig jól vágták a témát, már amennyi előadáson ott tudtam lenni :(

A PERMGEN OOM szelídítése

Frank Kieviet ír a blogjában a túlságosan is jól ismert permgen hibáról, és egész érthetően elmondja hogy mi vezet ide. Innentől boldogság lenne, ha lenne valami eszköz ami gyorsan felderíti nekem hogy pontosan mitől történik, hogy nekem már ne kelljen. A karácsonyi kivánságlistámra. Vagy inkáb a születésnapira, de addigra úgyse lesz kész, hacsak nem a jövő évire. Valami build lifecycle-be illeszthető dolog lenne jó.

Elméleti tapasztalat

Egy új szerzetes ment oda a Mesterhez.
- Mester, kérlek mondd el, hogyan láthatom meg a Lényeget?
A Mester ujjával rámutatott egy VAX-terminálra.
- Mi az ott?
- Egy VAX-terminál - felelte értetlenül a szerzetes.
- Mondd el nekem, hogyan láthatom meg a VAX-terminált?
A szerzetes immár tökéletes zavarban felelte:
- 'Ugy, hogy ránézel, Mester.
A Mester erre iszonyú haragra gerjedt, és a terminál-klaviatúrával ütlegelve elzavarta a szerzetest.
(Zen-Fóthista példázat)

Alighanem én is így járnék ha megmutatnám azt a kis projectet a Mesternek (természetesen maven és java 1.5 :) ) amiben modellezgetem az ELTE matematikai tanait.
De nem ez a Lényeg. Nagyon sok generic típus csináltam vele, egészen a halmazelmélettől felépítve a programozás elméletig, és úgy tűnik hogy a egész kellemes generic típusokat írogatni. A C++ template osztályoknál legalábbis sokkal olvashatóbb és igazából a korlátaiba se nagyon ütköztem bele. Szóval minden tudományos összehasonlítást mellőzve: jó cucc, még ha csak syntax sugar is.

A napos oldal

A Sun fejlesztői nap méretre évek óta szép nagy - nyilván, ha egyszer ingyenes :) - és a tartalma és tarthat számot némi érdeklődésre, én legalábbis már évek óta várom hogy az ESB technológia elterjedjen kishazánkban.
Viszont a Sun-nak valószinűleg szembe kell néznie azzal a kihívással hogy mindenki szines marketingcuccnak veszi azt ami onnan jön. Vajon így sikerülhet-e ezeket a technológiákat belopni a magyar köztudatba, vagy Sun-os perverziónak tűnik majd a nagyközönségnek?

Ezek derülnek ki csütörtökön, többek közt.

JHacks.hu vs hiperkorrekt cikkek

Javában tartanak a megszorítások^H^H^H^H^H^H^H^H reformok, így megy ez nálam is sajnos, amivel nem akarlak fárasztani titeket de ennek lett az áldozata a múlt héten a jhacks.hu. A háborúban áldozatok vannak*
Legeslegeslegelösször hackers.forgeahead.hu címen volt elérhető. Ezt akkor azért csináltam hogy az akkor széthulló cég-csapatom valamivel pótoljam és a kialakuló közösséggel el tudjam vinni az ajánlkozó projecteket. Na persze nem így sikerült, (tapasztalat levonva persze :) de mindenesetre az oldal akkor elég jól haladgatott. Mindenki csak hozta a saját kedvenc dolgait. Ebből adódóan soha nem volt hiperkorrekt, minden snip olyan volt mint maga a szerzője, kézzel lehetett tapintani a stílust akkor is ha nem olvastad el a szerkesztő nevét legfelül.

És pont ezzel kapcsolatban jutott eszembe az a kérdés hogy jobb-e (értsd: célravezetőbb-e) az ha egy wiki hiperkorrekt próbál lenni. Na és arra jutottam hogy szerintem nem, de leírom pár érvemet hogy miért nem:

• A magyar IT szaknyelv legkevésbé sincs letisztulva, az erőszakos magyarítások állandóan tréfák tárgyai. Például a bög (inode) és a felhasználói üllésszak (HttpSession).
• Elég dinamikusan változó mesterség, amit ma még így látunk, azt holnap már másként.
• Tele vagyunk flame-ekkel.
• Ha valaki van olyan jó arc hogy összedobjon pár dolgot arról amit kitapasztalt akkor köszönök szépen minden hasznos információt, nem unatkozó bölcsészekhallgatók vagyunk, sajnos :)
• Nyilván egy JUM-on jobban átjön, meg bármilyen más konferencián, de azt hiszem a kissé szlenges kifejezéseink jobban árnyalják véleményünket és ezáltal a tapasztalatainkat is, mint egy teljesen hiperkorrekt és száraz szöveg.
  

Kb ennyi. JHacks-ból nem lesz tankönyv. A tankönyveket úgy írják, az órákat úgy tartják, hogy ha a diák vizsgán mérgesen mutat egy tételre, akkor mondhassák hogy hát le van írva a könyv megadott oldalszám tartományában, el lett hadarva órán valamikor, jobban kéne figyelni. Ugyanakkor semmi felelősséget nem vállal a tanulmányi eredmények alakulásáért. Ez a stratégia szerintem a versenyszférában nem célravezető. Valahol a tacit knowledge háza-táján járkálunk, azt hiszem.

*: És a törpök élete se csak játék és mese. Tudom, hogy nagyon unalmas vagyok :)

Van élet a halál elött

A POI 3.0 a múlt hét pozitív meglepetése. Nagyon sok ideig volt alfa, pár hónapja még mindig alfa volt és semmi jele nem mutatkozott hogy ez változna, akkor le is mondtam róla. Amikor a microsoft XML formátumot tett lehetővé az Office csomag szoftvereinek, akkor kicsit ki is fogta a szelet a POI vitorláiból, hiszen lehet onnantól egy XML APIval is ügyeskedni. Persze koránt sem bármit, a XML formátum ugyanis nem enged olyanokat mint chart-ok. Persze a POI sem, de legalább meghagyja a már létezőt szóval templatelhető.
A Horrible SpreadSheet Format visszatért.

A másik nagy visszatérő apacs a xindice. Évekig kellett várni hogy mozduljon. Vajon a JCR technológiával nem redundáns kicsit? Az XML adatbázisokhoz még csak szabvány API sincs, leszámítva hogy XQuery meg XPath. Meglátjuk.

Sejtés

Két olyan számomra szokatlan dologgal néztem szembe ami a mai nap kihívásait adja:

• Állapotfüggő DAO réteg (nekem valahogy a nem állapotfüggő olyan természetesnek tűnik)
  
• Logikai réteg és prezentációs logikai közötti szoros kapcsolatok

Mindez egy cache architektúra kialakítása kapcsán, na ezzel kapcsolatban is lesz még mit kitalálni. A dolog másik oldalát nézve:

1. Örüljek neki hogy van IoC legalább, sokan ezt se mondhatják ám el
2. Ebből a szituációból is tanulok ha sikerül megoldanom a problémákat
   

Regisztrálj most és takaríts meg 3 milliárd forintot!

Azért a 3 milliárd forint megtakarítás jól hangzik, nem? Az nem hangzik jól amikor megnézed hogy a 3 milliárd forint "megtakarítással" is számolva mennyibe kerül.

Furcsa programok

Á, igen, maga az aki olyan furcsa programokat szokott írni

Egy tanárom a unit-tesztekről amiket írtam.
Bárkinek aki az ELTÉre jár: ne programozzatok le teszteket az alkalmazások fejlesztése tárgyak gyakorlatain. Úgy bekavart a tanároknál hogy az algoritmust meg se nézték, a ZH-ra meg 0-t adtak. A világháborús német hadsereg védelmi stratégiáját próbáltam bevetni miután a specifikációlengetés nem vezetett sikerre, de aztán kifogytam a türelemből. Ki tudja nekik mennyi idejük van...
N-edik alkalommal jutottam arra a következtetésre hogy az ELTÉn egyszerűen rossz irányba indítják el azokat akik ott kezdenek programozni.

A legkeményebb kihívás minden idegrendszerrel rendelkező élőlény számára: megcsinálni valamit amivel egyáltalán nem ért egyet.

Nagyon remote VM debugolása

Erről annyit, hogy olyan mint a törpök élete. Főleg ha használják és publikusn elérhető a neten.
De Rambó ezt is biztosan lenyomná.

Késztetések

Éppen PostgreSQL JDBC drivert hegesztek. Ősi project, a build úgy van megcsinálva, hogy egyetlen forrásfa, Abstract-Concrete pattern, minden az absztrakt osztályokban van implementálva. A fordításkor az ant megfigyeli hogy milyen JDBC api verzió érhető el, és annak megfeleően kizárja azokat a konkrét osztályokat a fordításból amelyek nem implementálnak minden szükséges JDBC metódust. Komoly, mi?
Csak fejleszteni nehéz vele. Az eclipse teljesen meg van tőle zavarodva, meg én is amikor azt próbálom kideríteni hogy mit miért próbál mégis lefordítani az ant. Az agyam maven-fanatikus része követeli hogy szedjem szét moduláris projectre. A comitterek meg esetleg engem szednek szét miszlikbe :)

My SOC

Persze hogy nem megyek nyaralni. Túrázni persze hogy megyek, de attól függetlenül már most készülgetek arra hogy nyáron lesz egy kis szabadidőm, és ez az egyik dolog amit szeretnék megcsinálni:
A Continuum-ba szeretnék egy kicsit erősebb integrációt építeni a maven report pluginjaival és a QALab segítségével, vagy legalábbis mintája alapján. A continuum szépen kifigyelné a test kimeneteket, eltárolná és innen lehetne a project élettartamán végig figyelni a változásukat.
Azért continuum, mert annak van elég komoly integrációja mavennel, és azért maven, mert az az egyetlen build tool, ami foglalkozik kifejezetten test futtatással és riportolással.

Semmi új, tudjátok, csak máshova tenni azt ami már létezik. Utálom a megdöbbentően új dolgokat :) Persze lesznek kihívások, nade ismeritek a törpök életével kapcsolatos népi közhelyet...

JUM log

Na, volt 3 ember akit már láttam életemben, ez pont 3-mal több a vártnál.

11 óra, végre hazaértem. Pár gyors jegyzet:

• Auth Gábor előadása tetszett a legjobban, látszik hogy tanít. Túl jó is tanárnak :). Mondjuk a ZK-t valószinűleg nem fogom használni, de a demó korrekt volt nagyon.
  
• A SAP-JCO cuccos szerintem kicsit lassú és vontatott volt. Lehet azért éreztem így mert 4-5 éve én is ilyeneket kellett hogy írjak és már akkor is elavultnak tartottam. Az SAP egy nagy állóviz.
• A saját cuccaimat kalapálhattam volna még. Valahol a közepén rájöttem hogy valószinűleg sokan még soha nem használtak maven-t, levegőbe beszélek valamiről amit nem értenek és ezért nem is érdekli őket. Az a lényeg hogy most már akkor tudom hogy hibát csinálok amikor csinálom, régen csak utánna jöttem rá :) Még egy kis gyakorlás és megy majd úgy is hogy még mielött elkövetném a hibát rájövök.
• Karenin előadőstílusa is tetszett, tipikus geek :) viszont itt még mindig azon gondolkodtam hogy a nép fogja-e azt amin tépjük magunkat. Vajon lejött-e hogy miért nem szeressük a CVS-be betolni a jar-okat? Vagy mindenki mindent vág?
• És ennél több nem is derült ki egyelőre mert Gábor előadása után el kellett rohanjak.
  

Ennyi, majd jönnek reakciók, lassan ülepszik a dolog egy kicsit, akkor majd feldogozom az inputot. Addig feldolgozok sok más sürgős inputot, például a holnapi beadandókat...

A guru egy mítosz

Ez a mém egy régi barátom agyáról ugrott át az enyémre (öreg motoros az arc, a fia kb velem egyidős), és mivel amúgy én is régen sejtettem már a dolgot, el is fogadtam. Szóval ha leszállna közénk Gosling mester és adná nekünk az észt, egy idő után mi is olyan okosak lennénk mint ő. (A desszantos-tétel alapján, lásd Analízis I.) Onnantól kezdve pedig eljön az unalom kora. Gosling mester persze biztosan elég sokáig tudna okítani, de ez a matematikai analízis számára akkor is csak véges.

Megalománisás gondolat lehet, de ha jól működik a JUM, akkor egy fenntartható fórumot kaphatunk. Még ha kicsi és viszonylag zárt is. Majd meglátjuk, akkor most indulok...

A kód bonyolultságával vívott véres harcok

A PMD egyik számomra mostanság leghasznosabb funkciója a Cyclomatic Complexity ellenőrzés. Egyébként messze a tolerancia-határ felett jelez, márminthogy a felső határ felett, így nincs olyan nagy jelentősége. Érdekes hogy csak a kis hibák kerülnek a célkeresztbe, erre valamit ki kéne találni.
Objektum orientált programozás esetén a switch és if blokkok száma viszonylag kicsi kell hogy legyen.

Műsorajánló

A hónap érdekesebb eseményei:

• JUM, jövő kedden este
  
• Newtech meetup, ezen a héten szerdán, azaz holnap. Lesz OpenID-s perzentáció is, bár előadáson kellene legyek, lehet mégis ellógok rá.
• Sun fejlesztői nap 24-én, ebből az OpenESB és az OpenSSO érdekelne, de nem tölteném ott miatta az egész napot. Főleg hogy munkanap.

A tavaszi pörgés.
Áprilisban volt összesen 1 nap amikor nem dolgoztam semmit, az a critical mass + Sárga túra napja volt, nade azzal sem pihentem ki magam :)

Funkcionális teszt nyűgök

Nekifutásból megfejeltem a Selenium korlátait:

• https support csak a 0.9.x-SNAPSHOT verzióban van, amihez viszont plugin nincs. Persze lehet űberelni egy kis hackeléssel, kockáztatva hogy beleölök X időt és mégsem fog működni a régi plugin az új szerverrel
  
• A flash elemek által generált eventeket a selenium-ide nem veszi észre, ha sok ilyen van, akkor nem lehet produktiívan használni azt sem, ott tartunk ahol a http-unittal.
  

Nézzük a pozitív oldalát: van hová fejlődni. Megérne még talán egy próbát JMeterrel a proxy-s dologgal megpróbálni, de az load testre van kihegyezve, nem funkcionálisra.

Tranzakciómentes övezet

But eBay's example suggests that living without transactions is far less impossible than many people think.

Van élet tranzakciók nélkül is, mint ahogy Martin Fowler is írta az e-bay-ről, de nagyon nem könnyű. Szóval ha valaki mégis meggondolná hogy neki ilyen nem kell a rendszerébe: de, kell.

Memetika II

Múlt héten halaszthatatlanul fontos adóügyben betértem egy ex-munkaadómhoz, ahol azóta új tanulságos képeket tettek ki, az egyiken ez a felirat áll (elnézést ha nem pontosan idézem)

Az hogy szükség van rád, még nem azt jelenti hogy fontos vagy.

Szeretem amikor valami ilyen zabolátlanul őszinte. Ez a mém ugrott át a képről az agyamba, az agyamból a blogomba, onnan a ti agyaitokba, hogy hozzáadódjon a többi mém tömegéhez és ezzel módosítsa a képet a világról amiben élünk. Volt még pár kép, hasonlóan mellőzve minden hízelgést a munkavállalók felé, ez ragadott meg leginkáb.

Szakmai etika II

Idézet a HUP-ról, mert nagyon fején találta a szöget a marketing-szöveggel kapcsolatban valaki.

Amikor egy gyártó azt mondja, hogy a terméke 99.99999...%-os rendelkezésre állást biztosít, azt nem lehet ellenőrizni. Szvsz nemcsak a közönséges vásárló nem tudja ellenőrizni, hanem a gyártó sem.

Van egy ilyen törvényi szabályozás a pénzügyi világban, itthon is, hogy senki nem állíthatja azt hogy a hozam garantált, és mint kiderült az érintett cégek csalók voltak. A hozam soha nem garantált.

A rendelkezésre állás sem garantált. Például kedvenc egykori szerver hosting szolgáltatóm egy alkalommal elvesztette a befizetési bizonylatot és lehúzta a hálózatról a szervert. Ennél csak az volt durvább, hogy miután telefonon sürgettem őket hogy dugják szépen vissza, csak azután voltak hajlandóak visszadugni, hogy bement az irodába náluk a számlázási osztályra valaki és előkereste a papírt. Elmondom mennyi idő volt mindez: 1 hét.
Kérlek titeket, azonnal vegyetek valamit a Ultraweb kft-től, a verseny-alapú gazdaság törvényeinek cáfolataként :)

Acegi OpenID support

Az Acegi security OpenID támogatást kapott. Király, ezzel se nekem kell foglalkozni :) Várom az OpenID technológia robbanásszerű elterjedését a java webalkalmazásokban.

A Cluster legenda

Egyszer azt olvastam valahol, hogy a szerverek áramfogyasztása teszi ki a teljes világ áramfogyasztásának 1 százalékát. Persze nem biztos hogy igaz, de ha mégis...

Itt van a melóm, persze top tartalomszolgáltató, és biztos nem vinné el egy asztaligép az alkalmazást az összes felhasználójával, de mégis inkáb az amerikai autóipar tervezési mintái érződnek az egész céges világ clusterein. Amikor a hummer a keskeny európai erdei ösvényeken. Túlméretezett, kihasználatlan, kihasználhatatlan.

Szerintem

Szerintem szóljon bele még valaki, hogy még jobb döntés szülessen.

Optimista vagyok mint állat.

Unit tesztek idővonatkozásai

Mind a TestNG mind a Junit 4.x támogatja a teszt futásra tett timeout-ot, ami hasznosnak látszik amikor kritikus kérdés a művelet idő igénye. Az idő-igény az valahonnan a számítás-igényből származik, és innen kezdve az ember már sejti hogy egy művelet futási idejét nem lehet csak úgy megsejteni, mert java esetében nagyban függ a virtuális gép paraméterezésén is, a processzorról és a többiről nem is beszélve.
Emellett interface-re írt tesztek esetén nagyon kevés értelme látszik a timeout-nak, hiszen az interface nem tartalmaz elvárást az implementáció futási idejére. Arra a futás időre amiről az derült ki az elöbb hogy csak homályos arányszámokban sejtjük.

Következtetés: a timeout inkáb arra jó hogy lockolás és egyéb problémák miatt ne ragadjon be a teszt a CI szerverbe, hanem inkáb hasaljon el, ehhez viszont bőven nagy időkorlátot kell megadni, amit a leggagyibb implementáció se tud alulmúlni. Performance tesztre nem igazán oké.

Mekkora havaj amikor vannak junit tesztek, most már nem fogom engedni hogy bármi bajuk essen :)

Continuum 1.1 preview

Alpha release elött áll a continuum 1.1, aki türelmetlen, vagy akinek nagyon fáj a foga az eddig nem támogatott perverz SCM implementációkra (mint én) annak rendelkezésére állnak nightly release-k, egész stabilak.
Az újdonságok közül:

1. Project csoportok.
2. Notifier-ek projecte csoportokra és projectekre is.
   
3. Finomabb role kezelés, már lehet project csoportonként kiosztani különböző szerepeket (admin, fejlesztő, felhasználó)
4. Végre működik azzal a bizonyos PiciPuha verziókövetővel, ami annyi fejfájásom és minden fejlesztési processz probléma kimeríthetetlen forrása :)
   
5. Emberbarátibb schedule szerkesztő felület
6. A logót már a company POM-mal lehet beállítani, ez spec nem mindig jön jól, de talán sikerül rácsábitani a népeket a company POM-ok megírására
7. Mint már írtam régebben, a maven 2 projecteknél ha van SNAPSHOT dependency, akkor akkor is buildel ha nincs változás a forráskódban, helyes :)

Szóval ajánlom mindenkinek a figyelmébe, mert ez már egy egész jó dolognak igérkezik, a maven 2 integráció terén mindig is verhetetlen volt.

A war overlay és a jetty plugin nehézségei

Egyes esetekben (pl OpenLaszlo alapú hegesztések) kénytelen az ember egy másik project war filejába belegyömöszölni a saját cuccát. Erre a maven tök jó megoldást kínál, egyszerűen csak adjuk meg dependency-ként a külső war file-t és a scope legyen runtime, a típus pedig persze war. Ekkor a war plugin tudja majd a dolgát és jól összemergeli a kettőt, persze itt még van mit paraméterezni. Ezt hívják war overlay-nek.
A gegasz már ott elkezdődik amikor a mindenki kedvence 'mvn jetty6:run' parancsot kiadjuk, mert a jetty6 plugin figyelmen kívül hagyja ezt a dependency-t, futtathatunk viszont egy 'mvn jetty6:run-exploded' parancsot, ez összeállít egy war-t a war pluginnel, kicsomagolja és végül elindítja rajta a jetty-t. A dolog két fájó pontja:

1. Nagyon lassan indul el, főleg ha a war file mérete nagy
2. Nem updateli a tartalmat

Erre az elegáns megoldás az lenne, ha a jetty6 plugin tartalmazna egy background thread-et, ami szinkronban tartja a jetty kicsomagolt war fáját a forráskóddal. Ezt viszont egy bash parancsból is egyszerű megoldani. Ilyesmi:

while true; do cp -ru src/main/webapp/* target/${artifactId}; cp -ru target/classes target/${artifactId}/WEB-INF/classes; sleep 1; done

Kicsit sem elegáns, legkevésbé sem portolható (de hát a vindózerek élete amúgy se játék és mese), de a túlélésre elég. A második bajt workaroundolja, az elsőt meg túléljük mert innentől már csak egyszer kell elstartolni.
Ki lehetne pofozni ezt a jetty plugint, például még mindig 6.0-beta17 verzióval megy a legfirssebb kiadás, pedig a fejleszés lassan már 6.2-nél tart. Miért hagyhatják ilyen elhanyagolatan a webfejlesztéshez leghasznosabb plugint?

Szakmai etika

Ma ez a szó ragadt meg a napi pörgés közben, ezt orvosoktól halljuk leginkább, én most elösször hallottam IT iparággal kapcsolatban, és arra gondoltam hogy ez a kifejezés egy pozitív mém, amivel minden erretévedő agyat meg kellene fertőzni.
Egy fáradt percemben tett kijelentésemmel ellentétben még csak 7 éve dolgozom hegesztőmunkásként, ami lényegesen kevesebb mint pármilliárd, de azért elég sok :)

Ennyi.

1,795.00 USD

=

331,830.08 HUF

Ha bárkit érdekelne mi ez, nos ez a JavaOne 2007 early-bird regisztrációs dijja forintba átszámolva.
Tacit knowledge (bocsi, denem tudom hogy mondják magyarul): Az a tudás, amit nem lehet elmondani, leírni, például az úszás, palacsintasütés, kernel hackelés. Attól hogy elolvastad a manuált, még nem tudod megcsinálni, viszont ha keményen próbálod persze rájössz magadtól. Tacit knowledge nem terjed a mainstream médián keresztül, könyvek, oktatófilmek, ilyesmi teljesen alkalmatlan rá. Forum, irc, talán inkább, személyes beszélgetés közben viszont ragadós.
Szóval ennyi az ára.

Többek ezért sajnálom én hogy például a magyar openlaszlo közösség ennyire csipkerozi.
Lehet elmegyek mégis a newtech meetup-ra, tudom hogy nem szivesen lát ott pár ember, de hát ha ennyit megtakarítok a tacit knowledge-re szánt költségekből :)

Maven fan klub hirek

Kicsit gyorsult a release-tempó a maven csapat háza táján. Remélem nem csak áprilisi tréfa hogy hat héten belül látunk egy alfát a maven 2.1-ből. Én már nagyon várom, bár az említett függőségi gubancot már kigubancoltam.

A héten nem tanítják a jó programozó elengedhetetlenül szükséges tulajdonságait az egyetemen, remélem lesz időm valami frankót hegeszteni.

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.
  

Igazán bosszantó dolgok

Az utóbbi fél évben elég sok munkaórám ment el tapestry 3-ról 4-re portolással (ami egyébként PITA volt, de igazán), na és erre most kijön a tapestry 5.
A technológiai lemaradás motivációit valahol itt kell keresni ha majd keressük. Szerintem.
Nekem mondjuk mindegy lenne, ha kifizetik. Nos, eddig még nem fizették ki, pedig ingyen azért nem csináltam volna. Dolgozzatok ti is sokat magyar kiscégeknek!

Update: A pénz néha mégiscsak boldogít, végül az X kiscég kifizetett. És boldogan éltek amíg...

Hová mész te java...

Ahogy olvasgatom a thread-eket, egyre inkáb tartok attól hogy a java nyelv megpróbál minden lehetséges nyelvi feature-t implementálni amit eddig a világon kitaláltak, aminek az eredményeként olvashatatlanná válik.

• closures, mert groovy meg rails jajjdejó
  
• a horrorisztikus nativ XML támogatás, mert a dotnet állítólag...
  
• super-package, ezt nem tudom honnan vették
  
• tömb-szerű syntax sugar a Map-ekhez, mert PHP-ben milyen jó
• új property syntax, Delphi-ből
  
• satöbbi
  

Egzaktabban ez valahogy úgy hangzik hogy a learning curve megnő. Közben az egész mögött a motivációt nem értem, így is lehet saját nyelvet implementálni JRE-re, most meg már forkolni is lehet a javac-t, eclipse plugint tessék írni hozzá és mehet a műsor.

A java 1.5, ami eddig talán a legnagyobb nyelvi feature újdonságokat hozta, ehhez a sokmindenhez képest szinte semmi. Nem tudom mi sül ki ebből a végén de a jó öreg diktatúra kényelmesen biztonságosnak tünt, bár mondjuk a napocskás arcok is kevertek időnként szépeket.