Quartz

Quartz je ogrodje za pisanje aplikacij, ki temeljijo na periodičnih opravilih. Je odprtokodni sistem, ki lahko poganja samostojne aplikacije v Java jeziku ali pa take pisane za EE okolje. Uporabljamo ga kot razdeljevalnik poslov, ki so del nekih poslovnih procesov na strežniku ali strežnikih, saj podpira tudi gruče (load-balance fail-over). Lahko ga uporabimo tudi kot RMI (Remote Method Invocation) strežnik.

S konfiguracijo lahko dosežemo, da prožilci (triggers) prožijo posle (jobs) na praktično neomejeno število načinov. Na primer:

• v določenem trenutku dneva (na milisekundo natančno)
• na določen dan v tednu/mesecu/letu
• periodično (n-krat, v neskončnost)
• do določenega datuma/ure
• ponavljajoče z zamikom
• ne na določen datum (praznik)

Posle lahko organiziramo v skupine in jih tako logično združujemo.

V Quartz-u imamo torej koncept posla in prožilca. Za en posel imamo lahko več prožilcev. Konkretno je posel, ki ga želimo izvesti (ali izvajati) implementiran kot razred, ki implementira vmesnik Job (ali InterruptableJob). Implementirati moramo samo eno metodo (execute), v kateri izvedemo kar želimo. Posle in prožilce lahko instanciramo programsko ali pa deklarativno. Osebno sem dosedaj uporabil slednji pristop, saj omogoča v produkcijskem okolju zelo enostavne spremembe kdaj na se kaj izvede. Potrebna je samo sprememba XML konfiguracijske datoteke. Quartz preverja ali se je kaj spremenilo in ustrezno reagira, torej nam ni potrebno aplikacije ponovno zaganjati, če želimo spremeniti na primer urnik posameznih opravil.

Posle, prožilce in ostale informacije o razdeljevalniku lahko hranimo tudi v podatkovni bazi, kar pomeni, da v primeru sesutja aplikacije ne izgubimo potrebnih informacij za nadaljevanje poslov ob ponovnem zagonu.

Če želimo prekiniti dolgo izvajajoč posel, potem implementiramo InterruptableJob vmesnik. Na ta način lahko v metodi interrupt nastavimo zastavico, ki jo v dolgi iteraciji pregledujemo in ustrezno reagiramo - varno končamo s procesiranjem.

Edina konkurenca je Flux, ki pa je komercialni izdelek.

Po mojih izkušnjah je uporaba Quartz ogrodja enostavno in zelo olajša (in skrajša!) razvoj aplikacije s potrebami po časovnem razdeljevalniku.

Agilni projekti - fokus

Peta lastnost vredna upoštevanja, če želimo boljše rezultate, je vedenje posameznika kaj je njegova prioriteta in "nekaj" neprekinjenega časa na tej nalogi. Osebne izkušnje, predvsem iz drugega dela prejšnjega stavka, so dobre, iz česar lahko varno zaključim, da delam v urejenem projektnem ozračju.

Od časa do časa slišim od kolegov, da delajo na več projektnih hkrati. Iz tona njihovega pripovedovanja je jasno kako nezadovoljni so zaradi stalnega preklapljanja med konteksti. Posledica je jasna - počasno napredovanje v vseh projektih. Menedžment se prav gotovo zaveda teh posledic, a jim je hkrati jasno, da od dveh ali več projektov hkrati firma lažje preživi. Mogoče kvaliteta niti ni toliko pomembna, važno je da se posel dobi, naveže stranke in vzdrževalne pogodbe, z ustrezno motivacijo (beri denarno nagrado ali napredovanjem) pa bodo vodje projektov že ukrotile razvojne oddelke.

Vodja projektov mora za vsakega razvojnika ob vsakem trenutku vedeti kaj sta njegovi dve prioritetni nalogi. Narava razvojnih inženirjev je že taka, da zlahka skrene iz pragmatične poti do cilja na tako, ki je na dolgi rok optimalnejša, ker bo omogočala še to in ono, včasih nepotrebno funkcionalnost, zato je občasno (ali periodično) nadzorno oko zaželjeno in potrebno. Preprost listek na steni pred vsakim razvojnikom je ena izmed preprostih metod, lahko pa seveda uporabimo programe za projektno vodenje.

