2009. december 30., szerda

Évvégi offtopic

Sziasztok!

Hát ha valami rendkívüli közbe nem jön, akkor ennek az évnek is vége lesz határidőre és gondoltam pár rendezetlen gondolatot kidumpolok ide arról, hogy mi volt idén és mi lesz jövőre.

Jövőre 3 éves lesz ez a blog. Az utóbbi 1 évben rettenetesen megritkultak a postok. Mondjuk nem csak itt, hanem nekem az az érzésem hogy a többi magyar java blogban is sajnos. Bele fogok húzni! Sőt már el is kezdtem, csak amivel fogalkozok mostanában, az szoftverfejlesztés szempontjából nem valami izgalmas.

Szerintem kapcsolódó probléma (illetve jelenség, amennyiben nem probléma), hogy a JUM-okon nem sikerült meghonosítani a quickie-ket. Teljesen ki is haltak és a hagyományos előadások vették át a helyét. Hát erre van igény, akkor ez van. A melóhelyem hasonló funkciójú "kb havi rendszerességű" összejövetelén próbálom most, szerintem kicsit több sikerrel. Az interaktívabb, mondjuk talán azért mert eleve lazább hangulatú az egész. Péntek délután, tea, süti, üdítő, kivetítő...


Szabadidőmben (ezt az előző postból biztosan kihámoztátok) a todomap projecttel foglalkozom. Ez érdemelne egy kis magyarázatot a jelenlegi állapotában, de mondjuk szóljon inkáb majd erről az új év első postja. Addig "What you see is WTF" :-). Itthon megtartottam pár kisérleti állapotából screenshot-ot amit mostanában nézegettem és úgy tűnik, az ötlet is, az implementáció is fejlődgetett elég sokat, közben kicsit képbe kerültem néhány technológiával. Az új évben ezt a projectet szeretném elvinni addig ameddig tudom.

Egyébként ezen kívül az történik, hogy egy nagyon fertőző gondolat-vírus született az agytekervényeimen, ami szerint a 30. születésnapra frankó befejezni az Országos Kéktúrát. Jópár barátomra átterjedt ez a vírus, így mostanában ennek engedemleskedve tapossuk a kilómétereket. Aki esetleg túl van a 30-on az használja nyugodtana gondolat-vírus 40. születésnapra vonatkozó mutációját :-)

2009. november 20., péntek

JUM 12

Tvik már beszámolt, de én is beszámolnék, csak hogy szinesítsem a képet és a visszajelzések számát.

Viczián István: JAX-WS

A végén rá is kérdeztem, bár kicsit hülyén, szóval az előadás a JAX-WS és a reference implementációjának problémáit ölelte fel. Azaz nem feltétlenül szívja meg az ember pont így. Igen, elég ijesztő volt. Contract first WS. Nem tudom, én ezekkel nem szivatom magam, felannotálom a web service interfaceket alaposan :-D és ha az interface marad ugyanaz, akkor a kigenerált WSDL is, sőt a SOAP üzenetek tartalma is. Szóval innentől én kevés motivációt érzek a dologra, persze ha bankot vagy atomreaktort kellene ezzel hajtani, akkor biztosan óvatosabb lennék. Még egy saját horror-élményt hozzáfűznék: CXF és jettison, ha ugyanaz a neve egy property-nek és a property property-jének, hát akkor a jettison ott elcsűri a json objektumot. A tréfa az, hogy a többi részét is kiteszi, csak elötte lezárja a tömböt. Atomreaktort már csak az ilyenekért sem hajtanék vele, ez a bug akármilyen egyszerűnek is hangzik, elég rég óta vár javításra.

Csutorás Zoltán: Agile, SCRUM, Lean

Igen, volt szó a SCRUM-ról is, de a végén az a modell, aminél a gyártósor leállások voltak és mindenki le volt rajta döbbenve, na az nem a SCRUM volt már, hanem valami más aminek a nevére nem emlékszem. Update: KANBAN. Az előadó stílusából azt a következtetést vontam le hogy neki alighanem vannak hozzá acéldrótokkal erősített idegei, hogy a felvázolt módszertant keresztülvigye. És akkor gondolom működik is. Annyi biztos, hogy én ehhez gyáva vagyok.

Kis Gergely: Andriod és Hundriod

Az elején kicsit gyanakvóan figyeltem, hogy miért indítja furcsa paraméterekkel parancssorból az openoffice-t, mi az a pythonos trükk, amit még elstartol hozzá... Viszont hamar kiderült, hogy innetől az androidos telefonnal irányíta a prezentációt. Onnantól kezdve nagyon tetszett, bár nem egy felhasználóbarát megoldás per pillanat, de nagyon látványos demó volt. Én továbbra is beérem az kötelező mutatvánnyal amúgy, én a telefonomat tényleg csak telefonként (és fényképezőként és pendrive-ként és walkman-ként) használom.

2009. november 7., szombat

Mosatanában elkövetett mini-projecteim

Kicsit elhanyagoltam mostanában ezt a blogot és inkább otthon hegesztgetek. Pár némileg újrafelhasználható dolgot is összekopácsoltam az utóbbi pár hétben.

MiniGeoIP

Szóval próbálkoztam azzal, hogyan tudom bemérni a kliens földrajzi helyét. Nem holmi öncélú marketingdolog miatt, hanem egyszerűen hogy az alkalmazás számára releváns infóval tudjon indítani. Egyébként a IP-blokkolás szerintem rasszizmus. Próbálkoztam a Google JSAPI-jával, a tapasztalatok viszont azt mutatták, hogy a Google vagy megmondja hogy hol vagy, vagy nem... Ami azért bár nagyon baráti, de mégsem 100%-os telitalálat. Söt, sajnos úgy tűnt az ismerőseim többségének IP címére nem mond semmit. Keresgetni kezdtem szerver oldalra beágyazható IP feloldást de nem sok használható dolgot találtam, úgyhogy a felgyűlt ihletből gyorsan összedobtam egyet. Ez az implementáció egy 100.000 soros adatbázist épít fel magának. Az még a memóriában is elférne talán, viszont én JPA-n keresztül keresem. Sajnos kényelmes voltam és spring JpaDaoSupport-ra építettem, szóval most totál spring-függő, de ez most még nem fáj nekem. Cucc. Ja és itt ki is lehet próbálni, hogy jó országba tesz-e.

