Selenium - funkcionalni testi

Izvajanje funkcionalnih testov spletnih aplikacij, ki jih venomer nadgrajujemo z novimi storitvami mora biti izvedeno in avtomatizirano. S funkcionalnimi testi moramo pokriti vsaj osnovne dele spletne aplikacije, ki so kritični (core business) za naročnika.

Da ne bo zmede z izrazi - funkcionalni testi se drugače imenujejo tudi "acceptance" ali "black-box" testi in so komplementarni xUnit in integracijskim testom. Unit testi so pisani na nivoju metod in razredov, integracijski testi zajemajo testiranje med posameznimi moduli. Če spletna aplikacija ni napisana v duhu MVC, potem je unit teste za C del prejšnje kratice praktično nemogoče pisati. Če še ne znamo pisati raznih xUnit testov, lahko začnemo s funkcionalnimi.

Tudi če imamo v firmi QA oddelek, ljudi v njem nepotrebno obremenjujemo z izvajanjem testov, predvsem regresijskih, za katere velikokrat sploh zmanjka časa. Rutinske naloge dajmo izvajati stroju, ljudje naj delajo bolj kreativne naloge!

Selenium je eno izmed orodij, ki ga lahko uporabimo v te namene. Od sorodnih (opensource: HtmlUnit, Canoo, jWebUnit, Sahi, MaxQ, SAMIE, Watir, Mechanize; licenčni: WinRunner, Rational Robot, SilkTest, Test Partner, IBM Rational Functional Tester), se loči po - citiram:

"Selenium tests run directly in a browser, just as real users do. And they run in Internet Explorer, Mozilla, and Firefox on Windows, Linux, and Macintosh. No other test tool covers such a wide array of platforms."

Kako pa lahko testi tečejo v brskalniku? Zato, ker jih poganja JavaScript. Res huda ideja, le spomnit in realizirat jo je treba. Selenium deluje v treh načinih:

• Bot mode (Seleium Core)
  Testi se izvajajo direktno v brskalniku. Navodila (testi) morajo biti na strežniku, kjer teče spletna aplikacija.
• Driven mode (Selenium Remote Control)
  Teste lahko pišemo v: Java (JUnit, TestNG), C# (NUnit), Perl (Test::More), Python (unittest), Ruby (Test::Unit)
• Record mode (Selenium IDE)
  Ni samo record tool! Je IDE, ki med drugim omogoča pametno detekcijo elementov na spletni strani (ID, imena, XPath), autocomplete ukazov, breakpoints,...

Ni potrebno poudarjati, da se nam čas (=denar) investiran v pametno avtomatsko funkcionalno testiranje večkrat povrne.

IBLOC 2006

V Portorožu se je 2. in 3. oktobra dogajala Mednarodna poslovna linux in odprtokodna konferenca. Otvoril jo je g. Dušan Kričej iz Ministrstva za javno upravo. Žal je sedanja oblast Ministrstvo za informacijsko družbo (MID) novembra 2004 ukinilo in njene naloge razdelilo na druga ministrstva.

Konferenca je bila razdeljena na več sekcij:

• varnost,
• spletne tehnologije,
• tehnična sekcija,
• dobre prakse,
• vgrajeni sistemi in
• poslovna sekcija.

Sekcija "dobre prakse" je bila vpeljana letos in je pokrivala nekatere rešitve bazirane na odprti kodi. Te rešitve so bile komentirane oziroma predstavljene iz ust uporabnikov in ne njihovih avtorjev ali posrednikov, kar doprinese k večji objektivnosti. Resnici na ljubo objektivnost ne pride sama po sebi, jo je pa lahko prepoznati. Ali, še lažje je prepoznati njeno nasprotje.

Eno izmed meni najbolj zanimivih predavanj je bilo "Turbo Gears - o(g)rodje za agile razvoj spletnih aplikacij". Predstavitev je imel Simon Belak iz firme Hruška. Je eden izmed nosilcev razvoja, zato je bilo predavanje avtoritativno. Zelo pozitivno lahko ocenim njegov pristop pri predstavitvi, saj lahko, kot sem že ničkolikokrat videl in bral, protagonist izpade kot borec za najsvetejše ideale - to pa ustvarja negativno klimo med uporabniki različnih tehnologij. Hvala bogu g. Belak ni eden izmed takih, čeprav se je med slušatelji oglašal provokator.

Sicer pa so si bila predavanja po tematiki med seboj sila različna. Nekatera zelo tehnično zahtevna, druga pa bolj filozofska, in žal tudi ne preveč v duhu odprtokodne skupnosti. Vsekakor potrebujemo konference o odprtokodnih rešitvah, ki se ukvarjajo vse od poslovnih modelov za uvedbo in uporabo takih tehnologij v realnem življenju, pa vse do konkretnih rešitev v obliki delavnic in predstavitev konkretnih tehnologij. Sicer pa - vsak odprtokodni projekt je viden toliko, kolikor ima aktivno skupnost. Če se skupnost ne zaveda pomena dokumentacije, prezentacije ali celo marketinga, ostane tehnologija bolj marginalna, čeprav tehnološko dobra.

Skupnost je sestavljena iz posameznikov, vsak zase pa najbolj ve ali je iz pravega testa za odprtokodno miselnost.

JIRA

Zakaj je za firmo dobro, da shranjuje znanje? Kaj sploh to pomeni!?! Proces razvoja programske opreme gre skozi mnogo faz in katerikoli pristop že uporabljamo, vedno bo prihajalo do predlogov za izboljšave in še boj zagotovo bo prihajalo do napak pri implementaciji željene funkcionalnosti. Ni vseeno kako in ali sploh beležimo težave. Te težave in še bolj njihove rešitve so temelj znanja (beri znanje je denar). Ali obstaja način, da znanje nevede (bizarno!) razdelimo med svoje sodelavce ali zanamce. Če nam je kaj do tega, potem se pameten gospodar ne odloča prav dolgo.

JIRA je sistem za projektno vodenje, ki nam omogoča zelo premišljen postopek za evidentiranje programskih pomankljivosti, želj po novih funkcionalnosti, razdeljevanje nalog sodelujočim, pregled nad urnikom posameznikov in skupin. Lahko je podlaga za odločanje o razporeditvah delovnih nalog, posameznim vodjem omogoča razna poročila o zasedenosti posameznikov (na podlagi njihovih ocen!). Razvitih je bilo že ničkoliko vključkov, ki dopolnjujejo osnovno funkcionalnost te spletne aplikacije.