Fokus se zlahka razblini tudi zaradi telefonskih klicev, nenapovedanih sestankov, raznih koordinacij zaradi nikoli definiranih postopkov v firmi, dajanja pomoči (informacij) nekomu, itd. Narava prekinitev je taka, da imajo visoko prioriteto, zato je nesmiselno, da poskušamo odgovore na njih stlačiti v nek časovni okvir. Bolje je da se odločimo, za dve uri na dan, ko "nihče" ne sme motiti razvojnega procesa. Nihče je jasno v narekovaju, ker se idealu lahko samo približamo.

Motnje v okolju so odvisne v veliki meri tudi od kulture posameznika, kar pa je že druga zgodba.

Apache Maven

Za Maven sem prvič slišal pred slabim letom. Na njega sem naletel iz projekta Forrest, ki sem ga uporabljal za projektno dokumentacijsko intranetno spletno stran. Takrat je bil še v prvi inkarnaciji, to je v verziji 1.0. Nisem si vzel dovolj časa za evaluacijo, zato je bilo tedanje razumevanje tega ogrodja zelo površno. Pravzaprav sem ga nameraval uporabljati samo iz ene perspektive tj. kot pripomoček pri izdelavi projektne dokumentacije. Zdaj so za mano kaki trije meseci uporabe verzije 2.0, ki pa se kar v precejšnji meri razlikuje od prve.

Apache Maven je ogrodje za pomoč pri projektni organizaciji procesov (project management framework). Odprtokodni projekti so si med seboj zelo različni po zrelosti kode, konceptih in načinih izdaj verzij, nadgradenj in popravkov. Že na začetku moram omeniti, da so potrebni pri uporabi Maven ogrodja močni živci in zvrhana mera potrpežljivosti. Do izida knjige Better Builds with Maven je bilo prebijanje skozi razmetano dokumentacijo na uradni strani pravo doživetje in malo je manjkalo, da nisem vsega skupaj poslal k vragu. Vseeno sem imel občutek, da je za vsem skupaj nekaj dobrega. In po dosedaj videnem sem imel kar prav.

Maven je:

1. zbirka standardov
2. repozitorij programskih knjižnic
3. orodje za opis projektov
4. orodje za projektno organizacijo

Za najbolj pomembno vrednost sem spoznal dejstvo, da definira cikle za prevajanje kode, testiranje in nameščanje programskih artefaktov. Ker vedno več projektov uporablja Maven v procesu razvoja programske kode, je zaradi uporabljenih konvencij izredno zmanjšan uvodni čas pri spoznavanju projekta.

Z leti se izoblikujejo določeni vzorci in nekateri so prepoznani kot boljši. Če te vzamemo in združimo z deklarativnim pristopom opisa projekta, namesto da vsakič znova uporabljamo bolj ali manj spremenjene build skripte, potem lahko določene postopke poenostavimo.

Firma, če povzamem enega izmed avtorjev, lahko z uporabo Maven ogrodja pridobi na področjih:
Koherenca - To pomeni standardizacija na področju najboljših pristopov, ki so se izoblikovali.
Reuporaba - Ne izumljamo že videnega, ampak raje uporabimo kar se je izkazalo za dobro.
Agilnost - Razvojniki lažje prestopamo iz projekta na projekt, ker ni potrebnega uvodnega spoznavanja s sistemom.
Vzdrževanje - Razbremenitev ljudi, ki so prej pisali razne skripte, pogosto niti v okviru standardov firme (če sploh obstajajo).

Brez teh lastnosti že v skupini prihaja do velikih razlik med postopki razvoja. To ni nujno tako slabo, a nobena skupina ne vključuje posameznikov z istim znanjem, željami, voljo in še čim, da ne bi prihajalo vsaj do občasnih zastojev dela zaradi nedefiniranih postopkov. Ko v tako skupino pride nov član, je bolj ali manj odvisen od svoje iznajdljivosti, saj so postopki redko popisani.

Princip uporabe konvencij raje kot konfiguracij pomeni, da uporabljamo vnaprej dogovorjene vzorce in jih le po potrebi konfiguriramo. Eden izmed takih vzorcev je standardna direktorijska struktura. Kolikokrat ste se že znašli v situaciji, da ste premišljali kam bi šla kakšna datoteka? Verjetno večkrat kot je to potrebno, zraven pa še poželi negodovanje sodelavca, ki si je stvar zamislil malo drugače. Poznano? Naslednja stvar, ki je pomembna je višjenivojska organizacija kode v projektu ali drugače rečeno - princip ločevanja odgovornosti (Separation of Concerns). To pomeni več-modulski projekt. Še tretja stvar, ki jo bom omenil pa je standardno poimenovanje artefaktov, ki jih proizvajamo v procesu razvoja. To so na primer datoteke JAR.

Obsežna tema, zato verjetno sledi nadaljevanje.