Poglavje 2 LP Spletna aplikacija na strani strežnika

LP

2.1 Pravila, zahteve in omejitve

Osrednji cilj vaj je pomoč pri razvoju lastnega projekta (LP), kjer boste na poljubno izbrani problemski domeni razvijali spletno aplikacijo od začetka do delujoče različice. Na vajah bodo potekale predvsem konzultacije glede razvoja lastnega projekta, zagovor lastnega projekta in prikaz uvodnih primerov ter orodij, ki jih boste uporabljali pri izdelavi lastnega projekta.

Pri izbiri ideje za vaš projekt je priporočeno, da se posvetujete z asistentom na vajah, da vam tematiko odobri in vas pravilno usmeri glede težavnosti projekta. V naslednjem poglavju 2.2 je priložen tudi seznam idej, ki ga lahko uporabite kot izhodišče pri oblikovanju lastne ideje.

Opomba: Vsi udeleženci morate oddati GitHub uporabniške račune, da pridobite dostop do lastnega repozitorija (LP-<vaš-GitHub-račun> v okviru organizacije UL-FRI-DevOps-WebDevelopment), na katerem boste delali!

1. LP Dinamična spletna aplikacija na strani strežnika in odjemalca je sestavljen iz štirih delov, ki jih opravljate zaporedno v skladu s terminskem planu izvajanja tečaja:

• 1. del - osnutek aplikacije in wireframe model,
• 2. del - arhitektura aplikacije in različna razvojna okolja,
• 3. del - zaledni del in dostop do podatkovne baze.

Povzetek funkcionalnih zahtev je prikazan na sliki 2.1, medtem ko so podrobnosti za vsak posamezen del lastnega projekta na voljo v nadaljevanju.

Slika 2.1: Povzetek funkcionalnih zahtev LP (večja slika)

Nalogo boste oddali v elektronski obliki preko elektronske pošte (povezava na zadnjo uveljavitev), sistema Github in povezave na delujočo aplikacijo.

Na zagovoru boste predstavili stanje v oddanem repozitoriju izvorne kode, kjer se bo upoštevalo stanje uveljavitve, ki je bila oddana preko elektronske pošte.

2.2 1. del Osnutek aplikacije in wireframe model

Navodila za 1. del

Za 1. del lastnega projekta si boste zamislili projekt, na katerem boste delali skozi vse dele LP. Na Github boste pridobili dostop do repozitorija v okviru katerega boste opravljali lastni projekt. Repozitorij bo zaseben in dostopen zgolj vam. Izvajalci pri predmetu bodo imeli na repozitoriju administratorske pravice.

V repozitoriju že imate mapo z imenom docs, kamor boste shranili rezultate 1. dela. Za vsak pogled, ki ga boste izdelali v okviru lastnega projekta, morate pripraviti po eno zaslonsko masko, ki jo shranite v eni izmed oblik in sicer:

• ločena HTML datoteka ali
• slika wireframe modela (npr. JPG, PNG,..).

Za vsako zaslonsko masko je potrebno tudi opisati njene funkcionalnosti po alinejah, da vam bo olajšalo kasnejšo implementacijo zalednega dela. Bootstrap ogrodja v okviru tega tečaja ne bomo uporabljali.

V skladu z vašim lastnim projektom izdelate zaslonske maske vsaj sledečih tipov:

• prijava/registracija uporabnika,
• dodajanje elementa,
• izpis seznama elementov in master/detail vzorec,
• brisanje elementa,
• pregled in urejanje elementa,
• iskanje,
• integracija aplikacije z zunanjim virom (lahko nadgradite eno izmed obstoječih zaslonskih mask).

Posamezen pogled lahko vključuje različne zaslonske maske.

V korenski mapi repozitorija v datoteki README.md na kratko opišite vašo aplikacijo (glejte primere opisov projektov v nadaljevanju) in v dokument vključite povezave na zaslonske maske. Pri opisu vašega lastnega projekta naj le ta vključuje nekatere od sledečih funkcionalnih zahtev:

• več uporabniških vlog in/ali različnih pogledov in/ali funkcionalnosti,
• zaželena implementacija ali integracija naprednejših funkcionalnosti z namenskimi knjižnicami ali ogrodji, kot primer:
  • e-mail obveščanje pri registraciji ali ob drugih akcijah,
  • predstavitev podatkov tudi z grafi,
  • zemljevidi,
  • napredne HTML komponente,
  • autocomplete,
  • generiranje poročil,
  • drag & drop funkcionalnosti,
  • zoom komponenta območja velikih slik idr.
• pregled nad potekom določenih aktivnosti naj bo razvidna v zgodovinskem pregledu,
• možnosti interakcije med uporabniki (npr. klepet, komentarji, ocenjevanje), seveda če je to smiselno za izbran lastni projekt.

Del izbranih zahtev bo implementiran na strani strežnika v okviru tega tečaja, funkcionalnosti odjemalca pa na naslednjem tečaju, ki se osredotoča na odjemalsko vsebino.

Primeri opisov projektov

Interaktivno orodje naprednih oblačnih rešitev

Vaš stric Zvonko Merlak razpolaga z izjemno kompleksno računalniško rešitvijo. Ker se je naveličal interakcije preko ukazne lupine, si je zaželel interaktivno spletno aplikacijo. Ta naj omogoča agregacijo posameznih oblačnih komponent (npr. Microsoft Azure Components) v oblačne arhitekture. Nenazadnje spletno orodje omogoča pripravo arhitekture lastnega projekta.

