6. oktober 2007

IBLOC 2007

Letos sem konferenco izkoristil za obisk delavnice "JBoss Seam: Revolucija poslovnega spleta", ki sta jo vodila (delavnico, ne revolucije) Aleš Justin in Matija Mazi. Naslov je bil za moj okus zastavljen preveč marketinško. Sama beseda "revolucija" ni bila pojasnjena.


Pogovarjali smo se o:
  • JBoss (aplikacijski strežnik),
  • Hibernate (OR/M ogrodje),
  • Seam (spletno ogrodje)
  • Drools (orodje za gradnjo poslovnih pravil),
  • jBPM (workflow engine)
Cilj delavnice naj bi bil izdelava preproste CMS spletne aplikacije, ki bi demonstrirala zgoraj naštete tehnologije, plus Ajax in postavitev v gručo. Resnici na ljubo, delavnica ni bila delavnica ampak predavanje, tako da sami nismo ničesar tipkali. Manjše razočaranje, ampak ok.

Šli smo korakoma skozi več faz implementacije mini CMS sistema. Aplikacija je bila shranjena v Subversion repozitoriju na Google Code, faze pa označene z značkami, tako da smo lahko hitro preizkušali funkcionalnosti - dober prijem.

Najprej smo govorili o modelu. Vsak razred je predstavljen kot POJO z anotacijami. Anotacije so bile praktično na vsakem koraku, na momente jih je bilo strašljivo veliko - najbrž se človek privadi. Anotacije so bile iz javax.persistence in org.hibernate.search.annotations. Več o Hibernate search kasneje. Na hitro smo omenili tudi strategije za preslikovanje modelnih razredov, če med njimi obstaja dedovanje. Pomembno je namreč, kako se taka struktura preslika v bazne entitete. Malo me je motilo, da se določeni pojmi niso razložili dovolj natančno, na primer - kako so med seboj povezani EJB 3, JPA in Hibernate 3 (v dvorani smo bili različni profili).

Ogledali smo si prikazno tehnologijo - JSF in Seam. Zdaj, ko poskušam napisati kako sta povezana, se mi poraja več vprašanj kot odgovorov. Moral sem iti na Google in malo raziskovati, da sem ugotovil, da je Seam "povezava" med JSF in EJB3. JSF je standard, privzeto Seam uporablja RichFaces kot implementacijo UI komponent. JSF je tudi po besedah Aleša, ki je zaposlen na JBoss, že od izida trpel zaradi slabega dizajna (v navezi z JSP), zaradi česar se mi je prav oddahnilo, saj je s tem pritrdil mojemu prepričanju. Bom pa najverjetneje v bližnji prihodnosti Seam (in JSF inkarnacije) raziskal. Na vprašanje o procesu izdelave spletne aplikacije, predvsem kako med seboj sodelujejo programerji in oblikovalci, nisem dobil ravno zadovoljivega odgovora. Grafično orodje za izdelavo dinamičnih HTML strani je še v izdelavi, ampak to sem odkril sam kasneje. Tako orodje Maticu ni kaj dosti pomenilo, po občutku.

Takole izgleda xhtml predloga (template) za vstopno stran mini CMS aplikacije:




V glavi je definiranih kar nekaj imenskih prostorov. Koliko je elementov v posameznem nimam pojma, bom pa ravno tako preveril. Nekatere od teh značk so vizualne, druge pa nevizualne "komponente". V narekovajih zato, ker si tudi še ne predstavljam JSF-jeve definicije komponente.

Govorili smo tudi o tako imenovani bijekciji (bijection), ki je posplošena injekcija (injection). Inversion of Control ali Dependency Injection ni obskurna tehnika, ampak mainstream prijem za pisanje bolj modularnih in testabilnih aplikacij.


Seam ima dobro rešen koncept kontekstov. Iz servlet specifikacije recimo poznamo request, session in application kontekste, Seam pa doda predvsem dva zanimiva: conversation in business. Oba sta veliko bolj smiselna iz stališča aplikacije, saj je vsaka uporabnikova akcija sestavljena iz niza nekih opravil in pri pisanju spletnih aplikacij pride vsaka pomoč pri abstrakciji takih nizov opravil nad stateless http protokolom zelo prav. Poslovni procesi pa gredo še korak dalje. Zajemajo več pogovorov različnih uporabnikov, stanja pa se shranjujejo na strežniku in delujejo tudi po izpadu strežnika. Proces opišemo z jezikom jPDL.