Obstaja mnogo projektov, ki omogočajo prijavljanje napak programske opreme, a se nobena od meni znanih ne približa intuitivnosti in hkrati tolikšni fleksibilnosti. Ker sem se pred leti tudi sam ukvarjal z razvojem tovrstne spletne aplikacije, toliko bolj spoštujem nastalo rešitev.

Več odprtokodnih projektov, ki so mi prekrižali pot (Cayenne, Quartz, Maven, Tapestry, HttpClient...) uporabljajo ta sistem in kot uporabnik na vseh teh se mi zdi, da ima primat z razlogom. Še bolj pa me je prepričal, ko sem ga pogledal v drobovje iz administratorske strani. Sistem lahko namestimo in ga brezplačno uporabljamo mesec dni.

Če poskušam odgovoriti na svoje v uvodu zastavljeno vprašanje kako shranjevati znanje - preprosto, organizirano zbirajmo vsakodnevne težave in jih rešujmo eno za drugo, a pri tem pustimo za sabo sled! Ta sled je referenca, je točka na katero se lahko vrnemo in iz nekaj preprostih stavkov razberemo rešitev. Je referenca, ki nas lahko opomni, da gre osel lahko večkrat na led. Že pomanjkanje komunikacije med sodelujočimi na istem projektu je težava, kaj šele pomeni to za dolgoročne projekte z nestalnimi sodelujočimi.

Commons Configuration

V enem izmed prejšnjih zapisov sem omenil, da lahko z malo raziskovanja odkrijemo že izdelane rešitve, ker je skoraj zagotovo že nekdo pred nami potreboval in rešil kakšen problem, ki nas tare.

Commons Configuration (CC) je programska knjižnica, ki nam olajša dostop do resursov, ki jih potrebuje aplikacija. Za osnovne potrebe nam Java ponuja razred Properties, včasih pa bi potrebovali kaj več. Recimo, da aplikacija iz nekih razlogov potrebuje štiri konfiguracijske datoteke ali še bolje - vire. Ali ne bi bilo fino, da lahko do vseh štirih dostopate na enoten način - prek enotnega mehanizma? Recimo, da potrebujete nek vrstni red ali hierarhijo konfiguracijskih vrednosti. Kaj pa nekaj tako naravnega kot je pisanje nazaj v navadno properties datoteko, ampak tako, da se ohrani vrstni red zapisov in komentarjev ter vmesne prazne vrstice? Včasih bi si človek zaželel, da lahko dostopa do konfiguracijskih vrednosti neodvisno od formata in fizične lokacije. To in še več je možno s Commons Configuration.

CC nam ponuje enoten vmesnik za dostop do vrednosti iz sledečih virov:

• Property datotek
• XML dokumentov
• Property list datotek (.plist)
• JNDI
• JDBC Datasource
• System properties
• Applet parametrov
• Servlet parametrov

Naša naloga je, da ob zagonu aplikacije inicializiramo konfiguracijski sistem in ga damo na volju posameznim aplikacijskim sklopom. To običajno pomeni, da mora biti na voljo objekt tipa Configuration. Z aplikacijo se osredotočimo na reševanje zadanega poslovnega problema in se ne ubadamo s podrobnostmi ali načrtovanjem lastnih rešitev znotraj firme, kar običajno ni poceni.

Iz lastne izkušnje lahko tudi povem, da je avtor te odprtokodne knjižnice dojemljiv za predloge in izboljšave in kot vedno - na voljo imamo izvorno kodo, tako da jo lahko tudi sami prikrojimo, če nam kaj ne ustreza.

Agilni projekti - lahek dostop do izkušenih uporabnikov

Najprej bi omenil razliko med domenskimi strokovnjaki (business experts) in izkušenimi uporabniki (expert users). Ni nujno, da sta to različni osebi, je pa v praksi to večkrat res.

Po domače povedano bi rekel, da domenski strokovnjaki obvladajo teorijo, izkušeni uporabniki pa poznajo vsakdanje operacije v delovnih postopkih. Prvi imajo pregled nad poslovnimi strategijami, drugi pa vedo katere informacije so v določenem trenutku pomembne za izvedbo konkretnega postopka.

Kaj pridobimo z lahkim dostopom do slednjih?

• Ljudi, ki jim lahko dajemo vmesne produkte v testiranje.
• Hiter odziv o kvaliteti produkta.
• Razvojna ekipa pridobi odzive na uporabljene prijeme pri načrtovanju aplikacije.
• Pridobimo ažurne podatke o funkcionalnih zahtevah

Raziskave (Kiel, Carmel) so pokazale veliko večji uspeh pri projektih, ki so imeli neposredno povezavo med razvojno ekipo in izkušenimi uporabniki sistema, ki ga želimo informatizirati ali izboljšati procese. Razlika se pokaže že pri tedenski frekvenci komunikacije. V odvisnosti od faze projekta je seveda odvisna tudi komunikacija. Ob začetku sta dva sestanka tedensko in dostop prek telefona ali druge elektronske komunikacije običajna.

Pri pomembnih projektih naročnik tudi "posodi" take uporabnike razvojnim ekipam ali pa obratno, nekdo iz razvojne ekipe se začasno "zaposli" pri naročniku in tako pridobi neprecenljive informacije procesov, ki jih želimo informatizirati. V slednjem primeru se tudi ublaži razlika med običajno dvema različnima svetovoma programerjev in uporabniki njihovih izdelkov - lahko se okrepi spoštovanje do drugega dela in zadovoljstvo ob rešitvi.

XML členitelji

Med tri-črkovnimi kraticami je verjetno med bolj znanimi v programerskih vodah - XML (Extensible Markup Language). Ima burno zgodovino in mislim, da se prah okoli te kratice le polagoma poseda. Koliko zvenečih besed je bilo izrečenih in nekaj prav gotovo utemeljeno. No, izkazalo se je, da XML le ni naš odrešitelj, je "le" zelo uporabno orodje, če ga lahko tako kličem. Ker se ta blog ukvarja predvsem z jezikom Java, bom danes poskusil razdelati XML členilnike (XML parsers) po več kriterijih.

Slika po znanem reku pove več kot 1000 besed, zato bom pokomentiral posamezne standarde oziroma značilnosti le-teh.

