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.