Talk:Meeskond:Valar Morghulis

Teenuse ja kliendi retsensioon meeskonnalt Dot muzei

Teenus

Domeeni mudelid:

Domeeni mudeli põhjal loodud POCO’d järgivad andmemudelis defineeritud seoseid. Olemid on varustatud Data Annotatsioonidega, mis defineerivad tabeli väljade omadusi. Lisaks sellele on defineeritud ka eesti keelsed veateated. Sõned tabeliväljades on piiratud. Lisaks sellele on domeenimudelisse lisatud Identity projekti olemid ning Identity projekti kasutaja on seotud domeeni mudeliga.

DAL:

Andmekäitlus kiht on loodud kasutades kõiki nõutud disaini mustreid nagu seda on UOW, repositooriumid, liidesed, vabriku muster ja code-first andmebaas. Enamus domeenimudelid on loodud läbi standard repositooriumite. Erandiks on siinkohal AppUserRepository, mille jaoks on loodud eraldi repositoorium. Standard repositooriumi liidesele on lisatud teenuse spetsiifilisi meetodeid andmetöötluseks. Igale repole on loodud ka vastav liides. Samuti on andmekäitlus kihis ka Identity projektiga seotud liidesed ja repositooriumid. Andmekäitlus kiht vastab igati nõutud kriteeriumitele ning midagi anomaalset seal ei esine. Järgitud on häid tavasid ning on näha, et projekti autor on teinud tööd põhjalikusega ning mõistab enda poolt loodud projekti arhitektuuri.

Äriloogika kiht:

Äriloogika kiht on varustatud DTO-dega, mis võimaldavad edastada mudeli kohta soovitud andmeid. DTO-de loomiseks on olemas vabrikud, mis läbi vabriku mustri võimaldavad luua uusi DTO objekte vastavalt olemitele, mida DTO kirjeldab. Äriloogika kiht on varustatud ka meetoditega, mis tegelevad andmepäringutega. Hetke seisu järgi tundub nagu osa meetodeid on jäänud implementeerimata või ei osutunud need rakenduse jaoks vajalikuks. Äriloogika kiht on järjekordselt korrektselt tehtud ning pretentsioone selles osas ei ole. Teenuse autor on läbimõelnud oma lahenduse ning järginud häid tavasid koodi kirjutamisel.

WebApi:

Veebi teenus kasutab ära SSL-i ning töötab üle HTTPS-i, mis on väga oluline tagamaks, et teenus oleks turvaline. Lisaks Identity projektist kaasa tulnud kontrolleritele ja home kontrollerile on teenuses olemas veel 2 autori enda loodud kontrollerit. Kontrollerid töötavad üle Unit of Worki, kahjuks pole Dispose meetodid välja kommenteeritud. Samuti pole ka kontrollerite enda meetodid varustatud dokumentatsiooni stiilis kommentaaridega, mis võimaldaksid teistel arendajatel paremini teenuse sisust aru saada. Küll on aga meetodi nimed iseennast kirjeldavad. Lisaks CRUD operatsioonidele on ka teenuse spetsiifilised meetodid. Teenuse lehe kasutajaliides ja selle laotus on muutmata ja vastab algupärasele avakuvale. Teenuses on kasutatud sõltuvuse süstimist ning see on realiseeritud läbi Ninjecti. Teenus ise vastab üldjoontes headele tavadele ja kasutab nõutud võtteid.

Klient

Admin paneel:

Admin paneeli valikuks on kasutatud modernse välimusega admin paneeli template’i, mis annab rakendusele professionaalset välimust. Lisaks sellele on template varustatud ka erinevate widgetitega, mis lisavad nii võimalusi template’i välimuse muutmiseks kui ka annavad teada, mis kell on. Admin rakendus on ühendatud Identity projektiga. Samuti kasutab rakendus ka HTTPS-i, mis on ainumõeldav turvaline lahendus rakenduse jaoks, mis võimaldab pea kõike muuta. Kõikide domeenimudelite jaoks on oma kontrollerid, ka Identity projektist tulnud olemite jaoks. Defineeritud on baas kontroller, kuid seda ei ole kasutusele võetud. Samuti suhtlevad paljud kontrollerid andmebaasiga läbi Entity raamistiku. Ainult teenuse enda domeeni mudelid kasutavad Unit of Worki. Vaatemudeleid ei ole peamiste domeenimudelite kohta loodud ning paljudesse kohtadesse on sisse jäänud viewbagid. Rakendus kasutab ka sõltuvuse süstimist. Tundub, et administratsiooni paneeli prioriteet on olnud projekti juures kõige madala väärtusega, kuid arvestades, et projekt on tehtud üksi ja võrdlemisi põhjalikult, siis ei selle tõttu autorit väga kritiseerida. Rakendus ise täidab oma funktsionaalsust ning võimaldab kõiki olemeid modifitseerida või luua.

