Talk:DevHelpVR - Revision history

Mmatson at 06:42, 15 June 2017

2017-06-15T06:42:29Z

@@ Line 2: / Line 2: @@
 ==Sissejuhatus==
-. Andmebaasi olemite arv
+Sorry, kuna meil viide pealehelt retsensioonile oli sama, siis kukkusin kohe kirjutama. Võtan oma osa ära, jätan teie oma alles.
+Mihkel (Talutooted).
@@ Line 84: / Line 40: @@
 Klientrakendus on korralikult kirjutatud ning arvestades kogu projektimahtu, ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks ''AngularJS''-i veebiraamistikuna ja näiteks ''Bootstrap'' raamistiku elemente. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames ''Angular'' raamistikust väga midagi rääkida ei jõutud). Selle tulemusena oleks saanud disaini ka veidi parema teha, kuid kõige tähtsam on siiski funktsionaalsuse realiseerimine, mis õnnestus väga hästi ja mille eest tuleb meeskonda kiita. Ükski lahendus ei tundu poolik, ning kõik on suures plaanis läbi mõeldud. Siit jääb kuvama ka tõsiasi, et see projekt on tegelikult edasiarendus C# aines kirjutatud projektile ning võib arvata, et seetõttu oli ka andmebaasi struktuuri ülesehitamine selle võrra lihtsam. Mõte ise on samuti hea. Kui meeskonnal tekiks tahtmine asja päriselt realiseerida, oleks nüüd lihtne võtta teenus ning teha sellele lisaks otsa korralik veebirakendus, mis näeb ilus välja.

Mmatson at 21:17, 14 June 2017

2017-06-14T21:17:53Z

← Older revision		Revision as of 00:17, 15 June 2017
Line 53:		Line 53:
	==Tehnoloogilise osa arvustus==		==Tehnoloogilise osa arvustus==

	=== Veebiteenus ===		=== '''Veebiteenus''' ===

	==== Domeenimudelid ====		==== Domeenimudelid ====

Mmatson at 21:15, 14 June 2017

2017-06-14T21:15:35Z

Show changes

Jeerik: /* Lõpptoote retsensioon meeskonnalt PC KartKicker */

2017-06-14T19:52:24Z

Lõpptoote retsensioon meeskonnalt PC KartKicker