Izdelajte spletno aplikacijo, ki omogoča najmanj:

• drag & drop interakcijo oblačnih komponent,
• napredno iskanje po oblačnih arhitekturah,
• registracijo novega uporabnika,
• komentiranja oblačne arhitekture,
• vidljivost arhitekture med posameznimi uporabniki ali tipi uporabnikov,
• vizualizacijo podatkov sistema v administratorskem pogledu (npr. najpogosteje uporabljene komponente v oblačnih arhitekturah) in
• ustvarjanje novih komponent.

Generična kripto menjalnica kriptoFRI

Vaš bratranec Zvonko Merlak je naveličan kripto menjalnic, ki omogočajo le izmenjavo kriptovalut preko že vnaprej definiranih parov (npr. med Bitcoin in Ethereum ter obratno). Ker ima Zvonko že pripravljene varne kripto denarnice, vas je prosil, da mu pripravite generično kripto menjalnico. Ta naj omogoča, da ima vsak običajen uporabnik možnost dodajanja svojih najljubših kriptovalut v denarnico preko zaslonske maske in možnost dodajanja naročil za vse poljubne pare kriptovalut, ki jih imajo ostali uporabniki v platformi. Naročila lahko sprejema vsak uporabnik, ki ima dovolj sredstev in se s ceno strinja. Od vsakega izvedenega naročila naj kripto menjalnica vzame ugodno provizijo (npr. 0.05%) od uporabnika, ki je naročilo ustvaril.

Za najzahtevnejše uporabnike naj sistem omogoča VIP račun pri čemer lahko takšni uporabniki vidijo kdo je naročilo ustvaril ter omogoča pošiljanje sporočil, ki so vezana na naročila in zasebna sporočila uporabnikom nasploh.

Kot skrbnik sistema naj omogoča tudi administratorski pogled, ki omogoča pregled nad kriptovalutami, ki se nahajajo v kripto menjalnici, poljubne statistične podatke ter zanimive podatke cenovnih trendov (npr. trenutna ter pretekle cenovne vrednosti).

Izdelajte spletno aplikacijo, ki omogoča najmanj:

• registracijo novega uporabnika,
• prijavo in odjavo uporabnika,
• dodajanje kriptovalut v sistem na nivoju uporabnika,
• dodajanje preprostih naročil in izvedbo naročil z ustreznim obveščanjem obeh akterjev ob izvedbi naročila (npr. želim prodati 1 Bitcoin za 100.000 EUR),
• pošiljanje sporočil in komentiranje,
• vizualizacijo statističnih podatkov sistema v administratorskem pogledu.
• Pomislite tudi na kakšne zanimive funkcionalnosti z dodano vrednostjo uporabnikom VIP računa.
• Pripravite preprosto izmenjavo kriptožetonov na podlagi na podlagi podatkov izven verige trenutne vrednosti kriptovalute ali kriptožetona, kjer uporabimo pristop pametnih prerokov⁴⁶ ChainLink (ZAHTEVNEJŠE!).

Zgledujte se lahko po spletnih platformah Bitstamp, Binance, Kraken, …

e-Študent

Vaš stric Jovo je novopečeni dekan fakultete za raziskovanje rude in zapravljanje časa. Na fakulteti, kjer je časa na pretek, še niso osvojili informacijskih tehnologij, zato celotno študijsko informatiko vodijo kar na papirju. Vsak študent ima v referatu svoj kartotečni list, ki še najbolj spominja na kopijo študentskega indeksa. Vsak študent ima tudi svoj indeks, v katerega se vpisujejo ocene opravljenih predmetov. Če se želi ubogi študentTM prijaviti na izpit, pa mora izpolniti papirnato prijavnico in le-to dostaviti v referat na fakulteto. Podobno mora storiti tudi za odjavo od izpita.

Ker ste nad informacijsko tehnologijo navdušeni, mu pomagajte pri informatizaciji njegove fakultete. Izdelajte spletno aplikacijo, ki bo omogočala najmanj:

• prijavo in odjavo iz izpita,
• razpisovanje izpitnega roka,
• vnos ocen za posamezni izpitni rok,
• hrambo in pregled ocen opravljenih izpitov,
• pregled elektronskega indeksa oz. kartotečnega lista,
• pregled izpitnih rokov z odprtimi prijavami.
• Ne pozabite na to, da uporabniki aplikacije e-Študent nastopajo v različnih vlogah. To pomeni, da bo aplikacija za profesorja izgledala drugače kot za študenta ali za študentski referat.
• Plačevanje opravljanja študijskih obveznosti (npr. vaj brez statusa študenta, komisijskih izpitov, vpisnine) naj bo omogočena s pomočjo kriptovalut ali kriptožetonov z možnostjo vpogleda v plačila s strani skrbnika sistema.

Spletna učilnica

Novica o tem, da Ladislava in Jovo na veliko informatizirata svoji šoli je prebudila vaš podjetniški duh. Zakaj ne bi izdelali spletne učilnice, ki bi jo lahko prodali kar obema… Pozabite na odprtokodni Moodle, prepričani ste, da lahko pripravite boljši izdelek.

Vaša spletna učilnica mora omogočati najmanj:

