Talk:LuckyYou: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Mbetlem (talk | contribs)
No edit summary
Jturnpuu (talk | contribs)
 
(8 intermediate revisions by 4 users not shown)
Line 46: Line 46:


Nähes veebiteenuse kasutajaliidest ja funktsionaalsust võib oletada, et selle taga peab olema korralik kogus koodi. See oletus pidas täiesti paika. Veebiteenus on korralikult ära jaotatud kihtidesse: BLL (milles asuvad DTO-d, Factorid ja service-id), DAL (milles asuvad Mapper-id, Helper-id, Interface-id, Repositor-id, DBContext ja UOW), Domain (milles asuvad rollid ja olemid), Identiy, Modul (milles leidub turvaelemente kui ka tõlkimisega seotud service-id), Resources ja WebApp (milles on siis kontrollerid, mudelid, vaated ja muu vajalik koos scriptidega). Nagu mainitud, on koodi palju ning kõike pole aega väga põhjalikult läbi uurida. Kokkuvõttes võib öelda, et hakkama on saadud väga suure tööga. Kood on ilusti loetav, kommenteeritud ja vastavateks osadeks ära jaotatud. Võib julgelt väita, et selle kursuse üks korralikumaid töid. :)
Nähes veebiteenuse kasutajaliidest ja funktsionaalsust võib oletada, et selle taga peab olema korralik kogus koodi. See oletus pidas täiesti paika. Veebiteenus on korralikult ära jaotatud kihtidesse: BLL (milles asuvad DTO-d, Factorid ja service-id), DAL (milles asuvad Mapper-id, Helper-id, Interface-id, Repositor-id, DBContext ja UOW), Domain (milles asuvad rollid ja olemid), Identiy, Modul (milles leidub turvaelemente kui ka tõlkimisega seotud service-id), Resources ja WebApp (milles on siis kontrollerid, mudelid, vaated ja muu vajalik koos scriptidega). Nagu mainitud, on koodi palju ning kõike pole aega väga põhjalikult läbi uurida. Kokkuvõttes võib öelda, et hakkama on saadud väga suure tööga. Kood on ilusti loetav, kommenteeritud ja vastavateks osadeks ära jaotatud. Võib julgelt väita, et selle kursuse üks korralikumaid töid. :)
==LuckyYou veebiteenuse ja klientrakenduse retsensioon==
Meeskond LuckyYou on teinud oma veebiteenusele hea analüüsi, et andmebaas eeldusena on olemas ning olemeid on seal kohe kindlasti paljud kui üheksa. Analüüsis on välja toodud nii „must have“ kui ka „ should have“ asjad, mida toodud teenus peab võimaldama.  Rakenduse idee on hea, et antud teenus võiks olla kasutatav ka ärilistel eesmärkidel. Täidatakse “should have” ning võiks olla kasutatav ka ärilistel eesmärkidel.  Wiki lehes on hästi koostatud ja informatiivne.  Kasutaja saab valida loosimisi kategooria järgi kui tal on soov. Esinevad küll kergesti parandatavaid puudujääke.
Lahendus on kenasti ära jaotatud erinevateks projektideks nagu
*BLL
*DAL
*DALWebAPI
*Domain
*Identity
*WebApp
Kasutatud on ka muud: interface, UOW, Repository, DTO, MVC.<br/>
Hea, et veebirakendus on juba serveris, kuid probleemi sisse logimisega olnud. - Testisime siis töötas, aga keeruliseks teha. Oleks teada, et koosta vajalikult  juhendit. On vaja hea ja lihtne juhend.
Kokkuvõtteks võib öelda meie meeskond, et tehtud töö on konkreetne ja hea. Kõik ülesanded on täidetud nõutud punktid ning meeskond on astunud sammu edasi ning tulevikus ootame suuri tegusid.


Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/SHOP Meeskond SHOP]
Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/SHOP Meeskond SHOP]
= Retsensioon tiimi LuckyYou veebiteenusele =
Meeskonna LuckyYou projektiks on veebiteenus, mis võimaldab erinevaid loosimisi vahendada. RESTful ehk Web API teenus võimaldab lisada, muuta ja kuvada erinevaid loosimisi, mis on jaotatud erinevatesse kategooriatesse ning liigitatud tähtsuse järgi. Teenuses on olemas ka kasutajate süsteem, mille kaudu saab ennast loosimistele registreerida ning lepingulistel ka loosimisi lisada.
Projekti kood on puhas ja korrektne, kenasti arusaadav ja hallatav, kuna õpitud arendusmustreid on otstarbekalt ära kasutatud. Andmebaas on loodud kasutades EntityFrameworki ning „kood enne“ lähenemist. EFi kasutades ei pea andmebaasi loomiseks SQLi kirjutama, mis hoiab kõvasti aega kokku. Kuna LuckyYou andmebaasis on 10 domeenimudelit ja lisaks veel kasutajate haldamissüsteem, siis on EFi kasutamine igati mõistlik.
Meeskond on väga hästi rakendanud ka repositooriumite mustrit. Repositooriumid(repod) aitavad minimaliseerida andmebaasi päringute hulka. Repod töötavad justkui mäluna, kuna objektid salvestatakse andmebaasi alles siis, kui on välja kutsutud vastav meetod. Senikaua võib andmebaasist objektidega teha midatahes. Samuti on repode plussiks see, et kui peaks olema vajadus EF välja vahetada mõne muu ORMi raamistiku vastu, siis ei rikuks see ülejäänud rakenduse loogikat. Tuleb lihtsalt üks kiht alt välja vahetada. LuckyYou projektis tublisti igal domeenimudelil oma repositoorium, kus sees on palju mudelispetsiifilisi meetodeid lisaks baasrepost tulevatele meetoditele(CRUD meetodid). Kõik projekti repod on ühendatud ka üheks suureks Unit of Workiks, mis töötab kui kõikide repode vahemäluna – kõik muudatused saadetakse andmebaasi ühe suure tükina, mis omakorda vähendab päringute hulka andmebaasi vastu.
Meeskond on kasutanud sõltuvuste süstimiseks Ninjectit. Sõltuvuste süstimist on mõttekas tarvitada, sest see muudab süsteemi tulevikus ettetulevatele muudatustele vastuvõtlikumaks. Sõltuvuste inversiooni kasutades ei sõltu kõrgema taseme moodul madalama taseme moodulist, sõltuvused on just vastupidi. Madalama taseme moodulid peavad täitma kõrgema taseme liidest. Sedasi tehes ei pea muretsema, et oleks vaja muuta kõrgema taseme mooduli loogikat.
Projekti äriloogika kihis on andmeedastusobjektid(DTO) ning nende tehased. Samuti erinevad teenused, mida kasutatakse API kontrollerites. Domeenimudelite DTOdeks tegemiseks on loodud tehased, mis on vägagi mõistlik, et välistada pidevat objekti väljade mappimist. Samas hakkas silma, et mõnes kohas on kaardistamist ikkagi käsitsi tehtud, mitte läbi tehase(nt BillService, DrawService ja mõned veel). Ilmselt oleks mõistlik olnud ka BLLi teenustes UOWd pruukida. Näiteks DrawService’is on deklareeritud 4 erinevat repot, kuigi oleks võinud siis juba UOWga probleemi lahendada.
Teenus on mahukas, sisaldab palju erinevaid kontrollereid ning võimaldab teha vähemalt 66 eri sorti päringut. API on väga kenasti tehtud ning tundub, et kõik päringud töötavad nagu peaks. Ainuke etteheide oleks see, et kõik kasutajad saavad API vastu kõiki päringuid teha ehk puudub autentimine rääkimata autoriseerimisest. Tundub, et kõik eeldused autentimiseks oleks justkui olemas. Fiddleriga testides saab teenusest isegi Tokeni kätte.
Kui veel näpuga veebiteenuse nõuetes järge ajada, siis ei hakanud koodis silma kasutusstatistika jälgimise ning päringute arvu piiramise võimalused(mõlemad on tegelikult üsnagi kerge vaevaga tehtavad, kasutades mõnda olemasolevat NuGeti paketti).
Üldiselt on meeskond teenust ehitades ära teinud väga suure töö ning aine raames õpitud arendusmustrid on otstarbekalt ära kasutatud ning koodi on ka dokumenteeritud. Ilmselt kui projektiga veel mõned päevad vaeva näeks, siis saaks ka kasutusstatistika, päringute arvu piiramise ning autentimise ilusti tööle. Hetkeseisuga oleks veebiteenus kindlasti väärt vähemalt 95% punktidest. Tubli töö!
Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Undress_Gaver Undress Gaver]
= Retsensioon tiimi LuckyYou klientrakendusele=
Meeskonna LuckyYou klientrakendus kasutab ära veebiteenusena realiseeritud CRUD operatsioone. Meeskonna klientrakendus on tehtud kasutades MVC tehnoloogiat. Positiivsena tooks kohe välja selle, et kuigi on kasutatud veebiteenust on jäädud truuks MVC repo mustri juurde ning kontrollerites kasutatud ära reposid/unitofworki ehk kõik päringud ongi realiseeritud repodes, selle jaoks on tehtud eraldi projekt - DALWebAPI. Kliendis ringi liikudes tundus kõik nupud/funktsioonid toimivat ning ühtegi errorit Google Chrome Consolega ei leidnud. Kliendis on realiseeritud kolm kasutajagruppi ning igalühel neist on oma vaade/võimalused. <br /><br />
1) tavakasutaja - menüüst saab lisaks reeglitele vaadata kõiki käimas olevaid loose, sorteerida loose kategooriate järgi, vaadata edetabelit ning muidugi ka oma võite. Kõik töötab nii nagu peab.
2) klient - klient saab vaadata edetabelit, käimasolevaid loose (lisaks ka enda loosid), tooteid juurde lisada - siin tekitab natukene segadust see, et toodet lisades tuleb määrata ees- ja perekonnanimi ning mis peamine - uusi loose teha, uue loosi tegemine on tehtud väga lihtsaks, kõik vajalikud väljad on olemas ning uue loosi tegemine on sekundite küsimus, ainus asi mis häirima jäi oli vanusegrupi väli - see võiks olla näiteks selectbox või muu taoline, sest lihtsalt textbox tekitab segadust, seda enam, et puudub juhend mis formaadis peaks vanuse kirjutama. Lisaks kõigele eelnevale on kliendil ka arved, mida ta iga loosi tegemise eest saab, ka see funktsionaalsus tundub toimivat. Üldjoontes võib öelda, et kliendi funktsionaalsus on hästi realiseeritud ning kõik töötab. <br /><br />
3) admin - funktsionaalsus tekitab küsimusi, näiteks see, et looside võitjate valimine toimub "My winnings" alt ning kui mingile loosile võitja panna, siis loos ei lõppe, vaid lihtsalt kuvab seda "My winnings'ite" all. Admin kasutaja peaks nägema kellele arve määratud on ning olema mingi funktsionaalsus arveid eemaldada. Lisaks eelnevale peaks admin kasutajal olema ka mingi kasutajahaldus variant ehk peaks saama kasutajate õiguseid muutma, sest läbi andmebaasi võiks see reaalses lahenduses olla tüütu.
Üldiselt kasutajate funktsionaalsus kokku võtta, siis võiks ainult nokkida natukene admin kasutajaga, kuid üldjoontes võib projekti liikmeid ainult kiita. <br /><br />
Viimasena võtaks ette veebilehe disaini, disain on väga meeldiv ning "tundub nagu päris" ehk väljasõitev menüü, edetabeli "karikas" on silmale mõnus ning ei väsita ning lahendus on nii palju valmis, et võiks ka reaalselt leiba teenida mõne ettevõtte jaoks. Üks asi mis projekti juures häiris oli see, et kõik asjad on ühes solutionis, autorid oleksid võinud klientrakenduse teha uue solutioni alla, sest praegu oli esialgu natukene toimuvast keeruline aru saada ning ka klientrakenduse/teenuse korraga käivitamine tekitas probleeme.<br /><br />Retsensioon kokkuvõtta, siis võib öelda, et projekti liikmed on teinud head tööd ning vähemalt esmapilgul tundub kõik must-have funktsionaalsus realiseeritud. Soovin neile edu järgnevatest projektides.
Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Undress_Gaver Undress Gaver]