← Older revision		Revision as of 22:52, 14 June 2017
Line 71:		Line 71:

	Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlalt maksimumpunkte!		Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlalt maksimumpunkte!

			== Klientrakendus ==

			=== Arhitektuur ===

			Klientrakendus on realiseeritud Windows Application’ina ning asub samas solution’is. Klientrakendus kasutab samu domeenimudeleid ning samuti on olemas Enum’ite kaust fikseeritud skaalaga väljade jaoks. Nii nagu teenuse osas, häirivad veidi silma alakriipsuga deklareeritud väljad (nt. User_UserStoryStart), kuid see on jällegi puhtalt stiili küsimus. Domeenimudelid suhtlevad API-ga tokenite abil, mis initsialiseeritakse konstruktoris. Samuti on olemas vaatemudelid, mis pärinevad baas vaatemudelist BaseVM, mis on põhimõtteliselt event handler. Vaated näevad välja nagu nad out of the box on - eristuvat disaini ei ole siinkohal märgata. Samas on see arusaadav, kuna projekti maht oli niigi suur ja põhifookus lasus funktsionaalsuse realiseerimisel. Eraldi on olemas service layer, mille ülesandeks on andmete edastamine API vastu. Iga domeenimudeli jaoks on eraldi service, mis pärineb baas service’ist. Mõne viewmodel’i puhul jäi silma, et see kasutab väga palju service klasse (näiteks DevTeamVM kasutab viite service’it). Siinkohal oleks võinud kaaluda teha lisaabstraktsioon, mis koondaks enda alla service-id. Idee poolest võiks see olla nagu UOW (Unit of Work), mida saaks süstida vaatemudelitesse, et need võiksid kasutada kõiki vajaminevaid service klasse. Teisalt ei ole projekti maht niivõrd suur ja see võib vabalt jääda ka tulevikuks.

			=== Funktsionaalsus ===

			Rakendust avades kuvatakse kõigepealt sisselogimise aken, kust on konto puudumisel võimalik kohe ka uus kasutaja registreerida. Peale registreerimist võiks kuvada lisaakna, millega kinnitada kasutajale, et registreerimine tõepoolest õnnestus. Praegu suunatakse lihtsalt tagasi sisselogimise aknasse. Peale sisselogimist avaneb “põhiaken”, kus saab kasutada juba põhifunktsionaalsust - siduda kasutajat projektide ja arendusmeeskondadega, projektidele lisada iteratsiooni ning iteratsioonidele kasutajalugusid. Nii projekte, kasutajalugusid kui iteratsioone saab sealjuures eraldiseisvalt kustutada ning ülemkategooria kustutamisel kaovad ka alamüksused (cascade delete). Siin tuleb selgelt välja, et domeenimudelid on läbimõeldud ning lisatud vajalikud väljad. Samas ei ole “surnud” välju, mida kuskil ei kasutata ja mis niisama objekti küljes on. Lisaks on võimalik vaadata statistikat ning muuhulgas jälgitakse ka kasutajate sisselogimiste arvu (teatavasti oli sisselogimiste arvu piiramine ka üks projekti nõuetest).

			=== Kokkuvõte ===

			Klientrakendus on korralikult kirjutatud ning arvestades tervet projektimahtu ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks AngularJS-i veebiraamistikuna. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames Angularist väga mida rääkida ei jõutud). Selle tulemusena oleks saanud disaini ka veidi parema teha, kuid kõige tähtsam on siiski funktsionaalsuse realiseerimine, mis õnnestus väga hästi ja mille eest tuleb meeskonda kiita. Ükski lahendus ei tundu poolik, ning kõik on suures plaanis läbi mõeldud. Siit jääb kuvama ka tõsiasi, et see projekt on tegelikult edasiarendus C# aines kirjutatud projektile ning võib arvata, et seetõttu oli ka andmebaasi struktuuri ülesehitamine selle võrra lihtsam. Mõte ise on samuti hea. Kui meeskonnal tekiks tahtmine asja päriselt realiseerida, oleks nüüd lihtne võtta teenus ning teha sellele lisaks otsa korralik veebirakendus, mis näeb ilus välja.

Jeerik: /* Lõpptoote retsensioon meeskonnalt PC KartKicker (Broneering) */

2017-06-14T19:50:51Z

Lõpptoote retsensioon meeskonnalt PC KartKicker (Broneering)

← Older revision		Revision as of 22:50, 14 June 2017
Line 52:		Line 52:


	=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker] ~~(Broneering)~~=		=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker]=

	== Veebiteenus ==		== Veebiteenus ==

Jeerik: /* Lõpptoote retsensioon meeskonnalt PC KartKicker (Broneering) */

2017-06-14T19:50:39Z

Lõpptoote retsensioon meeskonnalt PC KartKicker (Broneering)