• dodajanje predmetov,
• dodajanje gradiv (besedilo, spletne povezave, različni dokumenti, predstavitve, …) v predmet,
• objavo nalog (besedilo) in oddajanje rešenih nalog (nalaganje datoteke),
• ocenjevanje nalog.
• Seveda lahko razmislite še o drugih aktivnostih (forum, kviz, …), ki jih sicer nudijo sodobne spletne učilnice. Ne pozabite, da mora vaša spletna učilnica ločiti med vlogami skrbnik, učitelj in dijak oz. študent.
• sistem naj omogoča glasovanje s pomočjo DApps pristopa.

Kalkulator življenjskih stroškov

Vsi poznate situacijo. Nekje sredi meseca je denarnica prazna, niste pa točno prepričani, kam je izginil vaš denar. Stanje na vašem računu ravno tako ni rožnato, kljub temu pa bi radi zimske počitnice izkoristili za oddih v toplih krajih. Guruji varčevanja, avtorji knjig kako postati milijonar in na sploh tisti, ki mislijo, da je obrestno-obrestni račun magično sredstvo, ki omogoča iz nič ustvarjati milijone, se prav vsi strinjajo, da je začetek vsakega varčevanja vsekakor nadzor naših izdatkov.

Napišite spletno aplikacijo, ki bo uporabnikom omogočala:

• vodenje stanja na različnih računih (npr. transakcijski račun, varčevalni račun, denarnica),
• vnašanje izdatkov,
• kategoriziranje izdatkov (npr. izdatki za avto, študij, zabavo, hrano),
• pripravo različnih poročil (npr. pregled izdatkov po kategorijah, spreminjanje izdatkov po mesecih, …) in
• omogočen vpogled v porabo kriptovalut z možnostjo varčevanja (npr. prenos v varčevalno denarnico) po DApps pristopu.

Vaša aplikacija naj omogoča tudi nastavljanje ciljev (npr. privarčevati vsaj 100 EUR mesečno ali privarčevati 1000 EUR do junija 2012) in seveda spremljanje izpolnjevanja teh ciljev.

Zgledujete se lahko po programih GNUCash, Quicken, Toshl, …

Obračun potnih stroškov

Žena sestričnine tete Genovefa ima srednje veliko podjetje, kjer zaposleni dosti potujejo po različnih konferencah po svetu. Trenutno poteka proces obračuna stroškov povezanih s službeno potjo nekako takole:

Zaposleni pred odhodom izpolni obrazec za odobritev službene poti. Na obrazcu mora napisati, kam in kdaj potuje. Označiti mora tudi, ali želi za službeno pot prejeti predujem. Njegov nadrejeni mora službeno pot v danih terminih potrditi (lahko jo seveda tudi zavrne in/ali predlaga spremembe). Če je pot odobrena, potem prejme zaposleni potni nalog. Zaposleni vse (upravičene) stroške povezane s potjo dodaja na potni nalog. Ko se zaposleni vrne, odda potni nalog v računovodstvo. Računovodstvo oddano pregleda in odobri ali zavrne posamezne stroške. Odobreni stroški se zaposlenemu povrnejo na TRR. Pri vračilu stroškov je potrebno preveriti, ali je zaposleni že dobil predujem in seveda ustrezno vrednost odšteti. Vaša spletna aplikacija naj podpre opisani proces. Posebno pozornost namenite dodajanju nastalih stroškov na potni nalog. Upoštevajte, da lahko dodajamo stroške prevoza (letalska vozovnica, taxi, rent-a-car, …), stroške bivanja (hotel, motel, …), stroške prehrane (to sicer zajema dnevnica, ampak ni treba komplicirati s tem). Pomislite tudi na to, da je za nastale stroške potrebno oddati dokazila (slika oz. scan računa, vozovnice, …).

Ne pozabite tudi, da imajo različni zaposleni različne vloge v procesu ustvarjanja, potrjevanja in obračuna potnega naloga.

Tehnična podpora

Rajmund pravi, da bi bil IT precej lepši, če ne bi bilo uporabnikov. Kljub temu pa se zaveda, da je dobra podpora uporabnikom ključna za dolgoročni uspeh. Trenutno so njegove stranke s podporo še kar zadovoljne, saj jim je uspelo dobiti direktne telefonske številke strokovnjakov, ki delajo na različnih rešitvah v Rajmundovem podjetju. Kljub temu, da sistem deluje, pa se strokovnjaki pritožujejo, da večino svojega delovnega časa porabijo za reševanje trivialnih problemov (ste poskusili ponovno zagnati računalnik). Zato se je Rajmund odločil, da vzpostavi službo za pomoč uporabnikom, ki bo temeljila na pridnih študentih, vsaj delno pa bo razbremenila njegove strokovnjake. Seveda pa ne bo šlo brez aplikacije, ki bo v pomoč vsem, ki sodelujejo pri reševanju incidentov.

Izdelajte spletno aplikacijo za podporo tehnične podpore ;-) Rajmund si je proces tehnične podpore zamislil nekako takole:

