Talk:KKMK: Difference between revisions
Line 10: | Line 10: | ||
=Meeskond „[[V]]“ retsensioon meeskond „KKMK“ teenuse kohta – 4.06.2013= | =Meeskond „[[V]]“ retsensioon meeskond „KKMK“ teenuse kohta – 4.06.2013= | ||
Meeskons KKMK on teinud WCF teenuse mille eesmärk on pakkuda foorumite haldamise võimekust. Teenuse host osast on eraldatud teenuse meetodite täitevosa. Meetodite realisatsioon on omakorda viidud eraldi repositooriumitesse, nagu autorid neid sisaldavat kausta nimetavad. Membership, Role, Forum jm. päringute jaoks on tehtud eraldi klass, mis muudab nende päringute muutmise ja haldamise tulevikus väga lihtsaks. | |||
Eraldatud päringute klassid on küll hea, kuid mingil põhjusel pole nendest meetoditest tehtud staatilisi meetodeid, seega on nende välja kutsumiseks vaja esmalt luua alati meetodeid sisaldav klass. Autoritel võis selleks mingi põhjus olla, kuid koodist seda otseselt välja ei loe ning see tundub hetkel lihtsalt üleliigse koodina. Eraldatud päringute klassides hakkab ka silma päringu (query) tulemuse kontrollimine „null“´iga võrdlemise meetodil, mitmese (list) tüüpi tulemusega päring ei ole aga kunagi null, mingil põhjusel on aga selline kood sisse jäetud. | |||
Teenuse jaoks on loodud klass nimega „firstQueries“, mis arvatavasti on mõeldud esmase käivitamiseks ehk esimese foorumi ja kasutaja loomiseks. Antud klassist suurem osa on üks try-catch lause, milles veahaldus on lahendatud „huvitavalt“. Igasugune veahaldus on vast siiski positiivne nähtus. Antud esmakäivituse puhul vea tekkimisel, näiteks kasutaja loomisel, on juba eelnevalt foorum ning aplikatsioon juba loodud ning pärast vea kõrvaldamist ei saa enam sama foorumi nime kasutada. Antud juhul oleks võinud ebaõnnestumisel ka eelnevalt andmebaasi loodud andmed kustutada, sest ilma ühe osata ei ole väärtust ka teistel. | |||
Mudelite juures hakkab silma, et enamustel on korduvalt väljad loomise, uuendamise ja kustutamise kuupäevade jaoks, need oleks võinud minu hinnangul eraldi baasklassi viia. Mudelid on meeskond loonud, et kaardistada ümber LinqToSql andmekihist tulevaid klasse. Kuna aines käsitleti ka Entity Framework kood enne lähenemist, siis oodanud, et kasutatakse seda. Kood enne lähenemisel on kerge viia andmebaasi sisse muudatusi mida tihtipeale arenduse käigus tuleb teha, kuid samas võisid meeskonnal andmebaasitabelit olla korralikult läbi mõeldud. | |||
Teenuses on kasutusel ka asp.net´i sisseehitatud kasutajatehaldus ning see põimitud otse foorumi andmeid sisaldavasse baasi. Teenuses puudub võimekus kasutajate päringute logimiseks ning seega ka nende hulga piiramiseks. Samuti ei ole päringud teenuse poolelt kuidagi rollidega piiratud, seega saab reaalselt ligi kõikidele teenuse poolt väljastatud andmetele sõltumata rollist ning ka neid redigeerida ja kustutada. | |||
Kokkuvõttes on foorumite teenuse pakkumise idee majanduslikku perspektiivi omav ning ilmselgelt ka kogukondi kaasav. Teenuse juures on küll asju mida võiks täiustada, kuid tehtud algusest jääb mulje, et asi on läbi mõeldud ning mõninga lisaajaga oleks saavutatud enamatki. | |||
<b>Meeskond "[[V]]"</b> | <b>Meeskond "[[V]]"</b> |
Revision as of 20:31, 4 June 2013
Retsensioon meeskonna "KKMK" XML ülesande kohta
Meeskond KKMK on teinud XMLi genereeruvaks C# koodi kaudu, mis on väga lahe kuna tiim on ilmselgelt vaeva näinud. Sellegipoolest tekib küsimus, et miks on vaja sellist asja luua, sest ilmselgelt antud ülesande juures oleks käsitsi selle XMLi tegemine tunduvalt kiirem olnud. Üldiselt on C# kood siiski selge ja arusaadav. Koodi poolt genereeritud XML fail on korrektne ja täidab ka antud ülesande nõudmisi. Stiilifail 1 on hästi tehtud, see väljastab korrektse HTMLi ja lisab sinna ka stiilid. Muidu inline stiilid ei ole küll viisakad, aga sellega demonstreeris tegija oma CSS oskusi, mis on alati teretulnud (näiteks antud ülesandes polnud neid isegi nõutud) – tulemuseks on ilus HTML leht. Stiilifail 2 ja 3 annavad vastuse XML kujul ja ülesanne on täidetud, kuid jällegi ei saa aru miks ei oleks võinud vastused olla lihtsalt HTML kujul nagu esimese stiilifaili puhul. XML vastab nii automaatselt kui ka manuaalselt genereeritud skeemifailile ehk ülesanne täidab oma eesmärki. Skeemifaili juures kiidaks meeskonda selle puhul, et nad on lisaks automaatselt genereeritud skeemifailile teinud ka ise skeemifaili. Kokkuvõtteks võib öelda, et meeskond on oma ülesannetega küll väga hästi hakkama saanud, kuid samas leiame, et nad on teinud palju üleliigset ja ebavajalikku tööd.
Meeskond: "BitByBit"
Meeskond „V“ retsensioon meeskond „KKMK“ teenuse kohta – 4.06.2013
Meeskons KKMK on teinud WCF teenuse mille eesmärk on pakkuda foorumite haldamise võimekust. Teenuse host osast on eraldatud teenuse meetodite täitevosa. Meetodite realisatsioon on omakorda viidud eraldi repositooriumitesse, nagu autorid neid sisaldavat kausta nimetavad. Membership, Role, Forum jm. päringute jaoks on tehtud eraldi klass, mis muudab nende päringute muutmise ja haldamise tulevikus väga lihtsaks.
Eraldatud päringute klassid on küll hea, kuid mingil põhjusel pole nendest meetoditest tehtud staatilisi meetodeid, seega on nende välja kutsumiseks vaja esmalt luua alati meetodeid sisaldav klass. Autoritel võis selleks mingi põhjus olla, kuid koodist seda otseselt välja ei loe ning see tundub hetkel lihtsalt üleliigse koodina. Eraldatud päringute klassides hakkab ka silma päringu (query) tulemuse kontrollimine „null“´iga võrdlemise meetodil, mitmese (list) tüüpi tulemusega päring ei ole aga kunagi null, mingil põhjusel on aga selline kood sisse jäetud.
Teenuse jaoks on loodud klass nimega „firstQueries“, mis arvatavasti on mõeldud esmase käivitamiseks ehk esimese foorumi ja kasutaja loomiseks. Antud klassist suurem osa on üks try-catch lause, milles veahaldus on lahendatud „huvitavalt“. Igasugune veahaldus on vast siiski positiivne nähtus. Antud esmakäivituse puhul vea tekkimisel, näiteks kasutaja loomisel, on juba eelnevalt foorum ning aplikatsioon juba loodud ning pärast vea kõrvaldamist ei saa enam sama foorumi nime kasutada. Antud juhul oleks võinud ebaõnnestumisel ka eelnevalt andmebaasi loodud andmed kustutada, sest ilma ühe osata ei ole väärtust ka teistel.
Mudelite juures hakkab silma, et enamustel on korduvalt väljad loomise, uuendamise ja kustutamise kuupäevade jaoks, need oleks võinud minu hinnangul eraldi baasklassi viia. Mudelid on meeskond loonud, et kaardistada ümber LinqToSql andmekihist tulevaid klasse. Kuna aines käsitleti ka Entity Framework kood enne lähenemist, siis oodanud, et kasutatakse seda. Kood enne lähenemisel on kerge viia andmebaasi sisse muudatusi mida tihtipeale arenduse käigus tuleb teha, kuid samas võisid meeskonnal andmebaasitabelit olla korralikult läbi mõeldud.
Teenuses on kasutusel ka asp.net´i sisseehitatud kasutajatehaldus ning see põimitud otse foorumi andmeid sisaldavasse baasi. Teenuses puudub võimekus kasutajate päringute logimiseks ning seega ka nende hulga piiramiseks. Samuti ei ole päringud teenuse poolelt kuidagi rollidega piiratud, seega saab reaalselt ligi kõikidele teenuse poolt väljastatud andmetele sõltumata rollist ning ka neid redigeerida ja kustutada. Kokkuvõttes on foorumite teenuse pakkumise idee majanduslikku perspektiivi omav ning ilmselgelt ka kogukondi kaasav. Teenuse juures on küll asju mida võiks täiustada, kuid tehtud algusest jääb mulje, et asi on läbi mõeldud ning mõninga lisaajaga oleks saavutatud enamatki.
Meeskond "V"
Meeskond „V“ retsensioon meeskond „KKMK“ klientrakenduse kohta – 4.06.2013
Meeskond on loonud klientrakenduse enda pakutavale Forumite teenusele ning teostanud selle ASP.NET MVC4 baasil. Esmasel klientrakenduse käivitamisel näeme tühja lehte ilma ühegi navigeerimisvõimaluseta, kuid pärast pilku meeskonna wiki kasutusjuhendisse saame teada, et esmasel käivitusel tuleb navigeerida „setup“ lehele. Setup lehele andmete sisestamine tulemus on aga erinevad veateated kuni lõpuks ilmub „Epic Fail“ veateade. Iseenesest on veahalduse tegemine hea asi, kuid esimsele korral saadud veateada „Error when creating the membership“ ei olnud minu hinnangul piisavalt informatiivne. Esmase foorumi lisamine õnnestus siiski lõpuks pärast teenuse poolelt veateadete uurimist, millest tuli välja, et minu sisestatud parool ei vasta nõuetele. Antud klientrakenduses oleks võinud sel kohal olla ka sisendite valideerimine.
Kui foorum edukalt loodud, siis edasine kategooriate, teemade ja postituste lisamine tundus edukalt töötavat. Administraatorina on võimalik mul ka kasutajaid hallata, mis sisaldab nende pehmet kustutamist (kustutamiskuupäeva sättimine) ja profiilide muutmist, uusi kasutajaid ei saa administraator luua. Kasutajate kustutamise järel on võimalik neid ka taastada, kuid katsetamisel selgus, et selleks pole vajadust, sest kasutajaid saavad ka kustutatud olekus sisse logida ja rõõmsalt postitusi teha.(See viga on ühe autori andmetel nüüdseks parandatud 04.06.2013 - 20:50) Kustutamisel aga blokeeritakse kasutaja redigeerimine, seega selle üritamine tagastab „kollase surmaekraani“ koos huvitava informatsiooniga.
Olles ühe foorumi juba infoga täitnud, selle sulgenud ja uue loonud, satutakse olukorda, kus eelmisse foorumisse enam ei pääse ja uude samuti mitte. Olles aadressiribale kustutatud foorumi nime kirjutanud, siis pääseb sellele taas ligi, kuid uuele foorumile ei tundu olevat mingit võimalus administraatori ligipääsu luua. Samas positiivselt küljelt niipalju, et administraatori osa tundub olevat korralikult turvatud, erinevalt kasutajate poolest. Näiteks postitusi saab teha, redigeerida ja kustutatada igaüks, kusjuures igaühe postitusi.
Rakendus vajaks küll veel testimist, kuid esmamulje hindaks siiski heaks. Rakenduse koodi poolelt on teretulnud nähtus, et vaadetesse antakse info ette vaatemudelite kaudu, mitte niinimetatud vaatekotis (viewbag). Mõnes kohas koodis tekkis esmapilgul küsimusi, et milleks just nii ning mida see koodiosa nüüd teeb. Seega oleks lihtsama arusaamise nimel võinud kasutada kommenteerimist, seda enam, et projekt oli teostatud meeskonna peale. Hea on näha, et kohati on kasutatud ka javascripti, ilma milleta tänapäeval veebilehti tehes tihtipeale ei saa.
Kokkuvõtteks on tegemist siiski asjaliku rakendusega, mis täidab esmased ootused ehk foorumi loomine, haldamine ja sellesse postitamine. Eelnevalt olen toonud välja küll vigu, aga nagu meeskond ise oma wiki lehel mainis, siis arenemisruumi on tõesti. Veelgi enam, et vigu leida ja neid välja tuua on kerge, kuid välisel vaatlusel hinnata inimeste panust (loe: valatud verd ja higi) on keeruline.
Meeskond "V"