← Older revision		Revision as of 22:50, 14 June 2017
Line 53:		Line 53:

	=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker] (Broneering)=		=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker] (Broneering)=

			== Veebiteenus ==

			=== Domeenimudelid ===

			Veebiteenuse domeenimudelid on kirjeldatud üsna põhjalikult ja meeldib, et mõistlikes kohtades on kasutatud annotatsioone – näiteks piiratud stringi pikkused ja lisatud required väljad kuhu vaja. Mudeleid on kokku kümne ringis, mis viitab sellele, et projekt tundub nõudeid arvestades paraja suurusega. Lisaks on leidub eraldi kaust, kus on realiseeritud Enum’itena erinevad fikseeritud skaalaga väljad. Veel torkab silma, et kasutatakse Lazy Loading’ut, mis antud rakenduse suuruse juures pole võib-olla kõige vajalikum. Samuti võib see tulevikus raskendada rakenduse üle viimist ASP.NET Core’i peale, mis seda ei toeta. Natukene häirivad mõned mitu-mitmele seoste tulemusel tekkivate olemite nimetused – näiteks User_DevTeam või User_Project. Võib-olla oleks silmale veidi ilusam neid ilma alakriipsuta kirjutada, kuid see on paljuski isiklik eelistus. Kokkuvõtvalt aga peab mainima, et mudelid tunduvad hästi läbi mõeldud ning siinkohal on etteheiteid teha raske.

			=== Andmebaas ja repositooriumid ===

			Arhitektuuri osas on kasutatud Repository pattern’it db-contexti vastu, samuti Unit of Work pattern’it, mis koondab enda alla repositooriumid. Kiita saab seda, et Helpers kataloogis on DbInitializer, mis teeb konkreetset koodi mittetundvale inimesele rakenduse järgiproovimise lihtsaks (ei pea ise dummy data’t genereerima, vaid saab kohemaid sisusse süveneda). Repositooriumite osas torkab silma, et need on enamjaolt tühjad (peale UserRepository), kuid UOW-s registreeritakse need custom repositooriumitena. Loomulikult võib need tuleviku arendusi silmas pidades valmis ära teha, kuid siis pole suurt mõtet neid veel eraldi Dictionary-sse registreerida vaid kasutada UOW-s standardsetena. Iga repositooriumi vastu on kirjutatud eraldi Interface, nii repositooriumid, kui Interface’id kasutavad baasmudelit (vastavalt EFRepository ja IRepository), millest nad pärinevad.

			=== Äriloogika ===

			Kontrollerid suhtlevad antud juhul service layer’iga ja kasutatakse DTO-sid koos factory pattern’iga. DTO-d tunduvad kõik domeenimudelitega identsed ja on seega ilmselt valmis tehtud just tulevikku silmas pidades. Kontrollerites on realiseeritud enamjaolt CRUD meetodid, mis kasutavad DTO-sid, kuid väga palju spetsiifilisi lahendusi realiseeritud ei ole. Kontrolleritele võiks vaid nii palju ette heita, et ei kasutata asünkroonset lähenemist, mis teeks rakenduse tulevikus veelgi skaleeritavamaks. Samas, nii repositooriumid kui kontrollerid on õiges kohas ja õigesti üles ehitatud ning kõik tundub ilusasti töötavat. Kasutajate haldus kasutab Entity Framework-i enda ApplicationUser’it, seega aine baas-repositooriumis välja pakutud custom Identity lahendust ei ole siinkohal realiseeritud (mis ei olnud ka ise-enesest eraldi nõue).

			=== Kokkuvõte ===

			Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlalt maksimumpunkte!

Mmatson at 18:07, 14 June 2017

2017-06-14T18:07:15Z