Latest revision as of 18:05, 9 June 2016

Aloha Snackbari retsensioon

Wiki on koostatud meie rühma hinnangul hästi, sest kirjeldatud on idee ning loodud ka blogivaade, kust kohast võib uurida meeskonna tööprotsessi. Lisatud on andmebaaside joonis, mis annab parema ülevaate XML faili uurimiseks.


XML fail on enamuses korrektselt vormistatud. Täidetud oli 4 dimensioooni olemasolu nõue. Puuduseks võib tuua, et ei ole lisatud piisavalt atribuute erinevatele dimensioonidele. Nõudeks oli atribuutide kasutamine kolmel eirneval dimensioonil. Sellel XML'il oli kasutatud atribuute ainult kahel dimensioonil.

Draw
    drawPrice või rule

XSD failis on kontrollimata on jäänud muutujate andmetüübid. Näiteks mõned eksimused: failis on "quantity xs:unsignedByte ". Mis juhtub siis kui näiteks mõni firma soovib jagada rohkem kui 255 toodet? Sama lugu on page-positioniga "xs:unsignedByte", mis tähendab, et kohti võib jagada 255ni. Juhul kui aga draw e oleks rohkem kui 255, jookses süsteem jälle kokku. Arvame, et skeem on 'genereeritud automaatselt' ning seda ei ole üle vaadatud.

