Talk:Meeskond:Taandarendajad VR2 - Revision history

Tliblik: /* Meeskonna Vertigo retsensioon veebiteenusele */

2015-06-15T18:04:29Z

Meeskonna Vertigo retsensioon veebiteenusele

← Older revision		Revision as of 21:04, 15 June 2015
Line 97:		Line 97:

	Kokkuvõttes on meeskond ilusti kasutanud nõutud mustreid ning veebiteenus on kodeeritud kenasti. Küll aga, jäid tõenäoliselt ajapuudusest mõned teenuse omadused välja arendamata.		Kokkuvõttes on meeskond ilusti kasutanud nõutud mustreid ning veebiteenus on kodeeritud kenasti. Küll aga, jäid tõenäoliselt ajapuudusest mõned teenuse omadused välja arendamata.


	=Meeskonna Vertigo retsensioon klientrakendusele=		=Meeskonna Vertigo retsensioon klientrakendusele=

Tliblik: /* Meeskonna Vertigo retsensioon klientrakendusele */

2015-06-08T17:02:58Z

Meeskonna Vertigo retsensioon klientrakendusele

← Older revision		Revision as of 20:02, 8 June 2015
Line 80:		Line 80:

	Ü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.		Ü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 veebiteenusele=

			Veebiteenuse analüüs on jäetud esitamata, seega ei ole võimalik tuvastada, mis meeskond algselt kavandas, kuidas see ajas muutus ning kas jõuti sinna, kuhu plaaniti ning täideti püstitatud eesmärgid. Lisaks jäi sellega ka ära meeskonnapoolne selgitus, mida nende loodud teenus peaks endas sisaldama. Teenuse loomisel on tehnoloogiaks valitud ASP.NET MVC Web API.

			Kood on loetav ning kaasa aitavad ka koodis esitatud kommentaarid. Kiidusõnad annaksime ka selle eest, et neile koodijuppidele, mis on välja kommenteeritud, kuid pole ära kustutatud, on samuti lisatud kommentaarid, et oleks võimalik aru saada, mis põhjusel on need sisse jäetud.

			Nõue, et projektis oleks vähemalt 6 andmebaasi olemit, on täidetud. Olemite väljadele on pandud peale piirangud ja kontrollid, mis andmeid võib sisse võtta. Lisatud on ka veateated, mis peaksid aitama kokku võttes kasutajal infot sisestada. Küll aga on mõned piirangud küsitavad, nagu näiteks “Asukoht” peab olema vähemalt 4 tähte. Huvitav lahendus on ka Trainingu puhul, kus kommentaarides on meeskond lisanud, et peaks olema “alguskuupäev ja kellaaeg ?”, kuid lõpuks on otsustatud, et piirdutakse ainult kuupäevaga ja on jäetud DataType.Date. Äriloogilises mõttes, võiks arvata, et treeningu puhul on väga oluline ka algus- ning lõpukellaaeg, kui just pole tegu 48-tunni maratonidega, kus tõesti võib juhtuda, et, piisab ainult kuupäevast.

			Puudulikult on tehtud HTML response’id, kuna kui näiteks proovida sisse logida kasutajaga, mida pole registreeritud, siis jõuame server errorini.

			Tundub, et kasutajate ja kasutajate rollide haldus jäi poolikuks, kuna leidsime küll need kohad koodis, kus olid eelmainitud realiseeritud, kuid need koodijupid olid väljakommenteeritud. Nõue, et teenus peab toetama mitme kasutaja võimalust, on täidetud.

			Hea on näha, et on kasutatud nõutud mustreid ning olemas on DAL, repository’d ja interface’id. Loodud on eraldi konsooli rakendus testimiseks ja äriloogika kiht, kasutatud on UOW raamistikku..

			Kokkuvõttes on meeskond ilusti kasutanud nõutud mustreid ning veebiteenus on kodeeritud kenasti. Küll aga, jäid tõenäoliselt ajapuudusest mõned teenuse omadused välja arendamata.

Apaalo: /* Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon */

2015-06-02T20:23:13Z

Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon

