Talk:Liisa ja Poisid

Retsensioon meeskonnalt Lupardid

Struktuur

XML vastab nõuetele: sügavust on üle miinimumi ning atribuudid on olemas. Nii XML, XSD eraldi kui ka XML XSD põhjal valideeruvad. CDATA kasutust on üleliigselt, eriti kohtades kus XSD määrab ära selle, et elemendi väärtus on arvu kujul. Miks on aasta, kuu ja päev eraldi elemendid mitte atribuudina? Arvutid pole nii aeglased, et teatud kuu kanded kõikidest kannetest üles otsida. Lisaks pole "aasta" nimeline element semantiline (nimi ei kirjelda sisu). Antud lähenemine pole vale aga pole ka mõistlik. Kuna minimaalne sügavus jääb siiski täidetuks tunduks mõistlikum kui oleks järgnevalt:

 <practices>
   <practice startDate="2015-03-14T17:09" endDate="2015-03-14T18:55" weight="85">
       <type><![CDATA[Zumba]]></type>
       <lostCalories>1980</lostCalories>
   </practice>
 </practices>

Skeemifailis on defineeritud täisarvu ja kuupäeva tüübid ning märgitud ka esinemiste arv kommentaari elemendil, see on hea.

Transformatsioonid

HTML'i genereerimine töötab, andmed näidatakse välja. Küll aga on HTML'i enda struktuur väga kehv ning ei valideeru, see polnud vist küll ülesandes vajalik aga et te teaksite. Listide sisse ei panda päiseid ega suuri hulki tekste, lisaks ilma põhjuseta ei pea kõiki elemente ümbritsema teiste elementidega (antud juhul paragrahvi elementidega). XML transformatsioon on võib-olla liiga lihtne aga kuna selle kohta mingeid nõudeid ei olnud siis ütleks, et nutikas lähenemine. Kõik muu on hästi.

Klientrakenduse retsensioon meeskonnalt Lupardid

Olemeid on 6. Olemite väljadel atribuudid kirjeldatud(stringi pikkused, kuvatavad nimed), täpselt nagu nõutud oli.

Pole kasutatud UOWd(on olemas, ninjectis sõltuvused süstitud, kuid pole kuskil kasutatud). Tundub siiski üpris puhtalt ja loogiliselt üles ehitatud projekt. Arvatavasti ei hakatud UOWd kasutama, kuna ei osatud seda korrektselt rakendada ning jäeti see osa lihtsalt implementeerimata.

DTO’d on olemas, viisakad. Iga DTO jaoks loodud ka DTO factory. Service’sid sisaldavad custom meetodeid. Igal service’l olemas interface.

Puudujäägid:

• Registreerides ei tulnud veateateid - tekitas palju frustratsiooni ja segadust, sest ei saanud aru, kas kasutaja sai loodud või mitte.
• Treeningut sisestades ei saanud treeningu kestvust valida(combobox tühi) ning

salvestades jookseb kogu rakendus kotti. Comboboxi asemel oleks võinud kasutada lihtsat textboxi, mis tundub palju loogilisem ja mugavam kasutajale.

• Üks viewmodel kõige jaoks - veidi halb, võiks olla organiseeritum.
• Ma eeldan, et vanuse peaks automaatselt arvutama, kuid seda ta ei tee,

tagastab arvu 0.

• Rakenduse sulgemisfunktsiooni puudumine.

Kokkuvõtteks võib öelda, et projekt on viisakas, kuid jääb tunne, et on jäetud päeva pealt pooleli ning jäetud pisiasjad lisamata/parandamata(detailidesse pole süübitud).

Retsensioonid meeskonnalt KTT

Veebiteenus

SportifyLibrary – olemas on täpselt 6 andmebaasi olemit, mis vastab projekti nõuetele, lisaks sellele on olemas ka identity-ga kaasnevad klassid. Klassides on ilusti märgitud peale kõik vajalikud atribuudid ning lisatud ka display atribuudid, mis muudavad vaated ilusamaks.

DAL - on kasutatud kõiki vajalikke mustreid : Interfaced, repod, helpreid, UOW ja identity-ga kaasnevad klassid. Kuna üldjoontes DAL-i puhul ongi tegu suhteliselt standardse asjaga, mis ülesehitluselt väga ei erine, siis siin ei ole midagi kommenteerida, kõik vajalik on olemas ja nõuded täidetud.

BLL – projekt on aine raames õpetatud heade kommete kohaselt struktureeritud. DTO-d , servicid ja muud suuremad osad on jaotatud eraldi kaustadesse, mis on väga hea. Servicite näol on olemas terve CRUD, ühtegi custom meetodit silma ei hakanud. Üldjoontes on kõik vajalik tehtud ning korrapäraselt. Ainukeseks norimiskohaks võiks olla ObjectDTOFactory kaust, mille kõik klassid oleks võinud väga edukalt ühte klassi, näiteks ModelFactory-sse kirjutada.