XLST fail on lihtne loosimiste kuvamine. Positiivne on, et kasutatud on enamat kui ainult ühte for-each tsüklit. Kasutamata on jäänud erinevate parameetrite ning tingimuste kontrollid.

ABIKS: Iseenesest saab asja ajada mitmekesisemaks nii, et nimes ei kasutata konkreetset numbrit, vaid lisatakse eraldi atribuut KOGUS. Formeerimises võib kasutada <xsl:value-of select=”concat(@KOGUS, ‘x ‘, .)”/> mis lisaks kokku atribuudi väärtuse ning seejärel x kui korda ja siis nime. Näiteks formeeriks IPhone 5S puhul antud koodijupp selle 1x Iphone5S

KOKKUVÕTE: Rakenduse idee on hea, täites nõuet, et antud teenus võiks olla kasutatav ka ärilistel eesmärkidel. Esineb küll kergesti parandatavaid puudujääke, kuid Wiki leht on üleüldiselt informatiivne ja hästi koostatud.

Retsenseeris meeskond Aloha Snackbar


Retsensioon meeskonna SHOP Veebiteenusele meeskonna BurgerAce poolt

Meeskond SHOP valmis teinud veebiteenuse, mis võimaldab kiiresti ja lihtsalt luua uusi veebi poode. Wiki-s on lühidalt välja toodud analüüs, kus on lühidalt välja toodud teenuse idee, teenuses olevad kasutajate rollid, nende põhimõtted ning eesmärgid ja seejärel “must have“ ja “nice to have“ funktsionaalsused. Maha kriipsutatud funktsionaalsused viitavad sellele, et vastavad funktsionaalsused on olemas. Seda saame teada pärast projektiga lähemalt tutvust tegemist. Andmebaasi skeemilt on kohe näha, et olemeid on kõvasti rohkem kui ülesanne nõuab (9 olemit min) ja võib välja lugeda, et andmebaas on põhjalikult läbi mõeldud. Samuti on mainitud logis, et andmebaasi on arenduse käigus uuendatud, tõenäoliselt kohandatud vastavalt vajadusele.

