.* meaning detection

Egyszer megkaptam egy cobol program forráskódját (első és utolsó eset azóta). Alighanem egy mérges vegyész írta, ugyanis a változónevek ilyenek voltak mint shit, fuck és így tovább... Egy ideig gondolkodhattam rajta hogy mi célt szolgálhatnak a változók mire sikerült működésre bírnom a cuccot. Ilyesmivel gondolom mindenki találkozott már. Körülbelül minden környezetben, programozási nyelvben, satöbbin létezik valamilyen konvenció, ami alapján létjogosultságot kap egy osztály, abban egy metódus, a metódusban paraméterek, változók, és a nevét is többé kevésbé meghatározza. Szerencsére ezzel mi nagyjából rendben is vagyunk.
Viszont arra gondoltam, hogy a legalább ennyire fontos lenne a magasabb szerveződési szintekre is érvényesíteni valami konvenciót és a csapatokat, projecteket, szoftvereket satöbbit kicsit kevésbé nagyzó, de sokkal inkább sokatmondó nevekkel kellene ellátni, hogy az embernek a csapat/project nevéből felderengjen hogy körül belül mi is az egész célja. Ezzel a dologgal elég csúnyán állunk :-(

SWT

Éppen mostanában átfutok egy SWT könyvet, hogy kicsit rendbetegyem a fejemben ami eddig az SWT-vel kapcsolatban bele került innen-onnan. Pár dolog, ami első nekifutásra nem tetszik...

• Az SWT konstans interface. Kusza mindenfélék halmaza. Widgetek attribútumai, eventek nevei, minden. Tudom, hogy a java 1.5 elött nincs enum, de akkor is szét lehetett volna robbantani pár kissebb osztályra. Használhatóbb lenne.
  
• A checkSubclass() metódus mindenképpen érdekes módja az örökldésen való akadékoskodásnak.
  

Kiváncsi vagyok mikor dobják el az 1.4-es java stílust és építenek kicsit más felületet.

A közösséggé vállás rögös útjai

A korábbi postban a sonarral kapcsolatban írtam, hogy esetleg egy vitafórumban a fejlesztőcsapat megtárgyalhatja, hogy milyen ellenőrzéseket tart fontosnak. Nos, konkrétan ezt ki is próbáltam, és várnom kellett egy alkalomra, mert elég sok munkánk volt. Mire demohoz értünk, volt már bőven statissztika a sonar adatbázisában a szűkebb csapatom projecteiből. Pár tapasztalat némi emésztés után:

• Az érdeklődés mértéke résztvevőnként elég változatos volt, de jóval 50 százalék alatt, ha lehet így pontozni. Azt hiszem jórészt nem rettenetesen elvetemült java kóderekkel dolgozok együtt mostanában.
• Tök jó lenne egy pozitív és egy negatív példa minden ellenőrzési pontra, csak hogy gyorsabban és kevesebb agymunkával lehessen választani.
• Igazából jó koncepciónak tartom hogy a szabály lehet kötelező, opcionális, vagy figyelmen kívül hagyott, de lehet hogy ez is sokat bonyolít a döntésen.
  
• 300 ellenőrzés nyilvánvalóan túl sok ahhoz, hogy egyszerre végignézzük és mindre szavazzunk, úgyhogy kb 20 %-nál félbehagytuk (tartok tőle elég sok időre, legalábbis érdemes átgondolni hogy ezt így érdemes-e erőltetnem)

Ha hazaérek és még lesznek működő agysejteim, ide fogom vágni Vonnegut ide vonatkozó bejegyzéseit, mert attól műveltnek látszom majd. Tessék:

[...] Félrevezeti az embereket, ha folyton-folyvást óriási sikerekről olvasnak, mivel tapasztalataim szerint még a középosztálybeli és felsőközéposztálybeli fehérek esetében is a kudarc az általános. [...]

Napfogyatkozás

Azt hiszem az ganymede usage data feltöltésre reflexből a legtöbb ember nemet kattint, viszont azok akik bekapcsolják, azok hasznos statisztikai infókkal látják el az eclipse alapítványt. Mellesleg ez publikus is, így megtudhatjuk mit használunk a legtöbbet az Eclipse-ből. Érdekes átnézni, nem meglepő módon a debug parancsok és nézetek igen előkelő helyezést értek el, viszont eléggé ott van a JEE perspektíva is.