← Older revision		Revision as of 23:23, 2 June 2015
Line 156:		Line 156:
	Üldiselt oli kood hästi üles ehitatud, tabuleeritud ning puhastatud asjadest, mida vaja ei läinud. Projekt tundus, et ei ole veel täielikult valmis, seega midagi on kindlasti veel täiustada ning funktsionaalsuseid lisada.		Üldiselt oli kood hästi üles ehitatud, tabuleeritud ning puhastatud asjadest, mida vaja ei läinud. Projekt tundus, et ei ole veel täielikult valmis, seega midagi on kindlasti veel täiustada ning funktsionaalsuseid lisada.

	'''~~Täidetused~~:''' [Seisuga 30.05.15]		'''Nõuete täitmine:''' [Seisuga 30.05.15]


	Teenuse pakkumist – Peaaegu täidetud, kuna tundub, et meeskond veel projekti muudab, siis võib arvata, et see saab varsti rohkem täidetud.		Teenuse pakkumist – Peaaegu täidetud, kuna tundub, et meeskond veel projekti muudab, siis võib arvata, et see saab varsti rohkem täidetud.

Apaalo: /* Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon */

2015-06-02T20:22:56Z

Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon

← Older revision		Revision as of 23:22, 2 June 2015
Line 158:		Line 158:
	'''Täidetused:''' [Seisuga 30.05.15]		'''Täidetused:''' [Seisuga 30.05.15]

	~~Loodav veebiteenus peab võimaldama:~~

	Teenuse pakkumist – Peaaegu täidetud, kuna tundub, et meeskond veel projekti muudab, siis võib arvata, et see saab varsti rohkem täidetud.		Teenuse pakkumist – Peaaegu täidetud, kuna tundub, et meeskond veel projekti muudab, siis võib arvata, et see saab varsti rohkem täidetud.
Line 173:		Line 172:

	Andmebaasis peab olema vähemalt 6 olemit – 6 olemi olemasolu nõue tundus täidetud olevat.		Andmebaasis peab olema vähemalt 6 olemit – 6 olemi olemasolu nõue tundus täidetud olevat.

			'''Kokkuvõte:'''

			Ka veebiteenud on suures osas meeskonnal loodud ning töötavad. Siiski tundub, et mõnda osa oleks veel vaja täiendada.

Apaalo: /* Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon */

2015-06-02T18:56:36Z

Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon

← Older revision		Revision as of 21:56, 2 June 2015
Line 143:		Line 143:
	'''Üldine:'''		'''Üldine:'''

	Kuna Web-Apit on raskem välimuse kui sellise poole pealt uurida ning vaadata (sest kävitatakse web api pool ning peale seda tehakse edasi puhtalt klientrakenduse vaates), siis tuleb keskenduda rohkem koodi poolele ning porjekti üldisele ülesehitusele. Algselt projektikaustale pilku peale visates, on näha, et tegu on A.Käveri poolt õpetatud õppeaine ASP.NET-i Web-Api koodiga, mis on meeskonna Taandarendajad projektile vastavaks muutnud ning lisanud endale vajalikke asju. Kõik vajalik tundub esmapilgul olemas olevat. Kasutatud on Domain (mudelid), DAL (andmebaas), ConsoleTestApp (testimiseks), Identity (kasutajahaldus), BLL/DTO (äriloogika) ning ~~WebA~~ ja MVC projektivaated.		Kuna Web-Apit on raskem välimuse kui sellise poole pealt uurida ning vaadata (sest kävitatakse web api pool ning peale seda tehakse edasi puhtalt klientrakenduse vaates), siis tuleb keskenduda rohkem koodi poolele ning porjekti üldisele ülesehitusele. Algselt projektikaustale pilku peale visates, on näha, et tegu on A.Käveri poolt õpetatud õppeaine ASP.NET-i Web-Api koodiga, mis on meeskonna Taandarendajad projektile vastavaks muutnud ning lisanud endale vajalikke asju. Kõik vajalik tundub esmapilgul olemas olevat. Kasutatud on Domain (mudelid), DAL (andmebaas), ConsoleTestApp (testimiseks), Identity (kasutajahaldus), BLL/DTO (äriloogika) ning WebApi ja MVC projektivaated.

	Alustades DAL ehk Data Access Layerist on näha, et see on üldiselt hästi ülesehitutatud. Siin on kasutatud UOW printsiipe. Iga olemi kohta on loodud Repository ning vajalikud Interfaced. Vaadates Entity Framework poolset DAL-i on ka seal kõik vajalik olemas: Helpers, Interfaces ja Repositories. Küll aga oli näha Entity Framework contexti all, et projekti loojad olid sattunud Foreign ja Primary key vahelistesse sekeldustesse. Nimelt oli kasutatud mitmes kohas CascadeOnDelete lauseid, mis tähendab et seotud tabelite kustutamisel jäävad mõned tabelit õhku „hõljuma“. See aga kasutab rohkem ressursse ning võib tekitada palju turvariske. Näiteks kui kustutatakse mingi kasutaja ära, siis temaga seotud andmed (näiteks treeningud) jäävad alles, mida on hiljem võimalik siiski näha, kuna need muudetakse ainult „nähtamatuks“. Samuti, kuna see jätab kasutamata kirjed alles, siis see võib tekitada palju vigu nende pärimisel või muutmisel.		Alustades DAL ehk Data Access Layerist on näha, et see on üldiselt hästi ülesehitutatud. Siin on kasutatud UOW printsiipe. Iga olemi kohta on loodud Repository ning vajalikud Interfaced. Vaadates Entity Framework poolset DAL-i on ka seal kõik vajalik olemas: Helpers, Interfaces ja Repositories. Küll aga oli näha Entity Framework contexti all, et projekti loojad olid sattunud Foreign ja Primary key vahelistesse sekeldustesse. Nimelt oli kasutatud mitmes kohas CascadeOnDelete lauseid, mis tähendab et seotud tabelite kustutamisel jäävad mõned tabelit õhku „hõljuma“. See aga kasutab rohkem ressursse ning võib tekitada palju turvariske. Näiteks kui kustutatakse mingi kasutaja ära, siis temaga seotud andmed (näiteks treeningud) jäävad alles, mida on hiljem võimalik siiski näha, kuna need muudetakse ainult „nähtamatuks“. Samuti, kuna see jätab kasutamata kirjed alles, siis see võib tekitada palju vigu nende pärimisel või muutmisel.