Najbolj groba delitev je na drevesni objektni model (Document Object Model) in na pretočne (streaming) členitelje. Za odločitev katero družino uporabiti je odločina velikost dokumentov, ki jih nameravamo obdelovati. Najbolje je, da na pričakovanih realnih primerih izmerimo porabo pomnilnika in procesorskega časa, velja pa ocena, da za dokumente velikostnega razreda nekaj 10 MB ni več optimalna uporaba DOM členiteljev. Seveda je brezpredmetno tudi za Java ME. Če si vseeno lahko privoščimo uporabo DOM Java APi-jev, pa so nekatere rešitve precej elegantne, kot na primer uporaba XPath jezika za poizvedbe po drevesnem objektnem modelu.

Priporočam JDOM, ki je zelo "očiščen" Java API za manipulacijo z XML DOM drevesom. Očiščen pravim zato, ker je DOM W3C-jev standard in členitelji, ki temeljijo na njem morajo upoštevati razne obskurnosti, ki so v specifikaciji zaradi pokrivanja splošnosti med programskimi jeziki.

Naslednja velika delitev je med pretočnimi izvedenkami. Povlečni (pull) in potisni (push) način. Bolj znan je SAX, ki je starejši, a ga začetniki vseeno neradi uporabljajo zaradi kompliciranosti. Sam API je dokaj enostaven, vendar je uporaba v aplikacijah nepotrebno komplicirana. Ima pa zelo dobro lastnost - hitrost. Zaradi zelo majhnega števila objektov, ki se morajo kreirati med členjenjem, je tudi poraba sistemskih virov majhna. Razne skupine so kmalu ugotovile pomanjkljivosti potisnega načina, kot je na primer dejstvo, da členitelj kliče našo aplikacijo in ne obratno, kot se to počne pri potisnih izvedenkah. Iz tega so nastali XPP serija in nazadnje (oktober 2003) tudi StAX standard.

Razlika je v tem, da SAX členitelj prebere XML dokument in nato kliče metode v naši aplikaciji, povlečne členitelje pa kontroliramo iz aplikacije, torej mi povemo členitelju kdaj naj procesira. Imamo torej kontrolo nad aplikacijsko nitjo.

Bistvene prednosti povlečnih pred potisnim SAX so:

• Členjenje preprostih XML dokumentov lahko izvedemo s preprosto kodo.
• Lažje je napisati kodo za rekurzivno členjenje.
• Če med členjenjem enega dokumenta ugotovimo, da potrebujemo informacije iz drugega, lahko to storimo v isti niti.
• Lahko preskakujemo dele XML dokumenta, ki nas ne zanimajo in tako prihranimo čas in procesorsko moč.
• Lahko ustvarimo pretočne cevovode (streaming pipelines).

Iz slike je razvidna še ena delitev in sicer na take povlečne, ki uporabljajo iteratorje, kurzorje in take, ki se obnašajo mešano (kreiranje dogodkovnih objektov med členjenjem lahko preprečimo s ponovno uporabo starih). Pri StAX standardu, ki bo mimogrede vključen v Java 6 (Mustang), so se odločili za izvedbo dveh API-jev, enega, ki uporablja iteratorje in drugega, ki uporablja kurzorje. Iz tega razloga imamo možnost izbire glede na kontekst aplikacije, ki jo razvijamo. Odločimo se glede na:

• Če razvijamo Java ME aplikacijo, uporabimo kurzor API.
• Če želimo imeti brezkompromisno hitrost procesiranja, uporabimo kurzor API.
• Če želimo spreminjati dogodkovni tok, uporabimo iterator API.
• Če delamo ekstenzibilne module, uporabimo iterator API.
• Če smo v dvomih, uporabimo iterator API.

Priporočam StAX, ki ga lahko uporabimo tudi za kreiranje XML dokumentov (bolj intuitivno pa to počnemo z JDOM).

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.

Apache Ant

Apache Ant je orodje za avtomatizacijo build procesov. Napisano je v jeziku Java in je tudi primarno namenjen temu jeziku. Proces opišemo v XML dialektu, kar skupaj s prej omenjenim pomeni, da je Ant prenosljivo orodje - lahko ga poganjamo v Windows in Unix sistemih. No, samo po sebi to še ni dovolj, Ant mora namreč vsebovati potrebno funkcionalnost, da zna na primer izvesti ukaz copy transparentno ne glede na spodaj "ležeči" operacijski sistem. To pomeni, da zna ustrezno pretvarjati ali pripraviti datotečne poti, ki se na Windows in Unix sistemih razlikujejo. To je samo preprost primer prenosljivosti.

Ant je nastal, ko je Sun dal svoj interni projekt v odprtokodno skupnost za nadaljni razvoj. Ta projekt se danes imenuje Apache Tomcat. Ker v odprtokodni skupnosti ljudje uporabljamo veliko različnih kombinacij strojne in programske opreme, je nastala potreba po build orodju. Tako se je rodil Ant, ki je kot samostojeni projekt izšel poleti leta 2000. Do današnjih dni je pridobil ogromno privržencev, pravzaprav je postal de-facto standard za Java aplikacije.

Ant izvršuje naloge na podlagi napisanih opravil (tasks). Tu lahko najdete spisek, ki je razdeljen po temah. Opravila pa lahko napišemo tudi sami, če ne najdemo ustreznega. Vsekakor je za majhne in srednje velike projekte Ant primerno orodje. Nanj lahko gledamo tudi kot del standardizacije delovnega okolja razvijalcev v podjetju. Seveda lahko za build sistem uporabljamo tudi IDE okolja, v katerem razvijamo, vendar je potem potrebna konsolidacija vseh vpletenih - vsi razvojniki pač ne uporabljajo iste IDE aplikacije, če v podjetju (ali skupnosti) za nepokorščino ni zagrožena smrtna kazen. Malo šale. Nekateri IDE proizvajalci so se zavedli tega problema in vgrajujejo Ant podporo kot paralelni build način.

Omeniti je potrebno tudi negativne lastnosti. Večji kot postaja projekt, teže je obvladovati špagete XML Ant skript. Build procesna navodila v XML obliki enostavno presežejo prag zmožnosti vzdrževanja. Obvladovanje napak ni izvedeno najbolje, npr. nedefinirane spremenljivke niso vzrok za napako, ampak se tiho nadomestijo z neko pred-definirano vrednostjo.

Sicer pa, najbolje da si preberete komentar avtorja samega, ki je objavljen v knjigi Pragmatic Project Automation in ga objavljam tu v celoti.

"The Creator of Ant Exorcizes One of His Demons" by James Duncan Davidson.

The first version of Ant didn t have all the angle brackets that you see sprinkled all over its build files. Instead, it used a properties file and the java.util.Properties class to define what tasks should be executed for a target. This worked really well for small projects but started breaking down rapidly as projects grew.

