Talk:Meeskond:Taandarendajad VR2

Veebiteenuse retsensioon meeskonna Tab poolt

Peale Identity mudelitele on meeskonnal veel 6 olemit. Olemites olevad stringid on ilusasti piiratud ning isegi datetime'd on annotatsiooniga tüüp paika pandud, kuid selleks on imelikul kombel Date mitte DateTime. Vea sõnumid on ka kirjutatud. Oma olemitele on enamus ridadele peale kirjutatud Display name, mis teeb rakenduses olemite kujutamise kergemaks.

Veebiteenuse DAL on ehitatud nõuetekohaselt. Olemas on helper'd, interface'd ja repo'd, milles mõnel on kirjutatud vajaminevaid päringuid DbSeti vastu. Probleeme võib tekitada WebAppEFContext, kus meeskond on oma tabelite cascade kustutamised maha võtnud. See tähendab, et iga kirje kustutamisel tuleb teha ise kontrolli, kas teistes tabelites on vastava id-ga objekt enne kustutatud või kuidagi asendatud, et ei tekiks andmebaasis probleeme.

BLL-is on ära kirjeldatud ka treeningutele DTO, kuid see tagastab täies mahus sama treeningu, mis sinna sisse pandi. Sellest võib järeldada, et kõik info, mis saadetakse veebiteenusest klienti, on üldjuhul pikkade graafidena.Väikeste andmemahtudega see tõenäoliselt ei tekita ebameeldivusi. Probleem tekib olukorras, kus kirjeid tuleb palju. Kui päritakse kasutaja siis sellega tuleb kaasa ka kasutajatüüp ning sellega ka list kõikidest kasutajatest, kellel on see tüüp. See võib tekitada tulevikus probleeme.

Kasutajate tuvastamiseks ning haldamiseks kasutasin nende klientrakendust, mis neil on ehitatud sama veebiteenuse poole ja üllatuseks leidsin, et kasutajatele ei panda rolle külge. Lähemalt uurides leidsin, et kliendil on olemas kogu kasutaja ja ta rollide muutmise võimalus, kuid see on lihtsalt välja kommenteeritud layout-st.

Lõpptulemuseks on see, et kuigi kasutajad on olemas ning neid on võimalik hallata, siis õigusi pole kasutatud. Rääkimata turvalisuse poole pealt, et kas kasutajal on õigus midagi muuta. Veebiteenuse poole pealt pole mingeid erilisi kontrolle, et kas on õigus andmeid vaadata või mitte. Võib lihtsalt api lahti teha ning hakata andmeid vaatama.

Statistikat ei peeta, mis teeb ka päringute piiramise võimatuks. Logimine on tehtud NLog loggeriga kohtades, mis on automaatselt loodud. Meeskonna enda poolt pole dokumentatsiooni ega loggimist.

Kokkuvõtteks võiks öelda, et meeskond on hästi kasutanud raamistikku. Probleemiks on aga nende äriloogika.

Klientrakenduse retsensioon meeskonna Tab poolt

Meeskonna klientrakenduseks on treeningutele registreerimise rakendus. Rakendus on ehitatud nende poolt loodud veebiteenusele.

Treeninguid saab luua ning nendele saab registreerida. Lisaks on rakendusel sotsiaalmeediale vastav pool, kus kasutajaid saab jälgida, mille tulemusel tekib pealehele nende poolt koostatud treeningud. Kasutajad saavad üksteisele tagasisidet jätta ning neid saab ka blokeerida, mille tulemusena blokeeritud kasutajad ei saa blokeerija treeningutele registreerida.Oleks võinud ka jälgimist ja tagasiside andmist piirata ning üldse peita kasutaja ilmnemist blokeeritud kasutajast, kuid neid võimalusi pole.

Koodi poole pealt on kasutatud korralikult UOW raamistikku: repo'd, interface'd. Huvitav on märgata, et UOW-s on baseurl, mille poole pöördutakse, klassi peal. Tore on näha, et on üritatud seda eraldada ülejäänust. See võimaldab kerget muutust olukorras, kui veebiteenus on kuskil mujal. Selel asukoht oleks võinud olla eraldi konfiguratsioonis. Vaatemudeleid on küllaga kasutatud, meeskonna enda koodis pole viewbag-e näha.

Tokenid töötavad korralikult. Kasutajaga peab uuesti sisse logima, kui projekt taaskäivitatakse.

Järgnevalt tulevad probleemsed kohad.

Sisse logides väära emailiga jookseb leht kokku kollase surmalehega. See näitab, et html response’d pole päris korralikult tehtud.

