Talk:Ajamasin - Revision history

Ptiganik: /* Arhitektuur */

2016-11-13T21:05:30Z

Arhitektuur

← Older revision		Revision as of 00:05, 14 November 2016
Line 2:		Line 2:

	=== Arhitektuur ===		=== Arhitektuur ===
			Loodetavsti saame õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi programmist või vaatest, mille aluskood on ilmselt üpris sarnane, kuid tegu on siiski täiesti eraldiseisvate programmidega, mis on ühendatud vaid andmebaasi kaudu. Kui nii, siis kahe programmiloomine ja haldamine võib mõnes mõttes olla lihtsam (funktsionaalust saab eraldiseisvalt täiendada, ühe programmi muudatused ei tohiks teist segada jne), kuid võib pikemas perspektiivis tekitada ka probleeme (alguses kohati sarnane kood võib kahe programmi lõikes kiiresit muutuma hakata ning mingi aja pärast võib olla vaja hallata kahte täiesti erinevat programmi).

	~~Loodetavsti saan õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi~~ programmist ~~või vaatest~~, ~~mille aluskood~~ on ilmselt ~~üpris sarnane, kuid tegu~~ on ~~siiski~~ täiesti ~~eraldiseisvate programmidega~~, ~~mis~~ on ~~ühendatud vaid andmebaasi kaudu~~. ~~Kui nii~~, siis ~~kahe programmiloomine ja haldamine võib mõnes mõttes olla lihtsam (funktsionaalust~~ saab eraldiseisvalt täiendada, ühe programmi muudatused ei tohiks teist segada jne), kuid võib pikemas perspektiivis tekitada ka probleeme (alguses kohati sarnane kood võib kahe programmi lõikes kiiresit muutuma hakata ning mingi aja pärast võib olla vaja hallata kahte täiesti erinevat programmi).		Põhimõtteliselt võib kodutöö koosneda ka ainult ühest programmist, aga selle sees on siis kuidagi (nt sakkidega) eristatud pakkumise loomine ja kandideerimine. Kuna asi töötab ühe ettevõtte sees, siis ilmselt on täiesti võimalik olukord, kus üks isik on nii pakkumiste looja kui ka kandideerija. Kuna selliseid rolle kuigipalju siiski olla ei saa, siis saab pakkumiste loomist kasutajaõigustega piirata.

	Põhimõtteliselt võib kodutöö koosneda ka ainult ühest programmist, aga selle sees on siis kuidagi (nt sakkidega) eristatud pakkumise loomine ja kandideerimine. Kuna asi töötab ühe ettevõtte sees, sisi ilmselt on täiesti võimalik olukord, kus üks isik on nii pakkumiste looja kui ka kandideerija. Kuna selliseid rolle kuigipalju siiski olla ei saa, siis saab pakkumiste loomist kasutajaõigustega piirata.		Tundub, et ideaalsel juhul peaks praeguse rakenduse puhul tegemist olema klient-server rakendusega, kus kogu loogika on serveri poole peal. Antud programmi kirjeldus viitab aga sellele, et kogu loogika asub siiski kasutaja arvutis asuvas programmis. Ilmselt saab kodutöö eesmärgid ka nii täidetud, kuid kui soovida sama süsteem reaalselt mitmete kasutajatega tööle panna, siis võib tekkida mitmeid probleeme nagu näiteks sama ürituse samaaegne muutmine mitme isiku poolt vms.

	Tundub, et ideaalsel juhul peaks praeguse rakenduse puhul tegemist olema klient-server rakendusega, kus kogu loogika on serveri poole peal. Antud programmi kirjeldus viitab aga sellele, et kogu loogika asub siiski kasutaja arvutis asuvas programmis. Ilmselt saab kodutöö eesmärgid ka nii täidetud, kuid kui soovida sama süsteem reaalselt mitmete kasutajatega tööle panna, siis võib ~~ilmselt~~ tekkida mitmeid probleeme nagu näiteks sama ürituse samaaegne muutmine mitme isiku poolt vms.

	=== Funktsionaalsus ===		=== Funktsionaalsus ===