The reason it broke down was the way that Ant views the world: A project is a collection of targets. A target is a collection of tasks. Each task has a set of properties. This is obviously a hierarchical tree. However, property files give you only a flat name=key mapping, which doesn t fit this tree structure at all.

I wanted a hierarchical file format that would capture the way that Ant viewed the world. But I didn't want to create my own format. I wanted to use a standard one and more important I didn't want to create a full parser for my own custom format. I wanted to reuse somebody else's work. I wanted to take the easiest way possible.

At the time, XML was just breaking out onto the radar. The spec had been completed, but only recently. SAX had become a de-facto standard, but we didn't yet have JAXP. I was convinced that XML was going to be the next big thing after Java. Portable code and portable data. Two buzzphrases that go well together.

Even better, since XML viewed data as a tree structure, it seemed like a perfect fit for the kinds of things that needed to be expressed in a build file. Add in that XML was still a hand-editable text-based format, and it seemed like a marriage made in heaven. And, I didn't have to write a parser. The deal was done.

In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long, and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped. As well, when you mix XML and the interesting reflection-based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment that gives you quite a bit of the power and flexibility of a scripting language but with a whole lot of headache in trying to express that flexibility with angle brackets.

Now, I never intended for the file format to become a scripting language. After all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70 80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.

If I knew then what I know now, I would have tried using a real scripting language, such as JavaScript via the Rhino component or Python via JPython, with bindings to Java objects that implemented the functionality expressed in today s tasks. Then, there would be a first-class way to express logic, and we wouldn't be stuck with XML as a format that is too bulky for the way that people really want to use the tool.

Agilni projekti - osebna varnost

Osebna varnost pomeni zmožnost izražanja svojih pogledov brez strahu pred kakršnimikoli povračilnimi ukrepi.

Projektno delo v skupini običajno živi v hierarhičnem okolju sodelavcev, vodij skupin, menedžerjev, naročnikov, strank in še koga. Varnost pomeni, da smo sposobni v oči povedati menedžerju, da je njegov rok za predviden dan izida daleč preoptimističen.

Pomeni to, da smo sposobni povedati sodelavcu, da nas moti njegova smrdljiva srajca. Pomeni to, da lahko sodelavcu brez strahu povemo, da njegov načrt ali izvedba nista za nikamor. Brez takih odprtih pogovorov škodujemo celotni ekipi.

Ali ste že imeli sodelavca ali sodelavko, ki pri jedi sendviča tako cmoka, da ga (jo) je slišati v sosednji volilni okraj? Pa ste mu (ji) kaj rekli? Ali se je sploh vredno za nekaj minut trpljenja dnevno izpostavljati in potem poslušati ego obrambne protinapade? Kakor kdo, kakor kje, kakor za kaj. Bolj moteči so hrup ali celo konstantno tresenje mize, ker ima sodelavec "v riti mravljince". Verjetno ima vsakdo od vas še bolj pikantne primere!

Osebna varnost je pot do izgradnje timskega zaupanja. Zaupanje pomeni, da nekomu damo moč nad nami in pri tem tvegamo, da nas rani. Nekateri smo po naravi bolj odprti kot drugi, ravno tako kot nekateri gledamo na svet bolj optimistično kot drugi. Nezaupanje v delovni skupni povzroča celo vrsto negativnih posledic - prikrivanje ali celo laganje, slabše opravljeno delo zaradi pomanjkanja informacij, izdajanje poslovnih informacij in še kaj. Za povečanje zaupanja se moramo odpreti, to pomeni priznavati svoje šibkosti, a pri tem vedeti, da nam drugi zaradi tega ne bodo škodovali. Priznanje, da česa ne znamo, da smo kaj naredili narobe, ali da česa ne bomo zmogli je pogoj. Takoj za tem pa mora biti na voljo pomoč ostalih v skupini - neavtoritativna in dobrovoljna!

Živali se ob nesporazumih pogrizejo. Koliko krvavi končujemo izmenjavo mnenj, je tudi stopnja zrelosti posameznikov v skupini. Mogoče sam boj ni tako sporen, kot pa njegov zaključek. Bolj pomemben se mi zdi zaključek - ali lahko končamo vedro, prijateljsko, inteligentno!

Ali ste imeli kdaj sodelavca, ki ni poslušal, ali če rečem, ni poslušal v dobri volji? Tak človek je "natural party braker".

Druga plat komunikacije pa je prevelika vljudnost - kar z vsem se strinjamo, samo da ne bi "škodili" sogovorniku. Zombi ekipa.

Jakarta Commons

Računalništvo in njena poddomena - programiranje - je, sedaj že lahko rečemo, zrela veda. Z leti se izoblikujejo določeni vzorci. Načrtovalski vzorci so rešitev nekega ponavljajočega problema pri razvoju programske opreme. Takega vzorca ne moremo direktno prenesti v kodo, lahko rečemo celo, da so agnostični na programski jezik. Dve knjigi, ki jih imam na spisku na temo objektno orientiranih vzorcev sta: Design Patterns Explained: A New Perspective on Object-Oriented Design in Head First Design Patterns.

Če problem še nadalje drobimo, pridemo do faze realizacije, ko moramo za določen podproblem napisati kodo. Ker si hočemo prihraniti čas, je najbolje, da si pogledamo, če je kdo pred nami že rešil naš problem in nam tudi dovoli uporabiti znanje, ki je običajno v obliki programskih knjižnic ali ogrodij. Najbolj znano "zatočišče" za programerje v jeziku Java je jakarta commons.

Cilj odprokodnega projekta jakarta commons je pod eno streho združiti Java komponente, ki so na voljo pod Apache 2.0 licenco. Namen je združitev znanja in preprečevanje redundantnega dela. Komponente so narejene tako, da so minimalno odvisne od drugih zaradi lažjega nameščanja. Sledi se tudi stabilnosti programskih vmesnikov (API), tako da so nadgradnje manj boleče.

Prej omenjene komponente so jar datoteke, ki jih samo damo na razpolago Java virtualnemu stroju, ki pa imajo priložene tudi izvorne datoteke, dokumentacijo in običajno Ant build skript. To pomeni, da lahko sami po potrebi kakšno funkcionalnost tudi dodamo, če jo potrebujemo. Kar je še bolje, v projekt lahko tudi prispevamo naše znanje in tako drugim olajšamo razvoj.