Veebiteenusega enesega oli tutvust teha väga mugav, kuna see oli serverisse üles laetud ning meeskonna pool pakutud juhend selle kasutamiseks oli lühike ja arusaadav.

Veebiteenuse kasutajaliides on moderne ning seda on mugav kasutada. Sõltuvalt soovist on võimalik valida keel, milles käesolevat keskkonda kuvatakse. Vaated on ilusti ära jaotatud kategooriatesse ja administraatori kui ka tavakasutaja vaated on siis vastavalt rollile kas peidetud või kättesaadavad. Administraatoril on võimalik hallata nii poode, kontaktandmeid kui ka neis müüdavaid kaupu. Igat väiksemat detaili on võimalik muuta ja uuendada (ja mitte ainult eelnevalt mainitud osade puhul). Võimalusi on nii palju, et neid võibki jääda loetlema.

Üks peamine funktsionaalsus on ettevõtete haldus, kes oleks siis vastava veebiteenuse tarbijad. Tänu hästi läbi mõeldud kasutajaliidesele, on igasugune redigeerimine, andmete muumine ja kustutamine väga lihtne. Võimalik on muuta ettevõtete kontaktandmeid, aadresse ja maksemeetodeid.

Poodides on võimalik luua uusi ja muuta olemasolevaid kategooriad, võimaldades sorteerida ja rühmitada kaupu vastavalt tüübile. Selle jaoks on tehtud eraldi vaade, mis väidetavalt oli üks keerulisemaid osi selle projekti raames. Raske töö on ennast ära tasunud ning vastav vaade töötab veatult. Kui avada mingi poe lehekülg, kuvatakse müüdavate kaupade eelvaated (ehk siis toote pilt, nimi ja hind koos allahindlusega, juhul kui on). Samuti on olemas link, mis viib detailsemasse vaatesse ja toote ostukorvi lisamise võimalus. Minnes detailsesse vaatesse on veel lisaks kuvatud vaatamiste arv (hetkel LIVE-is ja kõiki vaatamisi läbi aegade), toote tehnilised andmed ja muu lisainformatsioon, nagu toote asukoht ja kus kui palju vastavat kaupa on.