← Older revision		Revision as of 21:07, 14 June 2017
Line 37:		Line 37:
	Kokkuvõtvalt on veebiteenus hästi ülesehitatud, kuid silma jäi ja välja võiks tuua ehk selle, et mitte kõik kontrollerid ei tagasta vea korral 404 veateadet.		Kokkuvõtvalt on veebiteenus hästi ülesehitatud, kuid silma jäi ja välja võiks tuua ehk selle, et mitte kõik kontrollerid ei tagasta vea korral 404 veateadet.

	==Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus==		==Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus, statistika==
	Teenus on ülesehtitatud kasutades Asp.Net enda Identity moodulit, mistõttu toetab see mitmekasutaja funktsionaalsust ja kasutajate hallatavust. Võib näha, et esialgne andmemudel oli planeeritud kasutama iseseisvat kasutajate andmemudelit ja nii on see ka teostatud. Küll aga on lisandunud seos AspNetUsers tabelile, kui kasutaja registreeritakse ja hilisemate mõningate teenuste puhul. Parendusettepanekuna, nagu eelpool mainitud, võiks selle tulevikus viia ühtse mudeli peale, oleks kokkuvõttes lihtsam koodi hallata. Kontrolleris kasutatakse teenusetarbijate autentimist, mistõttu on raskendatud juurdepääsu mitteomavate kasutajate süsteemi sisenemine. Lisaks on rakendatud ka autoriseerimist, mis omakorda piirab juurdepääsu omavatel süsteemi kasutajatel üksteise sessioonide kuulamise ja andmelekke tekkimist. Iga päringu tegemiseks kasutatakse sisselogimisel saadud tokenit, mis võimaldab eelpool toodut rakendada.		Teenus on ülesehtitatud kasutades Asp.Net enda Identity moodulit, mistõttu toetab see mitmekasutaja funktsionaalsust ja kasutajate hallatavust. Võib näha, et esialgne andmemudel oli planeeritud kasutama iseseisvat kasutajate andmemudelit ja nii on see ka teostatud. Küll aga on lisandunud seos AspNetUsers tabelile, kui kasutaja registreeritakse ja hilisemate mõningate teenuste puhul. Parendusettepanekuna, nagu eelpool mainitud, võiks selle tulevikus viia ühtse mudeli peale, oleks kokkuvõttes lihtsam koodi hallata. Kontrolleris kasutatakse teenusetarbijate autentimist, mistõttu on raskendatud juurdepääsu mitteomavate kasutajate süsteemi sisenemine. Lisaks on rakendatud ka autoriseerimist, mis omakorda piirab juurdepääsu omavatel süsteemi kasutajatel üksteise sessioonide kuulamise ja andmelekke tekkimist. Iga päringu tegemiseks kasutatakse sisselogimisel saadud tokenit, mis võimaldab eelpool toodut rakendada.
			Nõuetekohaselt salvestatakse statistikat kasutaja tegevuste kohta, mis kokkuvõttes on kindlasti hea nii kasutajale endale oma protsesside optimeerimiseks kui ka eelkõige rakenduse arendusmeeskonnale erinevate tegevuste optimiseerimiseks.
	Küll aga leidsime ühe vea, kus kõigil kasutajatel on võimalik näha kõiki sisestatud projekte, see aga ei oleks ka ettevõttesiseselt ehk alati otstarbekas, ja tasuks kindlasti üle vaadata ning muuta kui soovitakse rakendust ka SaaS mudeli alusel müüja.		Küll aga leidsime ühe vea, kus kõigil kasutajatel on võimalik näha kõiki sisestatud projekte, see aga ei oleks ka ettevõttesiseselt ehk alati otstarbekas, ja tasuks kindlasti üle vaadata ning muuta kui soovitakse rakendust ka SaaS mudeli alusel müüja.

	~~==Kasutusstatistika üle arve pidamist==~~

	==Piirangute olemasolu pöördumiste arvu osas ning nende haldust==		==Piirangute olemasolu pöördumiste arvu osas ning nende haldust==

Mmatson at 18:03, 14 June 2017

2017-06-14T18:03:19Z

← Older revision		Revision as of 21:03, 14 June 2017
Line 3:		Line 3:
	==Sissejuhatus==		==Sissejuhatus==
	Retsensiooni eesmärgiks oli võrrelda püstitatud ülesannet lõpptulemusega ning analüüsida esmalt veebiteenuse poolt, kasutatud andmemudeleid, mustreid ning koodi jälgitavust ehk visuaalset poolt. Teiseks tuli analüüsida ka kliendirakendust, mis eesmärgipäraselt peaks suhtlema loodud veebiteenusega.		Retsensiooni eesmärgiks oli võrrelda püstitatud ülesannet lõpptulemusega ning analüüsida esmalt veebiteenuse poolt, kasutatud andmemudeleid, mustreid ning koodi jälgitavust ehk visuaalset poolt. Teiseks tuli analüüsida ka kliendirakendust, mis eesmärgipäraselt peaks suhtlema loodud veebiteenusega.
	Retsensiooni käigus hindasime veebiteenuse osas vastavalt järgmiseid nüansse:		Retsensiooni käigus hindasime veebiteenuse ja klientrakenduse osas vastavalt järgmiseid nüansse:

	1. Andmebaasi olemite arv		1. Andmebaasi olemite arv
Line 20:		Line 20:

	8. Kasutusjuhendi olemasolu		8. Kasutusjuhendi olemasolu

			9. Klientrakenduse tehnoloogia, ülesehitus ja kasutusmugavus

	==Andmemudel, olemid==		==Andmemudel, olemid==