Po funkcionalnosti se med seboj zelo razlikujejo saj pokrivajo zelo široko problemsko področje. 32 komponent je produkcijske kvalitete in še nadaljnih 10 je v tako imenovanem peskovniku. Naj jih nekaj omenim samo na kratko - mogoče jih bom podrobneje predstavil vsako posebej v prihodnjih zapisih v tem blogu.

Collections Nadgradi funkcionalnost java.util.Collection.
Configuration Splošen dostop do konfiguracijskih virov.
DBCP DataBase Connection Pool
HttpClient Nadgradi java.net z veliko nove funkcionalnosti.
Lang Veliko uporabnih metod, nekakšna splošna razširitev jezika.

Gotovo se splača pregledati metode posameznega API-ja, saj nam uporaba že izdelanih rešitev skrajša število vrstic naše kode, vsi pa vemo, da to pomeni manjšo možnost napake in lažje vzdrževanje produkta. Še kako pomebno je, da bo nekomu za
nami, ki bo moral vzrževati kodo, znan uporabljen API, ki ga je mogoče že uporabljal na prejšnji firmi. V težavah se vedno lahko zatečemo na liste za razvojnike ali uporabnike, kjer nam uporabniki ali avtorji posamezne komponente odgovorijo na naše vprašanje. V veliki skupnosti zagotovo lažje rešimo problem.

Subversion

Subversion je odprtokodni sistem za upravljanje z revizijami dokumentov - največkrat izvorne kode. Je neke vrste naravni naslednik že precej osivelega CVS (Concurrent Versioning System) sistema, ki še vedno obvladuje večji del trga, a z vsakim mesecem izgublja boj proti bolj napredenemu bratu.

Razvoj programske opreme zahteva navadno skupino ljudi, ki bolj ali manj paralelno razvija nek produkt. Kako torej poteka razvojni cikel? Idealno je, da imamo zelo dobro definirano datotečno strukturo za posamezen tip projekta. O tem bom več govoril v enem izmed neslednjih člankov.

Začetno ogrodje za projekt uvozimo v repozitorij, do katerega imajo dostop vsi udeleženi. Vsak posameznik si na svoj delovni računalnik prenese projekt iz repozitorija in prične z dodajanjem novih datotek ali spreminjanjem že obstoječih. Kmalu se pojavi potreba po več razvojnih vejah. Eden izmed razlogov je razvoj nove verzije produkta. Ker ne želimo z novo verzijo pokvariti tekočega konja naše firme, ki ga nameravamo vzdrževati zaradi strank še kar nekaj časa, moramo pričeti z razvojem novejše verzije na tak način, da kljub skupni bazi ne pokvarimo stabilne kode. Drug razlog je razvojne narave. Nekdo v ekipi želi testirati nov algoritem in to lahko počne na svoji razvojni veji, ki se kasneje ali uporabi ali pa zavrže.

Konfliktne situacije, ki nastanejo zaradi sprememb v isti datoteki rešujemo najlaže s podporo kakšnega namenskega grafičnega primerjalnega orodja, ki je navadno kar del razvojnega okolja v katerem razvijamo. Z utečenostjo ekipe in dobrim projektnim vodenjem so te "težave" obvladljive.

V čem so prednosti sistema Subversion pred CVS?

• Atomarni vnosi v repozitorij - prekinjen vnos (commit) ne povzroči nekonsistentnega stanja.

• Preimenovane, kopirane ali odstranjene datoteke ohranijo informacijo o verziji.

• Nativna podpora za binarne datoteke in prostorsko učinkovit algoritem shranjevanja za binarno primerjavo.

• Imeniki imajo verzije. Celotna poddrevesa se lahko premikajo po repozitoriju in pri tem še vedno ohranijo informacijo o verziji.

• Čas za izdelavo vej in označevanje (tagging) je konstanten.

• Optimiziran dostop do repozitorija zmanjšuje mrežni promet.

S CVS sistemom sem prvič srečal leta 2001 in ga uporabljam za posamezne projekte še danes. Pred časom pa sem začel spoznavati zgoraj naštete prednosti na lastni koži. Kar se zgoraj bere kot suhoparna alineja, se v praksi izkaže kot neprecenljiva lastnost. Če izpostavim samo eno - pri CVS sistemu je še toliko bolj pomembna dobra začetna zasnova direktorijske strukture projekta, saj je prestavljanje imenikov ali vej prava muka, ki zahteva ročne posege v drobovje repozitorija.

S prakso, znanjem in dobrimi delovnimi navadami je uporaba sistema za kontrolo verzij pravi blagoslov. Priporočam uporabo tudi za solo projekte.

Agilni projekti - osmotska komunikacija

Razporeditev prostorov in delovnih mest lahko pomembno vpliva na potek projektov, ki se izvajajo v hiši. V večji meri zaposleni nimajo vpliva na razporeditev po svoji izbiri, zato je toliko bolj pomembno koliko se komunikacije med programerji, o tej "podvrsti" govorimo tu, zavedajo odgovorni. Neprimerni prostori že sami po sebi slabo vplivajo na storilnost, nedostopnost informacij pa zadevo še poslabša.

Izraz osmotska komunikacija izhaja iz biologije, a ga lahko prenesemo v bolj abstraktne koncepte. Pomeni tok informacij v ozadju, ki ga nezavedno filtrirajo člani skupine na ožjem delovnem območju. To običajno pomeni skupino ljudi v istem prostoru. Ob zastavljenem vprašanju se lahko posamezniki vključijo v diskusijo ali pa tudi ne, po lastni presoji. Največkrat osmotska komunikacija niti ne pomeni diskusije, ampak samo kratek stavek, ki bodisi odgovori na vprašanje ali pa popravi kaj že izrečenega, morda izrazi pomislek ali nestrinjanje. Z zdravo mero pameti tako dosežemo hitre in spontane odgovore na vprašanja, ki ne motijo delovnega procesa posameznika. Za posamezne faze projekta je lahko take vrste komunikacija povsem dovolj in lahko celo prepreči kakšen dolgočasen sestanek. Za majhne projekte je tovrstno komuniciranje lahko celo večinsko, običajni sestanki pa bolj redki. Že sama fizična oddaljenost običajno preprečuje zastavljanje vprašanj izkušenejšim na določenem področju. Sam zelo pogosto uporabljam poštne liste za razvojnike odprtokodnih projektov za iskanje odgovorov ali tehnik, to pa zahteva čas, predvsem takrat, če odgovora še ni na voljo na listi. V takem primeru moramo računati na dobro voljo nekoga z ustreznim znanjem, da nam odgovori na običajno zelo specifično vprašanje. Veliko pogostih vprašanj je na takih listah že odgovorjenih ali zbranih v FAQ datotekah za lažji dostop. Če sedimo v manjši skupini, po možnosti še z možnostjo hitrega pogleda na sosednji monitor z ustrezno informacijo, dobimo odgovore v rangu sekund, mogoče minut, kar je bistveno pri hitrem razvoju.