Oma andmeid pole võimalik muuta. Sarnase sotsiaalmeedia taustaga rakenduses võiks vähemalt olla nime lahter, millega on parem kasutajaid tuvastada.

Kasutajate ja rollide haldus on olemas, kuid see on välja kommenteeritud. Tehniliselt kasutajate haldus ka töötab, kuid kuna cascate kustutamine on veebiteenusest maha võetud, siis jookseb leht kokku, kui kasutajal on vähemalt 1 seos millegiga. Lisaks näitab kasutajate muutmisel securitystampi ja passwordhashi, mis on loomulikult halb. Meeskonna enda tabelite kustutamisel pole probleemi, sest äriloogikas on see käsitsi ära tehtud, kuid neid kahjuks ei saa jällegi kuidagi muuta, sest see on välja kommenteeritud. Kommenteerimise maha võttes muutmine jällegi jooksutab lehe kokku.

Kokkuvõtteks võiks öelda, et näidati ainult neid omadusi, mis töötasid. Kõik ülejäänud kommenteeriti välja. Meeskond kasutas raamistikku hästi ära. Probleemiks jäi äriloogika, kus ei realiseeritud kõike olemasolevat.

ALTER eGO veebiteenuse ja klientrakenduse retsensioon

Teenus

Meeskond on loonud RESTful teenuse ning võttes arvesse, et meeskonna lehekülg Wikis on väga minimalistlik, kus kohast ei leidnud otseselt projekti/teenuse analüüsi, siis peab projekti koodist välja lugema, mis teenusega täpsemalt tegu on. Teenuse tehnoloogiaks on valitud ASP.NET MVC Web API ning teenus peaks võimaldama kasutajatel erinevate treeningutega seonduvat informatsiooni luua ja hallata.

Projekt on jaotatud alamprojektideks, mis annab ülevaate sellest, millistest nii-öelda komponentidest projekt koosneb. Loodud on konsoolirakendus testimise eesmärgil, andmekihid, olemite kogu, äriloogikakiht, WEB API teenus ise ning ASP.NET MVC veebirakendus. Kasutusele on samuti võetud ka Identity kasutajate haldamiseks. Sellise ülesehitusega projekt annab paindlikkuse muudatuste tegemiseks.

Domain kaustas on lisaks Identity olemitele veel kirjeldatud teenuse olemid, mida on täpselt 6 ning sellega vastab andmebaas ka nõutule. Olemite ja nende väljade nimetused annavad peale vaadates selge ülevaate sellest, mis andmeid võidakse hoida. Seejuures on olemite väljadel ka sisendite kontrollid ning veateated juhtudeks, mil sisend on ebakorrektne ja vaja kasutajat teavitada teda tabanud ebaõnnest. Mudelite väljadele on määratud sobivad eesti keelsed nimetused välja kuvamiseks.

Andmekihis on kasutatud interface’e ja repository mustrit, samuti on kasutusel ka unit of work ehk nõutav on realiseeritud. Selguse loomiseks ning hoidmiseks on loodud andmekihid vastavalt WEB API teenusele ning MVC veebirakendusele. Samuti on teenuse ning rakenduse tarvis loodud eraldi Identity kasutajate haldamiseks.

Seejuures on huvitav see, et nii mõneski projekti andmekihti loodud repos on kirjeldatud veel spetsiifilisi meetodeid vajalike andmete pärimiseks ehk juba repodes realiseeritud meetodite põhjal näeb ära, et ei ole piirdutud pelgalt CRUD operatsioonidega. Koodi põhjal on näha, et loodud on ka erinevate tegevuste, päringute jaoks logimise võimalus. Paraku isklikult ei õnnestunud kuidagi logi kirjeid loodud platvormiga nii-öelda juurde tekitada.

Äriloogikakihis on üks DTO, mis tagastab treeningu objekti infot ning selle tarbeks on loodud ka teenus, mis tagastab konkreetse kasutaja kõik treeningud, rohkema järele ei ole tõenäoliselt vajadust nähtud.

WEB API teenus asub samanimelises alamprojektis. Vastavalt loodud olemitele on kirjeldatud kontrollerites vajaminevad CRUD operatsioonid. Samuti on realiseeritud, kasutusele võetud repodes loodud spetsiifilisemad meetodid. Kontrollerites on samuti näha, et kasutatakse unit of work’i andmesuhtluseks nagu nõutud. Teenusega suhtlemine toimub JSON andmeformaati kasutades.