GeoCoder

Hasonlóan föcis téma, egy adott koordinátából szeretnénk megkapni a postai címet amennyire lehet. Unalmas. Google reverse geocoder. Köszi gúgli. Cucc.

Jetty-gzip-plugin

Ez szerintem vicces téma, a jetty default servlete tud olyat (és alapból be is van kapcsolva), hogy ha egy statikus file mellett ott van a .gz tömörített változata, ÉS a kliens nem IE :-D, akkor a tömörített változatot küldi el, ezzel megtakarítva sávszélességet és egy kis időt is. Pl a javascript library-k egészen hatalmasra nőttek. Ez a kis maven plugin egyszerűen packageléskor létrehozza a .gz fileokat. Akár kézzel is megcsinálhatná az ember, ha nem felejtené el mindig. Nekem kicsit több mint 100Kb-t takarít meg egy oldalmegjelenéskor, ennyiért úgy gondoltam, hogy már megéri. Cucc...

Google Translate Java kliens

Hát ez annyit tud, hogy megmondja, milyen nyelven van a szöveg. Teljesen minimalista, de ennyivel beérem. Ismét köszi gúgli. Kicsit már zavar hogy mennyi mindent ráépítek google szolgáltatásokra. Cucc...

Ennyi, köszi ha eddig eljutottál, akkor most megint pár hét lapátolás...

2009. október 26., hétfő

Az ajax file upload és a gonosz flash

Próbálgattam AJAX-os file upload cuccokat JQuery-hez és elsőre majdnem bedőltem az uploadify-nak. Egy kis időt eltöltöttem azzal, hogy a file feltöltés miért nem látja a szerver oldali session-t, teljesen azt hittem egy ideig, hogy a szerver oldalon szúrtam el valamit. Pedig nem: az uploadify flash-t használ feltöltéshez és a flash figyelmen kívül hagyja a cookie-kat. Ezt már hallottam mástól is, csak nem jutott át az ingerküszöbön.

Gyorsan át is gyergeltem erre a másik ajax upload cuccra, ez teljesen jól működik idáig, nincs benne flash, bár a skineléssel akadt problémám de az valószinűleg inkáb abból származik, hogy CSS-ből még mindig kettes alát érdemelnék.

2009. szeptember 8., kedd

@Autowired és társai

Mostanában gyakran beleakadok a spring framework @Autowired annotációjába, amit kifejezetten private mezőkre húztak rá, amin nincs setter sem. Pl...

@Autowired
private Datasource datasource;

Az a kifogásom ellene, hogy:
  • besettelni sem lehet neki valami mást
  • springen kívül nem lehet inicializálni
  • elég sok időbe tellik kibogarászni hogy vajon mi lesz ide besettelve
Nem olyan, mint a JdbcTemplate, amit szerintem simán más framework-re is bele lehet tuszkolni, és ráadásul nagyon hasznos. Sikerült portolhatatlanná tenni a kódot, pedig a spring úgy indult annak idején, hogy non-intrusive IoC framework. Másrészt ez olyan, mintha service lookup-ot használnánk, annyi előnnyel, hogy a boilerplate kódot átvette a spring. Viszont akkor már ilyet is csinálhatnánk:

@JndiLookup("jdbc/MyDS")
private Datasource datasource;

A megoldás: TestNG

N alkalommal futottam neki a TestNG használatának eddig, mindig nagyon boldog voltam magával a TestNG-vel, de az IDE integrációjával soha nem tudtam kibékülni és végül inkáb maradtam junit-nál. Az 'új' projectem pár artifact-jába viszont valamiért belecsomagolták a junit egy matuzsálemi verzióját, ami teszt alatt ütközésbe kerül az új verzióval, így nem maradt más választásom, mint testng-t használni.

2009. augusztus 24., hétfő

RIA kalandok

Hát igen, jó hosszú történet, ugyanis a kliens oldaltól mindig próbáltam magam távol tartani. Nyilván a CV-ben sem áll jól, ha valaki nem pöpec a teljes alkalmazás stack minden apró elemében, meg elkezdett érdekelni is a téma.

Szóval a hosszú történet...

OpenLackó

Úgy kezdődött, hogy OpenLackó. Az OpenLaszlo volt nálam az első és eleinte marhára bejött, hogy én is tudok olyanokat csinálni benne, mint a UI guruk.
Előnyök:
  1. Tényleg marha gyorsan össze lehet dobni a felületet.
  2. Alapértelmezésben is szép.
Hátrányok:
  1. Szőrös RPC megoldások. Például minden hívást a laszlo szerveren keresztül akar végrehajtani. Minek? "Java RPC" - public static metódusokat lehet vele hívni. Csúnya dolgokat kényszerített ki a szerver oldalon.
  2. Horrorisztikus fejlesztési menet. Dobáljuk be a lzx fileokat a laszlo szerverbe? Miért nem lehet inkáb beágyazni az egészet?
  3. Nem igazán indult be a komponens-piac, talán éppen a fentiek miatt.
Flex + BlazeDS vagy amit akarsz

A flex-ben amit elsőre megszerettem, az az hogy végre normálisan néz ki a RPC. Hívhatunk teljesen szabványos SOAP hívásokat, vagy kicsit cifrább mulatságba is belemehetünk BlazeDS-sel. Extra a lackóhoz képest az is, hogy nem kell a runtime környezetbe beletolnunk semmi flex specifikus dolgot. Egyből 40 megával kissebb a war file, hoppá.
Előnyök:
  1. Sokféle és használható RPC. Akár szerver data push is.
  2. A data binding szerintem király.
  3. Nem feltétlenül akar valami spécit a szerver oldalra.
  4. Kiválló maven plugin :)
  5. Sokféle free UI komponens és library a neten.
Hátrányok:
  1. Pokolian lassú fordító.
  2. Hát van a flexbuilder, ami pénzes windowsos, akkor már egy új gépet is kellene vennem... Valamint összedobtam egy gyors plugint régebben, ami semmi mást nem csinál, csak lefordítja minden módosításra a flex kódot. Ezek nélkül azért meg lehet lenni.
ZK