Klient:

Klient suhtleb teenusega üle HTTP, mis oli kliendi puhul vajalik nõue. Suhtlus teenusega on defineeritud läbi teenuste klasside, mis kõik pärinevad baasteenuse klassist. Tundub, et mingil hetkel on autor soovinud klienti luua kasutades Angular.js-i, kuid tõenäoliselt leidis sellise lahenduse alustamiseks liiga raske olevat. Rakendus suhtleb teenusega üle HTTPS-i, mis on järjekordselt turvalisuse tagamiseks väga oluline nüanss. Ainuke kontroller projektis on Home kontroller, mis tegeleb kõigi vaadete kuvamisega. See on veidi kummaline, kuid arvestades kliendi poolset lihtsat funktsionaalsust, mis on keskendunud väheste operatsioonide tegemisele, siis see annab vihjeid, misk autor on sellise valiku teinud. Isiklikult oleks ma siiski loonud olemite jaoks eraldi kontrollerid ja läbi kontrollerite operatsioonide jaoks välja kutsunud rakenduse teenustes defineeritud meetodeid. Mis puudutab audentimist ja autoriseerimist, siis sellega on autor edukalt hakkama saanud. Puudu on veel viimased lihvid, sest kohati on näha, et palju funktsionaalsust on hetkel kokku liigendatud nii, et rakendus toimiks. Soovitaks olemite jaoks luua eraldi kontrollerid ning kui kontrolleri meetod ei tagasta põhimõtteliselt midagi, siis soovitaks kaaluda selle eemaldamist. Iga kontrolleri jaoks võiksid olla oma vaated ning kui vaja, siis ka vaatemudelid. Vaated vajaksid kordategemist. Siiski arvestades, et kogu projekt on ühe inimese poolt loodud, siis töö mahtu arvestades piirdun pretentsioonidega.

Retsenseeris meeskond Dot muzei

Klientrakenduse retsensioon meeskonnalt Iread

Olles käivitanud WebApi ning täitnud selle testandmetega käivitan kliendi enda. Proovides läbi kliendi kasutajat luua, ei saanud aga ühtegi teadet, ega tagasisidet. Proovides pärast oma loodud kasutajaga sisse logida, lajatab järjekorde tühjus ja vaikus. Prooviks tõmbasin Fiddleri käima, et proovida aru saada mis toimub, selgus et esmane päring pannakse kenasti api suunas teele kuid peale seda tehakse veel neli identset päringut porti 44399 mis ei tundu üldse projektiga seotud olevat. Võimalik, et tegemist on mõne minu masina anomaaliaga. Kui aga lahkasin natuke registreerimise päringut, siis mulle lajatas fiddleris ilus 200 vastus kuid mida ei olnud, oli kasutaja baasis. Pärast mitut proovimist ja õnne, tuli välja, et paroolis peaks ikka sümbol olema, ja et suur täht nii sammuti. Sellised teated justkui elutsevad koodis, kuid esile neid miskipärast ei kutsutud. Peale regamist ei saanud ma mingit tagasisidet, kas registreerimine õnnestus või mitte, igal juhul kuvati järgmisena kohe sisselogimise vaade. Ka siin vaates ei anta kasutajale mingit tagasisidet logimise staatusest või vastusest.

Mõne kasutajale küsimuse lisamisel wordsLeft counter ei toiminud ning pärast Esita nuppu muljumist suunati mind tagasi "AllUsers" vaatesse. Tundub, et midagi oleks nagu source'ist puudu või ma olen midagi valesti jooksutanud. jätkan koodi vaatamist.