Projekti tegemisel on järgitud arendusmustreid, teenus struktuuri ning koodi poolest on hästi vormistatud ja läbimõeldud. Seejuures ei häirinud isegi kommentaaride vähesus, sest tegemist oli loetava koodiga ning natukese süvenemise järel sai selgust.

Klientrakendus

Klientrakendus oma välimuse poolest sulandub ühte kõigi teiste vaikimisi, out of the box MVC rakendustega. Kui aga välimus kõrvale jätta, siis keskenduda sisule.

Klientrakenduse puhul oleks eeldanud siiski mingisugust detailsemat dokumentatsiooni, kui seda on hästiloetav lähtekood, sest sel juhul saaks aimu täpsemalt, mida kasutaja tegema peab, et kõik olemasolev, loodud funktsionaalsus katsetatud ja proovitud saaks. Sellegi poolest rakendus töötab, kuid kasutajamugavuse aspektist nõuab natuke süvenemist.

Kasutaja on võimalik registreerida ning temaga sisse logida. Ahjusoojale kasutajale kuvatakse teadet, et võiks end registreerida mõnele treeningule. Menüüs erinevate valikutega mängides on võimalik lisada trennitüüpe ning treeninguid. Mis aga puudutab treeningu lisamist, siis probleemne on esialgu algus- ja lõpukuupäeva lisamine, nimelt isegi veateate abil ei ole võimalik ära arvata, missuguses formaadis/kujul peaks kuupäeva sisestama. Sellest tulenevalt oleks olnud muidugi suurepärane, kui kuupäevade valik oleks olnud lahendatud mõne datepicker lahendusega.

Mis puudutab maksimaalset osalejate arvu ning trenni maksumust, siis siinkohal on võimalik ka negatiivse sisendi anda. Tegelikkuses sellist asja ei tohiks lubada.

Küll aga saavad sportlased omavahel tagasiside raames sõnumeid jätta. Samuti on võimalik kaaskasutajate treeningutega ühineda, kuid eriti mugav oleks, kui saaks esilehel näha kohe kõiki treeninguid ning seejärel filtreerida välja ainult nende kasutajate treeningud, keda oled jälgimas.

Kui natukene rakendusega tegeleda, siis mõistab, et iga registreeritav kasutaja on nii-öelda treener, ehk praegusel juhul on tegu platvormiga, kus treenerid omavahel saavad luua treeninguid, neid hallata, nendest osa võtta. Samuti saavad nad teisi treenereid blokeerida, et nad ei saaks ühineda loodud trenniga ning soovi korral saavad jätta tagasisidet.

Rakenduses võimaldatakse kasutajate tuvastamist ning haldamist, kuid tundub, et iga registreeritud kasutaja on justkui admin rollis ning sellest tulenevalt saab soovi korral „Kõik kasutajad“ sektsioonis kaaskasutaja blokeerida. Seega paistab, et konkreetne rollide/õiguste andmine, määramine puudub.

Isegi, kui eelmainitu on puudus, siis tegelikkuses võib olla konkreetne rakendus just treeneritele suunatud - koolitamiseks, harimiseks erinevate spordialade, treeningtüüpide osas.

Mis puudutab kliendirakenduse köögipoolt, siis kontrollerites paistab samuti silma, et CRUD operatsioonide tegemiseks piisab sellest, et kasutaja on end autentinud ning õiguste gruppe, autoriseerimist ei nõuta. Sellegi poolest on kontrollerid ilusad ühes unit of work’i kasutusele võtmisega.

Seejuures on kuvade tarvis loodud ViewModel objektid, et vaates välja näidata vaid vajaminev.

Üldjoontes on klientrakendus hästi tehtud, töötab, kood on arusaadav. On näha, et aega ning mõttetööd on siinse projekti puhul rakendatud.

Meeskonna Vertigo retsensioon klientrakendusele

Meeskond on loonud veebirakenduse omaloodud veebiteenusele.

Registreerimine ja sisselogimine toimib. Kui üritada sisse logida suvalise kasutajaga, ei kuvata kasutajale talle mõistlikku veateadet ega selgitust. Kui registreerida kasutaja, ei anta samuti kasutajale infot, kas registreerimine õnnestus või mitte ning mida kasutaja saab edasi teha. Küll aga on hästi tehtud see, et sisse logides on lisatud tore tervitusinfo ning lauserida, mis annab mõista, mida rakenduses üldse teha saab.

Rakenduses pole võimalik kasutada ühtegi funktsionaalsust, kui ei olda registreerinud ja sisseloginud. Samas, kui olla sisse loginud, siis on kasutatavad kõik funktsionaalsused. Seega, hetkel puudub jaotus tavakasutaja vs nn admin-kasutaja, mis tähendab, et pole ka võimalik õigusi ja rolle jagada. Tundub, et nii mõndagi veel on koodina kirja pandud, kuid mingil põhjusel välja kommenteeritud, nii et hetkel rakendust kasutades ei saa neid katsestada.