Erre egy volt munkatárs hívta fel a figyelmemet és nagyon örültem is neki. A zk király... bizonyos dolgokra.
Előnyök:
  1. Nem kell IDE :) Simán eclipse-ből editálva a zul fileokat háttérbe futó jetty-vel ment minden mint karikacsapás. Nagyon gyorsan lehet vele haladni. Módosítás esetén is villám gyorsan újrafordít.
  2. Tiszta html.
  3. Nagyon egyszerű és működő spring integráció.
  4. Akadnak hozzá hasznos kis extra komponensek, egész könnyűnek tűnik sajátot írni. Az alap csomag is rengeteget tartalmaz.
Hátrányok:
  1. Nekem úgy tűnik, borzasztó sokat nyúl a szerverhez. Nem tudom róla leszoktatni. Mindenért a szerverhez szalad.
  2. Szerver oldali session-t nyit, egész nagyot. Skálázhatósággal nem tudom hogy állhat.
Szóval bekategorizáltam, hogyha egyszer valami csili-vili intranetes dolgot kell majd csinálni, akkor új lehetőségeket kap.

Google Web Toolkit

Hát ezzel odáig jutottam, hogy végigcsináltam egy tutoriált, és amikor oda jutottam hogy lefordít, akkor olyan botrányosan lassú volt, hogy fejvesztett menekülésbe kezdtem és azóta nem merészkedtem vissza. További információk így nem derültek ki.

HTML + JS + jQuery

Végülis feladtam és elfogadtam, hogy meg kell tanulnom javascriptet használni. Kicsit új eszközöket kellett keresgetnem ehhez, tényleg olyan érzés volt, mint gimi után C-ben kalapálni. A jQuery-t egy munkatársamtól lestem el, ő egekig magasztalta.
Előnyök:
  1. Még csak nem is jsp. Statikus html. Akármilyen IDE elegendő támogatást ad hozzá. Jó, mondjuk az eclipse javascript képességei tényleg nem tűnik valami nagy pukknak
  2. A SOAP-ot nem próbáltam, de a REST hívások simán mennek. Csak az megy át a dróton, amit az ember programoz. Alacsony szintű ajax megszelídítve.
Hátrányok:
  1. Még felfedezés alatt áll, de a UI library nem olyan nagyon frankó még.
  2. Alacsony szintű összeakadások. Például beleraktam egy google map-et egy dialog-ba, és hát voltak vele bajok, kicsit elcsúszott a google map. Nem tudom miért, kicsit erősítenem kell még javascrptből.
  3. Szerintem az olvashatósággal vannak problémák, de lehet hogy csak nekem kell még megtanulnom olvasni.
Ez a helyzet idáig. A véleményeteket és útmutatásaitokat természetesen örömmel látom.

2009. július 8., szerda

JAX-RS és JAX-WS

Köszi a hozzászólásaitokat az előző postra, egész sok inspirációt kaptunk ahhoz hogy hogy írjuk át a teszteket!

Igazából most is a véleményetekre lennék kiváncsi.

Szintén munkahelyi projectben azon mesterkedtem, hogy SOAP-os REST-es web service-t is meghagyom egészen addig, amíg teljesen világossá nem válik hogy az adott környezetben melyik a nyerő megoldás. Természetesen spring-gel inicializálom a service bean-eket, CXF-fel exportálom ki, JSR 181 web services és JSR 311 rest annotációkkal látom el a service metódusokat és a beaneket még JAXB annotációval is helyenként. Sikerült is, bár szerintem kicsit szőrös a dolog.
  1. Elösször is a JAX-RS a beanjeid Collection (list, map) mezőire megköveteli, hogy legyen mindnek alapértéke és csak gettere. Azaz ne lehessen null soha, legfejebb üres. Viszont a JAX-WS elvárja hogy mindenkinek legyen szép gettere és settere, különben nem számít proprtynek. Ez a kettő nem feltétlenül zárja ki egymást, csak kicsit megcsúfítja a bean-eket.

    Például így fog kinézni egy bean:



    /**
    * Szerintem gáz, amikor magyar neve van egy osztálynak :)
    * Majdnem mint amikor a javadoc is magyar.
    */
    @XmlRootElement(name="csirke")
    public class Csirke {
    boolean isKopaszNyaku;
    boolean isKendermagos;
    List<Tojas> tojasok = new ArrayList<Tojas>();
    @XmlTransient // Nem ezt a property-t hasznaljuk a rest apival
    public List<Tojas> getTojasok() {return tojasok;}
    public void setTojasok(List<Tojas> tojasok) {this.tojasok = tojasok;}
    @XmlElement(name="tojas")
    @XmlElementWrapper(name="tojasok")
    public List<Tojas> getTojasLista(){ return getTojasok();}
    }


    Szóval szerintem kicsit összetúrkáltuk az alkalmazás legérzékenyebb részét: az adatmodellt. Ha az adatmodell csúnya, az mindennek rossz alaphangulatot ad.
  2. A CXF-nek kicsit nehéz volt megmagyarázni, hogy ha pl a /services/ alá mappeltem a CXFServlet-et, akkor mit kell csinálnia akkor, amikor kap a /services/-re egy kérést. Azt hiszem az lehetett a baj, hogy nem állítottam be at address-t.



    <jaxrs:server name="jaxrs-server" bus="rest" address="/rest">
    <jaxrs:servicebeans>
    <ref bean="csirkefarm">
    </jaxrs:serviceBeans>
    </jaxrs:server>



  3. A service interfacekre raktam az annotációkat, hogy ha lecserélem az implementációt, akkor az új service-re már ne kelljen másolgatnom. Hát elég cifrán meg lett annotálva egy-egy ilyen metódus.



    @WebService(name = "csirekFarm")
    @Path("/csirkeFarm/")
    public interface CsirkeDAO {
    @WebMethod(operationName = "getCsirke")
    @WebResult(name = "getCsirkeResult")
    @GET
    @Path("/csirke/{csirkeId}")
    public void Csirke getCsirkeById(@Webparam(name="csirkeId") Long id);



Most, hogy az annotációk legyőzték az XML konfigurációkat, a kódunk tele van konfigurációval :-) A hétvégén összedobok hozzá egy archetype-ot, ha elég időm marad rá.

2009. június 25., csütörtök

Logging