Najverjetneje se bo uveljavila tudi video konferenčna zveza med udeleženci, a bo to zahtevalo prilagajanje mediju in bo težko nademestilo osebni kontakt, papir in svinčnik. Obstajajo urejevalniki programske kode (in seveda besedil), ki dopuščajo hkratno urejanje istega modula, če na primer potrebujemo nasvet kako sprogramirati določen odsek kode. Tako ni potrebno združevanje prek sistemov za upravljanje z izvorno kodo (CVS, Subversion, SorceSafe, ...), če nam to ustreza. Vse je seveda odvisno od urejenosti delovnih procesov in nenazadnje tudi od navdušenosti posameznikov za napredne in ne vedno tudi koristne pripomočke.

Razporeditev pisarniškega pohištva v prvi meri vpliva na osebni prostor posameznika, neposredno s tem pa na odnose med sodelavci. V odvisnosti od narave dela so se izoblikovale tipične konfiguracije miz, predelnih sten in samih pisarniških sob. Vsakemu posamezniku seveda ustreza nekaj česar drugemu ne. Nekoga moti, da mu drugi lahko gledajo v monitor vsak trenutek, drugega (beri mene) moti, če nekdo konstantno trese mizo, spet tretjega ne moti, da mora vsakič vstati, če hoče pogledati sogovorca in tako naprej. Fino je, da obstaja prostor kamor lahko na trenutke "zaidemo", da prekinemo rutino ali da se umaknemo iz skupine. Najbolje je, da obstaja na firmi neformalna soba za sestanke. To je nekakšna večnamenska soba kjer poleg običajnih sestankov lahko naključno s kakšnim kolegom (ki ne kadi :-)) mimogrede izmenjamo kakšno idejo. Kajenje sem omenil z razlogom. Kot bivši kadilec lahko z gotovostjo rečem, da se je v vseh čik pavzah povedalo poleg nujnih govoric tudi precej, če ne večino, s službo povezanih zadev. Ne gre pa pretiravati s temi pavzami - slej ko prej postaneš aktualna tema udeležencev ne-čik pavz.

Slaba lastnost osmotske komunikacije je ta, da generira veliko šuma in da običajno predstavlja breme za vodilnega razvojnika, ki največkrat odgovarja na vprašanja. Veliko komunikacije pomeni za nekoga motenje svojega dela in tako postane manj storilen ali pa sploh ne dosega svojega potenciala. Vodilni razvojnik(i) običajno najdejo svojo rezino miru po običajnih delovnih urah ali čez vikend. Boljše, čeprav nenaravno, je doseči dogovor o tihi uri ali dveh. Nazadnje se vse konča pri posamezniku in njegovem značaju, o čemer pa bom pisal v nadaljevanju člankov o agilnih projektih.

Cayenne

Vsi vemo, da je zadan problem rešljiv na veliko načinov. Ena izmed možnih poti pri izdelavi dinamične spletne aplikacije je tudi uporaba ORM (Object Relational Mapping) ogrodij. To je programska tehnika, ki podatkovno bazo predstavi kot objektno strukturo.

Zakaj bi si sploh želeli imeti podateke zapisane v bazi v aplikaciji predstavljene kot graf objektov? Odgovor je zelo podoben tistemu, zaradi katerega je veliko programerjev opustilo proceduralne programerske tehnike in jezike ter osvojilo koncepte objektnega programiranja. Ljudje lažje razmišljamo o objektih, njihovih lastnostih in povezavami med njimi, kot pa o tabelah in vrsticah podatkovne baze (po lastnih izkušnjah velikokrat nenormaliziranih).

Uporaba relacijske baze za shranjevanje objektno orientiranih podatkov vodi v semantični prepad - programerji moramo(jo) programsko rešitev snovati tako, da mešajo dva pristopa. S podatki operiramo na objekten način, shranjujemo pa jih relacijsko. Združevanje tehnik na tak način pomeni zadajanje omejitev enega na drugega in obratno. Prihaja do tako imenovane impedančne nezdružljivosti. SQL podatkovne baze so sestavljene iz niza tabel, ki vsebujejo elementarne podatke. Posamezen zapis v taki bazi se običajno razteza čez več tabel, ki jih moramo za aplikativne potrebe pred tem združiti. S tem hočem povedati, da moramo pri pisanju poizvedbe navesti tudi relacije med njimi.

Uporaba SQL stavkov bo vedno hitrejša rešitev, ob predpostavki da je to v celotnem kontekstu problema najbolj kritičen člen. ORM rešitve podatke na veliko shranjujejo v medpomnilniku, kar je resnično velikega pomena za visoko zmogljiv sistem.

To je bilo nekaj malega v splošnem, zdaj pa še o Cayenne. Ogrodje se zgleduje po EOF (Enterprise Objects Framework), ki velja za enega izmed najboljših. Tabele in vrstice so v pomnilniku predstavljeni kot graf objektov. Nad tem grafom objektov izvajamo čisto običajne operacije kot bi delali z javanskimi zrni. Cayenne spremlja kaj počnemo s posameznimi objekti in relacijami med njimi in ko je čas za zapis v bazo, ogrodje samo izgradi optimizirane SQL stavke. Podatkovne baze različnih proizvajalcev lahko združimo v enoten podatkovni vir do katerega dostopamo prek enega vmesnika. To pomeni, da imamo lahko več dislociranih podatkovnih baz, ki v navezavi z naprednim (Cross-VM Cache Sharing) mehanizmom omogoča skalabilne aplikacije.

Običajno najprej popišemo problem, ki ga želimo aplikativno rešiti. V tem procesu spoznamo naravo podatkov in relacije med njimi. Entitetni model lahko prenesemo v Cayenne Modeler, ki je vizualno modelirno orodje. Z njim lahko tudi preberemo že obstoječo podatkovno shemo in iz nje tvorimo javanske razrede, lahko pa iz modela naredimo shemo - imamo skratka dvosmerno povezano operacijo. S tem orodjem se posredno izdelajo vse konfiguracijske datoteke, ki jih potrebuje naša (spletna) aplikacija. Cayenne je agnostičen na prezentacijski nivo. Java razredi se avtomatsko zgenerirajo "v paru", vedno se naredi še podrazred, v katerega mi dodajamo poslovno logiko. Na ta način lahko Cayenne Modeler ob spremembi (npr. dodan ali spremenjen atribut tabele) prepiše "očeta", ne pa tudi naše dodatne logike. Ne potrebujemo razmišljati, če tega eksplicitno ne želimo, o primarnih ključih, ker to ni v OO (Object Oriented) semantiki. Ker so vsi podatki o preslikavah v posebnih konfiguracijskih datotekah, ki jih izdela prej omenjeni Modeler, je v samih razredih lahko samo čista poslovna logika, kar je lep način ločitve odgovornosti.