• Stranka v spletno aplikacijo vnese zahtevo za podporo z opisom napake (če je stranka poklicala po telefonu, bo opis napake zabeležil vestni študent, ki je prevzel klic). Vsak opis napake oz. incident dobi svojo številko za sledenje.
• Eden od sodelavcev v službi za pomoč uporabnikom (t.i. 1^st level support ali ubogi študent pregleda opis napake in skuša podati rešitev. Če rešitve ne more podati, prosi stranko za dodatne podatke.
• Če incidenta ni mogoče rešiti na 1. nivoju podpore, se poviša prioriteta incidenta, kar pomeni, da se z incidentom začnejo ukvarjati strokovnjaki (t.i. 2^nd level support). Strokovnjaki lahko od stranke zahtevajo dodatne podatke.
• Ko je incident rešen, to potrdi stranka.
• Stranka lahko kadarkoli ponovno odpre obstoječi incident, če se npr. napaka ponovi.
• Uporabniki aplikacije imajo različne poglede na reševanje incidenta. Določite ustrezne vloge za stranko, prvi nivo podpore in strokovnjake.
• Skrbnik tehnične podpore s pomočjo DApps principa stanje napake beleži povsem decentralizirano. Stranka ima možnost spremljanja stanja napake na svoji uporabniški strani.

Organizacija konference

Vaš najljubši profesor dr. Zmeda organizira mednarodno konferenco z delovnim imenom Kako raziskovati rudo in ne izgubljati časa. Seveda pa organizacija konference ni kar tako, na vsak način pa je celoten dogodek potrebno tudi informacijsko podpreti.

Dr. Zmeda je v vsej svoji zmedenosti spletno aplikacijo opisal nekako takole…

Avtorji prispevkov morajo svoje prispevke oddati do določenega datuma. Po tem datumu gredo prispevki v recenzijo skupini urednikov. Vsak prispevek morajo pregledati vsaj trije uredniki. Vsak izmed urednikov lahko poda svoje komentarje na prispevek, poleg tega pa lahko prispevek sprejme, zavrne ali pa pogojno sprejme. Če je prispevek samo pogojno sprejet, ga mora avtor popraviti do določenega roka, nato pa gre ponovno v pregled (lahko drugim urednikom).

Sprejeti prispevki sestavljajo program, ki je prikazan na spletni strani konference. Predavanja lahko hkrati potekajo v različnih predavalnicah. Pri pripravi programa je potrebno paziti, da ne damo istega avtorja hkrati ob isti uri v dve različni predavalnici. Pri pripravi programa moramo paziti tudi na dodatne omejitve kot so čas kosila, čas odmorov, čas nedosegljivosti predavalnic, ipd.

Prijava na dogodke

Dr. Zmeda organizira konferenco, as. Krevl šušlja o nekem varnostnem dogodku, govori se tudi o poletnih šolah za študente in vaša podjetniška žilica vam spet ne da miru. Vse našteto so primeri dogodkov… in organizatorji dogodkov ponavadi potrebujejo sisteme, ki omogočajo udeležencem, da se na dogodek prijavijo.

Napišite spletno aplikacijo, ki bo organizatorjem olajšala delo. Spletna aplikacija naj omogoča objavo programa dogodka. Upoštevajte, da lahko dogodek traja tudi več dni. Pri programu omogočite enostaven prenos v koledarske aplikacije. Ne pozabite na objavo lokacije, ki je lahko integrirana v kakšnega od spletnih zemljevidov. Udeležencem omogočite prijavo dogodkov. Ne pozabite tudi na možnost odpovedi udeležbe. Zagotovite podporo tako za dogodke, ki so brezplačni, kakor tudi za plačljive dogodke. Upoštevajte, da je prostor, kjer organiziramo dogodek pogosto omejene velikosti, zato omogočite tudi omejitev števila prijav. Ko se uporabnik uspešno prijavi na dogodek, lahko natisne e-vstopnico. Razmislite, kako rešiti problem ponarejanja vstopnic.

S pomočjo DApps principa je omogočena monetizacija za plačilo plačljivih dogodkov.

Dokumentni sistem

Vaš najboljši prijatelj Vladko, ki ni sosed od Žmauca, ima Majhno podjetje d.o.o. Ugotovil je, da se vsak dan srečuje z različnimi dokumenti, ki so sicer shranjeni na nekem skupnem disku, vendar pa bi jim koristili kakšni dodatni podatki.

Napišite spletno aplikacijo, ki bo ustrezala spodnjim zahtevam:

Skenirani dokument se doda v spletno aplikacijo, takrat se mu doda tip, datum skeniranja in druge meta podatke. Mogoče je dodajati nove tipe dokumentov. Vsako spremembo ali dodatek metapodatkov k dokumentu je potrebno zabeležiti in prikazati skupaj z dokumentom. Zabeležiti je treba tudi dostop do dokumentov. Za vsak tip dokumenta lahko določimo pravice - kdo ima dostop, kdo lahko ureja metapodatke, … Za vsak tip dokumenta je mogoče določiti proces potrjevanja. Npr. vsak račun mora potrditi direktor, šele nato ga vidijo v računovodstvu, prošnjo za izdajo potnega naloga ali za dopust pa mora odobriti neposredno nadrejeni. Vsakemu dokumentu dodelite avtorstvo na podlagi funkcije razpršitve⁴⁷ s pomočjo DApps pristopa, kjer je jasno razvidno kdo je izvirni avtor dokumenta.

Naročila

Vaš stric Jovo s fakultete za raziskovanje rud in zapravljanje časa je ugotovil, da je e-Študent res super stvar, vendar pa birokracija omejuje tudi njegove zaposlene. Področje, ki ga zaposleni nenehno kritizirajo, je naročanje opreme in drobnega inventarja. Na papirju izgleda proces takole:

• Zaposleni, ki želi kupiti svinčnik (ali prenosnik), izpolni obrazec N-1, na katerem napiše, kakšno opremo želi kupiti, šifro sredstev, iz katerih naj fakulteta financira nakup, in vrednost nakupa.
• Obrazec mora najprej potrditi nosilec šifre sredstev (ponavadi neposredni nadrejeni). Če je nosilec sredstev zaposleni sam, lahko tudi obrazec potrdi kar sam.
• Obrazec se posreduje računovodstvu, ki mora potrditi, ali je na navedeni šifri sredstev dovolj denarja za nakup.
• Obrazec se posreduje nabavnemu referentu, ki izvede naročilo.
• Ko naročeno blago prispe na fakulteto, se mu dodeli inventarna številka (tu bomo svinčnik obravnavali enako kot prenosnik, čeprav svinčnik načeloma ne dobi inventarne številke).
• Zaposleni potrdi prejem nabavljenega skupaj z inventarno številko in sporoči lokacijo kupljene opreme (npr. LRK).

Napišite spletno aplikacijo, ki podpira opisani proces. Pazite na različne vloge, ki nastopajo v procesu.

Za izboljšanje transparentnosti naročanja naj bo stanje naročanja na voljo preko DApps pristopa.

GadgetFreak

Vaša prijateljica Rozina ima idejo, kako združiti vse ljubitelje takšnih in drugačnih elektronskih naprav, po domače gadgetov. Rada bi naredila neke sorte družbeno omrežje, kjer si bodo lahko lastniki različnih naprav izmenjali izkušnje. Rozina ima samo eno težavo… ne ve prav nič o spletnem programiranju. Pomagajte ji narediti spletno aplikacijo, ki bo omogočala vsaj naslednje:

• registracijo novega uporabnika,
• dodajanje nove naprave (npr. iPhone),
• dodajanje tehničnih lastnosti naprave,
• dodajanje slik naprave,
• dodajanje preizkusov naprave,
• forum za vsako napravo (dodajanje teme, odgovori),
• komentarji uporabnikov, kjer je to smiselno,
• ocenjevanje komentarjev na podlagi kriptožetonov po DApps principu, kjer se uporabnikom gradi ugled na platformi.

Vprašanja in odgovori

Kljub poplavi podobnih spletnih strani se je vaš prijatelj Vladko odločil, da svet potrebuje še eno spletno stran, kjer lahko ljudje postavijo vprašanja na katera jim drugi uporabniki spletne strani odgovarjajo. Seveda si je Vladko zadevo zamislil po svoje, ker pa nima pojma o spletnem programiranju, mu morate pri izvedbi pomagati vi.

Vse svoje ideje je Vladko napisal na papirnato servieto, mnenja o tem, ali so na teh servieti tudi ostanki Vladkovega kosila, pa ostajajo deljena. Servieta torej pravi:

Stran mora omogočati, da vprašanja postavimo tudi anonimno. Odgovori morajo biti nekako točkovani (I like, +1), bolje točkovani odgovori se morajo prikazati višje. Spraševalec lahko za posamezni odgovor označi, ali je ta odgovor rešil njegov problem. Vsako vprašanje in odgovor je možno komentirati.

Družabno omrežje

Vladkov prijatelj Radko ugotavlja, da je sit socialnih omrežij, ki so jih zasnovali Američani, in da je čas za nekaj popolnoma drugačnega.

Ideja je torej znana. Naredimo svoj profil. Ne pozabimo, da je Radko obseden z varnostjo, zato lahko za prav vsako vrstico besedila nastavljamo, kdo jo bo videl in kdo ne. Potem dodamo kakšno sliko, poiščemo prijatelje, jih dodamo v kroge, skupine ali gnezda. Poleg slik lahko objavljamo tudi krajše zapise besedila in spletne povezave. Kot je bilo že omenjeno, lahko za vsako objavo nastavljamo, kdo vse jo lahko vidi.

Poskusite se v igri socialnih omrežij in pomagajte Radku, da postane naslednji Marko Sladkorček.

Spletni koledar

Jožetov bratranec je zadnje čase vse bolj nezadovoljen s koledarjem, ki ga ponuja Google. Jože se je odločil, da bo temu negodovanju naredil konec tako, da bo razvil svoj spletni koledar. Ker je Jože moral nujno na službeno pot, mu morate seveda pomagati vi.

Jožetov bratranec pravi, da mora zanj koledar imeti naslednje funkcionalnosti:

• vsak uporabnik mora imeti svoj koledar,
• obstajati mora način za dajanja dogodkov iz koledarja v skupno rabo,
• obstajati morajo skupni koledarji, ki so na voljo vsem,
• “ločljivost koledarja” mora biti na 5 minut (to pomeni, da je možno dogodke dodajati npr. od 9:00 do 9:05),
• dogodek, ki ga dodamo na koledar, mora vsebovati podatke o imenu dogodka, lokaciji dogodka, začetku dogodka, koncu dogodka in morebitne dodatne opombe.
• cena dogodka naj se določi na podlagi podatkov izven verige in sicer API-ja vremena kjer uporabimo pristop pametnih prerokov ChainLink (ZAHTEVNEJŠE!).

Spletna trgovina

Hilda želi odpreti spletno trgovino in nikakor ne uspe najti primerne programske rešitve, ki bi se lepo vključila na slovenski trg. To, da Hilda ne zna prav dobro uporabljati Googla, pustimo ob strani… Med tem, ko postaja nakup glasbe prek spleta vse lažji, je Hilda prepričana, da se bodo plošče LP in CD še naprej dobro prodajale, zato bo njena spletna trgovina specializirana prav za ti dve vrsti artiklov.

Pomagajte ji narediti spletno trgovino, ki bo omogočala:

• dodajanje novega izdelka v katalog izdelkov,
• brskanje po izdelkih,
• iskanje izdelka (po izvajalcu, po imenu albuma, po imenu pesmi, …),
• dodajanje izdelka v košarico,
• naročanje izdelka,
• pregled in urejanje naročil,
• monetizacijo s kriptovalutami ali kriptožetoni po DApps principu.

Branje virov RSS

Zakaj uporabljati spletne aplikacije drugih, če lahko boljše naredimo sami? Ravno to se je vprašala Rozina, ko je prebrala še zadnjo današnjo novico na Slo-techu. Ker je po duši kuharica, je imela v glavi preprost recept:

• Prijavim se v spletno aplikacijo.
• Prikažejo se mi novice iz mojih virov RSS urejene po datumu.
• Pregledujem naslove in kratke opise novic, če najdemo kaj zanimivega, kliknem na povezavo in ta mi odpre novo okno brskalnika.
• Če mi je novica všeč, imam poleg prikazane novice gumbek, s katerim ji dodam glas.
• Če mi novica ni všeč, imam tudi za to ustrezen gumbek (ki ni enak tistemu za brisanje).
• Aplikacija vsakih n minut preveri za spremembe virov RSS in mi prikaže novosti.
• Če aplikacijo pogleda neprijavljeni uporabnik vidi zgodbe, ki so bile všeč največ uporabnikom.
• Pomagajte Rozini uresničiti njen recept.

Wiki

Wikiji so postali popularni predvsem na račun spletne enciklopedije Wikipedia. Vendar pa včasih nočemo kompleksnosti, ki jo ponuja platforma MediaWiki, na kateri temelji Wikipedia. Tako je razmišljal tudi naš znanec Rajmund. Zaželel si je preprost wiki, ki mu bo pomagal pisati dokumentacijo za njegovo spletno aplikacijo. Želi si seveda čim več bombončkov, ki jih nudijo sistemi Wiki in čim lažjo uporabo sistema.

Razmislite, katere lastnosti wikijev boste vključili v svojo spletno aplikacijo, da ta še ne bo prezahtevna za uporabo (in seveda administracijo).

Knjižnica

Genovefa ima doma kar precej veliko in zanimivo zbirko knjig. Kljub pojavu raznoraznih elektronskih bralnikov pa meni, da je ima papir še vedno svoj čar, pa pod mizo lažje podložiš knjigo kot pa Kindle. Genovefino zbirko knjig cenijo tudi njeni prijatelji, saj na ta način pridejo do prodajnih uspešnic prej kot v knjižnici. Žal pa si Genovefa bistveno bolje zapomni vsebino knjig kot pa osebo, ki si je neko knjigo izposodila.

Pomagajte ji iz zagate s spletno aplikacijo, ki bo še najbolj spominjala na knjižnico. Aplikacija naj omogoča vnos nove knjige (vsaka knjiga naj pri vnosu dobi svojo unikatno številko), lahko celo omogočite izpis nalepke oz. kartončka za posamezno knjigo.

Poleg tega naj aplikacija omogoča tudi beleženje evidence o izposoji (torej, kdo si je izposodil katero knjigo in kdaj). Zgodovina izposoj za posamezno knjigo naj se ohranja.

Genovefinim prijateljem pa omogočite iskanje po njeni zbirki knjig in pregled statusov (ali je posamezna knjiga izposojena ali ne).

Aplikacija naj ponuja tudi izpis različnih statistik (kdo si največkrat izposodi knjigo, kdo ima trenutno največ izposojenih knjig, …).

Aplikacija naj bo napisana tako, da bo omogočala tudi izposojo drugih reči (npr. CD-jev, orodja, …)

Ocenjevanje

Pri predmetu Spletno programiranje delamo v skupinah na 3 različnih projektih. Napišite spletno aplikacijo, ki bo asistentom poenostavila ocenjevanje vaših aplikacij.

Spletna aplikacija mora omogočati naslednje stvari:

• Skupinam naj omogoča dodajanje njihovega projekta. Vsak projekt mora imeti tudi povezavo, na kateri je dostopna delujoča koda. Vsaka naloga mora imeti tudi ustrezne metapodatke - imena članov skupine, ime projekta, platforma, …
• Aplikacija naj omogoča pripravo kriterijev za ocenjevanje. Za vsako oceno lahko določimo lestvico, ki jo bomo uporabili (zvezno/diskretno). Končno * oceno sestavlja več posameznih ocen. Posamezne ocene lahko združujemo s preprostimi matematičnimi formulami.
• Aplikacija naj omogoči, da posamezno oceno oddajo tako študenti kakor tudi asistent(a) in profesor.
• Aplikacija mora omogočati, da člani skupine ocenijo drug drugega (tudi da ocena je lahko sestavljena iz več posameznih ocen).
• Študentom naj omogoča ocenjevanje aplikacij. Ocene naj bodo diskretne: slabo, srednje, dobro, pri čemer lahko vsak študent izbere vsako od ocen natanko 14x.
• Ko asistent zaključi ocenjevanje, mora aplikacija omogočiti prikaz ocene vsakemu od udeležencev.
• Aplikacija naj za avtentikacijo uporablja univerzitetni imenik LDAP.
• Aplikacija naj posameznikom omogoča dodajanje komentarjev k oddani oceni.

Dobrodelni foto mozaik

Od gospe Zvonke smo dobili naslednjo prošnjo.

Kot umetnica premalo zaslužim za pokrivanje sprotnih stroškov in dostojno življenje. Zato delam različne donatorske akcije in zbiram sredstva za šolnino mojega sina in podobno. Med drugim sem zastavila projekt na internetu. Svojega sina sem razstavila v šestih različnih galerijah po Ljubljani. Sem naredila foto dokumentacijo. Iz te fotodokumentacije pa sedaj želim na internetu po koščkih zbirat donacijo.

Izbrala sem šest fotografij, iz vsake galerije po eno. To bi sedaj dala na internet in ljudje bi jih košček po košček aktivirali, s tem, ko bi donirali… slika bi bila skoraj nevidna, videni pa bi bili koščki-pravokotniki na sliki, ki se jih lahko izbere po želji. Izbran košček in skupaj z doniranjem, bi se košček aktiviral. Tako bi skupaj sestavljali mozaik.

Spletna aplikacija mora omogočati naslednje stvari:

• Predstavitev dobrodelnega projekta, objava novic
• Prikaz foto mozaika
• Izbira želenega koščka mozaika in donacija prek enega izmed online plačilnih storitev (Paypal, Scrill, BitPay) ali bančnih nakazil
• Administratorski pogled, kjer se nalagajo fotografije, preverjajo plačila in odkrivajo koščki mozaika
• Možnost komentiranja fotografij in novic
• Registracija na spletni strani ali prijava prek oauth (google, fb)
• S spletno aplikacijo boste v resnici pomagali sočloveku. Možna je tudi npr. razširitev ideje v komercialno platformo za zbiranje donatorskih sredstev (crowdfunding).

2.3 2. del Arhitektura aplikacije in različna razvojna okolja

Navodila za 2. del

V okviru 2. dela naloge boste vzpostavili arhitekturo vaše spletne aplikacije z uporabo načrtovalskega vzorca MVC, kjer ustrezno ločite posamezne komponente, kot so usmerjevalniki, krmilniki in modeli (struktura mape naj bo podobna strukturi, ki ste je spoznali na predavanjih).

Opomba: Pogledov na strani strežnika ne bomo razvijali, ker bomo v nadaljevanju pri naslednjem tečaju razvili odjemalsko aplikacijo v ogrodju Angular. S krmilniki in modelu pa se boste podrobneje ukvarjali v 3. delu naloge, kjer boste razvijali poslovno logiko na strani strežnika v obliki REST API storitev.

Začetna verzija aplikacija, ki jo bo vaš strežnik postregel, so zgolj statične datoteke iz osnutka aplikacije, ki ste jih razvili pri prejšnjem 1. delu naloge.

Vašo aplikacijo in podatkovno bazo objavite in naredite javno dostopno na oblačni infrastrukturi (npr. Fly.io, Render, Heroku, MongoDB Atlas idr.), kar naj predstavlja produkcijsko verzijo vaše rešitve. Za potrebe lokalnega razvoja in lažje prenosljivosti vzpostavite tudi lokalno verzijo aplikacije v okolju Docker, ki naj se v celoti vzpostavi samodejno zgolj z ukazom docker-compose up, kar naj poskrbi za zagon in nastavitev vseh potrebnih komponent vaše aplikacije.

Ob dostopu na korenski naslov vaše spletne strani (/) se lahko odpre začetna stran vaše aplikacije (statične HTML datoteke, pri naslednjem tečaju pa bo to odjemalska aplikacija). Povezavo do objavljene aplikacije navedite v datoteki README.md. V datoteki README.md prav tako vključite navodila z vsemi koraki, ki jih je treba izvesti, da se lahko vašo aplikacijo v okolju Docker zažene lokalno (pričakuje se zagon z ukazom docker-compose up, ki samodejno poskrbi za vse potrebne komponente). To vključuje tudi virtualizirano podatkovno bazo MongoDB.

V nadaljevanju boste v okviru 3. dela naloge dodali implementacijo REST API storitev ter v okviru naslednjega tečaja odjemalsko aplikacijo in boste poskrbeli za posodobitev lokalnega in produkcijskega razvojnega okolja.

2.4 3. del Zaledni del in dostop do podatkovne baze

Navodila za 3. del

3. del naloge zahteva implementacijo poslovne logike na strani strežnika z dostopom do podatkovne baze, objavo zahtevanih funkcionalnosti v obliki REST API storitev in dokumentiranje REST API vmesnika.

V okviru implementacije vaših funkcionalnosti na spletnem mestu npmjs uporabite vsaj dve dodatni knjižnici, ki vam bo bosta olajšali implementacijo ali vam nudili ustrezno podporno funkcionalnost (npr. pošiljanje elektronskih sporočil). Izbrani knjižnici naj ne bosta iz nabora knjižnic, ki smo jih uporabili na predavanjih oz. vajah (prav tako med te knjižnice ne štejeta swagger-jsdoc in swagger-ui-express, ki jih boste potrebovali pri dokumentaciji vmesnika). Namen uporabe izbrane knjižnice naj bo opisan v datoteki README.md.

Podatkovna baza

Izdelajte shemo podatkovne baze MongoDB, ki jo boste uporabljali. Shema mora vsebovati vsaj pet zbirk dokumentov, kjer morata biti vsaj dve odvisni. Preko vaše aplikacije mora biti možno dodajanje in brisanje vseh tipov dokumentov, kjer morajo biti te operacije izvedljive tudi iz spletne aplikacije.

Pri lokalnem zagonu aplikacije (npr. zagon aplikacije na lastnem računalniku oz. v okolju Docker) naj se uporabi lokalna podatkovna baza, medtem ko naj ista aplikacija ob zagonu v vašem oblačnem okolju samodejno uporabi vašo produkcijsko podatkovno bazo (npr. MongoDB Atlas). Na voljo naj bo tudi virtualizacija v okolju Docker, ki omogoča zagon vseh potrebnih komponent v lokalnem okolju (npr. z uporabo ukaza docker-compose up).

Zaradi lažjega testiranja in ponovne vzpostavitve začetnega stanja v vaši aplikaciji izdelajte spletno stran /db, kjer sta na voljo dve funkcionalnosti:

• izbris vsebine podatkovne baze, ki omogoča izbris vseh obstoječih podatkov iz podatkovne baze in
• vnos začetnih podatkov, ki omogoča vnos začetnih podatkov v podatkovno bazo - npr. seznam produktov, uporabniški računi, komentarji itd.

REST API storitve

Vaša aplikacija naj za dostop do podatkov v podatkovni bazi uporablja REST API pristop. Za vsak dostop do podatkovne baze v vaši aplikaciji uporabite smiselne metode, ki ustrezajo zahtevi (npr. PUT za posodabljanje dokumenta v podatkovni bazi, DELETE za brisanje obstoječega dokumenta v podatkovni bazi itd.) ter poskrbite za vračanje ustreznega odgovora in njegovega statusa.

Treba je zagotoviti tudi integriteto podatkov, ki jo preverjajte na različnih ravneh, in sicer:

• na ravni sheme, pred shranjevanjem podatkov z uporabo Mongoose,
• na ravni aplikacije, preden so podatki posredovani v podatkovno bazo na strani strežnika,
• na ravni odjemalca, preden so podatki obrazca posredovani na strežnik, kar boste implementirali v okviru naslednjega tečaja.

Posebej pozorni bodite na obvladovanje napak, saj morajo API-ji vračati ustrezna obvestila.

Dokumentacija REST API vmesnika

Za razvit REST API vmesnik morate pripraviti ustrezno dokumentacijo, ki naj bo v skladu z OpenAPI specifikacijo verzije 3.0. Obstoječim metodam REST API vmesnika dodajte dokumentacijo v obliki JavaScript komentarjev JSDoc ter uporabite Node.js knjižnico swagger-jsdoc, ki vam samodejno generira specifikacijo v obliki datoteke swagger.json. Nato s pomočjo knjižnice Swagger UI Express poskrbite za prikaz dokumentacije REST API vmesnika in možnost interaktivnega testiranja posameznih metod.

Datoteka swagger.json, ki predstavlja OpenAPI specifikacijo vašega REST API strežnika, naj bo na voljo na naslovu /api/swagger.json, medtem ko naj bo grafični vmesnik dokumentacije REST API strežnika objavljen na /api/docs/.

Dokumentacijo morate pripraviti za vse metode (tj. GET, POST, PUT in DELETE), vključno z vsemi parametri, ki so del spletnega naslova, del poizvedbe ali v telesu zahteve. Pri odgovorih morate vključiti vse možne rezultate, ki jih vaša metoda vrača, tj. vsaj 1 uspešen rezultat (npr. 200, 201, 204 itd.) in vsaj 1 neuspešen rezultat (npr. 400, 401, 404, 409, 500 itd.). Vsi vhodni in izhodni podatki morajo biti opredeljeni s shemo, kjer je razvidna struktura podatkov, vključno s primeri vrednosti.

Opomba: Dodajte tudi možnost uporabe JWT žetona za tiste metode, ki bodo zaščitene. Pri vseh teh metoda bo med rezultati morala biti na voljo tudi koda rezultata 401.

Avtentikacija in avtorizacija

Vaša aplikacija mora podpirati vsaj naslednje 3 vrste uporabnikov:

• neprijavljen uporabnik oz. gost,
• prijavljen uporabnik,
  • navaden uporabnik in
  • uporabnik administrator.

V datoteki README.md opišite razlike med uporabniki (dostop/spreminjanja pogleda) predvsem z vidika funkcionalnosti, ki so jim na voljo.

Z uporabo žetona JWT implementirajte:

• prijavo uporabnikov (avtentikacija oz. preverjanje istovetnosti identitete) in
• nadzor dostopa (avtorizacija oz. pooblastitev) do določenih funkcionalnosti.

Popoln dostop do spreminjanja in brisanja podatkov v podatkovni bazi (preko REST API) naj ima uporabnik administrator, medtem ko omejene spremembe podatkov v podatkovni bazi (preko REST API) dovolite tudi prijavljenemu uporabniku. Neprijavljen uporabnik naj ima v skladu s funkcionalnostmi vaše aplikacije zgolj bralni dostop do izbranih funkcionalnosti.

Vaša aplikacija naj podpira registracijo novega uporabnika in prijavo obstoječega uporabnika v sistem. Ko se v sistem registrira nov uporabnik, ima dodeljeno vlogo navadnega prijavljenega uporabnika.

Ne pozabite na ustrezno šifrirano shranjevanje gesel v podatkovni bazi in dokumentiranje REST API metod zaradi vpeljave avtentikacije in avtorizacije ter podporo testiranju z JWT žetonom pri dokumentaciji REST API vmesnika.

---

46. angl. Smart Oracles↩︎

47. angl. hash function↩︎