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