Hammas - Revision history

Slunden: /* Retsensioonid */

2018-06-08T09:35:28Z

Retsensioonid

← Older revision		Revision as of 12:35, 8 June 2018
Line 394:		Line 394:
	Tehniliselt on API'ga suhtlemiseks loodud baasteenus kus on kirjas API aadress ja loogika tokeni headerisse lisamiseks. Domeeniobjekti-spetsiifilised teenuseklassid pärinevad samast baasklassist. Vaated saavad oma andmed ViewModelitelt, mis omakorda suhtlevad teenustega andmete saamiseks. Refereerija ei oma piisavalt kogemust WPF projektidega, et arhitektuuri süvitsi kommenteerida, ent tundub, et järgitakse MVVM mustrit. Kuna API annab välja puhtalt domeeni-, mitte äriobjekte, siis on ka klientrakendust raske ehitada. Näiteks, et toodetele hinnad arvutada, peab ProductService esiteks tooted pärima (GetProductsFromWebServiceAsync()), seejärel foreach tsüklis iga toote kohta eraldi API hinnapäringu tegema (GetPricesAsync()). Kui ostukorvis on 10 toodet, tehakse API'sse 10 päringut. Selle asemel võiks API välja saata ostukorvi koos toodete ja hindadega - kümne päringu asemel saab siis hakkama ainult ühega.		Tehniliselt on API'ga suhtlemiseks loodud baasteenus kus on kirjas API aadress ja loogika tokeni headerisse lisamiseks. Domeeniobjekti-spetsiifilised teenuseklassid pärinevad samast baasklassist. Vaated saavad oma andmed ViewModelitelt, mis omakorda suhtlevad teenustega andmete saamiseks. Refereerija ei oma piisavalt kogemust WPF projektidega, et arhitektuuri süvitsi kommenteerida, ent tundub, et järgitakse MVVM mustrit. Kuna API annab välja puhtalt domeeni-, mitte äriobjekte, siis on ka klientrakendust raske ehitada. Näiteks, et toodetele hinnad arvutada, peab ProductService esiteks tooted pärima (GetProductsFromWebServiceAsync()), seejärel foreach tsüklis iga toote kohta eraldi API hinnapäringu tegema (GetPricesAsync()). Kui ostukorvis on 10 toodet, tehakse API'sse 10 päringut. Selle asemel võiks API välja saata ostukorvi koos toodete ja hindadega - kümne päringu asemel saab siis hakkama ainult ühega.
	</p>		</p>
			===XMLi retsensioon meeskonnale MealPlannerSolo===
			<p>Nii xml kui ka xsd failid valideeruvad (testitud http://www.utilities-online.info/xsdvalidation/). Nõue neljatasemelise hierarhia kohta on täidetud, samuti kasutatud kolmel dimensioonil atribuute, mis on enamat kui lihtsalt id. CDATA’t on kasutatud step elemendis, aga võiks julgelt kasutada ka kõigis muudes elementides, mis string andmetüüpi kannavad (näiteks ingredient). </p>
			<p>Skeemifailis - piiratud on toidukordade arv ühes menüüs neljale, atribuut unitoftime on muudetud unsignedBytest positiveIntegeriks (loogiline), element instructions peab esinema vähemalt ühe korra. Mitmete elementide (ingredient, toidukord) ID atribuudid on defineeritud kui nonNegativeInteger (lubatud väärtused { 0,1,2… }) Võibolla sellel on mingi spetsiifiline põhjus, aga ehk saaks ka siin kasutada positiveIntegeri (väärtused { 1,2… }).</p>
			<p>Html transformatsioon – tekitatakse viisakas html vaade, kus andmed tabelisse ja listi paigutatakse. Kasutusel foreach tsükkel ja choose avaldis.</p>
			<p>Xml transformatsioon – foreach tsükliga loetakse iga menüü toidukordadest välja retseptinimi ning kuvatakse vastavalt koostisosadele allergeenid. Kasutusel samuti foreach ja choose.</p>

Slunden: /* Retsensioonid */

2018-06-07T10:21:34Z

Retsensioonid

← Older revision		Revision as of 13:21, 7 June 2018
Line 383:		Line 383:
	</li>		</li>
	</ul>		</ul>
			===Klientrakenduse retsensioon meeskonnale GoFood===
			<p>Klientrakenduse funktsionaalsus:</p>
			<p>Käivitamisel tuleb kasutaja registreerida, misjärel on võimalik sisse logida. Ilma registreerimata rakendust kasutada ei saa. Peale sisselogimist on realiseeritud kaks peamist kasutajajuhtu - toitumiskava loomine ning ostunimekirja tegemine. Lisaks sellele ka konto haldus (mis tähendab momendil rakendusest väljalogimist).</p>
			<p>Toitumiskava loomisel tuleb sellele anda nimi, seejärel on võimalik tekitada nädalapäeva-spetsiifilisi kavasid. Peale seoste tekitamise momendil rohkem midagi teha ei saa - domeeniolemid on küllaltki algusjärgus ja peale võtmete seal väga palju rohkem salvestada ei ole. Toitumiskava on võimalik ka kustutada. Sel juhul kustutatakse automaatselt ka päevaspetsiifilised kavad.</p>
			<p>
			Ostunimekirja saab luua, peale mida antakse kasutajale võimalus sellesse tooteid lisada. Tooted on jagatud kategooriatesse, peale nimetuse on neil ka kaal, hind ja kasutajaliideses näha erinevad toiteväärtuse indikaatorid. Tootel ja hinnal on üks-mitmene suhe (tootel võib erinevates poodides olla erinev hind), ent päringutes seda momendil ei arvestada ja võetakse esimene leitud hind. Ostunimekirja lisamisel peab kasutaja sisestama koguse, klientrakendus arvutab seejärel vaates lõppsumma kokku. Koguse sisestamisel kontrollitakse, et tegu integeriga, ent sisestada saab ka null või miinusekoguse, mis salvestatakse ka baasi.</p>
			<p>
			Pisut häiris see, et UI ei anna momendil tagasisidet - kas tehtud tegevus õnnestus või ebaõnnestus.</p>
			<p>
			Tehniliselt on API'ga suhtlemiseks loodud baasteenus kus on kirjas API aadress ja loogika tokeni headerisse lisamiseks. Domeeniobjekti-spetsiifilised teenuseklassid pärinevad samast baasklassist. Vaated saavad oma andmed ViewModelitelt, mis omakorda suhtlevad teenustega andmete saamiseks. Refereerija ei oma piisavalt kogemust WPF projektidega, et arhitektuuri süvitsi kommenteerida, ent tundub, et järgitakse MVVM mustrit. Kuna API annab välja puhtalt domeeni-, mitte äriobjekte, siis on ka klientrakendust raske ehitada. Näiteks, et toodetele hinnad arvutada, peab ProductService esiteks tooted pärima (GetProductsFromWebServiceAsync()), seejärel foreach tsüklis iga toote kohta eraldi API hinnapäringu tegema (GetPricesAsync()). Kui ostukorvis on 10 toodet, tehakse API'sse 10 päringut. Selle asemel võiks API välja saata ostukorvi koos toodete ja hindadega - kümne päringu asemel saab siis hakkama ainult ühega.
			</p>

Slunden: /* Veebiteenuse retsensioon meeskonnale GoFood */

2018-06-06T09:03:26Z

Veebiteenuse retsensioon meeskonnale GoFood

← Older revision		Revision as of 12:03, 6 June 2018
Line 363:		Line 363:

	<ul>		<ul>
	<li> Majanduslik mõtlemine (kas loodav teenus ja rakendused oleks kasutatav ka ärilistel eesmärkidel) – ~~Toote~~ sihtgrupp on paigas, idee on üsna huvitav ja ambitsioonikas. Projekti sajaprotsendilise teostuse korral oleks monetiseerimine kindlasti mõeldav</li>		<li> Majanduslik mõtlemine (kas loodav teenus ja rakendused oleks kasutatav ka ärilistel eesmärkidel) – toote sihtgrupp on paigas, idee on üsna huvitav ja ambitsioonikas. Projekti sajaprotsendilise teostuse korral oleks monetiseerimine kindlasti mõeldav</li>
	<li>		<li>
	 Mobiilirakendused/Angularis/reactis loodud klientrakendus – klientrakendus teostatud WPF’is. Konkreetne rakendus vajaks ilmselt Native\Hybrid mobiilset äppi, kuna kasutaja peaks tegevusi tegema mobiilsest seadmest erinevatel aegadel päeva jooksul		 Mobiilirakendused/Angularis/reactis loodud klientrakendus – klientrakendus teostatud WPF’is. Konkreetne rakendus vajaks ilmselt Native\Hybrid mobiilset äppi, kuna kasutaja peaks tegevusi tegema mobiilsest seadmest erinevatel aegadel päeva jooksul

Slunden: /* Retsensioonid */

2018-06-06T09:01:51Z

Retsensioonid

← Older revision		Revision as of 12:01, 6 June 2018
Line 346:		Line 346:

	==Retsensioonid==		==Retsensioonid==

			===Veebiteenuse retsensioon meeskonnale GoFood===
			<p>Projekti arhitektuur vastab headele tavadele ja on üles ehitatud õppejõudude soovituste kohaselt - kasutusel teenuste kiht, mis omakord kasutab uow'd ja repositooriumeid. Kasutusel nii generic kui ka custom repositooriumid. Kood on kirjutatud vastu liideseid (Interface). Kasutusel ka DTO'd mis pannakse kokku Factorites. </p>
			<p>
			Domeenimudel on samuti viisakas. Eksisteerib 12 olemit + kasutajate tabel. Stringid on limiteeritud, PK'd ja FK'd olemas. </p>
			<p>
			Kiiduväärt on ka see, et erinevalt mitmetest teistest proovitud projektidest buildis see esimese katsega ja Migrationid läksid kohe läbi. Eks oleks nice-to-have kui tekitatakse ka kohe mõned andmed millega testida (eriti kuna clientapp kippus vigu andma kui mõned objektid olid tühjad), aga ei olnud suur probleem ka ise andmeid tekitada.</p>
			<p>
			Iga domeeniobjekti kohta eksisteerib kontroller, kuhu on süstitud samanimeline teenus. Siin on ehk tegu väikest viisi liiasusega, sest API seisukohast võiks siduvate tabelite andmeid välja anda läbi root-objekti. Näiteks ProductInShoppingListControlleri võiks ära kaotada ning ShoppingListController võiks neid andmeid välja anda olemasolevate päringute lisana (ShoppingListDTO võiks omada kollektsiooni List<ProductInShoppingList>, mille saaks täita kui EFShoppingListRepositoryst välja anda andmed kujul _db.ShoppingList.Include(x => x.ProductsInShoppingLists). Alternatiivina võiks ProductInShoppingListControlleri meetodid üle viia ShoppingListControllerisse. Sõltumata sellest mis meetodit kasutada, jätaks refereerija alles kontrolleri ainult iga põhilise ’päriselu’ objekti kohta – Store, ShoppingList, Product, NutritionPlan etc ja serveeriks andmeid ainult läbi nende. See teeks ka API tarbija elu lihtsamaks, kuna objektid on intuitiivsemad.</p>
			<p>
			Kõik kontrollerid (v.a SecurityController) on Authorize annotationiga illustreeritud nagu peabki. Seadistatud on ka Swaggeri endpoint.</p>
			<p>
			API funktsionaalsuse poolest on realiseeritud kasutajate loomine, autentimine ja andmebaasi salvestamine ning kontrollerid on valmis iga domeeniobjekti CRUD tegevusteks. Teenuste kihis keerulisemat äriloogikat veel ei ole, toimub suht üks-ühele DTO vs domeeniobjekti mappimine ning seejärel repostiooriumisse või tagasi kontrollerisse saatmine. </p>
			<p>
			Lõpetuseks vaataks üle kuidas projekti suhestub hindamiskriteeriumitega:</p>

			<ul>
			<li> Majanduslik mõtlemine (kas loodav teenus ja rakendused oleks kasutatav ka ärilistel eesmärkidel) – Toote sihtgrupp on paigas, idee on üsna huvitav ja ambitsioonikas. Projekti sajaprotsendilise teostuse korral oleks monetiseerimine kindlasti mõeldav</li>
			<li>
			 Mobiilirakendused/Angularis/reactis loodud klientrakendus – klientrakendus teostatud WPF’is. Konkreetne rakendus vajaks ilmselt Native\Hybrid mobiilset äppi, kuna kasutaja peaks tegevusi tegema mobiilsest seadmest erinevatel aegadel päeva jooksul
			</li>
			<li>
			 Kogukondade kaasamine – sihtgrupp on oma tervisest lugu pidavad inimesed. Ärilise edu korral võib see aidata inimestel teha igapäevaselt paremaid\teadlikumaid valikuid toidu osas ja omab seega positiivset mõju ühiskonnale
			</li>
			<li>
			 Kasutajamugavus – sõltub eelkõige klientäpi realisatsioonist. API kasutusmugavuse kohta on kommentaarid antud eelnevalt. Swaggeri olemasolu on väga abiks.
			</li>
			<li>
			 Läbimõeldud töökorraldus – projektil on versioonihaldus (millesse refereerija millegipärast sisse ei saanud), wiki lehel kirjeldatud lühidalt üldine idee ja soovitud funktsionaalsus. Eks analüüs võiks detailsem olla (andmeskeem jne), aga üldjoontes on lähenemine struktuurne
			</li>
			<li>
			 Lisavõimaluste realiseerimine (vt näidisteemad) – klientäpp on veel üsna algusfaasis, seega on hetkel keskendutud pigem baasfunktsionaalsuse arendamisele
			</li>
			<li>
			 Korraliku arhitektuuriga kirjutatud kood – projekti ülesehitus korralik, võiks veel julgemalt eksperimenteerida linq’i ja keerulisemate äriloogikate ehitamisel
			</li>
			</ul>

Slunden: /* Transformatsioon XMLi */

2018-05-16T21:42:22Z

Transformatsioon XMLi

← Older revision		Revision as of 00:42, 17 May 2018
Line 299:		Line 299:
	===Transformatsioon XMLi===		===Transformatsioon XMLi===

	Grupeerime tooted laopõhiselt. Transformatsioon nähtav [http://enos.itcollege.ee/~slunden/~~Sten~~.~~xml2~~ siin].		Grupeerime tooted laopõhiselt. Transformatsioon nähtav [http://enos.itcollege.ee/~slunden/Sten2.xml siin].

	<source lang="xml">		<source lang="xml">

Slunden: /* Transformatsioon XMLi */

2018-05-16T21:41:48Z

Transformatsioon XMLi

← Older revision		Revision as of 00:41, 17 May 2018
Line 298:		Line 298:

	===Transformatsioon XMLi===		===Transformatsioon XMLi===

			Grupeerime tooted laopõhiselt. Transformatsioon nähtav [http://enos.itcollege.ee/~slunden/Sten.xml2 siin].

	<source lang="xml">		<source lang="xml">
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>

Slunden: /* Transformatsioon HTMLi */

2018-05-16T21:36:47Z

Transformatsioon HTMLi

← Older revision		Revision as of 00:36, 17 May 2018
Line 214:		Line 214:

	===Transformatsioon HTMLi===		===Transformatsioon HTMLi===

			Transformatsioon nähtav [http://enos.itcollege.ee/~slunden/Sten.xml siin]
	<source lang="xml">		<source lang="xml">
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>

Slunden: /* Transformatsioon XMLi */

2018-05-16T21:27:19Z

Transformatsioon XMLi

← Older revision		Revision as of 00:27, 17 May 2018
Line 338:		Line 338:
	</xsl:template>		</xsl:template>
	</xsl:stylesheet>		</xsl:stylesheet>
			</source>

	==Retsensioonid==		==Retsensioonid==

Slunden: /* Transformatsioon HTMLi */

2018-05-16T21:27:10Z

Transformatsioon HTMLi

← Older revision		Revision as of 00:27, 17 May 2018
Line 293:		Line 293:
	</xsl:template>		</xsl:template>
	</xsl:stylesheet>		</xsl:stylesheet>
			</source>

	===Transformatsioon XMLi===		===Transformatsioon XMLi===

Slunden: /* Skeemifail */

2018-05-16T21:27:00Z

Skeemifail

← Older revision		Revision as of 00:27, 17 May 2018
Line 211:		Line 211:
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
			</source>

	===Transformatsioon HTMLi===		===Transformatsioon HTMLi===