Talk:LuckyYou

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