Java EE 6 előadás

Ismerkedés a Java EE 6 újdonságaival. Az előadást egyik kollégánk tartotta.

JSystem

A JSystem egy JUnit alapú ingyenes, nyílt forráskódú teszt automatizálási eszköz. Lehetővé teszi pl. scenario-k létrehozását, vagyis a tesztekből csoportokat lehet képezni, és ezek a csoportok tárolhatók, visszatölthetők pl. egy-egy feature tesztelése céljából, vagy minimál teszt, komplett teszt, stb. kialakításához.

Automatikusan generál HTML reportokat, amiért minden menedszer és ügyfél hálás (sőt, a report generáló alrendszer cserélhető). Továbbá definiálhatók tesztkörnyezetek, paraméterezhetőek a tesztek, menedzselhetők több gépes elosztott tesztek, stb.

Részletek: http://www.jsystemtest.org

Adat (f)eldolgozás

Egyik ügyfelünk érdekes problémával keresett meg minket. Leegyszerűsítve: ZIP fájlokat töltenek be a rendszerükbe, de a UI valamiért többször jelenít meg bizonyos fájlokat, hiába csak egyszer lettek betöltve.

A betöltő alkalmazásnak saját adabázisa van, úgyhogy ott kezdtük a keresést. Itt minden jónak tűnt, ugyanazokat a select-eket futtatva, mint a betöltő alkalmazás, az elvárt eredmény kaptuk. Nah akkor nézzük a kódot...

Régen íródott nem igazán refaktorált alkalmazásról lévén szó, amiben egy pár ezer soros "fő-fő" Servlet-hez jutottunk, ami implementálta az üzleti logikát. Az alkalmazás az adatbázisból lekérdezett adatokat rendezi pl. név, ill. feldolgozás kezdete, feldolgozás vége szerint.

Az egyik kollégát idézve: "ÁÁÁ a rendezéssel nem lehet gond, azt nem lehet elrontani..." Azért csak megnéztük a rendező kódot, és bizony itt volt a hiba. Valószínűleg idő hiányában a ZIP fájlok adatait egy String listában tárolták a fejlesztők a következő formátumban:
[név]*[feldolgozás_kezdete]*[feldolgozás_vége]*....

Egy ilyen listát rendezni nem olyan egyszerű. Praktikusabb lett volna egyszerű DTO objektumokban tárolni az adatokat, és Comparator-okat írni az egyes szempontok szerinti rendezéshez... Ehelyett kiszedték a megfelelő adatot minden egyes elemből, egy külön listában lerendeztették őket, majd egy harmadik listába a megfelelő sorrendben szúrták be az adatokat. A végső lista összeállításába csúszott hiba. A kód nem tudta lekezelni azt az esetet, amikor két Zip fájl esetén, az egyik feldolgozás_kezdete megegyezik a másik feldolgozás_végé-vel. Tanulság: A rendezést is el lehet rontani. :)

U.i: erre a részre nem találtunk sok unit tesztet a kódban, pedig azok segíthetettek volna elkerülni ezt a problémát (is).

F.B.

PHP 4 vs PHP 5, 2. rész

Az első rész: http://epam-debrecen.blogspot.com/2010/02/php-4-vs-php-5-1-resz.html

Egy másik gyakori kódtípus, ami nem ugyanúgy viselkedek a különböző verziókban:

class Category {
    var $id;
    var $parentId;
    var $children;
    
    function Category( $id, $parentId=0 ) {
        $this->id       = $id;
        $this->parentId = $parentId;
    }
}

$categories[1] = new Category( 1 );
$categories[2] = new Category( 2, 1 );
$categories[3] = new Category( 3, 1 );
$categories[4] = new Category( 4, 2 );
$categories[5] = new Category( 5, 3 );

foreach ( $categories as $id=>$category ) {
    // Az újabb verziók automatikusan referencia 
    // szerinti átadást használnak:
    $categories[$category->parentId]->children[$id] = $categories[$id];     
    // A régebbiekben ezt nekünk kell kényszerítenünk:
    $categories[$category->parentId]->children[$id] = &$categories[$id];    
}