Belekeveredtem egy problémába a OpenJPA unenhanced osztályaival és úgy döntöttem hogy inkább visszatérek kicsit Hibernate-re. Nos magában a visszatérés nem lett volna nagy ügy: kiszedni az OpenJPA-t a pom.xml-ből, betenni a hibernate-entitymanagert, kicsit módosítani a jpa konfiguráción és kész is lenne...
Viszont a hibernate időközben nagyon szépen áttért a log4j logolásról a slf4j logolásra. Őszintén szólva teljesen lusta voltam egész idáig akár belenézni is, hogy mit kínál az új logging api. Nos a Simple Logging Facade 4 Java azt találta ki, hogy az régi logging apik helyére tesz egyetlen loging rendszert. Azaz kidobtak egy halom jar file-t, amiben például benne lehet a jó öreg org.apache.log4j.Logger, és emiatt nem tűri meg maga mellett az eredeti log4j-t. Dependency hell. Akármelyik csomagom is hozott be log4j függőséget, azonnal ki kell vadásznom a teljes dependency fából. Most még be kell dobálni a slf4j api-t, majd a log4j-over-slf4j csomagot...

A végeredmény az, hogy a JPA implementáció cseréje sokkal kevesebb időt vett igénybe mint a logging api cseréje. A logging az a dolog amitől azt várnám hogy nem zavarhat semmit, nem romolhat el és nem okoz semmiképpen sem futási hibát.

"Lassan haladunk, de nem baj, mert rossz irányba"

2009. június 21., vasárnap

Rémálom a JPA utcában

Ezt a problémát próbáltam felvázolni Tvik-nek a eclipse democamp elött, de azt hiszem túl alacsonyan volt akkor még az agytevékenységem hogy sikerrel járjak. Meg talán viccnek túl hosszú ez az egész.

Szóval egyik nap áthívott az egyik srác egy másik projecttől, hogy segítsek elindulni a JPA persistence tesztek fejlesztésével a projecthez. Eléggé félfüllel követtem a project életét, szóval igazából csak nagyon kevés ötletem van arról hogy mi miért jutott oda ahol van az architektúra fejlődése során, de ehhez a feladathoz ezen a ponton rendelkezésünkre állt:
  • Netbeans-ben kigenerált JPA controller kód (ahogy én értettem ez ugyanaz mint a DAO pattern)
  • persistence.xml kitöltve a production környezethez (JNDI datasource inside)
  • Azt hiszem szintén generált perzisztens osztályok
  • Maven-es build
Feladat: A kódot teszteljük úgy, hogy használjuk fel hozzá kigenerált kódot is. Szóval sima DAO tesztelés.
A generált kód nemnyúkapiszka tárgya.

Első nekifutásra egyszerűen azt javasoltam a kollégámnak, hogy egyszerűen dobjon be egy új persistence.xml-t a teszteknek, és használja azt a tesztekből. Biztosan lehet valahogy, mert a spring és a unitils is meg tudja mondani a persistence layernek, hogy melyik persistence.xml-t használjuk fel. Mondani könnyű persze.
Párhuzamosan én is elkezdtem keresni, hogy vajon a JPA-nak hogy is kell ezt megmondani, de látványosan sehol semmit nem találtam, csak akkor nem foglalkoztam vele tovább mert persze én másik projecten vagyok és azt kell hegeszteni.

Második nekifutás: Be kellett látnunk hogy kicsit alaposabban kell foglalkozzunk a JPA kérdéssel ahhoz hogy a teszteket élesbe állítsuk. Összeültünk egy eredetileg rövidre tervezett pair programming sessionre és nekiláttunk átnézni a teszt menetet. Hamarosan kiderült hogy a spring valami nagyon hosszú tréfát használ arra, hogy a persistence.xml-t más néven keresse meg és ezt nem akartuk átmásolni tőlük, inkáb az volt az alapötlet, hogy a spring-gel inicializáltatunk egy JPA EntityManager-t és azt odaadjuk az érintett DAO objektumoknak. A JPA init ment is mint a karikacsapás, de amikor odaértünk, hogy beletömjük a DAO objektumokba az eredményt, akkor elmúlt a jókedv: a generált osztályok konstruktora inicializálta és private mezőként tartotta az EntityManagert. Azaz szépen udvariasan nem tudunk hozzányúlni. Ráadásul a kódba bele van generálva a persistence unit neve is. Ezt az egészet úgy látszik úgy találták ki, hogy a végleges környezeten kívül máshol ne lehessen futtatni. Azaz nem tesztelő-barát.

Harmadik nekifutás: Override-oljuk a konstruktort. Ja, de az ősosztály default konstruktora akkor is meghívódik. Rövid roham, fejvesztett menekülés.

Negyedik nekifutás: Jó, akkor használjuk a production-ra szánt persistence.xml-t és mielött mindezt felstartoljuk, dobjunk össze egy JNDI contextet a teszt DataSource objektummal. Ez tűnt vagy fél órán keresztül a nagy és tökéletes ördögi tervnek, én teljesen hittem a sikerben amíg a tesztbe drótoztam a spring-test csomag JNDI mock csomagját és startnál elmondtam a varázsigét is, hogy "Fuss QA!!!".... és nem működött. Azért nem, mert a spring JNDI mock csomaga pár metódust nem implementált a JNDI standardból, amit a JPA implementáció akkor is meg akart hívni. Na igen, régen használtam a spring JNDI implementációját és fogalmam nem volt a korlátairól.

Ötödik nekifutás: diplomáciai tárgyalások az ellenséggel. Ekkor kitaláltuk, hogy akkor a build eszközzel etetjük meg azt, amit a szőrös apikkal nem tudtunk. Nos a maven esetében ha két ugyanolyan nevű resource van a src/test/resources és src/main/resources alatt, akkor úgy tűnik kb véletlenszerűen fogja egyiket vagy másikat megtalálni. Nincs más választás, külön profile-ba kell tenni az éleset és a tesztet.
Ant-tal pofátlanul egyszerű lenne a junitnak odalökni egy másik classloadert. Rettenetes mellékhatások: nem futhat egy buildben a deploy és a teszt. A CI konfiguráció se lesz persze egyszerűbb.