Line 36:		Line 38:

	==Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus==		==Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus==
			Teenus on ülesehtitatud kasutades Asp.Net enda Identity moodulit, mistõttu toetab see mitmekasutaja funktsionaalsust ja kasutajate hallatavust. Võib näha, et esialgne andmemudel oli planeeritud kasutama iseseisvat kasutajate andmemudelit ja nii on see ka teostatud. Küll aga on lisandunud seos AspNetUsers tabelile, kui kasutaja registreeritakse ja hilisemate mõningate teenuste puhul. Parendusettepanekuna, nagu eelpool mainitud, võiks selle tulevikus viia ühtse mudeli peale, oleks kokkuvõttes lihtsam koodi hallata. Kontrolleris kasutatakse teenusetarbijate autentimist, mistõttu on raskendatud juurdepääsu mitteomavate kasutajate süsteemi sisenemine. Lisaks on rakendatud ka autoriseerimist, mis omakorda piirab juurdepääsu omavatel süsteemi kasutajatel üksteise sessioonide kuulamise ja andmelekke tekkimist. Iga päringu tegemiseks kasutatakse sisselogimisel saadud tokenit, mis võimaldab eelpool toodut rakendada.
			Küll aga leidsime ühe vea, kus kõigil kasutajatel on võimalik näha kõiki sisestatud projekte, see aga ei oleks ka ettevõttesiseselt ehk alati otstarbekas, ja tasuks kindlasti üle vaadata ning muuta kui soovitakse rakendust ka SaaS mudeli alusel müüja.

			==Kasutusstatistika üle arve pidamist==

			==Piirangute olemasolu pöördumiste arvu osas ning nende haldust==


			==Kasutusjuhendi olemasolu==

			==Klientrakenduse tehnoloogia, ülesehitus ja kasutusmugavus==

	'''Pealkiri 13'''		'''Pealkiri 13'''

Mmatson at 17:43, 14 June 2017

2017-06-14T17:43:48Z

