D I P L O M S K A N A L O G A - Milovan Tomaševićdk.fis.unm.si/dip/UN_2010_Peter_Grilj.pdffakulteta za informacijske Študije v novem mestu . d i p l o m s k a n a l o g a . univerzitetnega

FAKULTETA ZA INFORMACIJSKE ŠTUDIJE

V NOVEM MESTU

D I P L O M S K A N A L O G A

UNIVERZITETNEGA ŠTUDIJSKEGA PROGRAMA PRVE STOPNJE

PETER GRILJ

FAKULTETA ZA INFORMACIJSKE ŠTUDIJE

V NOVEM MESTU

DIPLOMSKA NALOGA

SPLETNA GALERIJA »galx«

Mentor: doc. dr. Blaž Rodič

Novo mesto, september 2010 Peter Grilj

IZJAVA O AVTORSTVU

Podpisani Peter Grilj, študent FIŠ Novo mesto, v skladu z določili statuta FIŠ izjavljam:

da sem diplomsko nalogo pripravljal samostojno na podlagi virov, ki so navedeni v diplomski nalogi,

da dovoljujem objavo diplomske naloge v polnem tekstu, v prostem dostopu, na spletni strani FIŠ oz. v digitalni knjižnici FIŠ (obkroži odločitev):

o takoj, o po preteku 12 mesecev po uspešnem zagovoru, o ne dovoljujem objave na spletni strani oz. v elektronski knjižnici FIŠ zaradi

prepovedi organizacije, v sklopu katere je bil pripravljen empirični del naloge. da je diplomska naloga, ki sem jo oddal v elektronski obliki identična tiskani verziji, da je diplomska naloga lektorirana.

V Novem mestu, 30.9.2010 Podpis avtorja ______________________

ZAHVALA

Zahvaljujem se mentorju doc. dr. Blažu Rodiču za strokovno pomoč in nasvete pri izdelavi diplomske naloge.

Zahvala gre tudi moji družini in vsem ostalim, ki so mi bili tekom študija v podporo in pomoč.

POVZETEK

Diplomska naloga zajema opis orodij in tehnologij ter razvoj spletne galerije »galx«. Povod

za razvoj aplikacije je vedno večja potreba različnih vrst umetnikov po samopredstavitvi na

spletu. Namen diplomske naloge je razviti specifični CMS (»Content Management System«)

sistem s primarno funkcionalnostjo spletne galerije, ki bo stremela k čim boljšem pokritju

uporabniških zahtev in preprostosti uporabe. Kot sekundarne funkcionalnosti pa bo rešitev

vsebovala še ostale ključne elemente, ki jih mora vsebovati vsaka predstavitvena stran na

spletu: blog, komentarje, povezave, statične strani z dodatnimi informacijami itn. Dodana

vrednost te rešitve za uporabnika je možnost enostavnega ustvarjanja in urejanja vsebin ter

prilagajanja oblike spletne strani lastnim potrebam. Ciljni uporabniki sistema »galx« so

predvsem različni tipi umetniško usmerjenih podjetij ali posameznikov in tisti, ki bi se želeli

na spletu predstaviti z zbirkami slik.

KLJUČNE BESEDE: spletna stran, galerija, slike, komentarji, blog, povezave, teme,

iskanje, administracija, CMS sistem.

ABSTRACT

The thesis contains a brief description of tools and technologies, as well as the development

of “galx” web gallery. The catalyst to develop this application is the increased need of

different types of artists for self presentation on the web. The purpose of the thesis is to

develop a specific CMS with web gallery as its primary functionality, which is going to try

covering user demands and include an intuitive user interface. Its secondary functionalities are

the other usual key elements of any self presentation website: blog, comments, links, static

pages, etc. The advantages of such an application for the user are the possibilities to easily

create and edit content and the adaptation of the page's design to personal needs. The target

users of the “galx” system are mainly different types of businesses or individuals who would

like to present themselves with collections of images.

KEY WORDS: web gallery, web page, images, comments, links, themes, search,

administration, CMS

KAZALO

1 UVOD ................................................................................................................................. 1

2 PREGLED PODOBNIH REŠITEV ................................................................................... 2

2.1 Galerije z uporabo odprtokodnih CMS sistemov ........................................................ 2

2.2 Gallerycms ................................................................................................................... 3

2.3 Gullery ......................................................................................................................... 3

2.4 GrokPhoto .................................................................................................................... 3

2.5 Gallery ......................................................................................................................... 4

2.6 Coppermine gallery ...................................................................................................... 4

2.7 Zenphoto ...................................................................................................................... 4

3 METODOLOGIJA ............................................................................................................. 5

3.1 Agilna metoda razvoja aplikacij .................................................................................. 6

3.1.1 Posamezniki in komunikacija so pomembnejši kot sam proces in orodja ............ 7

3.1.2 Delujoča programska oprema je pomembnejša kot popolna dokumentacija....... 7

3.1.3 Vključevanje uporabnika je pomembnejše kot pogajanje na osnovi pogodb ....... 7

3.1.4 Upoštevanje sprememb je pomembnejše od sledenja planu. ................................ 8

3.1.5 Priporočila pri gradnji in vrednotenju metodologij ............................................. 8

3.1.6 Model XP .............................................................................................................. 9

3.1.7 Model SCRUM .................................................................................................... 10

3.1.8 Model FDD ......................................................................................................... 11

3.1.9 Model ASD .......................................................................................................... 12

3.1.10 Agilna metodologija in Ruby on Rails ................................................................ 13

4 OPIS PROGRAMSKEGA OKOLJA APLOKACIJE ...................................................... 14

4.1 Programski jezik Ruby ............................................................................................... 14

4.2 Platforma Ruby on Rails ............................................................................................ 15

4.2.1 Komponente Ruby on Rails................................................................................. 18

4.3 jQuery ........................................................................................................................ 19

4.4 Podatkovna baza MySQL .......................................................................................... 19

4.5 Strežnik Nginx ........................................................................................................... 20

4.5.1 Phusion Passenger ............................................................................................. 21

4.6 Sphinx ........................................................................................................................ 21

4.7 ImageMagick ............................................................................................................. 21

5 NAČRTOVANJE APLIKACIJE ..................................................................................... 21

5.1 Analiza zahtev ............................................................................................................ 22

5.2 Definiranje funkcionalnosti aplikacije ....................................................................... 23

5.2.1 Primeri uporabe ................................................................................................. 23

5.2.2 Podatkovni model ............................................................................................... 25

5.2.3 Koncept uporabniškega vmesnika ...................................................................... 28

5.3 Časovni načrt ............................................................................................................. 33

6 IMPLEMENTACIJA ....................................................................................................... 34

6.1 Priprava sistema ......................................................................................................... 34

6.1.1 Compass ............................................................................................................. 35

6.1.2 Haml/Sass ........................................................................................................... 35

6.1.3 Haml-scaffold ..................................................................................................... 35

6.1.4 Will_paginate ..................................................................................................... 35

6.1.5 Mocha ................................................................................................................. 35

6.1.6 FCKeditor ........................................................................................................... 35

6.1.7 Paperclip ............................................................................................................ 35

6.2 Implementacija galerije .............................................................................................. 36

6.3 Implementacija slik .................................................................................................... 36

6.4 Implementacija bloga ................................................................................................. 37

6.4.1 Acts-as-taggable-on ............................................................................................ 37

6.5 Implementacija komentarjev ...................................................................................... 37

6.5.1 RedCloth ............................................................................................................. 37

6.6 Implementacija statičnih strani .................................................................................. 37

6.7 Implementacija povezav ............................................................................................ 38

6.8 Implementacija indeksne strani.................................................................................. 38

6.8.1 Implementacija glave .......................................................................................... 38

6.8.2 Implementacija noge........................................................................................... 38

6.9 Implementacija nadzorne plošče ................................................................................ 38

6.9.1 Simple navigation ............................................................................................... 39

6.9.2 Rails-settings ...................................................................................................... 39

6.10 Implementacija tem ................................................................................................ 39

6.11 Implementacija zaščite ........................................................................................... 39

6.11.1 Authlogic ............................................................................................................. 40

6.12 Implementacija iskanja ........................................................................................... 40

7 TESTIRANJE ................................................................................................................... 40

7.1 Testiranje enot ............................................................................................................ 41

7.2 Funkcionalno testiranje .............................................................................................. 42

7.3 Testiranje integracije .................................................................................................. 43

7.4 Sistemsko testiranje ................................................................................................... 44

8 REZULTAT RAZVOJA .................................................................................................. 46

8.1 Namestitev ................................................................................................................. 46

8.2 Uporaba ...................................................................................................................... 47

8.2.1 Predstavitveni del ............................................................................................... 47

8.2.2 Administratorski del ........................................................................................... 54

9 ZAKLJUČEK ................................................................................................................... 60

10 LITERATURA ................................................................................................................. 63

11 VIRI .................................................................................................................................. 65

KAZALO SLIK

Slika 3.1: Model XP ................................................................................................................. 10

Slika 3.2: Model SCRUM ........................................................................................................ 11

Slika 3.3: Model FDD .............................................................................................................. 12

Slika 4.1: Hierarhija razredov Ruby 1.9 ................................................................................... 15

Slika 4.2: Rails Model View-Controler-arhitektura ................................................................. 17

Slika 5.1: Primer uporabe: administrator .................................................................................. 24

Slika 5.2: Primer uporabe: obiskovalec .................................................................................... 25

Slika 5.3: Podatkovni model ..................................................................................................... 26

Slika 5.4: Koncept indeksne strani ........................................................................................... 29

Slika 5.5: Koncept zbirke galerij .............................................................................................. 29

Slika 5.6: Koncept prikaza galerije........................................................................................... 30

Slika 5.7: Koncept urejanja in kreiranja vsebin ........................................................................ 30

Slika 5.8: Koncept prikaza posamezne slike ............................................................................ 31

Slika 5.9: Koncept prikaza članka na blog-u ............................................................................ 31

Slika 5.10: Koncept komentiranja vsebin ................................................................................. 32

Slika 5.11: Koncept prijavnega obrazca ................................................................................... 32

Slika 5.12: Koncept nadzorne plošče ....................................................................................... 33

Slika 5.13: Časovni načrt .......................................................................................................... 34

Slika 8.1: Indeksna stran ........................................................................................................... 48

Slika 8.2: Seznam galerij .......................................................................................................... 49

Slika 8.3: Galerija ..................................................................................................................... 49

