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.