Tanulságok:
  1. Rájöttem hogy eddig soha nem próbáltam spring nélkül JPA apit használni
  2. És valószinűleg ez az oka annak, hogy nem utáltam meg már az elején a JPA-t. A JEE architektúra csak kicsit lett kevésbé toldott-foldott mint a jó öreg EJB 2.1 időkben.
  3. A generált kódoktól nagyon udvariatlan dolog, hogy ők akarják inicializálni a persistencemanagert és erről nem lehet lebeszélni őket.
  4. A JPA-ban már az elején nem tetszett, hogy a META-INF/persistence.xml-hez ennyire ragaszkodik, de nem gondoltam, hogy nincs is szabványos megoldás ennek a felülbírálására.
  5. A netbeans generált kódjaitól ments meg uram mintket!
  6. Amikor ilyen kavar a kód, a maven szigorú struktúrája is akadállyá válik.

2009. június 18., csütörtök

Eclipse DemoCamp frissen

Ma este betértem az Eclipse DemoCamp 2009 rendezvényre, szocializálódni és telepakolni a szatyromat információkkal. A hely egy kellemes kis teázó a vár aljában, a hőmérséklet és a népsűrűség is sokkal kellemesebb volt mint tavaly. Persze nem azért, mert kevesebben voltunk :) Kicsit lassan rázódtam bele a hangulatba, inkáb már csak az első előadás után kezdtem kommunikálni emberekkel.

Előadások...

Bocsi, még mielött nekivágok... Nem próbálom hitelesen visszaadni az előadások tartalmát, az biztosan elérhető lesz majd valahol, a saját reakcióimat írnám le ide velük kapcsolatban.
  • Nagy Gergely: Dependency Management with Ivy and IvyDE
    Demókkal megtűzdelt előadás volt arról, hogy az Ivy-t hogyan lehet fejlesztőbarátabbá tenni egy eclipse plugin segítségével. Volt is benne apróbb bug, egyszerű javítással. Ahol kicsit nekem elakadt a lélegzetem, az a repository modell volt. Miért lett ez ilyen bonyolult?
    Feltettem az a kérdést, hogy ha "csak például :)" én mavent használok, de a cég egy másik csapata ivy-t és ant-ot, tudnak-e ők nekem olyan mavenes descriptort generálni a ivy dependency-kből, amivel az én mavenes projecteim tudják használni az ivy+ant kombinációval buildelt cuccot. Gergely mondta, hogy nincs ilyen megoldás és Jason hozzátette hogy igazából nem is lehet, a két project classloader rendszere teljesen más és összeegyeztethetetlen.

    Kövekeztetés: a Cégen belül ha valaki ilyet használ, az nekem nem segítség. Továbbra is hímezhetem kézzel a pomokat.

  • Jason van Zyl: Next Generation Enterprise Builds: Maven, Mercury and Tycho
    Külföldi sztárelőadóval folytatódott a build eszközök harca :)

    Szóval Jason elegánsan átsiklott a maven 3.0 téma felett, ahol én meglepődtem, mert a maven 3.0-ról most hallottam elösször és nagyon érdekelt volna erről minnél több infó, de ennyit kaptunk: minden működni fog a maven 2.x-ből 3.0-on is.
    A m2eclipse alias Tycho igazán meggyőző demó volt. Persze volt benne pár apróbb hiba, mint minden live demóban, de talán végre eljött az ideje, hogy beálljak a sorba és elfelejtsem az 'mvn eclipse:eclipse' parancsot. Amúgy is túl geek-es volt, windowson meg rettenetes.
    A nexusról nem sok újat tudtam meg, mondjuk azon amennyire tudtam rajta tartottam a szemem. Az első pár feature requestet én dobtam be rá és igazából elégedett vagyok azzal amit kaptam ingyen :) A kérdésem az volt hogy mi az, ami kiemeli a nexus-t a maven repository managerek versenyéből. Jason alapvetően a stabilítást és a teszteltséget emelte ki, valamint hogy az archiva igazából bebukóban van.
    További információmorzsa: a nexus a jsecurity-t használja azonosításra és csak 1 hét volt beintegrálni, ami jobb mint a spring-security. Volt nekem is pár problémám a spring-security-vel, de soha nem szúrtam el rá 1 hetet. A rekord egy régi grails-es projectemen volt 2 estényi gubancolás, mert akkor még a grails is gyerekcipőben járt, meg groovy-ban is az volt az első dolog amit írtam. Házi feladat: jsecurity


    Félig meddig ide tartozik, és a következő blog postom arról fog szólni hogy milyen torkos szívás volt generált JPA kódra írt teszteket futtatni mavennel. Pff, a kódgenerálás a múlt század. Nekem az idl compilerek jutnak róla eszembe.

  • Bánfai Balázs, Török Zsolt: Transition from classroom to real-life software engineering
    Nos ebből a szempontból az én karrierem - ha beszéljetünk ilyenről- nem a szokásos dolog. Soha semmi hasznosat nem tanultam iskolában főleg nem informatikáról, és bár jártam egyetemre, úgy érzem hogy -persze csak intellektuális- pofonokon kívül mást nem kaptam. Persze kell a karó a virág mellé, de hát... kéne a virág a karó mellé.
    Úgyhogy erről kimentem dumálni a teázó elé, aztán pedig hazatekertem.

Köszi a szervezésért és a kajáért a B2 International-os arcoknak!

Sziasztok, boldog csütörtököt!

2009. május 29., péntek

easyb próbakör

A CÉG másik fele (nem az amelyikben én működök, hanem a gonosz fele) nagyon kedveli a fitnesse-ben írt teszteket. Az első alkalomtól kezdve nekem nem volt szimpatikus ötlet az, hogy a programomat browserből teszteljem, wiki-ben editáljam a teszteket és ráadásul összelőni a builddel is egy borzalom (ebben a legfőbb gonoszok is egyetértettek). Másoknak se jött át az ötlet. Elkezdtem hát más, kicsit elterjedtebb megoldást keresni.
Kipróbáltam mennyire tud fájni a easyb-vel történő tesztelés és megosztanám veletek:
  • A teszt tulajdonképpen groovy forráskód. Editálhatja az ember eclipse-ből -ha van groovy pluginja-, vagy alighanem netbeans-ből is (nem próblátam ki). Valamennyi highlight-olást kapunk hozzá, meg egy kics code-completiont-t is. Nem sokat egyikből sem.

  • Futtatni ezt így eclipse-ből is lehetséges, de kicsit fapados (mondjuk a fitnesse-hez képest még mindig sci-fi)
  • Maven-ből hajtva kicsit lassú, de rendesen fut.
  • A példa kimenet szerintem viszonylag jól öndokumentáló (fájjon csak az angoloknak amit csinálunk a nyelvükkel):
    3 scenarios executed, but status is failure! Total failures: 1

    Story: situation

    scenario normal everyday life
    given a normal situation
    when there are some problems
    then that is just usual


  • Példa projectet ide pakoltam fel.