Slika 8.4: Slika .......................................................................................................................... 50

Slika 8.5: Blog .......................................................................................................................... 51

Slika 8.6: Etikete ...................................................................................................................... 51

Slika 8.7: Seznam komentarjev ................................................................................................ 52

Slika 8.8: Obrazec za oddajo komentarja ................................................................................. 52

Slika 8.9: Statična stran »About« ............................................................................................. 53

Slika 8.10: Povezave ................................................................................................................ 53

Slika 8.11: Iskanje .................................................................................................................... 54

Slika 8.12: Obrazec za priajvo .................................................................................................. 55

Slika 8.13: Glava ...................................................................................................................... 55

Slika 8.14: Glava galerij in slik ................................................................................................ 55

Slika 8.15: Možnosti galerije .................................................................................................... 56

Slika 8.16: Sortiranje slik v galeriji .......................................................................................... 56

Slika 8.17: Obrazec za urejanje vsebin ..................................................................................... 57

Slika 8.18: Nastavitve ............................................................................................................... 57

Slika 8.19: Nastavitve statičnih strani ...................................................................................... 58

Slika 8.20: Administracija komentarjev ................................................................................... 58

Slika 8.21: Teme ....................................................................................................................... 59

Slika 8.22: Nastavitve uporabnika ............................................................................................ 59

Slika 8.23: Nastavitve uporabnikov ......................................................................................... 60

KAZALO TABEL

Tabela 5.1: Specifikacija zahtev ............................................................................................... 22

Tabela 5.2: Tabela aktivnosti.................................................................................................... 33

1

1 UVOD Samopredstavitev na spletu je dandanes ključnega pomena na malodane vseh področjih.

Umetnost oz. posel ustvarjanja vizualnih vsebin ni izjema. Vedno več je umetnikov, ki na

spletu predstavljajo svoja dela, bodisi z željo po večji prodaji izdelkov, pridobitvi novih strank

ali zaposlitve. Potrebe po predstavitvi svojega portfelja pa nimajo samo umetniki, sem

spadajo tudi razvijalci informacijskih sistemov, razvijalci video iger, obrtniki itn. Obstaja

torej potreba po celoviti rešitvi, ki bi bila enostavna za uporabo in bi pokrila vse potrebe ciljne

skupine uporabnikov.

Veliko podjetij ponuja svojim strankam rešitve v obliki CMS1 sistemov. Ti se v večini delijo

na osnovne predstavitvene sisteme, ki omogočajo objavo novic in spreminjanje ostalih

statičnih vsebin na strani in tako imenovane e-poslovne CMS sisteme, ki omogočajo spletno

trgovanje z izdelki. CMS sistemi, ki bi se osredotočali na galerije slik, so zelo redki. Za

izpolnitev teh potreb se v večini primerov odločajo za predelavo osnovnih CMS sistemov ali

izdelavo strani od začetka po željah stranke, ker je lahko za slednje zelo drago.

Namen diplomske naloge je razviti specifični CMS sistem s primarno funkcijo spletne galerije

imenovane »galx«. Sistem bo služil kot predstavitvena spletna stran posameznika ali podjetja

s poudarkom na slikovnih vsebinah. Primarna funkcionalnost bo ustvarjanje in urejanje galerij

slik in njim pripadajočih atributov, kot so npr. naslov, opis, datum objave, avtor itn.

Sekundarne funkcionalnosti bodo: blog, povezave, statične strani z dodatnimi informacijami

itn. Obiskovalec spletne strani bo lahko svoje mnenje o posamezni vsebini izrazil z oddajo

komentarja. Dodana vrednost, ki jo bo za uporabnika uvedla predlagana rešitev, je možnost

enostavnega ustvarjanja in urejanja vsebin ter prilagajanja oblike spletne stani lastnim

potrebam.

Cilj diplomske naloge je izdelati spletno aplikacijo, ki bo stremela k čim boljšem pokritju

uporabniških zahtev in preprostosti uporabe. Fleksibilnost produkta omogoča pokritost

segmenta predstavitvenih spletnih strani in ogrodje za nadaljnjo izdelavo morebitnih

kompleksnejših rešitev.

1 CMS (ang. Content management system) je sistem, ki omogoča urejanje in vzdrževanje vsebine spletne strani

brez znanja programiranja v HTML. Urednik spletne strani lahko samostojno ureja vsebino spletne strani brez

pomoči podjetja ali osebe, ki je stran izdelalo.

2

Ciljni uporabniki sistema »galx« so predvsem različni tipi umetniško usmerjenih podjetij ali

posameznikov (oblikovalci, fotografi, slikarji, kiparji,…) in tisti, ki bi se želeli na spletu

predstaviti z zbirkami slik. Takšna spletna stran bi služila predvsem kot neke vrste spletni

portfolio ali spletni katalog. Dodatne funkcionalnosti bloga in komentarjev bi lastnikom strani

omogočale neposredni stik z njihovo ciljno publiko. Obenem pa je to tudi enostaven način

pridobivanja povratnih informacij, kako svoj produkt še izboljšati.

Pričakovani rezultat je delujoča spletna aplikacija, ki bo postavljena na splet kot praktična

predstavitev funkcionalnosti sistema morebitnim bodočim uporabnikom oz. kupcem. Zaradi

svoje fleksibilnosti in enostavnosti uporabe bo aplikacija predstavljala veliko poslovno

priložnost tako iz vidika stranke kot ponudnika storitve. Slednjemu ne bo potrebno vsakič

ponovno začeti razvijati spletne strani, kar bo posledično drastično znižalo ceno produkta.

2 PREGLED PODOBNIH REŠITEV Galerije slik so eden od ključnih elementov sodobnih internetnih strani. Malodane vsaka stran

v neki meri predstavlja določen del svoje vsebine preko zbirk slik. Večina teh je specifično

implementiranih le za dotično stran. Gre bodisi za predelave obstoječih rešitev ali specifični

razvoj po meri. V obeh primerih ne gre za galerijo kot primarno funkcionalnost spletne strani,

temveč le za dopolnilo k vsebini. Celovite rešitve, ki bi ponujale galerije kot primarno

funkcionalnost, so redke. V večini primerov gre za rešitve po naročilu ali predelave z uporabo

vtičnikov (ang. »plugins«) v velikih odprtokodnih CMS sistemih. Vtičniki so bodisi specifični

za obstoječe CMS sisteme (predvsem odprtokodne) ali »prosti«, ki jih lahko vstavimo kar v

html kodo. Ti so običajno spisani bodisi v JavaScript2-u ali Adobe Flash3-u in je njihova

dodana vrednost predvsem estetske narave.

2.1 Galerije z uporabo odprtokodnih CMS sistemov V zadnjih letih se na spletu pojavlja vedno več odprtokodnih CMS sistemov. Ti imajo v

večini primarno funkcionalnost objavljanja novic ali blogov. Najbolj znani so: WordPress,

Joomla, Drupal, SilverStripe, modx itn. Ti so v večini napisani v zelo razširjenem

2 JavaScript je objektni programski jezik, vgrajen v brskalnike.

3 Adobe Flash je multimedijska platforma za dodajanje animacij, videa in interaktivnosti spletnim stranem.

3

programskem jeziku PHP4. Skupni imenovalci vseh so možnost prilagoditve videza z uporabo

tem, odprtost kode, ki omogoča, da se platformo povsem priredi lastnim potrebam in vtičniki.

Slednji omogočajo na enostaven način spletni strani dodati kakršnokoli funkcionalnost.

Uporabnik lahko sam razvije svojega ali izbere med kopico obstoječih rešitev, ki so lahko

bodisi plačljive bodisi odprtokodne.

2.2 Gallerycms Gallerycms je brezplačen CMS sistem za upravljanje z galerijami slik. Spisan je v PHP

platformi Codelgiter. Zbirka galerij je zelo preprosta, vsaka galerija vsebuje naslov in opis ter

vsebujoče slike. Tako galerije kot posamezne slike v njih je možno urejati, brisati in jim

določiti vrstni red ter velikost. Gallerycms je načrtovan kot zgolj CMS sistem, ki galerije

generira v xml5 formatu, na katerem se lahko zgradi galerijo v Adobe Falsh-u. (Gallerycms)

2.3 Gullery Gullery je zelo preprosta odprtokodna galerija slik spisana v Ruby on Rails. Namenjena je

ustvarjanju manjših galerij ali portfoliov. Omogoča preprosto urejanje galerij slik in njihovih

atributov. Vsaka galerija ima poleg naslova še opis. Vmesnik je zelo preprost, vse operacije se

izvajajo na isti strani. Slike se lahko poljubno sortira in tudi obrača. Urejanje izgleda je možno

z CSS6 kodo. Slikam, ki so dodane v galerije, se avtomatsko prilagodi velikost s programom

ImageMagick, ki ga je potrebno namestiti na strežnik poleg galerije. (Gullery Photo Gallery,

2010)

2.4 GrokPhoto Gorkphoto je profesionalna CMS galerija, namenjena predvsem fotografom. Fotografu

omogoča ustvarjanje lastnega portfolia, razstavljanje galerij slik in direkten kontakt s

strankami. Poleg običajnih galerij, ki so vidne vsem obiskovalcem strani, lahko administrator

v svoji nadzorni plošči ustvari uporabnika tipa stranka, ki preko prijave dostopa do lastne

galerije ali več njih. V tem oddelku lahko stranka tudi odda komentar pod slikami in se tako

ustvari direktna komunikacija z avtorjem. Administrator lahko ustvari poleg galerije še

4 PHP Ang. Hypertext Preprocessor ali v preteklosti Personal Home Page Tools je odprtokodni programski jezik

za razvoj strežniško baziranih aplikacij.

5 Xml (ang. extensible markup language) je razširljiv označevalni jezik, ki omogoča format za opisovanje

strukturiranih podatkov.

6 CSS (ang. cascading style sheets) so predloge, ki določajo izgled spletnih strani.

4

poljubno število statičnih strani z različnimi dodatnimi informacijami, ki jih želi posredovati

obiskovalcem. Za zaščito slik pred zlorabami aplikacija omogoča avtomatsko vključitev

poljubnega vodnega žiga na slike. Aplikacija je v celoti implementirana s platformo Ruby on

Rails. Za obdelavo fotografij uporablja program ImageMagick. (GrokPhoto)

2.5 Gallery Gallery je odprtokodni projekt, katerega cilj je razvoj in podpora vodilne aplikacije za