← Older revision		Revision as of 20:43, 14 June 2017
Line 28:		Line 28:

	Välja võib tuua seda, et kõik olemid ja seosed on hästi läbimõeldud, kasutatud on piisavalt annotatsioone ja kõik viitetüüpi olemi atribuudid on sobivalt piiratud (eelkõige string muutujad).		Välja võib tuua seda, et kõik olemid ja seosed on hästi läbimõeldud, kasutatud on piisavalt annotatsioone ja kõik viitetüüpi olemi atribuudid on sobivalt piiratud (eelkõige string muutujad).

			==Kasutatav tehnoloogia ja veebiteenuse olemasolu==
			Projekt on ülesehitatud kasutades ASP.NET MVC Web API tehnoloogiat nii, nagu kirjas ka õppejõu poolt antud projekti nõuetes. Rakenduse ülesehitus on hajutatud, mis tähendab, et andmekihid on üksteisest eraldatud ja kogu andmevoog on hästi jälgitav ning lihtsasti muudetav. Eraldi asuvad mudelid, äriloogika kiht, teenused ning kontrollerid ja klientrakendus.
			Kontrollerite ülesehitus on loogiline - iga ärilise funktsionaalsuse kohta on oma kontroller - eriti jääb silma ja peab siin ära märkima kommentaarid, mis aitavad selgemalt aru saada kontrolleri taustast.
			Andmevoog liigub nagu raamatus :), kontrollerist teenusesse ja sealt edasi kasutatakse Unit of Work ja Repository mustreid, mis aitab kindlasti jõudlusele kaasa.
			Kokkuvõtvalt on veebiteenus hästi ülesehitatud, kuid silma jäi ja välja võiks tuua ehk selle, et mitte kõik kontrollerid ei tagasta vea korral 404 veateadet.

			==Kasutajate tuvastamine, haldus, mitmekasutaja funktsionaalsus==




	~~=Tase 1 [https://wiki.itcollege.ee/index.php/PC_KartKicker Link]=~~
	~~==Tase 2==~~

	'''Pealkiri 13'''		'''Pealkiri 13'''

Mmatson at 17:22, 14 June 2017

2017-06-14T17:22:00Z

← Older revision		Revision as of 20:22, 14 June 2017
Line 1:		Line 1:
	~~'''~~Retsensioon projektile DevHelpVR~~'''~~		=Retsensioon projektile DevHelpVR=

	=Sissejuhatus=		==Sissejuhatus==
	Retsensiooni eesmärgiks oli võrrelda püstitatud ülesannet lõpptulemusega ning analüüsida esmalt veebiteenuse poolt, kasutatud andmemudeleid, mustreid ning koodi jälgitavust ehk visuaalset poolt. Teiseks tuli analüüsida ka kliendirakendust, mis eesmärgipäraselt peaks suhtlema loodud veebiteenusega.		Retsensiooni eesmärgiks oli võrrelda püstitatud ülesannet lõpptulemusega ning analüüsida esmalt veebiteenuse poolt, kasutatud andmemudeleid, mustreid ning koodi jälgitavust ehk visuaalset poolt. Teiseks tuli analüüsida ka kliendirakendust, mis eesmärgipäraselt peaks suhtlema loodud veebiteenusega.
	Retsensiooni käigus hindasime veebiteenuse osas vastavalt järgmiseid nüansse:		Retsensiooni käigus hindasime veebiteenuse osas vastavalt järgmiseid nüansse:

	1. Andmebaasi olemite arv		1. Andmebaasi olemite arv

	2. Kastutatav tehnoloogia (WCF või ASP.NET MVC Web API)		2. Kastutatav tehnoloogia (WCF või ASP.NET MVC Web API)

	3. Veebiteenuse olemasolu		3. Veebiteenuse olemasolu

	4. Mitmekasutaja funktsionaalsuse olemasolu		4. Mitmekasutaja funktsionaalsuse olemasolu

	5. Kasutajate tuvastamist ja haldamist		5. Kasutajate tuvastamist ja haldamist

	6. Kasutusstatistika üle arve pidamist		6. Kasutusstatistika üle arve pidamist

	7. Piirangute olemasolu pöördumiste arvu osas ning nende haldust		7. Piirangute olemasolu pöördumiste arvu osas ning nende haldust

	8. Kasutusjuhendi olemasolu		8. Kasutusjuhendi olemasolu

	==Andmemudel, olemid==		==Andmemudel, olemid==
	Projekti eesmärgiks oli luua rakendus, mis aitaks arendajal oma töid paremini planeerida ja omada ülevaadet käimasolevatest ning järgmisena algavatest ülesannetest.		Projekti eesmärgiks oli luua rakendus, mis aitaks arendajal oma töid paremini planeerida ja omada ülevaadet käimasolevatest ning järgmisena algavatest ülesannetest.
	Projekti andmemudel on ilusti üles ehitatud, kuid võrreldes esialgu planeerituga esineb erinevus olemite koguarvus, samas on põhifunktsionaalsus kenasti olemas. Andmebaasi olemite arv, ilma Identity olemiteta, on 10. Analüüsi käigus ei suutnud tuvastada ühtegi suurt viga, küll aga saaksime teha mõned soovitused. Nimelt enamik olemeid, milles esineb nn algus ja lõppaeg, võiks lõppaja väli olla pigem valikuline, kuna alati ei pruugi projektil, meeskonnal või muul olemil olla teada lõppaeg selle objekti sisestamisel - ehk et see võib selguda alles peale mõningast analüüsi. Lisaks, tõenäoliselt tähelepanuta jäänud, on UserStory olemi Storypoints attribuudil annotatsioon [Required]. Seda aga tegelikult vaja pole, kuna int on väärtustüüpi muutuja ja nõuab vaikimisi väärtust.		Projekti andmemudel on ilusti üles ehitatud, kuid võrreldes esialgu planeerituga esineb erinevus olemite koguarvus, samas on põhifunktsionaalsus kenasti olemas. Andmebaasi olemite arv, ilma Identity olemiteta, on 10 (esialgses analüüsidokumendis saime neid kokku 16).
			Analüüsi käigus ei suutnud tuvastada ühtegi suurt viga, küll aga saaksime teha mõned soovitused. Nimelt enamik olemeid, milles esineb nn algus ja lõppaeg, võiks lõppaja väli olla pigem valikuline, kuna alati ei pruugi projektil, meeskonnal või muul olemil olla teada lõppaeg selle objekti sisestamisel - ehk et see võib selguda alles peale mõningast analüüsi. Lisaks, tõenäoliselt tähelepanuta jäänud, on UserStory olemi Storypoints attribuudil annotatsioon [Required]. Seda aga tegelikult vaja pole, kuna int on väärtustüüpi muutuja ja nõuab vaikimisi väärtust.
			Kolmanda soovitusena võiks mainida ka seda, et tegelikult saaks edukalt ära kasutada ka Identity-ga kaasa tulevaid olemeid näiteks rollide ja kasutajate kirjeldamiseks.
	~~=XML ülesannete retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker]=~~
	~~==XML fail==~~
	~~Näidisfail valideerub ning vastab struktuuri keerukuskriteeriumitele - on vähemalt neli loogilist dimensiooni~~, ~~kahel dimensioonil (iterations ja userstory) on kasutatud ID-st informatiivsemaid atribuute.~~

	~~XML fail on loogiliselt struktureeritud ja kergesti arusaadav, seda~~ ka ~~vaatamata kommentaaride puudumisele. Elementide ja atribuutide nimed on loogilised ja järgivad ühtset stiili.~~
	~~Andmete paigutus atribuutidesse ja elementidesse tundub üldjoontes mõistlik, aga mina isiklikult oleks erinevates kohtades kasutatud 'name' elemendi asemel selle info pannud atribuudiks.~~

	~~==XML schema==~~
	Näidisfail vastab schema tingimustele. Andmetüübid vastavad andmete sisule ja eeldatavale kasutusele, aga nt. kuna identifikaatorid on üldjuhul positiivse väärtusega, siis võiks 'id' andmetüüp olla integer asemel unsignedInt.
	Üritasin erinevaid kavalaid sigadusi korraldada XML failis ja iga kord oli Visual Studio kohe jaol tänu XSD failile, seega on XSD põhjalikult koostatud. Lisaks oleks olnud hea näha kommentaarides XSD valikute seletust äriloogika vaatepunktist.

	~~==Transformatsioonid==~~

	~~'''XML~~ -~~> HTML transformatsioon'''~~

	~~Transformatsioonis on kasutatud mitut 'foreach' tsüklit. Arvutusi~~ ja ~~tingimuste kontrolli transformatsioon ei sisalda~~. ~~Transformatsiooni tulemusel tekib funktsionaalse kujundusega ja hea loetavusega HTML fail. XSLT fail valideerub.~~
	~~Väljundiks olev HTML annab W3C validaatoris ühe vea ja kolm hoiatust:~~

	1. ~~viga: Line 1, Column 1: no document type declaration; implying "<!DOCTYPE HTML SYSTEM>"~~		Välja võib tuua seda, et kõik olemid ja seosed on hästi läbimõeldud, kasutatud on piisavalt annotatsioone ja kõik viitetüüpi olemi atribuudid on sobivalt piiratud (eelkõige string muutujad).

	~~1. hoiatus: Unable to Determine Parse Mode!~~

	~~2. hoiatus: No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type.~~

	~~3. hoiatus: Byte-Order Mark found in UTF-8 File.~~

			=Tase 1 [https://wiki.itcollege.ee/index.php/PC_KartKicker Link]=
			==Tase 2==

	'''~~XML -> XML transformatsioon~~'''		'''Pealkiri 13'''

	~~Transformatsioonis on kasutatud parameetreid, ühte 'foreach' tsüklit ning sisaldab mitmeid arvutusi ja boonusena ka sorteerimist. XSLT fail valideerub.~~
	~~Väljundiks olev XML läbis W3C validaatori vigadeta.~~

	=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker] (Broneering)=		=Lõpptoote retsensioon meeskonnalt [https://wiki.itcollege.ee/index.php/PC_KartKicker PC KartKicker] (Broneering)=