2009. május 20., szerda

JUM 2009-05-20

Ma végre összespóroltam rá időt és elhúztam a JUM találkozóra.
Ezek voltak sorrendben:

  1. Révész Tamás: Groovy és Java használata SOA projectekben.
    Cobol backend elé bármit is építeni nem lehet móka. Az előadó nem volt szerintem igazán ellazulva az előadáshoz, kapkodott, amitől nekem kicsit nehezen jött át pár infó, de megpróbálom visszaadni.
    Szóval valamiért cefet sok XSLT-t kell generálniuk, néha egészen nagyokat is, és ezt automatizálták groovy-val. Utánna még kézzel meg kell igazítani (robotok sportja). Szóval csak a build processz és fejlesztés támogatásához használnak groovy-t, élesben nem fut. Gondolom nem tennék szivesen élesbe az 1600 soros scriptet.
  2. Cursin Decurtins: Rapid prototyping with object-oriented databases
    Nyilvánvalóan szívás, amikor egy project elstartolásakor napokig elbíbelődik az ember az architektúra összekalapálásán. Főleg ha csak demó vagy prototype project. Adatbázis, mapping, miegymás. Persze segít valamit, hogy ma már elterjedtek beágyazott relációs adatbázis motorok, mint a derby, de alapvetően sokkal kevesebb meló lehet, ha nem kell mappinget írni. Az objektum adatbázis egyetlen közvetlenül elérhető layer. Példaként a db4o-t mutatta be az előadó. Valóban nagyon egyszerűnek tűnik a lekérdezés, bár volt egy pár példa, ami mögött én csúnya apikat sejtettem. Standard api nincs hozzá, ami talán annyira nem fáj egy prototype-nál. Viszont a mock-os meg a fake-k miért nem jók? Production használatra a szerző nem igazán javasolta egyik terméket sem.
    Szóval ha jól értettem, mitán megcsináltad az egyszerű objektum adatbázison a prototype-t, meg kell írnod relációs adatbázis kezelőre is.
  3. Elek Márton: Amazon WS
    Ez elég pöpec volt. Azt hiszem ideje végre komolyan utánnanézni a témának, bár a bankszámlám számát nem szivesen adnám meg az amazonnak. Mint kiderült az kell nekik, nekem viszont borzasztó rossz tapasztalataim vannak a netes fizetőeszközök megbízhatóságával kapcsolatban.

2009. május 13., szerda

python kitérő

Rövidebb időre átkényszerültem python használatára 3d alkalmazást kalapálni. Nem első ütközés a pythonnal (például itt egy scriptem ami Oracle[TM] MySQL dumpformátumát tömi be PostgreSQL-be... Hmm, lehet ez még hasznos lesz egyszer....), de munkában talán most használtam elösször úgy, hogy nem csak valami gyors egyszeri hegesztés, hanem élesben kell mennie és futnia, ügyfelek nézik majd az eredményeit.
És hát rendesen megszívatott a httplib-bel. Az az alapfelállás, hogy ez a progi egy queue-t polloz melóért, renderel valamit a saját kis 3D enginén és az eredményt szépen visszateszi az queue-ba. Mivel persze az eredmény egy szép nagy kép, gondoltam file uploaddal elpostolom. A probléma már itt elkezdődött, ugyanis a httplib ilyet nem tud. Az urllib sem tud, a későbbi python verziókban megtalálható ezeknek a libraryknak a 2-es verziója (httplib2, nagyon elegáns), de azok sem tudnak ilyesmit.
Valahol megtaláltam, hogy mikorra igérték ennek a javítását, de ezzel inkáb nem keltenék pánikot, nekem amúgy sem volt adott lehetőség, hogy felűbereljek kevésbé régi python verzióra.
Mindenesetre itt van egy nagyon egyszerű és működő megoldás file uploadra. Kis módosítás után már működött is, és boldog voltam hogy ezt is elfelejthetem. Érdemes még ezen a lapon megnézni hányan jöttek alternatív megoldásokkal.
Egészen addig tartott a boldogság, amíg a CI rendszer fel nem kapta a változtatásokat és ki nem próbálta. Az úgy 2-3 perc. Ami a localhoston működött, az valamiért mocsokul nem akart menni a tesztkörnyezeten, legmeglepőbb módon 404-et dobott az MQ, amikor vissza próbálta küldeni a eredményt. Eltartott egy ideig, amíg végigkotorásztam a tesztrendszer konfigurációit, nézegettem a logfilejait, míg végül már wireshark-ot rántottam, és ott is jó ideig néznem kellett míg végre észrevettem: http 1.0-át használt a file uploadhoz. A http 1.0 egy matuzsálem, nem voltak virtuális hostok benne, így az apache-nek végig fogalma sem volt hogy kinek postol a kliens progi.
Innentől még egy szép nagy kalapálás volt, mire sikerült végre rávennem, hogy http 1.1-et használjon a file uploadhoz is.
Úgyhogy a fenti linken látható alternatív megoldásokhoz hozzátenném a saját mégalternatívabb megoldásomat. Még szerencse, hogy mindent tesztelünk, a publikus tesztoldalakon már sokkal nehezebb lett volna kideríteni az igazságot.

Kiváncsi vagyok a profi python programozók ezt hogyan használják. Például a google a legnagyobb python felhasználó. Vajon nekik ez nem fájt?

2009. április 7., kedd

Apache ftpserver próbakör...

Elösször is szerintem az FTP filetransfer-es rendszerintegráció egy agyhalál, idejétmúlt, matuzsálem, őskövület, stb, de úgy tünik távoli munkatársaim egész hadai nem értenek ezzel egyet, és miután beláttam, hogy nem tudom másra rávenni őket, eltöltöttem egy kis időt káromkodással persze, aztán lekódoltam a cuccot és oda jutottam, hogy unit tesztel kellene körbetámasztgatni a dolgot. Jobb későn, mint soha :-)
És hamár unit-tesztelünk, de szép lenne ezt az egészet úgy csinálni, hogy ne kelljen neki valami ftp szerver valahol, felhasználóval, satöbbi, hanem ahogy van a project kicheckoutolás után már úgy magában is le tudja tesztelni önmagát. Arra gondoltam, hogy az ftp file-transzert kezelő kód teszteléséhez felstartolok egy beágyazott FTP servert, konkrétan a nemrég megjelent, MINA alapú Apache Ftpserver akadt a kezembe. Igazából az hogy NIO-s az ebben az esetben semmit sem ér, de a virtuális file-rendszere, "ftplet" api... szép kis cucc.