Kampaaniaid on võimalik lisada ja muuta vastavas vaates. Kõigepealt tuleb valida pood, kus tahetakse kampaaniat alustada/muuta. Seejärel on võimalik nimekirjast valida olemasoleva kampaania, mida soovitakse muuta või siis on võimalik luua uus. Nõutud on siinkohal Kampaania nimi, kirjeldus, promo kood ja allahindluse protsent. Samal põhimõttel töötab ka kullerite teenuste haldamine. Poe valides on võimalik vastavaid teenuseid lisada, redigeerida või kustutada. Nõutud on kulleri nimi ja teenustasu.

Arvete jaoks mõeldud vaates kuvatakse ainult tabelit, kus on siis kasutaja tüüp, millal arve loodi, maksmise viimane kuupäev, summa ja makse staatus. Tänu sellele on arvete haldamine mingil määral lihtsustatud, kuid lisaks arvete kuvamisele oleks võinud olla ka mingid lisa funktsionaalsused selles vaates (näiteks sorteerimine vastavalt ettevõttele).

Olles ostja rollis on võimalik ostukorvi lisatud esemete arvu muuta, neid kustutada ja kinnitada enda ostu.

Nähes veebiteenuse kasutajaliidest ja funktsionaalsust võib oletada, et selle taga peab olema korralik kogus koodi. See oletus pidas täiesti paika. Veebiteenus on korralikult ära jaotatud kihtidesse: BLL (milles asuvad DTO-d, Factorid ja service-id), DAL (milles asuvad Mapper-id, Helper-id, Interface-id, Repositor-id, DBContext ja UOW), Domain (milles asuvad rollid ja olemid), Identiy, Modul (milles leidub turvaelemente kui ka tõlkimisega seotud service-id), Resources ja WebApp (milles on siis kontrollerid, mudelid, vaated ja muu vajalik koos scriptidega). Nagu mainitud, on koodi palju ning kõike pole aega väga põhjalikult läbi uurida. Kokkuvõttes võib öelda, et hakkama on saadud väga suure tööga. Kood on ilusti loetav, kommenteeritud ja vastavateks osadeks ära jaotatud. Võib julgelt väita, et selle kursuse üks korralikumaid töid. :)


LuckyYou veebiteenuse ja klientrakenduse retsensioon

Meeskond LuckyYou on teinud oma veebiteenusele hea analüüsi, et andmebaas eeldusena on olemas ning olemeid on seal kohe kindlasti paljud kui üheksa. Analüüsis on välja toodud nii „must have“ kui ka „ should have“ asjad, mida toodud teenus peab võimaldama. Rakenduse idee on hea, et antud teenus võiks olla kasutatav ka ärilistel eesmärkidel. Täidatakse “should have” ning võiks olla kasutatav ka ärilistel eesmärkidel. Wiki lehes on hästi koostatud ja informatiivne. Kasutaja saab valida loosimisi kategooria järgi kui tal on soov. Esinevad küll kergesti parandatavaid puudujääke.

Lahendus on kenasti ära jaotatud erinevateks projektideks nagu

  • BLL
  • DAL
  • DALWebAPI
  • Domain
  • Identity
  • WebApp

Kasutatud on ka muud: interface, UOW, Repository, DTO, MVC.
Hea, et veebirakendus on juba serveris, kuid probleemi sisse logimisega olnud. - Testisime siis töötas, aga keeruliseks teha. Oleks teada, et koosta vajalikult juhendit. On vaja hea ja lihtne juhend. Kokkuvõtteks võib öelda meie meeskond, et tehtud töö on konkreetne ja hea. Kõik ülesanded on täidetud nõutud punktid ning meeskond on astunud sammu edasi ning tulevikus ootame suuri tegusid.

