Talk:Team SPOT - Revision history

Kkilgi: /* Meeskond CoverMe retsensioon meeskonnale SPOT */

2017-06-15T06:06:34Z

Meeskond CoverMe retsensioon meeskonnale SPOT

← Older revision		Revision as of 09:06, 15 June 2017
Line 108:		Line 108:
	Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.		Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.

	== Meeskond CoverMe retsensioon meeskonnale SPOT ==		= Meeskond CoverMe retsensioon meeskonnale SPOT =

	Meeskonna eesmärk oli luua veebiteenus, mis võimaldab saada infot pakutavate treeningute kohta, sisestada ja kuvada tunniplaani andmeid, registreerida osalejaid tundidesse ning end sealt eemaldada. Samuti oli ette nähtud, et administraatorid saavad lisada, muuta ja kustutada kõike sprodiklubiga seonduvat ning treenerid ja spordiklubi esindajad saavad toimetada treeningutega seotud andmete sisestamise ja muutmisega. Andmebaasimudel on tehtud väga põhjalikult ning tabelite kirjeldused on samuti välja toodud.		Meeskonna eesmärk oli luua veebiteenus, mis võimaldab saada infot pakutavate treeningute kohta, sisestada ja kuvada tunniplaani andmeid, registreerida osalejaid tundidesse ning end sealt eemaldada. Samuti oli ette nähtud, et administraatorid saavad lisada, muuta ja kustutada kõike sprodiklubiga seonduvat ning treenerid ja spordiklubi esindajad saavad toimetada treeningutega seotud andmete sisestamise ja muutmisega. Andmebaasimudel on tehtud väga põhjalikult ning tabelite kirjeldused on samuti välja toodud.

Kkilgi at 06:05, 15 June 2017

2017-06-15T06:05:35Z

← Older revision		Revision as of 09:05, 15 June 2017
Line 107:		Line 107:

	Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.		Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.

			== Meeskond CoverMe retsensioon meeskonnale SPOT ==

			Meeskonna eesmärk oli luua veebiteenus, mis võimaldab saada infot pakutavate treeningute kohta, sisestada ja kuvada tunniplaani andmeid, registreerida osalejaid tundidesse ning end sealt eemaldada. Samuti oli ette nähtud, et administraatorid saavad lisada, muuta ja kustutada kõike sprodiklubiga seonduvat ning treenerid ja spordiklubi esindajad saavad toimetada treeningutega seotud andmete sisestamise ja muutmisega. Andmebaasimudel on tehtud väga põhjalikult ning tabelite kirjeldused on samuti välja toodud.

			Meie hinnangul on eesmärk põhiosas täidetud, realiseeritud on enamus kavandatud must-have funktsionaalsusest (välja on jäänud logimine). Loodud on veebiteenus, mis kasutab REST arhitektuuri ja ASP.NET MVC Web Api tehnoloogiat.

			Veebiteenuse struktuur on üles ehitatud kihiliselt, mis võimaldab vajadusel süsteemi osasid lihtsamini muuta, täiendada ja vajadusel välja vahetada. Kihid on jaotatud järgmiselt:

			BL - sisaldab DTO-sid ja nende koostamiseks vajalikke Factoreid. Samuti on siin Service klassid, milles on kirjas kõik päringud andmebaasist (Get mitmesugustes variantides, Add, Edit, Delete). Lisaks tavalistele CRUD meetoditele on tehtud ka spetsiifilisemad päringud , näiteks GetByIdForUser jne. Päringuid tehakse uow-de kaudu. Service’tele ja Factory’tele on loodud Interface’d.

			DAL - kasutatakse EFRepositoryFactory ja EFRepositoryProvidery põhimõtteid. DbInitializeris antakse ette lähteandmete seed’imine. Repositooriumid on omaette kaustas, kuhu on lisaks EFRepository-st päritud meetoditele juurde kirjutatud palju erinevaid meetodeid funktsionaalsuse täiendamiseks.

			Domain - andmebaasi mudelis on kokku 12 olemit, mis on nõuetele vastav. Üldine andmebaasimudeli ülesehitus on loogiline ning listid on algselt väärtustatud, mis tagab selle, et ei pea NullReference Exceptione kontrollima. Vajalikesse kohtadesse on annotatsioonid juurde lisatud ja nendega ei ole üle pingutatud, et süsteemi liiga kirjuks ajada. Tõstame esile asjaolu, et kasutatud on Base Entity’t, millest kõik ülejäänud olemid pärinevad. See ühtlustab rakenduse koodi ja on üldse väga hea mõte. Kasutatud on palju nullable tüüpi muutujaid, mis on antud juhul õigustatud, andes andmete sisestamisel paindlikkust, samas lisades mõneti riskantsust.

			Interfaces - Kõikide repositooriumide jaoks on loodud ka interface´d. Samuti leidub seal UOW jaoks interface.

			WebApi - Kokku on kasutusel 6 kontrollerit, milles on realiseeritud CRUD meetodid koos mõne spetsiifilisema meetodiga (näiteks GetFilteredForPeriod). Kontrollerid saavad oma sisu vastavatest service’itest. Identity rakendamiseks on kontrollerite meetoditel kasutatatud Authorize annotatsioone. Samuti on läbi mõeldud, et mõnda meetodit on autoriseeritud kasutama ainult “Admin”-kasutaja. Näiteks ainult “Admin”, saab salvestada treenereid andmebaasi. Kontrollerites on kenasti kasutatud erinevaid Http-staatuskoode, mitte ainult Ok(), vaid ka Forbidden(), NotFound() jne. Samuti kasutatakse edukalt sõltuvuste süstimist (Dependency Injection). Kasutatud on OAuth bearer token authentication’it.

			Lisaks peame oluliseks märkida, et kood on kirjutatud heas stiilis, kõikjal inglise keeles, ei esine keelte segunemist. Paljudes kohtades oli kood kommenteeritud, kuid see tundus olevat ise kaasa tulnud. Meeskonna enda kommentaare ei paistnud.

			Kokkuvõtteks võib öelda, et tegemist on väga hästi kavandatud ja realiseeritud veebiteenusega ja meeskonnaliikmete panus on olnud märkimisväärne, eriti arvestades seda, et tegemist oli vaid kahe liikmega.