Ptiganik at 21:01, 13 November 2016

2016-11-13T21:01:49Z

← Older revision		Revision as of 00:01, 14 November 2016
Line 1:		Line 1:
	Ajamasinat retsenseeris meeskond [[Isearve]], Siim Kallari ja Priit Tiganik		Ajamasinat retsenseeris meeskond [[Isearve]], Siim Kallari ja Priit Tiganik

	~~RETSENSIOON ON VEEL KIRJUTAMISEL~~


	=== Arhitektuur ===		=== Arhitektuur ===

Ptiganik: /* Arhitektuur */

2016-11-13T20:54:40Z

Arhitektuur

← Older revision		Revision as of 23:54, 13 November 2016
Line 6:		Line 6:
	=== Arhitektuur ===		=== Arhitektuur ===

	Loodetavsti saan õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi programmist või vaatest, mille aluskood on ilmselt üpris sarnane, kuid tegu on siiski täiesti eraldiseisvate programmidega, mis on ühendatud vaid andmebaasi kaudu.		Loodetavsti saan õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi programmist või vaatest, mille aluskood on ilmselt üpris sarnane, kuid tegu on siiski täiesti eraldiseisvate programmidega, mis on ühendatud vaid andmebaasi kaudu. Kui nii, siis kahe programmiloomine ja haldamine võib mõnes mõttes olla lihtsam (funktsionaalust saab eraldiseisvalt täiendada, ühe programmi muudatused ei tohiks teist segada jne), kuid võib pikemas perspektiivis tekitada ka probleeme (alguses kohati sarnane kood võib kahe programmi lõikes kiiresit muutuma hakata ning mingi aja pärast võib olla vaja hallata kahte täiesti erinevat programmi).

			Põhimõtteliselt võib kodutöö koosneda ka ainult ühest programmist, aga selle sees on siis kuidagi (nt sakkidega) eristatud pakkumise loomine ja kandideerimine. Kuna asi töötab ühe ettevõtte sees, sisi ilmselt on täiesti võimalik olukord, kus üks isik on nii pakkumiste looja kui ka kandideerija. Kuna selliseid rolle kuigipalju siiski olla ei saa, siis saab pakkumiste loomist kasutajaõigustega piirata.

			Tundub, et ideaalsel juhul peaks praeguse rakenduse puhul tegemist olema klient-server rakendusega, kus kogu loogika on serveri poole peal. Antud programmi kirjeldus viitab aga sellele, et kogu loogika asub siiski kasutaja arvutis asuvas programmis. Ilmselt saab kodutöö eesmärgid ka nii täidetud, kuid kui soovida sama süsteem reaalselt mitmete kasutajatega tööle panna, siis võib ilmselt tekkida mitmeid probleeme nagu näiteks sama ürituse samaaegne muutmine mitme isiku poolt vms.

	=== Funktsionaalsus ===		=== Funktsionaalsus ===

Skallari: /* Funktsionaalsus */

2016-11-13T20:34:56Z

Funktsionaalsus

← Older revision		Revision as of 23:34, 13 November 2016
Line 11:		Line 11:
	=== Funktsionaalsus ===		=== Funktsionaalsus ===

	Väga mahukas ettevõtmine!		Väga mahukas ettevõtmine ning väga täpselt on kirja pandud kasutaja käitumine!
	Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides
			Soovitaks korraks hinnata töö tegijatel, kaua võib nende erinevate osade programmeerimine aega võtta ning hinnata, kas saadakse valmis õigeks ajaks ja võib-olla kaaluda funktsionaalsuse vähendamist. (N: alustada prototüüpimist ainult tööpakkumise sisestamisest/kustutamisest, vaatamisest ning vastuvõtmisest)

			Hetkel jääb selgusetuks, kuidas erinevaid kasutajaid eristatakse, kas olemas on sisselogimise funktsioon või saab iga kasutaja anonüümselt valida, kes ta on ning kui tuleb sisselogimise funktsioon, siis kes tegeleb kasutaja registreerimisega, kasutaja ise või organisatsiooni HR?

			Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides.
			Töö algus ja lõpu aega soovitaks märkida kellaaegadega, kuna isegi organisatsiooni siseselt võivad töö algus / lõpu kellaajad olla erinevad (võimalikud ka öövahetused).
			Sellest lähtuvalt, kas kuhugi läheb hiljem kirja ka palju tööd tehti või on arvestus selle järgi, et inimesed käivad tööl lepingu alusel 8-17.00 (16.00) ja siis valivad selle järgi, organisatsiooni siseselt, kus nad töötada tahavad?

			"Organisatsioonisiseste tööpakkumiste sirvimise moodul töötajale" - mitte kuskilt ei tule välja, kus kohas peaks olema töötajale see nupp, millega ta saab ennast mingile tööpakkumisele registreerida (küll on jutt sellest, kuidas ta saab ennast maha registreerida)

			"vastuvõetud – kui tööpakkumise juurde märgitakse selle töö vastu võtnud isiku andmed, muudetakse pakkumise staatus „vastuvõetud“" - segane lause, kas tööpakkumise juurde märgitakse isiku andmed süsteemi poolt automaatselt kui ta registreerib või kes märgib?

	=== Andmebaas ===		=== Andmebaas ===

