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...