Arusaamatuks jääb ka, mida tähendab kasutaja blokeerimine? Esimestel katsetustel tundus, et blokeeritud kasutaja sai blokeerijat ikkagi jälgida ja saata tagasisidet. Siinkohal tunneme jällegi suurt vajadust meeskonnapoolse dokumentatsiooni ja teenusekirjelduse järgi.

Uut treeningut luues, on võimalik sisestada kuupäevad. Siinkohal pole tegemist väga kasutajasõbraliku lahendusega, kuna väli on arvestatav rakenduse poole pealt kuupäevaks ainult siis, kui esitus on /-de abil, kuid selleni peab kasutaja ise katsetades jõudma. Lisaks on treeningu tüübi esitlusväli jäänud TrainingTypeId-ks, mis tavalisele kasutajale ei ütle midagi. Terminid on rakenduses läbi segi eesti- ja inglisekeelse. Tundub, et mõnes kohas on neid kohandatud ning teises kohas on jäänud need, mis tulevad otse andmebaasi tabelite nimedest. Kui luua uus treening ja sisestada kõik väljad, nagu nõutud (tore on näha, et mõned väljad on vajalikud ning mõndadel väljadel on piirangud, näiteks nagu kohanimi ei tohi olla väiksem, kui 3 tähemärki, mis on iseenesest hea mõte, kuid Aa rand ei pääseks ainult nimega läbi), siis treeningut luues tuleb järgmine veateade The ViewData item that has the key 'Training.TrainingTypeId' is of type 'System.Int32' but must be of type 'IEnumerable<SelectListItem>'. Seega ei õnnestunud meil omaloodud treeningu tüübiga treeningut luua.

Kasutajaloogika rakendust kasutades on kokkuvõttes siiski päris hästi teostatud. Käigud on kasutaja jaoks loogilises järjestuses. Näiteks registreerimine on eraldi pakutud sisselogimise all. Lisaks on loodud omajagu vaateid ning kasutajal on võimalik päris paljut korda saata rakenduses (olenemata sellest, et infot, mida saab teha, ei ole).

Oleksime väga tahtnud näha dokumentatsiooni. Rakendus ei ole peale vaadates iseennast selgitav. Kuna meeskond pole esitanud ei projekti analüüsi ega dokumentatsiooni, siis võime ainult eeldada, mis probleemi loodu lahendab ning mida sellega teha saab. Kaasa oleks aidanud ka esilehel mõningane kujundus, kirjeldus või selgitav tekst rakenduse kohta. Kahjuks on esileht aga jäetud selliseks, nagu ta originaalis luues on. Sisselogides ilmunud tervitustekstis “Registreeri end mõnele treeningule!” annab kasutajale vähemalt mingi vihje, milleks rakendust kasutada. Lähemal vaatlemisel selgub, et sisselogides avaneb selline asi, nagu Esileht. See teadmine tekitab küsimusi, miks on eraldi leht, mille sisu pole kohandatud ning mis avaneb rakendust avades - TFinder ja Esileht, mis on ligipääsetav ainult sisse logides, eraldi? Kas äriloogika mõttes, on mõeldud, et TFinder on nö korporatiivse sisuga leht ja Esileht on kasutaja jaoks funktsionaalse sisuga leht?

Äriloogika koha pealt, ei ole arusaadav (ja kahjuks pole ka dokumentatsiooni, kus oleks seda kirjeldatud), mis väärtuse annavad rakenduses olevad võimalused kedagi blokeerida ja järgida. Kuigi tundub, et tegemist on rakendusega, mida võiks reaalselt kasutada. Igati kiiduväärt on asjaolu, et meeskond on lisanud enda koodi kommentaare, mis aitavad hästi koodi loetavusele kaasa. Mõnes kohas on isegi lahenduse allikas kommenteeritud sisse. Samas on jäetud mitmel kohal sisse väljakommenreeritud koodijupid, mille puhul pole lisatud selgitusi nende olemasolu vajalikkuse kohta. Kokkuvõttes, on näha, et meeskond on näinud palju vaeva klientrakenduse loomisel. Rakendus on sisukas ja mitmete funktsionaalsustega. Pea kõik funktsionaalsused, mis rakenduses on võimalik teha, toimivad hästi (või vähemalt nii, nagu meile tundub, et nad peaksid toimima).