Talk:SimpleGeo - Revision history

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-31T07:06:43Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 10:06, 31 January 2015
Line 18:		Line 18:

	Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.		Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.
	Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.		Kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega süsteeme, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.
	~~Teine kitsaskoht~~ millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega süsteeme, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.
	See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.		See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-30T19:25:25Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 22:25, 30 January 2015
Line 23:		Line 23:
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
	Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.		Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
	Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud projektis realiseeritu.		Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud projektis realiseeritu.(dll-i dekompileerides ei saa mingitele lähteandmetele ligi)
	Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.		Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-30T19:24:49Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 22:24, 30 January 2015
Line 23:		Line 23:
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
	Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.		Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
	Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud ~~proejektis~~ realiseeritu.		Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud projektis realiseeritu.
	Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.		Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-30T19:23:14Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 22:23, 30 January 2015
Line 23:		Line 23:
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
	Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.		Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
			Kasutaja parooli salvestamise juures soovitaksin kasutada SHA1 algoritmi, see genereerib alati vaid ühesuunalise krüpteeringu ning on tõhusam, kui antud proejektis realiseeritu.
	Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.		Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-30T19:21:12Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 22:21, 30 January 2015
Line 19:		Line 19:
	Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.		Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.
	Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.		Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.
	Teine kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega ~~süsteemile~~, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.		Teine kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega süsteeme, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.
	See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.		See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
	Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.		Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
	Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.		Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Amets: /* Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial */

2015-01-30T19:20:39Z

Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial

← Older revision		Revision as of 22:20, 30 January 2015
Line 19:		Line 19:
	Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.		Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.
	Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.		Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.
	Teine kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes ~~vaatamata~~ kasutajaliidesega süsteemile, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.		Teine kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaadates kasutajaliidesega süsteemile, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.
	See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.		See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.
	Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.		Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
	Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.		Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
	Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.		Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Amets: /* Retsensioon. */

2015-01-30T19:19:16Z

Retsensioon.

← Older revision		Revision as of 22:19, 30 January 2015
Line 14:		Line 14:

	Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.		Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.

			=Retsensioon prototüüp Andres Mets; Meeskond CRM/WPF tehnoloogial=

			Kood on kenasti kihistatud, st. on olemas eraldi teenus-, andmepöördus- ja vaadete kiht.
			Välja tahaks tuua kihtide omavahelise liigse seotuse-> BO objekte kasutatakse teenuskihis, ma isiklikult arvaksin, et BO objektid võiksid olla view põhised ning resideeruda View kihis, mis võimldaks teenuste kihi absoluutselt lahutada view kihist, muidugi on see lihtsalt tehniline nüanss, mis praktilises elus palju juurde ei anna kuna andmebaasi ning teenuste struktuuri muutes tuleb tahesttahtmata muuta ka lõpuks vaate poolt- väga harva kui tekib juurde kalkuleeritavaid välju, mida saaks peidetud kujul töödelda.
			Teine kitsaskoht millele tahaks tähelepanu juhtida on Interface'ide puudumine teenuste kihis-> üldjoontes vaatamata kasutajaliidesega süsteemile, teostame me alati ühesuguseid toiminguid ning hetke implementatsiooni mudeli juures on väga raske vahetada teenuste funktsionaalsust, juhuks näiteks kui soovitakse muuta rakenduse andmesalvestus näiteks failidesse serialiseerimise põhiseks- ei saa lihtsalt teenuste kihti vahetada, et instantsieerida näiteks failidesse serialiseerimist toetavate teenuste implementatsiooniga.
			See on samuti tehniline nüanss- saab vaielda, et kui soovitakse teistsugust teenusekihi käitumist, siis tehaksegi uus projekt ning kopeeritakse teenuste kiht ja kirjutatakse ümber, kuid üldiselt on kood mugavam hallata ning jälgida kui on olemas Interface'ide põhine teenuste kirjeldus.
			Teenuste juures sooviksin veel viidata tüüpimise vajadusele-> implementeerivad klassid peaksid töötama vaid etteantud tüüpi objektidega- muudab koodi väga ühesuguseks ning jälgitavaks, võimaldab üldistamist-> näiteks save meetod on kõigile objektidele samasugune ainult andmetabel ning relatsioonid on teised, seega saab savlestamise, kustutamise generaliseerida üldisesse teenusklassi, mida teised teenused saaksid laiendada- saavutades vajaliku ühetaolise funktsionaalsuse automaatselt.
			Vaate kihis on koodis kasutatud sõnesid vaadete tiitlites, väljade kirjelduses ilmutatud kujul- soovitaksin kasutada stringi ressursse, mida saab laadida võtme järgi ressursifailist. Eeliseks on lihtne nimetuste haldamine, üle süsteemi nimetatakse asju ühte moodi, kerge internatsionaliseerida, vahetada ressursi fail, saab ingilise keelse versiooni jne.
			Mõned minu poolt väljatoodud asjad on vailedavad kuid hea programmeerimise tava kohaselt väga soovituslikud, kuna muudavad projekti haldamise üle pika ajaperioodi lihtsamaks- saab lihtsama vaevaga kaasata uusi arendjaid.