Retsenseeris meeskond Meeskond SHOP

Retsensioon tiimi LuckyYou veebiteenusele

Meeskonna LuckyYou projektiks on veebiteenus, mis võimaldab erinevaid loosimisi vahendada. RESTful ehk Web API teenus võimaldab lisada, muuta ja kuvada erinevaid loosimisi, mis on jaotatud erinevatesse kategooriatesse ning liigitatud tähtsuse järgi. Teenuses on olemas ka kasutajate süsteem, mille kaudu saab ennast loosimistele registreerida ning lepingulistel ka loosimisi lisada.

Projekti kood on puhas ja korrektne, kenasti arusaadav ja hallatav, kuna õpitud arendusmustreid on otstarbekalt ära kasutatud. Andmebaas on loodud kasutades EntityFrameworki ning „kood enne“ lähenemist. EFi kasutades ei pea andmebaasi loomiseks SQLi kirjutama, mis hoiab kõvasti aega kokku. Kuna LuckyYou andmebaasis on 10 domeenimudelit ja lisaks veel kasutajate haldamissüsteem, siis on EFi kasutamine igati mõistlik.

Meeskond on väga hästi rakendanud ka repositooriumite mustrit. Repositooriumid(repod) aitavad minimaliseerida andmebaasi päringute hulka. Repod töötavad justkui mäluna, kuna objektid salvestatakse andmebaasi alles siis, kui on välja kutsutud vastav meetod. Senikaua võib andmebaasist objektidega teha midatahes. Samuti on repode plussiks see, et kui peaks olema vajadus EF välja vahetada mõne muu ORMi raamistiku vastu, siis ei rikuks see ülejäänud rakenduse loogikat. Tuleb lihtsalt üks kiht alt välja vahetada. LuckyYou projektis tublisti igal domeenimudelil oma repositoorium, kus sees on palju mudelispetsiifilisi meetodeid lisaks baasrepost tulevatele meetoditele(CRUD meetodid). Kõik projekti repod on ühendatud ka üheks suureks Unit of Workiks, mis töötab kui kõikide repode vahemäluna – kõik muudatused saadetakse andmebaasi ühe suure tükina, mis omakorda vähendab päringute hulka andmebaasi vastu.

Meeskond on kasutanud sõltuvuste süstimiseks Ninjectit. Sõltuvuste süstimist on mõttekas tarvitada, sest see muudab süsteemi tulevikus ettetulevatele muudatustele vastuvõtlikumaks. Sõltuvuste inversiooni kasutades ei sõltu kõrgema taseme moodul madalama taseme moodulist, sõltuvused on just vastupidi. Madalama taseme moodulid peavad täitma kõrgema taseme liidest. Sedasi tehes ei pea muretsema, et oleks vaja muuta kõrgema taseme mooduli loogikat.

Projekti äriloogika kihis on andmeedastusobjektid(DTO) ning nende tehased. Samuti erinevad teenused, mida kasutatakse API kontrollerites. Domeenimudelite DTOdeks tegemiseks on loodud tehased, mis on vägagi mõistlik, et välistada pidevat objekti väljade mappimist. Samas hakkas silma, et mõnes kohas on kaardistamist ikkagi käsitsi tehtud, mitte läbi tehase(nt BillService, DrawService ja mõned veel). Ilmselt oleks mõistlik olnud ka BLLi teenustes UOWd pruukida. Näiteks DrawService’is on deklareeritud 4 erinevat repot, kuigi oleks võinud siis juba UOWga probleemi lahendada.

Teenus on mahukas, sisaldab palju erinevaid kontrollereid ning võimaldab teha vähemalt 66 eri sorti päringut. API on väga kenasti tehtud ning tundub, et kõik päringud töötavad nagu peaks. Ainuke etteheide oleks see, et kõik kasutajad saavad API vastu kõiki päringuid teha ehk puudub autentimine rääkimata autoriseerimisest. Tundub, et kõik eeldused autentimiseks oleks justkui olemas. Fiddleriga testides saab teenusest isegi Tokeni kätte.

Kui veel näpuga veebiteenuse nõuetes järge ajada, siis ei hakanud koodis silma kasutusstatistika jälgimise ning päringute arvu piiramise võimalused(mõlemad on tegelikult üsnagi kerge vaevaga tehtavad, kasutades mõnda olemasolevat NuGeti paketti).