deljenje slik na spletu. Aplikacijo že nekaj let razvija večja skupina razvijalcev in je trenutno

tik pred izidom tretje različice. Razvita je v spletnem jeziku v php, za obdelovanje slik pa

potrebuje ImageMagick ali NetPBM. Kot je zapisano na njihovi spletni strani gre za najbolj

razširjeno spletno aplikacijo tega tipa. Gallery omogoča intuitivno rešitev za upravljanje s

slikami na manjših ali večjih spletnih straneh. Aplikacija sama skrbi zgolj za upravljanje s

slikami, medtem ko za vse ostale funkcionalnosti, ki jih imajo običajne aplikacije, mora

uporabnik poskrbeti sam. (Gallery menalto)

2.6 Coppermine gallery Coppermine je odprtokodna, večnamenska, multifunkcijska spletna galerija, spisana v PHP-

ju. Gre za kompleten CMS sistem za upravljanje z galerijami slik, ki vsebuje dovršen sistem

administracije z veščimi tipi uporabnikov. Le-tem je možno po meri nastavljati pravice

dostopa do določenih vsebin in nastavitev. Slike lahko prijavljeni uporabniki komentirajo in

ocenijo. Stran beleži statistke uporabnikov in tako lahko posreduje najbolj priljubljene slike,

najbolj gledane slike ipd. Galerija ima več različnih vrst pogleda, katere je moč preko

nastavitev in tem preoblikovati v končni produkt. Dodatne funkcionalnosti, ko so novice

(blog), statične strani, forum ipd., je potrebno posebej implementirati. (Coppermine gallery)

2.7 Zenphoto Zenphoto je brezplačna spletna CMS galerija s filozofijo »preprosto je najboljše«. Aplikacijo,

spisano v PHP-ju, avtorji razvijajo že od leta 2005. Kljub motu, ki strmi k preprostosti, gre za

zelo dovršen produkt, ki ponuja vse potrebne funkcionalnosti za upravljanje z slikovnimi

vsebinami. Poleg slik pa podpira tudi video in avdio vsebine ter vse potrebne elemente za

kreiranje celotne spletne strani, vključno z novicami, komentarji in poljubnimi statičnimi

stranmi. Slikam lahko obiskovalci dajo tudi oceno. Videz galerije je možno spremeniti s

temami, nekaj jih je možno prenesti iz uradne strani, kjer so tudi navodila, kako ustvariti

svoje. Funkcionalnosti aplikacije je možno še dodatno razširiti z dodatki, ki so prav tako

5

dostopni na uradni strani skupaj z navodili kako ustvariti svoje. Dotična aplikacija se najbolj

približa »galx« tako po filozofiji razvoja kot po funkcionalnostih. (Zenphoto)

3 METODOLOGIJA Za razvoj aplikacij oz. informacijskih sistemov, kamor spadajo tudi spletne aplikacije, se

uporabljajo različne metodologije. Metodologijo lahko v splošnem opredelimo kot skupek

postopkov, tehnik, orodij in pripomočkov za dokumentiranje, ki koristijo razvijalcem sistema

pri implementaciji informacijskega sistema. Sestavljajo jo faze, ki so same sestavljene iz

podfaz in ki vodijo razvijalce sistema pri izbiri tehnik, ki so primerne v vsaki fazi projekta ter

jim pomagajo načrtovati, upravljati, kontrolirati in ocenjevati projekte razvoja informacijskih

sistemov. Metodologija je dejansko še več kot le skupek njenih sestavin. Metodologije se

razlikujejo v posameznih tehnikah, ki jih priporočajo, v postopkih, ki jih predpisujejo ali v

vsebini posamezne faze, včasih gre celo za bolj osnovne razlike. (Avison in Fitzgerald, 2006:

347-352)

Pogosto, ko govorimo o metodologijah, pravzaprav ne vemo dobro, kaj metodologija sploh je.

Ni res, da številna podjetja pri svojem delu ne uporabljajo nobene metodologije, saj je ta v

neki obliki prisotna praktično pri vsakem organiziranem delu. Metodologija zajema vse, kar

redno počnemo, da bi dosegli želen rezultat, torej izdelek ali storitev, ki je cilj našega dela. V

primeru razvoja programske opreme to ne pomeni zgolj postopkov, ki so neposredno

povezani z razvojem, temveč zajema tudi podporne postopke, načine komunikacije med

sodelujočimi, pravila odločanja itd. V tem oziru lahko metodologijo opredelimo tudi kot

množico dogovorov (konvencij), s katerimi se projektna skupina oz. organizacija strinja.

(Bajec in Krisper, 2003)

Metodologija je kot taka prežeta s filozofijo, načeli, idejami in pogledi organizacije in njenih

članov, kar še posebej poudarja njeno sociološko komponento. Metodologija namreč ni nekaj,

kar lahko nastane neodvisno od ljudi, katerim je namenjena. Čeprav obstajajo številne

formalne metodologije, ki temeljijo na preizkušenih postopkih, ki so se v praksi izkazali kot

dobri, si jih organizacije, ko jih privzamejo, vedno prilagodijo po svoji meri, tako da ustrezajo

njihovemu načinu dela ter percepciji domene, za katero so vzpostavljene. Z uporabo

metodologije se uporabniki učijo in pridobivajo nove izkušnje, s čimer se posledično bogati

tudi metodologija sama. (Bajec in Krisper, 2003)

Najuspešnejše metodologije razvoja spletnih aplikacij so:

6

• Modeli tradicionalnih metodologij:

o Model od zgoraj navzdol

o Model od spodaj navzgor

o Kaskadni model

o Inkrementalni model

• Modeli evolucijske metodologije:

o Spiralni model

o Prototipni model

o Ciklični in inkrementalni model

• Agilne metodologije:

o XP - Ekstremno programiranje

o SCRUM

o FDD - Funkcionalno usmerjen razvoj programskih rešitev

o DSDM - Dinamični sistemski model razvoja programskih rešitev

o ASD - Prilagodljivi razvoj programskih rešitev

(Bauer, 2005)

3.1 Agilna metoda razvoja aplikacij Temelji agilnih metodologij so bili postavljeni decembra 2001, ko se je sestala skupina

sedemnajstih gurujev, tako ali drugače znanih s področja lahkih metodologij (Adaptive

Software Development, XP-Extreme Programming, Feature-Driven Development, Crystal,

Scrum, Dynamic System Development Method idr.). Namen sestanka je bil ugotoviti, kaj

imajo »njihove« metodologije skupnega in na osnovi tega postaviti skupne metodološke

osnove. Tokrat so pod drobnogledom lahke metodologije, katerih število je v zadnjih letih

močno naraslo. Njihova temeljna lastnost je učinkovitost in prilagodljivost, s čimer je skupina

sedemnajstih, združena v zvezo Agile Alliance, opisala tudi nov trend agilnih metodologij. V

skupni izjavi so člani zveze kot njihov cilj zapisali »iskanje boljših pristopov razvoja

programske opreme, tako da pri tem sami sodelujejo in pomagajo drugim.« Iz tega so izpeljali

štiri načela:

• posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja,

• delujoča programska oprema je pomembnejša kot popolna dokumentacija,

• vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi

pogodb in

7

• upoštevanje sprememb je pomembnejše od sledenja planu.

(Agilemanifesto)

Najbolj priljubljeni modeli razvoja programskih rešitev na področju agilnih metodologij so

model XP, model SCRUM, model FDD, model DSDM in prilagodljiv razvoj programske

opreme.

3.1.1 Posamezniki in komunikacija so pomembnejši kot sam proces in orodja Prvo načelo izhaja iz mnenja, da se je potrebno v večji meri posvetiti individualnim članom

projekta, njihovemu znanju in tudi željam. Toga porazdelitev vlog, ki jih proces določa med

člane projekta ni smiselna, če nimamo ustreznih ljudi, ki bi te vloge uspešno opravljali. Poleg

upoštevanja posameznikov načelo poudarja pomen komunikacije. Dobra komunikacija je

namreč ključna za uspešnost projekta. Boljše rezultate dosežemo, če je komunikacija in

sodelovanje članov projekta dobro, pa čeprav se ne držijo nobenega predpisanega procesa, kot

pa v primeru, ko je proces predpisan, komunikacija med njimi pa slaba. (Bajec in Krisper,

2003)

3.1.2 Delujoča programska oprema je pomembnejša kot popolna dokumentacija

Delujoč program je največ, kar lahko končni uporabnik dobi. Dokumentirane zahteve, model

statičnih elementov sistema, model interakcij in druga dokumentacija o problemski domeni in

samem sistemu so vsekakor koristni, vendar vseeno sekundarnega pomena. Naročnik ne bo

zadovoljen s kupom dokumentacije, če ne bo najprej videl delujočega sistema. Ena večjih

kritik slapovnega procesa je ravno v tem, da naročnik praktično vse do konca projekta čaka na

sleherno komponento programske opreme. Vse, kar lahko medtem dobi, je dokumentacija. Po

drugi strani pa je dokumentacija temeljnega pomena, saj olajša vzdrževanje sistema,

komunikacijo med izvajalcem in naročnikom, proučevanje kakovosti dela projektne skupine

itd. Zato je pomembno, da dokumentacijo izdelujemo, vendar s poudarkom na »ravno

dovolj«. Vsak kos dokumentacije mora biti utemeljen. (Bajec in Krisper, 2003)

3.1.3 Vključevanje uporabnika je pomembnejše kot pogajanje na osnovi pogodb

S tretjim načelom je pozornost posvečena odnosu med naročnikom in izvajalcem. Ta je v

mnogih primerih preveč formalen in strog. Za uspešnost projekta je ključnega pomena, da se

8

naročnik in izvajalec dobro ujameta. Poleg tega naročnik najbolje ve, kaj potrebuje, čeprav

tega pogosto ne zna razložiti. V agilno usmerjenih metodologijah je zato vloga naročnika

postavljena na pomembno mesto. Medtem ko lahko dober odnos med naročnikom in

izvajalcem v veliki meri olajša še tako tehnološko zahteven projekt, lahko strog pogodbeni

odnos in nerazumevanje med naročnikom in izvajalcem zamaje tudi enostavne projekte.

(Bajec in Krisper, 2003)

3.1.4 Upoštevanje sprememb je pomembnejše od sledenja planu. Spremembe so eden od razlogov, ki ga pogosto povezujemo z neuspešnimi projekti. Številni