Kvader: /* Retsensioon. */

2014-11-08T08:17:29Z

Retsensioon.

← Older revision		Revision as of 11:17, 8 November 2014
Line 9:		Line 9:
	Tööjaotus tundub meeskonnaliikmete vahel ühtlaselt jaotatud.		Tööjaotus tundub meeskonnaliikmete vahel ühtlaselt jaotatud.

	Plaanitav must have ~~funktisonaalsus~~ on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid ~~funktisionaalsusi~~ vähendada või viia üle soovitud ~~funktsinaalsuste~~ nimekirja.		Plaanitav must have funktsionaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktsionaalsusi vähendada või viia üle soovitud funktsionaalsuste nimekirja.

	Rakendus oleks sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.		Rakendus oleks sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.

	Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.		Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.

Tsoosalu: /* Retsensioon. */

2014-11-07T21:05:01Z

Retsensioon.

← Older revision		Revision as of 00:05, 8 November 2014
Line 11:		Line 11:
	Plaanitav must have funktisonaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktisionaalsusi vähendada või viia üle soovitud funktsinaalsuste nimekirja.		Plaanitav must have funktisonaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktisionaalsusi vähendada või viia üle soovitud funktsinaalsuste nimekirja.

	Rakendus ~~tundub olevat~~ sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.		Rakendus oleks sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.

	Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.		Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.

Tsoosalu at 20:59, 7 November 2014

2014-11-07T20:59:46Z

← Older revision		Revision as of 23:59, 7 November 2014
Line 2:		Line 2:
	Retsenseerija [[Meeskond:RemindEm]]		Retsenseerija [[Meeskond:RemindEm]]

	~~Antud meeskonna~~ analüüs on üsna põhjalik.		Meeskonna SimpleGeo analüüs on üsna põhjalik.
	Välja on toodud rakenduse eesmärk, mis ~~tundub olevat~~ põhjendatud, kuid kohati raskesti mõistetav. Millisele kasutajale on rakendus täpsemalt mõeldud? ~~Näiteks kas mina~~ eramaja omanik ~~peaksin~~ põlengu puhkedes ise endale päästekomandot otsima või on see mõeldud näiteks päästekeskuse kõneoperaatori töövahendiks?		Välja on toodud rakenduse eesmärk, mis üldjoontes on põhjendatud, kuid kohati raskesti mõistetav. Millisele kasutajale on rakendus täpsemalt mõeldud? Kas näiteks eramaja omanik peaks põlengu puhkedes ise endale päästekomandot otsima või on see mõeldud näiteks päästekeskuse kõneoperaatori töövahendiks?

	Rakendus kasutab suuresti kolmandate osapoolte poolt pakutavaid teenuseid, mis võivad mõjutata töökindlust ja kiirust. Kas seda kolmandaosapoole riski oleks võimalik mõne lahendusega maandada?		Rakendus kasutab suuresti kolmandate osapoolte poolt pakutavaid teenuseid, mis võivad mõjutata töökindlust ja kiirust. Kas seda kolmandaosapoole riski oleks võimalik mõne lahendusega maandada? Samuti tekib küsimus, kust saadakse info ja kuidas kajastatakse päästekomandode reageerimisaega. Siinkohal on vaja arvestada meeskonna suuruse, autode arvu jms, kuid ka sellega, et päästeautod võivad olla väljakutsel ning seetõttu pikeneb reageerimisaeg oluliselt.

	Tööjaotus tundub ~~meeskonna~~ vahel ~~ühtlane~~.		Tööjaotus tundub meeskonnaliikmete vahel ühtlaselt jaotatud.

	Plaanitav must have funktisonaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktisionaalsusi vähendada või viia üle soovitud funktsinaalsuste nimekirja.		Plaanitav must have funktisonaalsus on hästi lahti kirjutatud. Ülesande keerukust arvestades võiks neid funktisionaalsusi vähendada või viia üle soovitud funktsinaalsuste nimekirja.
Line 13:		Line 13:
	Rakendus tundub olevat sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.		Rakendus tundub olevat sobilik mobiilsele platvormile, kuid tundub, et see on pea täielikult planeeritud töölaua lahendusena. Näiteks on mobiilsetel seadmetel tihti olemas GPS seade, mis võimaldaks automaatselt asukohta tuvastada.

	~~Lahendus~~ tundub ~~väga~~ keeruline, ~~kindlasti~~ on ~~väga põnev~~ näha ~~lõpp tulemust~~.		Kokkuvõttes võib öelda, et meeskond on analüüsi käigus oma idee läbi mõelnud ning arusaadavalt ja loogiliselt kirja pannud. Analüüsi põhjal tundub rakendus küllaltki keeruline ning selle teostamisel võib tekkida palju probleeme, kuid seda põnevam on näha lõpptulemust.