Ptiganik: /* Andmebaas */

2016-11-13T20:32:12Z

Andmebaas

← Older revision		Revision as of 23:32, 13 November 2016
Line 22:		Line 22:
	*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.		*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
	*Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.		*Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.
			*Analüüsi funktsionaalsust kirjeldavas osas on algust tehtud juba ka andmete tüüpide kirjeldamisega, mis on väga hea. Pigem võiks seda teemat ilmselt just andmebaasi skeemi osas puudutada, sest siis ei peaks seda iga funktsionaalsuse juures eraldi tegema ning väheneb tõenäosus näpukatele. Näiteks paistab üks selline olevat ürituse ja positsiooni tekstiväljade pikkuse muutus vastavalt funktsionaalsuse kirjeldusele. Igaks juhuks mainime ära, et andmebaasi enda eelistatud kuupäeva formaat on YYYY-MM-DD.

Ptiganik at 20:22, 13 November 2016

2016-11-13T20:22:26Z

← Older revision		Revision as of 23:22, 13 November 2016
Line 1:		Line 1:
	Ajamasinat retsenseeris meeskond [Isearve ~~https://wiki.itcollege.ee/index.php/Isearve~~], Siim Kallari ja Priit Tiganik		Ajamasinat retsenseeris meeskond [[Isearve]], Siim Kallari ja Priit Tiganik

	RETSENSIOON ON VEEL KIRJUTAMISEL		RETSENSIOON ON VEEL KIRJUTAMISEL

Ptiganik at 20:18, 13 November 2016

2016-11-13T20:18:54Z

← Older revision		Revision as of 23:18, 13 November 2016
Line 1:		Line 1:
	~~BRONEERING~~		Ajamasinat retsenseeris meeskond [Isearve https://wiki.itcollege.ee/index.php/Isearve], Siim Kallari ja Priit Tiganik

	Ajamasinat ~~retsenseerib~~ meeskond ~~Isearve~~ [~~https://wiki.itcollege.ee/index.php/~~Isearve https://wiki.itcollege.ee/index.php/Isearve]

	RETSENSIOON ON VEEL KIRJUTAMISEL		RETSENSIOON ON VEEL KIRJUTAMISEL

Ptiganik: /* Andmebaas */

2016-11-13T20:14:47Z

Andmebaas

← Older revision		Revision as of 23:14, 13 November 2016
Line 23:		Line 23:
	*Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.		*Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
	*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.		*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
			*Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.

Ptiganik: /* Andmebaas */

2016-11-13T20:10:30Z

Andmebaas

← Older revision		Revision as of 23:10, 13 November 2016
Line 19:		Line 19:

	Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.		Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.
	Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.		*Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.
	Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus.		*Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus.
	Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.		*Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
	Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.		*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.

Ptiganik: /* Andmebaas */

2016-11-13T20:09:52Z

Andmebaas

← Older revision		Revision as of 23:09, 13 November 2016
Line 20:		Line 20:
	Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.		Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.
	Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.		Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.
	Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus		Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus.
			Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
			Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.