Agilni projekti - pogosta dostava

Zagotovo je najpomembnejša lastnost vsakega projekta, naj bo ta majhen ali velik, pogosta dostava v hiši pretestirane aplikacije končnim uporabnikom.

Naročnik s tem dobi jasen vpogled v napredek izdelka. Uporabniki lahko na ta način hitreje pridobijo izkušnje in občutek ali je izdelek to kar v resnici potrebujejo. Vse pripombe in novi zahtevki se zbirajo sproti, da je razvijalcem lažje snovanje. Razvojna ekipa se na tak način tudi izogne pogostim zastojem zaradi nezmožnosti sprejetja odločitve o določenem aplikacijskem problemu. Nenazadnje to omogoča zgodnje razhroščevanje in pogostejši pregled nad razvojnim ciklom. Skupini se prileže tudi doza moralne vzpodbude z dokončanjem cikla.

Dostave programske opreme se razlikujejo, saj to lahko pomeni namestitve na delovnih postajah vseh končnih uporabnikov ali pa druga skrajnost posodobitev spletne aplikacije. Slednje je seveda neprimerno lažje, zato lahko dostavljamo pogosteje - tudi v dvo tedenskih ciklih, če je potrebno.

Prepogoste menjave ali nadgradnje uporabnike v najboljšem primeru jezijo. Če je možno si v takih primerih pomagamo z uporabniki, ki želijo imeti najnovejšo različico in tako pri njemu/njej "vadimo" namestitev in od njega/nje pridobivamo povratne informacije.

Integracija in iteracija sta dva različna pojma, ki ju ne smemo mešati. Integracija je postopek, ki mora biti v največji meri avtomatiziran v navezi z avtomatskimi testi in se mora dogajati čim pogosteje - boljše ekipe imajo samo 30 minutni interval. Iteracija pa vsebuje dokončanje sklopa cele skupine, integracije, poročil nadrejenim, pogovora v obliki reflektivnih izboljšav in pa seveda doseganje občutka dokončanja dela naloge. Ta občutek je zelo pomemben in zagotovo pripomore k izboljšanju timskega duha.

Past v katero se radi ujamemo je podaljševanje roka za konec načrtovanih iteracij zaradi nedokončanih delov aplikacije. Četudi dobronamerno, odgovorna oseba za odobritev teh podaljškov ekipi na dolgi rok bolj škodi, saj se emocije ob zaključkih nikoli ne zgodijo.

V odvisnosti od "sovražnosti" okolja oziroma naročnika, se odloča o tem ali naj se fiksira zahtevke do njihove izvedbe. Če naročnik pogosto spreminja zahteve, je to vsekakor pomembno.

Povzeto po knjigi Crystal Clear: A Human-Powered Methodology for Small Teams.

Model-View-Controller paradigma

Ljudje radi rešujemo (in delamo) probleme in nič kaj fino ni, da bi morali vedno znova in znova tuhtati kako jih najbolje rešiti. Problemov je veliko in prav tako rešitev, a z leti se izoblikujejo vzorci, ki se jih lahko držimo, da probleme rešimo hitreje in elegantneje.

MVC je arhitektura programske opreme. To je vzorec, ki nadgrajuje objektno orientirano programiranje. Primarni cilj je preprečiti spreminjanje domenske logike zaradi spremembe uporabniškega vmesnika in obratno, namerno ali nenamerno.

Model - To se objekti nad katerimi izvajamo določene operacije v aplikaciji in so značilni za problem, ki ga rešujemo. Ti objekti hranijo informacije, ki jih prikazujemo uporabniku in mu jih dajemo na voljo tudi za urejanje.

View - Prezentacija modela uporabniku aplikacije, pogosto v obliki primerni za interakcijo. V spletnih aplikacijah je to HTML in vezna koda, ki priskrbi podatke za dinamične strani.

Controller - Koda odgovorna za reakcijo na uporabniški vnos ali interakcijo. Običajno to pomeni spremembo v enem ali obeh ostalih nivojih. Deluje kot lepilo med modelom (domenskimi objekti) in izgledom (prezentacijo).

Tako pravi teorija. Kaj pa praksa? Iz mojega zornega kota je za izdelavo MVC spletne aplikacije potrebno v začetku kar nekaj truda. Osvojiti je potrebno koncepte "na bojišču", torej s praktično izdelavo in analizo projektov za katere vemo, da je bil v njih uporabljen tak princip in po možnosti še "best practices" prijemi. Pogosto zaradi časovne stiske za dokončanje projekta uporabljamo "gverilsko" programiranje in jo celo odnesemo s celo kožo, pogosto upravičeno.

Kaj pa v primeru, ko pričakujemo rast aplikacije? Takrat se zagotovo izplača investirati čas in zastaviti projekt izdelave enterprise spletne aplikacije po vzorcih (MVC ni edini), ki bodo nam ali programerjem in ostalim sodelujočim v prihodnosti delo olajšali ali sploh dovoljevali.

Konferenca "Izzivi razvoja sodobnih spletnih aplikacij"

Običajno grem v Kolosej v kino, saj je temu namenjen - danes pa se je tam odvijala kratka konferenca ali kot so jo poimenovali organizatorji Oracle Software družabno srečanje.

Kolikor vem v Sloveniji še ni bilo takega naslova na kakem predavanju ali pa sem hodil po svetu gluh in slep. Pričakovanja so bila mešana, saj na take vrste predavanjih lahko pričakujemo bolj pristranska mnenja in poglede. Popolne objektivnosti ni, obstajajo pa razpoznavni nivoji in merila.

Kupite si knjigo Art of Java Web Development: Struts, Tapestry, Commons, Velocity, JUnit, Axis, Cocoon, InternetBeans, WebWork in vedeli boste o čem govorim.

Veliko število poslušalcev potrjuje aktualnost tematike in to navdušenje nad številom je z nami delil tudi organizator.

Imam to srečo, da sem se že na začetku leta 2000 spoznal z enterprise spletnimi aplikacijami in orodji, ki so omogočale stvari, ki še danes jemljejo sapo. Naravnost neverjetne koncepte pri programiranju spletnih aplikacij ni še danes uspelo doseči nobenemu meni znanemu skupku spletnih o(g)rodij. Glodajte.

Veliko svojega časa porabim za raziskovanje tehnologij sloneč na Java jeziku z namenom lajšanja dela vsem vpletenim v proces razvoja in vzdrževanja spletnih aplikacij.

Predavanji Uroša Mesojedca in Petra Brajaka sta bili dobri, a mestoma pri slednjem neobjektivni. Pohvalil bi pomirjujoč in razumen ton pri odločitvah glede izbora pravega orodja za specifičen problem. Všeč sta mi bili tudi dve ideji, ki se v podjetju g.Brajaka uporabljata v praksi: skupno lastništvo kode in nočni integracijski testi.

Ko dobim povezavo na vsebino predavanj, bom lahko bolj natančno razložil kaj sem mislil z grajo, če bo to koga zanimalo...