Iz svojih izkušenj lahko povem, da je arhitektura aplikacije in koda veliko lepša, če si lahko privoščimo toliko svobode pri načrtovanju.

Eclipse

Eclipse kot razvojno okolje sem začel uporabljati pred slabimi dvemi leti. V tem času sem spoznal, da za tem imenom stoji več kot samo okolje za razvoj aplikacij.

Eclipse je skupnost - odprtokodna skupnost, v kateri se "kuhajo" raznolika orodja za izdelavo aplikacij. Deluje kot povezovalno ogrodje. Deluje na Windows, Linux, Mac OS X, Solaris, AIX, HP-UX in QNX sistemih.

Nastajati je začel novembra 2001 s povezovanjem velikih podjetij kot so Borland, IBM, Red Hat, SuSE, Rational Software. Trenutno je v konzorciju že več kot 100 podjetij, ki razvija v Eclipse skupnosti devet večjih in preko petdeset manjših odprtokodnih projektov. Če naštejem omenjenih devet:

The Eclipse Top-Level Project
razvojno okolje za orodja in aplikacije

The Eclipse Tools Project
skrbi za medsebojno povezovanje in združljivost orodij

The Eclipse Web Tools Platform Project
platforma za razvoj spletnih aplikacij

Test & Performace Tools Platform
platforma na kateri razvijalci razvijajo testna in performančna orodja

The Business Inteligence and Reporting Tools Project
orodja za poročanja iz aplikacij

The Eclipse Data Tools Platform Project
orodja za podatkovno orientirane tehnologije

Device Software Development Platform
orodja za razvoj aplikacij namenjenih za različne naprave

The Eclipse SOA Tools Platform Project
okolje in orodja za SOA (Service Oriented Architecture) aplikacije

The Eclipse Technology Project
inkubator za nove tehnologije

V bližnji prihodnosti (junij 2006) se nam obeta izid kar desetih Eclipse projektov pod skupnim imenom Callisto.

Pri delu uporabljam intenzivno samo prvega, to je Eclipse IDE z raznimi dodatki (plug-ins). Za razvoj Java frontend aplikacij uporabljam MyEclipse in Spindle, za backend in samostojne aplikacije v Java jeziku pa so nepogrešljivi XMLSpy, RMI compiler, Subversion, UML, Log4E, LogWatcher in pa zadnje čase tudi JProfiler in Maven. Urejevalnik izvorne kode za Java jezik ima odlično podporo za refaktoring, ki prihrani čas in živce pri razvoju programske opreme.

Dodatki za Eclipse se najdejo na Eclipse plugins in na Eclipse plugin central.

Agilni projekti - reflektivne izboljšave

Ob branju prosto dostopnega poglavja knjige A Human-Powered Methodology for Small Teams, ki govori o lastnostih, ki naj bi jih imel projekt, da izpolni pogoje agilnosti, je drugi lastnosti ime - reflektivne izboljšave.

Od vseh sedmih, ki jih poglavje opisuje je ta po mojih izkušnjah najmanj problematična, saj še nisem sodeloval v projektu, kjer se ne bi sodelujoči občasno (tedensko ali dvo-tedensko) usedli skupaj in predebatirali probleme in morebitne rešitve.

Avtor to lastnost začne opisovati s presenečenjem, ki ga je doživel ob nekem projektu.

Skupina se je sestala po 4 mesecih dela in ugotovila, da so daleč za rokom izdelave, arhitekturna zasnova pa slaba. Ni treba posebej poudarjati, da je bila skupina demoralizirana. Vodstvo je odpustilo 23 od 24. razvijalcev in najela 23 novih. Reorganizirali so skupine in vodstvene ljudi, plačali nekajtedenska izobraževanja in začeli znova od začetka.

Po njihovi četrti iteraciji (o iteracijah pišem tu) je bil dizajn izdelan, že izdelana koda pa je prehitevala projektno časovnico. Avtor pravi, da je večina projektov pri katerih je bil zraven imela težke porodne krče. S sestajanjem se pridobi veliko novih informacij o projektu in okolju v katerem živi. Te informacije so podlaga za odločitve o morebitnih spremembah pri izboru orodij in tehnologij.

Nič posebnega. Metode za doseganje zadanih ciljev so ali pa niso primerne za določeno skupino. Omenja tipične pristope ektremnega programiranja: programiranja v parih, unit testing, test-driven development, pa malo manj znano - delo v samostojni pisarni napram delu v sobi z veliko ljudmi.

Sam večino časa delam na razvojno naravnanih projektih, zato je izmenjava idej in preizkušanje del vsakdanjika. Reflektivne izboljšave so najbrž samo lepo ime za običajne delovne sestanke.

Tapestry

Naj za hiter uvod nakažem kaj je stvar iz naslova. Tapestry je ogrodje (framework) za izdelavo spletnih aplikacij v jeziku Java. Prinaša spremembo v načinu razmišljanja in pozitivne učinke v razvojnem ciklu, ki seveda vključuje tudi oblikovalce. Delo je popolnoma objektno orientirano, kar pomeni, da ne razmišljamo kako sestaviti URL za izvedbo določene akcije na strežniški strani. Ravno tako ne skrbimo za nastavljanje parametrov, členjenje URL-jev in druge nizkonivojske operacije. Tapestry nadgrajuje Java Servlet API, kar omogoča delovanje spletne aplikacije v kateremkoli (npr. Tomcat) Java EE kontejnerju.

Na Tapestry poštno listo za uporabnike sem se vpisal avgusta leta 2004. Ponavadi se na listo za uporabnike prijavim takrat, ko me tema res zanima in jo v praksi tudi uporabljam. Lahko rečem, da sem programiranje spletnih aplikacij spoznal (leta 2000) iz diametralno nasprotne strani kot večina ostalih spletnih programerjev. Šok, ki sem ga doživel ob prehodu iz spletnega ogrodja WebObjects (WO) na Java Server Pages (JSP) ni bil majhen. Veselje ob odkritju Tapestry ogrodja je bilo veliko, saj sem že takoj na začetku spoznal WO korenine in idejne zasnove.