avtorji ugotavljajo pomen obvladovanja sprememb in temu sledijo tudi moderne

metodologije. Dinamika poslovnih okolij botruje številnim spremembam, zato je naivno

pričakovati, da bomo lahko v začetnih fazah projekta zajeli vse zahteve. Projektni plani so

koristen element, vendar morajo omogočati spremembe, vsaj v smislu preureditve prioritet

znotraj dogovorjenega okvirja. Poudariti velja, da je planiranje in sledenje planu koristno,

vendar le do stanja, ko se to ne razlikuje preveč od dejanskega. Najslabše je slediti planu, ki je

zastarel. (Bajec in Krisper, 2003)

3.1.5 Priporočila pri gradnji in vrednotenju metodologij Iz načel, ki veljajo kot osnova agilnih metodologij, so izpeljana številna priporočila, ki so v

pomoč pri gradnji in vrednotenju metodologij. Vse metodologije, ki se upravičeno deklarirajo

kot agilne, jih upoštevajo.

• Najvišja prioriteta je zadovoljstvo stranke, zato je priporočeno zgodnje in pogosto

izdajanje komponent preizkušene in delujoče programske opreme. To je temelj

prilagodljivega razvoja, saj na osnovi medprojektnih izdaj pridobimo koristne

povratne informacije, tveganje, da bo izdelek neustrezen, pa zmanjšamo.

• Delujoče komponente programske opreme je potrebno izdajati pogosto, v ciklu, ki ni

daljši od štirih mesecev. Če je naročnik zmožen sprejemati izdelke v krajših razmikih

in je tudi razvojna ekipa sposobna upoštevati vse sprotne spremembe, potem so krajši

cikli še boljši. Iterativni pristop je praktično nujen.

• Spremembe v zahtevah naj bodo dobrodošle tudi v poznih fazah razvoja. Eno izmed

načel agilnih pristopov je dober odnos med naročnikom in izvajalcem. Spremembe, ki

nastanejo med projektom in smo jih pripravljeni upoštevati, lahko prinesejo naročniku

pomembno konkurenčno prednost, zato se jih ne smemo otepati. Iterativni pristop se

tudi na tem mestu izkaže kot primeren.

9

• Projekti naj vključujejo motivirane posameznike. Omogočeno naj jim bo ustrezno

delovno okolje ter vse, kar pri svojem delu potrebujejo. Zaupati jim je potrebno, da

bodo delo opravili dobro. Nedvomno so na projektu koristnejši motivirani

posamezniki, ki med seboj dobro komunicirajo, čeprav ne sledijo predpisanemu

procesu, kot pa nemotivirani ljudje. Posamezniki lahko s svojim odnosom do dela v

veliki meri vplivajo na uspeh oziroma neuspeh projekta.

• Najboljši način prenosa informacij do in med člani projekta je komunikacija »iz oči v

oči«. Metodologija XP je ena prvih, ki je priporočala, da morajo člani projekta sedeti v

isti sobi, saj je s tem omogočeno pogosto in učinkovito komuniciranje. Vsaka druga

vrsta komunikacije (elektronska pošta, video sestanki, telefonski razgovori) je manj

učinkovita. Če med člane vključimo tudi predstavnike naročnika, potem je čas, ki ga

potrebujemo, da dobimo odgovor, praktično minimalen.

• Kakovost programske kode in arhitekture je potrebno stalno preverjati in izboljševati,

saj s tem povečamo prilagodljivost. Pristop, kjer najprej izpeljemo poglobljeno

analizo, izdelamo dober načrt in nato razvijemo programsko kodo, je priporočljiv,

vendar si ga pogosto ne moremo privoščiti. Zaradi potrebe po hitrih rezultatih je

kakovost velikokrat zapostavljena, zato je pomembno, da v vsakem ciklu stremimo k

izboljšavam.

• Enostavnost procesa je ključ do uspeha. Kako razviti kakovostno programsko opremo,

pri tem pa opraviti čim manj stranskih nalog in izdelkov? Proces mora biti ravno

dovolj zahteven. Raje malo manj kot pa preveč. To nikakor ne pomeni, da moramo

aktivnosti izvajati površno ali pomanjkljivo. Nasprotno, naše delo mora biti opravljeno

kvalitetno, paziti pa moramo, da ni po nepotrebnem komplicirano. Pot do enostavnosti

je v resnici težka, saj je včasih preprosteje pustiti stvari kompleksne, kot pa jih

poenostaviti.

• Po vsakem intervalu moramo preveriti proces, ki smo ga uporabljali, kjer ugotavljamo,

kaj je bilo pri tem dobrega in kaj odveč. Glede na ugotovitve proces prilagodimo in

izboljšamo za naslednje iteracije.

(Agilemanifesto)

3.1.6 Model XP Najbolj znani agilni model razvoja programskih rešitev je ekstremno programiranje ali model

XP (ang. »Extreme Programming«). Model XP se je razvil iz težav daljšega cikla razvoja

10

programskih rešitev, ki so jih povzročale klasične metodologije razvoja programskih rešitev.

Model XP je mogoče označiti s kratkimi razvojni cikli, primarnim načrtovanjem, stalne

povratne informacije in komunikacijo. Z vsemi navedenimi lastnostmi se XP programerji

odzivajo na spreminjajoče se okolje z veliko več poguma. Člani skupine XP porabijo skupaj

dnevno nekaj minut za programiranje, nekaj minut za upravljanje projekta, nekaj minut pri

oblikovanju, nekaj minut za povratne informacije in nekaj minut za oblikovanje in grajenje

timskih odnosov. Ena od temeljnih idej modela XP je, da ne obstaja ena metodologija razvoja

programskih rešitev, ki bi bila uporabna v vsakem projektu, ampak obstajajo prakse, ki bi

morale biti prilagojene potrebam posameznih projektov (Beck, 1999).

Slika 3.1: Model XP

Vir: Beck, 1999: 132.

3.1.7 Model SCRUM Model Scrum izvira iz hitre izdelave prototipov, ki naj bi podpirali okolje, v katerem so bile

zahteve na začetku nepopolne in so se lahko tudi zelo hitro spreminjale. Za razliko od modela

XP model SCRUM na prvo mesto vključuje vodstveni in ne razvojni proces, ki naj bi

nasprotno od težkih metodologij dramatično povečal produktivnost v timu. Model SCRUM je

empirična tehnika vodenja, za katero je realnost pomembnejša od načrtov, potrebno je

nenehno sodelovanje, zaupanje v ljudi in napredek. SCRUM temelji na samoorganizaciji, v

kateri se tim odloči, kaj storiti, medtem ko vodstvo vodi in odpravlja težave. Združuje vse

11

ključne lastnosti agilnih metodologij razvoja programskih rešitev, njena posebnost pa je

organizacija ter izvajanje vodenja in hkrati obvladovanje projektnega tima. Uporaba modela

SCRUM temelji na realizaciji realno mogočega, dnevnega preverjanja napredka in pogostih

korektur. Bistvo so majhni projektni timi (do deset ljudi), serija »sprintov« (eden do štirje

tedni), vidne in uporabne nadgradnje ter časovno omejevanje. Razvoj programske rešitve se

zaključi, ko je uporabnik zadovoljen z napredkom in ustreznostjo programske rešitve. Po

končani programski rešitvi nato tim izvede testiranje in usposabljanje ter napiše potrebno

dokumentacijo, ki je potrebna za sprostitev programske rešitve. (Abrahamsson in drugi, 2002:

27-36)

Slika 3.2: Model SCRUM

Vir: Abrahamsson in drugi, 2002: 28.

3.1.8 Model FDD Funkcionalno usmerjen razvoj programskih rešitev ali model FDD (ang. »Feature Driven

Development«) za razliko od drugih modelov ne zajema celotne programske rešitve

razvojnega procesa, temveč se osredotoča na načrtovanje in gradbene faze. Model FDD

pooseblja iterativni razvoj z najboljšimi praksami, ki se je izkazal za učinkovito metodo

predvsem v industrijski dejavnosti. Poudari vidike kakovosti v celotnem procesu in vključuje

pogoste in opredmetene dobave programskih rešitev, skupaj z natančnim spremljanjem

12

napredka projekta. Za razliko od nekaterih drugih agilnih modelov je model FDD primeren

tudi za razvoj kritičnih sistemov (Palmer in Felsing, 2002).

Slika 3.3: Model FDD

Vir: Palmer in Felsing, 2002: 57.

Model DSDM

Dinamični sistemski model razvoja programskih rešitev ali model DSDM (ang. »Dynamic

System Development Method«) je bil razvit v Veliki Britaniji v sredini leta 1990. Temeljna

zamisel modela DSDM je določiti čas in sredstva in nato prilagodi funkcionalnost programske

rešitve. Model DSDM je sestavljen iz petih faz:

• študija izvedljivosti,

• študija poslovanja,

• funkcionalni model,

• načrtovanje in izgradnja ter

• implementacija.

Prvi dve fazi sta zaporedni in se opravita samo enkrat. Zadnje tri faze, med katerimi je

dejansko razvojno delo, se ponavljajo do zaključitve projekta. Čas trajanja projekta je vnaprej

določen. V modelu DSDM je tipično obdobje trajanja projektnega cikla nekaj dni do nekaj

tednov (Stapleton, 1997).

3.1.9 Model ASD Prilagodljivi razvoj programskih rešitev ali model ASD (ang. »Adaptive Software

Development«) je razvil Jim Highsmith leta 2000. Model ASD ponuja prilagojen pristop k

13

razvoju programskih rešitev v projektih z velikimi in hitrimi spremembami. V hitro

napredujočem in nepredvidljivem poslovnem okolju ni mogoče uspešno načrtovati projekta,

tako da je v modelu ASD statični plan zamenjan z dinamičnim, špekulativnim in učečim se

življenjskim ciklom razvoja programske rešitve. Model ASD je sestavljen iz treh nelinearnih

in prekrivajočih se faz:

• špekulacija - za določitev poslanstva projekta se je potrebno zavedati, kaj je v projektu

nejasno in neznano,

• sodelovanje - poudarja pomen timskega dela v projektih z velikimi in hitrimi

spremembami in

• učenje - ta faza poudarja, da je potrebno priznati in se odzvati na napake ter da se

lahko zahteve tudi spremenijo med razvojem programske rešitve.

(Highsmith, 2000)

