Talk:Meeskond "C terav"
XML osa arvustus
XML struktuur on korralikult tehtud, süntaksi vigu pole näha. Kuupäevad ja ajad on piisavalt täpselt ära kirjeldatud, et neid hiljem oleks kerge välja lugeda. Mis aga mina oleks natuke teistmoodi teinud, on näiteks aadresi väli, kus hetkel on väli nimega "linnVald" ja peale mida tuleb kohe "tanav", kui aga näiteks ma tahaks kirjeldada kohvikut, mis asub mingis maakohas x vallas, siis poleks enam kohta, kuhu kirjutada asula nime. Teine asi, mis natuke liiga jäik on, on lahtioleku ajad, näiteks kui tahaks märkida kohvikut, mis töötab iga päev esmaspäevast kuni pühapäevani, siis alati peaks panema nädalavahetuse päevad erandpäevade alla, vaatamata, et selle kohviku puhul võib näiteks laupäeval lahtiolemine täiesti tavaline olla.
Skeemifail on olemas, samuti ka XSLT. Kõik piisavalt hästi tehtud, XSLT tulemuses oleks võinud ainult kuupäev ja kellajad korralikumalt punktide või kooloniga eraldatud olla, et loetavus parem oleks.
Rauno Rüga
Rruga 20:55, 4 March 2011 (EET)
XML-i arvestus
XML on üpriski korralikult disainitud. Lahtiolekuaegade jaotus ei piina silmi. On võimalik puhtalt kirja panna lahtiolekuajad kohviku kohta, mille ajad mitme päeva puhul kattuvad, või siis läbi "aeg" elemendi kirjeldada erinevaid aegu erinevatel päevadel. Toitude jaotus menüüs on ka väga hästi tehtud, küll aga oleks ehk ise teinud toitudele ülemelemendid nagu "liik" või "kategooria" kuhu alla oleks võimalik toite lisada. Mis natuke kahtlust tekitas, oli toitude jaotamine koguse järgi ja seda hindade all. Koguse kirjeldus võiks ehk olla ise mingi elemendi sees (mitte elemendina). Praegu on vist eeldatud, et kõikidel toitudel/kaupadel on "tais", "poolik" jm ühised portsjonid.
Joosep Ilves
XML Arvustus
- Kuna ise teeme ka sarnast projekti võrdlen seda palju meie omaga. Teil on kohvikute kohta info väga hästi ja täpselt välja toodud. Võibolla isegi liiga täpselt kuna te ei või kunagi teada kes teil kliendiks registreerib, et kas ta üldse oskab enda koordinaate leida, see tähendaks teile rohkem tööd ja võib põhjustada kliendi frustratsiooni kui ka teile. Isiklikult mulle koordinaatide süsteem meeldib, saate nii teha ühe suure kaardi kuhu kõik kohvikud peale märkida.
- Toidud on toodud välja väga lihtsalt, aga samas tundub see lisade süsteem pisut mõttetu, restoranides on tavaliselt lisad veel eraldi ostetavad aga kohvikus tavaliselt ei osta kotletti ja kartulit eraldi. Kommentaarid on teil ka kohe xmliga ära kaetud, kuid me näiteks edastame vaid laikijad, üldjuhul kommenteeritakse siis kui toit oli halb mis võib rohkem halba teha kohvikule kui head, aga jah, maitse asi. Portsude osa lahendasime sama moodi ja see meeldib.
- Üldiselt on XMLil korralik laotus, aga liigne keskendumine kohvikule endale kui menüüle, mis minu arvates on peamine.
- Jaan Kruusma D22
XML Arvustus
Kohe hakkab silma fakt et teie süsteem ei toeta mitut kohvikut, tunnen et see on suur miinus kuna süsteemi praktiline väärtus on seetõttu väga madal - ma saan aru, et te teete seda ühele kliendile, aga mis siis kui see üks klient tahab teie süsteemi mitmes kohvikus hakata kasutama tulevikus? Teiseks tundub väga overkill see ajatempli lahtikiskumine juppideks, lihtsam oleks kasutada mingit UNIX timestampi moodi asja ja siis kasutajaliideses see loetavaks ajaks koverteerida. Samuti on ülisuur miinus ajatsooni puudumine - sisuliselt ei saa teie programmi kasutada korraga ühe kliendi poolt mitmes riigis. Kolmandaks kriibib silma see "Eurohind", kas te mõtete teha nii et iga klient peab kasutajaliidesse kirjutama oma rahaühiku ja siis konverteeritakse on-the-fly eurodest või peab hakkama XMLi iga välisriigi jaoks eraldi täiustama?
Muu on normaalne ja eriti meeldib teie kolmekihiline süsteem.
Tanel Liiv D22
XML Arvustus
Mis meeldis ning mis ei karjunud oli lahtioleku aegade jaotus - oli lihtsalt ja arusaadavalt tehtud. Mis silma hakkas oli see, et seal on välja toodud küll väikesed ja suured portsud, kuid see kas ports saadaval on, käib siinkohal toidu kohta, see tähendab seda, et kui näiteks suur ports otsas on, siis ei tähenda see automaatselt seda, et poolikut portsu pole ka võimalik saada. Kui näitena võetud meie ITK kohvik, siis seal ennegi olnud näiteks ainult pool portsu alles. Samas oleks võinud kommentaaride alla lisada ka kuupäeva, millal seda antud toitu kommenteeritud on, et oleks võimalik näiteks viis kõige uuemat kommentaari kuvada. Üldjuhul võib rahule jääda, kõik tähtis oli ära kirjeldatud, vigu ei leidnud ka skeemifailist ega XSLT'st.
Kaspar Kallasmaa D21
XML Arvustus
XML on üldiselt hästi koostatud. Mõningad asjad oleks isiklikult teistmoodi teostada. Näiteks ,ei peaks ma vajalikuks kordinaatide lisamist. Lahtioleku aegade juurde oleks lisanud veel laupäev ja pühapäev kuna alati on võimalus, et teine klient,kes võtab teilt teenuse arenduse, võib hoida oma kohvikuid lahti ka nädalavahtusel ja selle näite puhul oleks selle kohviku saatuseks panna "suletud". Kommentaarile oleks võinud lisada ka aeg mil kommentaar tehti. Üks miinus on jah see, et toit on kas otsas või mitte kui teil on olemas täis ja poolik ports. Sel juhul pole teada, kas on veel poolikut või täis portsu kui on märgitud otsas. Üldiselt on xml hästi koostatud ja kergesti arusaadav, kus miski asi asub :)
Madis Kõosaar D21
XML Arvustus
Üldiselt võib XML-iga rahule jääda kuid mõned asjad tooks siiski välja. Nagu eelnevalt mainitud siis lahtioleku aeg on teil ainult nädalasees. Olete vist oma XML faili teinud meie kooli söökla jaoks nö. Mis meeldib on kordinaatide süsteem, ilgelt hea oleks ühe mapi pealt erinevaid kohvikuid/sööklaid näha. Kui eelnevalt öeldi, et võiks olla kommentaar millal tehteud siis ma arvan, et sellel väga vahet pole. kuna kommentaar kehtib nö nagunii tänase päeva menüü kohta. Kuid "otsas" süsteem võiks olla küll pooliku portsioni jaoks ka. Muidu tundub, et XML on täiesti mõistlik ja asjalik
Madis Sildaru D32
Arvustus XML failile
XML oli korralikult ülesehitatud ja struktureeritud. Samuti olid ka XML Schema ja XSLT normaalselt tehtud.
Siiski võinuks lahtiolekuajad olla veidi teistsuguse struktuuriga - võibolla olnuks lihtsam ära tuua nädalapäev ning avamis ja sulgemis ajad tol päeval. Seejuures, kui sulgemis aeg oleks üle kesköö, siis arvestataks seda ikkagi antud lahtiolekuaja koosseisus. Erijuhud lahtiolekuaegades, nagu näiteks lõunapausid, võiks siis märkida vastava nädalapäeva juurde eraldi. Lisaks võiks muidugi olla ka ajavööndi määramise võimalus, kuid see oleks hädavajalik vaid juhul, kui lahendus on mõeldud kasutamiseks mitmes ajavööndis korraga.
Hea on aga antud lahenduse puhul see, et olulisemad andmed ei ole toodud atribuutidena.
Teenuskihi Arvustus
Antud projekti teenuskihi juures jääb kohe silma, et andmemudel oleks justkui andmebaas ( wiki veebiteenuse alampunkti põhjal tekib selline mulje ). Lisaks pole pakutavas zip failis andmebaasi, mis toetab mainitud väidet. See aga on minuarust küll väga vale lähenemine, kuna teil on tehtud dbml andmemudeli fail, mis aga pole mõeldud üldsegi selleks, et selle põhjal andmebaasi genereerida. Võibolla kuidagi see õnnestuks, aga sellist funktsionaalsust .net ametlikult küll ei toeta.
Teine asi, mis oleks võinud teistmoodi olla, on valitud projekti tüüp. Kui juba WCF valisite teenuskihi jaoks, oleks võinud selle jaoks eraldi WCF projekti teha, hetkel on seal palju üleliigset asp.net träni kaasas, mis ei puutu üldse teenuskihti.
Liigudes edasi koodini ja meetoditeni, märkasin et tagastate teenuskihis alati klasse, isegi siis kui toimub millegi sisestus "teie andmebaasi" ja tagasi oleks vaja saada vaid booleani, et kas asi õnnestus või mitte. Suure teenuskihi kasutusel lisaks see kindlasti suurt koormust, kui lihtsa booli tagastamise asemel on vastuseks mingi suuremat sorti klass. Silma jäi ka järgnev koht koodis:
KasutajaKirjeClass KKC = new KasutajaKirjeClass();
if ( KKC.kontrolliKohvikuKasutaja(kohvikID, kasutajaID) == true)
{
try
{
kont.ExecuteCommand("insert into Menyy(fkKohvik_id,alates,kuni) values('" + kohvikID + "','" + alates.ToString("MM.dd.yyyy") + "','" + kuni.ToString("MM.dd.yyyy") + "');");
return true;
}
catch
{
return false;
}
}
else {
return false;
}
Kontrolli sisu on siin:
public bool kontrolliKohvikuKasutaja(int kohvikID, int kasutajaID)
{
var kasutajaOlemas = kont.KohvikuKasutajas.Where(x=>x.fkKohvik_ID==kohvikID && x.fkKasutaja_ID == kasutajaID).SingleOrDefault();
if (kasutajaOlemas == null)
{
return true;
}
else
{
return false;
}
}
Hetkel toimib süsteem nii, et kui antud kohviku id ja kasutaja id-ga kasutaja on andmebaasis, siis kasutajaOlemas muutuja saab selle objekti endale (mis pole kaugeltki turvaline autentimine) ja järgneva tingimuse põhjal tagastatakse false, seega väljakutsuvas meetodis ei täideta sql käsku. Käsk aga täidetakse sellisel juhul, kui andmebaasist ei leitud sellist kasutajat, kas mitte see süsteem vastupidi ei peaks töötama !? Sama asi oli veel mitmes kohas. Oleksite võinud ka valida ühe stiili, kas linq kasutamise või siis ainult sql käsud, hetkel läbisegi nii ühte kui teist kasutatud.
Head oli ka, see asi mis teil tehtud, oli tähtajaks valmis.
Rauno Rüga
Rruga 19:07, 23 April 2011 (EEST)
Tänan, et tõid esile selle vea. Kui hakkasime rakendust tegema siis vaatasime üle ja parandasime - Siim Sarv
Teenuse arvustus
Wiki puhul jäi silma, et klassid ja meetodid on kõik ilusasti wikis kirjas ja lahti seletatud, mis mida peaks tegema. Meeldis ka see, et oli välja toodud eraldi visioon andmemudelist. Koodi oleks võinud ka mõnel pool kommenteerida, olenemata sellest, et wikis on kõik juba kirja pandud. Kohati jäi arusaamatuks see, miks on Lahtioleku aegade jaoks tehtud eraldi tabel selle asemel, et need andmed siduda kohvikute andmetega. Kood üldiselt nägi välja meeldiv, mõnel pool olid mõned treppimise vead. Olen nõus ka eelkõnelejaga, et koodi kirjutamisel oleks võinud kasutada ühest stiili (kas LINQ või SQL), samas aga, kui te võtsitegi eesmärgiks mõlemat varianti proovida, siis on see teie otsus. Üldjuhul oli kena, plussiks veel ka see, et tabelites olid viisakad andmed.
Helen Muidik, D21
Teenuse arvustus
WMeeldis see , et wikis oli teenuse kohta kõik info kenasti välja tood ja seletatud, mis iga klass/meetod teeb. Kood nägi väga hea välja. Hästi üles ehitatud ja polnud lohakas. Sama märkus, mida eelkõneleja mainis, et päringud oleks võinud olla ühes stiilis kas linq või sql. Aga ei olnud väga häiriv :). Üks pisike märkus veel et oleks võinud koodi rohkem kommenteerida. Kiire ülevaatamise puhul kergem aru saada mida tehti. Üldjuhul, jäi korralik ja vaeva nähtud mulje :)
Madis Kõosaar, D21
Arvustus veebiteenusele
Teenuse lähtekood on üldjoontes mõistlikult kirjutatud, ehkki kohati aitaks mõningad kommentaarid asjast kiiremini aru saada.
Teenusega andmete vahetamiseks oleks liidestel aga olnud võibolla parem kasutada struct'e. Kuna struct'idel puuduvad meetodid, siis on need oma olemuselt rohkem kooskõlas teenuste toimimise loogikaga - vahetatakse üksnes andmeid (atribuudid), mitte käitumisi (meetodid). Sellisel juhul ei teki olukordi, kus klassi kirjutatakse kogemata meetodeid, mis toimivad vaid ühel osapoolel (kas rakendusel või teenusel). Täiendavalt oleks struct'e hea kasutada ka teenuse liidestel sisendina, kuna siis ei tekiks liidestel pikki parameetrite loetelusid.
Lisaks tundub teenuses olevat ka võimalus statistika tegemiseks, ent paistab, et seda pole reaalselt kasutatud.
Andmebaas on üsna mõistliku ülesehitusega. Lisaks on veel hea, et ka andmebaasi skeem on wiki's ära toodud.
Muidugi on igati kasulik põhjalik teenuse kirjeldus wiki's.
Teenuse arvustus
Esiteks mis kohe silma hakkas teenuse koha pealt oli ilus ja põhjalik wiki. See tähendab ka seda, et projektiga on vaeva nähtud, see on läbi mõeldud ning sinna korralikult aega investeeritud. Meeldis just see, kuidas klassid ja meetodid on lahti kirjeldatud ning on nende nimetamisel on hoitud sarnast joont. Pluss pooleks on ka kindlati see, et neid meetodeid on võimalikult palju tehtud ning need võivad tunduda sarnased(nime poolest), kuid reaalselt on seal erinevus olemas. Pigem rohkem "väksemaid" meetodeid kui vähem ja suuremad. Kui vaadata andmebaasi mudelit, siis mis natuke häirib on see, et eksisteerivad sellised väljad nagu tUp, tDown, ülejäänud väljad on nagu eesti keeles - seal oleks võinud ühtsemat joont hoida, aga see on selline väike puudus. Üldjuhul jättis väga positiivse mulje.
Kaspar Kallasmaa D21
Rakenduste arvustus
Meeldis see, et on tehtud valmis mitu rakendust, mis kasutavad sama teenust. On olemas WP7 mobiilirakendus , dekstopklient kui ka veebileht. Desktop klient oleks võinud iseenest natuke "värvikam" välja näha. Aga samas kasutajamugavus on täiesti olemas. Mobiilirakendust ise ei proovinud kuid nägin nende esitlust ja seal tundus see päris asjalik. Veebilehel olev rakendus on võialikult lihtne ja hõlpsasti kasutav.
Toomas Soha D21 ---
Arvustus veebiteenuse klientidele
Rakenduste näol on esindatud nii Windows Forms töölauarakendus, ASP .NET veebirakendus kui ka WP7 mobiilirakendus. Kõik klient rakendused on üldjoontes üsna lihtsa ja selge ehitusega.
Lähtekood on korralik, ehkki võiks kohati olla rohkem kommenteeritud, et sellest oleks võimalik kiiremini aru saada.
Siiski võinuks WPF ja ASP rakenduste puhul panna kliendi identifikaatorkoodi rakenduse juures ühte kohta - näiteks static klassi - nagu seda WP7 rakenduse puhul ka tehtud on. Sellisel juhul oleks seda lihtsam ühest kohast hallata.
Hea on, et klient rakenduste kasutamine on wiki's ka ära kirjeldatud. Täiendavalt on kasulik ka piltide kasutamine wiki's, mis annab rakendustest kiiresti hea ülevaate.
Arvustus projektile kokkuvõtvalt
Projekti raames tehtud töö oli üldjoontes üsna korralik. Kõik komponendid toimisid pealiskaudsel kasutamisel normaalselt.
Püstitatud ülesanded olid üldiselt mõistlikul viisil lahendatud. Lähtekood oli korralik, kuigi kommentaare võinuks ehk kohati veidi rohkem olla.
Siiski oli wiki's pea kogu vajalik info projekti kohta olemas ning seda ilma liigselt detailidesse süüvimata. Seepärast oli wiki üsna selge ja ülevaatlik. Täiendavalt olid abiks ka wiki'sse lisatud pildid ja skeemid.
Arvestades, et antud juhul oli vist tegemist tiimi liikmete esimese tööga teenuste ja rakenduste valdkonnas ning ka nende ajalised võimalused seejuures olid tõenäoliselt üsna piiratud, siis võib tehtud tööga küll igati rahule jääda.
---