Pl. adatbázisból kapunk egy halom adatot, ahol a rekordok között szülő-gyermek( 1-n ) viszony van, és szeretnénk egy egyszerűen bejárható fát építeni belőlük minél kisebb költséggel. Erre a problémára adnak a referenciák egy lineáris időben futó, kis költségű lépésekből álló megoldást.

A PHP manualra jellemző, hogy a referenciák felhasználási területei közül pont egy olyat említ, amivel az objektum metódusainak megkerülésével nyúlhatunk hozzá egy taghoz. Rossz szokás, ami az esetek 95%-ában csak ront a kódon:

class foo {
    public $value = 42;

    public function &getValue() {
        return $this->value;
    }
}

$obj = new foo;
// $myValue is a reference to $obj->value, which is 42:
$myValue = &$obj->getValue(); 
$obj->value = 2;
// prints the new value of $obj->value, i.e. 2.
echo $myValue;                

Az igazi szépsége a dolognak, hogy private tagokhoz is hozzá lehet férni ezzel a módszerrel :)

B.J.

PHP 4 vs PHP 5, 1. rész

Aki PHP-val foglalkozik már megszokhatta, hogy a legtöbb projekten a host korlátai miatt nem használhatja a legújabb verziókat. Különösen igaz ez a legacy fejlesztésekre, ahol gyakran még a 4.x verziókkal kell beérni, mivel az átállás sok helyen nehezen észlelhető bugokat okozna. Az egyik ügyfelünk rendszere is részben 4.x verziójú.

A legegyszerűbben észlelhető probléma rengeteg kényelmi funkció (file_put_contents, paraméterezhető microtime és a többiek) hiánya. Ez kényelmetlen ugyan, de hamar kiküszöbölhető. Valamivel nehezebb hozzászokni az interfészek, absztrakt osztályok, láthatósági szintek és osztályszintű statikus változók hiányához.

Az egyik legkevésbé nyilvánvaló, viszont fontos változás a paraméterek átadásának módja. Az újabb verziók skalárokat és a tömböket érték, minden mást referencia szerint adnak át, míg a régiek az érték szerinti átadást használják objektumok esetén is. Ez legelőször valószínűleg Singletonok használatánál tűnik fel, egy bosszantó és nehezen észrevehető bug formájában:

class Singleton {
    function getInstance() {
        // PHP 4-ben ez a legegyszerűbb módja
        // az instance nyilvántartásának
        static $instance;  
        if ( !$instance ) {
            $instance       = new Singleton();
            $instance->test = "A";
        }
        return $instance;
    }
}
$temp       = Singleton::getInstance();
$temp->test = "B";
// PHP 5 esetén B lesz, különben A.
print Singleton::getInstance()->test; 

Ez a kód átalakítva, hogy régi phpban is ugyanaz legyen a végeredmény:

class Singleton {
    // Jelezzük, hogy a metódus az eredményt 
    // referencia szerint adja vissza
    function &getInstance() { 
        static $instance;
        if ( !$instance ) {
            $instance       = new Singleton();
            $instance->test = "A";
        }
        return $instance;
    }
}
// A visszatérési értéket referencia szerint rendeljük változóhoz
$temp = &Singleton::getInstance(); 

B.J.

Java programozókat keresünk

Egyik csapatunk bővítéséhez Java programozókat keresünk:

Requirements:
Liferay 5.1.2
JSR 168 portlet development
Hibernate
Struts, Spring
Developing against Oracle 10i (fairly good SQL knowledge)
Java development experience

Advantages:
IBM Rational Application Developer (preferably used before)
IBM Websphere Application Server (must know the console usage, deployment, configuration, troubleshooting)
IBM HTTP Server (configuration and troubleshooting)

Soft skills:
Strong Communication skills
Learning ability
Strong trouble shooting skills

Ruby előadás

Ismerkedés a Ruby-val. Az előadást egyik kollégánk tartotta.