3.1.10 Agilna metodologija in Ruby on Rails Izbira agilne metode za razvoj spletne galerije »galx« je tako tekoč obvezna, kajti le-ta gre z

roko v roki s platformo Ruby on Rails. Agilnost je dejansko vključena v samo Rails

platformo.

Rails je usmerjen v posameznike in njihovo komunikacijo. Nima zapletenih orodij, ne

kompleksnih nastavitev, ne elaboriranih procesov. So le majhne skupine razvijalcev, njihovi

priljubljeni urejevalniki besedil in obilo Ruby kode. To vodi k popolni transparentnosti - kar

razvijalec naredi, se instantno prelevi v to, kar stranka vidi. Gre za resnično interaktiven

proces (Ruby in drugi, 2008: 16).

Rails ne zanemarja dokumentacije, temveč naredi trivialno enostavno ustvarjanje HTML

dokumentacije celotne kode. Toda proces razvoja z Ruby on Rails ni dokumentno usmerjen.

Programi tako ne vsebujejo več stranskih specifikacij, temveč uporabniki in razvijalci že od

začetka združijo moči pri iskanju rešitve. Platforma je tako sposobna servirati delujočo rešitev

že v zgodnjih fazah razvoja. Ta je še precej okorna in nedovršena, a ponuja uporabniku

možnost videti delček tega, kar bo na koncu nastalo (Ruby in drugi, 2008: 16).

Na ta način Rails izpodbuja sodelovanje z strankami. Ko stranke vidijo, kako hitro se Rails

projekt lahko odzove na spremembe, začnejo zaupati, da lahko razvijalski tim naredi to, kar je

14

potrebno in ne samo, kar je zahtevano. Tako se navadno pogajalski sestanki spremenijo v

»Kaj če« sestanke (Ruby in drugi, 2008: 17).

Vse to je tesno povezano z idejo sposobnosti hitrega odziva na spremembe. Močno, skoraj

obsesivno strmenje Rails-a k DRY principu programiranja pomeni, da je za vsako spremembo

potrebno spremeniti bistveno manj kode kot z uporabo kakšne druge platforme (Ruby in

drugi, 2008: 17).

4 OPIS PROGRAMSKEGA OKOLJA APLOKACIJE Spletna galerija »galx« je v celoti izdelana s spletno platformo Ruby on Rails, strežnikom

Nginx in podatkovno bazo MySQL. Za popolno delovanje aplikacije sta potrebna še programa

ImageMagick in Sphinx.

4.1 Programski jezik Ruby Ruby je objektno orientiran, dinamičen programski jezik z bogatim in močnim API7-jem.

Izhaja iz programskih jezikov Perl, Lisp in Smalltalk, toda s sintakso, ki je lahko razumljiva C

in Java programerjem. Je popolnoma objektno orientiran jezik, lahko pa se uporablja tudi za

funkcijsko in proceduralno programiranje (Flanagan in Matsumoto, 2008: 1-24).

V začetku devetdesetih let ga je ustvaril Japonec Yukihiro Matsumoto, v angleško govoreči

razvijalski skupnosti poznan pod vzdevkom Matz. Od svojih najpriljubljenejših programskih

jezikov je pobral tisto, kar se mu je zdelo najboljše, in ustvaril nov jezik, ki je ravnovesje med

funkcionalnim in imperativnim programiranjem (Ruby).

Prva stabilna verzija Ruby-ja je bila izdana decembra leta 1995. 25. decembra leta 1996 je

izšla različica 1.0. Trenutna stabilna različica Ruby-ja je 1.9.1. Ker jezik nima specifikacije,

velja MRI (Matz Ruby Interpreter), ki je napisan v jeziku C, za de facto referenco. Obstaja

več implementacij interpreterja, napisanih v različnih programskih jezikih, najbolj razširjena

pa je javanska implementacija jRuby (Matsumoto, 2001: 1-4).

Filozofija jezika predpostavlja, da so ljudje "gospodarji", računalniki (stroji na splošno) pa

njihovi "sužnji". Ruby je torej jezik, ki v ospredje postavlja programerje, njihovo

produktivnost. Kot pravi njegov avtor jezika: »Med razvojem jezika sem se osredotočal na

7 API (ang. application programming interface) je vmesnik, implementiran znotraj nekega programa, ki mu

omogoča komunikacijo z drugimi programi.

15

enostavno in hitro programiranje. Vse značilnosti so narejene in delajo točno tako, kot

programerji pričakujejo. Programerjem so elegantne, enostavne rešitve všeč in naredijo

programiranje zabavnejše.« (Matsumoto, 2001: 5-35).

Ker je Ruby v celoti objektno orientiran jezik, je vsaka vrednost v njem objekt. Celo kosom

informacij in kode je možno dodeliti lastnosti in metode.

RubyGems je Ruby knjižnica, ki omogoča razširitev programskega jezika z dodatnimi

zmogljivostmi. Gre za standardni format distribuiranja Ruby aplikacij in knjižnic. Orodje je

namenjeno enostavnemu načinu instalacije gem-ov in njihovo serversko distribucijo (podobno

kot EasyInstall pri jeziku Python). RubyGems je sedaj del standardnih knjižnic v Ruby 1.9.

Vse operacije nad gem-i se izvajajo preko konzolnega ukaza gem (oz. ruby gem v Windows

okolju). Eden od najpopularnejših gem-ov je »Rails«, ki Ruby-ju doda platformo za razvoj

spletnih aplikacij, ki je bistveno pripomogel k popularnosti jezika samega (Flanagan in

Matsumoto, 2008: 36-109).

4.2 Platforma Ruby on Rails Rails je odprtokodna platforma, namenjena izdelavi spletnih aplikacij, napisana v skriptnem

jeziku Ruby. Zasnovana je tako, da naredi programiranje spletnih aplikacij lažje z

Slika 4.1: Hierarhija razredov Ruby 1.9

Vir: Ruby Class Hierarchy.

16

ustvarjanjem določenih predpostavk o tem, kaj vse razvijalec potrebuje, da bi začel. Narediti

je možno več z bistveno manj kode kot pri kateremkoli drugem spletnem programskem jeziku

ali platformi. Platforma Ruby on Rails predpostavlja, da obstaja najboljši način izdelovanja

nečesa in je zasnovana tako, da vzpodbuja razvijalca, da izbere najboljšo pot. Ko razvijalec

enkrat osvoji »rails način«, se njegova produktivnost bistveno poveča (Tate in Hibbs, 2006: 1-

17).

Ustvaril jo je danski programer David Heinemeier Hansson iz podjetja 37signals. Izvira iz

spletne aplikacije imenovane Basecamp, iz katere ga je Heinemeier Hansson izpeljal. Za

razliko od jezika, na katerem sloni, avtor ni imel namena ustvariti platformo. Želel je iz

obstoječe aplikacije izluščiti ogrodje, da bi ga uporabljali za razvoj drugih aplikacij. Svoje

delo si je hotel olajšati tako, da je izluščil pogoste funkcionalnosti, kot so abstrakcije

podatkovne baze in predloge v to, kar je kasneje postalo prva javna različica Ruby on Rails.

Prva beta verzija je izšla julija 2004, verzija 1.0 je izšla 13. decembra 2005. To, da je Rails

izluščen iz Basecamp-a, se šteje v skupnosti Rails razvijalcev kot ena izmed velikih prednosti

platforme, kajti reševala je realne probleme že ob izidu. Ruby on Rails torej ni nastala iz nič,

temveč se je že izkazala kot uporabna in celovita platforma. David Heinemeier Hansson še

vedno vodi razvoj Rails-a, največja ugodnost za platformo je bila njena izdaja kot odprta

koda. S časom so razvijalci, ki delajo z Rails-om, objavili na stotine dodatkov in popravkov v

razvojno Rails skladišče (ang. »Rails development repository«). Vodi ga okoli dvanajst

visoko usposobljenih profesionalnih razvijalcev, ki jih vodi Heinemeier Hansson (Lenz, 2007:

1-16). Trenutna stabilna različica je 2.3, ki jo bo v kratkem zamenjala 3.0, ki je že v končnih

fazah testiranja.

Temeljni principi platforme Ruby on Rails so:

• MVC (Model-View-Controller) arhitektura. Koda je Rails-u organizirana v treh

plasteh (slika 4.2).

o Modeli skrbijo za shranjevanje in obdelavo podatkov. Rails pole tega vključuje

tudi podporo ORM (Object-relational mapping) tehniki, ki opravlja

komunikacijo s podatkovno bazo na nivoju objektov. Programerju torej ni

potrebno znati specifik posameznih implementacij SQL baz, saj za poizvedbe

na podatkovno bazo skrbi ActiveRecord, Rails implementacija ORM, ki je za

programerja transparentna, saj podatke vidi na nivoju objekta.

17

o Predstavitvena plast (View) predstavlja vmesnik med uporabnikom in

aplikacijo. Običajno so to HTML datoteke in delčki Ruby kode (podobno kot

pri PHP-ju). Naloga teh datotek je predstavitev podatkov uporabniku

aplikacije.

o Kontrolerji (Controller) so kot "lepilo" med modeli in predstavitveno plastjo.

Skrbijo za prihajajoče zahtevke in posredovanje podatkov v predstavitveno

plast.