Identity – tegu on Andres Käveri poolt antud koodiga, mis on kasutusel kõikidel meeskondadel ning siin ei ole kommenteerida midagi.

DummyDbData – projekti näol on tegemist lihtsalt testandmete lisamisega, mis arvatavasti lihtsustas ja kiirendas testimist.

SportifyWebApi – meeskonna kodulehel on öeldud, et tegu on API-ga, mis ei tööta ning kasutada soovitatakse WebApiAppi. Sellisel juhul oleks vöinud selle projektist üldse eemaldada.

WebApiApp – veebiteenus, millest vaatavad vastu kõik CRUD meetodid vajalike olemitega, mis projektis olemas on. Mingeid muid keerulisemaid meetodeid silma ei hakka, kuid järelikult polnud neid siis vaja. Kuna CRUD on tehtud ja üldjoontes on kasutusel vajalikud olemid, siis vöib öelda, et tööd on tehtud piisavalt ning selle käigus on kindlasti omandatud väärtuslikke teadmisi.

Veebiteenuse kokkuvõtteks ütleks, et aine raames seatud eesmärgid on täidetud, küll minimaalselt, kuid siiski täidetud. Silma jäi see, et üheski kohas ei olnud kommentaare, mitte, et tegu oleks väga keeruka asjaga, mida põhjalikult kommenteerima peaks, kuid hea tava oleks üht-teist siiski kirjutada.

Klientrakendus

Klientrakendus on loodud WPFi näol. Rakendus on üles ehitatud kasutades häid tavasi ning C# aines õpitud MVVMi, mis muudab projekti väga hästi hallatavaks. Kasutatud on enamikke loodud teenuseid ning seeläbi on klientrakenduses funktsionaalsust küll. Ei õnnestunud taaskord leida kommentaare, kood on lihtne, kuid vöiks sellegipoolest veidi kommenteerida. Pannes esmakordselt rakenduse käima, ei saanud ma seda kuidagi enam kinni, sest puudus vastav ristike või nupp login ja register vaates. Lisaks sellele jäi silma, et vaateid on päris palju, kuid olemas on ainult üks vaatemudel. Lühikese jutu kokkuvõtteks ütleks, et kõik on nõudmiste kohaselt struktureeritud, funktsionaalsust on kasutajate halduse näol puudu, kuid sellegipoolest asi töötab ja on piisav.

Retsensioonid meeskonnalt TrainSmart

Veebiteenus ja Klientrakendus

Mees-/Naiskond Liisa ja poisid tegid selle aine raames rakenduse "Sportify", mis kujutab endast treeninpäevikut. Veebiteenuse pool tundub olevat tehtud viisakalt, kasutades erinevaid kihte. Mudelid on ilusti ära annoteeritud, mis on kindlasti kasulik, samas minu silmis segab natuke koodi loetavust. Kontrolleri ja repo vahel on olemas service layer, kus on kirjeldatud erinevad meetodid DTO-de ja listide loomiseks, et neid kontrolleris välja kutsuda. Kontrollerid on suhteliselt lihtsad, ära annoteeritud, tagastatakse ka http status koode, mis tulevad klientrakendust ehitades kindlasti kasuks. Web Api puhul on tagatud turvalisus, kasutades Identityt ning tokenit. Kõik kontrollerid on klassipõhiselt märgistatud [Authorize] annotatsiooniga, samas ei paista välja, et mõni päring oleks piiratud näiteks admin õigustega. Kasutatud on UOW-d, mida kasutati Identity puhul.

Klientrakendust kahjuks rohkem, kui registreerimine testida ei saanud, kuna Api projekti minu VS-s millegipärast ei avanud, ja seega ei töötanud ka veebiteenus. Koodi poolt vaadates, tundub kasutaja jaoks olevat küllaltki mugav ja arusaadav UI. Üllatav oli full screen UI. Natukest ebameeldivust valmistas rakenduse sulgemine, kuna puudus Exit nupp kui selline. Õnneks jooksis mul rakendus sisselogimisel kokku, kuna puudus veebiteenusega ühendus, ühtlasi sain ka rakendusest välja. Üldiselt on klientrakenduse kood hästi organiseeritud ja ära kihistatud. Mudelid on pandud vastavusse JSON-ist tulevate andmetega, kasutatud on service-i kihti veebiteenusega suhtlemiseks. Kuna vaateid on ~7, siis oleks võinud vaatemudeleid olla rohkem kui 1, mis tagaks koodi parema haldamise. Klientrakendust testimata tundub, et erinevate vaadete vahel liikumiseks ei tekitata lihtsalt uusi aknaid kuskile, vaid on kasutatud Switcher klassi, mis vaadete vahetamisega tegeleb. Üldiselt on kood hästi struktureeritud ja vastab aine läbimise nõuetele, samas kommentaaride poole pealt on asi suhteliselt nutune.