JSP

Beszéltem az üzemeltetők főnökével, aki eléggé keresztben van azzal az alkalmazással amit fejlesztek. A probléma okát abban azonosítottuk, hogy túl sokat kell foglalkozniuk a rendszerünkkel, ami a boldogtalanság közismert és általános forrása.
Azért kell a mi rendszerünkkel kiemelten foglalkozniuk, mert mi nem JSP fileokban dobáljuk fel a progit, hanem egy darab war file-ként és akkor azt nyilván adott helyre be kell pakolni, újrastartolni a szervert, néha még a konfigurációt is módisítani. A JSP fileok behegesztésére van egy speciális rendszer, ami egy FTP helyről dobálja át a cuccokat, ebben az esetben egyszerően nem kell foglalkozniuk a dologgal, még csak újra se kell indítani a szervert, a JSP a legközelebbi request-nél újrafordul. Sajnos olyat nem tud ez a rendszer, hogy egy war file-t ugyanígy kidobjon. Azt, hogy a webalkalmazásba bármilyen program bármit is beledobjon, azt már régen kikapcsoltattam. A dinamikus tartalmat jobban szeretem dinamikus tartalomként kezelni.

Mindenesetre szerintem ez egy érdekes példa arról, hogy hogyan kezd egy cég fejlesztési metódikája és technológiái igazán elfajulni.

final paranoia

Az utóbbi években összeszedtem néhány furcsa programozási szokást, ezek közül az egyik a final kulcsszó agyonhasználata. Nem meggyőzni akarlak, de leírnám hogy mi vezetett ide, illetve miért maradt így a dolog.

A final kulcsszót általában illik mindig odaírni minden static mező (aka osztályváltozó, de hívjuk inkább konstansnak mert jobb ha nem változik :) ) mellé. Ezen elég rendesen túlléptem...

• final-ként kezdtem el deklarálni minden paramétert, mert olvashatatlannak tartom, amikor egy metódusban új értéket kap egy paraméter -és a környezetem bővelkedik ilyenekben. Persze aki belenyúl a metódusba, az a final-t is letörölheti, de az már plusz munka, lehet könnyebben talál rá más megoldást.
  Az eclipse clean-up parancsa gyönyörűszépen támogatja a paraméterek final-lé alakítását és utánna nagyon szépen látszik hogy ami nem lett final, az valahol értéket kap...
  
• Innen már csak kevés kellett ahhoz, hogy azokat a lokális változókat is final-nak deklaráljam, amik egyszer kapnak értéket és aztán csak olvasni kell őket. Úgy tűnik könnyebben olvasom a kódot ha nem kell azzal foglalkozzak, hogy egy változó tartalma hogyan változik pár kilóméterrel lejjebb.
  Az eclipse clean-up persze ezt is támogatja. Persze defaultból ki van kapcsolva, be szoktam kapcsolni.
  
• Még egy lépéssel később pedig egyes service beanekben final-nak kezdtem deklarálni egyes mezőket, pl egy DAO esetében egy DataSource vagy ilyesmi, ami nélkül teljesen semmi értelme nincs az életének és kár is lenne nélküle megszületnie. Na ezzel már nagyon csinján kell bánni, mert pl a spring a konstruktor argumentumok módosítását nem támogatja a talán leginkább elterjedt PropertyOverrideConfigurer-rel. Szóval csak olyan lehet, amit biztosan nem kell egy konfig file-ból módosítani.

Na, most jobb...

Közben 2 éves lett ez a blog, ez pedig pont a 200. bejegyzés. Köszi a 4.5-ös átlagot! Rosszabbra számítottam az XML-es posztjaim után. Ez után a post után lehet kiérdemeltem volna pár hármast is.