Üldiselt on meeskond teenust ehitades ära teinud väga suure töö ning aine raames õpitud arendusmustrid on otstarbekalt ära kasutatud ning koodi on ka dokumenteeritud. Ilmselt kui projektiga veel mõned päevad vaeva näeks, siis saaks ka kasutusstatistika, päringute arvu piiramise ning autentimise ilusti tööle. Hetkeseisuga oleks veebiteenus kindlasti väärt vähemalt 95% punktidest. Tubli töö!

Retsenseeris meeskond Undress Gaver

Retsensioon tiimi LuckyYou klientrakendusele

Meeskonna LuckyYou klientrakendus kasutab ära veebiteenusena realiseeritud CRUD operatsioone. Meeskonna klientrakendus on tehtud kasutades MVC tehnoloogiat. Positiivsena tooks kohe välja selle, et kuigi on kasutatud veebiteenust on jäädud truuks MVC repo mustri juurde ning kontrollerites kasutatud ära reposid/unitofworki ehk kõik päringud ongi realiseeritud repodes, selle jaoks on tehtud eraldi projekt - DALWebAPI. Kliendis ringi liikudes tundus kõik nupud/funktsioonid toimivat ning ühtegi errorit Google Chrome Consolega ei leidnud. Kliendis on realiseeritud kolm kasutajagruppi ning igalühel neist on oma vaade/võimalused.

1) tavakasutaja - menüüst saab lisaks reeglitele vaadata kõiki käimas olevaid loose, sorteerida loose kategooriate järgi, vaadata edetabelit ning muidugi ka oma võite. Kõik töötab nii nagu peab. 2) klient - klient saab vaadata edetabelit, käimasolevaid loose (lisaks ka enda loosid), tooteid juurde lisada - siin tekitab natukene segadust see, et toodet lisades tuleb määrata ees- ja perekonnanimi ning mis peamine - uusi loose teha, uue loosi tegemine on tehtud väga lihtsaks, kõik vajalikud väljad on olemas ning uue loosi tegemine on sekundite küsimus, ainus asi mis häirima jäi oli vanusegrupi väli - see võiks olla näiteks selectbox või muu taoline, sest lihtsalt textbox tekitab segadust, seda enam, et puudub juhend mis formaadis peaks vanuse kirjutama. Lisaks kõigele eelnevale on kliendil ka arved, mida ta iga loosi tegemise eest saab, ka see funktsionaalsus tundub toimivat. Üldjoontes võib öelda, et kliendi funktsionaalsus on hästi realiseeritud ning kõik töötab.

3) admin - funktsionaalsus tekitab küsimusi, näiteks see, et looside võitjate valimine toimub "My winnings" alt ning kui mingile loosile võitja panna, siis loos ei lõppe, vaid lihtsalt kuvab seda "My winnings'ite" all. Admin kasutaja peaks nägema kellele arve määratud on ning olema mingi funktsionaalsus arveid eemaldada. Lisaks eelnevale peaks admin kasutajal olema ka mingi kasutajahaldus variant ehk peaks saama kasutajate õiguseid muutma, sest läbi andmebaasi võiks see reaalses lahenduses olla tüütu. Üldiselt kasutajate funktsionaalsus kokku võtta, siis võiks ainult nokkida natukene admin kasutajaga, kuid üldjoontes võib projekti liikmeid ainult kiita.

Viimasena võtaks ette veebilehe disaini, disain on väga meeldiv ning "tundub nagu päris" ehk väljasõitev menüü, edetabeli "karikas" on silmale mõnus ning ei väsita ning lahendus on nii palju valmis, et võiks ka reaalselt leiba teenida mõne ettevõtte jaoks. Üks asi mis projekti juures häiris oli see, et kõik asjad on ühes solutionis, autorid oleksid võinud klientrakenduse teha uue solutioni alla, sest praegu oli esialgu natukene toimuvast keeruline aru saada ning ka klientrakenduse/teenuse korraga käivitamine tekitas probleeme.

Retsensioon kokkuvõtta, siis võib öelda, et projekti liikmed on teinud head tööd ning vähemalt esmapilgul tundub kõik must-have funktsionaalsus realiseeritud. Soovin neile edu järgnevatest projektides.


Retsenseeris meeskond Undress Gaver