• DRY (ang. »Don't repeat yourself«) narekuje, da se ne sme dvakrat napisati kodo, ki

naredi enako stvar. Raje se napiše generično.

• Konvencija namesto konfiguracije: predpostavlja, da programer ve, na kakšen način se

določeno stvar naredi namesto da se to zapisuje v konfiguracijske datoteke.

• REST (ang. representational State Transfer) je arhitektura aplikacij, katere glavni

principi so:

o vse naj ima svoj ID,

o vse mora biti povezano z povezavami,

o uporaba standardnih metod,

o viri naj imajo več predstavništev in

o komunikacija brez stanj.

(Railsguides)

Slika 4.2: Rails Model View-Controler-arhitektura

Vir: Intermediate Rails: Understanding Models, Views and Controllers.

http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/

18

Da Rails deluje, je poleg jezika Ruby potrebno imeti tudi spletni in podatkovni strežnik,

katerih je na voljo pestra izbira. Večina spletnih strežnikov za Rails je baziranih na spletnem

strežniku Apache. V zadnjih letih pa postaja vedno bolj priljubljen spletni strežnik Nginx v

navezi z modulom za izvajanje Rails aplikacij Passenger, ki porabi bistveno manj strežniških

resursov. Za razvojno okolje je najboljše če se uporablja privzeti strežnik Webrick, ki je

vključen v Ruby on Rails gem. Podatkovno bazo je moč izbrati med: MySQL, PostgreSQL,

SQLite, Oracle, SQL Server, DB2, CouchDB, Firebird ali privzeti SqLite strežnikih. Skoraj

katerikoli sistem zadostuje za razvoj in testiranje, a za produkcijsko okolje je priporočen Unix

tip operacijskega sistema (Rubyonrails).

4.2.1 Komponente Ruby on Rails Rails vsebuje številne komponente, ki omogočajo kreiranje spletnih aplikacij.

4.2.1.1 Action Controller

Action Controller je komponenta, ki upravlja kontrolerje v Rails aplikaciji. Sprejema zahteve

Rails aplikacije in namenjeni akciji posreduje ustrezne parametre. Action Controller-jeve

funkcije so upravljanje s sejami, generiranje predlog in preusmerjanje (Railsguides).

4.2.1.2 Action View

Action View upravlja s predstavitveno plastjo Rails aplikacije. Privzeto lahko generira HTML

in XML kodo. Upravlja tudi prikazovanje predlog (vključno z ugnezdenimi in delnimi

predlogami) in vključuje vgrajeno AJAX8 podporo (Railsguides).

4.2.1.3 Active Record

Active Record je osnova za modele v Rails aplikaciji. Zagotavlja neodvisnost od podatkovne

baze, osnovne CRUD9 funkcionalnosti (Railsguides).

4.2.1.4 Action Mailer

Action Mailer je platforma za kreiranje e-poštnih storitev znotraj Rails aplikacije. Uporabi se

lahko za pošiljanje e-pošte na fleksibilnih predlogah ali za prejemanje in procesiranje prejete

e-pošte (Railsguides).

8 AJAX (ang. Asynchronous JavaScript and XML) je skupina medsebojno povezanih spletnih razvojnih tehnik,

uporabljenih za ustvarjanje interaktivnih spletnih aplikacij.

9 CRUD (ang. Create, Read, Update and Delete) so osnovne funkcije za delo z objekti, hranjenimi v podatkovni

bazi.

http://mysql.com/http://www.enterprisedb.com/http://www.sqlite.org/http://www.oracle.com/index.htmlhttp://www.microsoft.com/sqlserver/http://www-01.ibm.com/software/data/db2/http://couchdb.apache.org/http://www.firebirdsql.org/

19

4.2.1.5 Active Resource

Active Resource prinese platformo za upravljanje z povezavo med poslovnimi objekti in

RESTful spletnimi storitvami. Implementira pot za mapiranje spletno osnovanih resursov v

lokalne objekte z CRUD semantiko (Railsguides).

4.2.1.6 Railties

Railties je jedro Rails kode, ki gradi nove Rails aplikacije in združuje različne paltforme

skupaj v vsaki Rails aplikaciji (Railsguides).

4.2.1.7 Active Support

Active Support je obsežna zbirka razredov in standardnih Ruby knjižnic, ki poganjajo tako

Rails kot tudi v njem napisane aplikacije (Railsguides).

4.3 jQuery jQuery je hitra in zgoščena izpeljanka JavaScript knjižnice. Omogoča hitrejšo in lažjo

uporabo knjižnic pri izgradnji spletnih strani. Zgrajen je s ciljem spremeniti način pisanja

JavaScript kode, in sicer z motom »Napiši manj, naredi več!«. Gre za eno izmed

najpopularnejših Javascript knjižnic na spletu, poganja pa zelo širok spekter različnih spletnih

strani; od medijsko bogatih, interaktivnih in efektov polnih strani, do poslovno kritičnih

aplikacij z naprednimi vmesniki. Pripravil jo je John Resig, prvič pa je bila objavljena

Januarja 2006 na BarCamp NYC (jQuery).

4.4 Podatkovna baza MySQL Privzeto podatkovno bazo SQLite je bilo tekom razvoja potrebno zamenjati z MySQL zaradi

implementacije iskanja s programom za indeksiranje Sphinks.

SQLite je odprtokodna podatkovna baza z izjemno majhno porabo resursov. Za razliko od

običajnih SQL podatkovnih baz, SQLite za svoje delovanje ne potrebuje ločenega procesa na

strežniku, saj bere in piše neposredno v običajno datoteko na disku. Tako je celotna zbirka s

tabelami, indeksi in pogledi shranjena v eno datoteko na disku. Je izjemno kompaktna baza,

saj z vsemi vključenimi funkcijami zasede okrog 300kB. Z izklopom posameznih funkcij pa

se lahko ta velikost še manjša (SQLite).

MySQL je sistem za upravljanje z relacijskimi podatkovnimi bazami. Gre za odprtokodno

implementacijo podatkovne baze, ki za delo s podatki uporablja jezik SQL10. Deluje na

10 SQL (ang. Structured Query Language) je strukturirani povpraševalni jezik za delo s podatkovnimi bazami.

20

principu odjemalec – strežnik, pri čemer lahko strežnik namestimo kot sistem, porazdeljen na

več strežnikov. Obstaja veliko število odjemalcev, zbirk ukazov in programskih vmesnikov za

dostop do podatkovne baze MySQL. Glavne značilnosti podatkovnega strežnika MySQL so

deklarativnost (povemo kaj in ne kako), relacijski model (množice), funkcionalna preprostost,

enostaven nabor ukazov, zmogljivost in brezplačnost. Napisan je v programskem jeziku C in

C++ in deluje na različnih platformah (Linux, Mac OS X, Windows,...). Knjižnice za dostop

do podatkovne baze MySQL so na voljo v vseh večjih programskih jezikih, preko tako

imenovanih vmesnikov API. MySQL je sposoben izkoriščati toliko centralnih procesnih enot,

kolikor jih je na voljo. Najbolj popularen je pri izdelavi spletnih strani in deluje kot

podatkovna zbirka tako imenovane LAMP11 in WAMP12 platforme. Njegova popularnost pri

uporabi spletnih aplikacij je tesno povezana s priljubljenostjo jezika PHP. Zaradi

zmogljivosti, ki jih ponuja, se vedno bolj uporablja tudi v navezi z platformo Ruby on Rails.

Predvsem gre tu za večje projekte, kjer osnovne funkcionalnosti, ki jih ponuja SQLite, ne

zadostujejo več (MySQL).

4.5 Strežnik Nginx Nginx, ki se izgovarja »Engine X«, je lahek, visoko zmogljiv in brezplačen spletni strežnik.

Deluje na vseh najbolj razširjenih operacijskih sistemih UNIX, Linux, Mac OS X, Solaris in

Microsoft Windows. Poznan je predvsem kot zmogljiv, stabilen, poln funkcij, preprost za

nastaviti in predvsem z nizko porabo resursov. Nastal je, da bi izpolnil potrebe večjih spletnih

strani v lasti ruskega podjetja Rambler, med katerimi velja izpostaviti največji istoimenski

ruski spletni portal, ki ima opravka z več kot 500 milijoni zahtevki na dan. Nginx je eden

rekih strežnikov, pisanih za reševanje problema C10K13. Za razliko od običajnih strežnikov

Nginx ne bazira zahtevkov na nitih. Namesto tega uporablja veliko bolj prilagodljivo

dogodkovno vodeno arhitekturo. Ta arhitektura porabi majhne, in kar je najpomembneje,

predvidljive količine pomnilnika pod obremenitvijo. Tudi, če stran ne potrebuje tako velikih

zmogljivosti, lahko še vedno pridobi veliko od Nginx-ove zmogljivosti in majhne porabe

resursov (Nginx).

11 LAMP - Linux, Apache, MySQL, PHP/Perl/Python

12 WAMP - Windows, Apache, MySQL, PHP/Perl/Python

13 C10K je čas, ki ga strežnik porabi za istočasno upravljanje z deset tisoč klienti.

21

4.5.1 Phusion Passenger Phusion Passenger je modul za izvajanje Rails aplikacij na strežnikih Apache in Nginx. Gre

za stabilen, zmogljiv in varen sistem, za katerega ni potrebna nobena dodatna konfiguracija. V

kombinaciji z Ruby Enterprise Edition 14je zmožen zmanjšati porabo spomina za kar 33% in

obenem povečati zmogljivost (Passenger).

4.6 Sphinx Sphinx je odprtokodni strežnik za iskanje nizov, ki indeksira vsebino podatkovne baze. Razvit

je bil od spodaj navzgor s cilji zmogljivosti, relevantnosti (kvaliteta iskanih zadetkov) in

enostavnosti integracije Indeksirane podatke lahko hrani v SQL in NoSQL podatkovni bazi ali

kar v datotekah v XML formatu. Na Rails platformi deluje v navezi z gem-om Thinking

Sphinx, ki poveže ActiveRecord z Sphinx-om in tako omogoči iskanje znotraj spletne

aplikacije (Sphinx, Thinking Sphinx).

4.7 ImageMagick ImageMagick je zastonjska zbirka programov za ustvarjanje, urejanje in sestavljanje bitnih

slik. Sposoben je delati s preko 100 različnih slikovnih formatov vključno z DPX, EXR, GIF,

JPEG, JPEG-2000, PDF, PhotoCD, PNG, Postscript, SVG in TIFF. Nad slikami je možno

izvesti naslednje operacije: pretvorbe, obračanja, preslikave, pomanjšanja, popravljaje barv in

dodajane različnih posebnih učinkov (ImageMagick).

5 NAČRTOVANJE APLIKACIJE Izbrana agilna metodologija narekuje, da je načrtovanje kratko in jedrnato, da se čim prej

preide v fazo implementacije. Potrebno se je osredotočiti na to, da bodo modeli čim bolj

preprosti in da so zajete vse osnovne zahteve. Prednost uporabe platforme Ruby on Rails

pride do izraza že pri načrtovanju, kjer je potrebno definirati le funkcionalnosti aplikacije. Vsi

ostali aspekti so že predefinirani in vgrajeni v platformo samo.

Zaradi lažjega dela s platformo Ruby on Rails bo spletna galerija »galx« tako z vidika kode

kot uporabniškega vmesnika spisana v angleškem jeziku.

14 Ruby Enterprise Edition je serverjem namenjena verzija Ruby-ja, z več izboljšavami, ki ga je razvilo podjetje

Phusion.

22

5.1 Analiza zahtev Glavne zahteve spletne galerije »galx« so:

Tabela 5.1: Specifikacija zahtev

Zahteva Opis

Kreiranje in urejanje

galerij slik

Administrator (oz. lastnik) strani lahko kreira galerije slik,

katerim doda želene atribute, kot so: naslov, opis in naslovna

slika. Naslov naj bo obvezen atribut, ostali so le opcijski.

Ustvarjene galerije in njihove atribute lahko poljubno ureja in

po potrebi tudi odstrani.

Nalaganje in urejanje

slik v galeriji

Administrator lahko v posamezno galerijo nalaga slike, katerim

doda naslov in po želji tudi opis. Slike in njihove atribute lahko

po želji ureja in odstranjuje. Slike naj bo moč tudi sortirati v

poljubnem vrstnem redu.


novic (bloga)

Administrator lahko na spletni strani objavlja članke v obliki

bloga. Le-te lahko ureja in briše. Vsaki objavi naj se pripiše tudi

ime avtorja.

Možnost komentiranja

galerij, slik in

objavljenih novic na

blogu

Obiskovalci spletne strani lahko komentirajo galerije, slike in

bloge. Možnost oddaje komentarja naj bo na dnu vsake od

vsebin. Administrator naj ima možnost izklopa komentiranja pri

posamezni vsebini ali kar globalno pri vseh komentarjih.

Etiketiranje objav na

blogu.

Članke bloga naj je moč etiketirati (ang. »tagging«). Vse etikete

naj bodo zbrane v posebnem oblačku etiket (ang »tag cloud«).

Pregled in

administracija nad

oddanimi komentarji

Administrator naj ima pregled nad zadnjimi oddanimi

komentarji na enem mestu. Komentarje naj ureja in po potrebi

tudi briše.

Dodajanje in urejanje

statičnih strani

Administrator lahko poljubno dodaja, ureja in odstranjuje

statične strani na strani. Povezava do teh naj se doda v glavnem

meniju.


povezav

Administrator lahko dodaja, ureja in odstranjuje povezave na

temu posebej namenjeni podstrani. Stran s povezavami lahko

tudi izklopi.

23

Upravljanje z

nastavitvami spletne

strani

Administrator naj ima popoln nadzor nad spletno stranjo v temu

posebej namenjeni podstrani, kjer naj bodo zbrane vse

nastavitve na enem mestu, sortirane po kategorijah.

Dostop do funkcij preko

prijave

Dostop do administratorskih funkcionalnosti naj bo zaščiten s

prijavo. Administrator mora vnesti svoje uporabniško ime in

geslo.

Dodajanje in urejanje

uporabnikov

(administratorjev) strani

Administrator ali več njih lahko urejajo svoje podatke in

kreirajo ter odstranjujejo druge uporabnike. Tip prijavljenih

uporabnikov naj bo eden administrator.

Možnost urejanje videza

spletne strani

Posebna sekcija nastavitev spletnih strani naj bodo teme, ki

omogočajo nastavitev in urejanje videza celotne spletne strani.

Uporabnik lahko ustvari poljubno število tem. Le-te lahko ureja

in po potrebi tudi odstrani.

Uporaben, enostaven in

intuitiven uporabniški

vmesnik

Uporabniški vmesnik mora biti zanimiv za pogled in prilagojen

za čim hitrejše delo.

Stran naj ima le en glavni meni v glavi. Ob prijavi naj se

pojavijo dodatne administrativne možnosti.

Urejanje vsebin spletne strani naj poteka preko vmesnika,

podobnega priljubljenim namiznim pisarniškim programskim

paketom kot je Microsoft Word.

Hitro in varno delovanje

aplikacije

Stran se mora nalagati hitro in pravilno v vseh podprtih

brskalnikih. Varnost podatkov naj bo zagotovljena z hranjenjem

le-teh v podatkovni bazi in s kriptiranjem gesel.

Podpora za vse najbolj

priljubljene spletne

brskalnike

Stran naj podpira vse najpriljubljenejše spletne brskalnike:

Firefox, Opera, Safari, Chorme in Internet Explorer 8.

Vir: Lastni prikaz, 2010.

5.2 Definiranje funkcionalnosti aplikacije

5.2.1 Primeri uporabe Akterji:

• Uporabnik (obiskovalec)

• Administrator

24

5.2.1.1 Administrator

Administrator je edini uporabniški tip, ki zahteva prijavo v sistem. Ima popoln nadzor nad

celotnim sistemom. Slika 5.1 prikazuje diagram primere uporabe za subjekt administrator.

Slika 5.1: Primer uporabe: administrator

Indeksna stran

Administrator

Prijava

Odjava

Gallerije

novice

Nastavitve strani

Nastavitve uporabnikov

statične strani

povezave

slika

splošne nastavitve

nastavitve statičih strani

administracija komentarjev

teme

nova galerija

uredi galerijosortiraj slike

galerija

nove slike

nova slika

briši galerijo

uredi sliko

briši sliko

nastavitve uporabnika

nastavitve uporabnikov

novica

nova novica

uredi novico

briši novico

komentiraj

nova povezava

briši povezavo

uredi povezavo

nova statična stran

uredi statično stranbriši statično stran

uredi komentar

briši komentar

nova tema

uredi temo

sortiraj statične strani

briši temo

uredi uporabnika briši uporabnika

nov uporabnik


5.2.1.2 Obiskovalec

Obiskovalec je osnovni tip uporabnika »galx«. Vpogled ima nad vsemi statičnimi in

dinamičnimi vsebinami spletne strani kot je prikazano na diagramu uporabe (slika 5.2).

Oddaja komentarjev je edini način, ki ga ima obiskovalec, da pripomore k vsebini.

25

Slika 5.2: Primer uporabe: obiskovalec

Indeksna stran

Obiskovalec

Gallerije

novice

statične strani

povezave

slikagalerija

novica

komentiraj


5.2.2 Podatkovni model Slika 5.3 prikazuje podatkovni model spletne galerije »galx«. Sestavlja ga enajst entitet:

galerija, slika, članek, komentar, tema, uporabnik, statična stran, povezava, uporabniška seja,

stran in pošta. Prikazuje, kakšne atribute imajo entitete in v kakšni relaciji je ena entiteta z

drugo.

26

Slika 5.3: Podatkovni model


Vsaka entiteta vsebuje standardne atribute, ki jih avtomatsko generira Ralis: created_at –

datum vnosa v bazo, updated_at – čas zadnje spremembe vnosa v bazo. Entitete Image,

Gallery in Post vsebujejo atribut delta, ki ga zahteva program za indeksiranje Sphinx. Gallery,

Static, Image, Theme in Post imajo atribut permalink, ki predstavlja alternativo ID-ju in se

uporablja v poti do dotične podstrani. Atribut position pri entitetah Image in Static predstavlja

pozicijo v vrstnem redu posameznega vnosa.

5.2.2.1 Galerija

Galerija (»Gallery«) je podatkovna struktura galerij slik. Njeni atributi so: id (primarni ključ

galerije), title (naslov galerije), content (vsebina oz. opis galerije), commenton (vklop/izklop

komentarjev galerije), front_file_name (ime datoteke naslovne slike), front_content_type (tip

datoteke), front_file_site (velikost datoteke) in front_updated_at (čas zadnje spremembe

datoteke).

comments

+id: integer+commenter: string+body: text+post_id: integer+gallery_id: integer+image_id: integer+created_at: datetime+updated_at: datetime

statics

+id: integer+name: string+permalink: string+content: text+created_at: datetime+updated_at: datetime+position: integer

galleries

+id: integer+title: string+permalink: string+content: text+commenton: boolean+created_at: datetime+updated_at: datetime+front_file_name: string+front_content_type: string+front_file_size: integer+front_updated_at: datetime+delta: boolean

images

+id: integer+title: string+permalink: string+content: text+commenton: boolean+gallery_id: integer+created_at: datetime+updated_at: datetime+photo_file_name: string+photo_content_type: string+photo_file_size: integer+photo_updated_at: datetime+position: integer+delta: boolean

settings

+id: integer+var: string+value: text+created_at: datetime+updated_at: datetime

links

+id: integer+name: string+link: string+description: text+created_at: datetime+updated_at: datetime

users

+id: integer+username: string+email: string+crypted_password: string+password_salt: string+persistence_token: string+created_at: datetime+updated_at: datetime

posts

+id: integer+title: string+content: text+commenton: boolean+author: string+created_at: datetime+updated_at: datetime+delta: boolean+permalink: string

user_sessions

+id: integer+username: string+password: string+created_at: datetime+updated_at: datetime

themes

+id: integer+name: string+permalink: string+created_at: datetime+updated_at: datetime+head_file_name: string+head_content_type: string+head_file_size: integer+head_updated_at: datetime+footer_file_name: string+footer_content_type: string+footer_file_size: integer+footer_updated_at: datetime+background_file_name: string+background_content_type: string+background_file_size: integer+background_updated_at: datetime+background_color: string+head_color: string+footer_color: string+links_color: string+text_color: string+head_links_color: string+footer_text_color: string+h1_color: string+h2_color: string+frames_color: string+headon: boolean+backgroundon: boolean+footeron: boolean+detail_color: string+page_title_color: string+page_title_image_file_name: string+page_title_image_content_type: string+page_title_image_file_size: integer+page_title_image_updated_at: datetime+pagetitleon: boolean

1..*

1..*1..*

1..*

27

5.2.2.2 Slika

Slika (»Image«) je podatkovna struktura slik, ki so del galerij. Njeni atributi so: id (primarni

ključ slike), tittle (naslov slike), content (vsebina oz. opis slike), commenton (vklop/izklop

komentarjev slike), gallery_id (tuji ključ galerije kateri pripada slika), photo_file_name (ime

datoteke, tj. slike), photo_content_type (tip detoteke), photo_file_size (velikost slike) in

photo_updated_at (čas zadnje spremembe pripete slike).

5.2.2.3 Članek

Članek (»Post«) je podatkovna struktura členkov bloga oz. novic. Vsebuje atribute: id

(primarni ključ članka), title (naslov članka), commenton (vklop/izklop komentarjev članka)

in author (avtor članka).

5.2.2.4 Komentar

Komentar je podatkovna struktura, ki predstavlja oddane komentarje obiskovalcev spletne

strani. Vsebuje atribute: id (primarni ključ komentarja), commenter (komentator oz. avtor

komentarja), body (vsebina komentarja), post_id (tuji ključ komentiranega članka), image_id

(tuji ključ komentirane slike) in gallery_id (tuji ključ komentirane galerije).

5.2.2.5 Tema

Tema (»Theme«) je podatkovna struktura, ki hrani vse podatke o izgledu spletne strani.

Osnovni atributi tem so: id (primarni ključ teme), name (ime teme), headon (vklop/izklop

ozadja glave), backgroundon (vklop/izklop ozadja spletne strani), footeron (vklop/izklop

ozadja noge) in pagetitleon (vklop/izklop prikaza logotipa spletne strani). Atributi, ki določajo

barve posameznih delov spletne strani so naslednji: background_color (barva ozadja),

head_color (barva ozadja glave), footer_color (barva ozadja noge), links_color (barva

povezav), text_color (barva besedila), head_links_color (barva povezav v glavi),

footer_text_color (barva besedil v nogi), h1_color (barva naslovov tipa h1), h2_color (barva

naslovov tipa h2), frames_color (barva okvirjev in obrob), detail_color (barva detajlov) in

page_title_color (barva naslova spletne strani). Ozadja glave (head), logo strani

(page_title_image), noge (footer) in celotne spletne (background) strani pa imajo atribute:

file_name (ime datoteke, tj. slike), content_type (tip datoteke), file_size (velikost datoteke) in

updated_at (čas zadnje spremembe).

5.2.2.6 Uporabnik

Uporabnik (»User«) je podatkovna struktura prijavljenih uporabnikov oz. administratorjev.

Vsebuje atribute: id (primarni ključ uporabnika), username (uporabniško ime), email (e-poštni

28

naslov uporabnika), crypted_password (kriptirano geslo uporabnika) in persistance token

(žeton prijavljenega uporabnika, ki se hrani v piškotkih brskalnika).

5.2.2.7 Uporabniška seja

Uporabniška seja (»UserSession«) predstavlja sejo prijavljenega uporabnika. Vsebuje

atribute: id (primarni ključ seje), username (uporabniško ime uporabnika) in password (geslo

uporabnika).

5.2.2.8 Statična stran

Statična stran (»Static«) je zbirka statičnih strani. Njeni atributi so: id (primarni ključ statične

strani), name (ime statične stran) in content (vsebina statične strani).

5.2.2.9 Povezava

Povezava (»Link«) je podatkovna struktura, ki služi za seznam povezav. Vsebuje atribute: id

(primarni ključ povezave), name (ime povezave), link (povezava) in description (opis

povezave).

5.2.2.10 Nastavitve

Nastavitve (»Settings«) je podatkovna struktura osnovnih nastavitev spletne strani. Vsebuje

atribute: id (primarni ključ nastavitve), val (ime nastavitve) in value (vrednost nastavitve).

5.2.3 Koncept uporabniškega vmesnika Slike 5.4 do 5.12 prikazujejo koncept videza uporabniškega vmesnika spletne galerije »galx«.

Gre za skice vseh ključnih elementov aplikacije, ki služijo kot zgled pri implementaciji

vmesnika.

Indeksna stran omogoča obiskovalcu hiter pregled nad zadnje dodanimi vsebinami na vseh

področjih (slika 5.4). Slika prikazuje še videz klasične glave in noge, ki sta del ogrodja

spletne strani in sta vedno prisotna.

29

Slika 5.4: Koncept indeksne strani


Seznam slik je nanizan skupaj z naslovom v širini brskalniku prilagodljivega seznamu (slika

5.5). Administrator lahko tu dostopa do funkcij urejanja in brisanja posamezne galerije ter

ustvarjanja nove.

Slika 5.5: Koncept zbirke galerij


30

Prikaz posamezne galerije vsebuje njen naslov, opis in vsebujoče slike. Administrator lahko

tu dostopa do funkcij urejanja in brisanja galerije ter brisanja, urejanja in dodajanja slik.

Slika 5.6: Koncept prikaza galerije


Urejanje in kreiranje vsebin poteka za vse vsebine preko enakega uporabniškega vmesnika, z

razliko zgolj v potrebnih poljih in dodatnih nastavitvah (slika 5.7).

Slika 5.7: Koncept urejanja in kreiranja vsebin


Izgled slike je v običajnem formatu z naslovom, sliko in opisom (slika 5.8). V zgornjem

desnem kotu sta gumba za pomik naprej in nazaj po galeriji, pod njo pa so povezava nazaj,

uredi in briši.

31

Slika 5.8: Koncept prikaza posamezne slike


Članke bloga sestavlja naslov zgoraj, vsebina članka.

Izgled članka bloga je v običajnem formatu z naslovom, datumom objave, avtorjem in

vsebino ter številom oddanih komentarjev, če so le-ti omogočeni (slika 5.9). Administrator

lahko tu dostopa do funkcij urejanja, brisanja in ustvarjanja novega članka.

Slika 5.9: Koncept prikaza članka na blog-u


32

Možnost oddaje komentarja, ki se vključi pod vsako od vsebin, če je možnost teh omogočena

(slika 5.10). Obiskovalec mora vnesti svoje ime oz. psevdonim in vsebino komentarja. Izpisan

komentar ima v glavi naslov, pod naslovom pa vsebino.

Slika 5.10: Koncept komentiranja vsebin


Administrator dostopa do dodatnih funkcionalnosti preko prijavnega obrazca (slika 5.11).

Slika 5.11: Koncept prijavnega obrazca


Administrator lahko dostopa do dveh nadzornih plošč, nastavitve uporabnikov in nastavitve

strani. Izgled obeh je v osnovi enak (slika 5.12). Nastavitve uporabnikov vsebujejo naslednje

jezičke: nastavitve, statične strani, komentarji in teme. Nastavitve uporabnikov pa vsebujejo

jezička: nastavitve uporabnika in uporabniki.

33

Slika 5.12: Koncept nadzorne plošče


5.3 Časovni načrt V tabeli 5.2 so navedene vse aktivnosti, potrebne za izvedbo projekta Spletna galerija »galx«.

Slika 5.13 prikazuje celoten časovni načrt, ki je bil predviden za realizacijo projekta.

Tabela 5.2: Tabela aktivnosti

1. Načrtovanje

2. Implementacija 2.1 Implementacija galerije

2.2 Implementacija slik

2.3 Implementacija novic (bloga)

2.4 Implementacija komentarjev

2.5 Implementacija statičnih strani

2.6 Implementacija povezav

2.7 Implementacija indeksne strani

2.8 Implementacija nastavitev strani

2.9 Implementacija zaščite

2.10 Implementacija nastavitev uporabnika

2.11 Implementacija tem

2.12 Implementacija iskanja

3. Testiranje 3.1 Funkcionalno testiranje

3.2 Testiranje integracije

3.3 Sistemsko testiranje

3.4 Testiranje enot

34

4. Namestitev (postavitev na splet)


Slika 5.13: Časovni načrt


6 IMPLEMENTACIJA Implementacija se začne z generiranjem novega Ruby on Rails projekta. Rails skripta poskrbi

za kreiranje vsega potrebnega za začetek pisanja kode. Generira tri različne tipe okolij:

razvijalno, produkcijsko in testno. Vsako od njih predstavlja eno od faz razvoja Rails

aplikacije. Razvijalno okolje je namenjeno za uporabo pri implementaciji aplikacije. Ob vsaki

poizvedbi brskalnika se avtomatično posodobi koda ne da bi bilo potrebno strežnik ponovno

zagnati. Prav tako je vključena možnost uporabe razhroščevalca in izključenega pomnjenja

(Railsguides).

6.1 Priprava sistema Preden začnemo z implementacijo je potrebno še konfigurirati podatkovno bazo MySQL, ki

ni privzeta, in namestiti nekatere gem-e, ki pripomorejo k hitrejši in enostavnejši

implementaciji.

35

6.1.1 Compass Compass je orodje za ustvarjanje izgleda spletne strani. Za pisanje slogov uporablja jezik

Sass, ki pripomore k temu, da je koda stilov krajša, bolj pregledna in posledično jo je lažje

vzdrževati. Compass ponuja najboljše elemente različnih CSS platform, ki se lahko uporabijo

brez uporabe njihovih razrednih imen, med drugimi tudi Blueprint, ki omogoča organiziranje

CSS div-ov vi mrežo (Conpass).

6.1.2 Haml/Sass Haml in Sass sta označevalna jezika, ki sta del Hanl gem-a, katerega je potrebno namestiti

skupaj z Compass-om. Haml opisuje HTML kodo spletne strani, medtem ko Sass opisuje

CSS. Jezika imata sintakso, ki omogoča pisanje krajše in predvsem preglednejše kode (Haml,

Sass).

6.1.3 Haml-scaffold Rails Scaffolding je hiter način za generiranje nekaterih večjih delov aplikacije. Hkrati lahko

generira model, view in controller za vnešene parametre. Haml-scaffolding je alternativa

privzetemu scaffolding sistemu, ki predstavitveni del (view) generira v jeziku haml.

Generirani seznami elementov že vsebujejo odstranjevanje z gem-om Will_paginate. Poleg

osnovne kode generira tudi testno kodo v jeziku Mocha (haml-scaffold).

6.1.4 Will_paginate Will_paginate je gem, ki omogoča odstranjevanje seznamov posameznih elementov spletne

strani. Nastavitev in uporaba sta zelo preprosti, saj zahtevata zgolj dve vrstici kode (Will

pagiante).

6.1.5 Mocha Mocha je jezik, ki se uporablja pri pisanju testov. Združljiv je z veliko testnimi platformami

kot so: Test::Unit, RSpec, test/spec, expectations, Dust, MiniTest in JtestR (Mocha).

6.1.6 FCKeditor Ima svoj sistem za nalaganje slik, te pa lahko dodamo tudi iz drugih virov izven strežnika.

6.1.7 Paperclip Paperclip je preprost sistem za pripenjanje datotek z ActiveRecord-om. Ustvarjen je bil z

namenom čim preprostejše namestitve in da se lahko datoteke tretira tako kot ostale atribute.

Datoteke se shranijo šele potem, ko je bila enota shranjena v ActivRecord-u. V podatkovni

http://www.ruby-doc.org/core/classes/Test/Unit.htmlhttp://rspec.info/http://chneukirchen.org/repos/tests

Documents

D I P L O M S K A N A L O G A - Milovan Tomaševićdk.fis.unm.si/dip/UN_2010_Peter_Grilj.pdffakulteta za informacijske Študije v novem mestu . d i p l o m s k a n a l o g a . univerzitetnega