Apaalo: /* Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon */

2015-06-02T16:21:50Z

Hubris meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon

← Older revision		Revision as of 19:21, 2 June 2015
Line 105:		Line 105:
	==[https://wiki.itcollege.ee/index.php/Hubris Hubris] meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon==		==[https://wiki.itcollege.ee/index.php/Hubris Hubris] meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon==

	'''KLIENTRAKENDUS'''		'''KLIENTRAKENDUS:'''

	'''Üldine:'''		'''Üldine:'''
Line 117:		Line 117:
	'''Kood:'''		'''Kood:'''

	Igas controlleris on tublisti kasutatud Unit of Work printsiipe ning ka Nloggerit. Kood on ilusti tabuleeritud ning muutujad on arusaadavalt inglise keeles. On siiski märgata, et paljud ViewModelid ning nendega seostuvad Controllerid on suht sarnased, seega mõned olemid on selle järgi võttes vähem. Igas ~~ViewModelid~~, tundub olevat kasutatud annotatsioone, kus neid vaja läheb, piirates sisestuse pikkust või tüüpi. Samuti on pandud vastavatesse kohtadesse tüüpide nimed. Üks asi mis jääb silma, on see, et kuigi Controllerites on kasutatud [Autohorize] tag-i, siis puudub täpsustav roll või kasutajanimi, andes kasutajatele õiguseid, mida neil tegelikult olla ei tohiks.		Igas controlleris on tublisti kasutatud Unit of Work printsiipe ning ka Nloggerit. Kood on ilusti tabuleeritud ning muutujad on arusaadavalt inglise keeles. On siiski märgata, et paljud ViewModelid ning nendega seostuvad Controllerid on suht sarnased, seega mõned olemid on selle järgi võttes vähem. Igas ViewModelis, tundub olevat kasutatud annotatsioone, kus neid vaja läheb, piirates sisestuse pikkust või tüüpi. Samuti on pandud vastavatesse kohtadesse tüüpide nimed. Üks asi mis jääb silma, on see, et kuigi Controllerites on kasutatud [Autohorize] tag-i, siis puudub täpsustav roll või kasutajanimi, andes kasutajatele õiguseid, mida neil tegelikult olla ei tohiks.

	'''Testimine:'''		'''Testimine:'''
Line 136:		Line 136:

	Klientrakenduse pool oli olemasoleva funktsionaalsuse kohta piisav ning hästi tehtud. Küll aga tuleb nõustuda teiste retsenseerijatega ning paluda projekti kohta rohkem dokumentatsiooni või seletust, mida see täpsemalt endast kujutab.		Klientrakenduse pool oli olemasoleva funktsionaalsuse kohta piisav ning hästi tehtud. Küll aga tuleb nõustuda teiste retsenseerijatega ning paluda projekti kohta rohkem dokumentatsiooni või seletust, mida see täpsemalt endast kujutab.

Apaalo at 22:52, 31 May 2015

2015-05-31T22:52:50Z

← Older revision		Revision as of 01:52, 1 June 2015
Line 101:		Line 101:
	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.		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).		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).


			==[https://wiki.itcollege.ee/index.php/Hubris Hubris] meeskonna poolt tehtud veebiteenuse ja klientrakenduse retsensioon==

			'''KLIENTRAKENDUS'''

			'''Üldine:'''

			Meeskonna kodulehel puudus info loodud projekti kohta. Selle tõttu on raske ette kujutleda, mida meeskonna Taandarendajad oma projektiga korda tahtsid saata. Oleks hea, kui meeskonna kodu lehel oleks projekti üldine kirjeldus ning „Must-have“ ja „Nice-to-Have“ analüüs, et luua esialgne pilt projektist. Esmapilgul on kohe märgata, et projekt on ASP.NET Web-Apiga seotud. Seda aga on retsenseeritud hiljem teisel poolel.

			Projekti käivitates on märgata, et aluseks on võetud A. Käveri poole õpetatud projektialus, mida on soovitud projekti kohaselt muudetud. Loodud on mitmeid olemeid lisaks vajalikele Identity olemitele. Iga olemi kohta on loodud ka Controller. Samuti on olemas tähtsamate Controllerite ning View-de vahele ViewModelid, et väljastada ainult vajaminev.

			Üleüldiselt, tundub projekti ülesehitus olevat väga hästi tehtud.

			'''Kood:'''

			Igas controlleris on tublisti kasutatud Unit of Work printsiipe ning ka Nloggerit. Kood on ilusti tabuleeritud ning muutujad on arusaadavalt inglise keeles. On siiski märgata, et paljud ViewModelid ning nendega seostuvad Controllerid on suht sarnased, seega mõned olemid on selle järgi võttes vähem. Igas ViewModelid, tundub olevat kasutatud annotatsioone, kus neid vaja läheb, piirates sisestuse pikkust või tüüpi. Samuti on pandud vastavatesse kohtadesse tüüpide nimed. Üks asi mis jääb silma, on see, et kuigi Controllerites on kasutatud [Autohorize] tag-i, siis puudub täpsustav roll või kasutajanimi, andes kasutajatele õiguseid, mida neil tegelikult olla ei tohiks.

			'''Testimine:'''

			Projekti käivitades on märgata, et välimuselt jätab see soovida. Koduelehelt tervitab kasutajast suur ASP.NETi frameworki reklaam, mida oleks võinud ära vahetada enda projektiga seostuva infoga või meeskonna logo/nimega. Samuti on jäetud muutumata lehe tagataust, olles tavaline valge template. Linkide nimetusi oleks samuti võinud väheke täpsemalt välja tuua. Näiteks tekkis esimesel vaatlusel küsimus, mis vahet on TFinder pealmisel linkil ning Pealeht linkil. Nagu eelnevalt mainitud, oli testimisel näha, et kõik menüüd on seotud [Authorize] tag-iga, mis tähendab, et ilma registreerimata kuskile sisse ei saa.

			Kasutaja loomisel tekkisid ilusti veateated. Parooli sisestuseks sai valitud numbrid 123, mis edukalt kasutaja registreeris. Siinkohal mainiks, et nii lihtne parooli lubamine võib olla turvarisk. Kuigi aga tegu on koolitööga, siis see ei oma nii suurt tähtsust. Kasutaja sai loodud edukalt. Küll aga oli näha, et kasutajanimeks oli kasutatud e-maili. Kuigi see võib ka kasutaja olla, oleks parem kui kasutajanimeks oleks ise valitud nimi. Meeldiv oli see, kuidas ülemisel navigatsiooniribal olid mõned lingid pandud kokku lahtituleva menüü alla, mis muutis riba kindlasti puhtamaks.

			Kasutaja „manage“ alla oli sisse jäetud A. Käveri algupärased valikud, mis tuleks projekti edasi arendades kas korda teha või sealt täielikult eemaldada. Üritades parooli muuta, oli veateateks 6 minimum tähe sisestus, mis tuleks kokku viia kasutaja loomise nõudega, et projekt oleks ühtlasem.

			Kõigepealt prooviti luua trenni tüüpe. Sellel oli samuti pikkuse nõue ilusti olemas. Tüüp loodi edukalt. Küll aga oli näha, et trenni tüüpe ei saanud enam muuta ega kustutada. Üritades seda aadressiribalt muuta, paluti uuesti sisse logida.

			Trenni loomisel oli märgata, et muutmata oli jäänud eelnevalt loodud trenni tüübi nimetus. Nimelt vaatas vastu nimetuseks TrainingTypeId. Meeldis väga see, et kuupäeva valik oli tehtud kalendriga, muutes kasutajale kindlasti valimise tunduvalt lihtsamaks. Nii osalejate arvu kui trenni maksumust oli võimalik miinustesse panna, mille kontroll tuleks koodi sisse lisada, et see võimalik enam ei oleks. Olles trenni loonud, oli märgata, et võimalik on selle detaile vaadata ning seda ära kustutada. Puudu oli aga edit nupp. Siinkohal peaks kindlasti olema mingi seletus, miks oma trenne muuta ei saa. Edit alamenüüle sai aadressiribalt ligi, mis tuleks kas täielikult ära keelata või see siis ikkagi korda teha (muutes oma treeningut tuli JSONi error).

			Rohkemat funktsionaalsust tundus, et siiamaani veel tehtud pole. Olemas oli ka „kõik kasutajad“ alamenüü, kus oli tiitel ning muutujad inglise keeles, mis tulevikus tuleks muuta ülejäänud projektiga ühtlaseks.

			'''Kokkuvõte:'''

			Klientrakenduse pool oli olemasoleva funktsionaalsuse kohta piisav ning hästi tehtud. Küll aga tuleb nõustuda teiste retsenseerijatega ning paluda projekti kohta rohkem dokumentatsiooni või seletust, mida see täpsemalt endast kujutab.


			'''VEEBITEENUS:'''

			'''Üldine:'''

			Kuna Web-Apit on raskem välimuse kui sellise poole pealt uurida ning vaadata (sest kävitatakse web api pool ning peale seda tehakse edasi puhtalt klientrakenduse vaates), siis tuleb keskenduda rohkem koodi poolele ning porjekti üldisele ülesehitusele. Algselt projektikaustale pilku peale visates, on näha, et tegu on A.Käveri poolt õpetatud õppeaine ASP.NET-i Web-Api koodiga, mis on meeskonna Taandarendajad projektile vastavaks muutnud ning lisanud endale vajalikke asju. Kõik vajalik tundub esmapilgul olemas olevat. Kasutatud on Domain (mudelid), DAL (andmebaas), ConsoleTestApp (testimiseks), Identity (kasutajahaldus), BLL/DTO (äriloogika) ning WebA ja MVC projektivaated.

			Alustades DAL ehk Data Access Layerist on näha, et see on üldiselt hästi ülesehitutatud. Siin on kasutatud UOW printsiipe. Iga olemi kohta on loodud Repository ning vajalikud Interfaced. Vaadates Entity Framework poolset DAL-i on ka seal kõik vajalik olemas: Helpers, Interfaces ja Repositories. Küll aga oli näha Entity Framework contexti all, et projekti loojad olid sattunud Foreign ja Primary key vahelistesse sekeldustesse. Nimelt oli kasutatud mitmes kohas CascadeOnDelete lauseid, mis tähendab et seotud tabelite kustutamisel jäävad mõned tabelit õhku „hõljuma“. See aga kasutab rohkem ressursse ning võib tekitada palju turvariske. Näiteks kui kustutatakse mingi kasutaja ära, siis temaga seotud andmed (näiteks treeningud) jäävad alles, mida on hiljem võimalik siiski näha, kuna need muudetakse ainult „nähtamatuks“. Samuti, kuna see jätab kasutamata kirjed alles, siis see võib tekitada palju vigu nende pärimisel või muutmisel.

			Meeldiv oli näha, et projektis oli olemas ka äriloogika seletus. Seal tundus olevat DTO treeningute kohta. Küll aga ei näinud väga suurt vahet sealsete klasside ning mudelis olevate klasside vahel, seega on näha et vaheldus käib täies mahus.

			Paljudes kohtades on näha, et http errori vastused pole täielikult kirjeldatud või täpsustatud, mis võib tekitada kliendile ebameeldivusi kui tegu oleks suurema projektiga.
			Ka Web-Api poolsed kasutaja õiguste kontrollid on poolikud ning ei ole täielikult täpsustatud. Olemas on küll nii MVC poolne kui Web-Api poolne Identity ning Web-Api poolel on olemas Claims, mis kasutajaid kontrollib. Puuduvad siiski kasutajate rollide erinevused ning õiguste erinevused. See tähendab, et hetkel võivad kõik kasutajad kõike muuta. Siin kohal oleks hea andmebaasi algselt sisse seedida mõned algsed väärtused treeningute tüüpidele ning samuti üks Admin kasutaja, kellel on kõik õigused olemas.

			Api poole pealt ei oldud välimust muudetud. Kuigi see ei olnud otsene nõudmine, siis soovitusena võib pakkuda ideed, kus muuta Web-Api esialgne vaade stiilseks tervituseks või viia Web-Api ning kliendirakendus üksteisega kokku.
			Märgata oli, et tehtud ei ole statistika loomist ning haldamist. See muudab päringute loomise raskemaks. Kuna projektil puudus ka esialge dokumentatsioon, siis on üleüldiselt projekti jaoks vähe statistikat ja seletusi.
			Üldiselt oli kood hästi üles ehitatud, tabuleeritud ning puhastatud asjadest, mida vaja ei läinud. Projekt tundus, et ei ole veel täielikult valmis, seega midagi on kindlasti veel täiustada ning funktsionaalsuseid lisada.

			'''Täidetused:''' [Seisuga 30.05.15]

			Loodav veebiteenus peab võimaldama:

			Teenuse pakkumist – Peaaegu täidetud, kuna tundub, et meeskond veel projekti muudab, siis võib arvata, et see saab varsti rohkem täidetud.

			Teenuse kasutajate tuvastamist ning haldamist – Töötavad edukalt sisselogimine ning registreerimine. Puudu oli AllUsersi alla toodud kasutajad (loodud kasutajaid ei lisatud nimekirja). Manage oli default template, kuhu oli sisse jäetud ebavajalikud funktsioonid.

			Teenuse kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes – Kasutajaid vaadata ei saanud. Samuti puudus üleüldine statistika.

			Teenuse poole pöördumiste arvu piiramist ja piirangute haldamist – Piirangud olid Authorize-ga piiratud, küll aga puudus rollide jaotus.

			Loodav veebiteenus peab toetama mitme kasutaja võimalust. – Kasutajaid saab edukalt mitu tükki teha ning erinevalt sisse logida.

			Loodav veebiteenus tuleb luua kasutades Windows Communication Foundation või ASP.NET MVC Web API tehnoloogiat – Teenus oli edukalt ühendatud ASP.NET MVC ja Wep Api tehnoloogia.

			Andmebaasis peab olema vähemalt 6 olemit – 6 olemi olemasolu nõue tundus täidetud olevat.

Tliblik: /* Meeskonna Vertigo retsensioon klientrakendusele */

2015-05-31T14:44:39Z

Meeskonna Vertigo retsensioon klientrakendusele

← Older revision		Revision as of 17:44, 31 May 2015
Line 94:		Line 94:
	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 inglisekeelsed. 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.		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 inglisekeelsed. 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).		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 ka 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?		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?

Tliblik: /* Meeskonna Vertigo retsensioon klientrakendusele */

2015-05-31T14:43:41Z

Meeskonna Vertigo retsensioon klientrakendusele

← Older revision		Revision as of 17:43, 31 May 2015
Line 92:		Line 92:
	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.		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.		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 inglisekeelsed. 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).		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).

Tliblik: /* Klientrakendus */

2015-05-31T14:39:06Z

Klientrakendus

← Older revision		Revision as of 17:39, 31 May 2015
Line 80:		Line 80:

	Ü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.		Ü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).