Kogu sisu on kenasti jagatud Controllers, Models, Services ja Views. Kasutatud on õppejõu WPF näites väljatoodud põhimõtet rakenduse loomisel. BaseService klass kasutab ServiceConstants klassi nii nagu ka õppejõu näites. Küll aga ei saa ma aru miks on kõik urlid hardcoded meetoditesse mitte pole kaasutatud config faili nende hoidmiseks? Kolades veel baseservice klassis ringi leidsin, et meeskond pole veel jõudnud tegeleda response vastustega ja nende kuvamise/teavitamisega.

Ühtlasi tundub ,et ViewModels on jäänud meeskonnal source'i kui mingi idee jääk.

Väga positiivne on näha, et Models vaadetes on pandud rõhku juba päringu tulemuste korrektsetesse piiridesse panemiseks. Küll aga kahjuks mina nende kuvamist ei näinud. Natuke rohkem oleks tahtnud näha meetodite kommenteerimist erit kuna service klassides olid osad meetodid väga mitmetähenduslike nimedega mis tekitasid segadust.

Kui lähtuda, et olin projekti käimatõmbamisel mõne veaga hakkama saanud, siis koodi poolt vaadates oli asi päris palju ilusam. Näha on, et projektiga on kõvasti vaeva nähtud ning köögipoolt oli tunduvalt rohkem kui seda mis välja kuvati. Olen kindel, et tööl on väga hea potensiaal kuid selle saavutamiseks vajaks veel natuke lihvimist ja silumist.

Retsensioonid meeskonna Valar Morghulis veebiteenusele ja klientrakendusele meeskonnalt Artur ja sõbrad

Veebiteenuse retsensioon

Meeskonna „Valar Morghulis“ veebiteenuseks on rakendus, milles kasutajad saavad anonüümselt teistele kasutajatele küsimusi esitada. Rakendus toimib järgnevalt: Kõik saavad sisse logimata otsida kasutajaid ja vaadata küsimusi, mille viimased on vastanud, küsimuse esitamiseks peab aga sisse logima. Isik, kellele küsimus esitati, ei näe küsimuse esitaja andmeid. Kui esitatud küsimus kasutajale ei meeldi, saab selle vastamata kustutada. Administraatorile kaebamise võimalust antud rakenduses ei ole. Kui esitatud küsimus kustutatakse, blokeeritakse küsija võimalus edasisi küsimusi esitada üheks tunniks. Teise järjestikuse kustutatud küsimuse korral blokeeritakse selline võimalus aga 24-ks tunniks. Kõik sisse logitud kasutajad saavad kliendirakendust (ja seega ka veebiteenust) kasutada ainult piiratud mahus. Sama kehtib ka anonüümsete kasutajate kohta (neid eristatakse IP-aadressi põhjal). Mõeldud on ka võimalusele lasta anonüümsetel kasutajatel teha rohkem päringuid kui sisse logitud kasutajatel. Sisse logimine käib kasutajanime ja salasõna kombinatsiooniga. Registreerimiseks tuleb kasutada emaili, registreerijale saadetakse kinnituslink. Email peab pärinema domeenilt @itcollege.ee. Nice to have funktsionaalsustest on välja toodud saidi ülesseadmist hostingupakkujasse ja hostingus oleva kliendirakenduse testimist erinevate mobiilibrauseritega. Projekti kaitsmise ajaks realiseeriti järgnevad punktid: võimalus luua kasutaja üle web-api; sisse logimise funktsionaalsus, mille puhul toimib tokeni hankimine ja kasutamine; küsimuste esitamine. Tegemist vajas Web-api turvalisus, äriloogika kiht ja admin’i liides. Lisatud on ka paar täiendatud projektiversiooni, milles toimib küsimusele vastamine ning mille WebApis on hakatud päringuid turvama. Projekt on lisatud väikese hilinemisega, kuid on meie arvates hästi teostatud, seega tulemus on igati positiivne.

Klientrakenduse retsensioon

Kliendirakenduseks on mobiiliveeb, mis on mõeldud kasutamiseks ekraanidel laiuse alates 480 pikslit. Antud osa teostatakse ASP.NET-i veebisaidina, mis saab andmebaasilt infot läbi veebiteenuse JSON päringute kaudu. Teostamisel on kasutatud põhiliselt Bootstrap’i ja Angular’i.