Hmm, hát tényleg beágyazható és nagyon jól megy, de a pársoros kis izé helyett 20-30 sorosra hízott inicializációt kellett írnom hozzá, ami azért szerintem sok egy tesztben. Plusz az enyémhez hozzá kell venni a filerendszer kurkászást és az azonosítási rendszer inicializációját is. Szóval kis egyszerűsítéssel szerintem jó fájdalomcsillapító lehetne.

2009. április 3., péntek

Agyhalott AOP svájcibicska

Pár AOP-os cuccom mostanában, ami szerintem egy jól működő rendszerben nem, vagy csak ritkán tudnék elképzelni...
  • Cache interceptor: főleg távoli metódushívások elé. Ez talán még nem olyan vészes. Egy akármilyen jcache megteszi neki, vagy egy map is. Újabban adatbázisba perzisztált map-en kisérletezek, annyi adatot kell cachelni és a backend olyan gyenge, hogy a memória + frissítgetés nem lenne jó megoldás.
    Ennek még látném valami hasznát egyébként, de azért érdemes odafigyelni a példaértékűen halott spring-modules cache projectjére.
  • Timeout intercetor: ha a metódus nem tér vissza X idő alatt (lassú backend), akkor hagyja futni és egy bekonfigurált értéket ad vissza helyette, vagy hibát. Ezt nyilván úgy csinálja, hogy külön szálat indít neki.
  • re-try interceptor: Szerintem ez a legbetegebb :) Van pár dolog, ami elsőre néha nem sikerül, és ilyenkor simán lehet hogy másodszorra vagy harmadszorra igen. Talán. Szerintem ez botrány, de ez van. Ez az interceptor elkap bizonyos bekonfigurált hibákat és újrapróbálja a hívást. Például egy bankkártya művelet tipikus példa arra, hogy hol nem merném bevetni :-) Persze azok is besz@rnak hébe-hóba.
  • Logging interceptor: a lassan válaszoló hívásokat logolja. Nem mintha utánna tudnék javítani a lassú backendeken...
Ez így egy április elsejei bejegyzésnek is elment volna, de nem az :-)

2009. március 23., hétfő

maven release plugin

Úgy egy éve áttértünk a melóban is maven-re. Igazából ennek nem holmi technikai "megvilágosodás" állt a hátterében, egyszerűen annyi, hogy a főnököm magasabb pozícióba lépett és a technikai jellegű feladatait átadta nekem, én pedig a magam módján folytattam. Bocsi ezért a kitérőért, csak a honi csillagászat fejlődéséről olvastam egy nagyon jó könyvet nemrég, ami számos helyen megemlítette, hogy a paradigmaváltásokhoz egyszerűen csak generációváltás kellett a csillagászok között is. Na, ennyit megtettem ennek a mém-nek a túléléséért.

Nemrég egy másik projecttel kapcsolatban mégiscsak kiváncsiak lettek a többiek hogy hogyan csinálok egy release-t ebből az egészből. Elkezdtem hát elmutogatni a maven release plugin hogyan működik és azt hiszem volt pár dolog amin jogosan ráncolták a homlokukat.

Ennyi, amit csinálok: mvn release:clean release:prepare release:perform

Ezt csinálja helyetted a release plugin "release:prepare":
  1. Megnézi, hogy szinkronban vagy-e a verziókövetőddel
    Igen, itt például svn parancsot akar futtatni az operációs rendszereden keresztül. A $PATH-on rajta kell legyen. Itt kezd macerássá vállni a dolog a windows felhasználóknak.
  2. Lefuttatja a teszteket.
  3. A pom.xml-ben módosítja a verziót akármi-SNAPSHOT-ról simán akármi-re. Ezzel a SNAPSHOT dologgal is keresztben vannak páran nálunk, én nagyon bírom. Ezután bekommitolja a pom.xml-t, és egyből létre is hoz neki egy tag-et. Azaz létrejött egy tag, amihez nem is kell hozzányúlni, hogy a pom-ban a korrekt információk benne legyenek a verziójáról és persze ay SCM tag is a megfelelő információt tartalmazza.
  4. Átírja a pom.xml-t a legfrissebb fejlesztési verzióra és a scm url-t trunk-ra (illetve arra a branch-ra, ahol vagy) és bekommitolja. Szóval szépen elindított téged a következő verzió felé.
Majd a release:perform:
  1. Az éppen az "elöbb" betagelt verziót kicsekooutolja a target dir alá akárhova...
    A release:perform onnan tudja, hogy mi lett tagelve az elöbb, hogy hagy magának egy file-t a pom.xml mellett. Ezt a file-t a release:clean parancs törli le, ezért ezt is a biztonság kedvéért (azaz hogy ezen se kelljen gondolkodnom) a release parancs elejére oda szoktam írni, nehogy ott legyen az előző futásból és valami hülyeséget csináljak.
  2. Lefuttatja rajta a unit-teszteket, csak hogy biztos legyen a dolgában :-)
    Itt az a trükk, hogy igazából egy új mvn processzt indít el, azaz ha nincs az mvn parancs a $PATH-ban, akkor megint problémák következnek.
  3. Amikor kész, packagel, majd a distributionManagement tag információit felhasználva bedobja a csomagot a maven repo-ba.
    Ez nyilván csak egy sima deploy, nem release plugin spec a dolog, de el lehet tévedni. Például hogy ha scp-t használ az ember deploy-hoz, akkor kell neki egy scp. Windows felhasználóknak megint fejtörés, linuxon azért mindig ott van.
    A szervered nevére szükség van egy server bejegyzésre a settings.xml fileodban.