Hantsov at 22:05, 14 June 2017

2017-06-14T22:05:08Z

← Older revision		Revision as of 01:05, 15 June 2017
Line 36:		Line 36:

	Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud.		Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud.


			=Retsensioon meeskonna Team SPOT veebiteenusele=

			Retsensioon meeskonna [https://wiki.itcollege.ee/index.php/Team_SPOT Team_SPOT] veebiteenusele meeskonna [https://wiki.itcollege.ee/index.php/A$unik A$unik] poolt.

			Taaskord (nagu meeskonna [https://wiki.itcollege.ee/index.php/Ticketer Ticketer] klientrakenduse retsensiooni tehes) jäi esimese asjana silma rakendust alla laadides see, et pole eemaldatud obj ja bin faile. See teeb lähtekoodi paki mõttetult suureks: antud rakenduse puhul ~200MB. Lihtne variant oleks need kaustad välistada (GIT korral) .gitignore failis ja siis linkida repo kloonimiseks.


			Veebiteenuse eesmärgiks on väljastada ning vastu võtta andmeid treeningute kohta. Järgnevas retsensioonis lähtutakse SPOT meeskonna lehel olevast analüüsist, projekti koodi vaatamisest ning Postman-iga tehtud päringutest teenuse vastu, et hinnata tehtut (vähesel määral sai ka klientrakenduse abil brauseri võrguliikluse kaudu veebiteenusele tehtavaid päringuid uuritud).

			'''„Peaks olema“ sektsiooni analüüs vaadates veebiteenuse koodi'''

			Implementeeritud on:

			1. kasutajate loomine;

			2. autentimine;

			3. klubide, treenerite ja treeningute info väljastamine;

			4. tunniplaani info väljastamine;

			5. treeningutesse registreerimine;

			6. registreeringu tühistamine;

			7. piirangute haldamine (autoriseerimise näol – heites aga kiire pilgu klientrakendusse, siis seda ei kasutatud seal või siis polnud realiseeritud selles funktsionaalsusi, mis seda vajaks).

			Puudu on:

			1. teenuse poole pöördumiste arvu piiramine (sellega seotult on küll määratud IdentityConfig.cs failis MaxFailedAccessAttemptsBeforeLockout muutuja, kuid detailsemaid kontrolle selle nõude lahendamiseks ei märganud).

			Enam-vähem olemas:

			1. kasutajate ja kasutusstatistika logimine – kasutusstatistikat saab vahetabelitest kätte küll, aga seal on abiks olevaid välju, mida ei kasutata (nt CancelledAtDt, CancelledBy, CreatedBy jne).

			Veebiteenuses on lisaks jõutud implementeerida ka „Võiks olla“ sektsioonist funktsionaalsusi nagu:

			1. klubide, treenerite, treeningute lisamine ja muutmine;

			2. tunniplaanis treeningute tühistamine.

			'''Praktiline teenuse testimine ja avastatud vead:'''

			Klientrakenduse põhjal ja brauseri tööriistade alt päringuid vaadates selgus, et GET päringud töötavad ning töötab ka sisselogimine ja registreerimine (viimased kaks on muidugi peamiselt Identity templiitidega juba realiseeritud funktsionaalsus). Püüdes Postman-iga POST, PUT, DELETE päringuid teha õnnestusid enamused neist, mis on hea. Mõned vead siiski avastatud sai TrainersController-is ja RegistrationsController-is.

			1. POST /api/trainers ehk treeneri loomine ebaõnnestub. Andmebaasi kirje küll luuakse, aga DTO tagastamisel tundub, et mapping on vigane.

			2. PUT /api/trainers/:id küll töötab täis andmekomplekti korral, kuid JSON-ist trainerId eemaldamisel taaskord tagastatav Dto ''mapping'' ei arvesta sellega ja server tagastab staatuse 500.

			3. PUT/DELETE api/registration – siin võiks olla lisaks GetByIdForUser kontrollile "admin" rolli kontroll, kes saaks siis nii või teisiti neid andmeid muuta. Lisaks, kui GetByIdForUser on mõeldud selleks, et kasutaja saaks ainult omi andmeid muuta, siis miks siin teenus lubab muuta userId välja, mis tähendab, et üks kasutaja saab registreerimise määrata endalt teisele kasutajale.

			See tähendab, et puudu on pisut veahaldust, kui kõik ei toimu nö ''happy path'' viisil, kus tuleb täpselt oodatud andmekogum kontrollerisse. Üldmulje praktilisest testimisest on aga hea. Kontrollerite järgi sai hästi pildi ette, mis andmeid nad ootavad ja mida kontrollitakse nende juures ning neid polnud raske Postman-iga tööle saada.

			'''Projekti struktuur, koodi ülesehitus ja kasutatud mustrid'''

			Positiivsed aspektid:

			Projekti üldine struktuur on loogiline. On eraldi projektid põhiosade jaoks - DAL, Domain, Identity, WebApi, DTO-ga seonduv projektis BL.
			Kasutatud on ''dependency injection''-it Ninject näol. Andmebaasiga suhtlus kontrollerites toimub Service ning UOW objektide abil. UOW-s on defineeritud ilusti kõik vajalikud repositooriumid. Repositooriumites on kohati ka lisameetodeid ja mitte kasutatud ainult neid, mis tulevad projektipõhjaga kaasa. Kasutatakse liideseid objekti tüübina ja mitte implementatsiooni ennast. Kontrollerites võetakse vastu ja tagastatakse DTO-sid, mitte otse andmebaasi minevaid objekte. Olemitel „Domain“ projektis on kasutatud valideerivaid annotatsioone. Neid võinuks ehk lihtsalt rohkem olla.

			Oleks võinud parem olla:

			Äkki oleks võimalik see MVC projekt, mis WebApi sees on ja mõeldud API dokumenteerimiseks, tõsta eraldi kausta? See on tõenäoliselt lihtsalt templiidiga loodud, aga teeb taolisel kujul WebApi projekti struktuuri segaseks. Eriti häirib seejuures need MVC poolt kasutatavad frontend faile hoidvad kaustad nagu „Content“, „Views“ ja „Scripts“.

			Domain, Interfaces ja DAL projektis võiks kasutada objektide kaustadesse jaotamist, et tekiks ülevaade seotud funktsionaalsusega klassidest. Lisaks on mõnel pool jäänud sisse palju väljakommenteeritud koodi (ja need pole TODO-d, mida kunagi ehk hakatakse kasutama). Siin oleks näiteks (tõenäoliselt A. Käveri projektipõhja jäänuk) DataBaseContext.cs, kus võinuks eemaldada „PK – string“ versioonis Identity olemite sektsioonid. Lisaks leidus pisemaid tähelepanematusi nagu DAL all on üks tühi klass ServiceMap.cs ning klassides on palju mittevajalikke „using“ direktiive – nende ebavajalike asjade eemaldamisel aitab tavaliselt IDE mõni tööriist.

			'''Kokkuvõte'''

			Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.

Kruutel at 11:44, 27 March 2017

2017-03-27T11:44:54Z

← Older revision		Revision as of 14:44, 27 March 2017
Line 12:		Line 12:
	Kirjeldusi ja nimesid sisaldavate elementide sisu on näitefailis esitatud ohutult CDATA lõikudena.		Kirjeldusi ja nimesid sisaldavate elementide sisu on näitefailis esitatud ohutult CDATA lõikudena.

	Näidisfail valideerub ning vastab struktuuri keerukuskirteeriumitele - on vähemalt neli loogilist dimensiooni; vähemalt kolmel dimensioonil on kasutatud ID-st informatiivsemaid atribuute		Näidisfail valideerub ning vastab struktuuri keerukuskirteeriumitele - on vähemalt neli loogilist dimensiooni; vähemalt kolmel dimensioonil on kasutatud ID-st informatiivsemaid atribuute.
	.

	==XML schema==		==XML schema==

Kruutel at 11:33, 27 March 2017

2017-03-27T11:33:46Z

@@ Line 1: / Line 1: @@
 '''Retsensioonid'''
-XML ülesanne
+=Retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/Ticketer Ticketer]=
-* Meeskond Ticketer
+==XML fail==

Rturi: Created page with "'''Retsensioonid''' XML ülesanne * Meeskond Ticketer"

2017-03-25T15:13:50Z

Created page with "'''Retsensioonid''' XML ülesanne * Meeskond Ticketer"

New page

'''Retsensioonid'''

XML ülesanne
* Meeskond Ticketer