Spletne strani so sestavljene iz komponent, vsaka odgovorna za del funkcionalnosti. Komponente so po funkcionalnosti različne (vizualne, nevizualne) in jih seveda lahko pišemo na enostaven način tudi sami. Poleg priloženih je nastalo že veliko novih v prostokodni skupnosti. Za lažjo predstavo kaj je to komponenta: DirectLink, For, Form, Image, Script, in veliko drugih.

Mogoče je najpomembnejša lastnost način doseganja iluzije, da uporabnik z spletno aplikacijo ne komunicira prek stateless HTTP protokola. Tapestry ponuja več načinov kako hraniti stanje uporabnika od ene do druge HTTP zahteve.

Večna dilema je tudi sodelovanje programerjev in oblikovalcev. Tapestry se tega loti takole: HTML ne vsebuje nobene nove značke, kar pomeni, da lahko HTML predlogo gledamo med samim razvojem tako kot jo vidi oblikovalec - z vsemi dinamičnimi elementi - tudi seznami, ki se v živo npr. zgradijo iz podatkov iz podatkovne baze! To je mogoče zaradi zelo zelo premišljenega koncepta, ki je že od vsega začetka vključeval idejo tesnega sodelovanja programerjev in oblikovalcev. Najbolj enostaven primer je vsem znani HelloWorld. Samo za okus.

Validacija vnosnih polj je neobhodna naloga, ki jo Tapestry olajša na skorajda rutinsko opravilo. Poleg vgrajenih (min, max, email, minLength, maxLength, pattern, minDate, maxDate) lahko pišemo svoje validacijske algoritme (npr. preverba znakov iz generirane popačene slike), na strežniški in uporabnikovi strani - na enem mestu. Poglejte si tretje poglavje knjige Enjoying Web Development with Tapestry, ki jo tudi priporočam, če želite spoznati Tapestry, saj vas vodi zelo natančno od namestitve naprej. Prebral sem že kakšno knjigo, ampak tako dobro napisanih primerov še nisem srečal. Mislim, da je avtor Kent Tong izdal še eno knjigo na temo Web Services, ki bo tudi zagotovo na moji mizi.

Če bi moral na kratko povzeti ključne točke:

1. Pristop k programiranju spletnih aplikacij ne zahteva razmišljanja o URL naslovih in parametrih v njih, ampak o objektih, metodah in lastnostih.
2. Značilna je zelo visoka stopnja ponovne uporabe že narejenih komponent med projekti. Poudarjam, to ni copy/paste.
3. URL-je gradi framework. Posledično pomeni, da kompleksnost spletnih strani ne raste hitro z velikostjo aplikacije.
4. Enostavna lokalizacija in validacija.
5. Najenostavnejša integracija programerjev in dizajnerjev do sedaj tudi za velike projekte.
6. Zelo robustna aplikacija (manj kode, manj napak). Napake se sporočajo zelo natančno, zato jih lahko hitreje odpravljamo.
7. Persistenca med zahtevami uporabnika.

Zaradi arhitekture nam Tapestry ponuja odlično MVC okolje.

Topic Maps

Pred meseci sem se začel ukvarjati s problemom čigar rešitev vidim v znanju, ki se je začelo zbirati v začetku devedesetih let prejšnjega tisočletja, torej pred petnajstimi leti.

Začetni problem je bil izbrati ali izdelati ustrezno podatkovno strukturo, s katero bi lahko modeliral poljubne objekte in njihove lastnosti. Potreboval sem nekaj uporabnega, po možnosti programsko knjižnico z jasno definiranim API vmesnikom, ki bi jo nemudoma lahko uporabil kot temelj podatkovno gnane spletne aplikacije.

Nemalo časa sem porabil za iskanje in v tem času je mojo raziskovalno pot prekrižalo ogromno novih pojmov in zloglasnih tri-črkovnih kratic. Da se ne zapletem vanje že na začetku, bom poskusil na kratko obrazložiti pojem iz naslova tega bloga - topic maps.

Topic maps so ISO standard za predstavitev in izmenjavo znanja s poudarkom na lažji pridobitvi željene informacije. V njih so informacije predstavljene s temami (topics), asociaciami (associations) in pojavitvami (occurances). Za občutek kaj bi posamezni pojmi lahko predstavljali:

Topic Praktično karkoli. To je lahko oseba, začimba, številka, dogodek, datoteka, ...
Association Relacije med zgornjimi temami.
Occurance Relacije med temami in njihovimi pojavitvami v določenih kontekstih.

Topic map zgradimo z XML dialektom imenovanim XTM. Obstajajo orodja, tako odprtokodna kot komercialna, za izdelavo, različne vizualne predstavitve, analize in zlivanja že zgrajenih map. To slednje je zelo pomembno, ker pomeni združevanje znanja. Najlaže ilustriram na primeru.

Nekdo ali neka organizacija pripravi topic map, ki popisuje npr. začimbe za hrano. Na drugem koncu sveta je nekdo storil isto in ker tam rastejo drugačne rastline, je logično, da njegova mapa vsebuje nekaj zeli, ki jih prvi popisovalec ni vključil. Nekdo tretji je najbrž že opisal merske enote. Sedaj lahko jaz opišem kaj je to krompir, fižol, moka, jajca, vi pa iz vsega dosedaj naštetega in zlitega skupaj sestavite opis za nekaj jedi!

S tako bogatimi opisi se odpirajo ogromne možnosti predstavitev podatkov in predvsem iskanja po še vedno eksponentno naraščajočih količinah informacij, predvsem pa je to dober temelj za semantični splet - gotove bodočnosti.

Omeniti moram še RDF (Resource Description Framework), ki je "ravno tako" primeren za enkodiranje, izmenjavo in uporabo strukturiranih (meta)podatkov v XML obliki. Ker se vanj še nisem poglabljal, ne morem narediti niti kratke primerjave - mogoče v eni izmed naslednjih objav.

Vsebine, ki sem se jih samo dotaknil, so zelo obsežne in odpirajo celo nove delovne discipline, kot je na primer informacijski arhitekt, ki naj bi predstavil vsebine na tak način, da bi jih obiskovalci spletne strani z lahkoto našli in po njih navigirali. Hkrati naročniku ne sme naložiti nemogoče naloge pri pripravi podatkov in ne nazadnje razvijalcem ne dati pretrdega oreha pri izdelavi aplikacije.