Kiválló lehetőségek elcsúszásra:
  1. első számú ok, hogy az SVN hozzáférésed nincs korrekten beállítva (nálam tipikusan a megbízhatatlan DNS szolgáltatás okozott bajokat régebben) és bár már módosította pom.xml-t, nem tudta bekommitolni. A dolog persze itt leáll, de nem csinálja ám vissza a változtatást. Ilyenkor futtatni kell egy svn revert-et a módosított file-okon.
  2. Ha nincs a setting.xml-ben megadva a maven repod eléréséhez a jelszó.
  3. És még egy pár dolog ami most nekem se jut eszembe :-D

Szóval a dolog legkevésbé sem golyóálló, de ha egyszer belőtted, akkor gyorsan kész lehetsz a release csomagolás unalmas feladatával, a kockázatokat és a mellékhatásokat is minimalizáltad. Ideális a release often release early gondolatvilágához. :)

Maven. Lustáknak, butáknak és nemtörődömöknek egyaránt tudom ajánlani.

A JUM-on megint nem voltam. Nagy megkönnyebbüléssel vettem tudomásul hogy nem került schedule-ra az a scrum kedvcsináló quickie, amit többen kértek tőlem, és inkáb a lemaradásaim csökkentésével foglalkoztam. Sajnos ki se látszom mostanában, például a fenti okokból.

Időközben pedig a scrum-ot kivégeztem, azaz alaposan átfaragtam a munkahelyi projectemen.

Ennyi a helyzet nálam. Boldog hétfőt, sziasztok!

2009. március 4., szerda

Néhány (majdnem) random gondolat

Mostanában kicsit elment az időm a munkámmal, ami nem túl érdekes, de persze abból is jön be valami input amit az ember összegez és eltesz későbbre. Ez jön most:
  1. Soha soha soha nem szabad elfogadni adatbázis schema-t gondos átbogarászás nélkül. A legcsúnyább dolog amikor migrálni kell az optimalizált adatszerkezetre. Előfordul ugyanis hogy valaki csv formátumban tart reláviókat. Ezzel már nem elösször szívattak meg életemben, de az előző úgy látszik túl régen volt.
  2. A beszállítókon be kell vasalni nem funkcionális követelményeket is, mint pl hogy a konfiguráció ne legyen belehegesztve a spring configba, de legalább tegyenek bele valami post processor bean-t (lehetőleg overrider-t), mert az üzemeltetők halálra szívják magukat a konfigurációk mergelésével. Ezeket a nem funkcionális követelményeket pont ugyanúgy kell kezelni mint a funkcionálisakat: ha nincs meg, akkor visszadobni. Ilyenkor kerülünk egyébként satuba a saját üzletembereink és az ellenség üzleteberei között. Még mindig jobb mint egy hét live rendszer pátyolgatás.
  3. Forráskód komentek: Soha ne írj trágár szöveget a kódba, nagyon rontja a munkahelyed imázsát amikor valaki idegen találja meg! Én most egy ilyet találtam: "Dirty hack to load the fuckers." Valójában velocity template-kről lenne szó egyébként. Nem vicces, bár nevettem rajta, de igazából azt gondoltam hogy jól kivagyok a szamócából ezekkel a srácokkal. Ugyanis engem rugdosnak az üzemeltetők ha a dirty hack mégsem működik.
    Ilyen is volt már régen, egy régi munkahelyemen valaki magyar káromkodást írt bele a logba, a német ügyfél visszaküldte a logfile-t, hogy nem érti.

2009. február 24., kedd

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.

2009. február 4., szerda

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.

2009. január 30., péntek

OFF: globálproblémák

A gazdasági vállság első hullámai hozzánk is eljutottak mostanra, a munkahelyem is nekilátott a leépítéseknek (ami a szokásos közismert multinacionális médiacég). Ez tök unalmas és agyontárgyalt dolog, csak egy megfigyelésemet szeretném megosztani, ami legalábbis engem meglepett:

Az elbocsájtott dolgozók között körülbelül saccra ugyanannyi a lusta és a szorgalmas, ugyanannyi a balfék mint a született tehetség, sőt a managerek és beosztottak aránya is passzol. Nem az a szempont, hogy a jól dolgozó embereket megtartsák, hanem egyszerűen akinek megszünik a projectje azt kirúgják.

Ettől kezd izgalmas lenni a játék.

2009. január 25., vasárnap

System.currentTimeMillis() tréfa

Na most kicsit sok idő kimaradt, az utóbbi időben jól el voltam látva munkával. Az XML-es ámokfutásomat is csak most tudom majd újrakezdeni. Bocsi mindenkitől, aki másnapra várta.

Megint kis bullshitelés következik.

Mese... A régi cache-interszatyorhoz írtam egy unit tesztet, ami párhuzamosan futó szálak lockolási megoldását teszteli. Azt a tulajdonságát akartam unit teszt karókkal megtámogatni néhány oldalról, hogy ha egyszerre egy cachelt szolgáltatást ezren meghívnak egyszerre, ne történjen meg minden hívás, hanem csak egy, a többi pedig kapja ugyanazt - ez egy fontos opció a cuccban, könnyen agyoncsaphatjuk valamelyik backendünket. Ezt kétféleképpen is verifikálom: minden szál lefutás után a ugyanazt étréket kell visszaadja a cache-ből, valamint mivel a cache-vel körbevett metódus maga úgy lett leheggesztve, hogy 1000 ms-ig tartson, azt is ellenőrzöm hogy 1000 ms-nél több időbe telljen a hívás, és persze az érintett cache-vel körbefalazott metódus csak egyszer hívódjon meg ténylegesen.
És ment is elsőre mint a karikacsapás, boldogság zöld csíkja. Egészen addig, amig be nem dobtam az SVN-be a cuccot és a nyilván linuxon futó build agenteink fel nem kapták hogy ők is kipróbálják tényleg megy-e. És nem ment :-) Nagyon gyanúsan 1000 ms köré eső értékek jöttek, de hát alatta voltak kicsivel.

A probléma az volt, hogy a System.currentTimeMillis() nem egészen pontosan adja vissza minden operációs rendszeren a jelenlegi értéket, hanem egy kicsit szemcsésen. Csak 64 bites linuxon sikerült ezt elérni amúgy. Ez így emlékeztetőnek kiválló volt, hogy ilyeneket ne írjak unit tesztekbe :)


Egyébkén köszi a szavazatokat, 4.5 fölött van idáig az átlagom, legutóbb általános iskolában volt így talán.