Omenjen je bil SeamGen, ki zna iz podatkovne baze zgraditi preprosto (iz publike je bilo slišati, da je še zelo nezrel) CRUD spletno aplikacijo. Videno in boljše realizirano že davno tega (
WebObjects Direct to Web ali Trails).


Avtentikacija in avtorizacija (AA) sta izvedeni kot nadgradnja nad JAAS in Seam skrije kompleksnost le-tega. Z Drools opišemo pravila, če jih potrebujemo za kompleksnejše postopke za AA.


Hibernate Search je bila ena izmed zanimivejših stvari tega predavanja. Poanta je, da z anotacijami v našem modelnem razredu, ki je seveda tudi perzistenten, označimo katera "polja" naj se indeksirajo (Lucene), tako da lahko transparentno po podatkih tudi iščemo (full text search)! Iskalnik nam tako vrača že inicializarane POJO objekte, ki ustrezaju danemu iskalmenu pogoju. Zelo, zelo zanimivo.


Ajax je pokrit z RichFaces. Malo, skoraj nič, nismo govorili o tem. Za raziskat.


No in na koncu smo aplikacijo pognali še v gruči (dva prenosna računalnika). V "osnovnem" načinu je gruča delovala, saj je po zrušitvi enega JBoss aplikacijskega strežnika delo prevzel drugi in uporabnik ni opazil, da dela na drugem stroju. Ni pa delovalo (ne vem zakaj) nadaljevanje dela, če je bil uporabik v seji (oddaja članka), ki traja čez več request-response ciklov.


Aleš pravi, da bo JBoss 5.0 kompletno prepisan na področju class loadinga, ker na zdajšnje stanje niso ravno ponosni.

Predavanje smo podaljšali kar za celo uro, ker je bilo na urniku skoraj preveč snovi - vsaka izmed njih bi lahko trajala nekaj ur. Teme so nam dale dobre iztočnice za samostojno nadaljevanje.

20. januar 2007

Commons Lang

Sicer že stara fora, ampak - ali najdete obraz na tej sliki? Po (pre)dolgem času sem se spet spravil napisat en tehno članek o rečeh, ki jih uporabljamo programerji. Tokrat o Jakarta Commons Lang.

Jakarta Commons Lang je javanska knjižnica, ki je nastala zaradi pomanjkanja metod, ki jih programerji potrebujemo pri vsakdanjem delu. JDK kljub ogromnemu številu razredov ne ponuja rešitev iz rokava za prav vsak problem, ki ga želimo rešiti.

Tako so se z leti razvoja te knjižnice izoblikovale “pomožne” (utility) metode za delo z
  • nizi (StringUtils, StringEscapeUtils, RandomStringUtils, Tokenizer, WordUtils),
  • znaki (CharSetUtils, CharSet, CharRange, CharUtils),
  • JVM (SystemUtils, CharEncoding),
  • serializacijo (SerializationUtils, SerializationException),
  • objekti (ObjectUtils),
  • razredi (ClassUtils),
  • polji (ArrayUtils),
  • boolean vrednostmi (BooleanUtils),
  • programskimi izjemami (!) (Exceptions),
  • graditelji (HashCodeBuilder, EqualsBuider, CompareToBuiler, ToStringBuilder),
  • matematičnimi operacijami (npr. NumberUtils.createNumber(String)),
  • tekstovnimi operacijami (StrBuilder, StrMatcher, StrTokenizer) in
  • operacije s časom (DateUtils, StopWatch, DateFormatUtils).
Suhoparno naštevanje paketov in razredov nima pomena. Tisti, ki ste taki, da začnete takoj tipkati ko zagledate nov API itak tega več ne berete in ste že na Commons Lang JavaDoc.

Fino je dobiti pregled nad celotno ponudbo takih in podobnih knjižnic, da ne izgubljamo časa z razvojem svojih (že izumljenih) rešitev. Na svetu je po zadnji oceni okrog tri milijone programerjev v Java jeziku in nekaj nas je že poskusilo napisat kak recept iz Commons Lang. Ste že našli noter tudi kaj svojega?

31. oktober 2006

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.

15. oktober 2006

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.

23. avgust 2006

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.

22. avgust 2006

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.

31. julij 2006

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.