Talk:KRTT
Retsensioon XML andmefaili osale
XML
Element "tegutsemisaeg" võiks olla ära jaotatud kaheks: "algusAasta" ja "aõppAasta" või teha need elemendid "tegutsemisaeg" elemendi sisse. Attribuudi "pikkus" võiks olla jagatud erinevateks attribuutideks "minut" ja "sekund". Attribuut "žanr" puhul ei ole soovitatav kasutada "ž" tähte, kuigi encoding on küll UTF-8. Albumite ja Artistide ID väärtused on üle kontrollimata - osad ID väärtused kattuvad. Elemendil "artist" peaks samuti olemasolema attribuut "id". Elemendi "laulud" attribuut "kogus" näitab ainult alamelementide arvu, seega ei anna mingisugust lisainfot. Sama lugu on ka attribuudi väärtusega "yhik", mis ei anna samuti midagi juurde, sest laulude kogus on ju peamiselt ikka "tk" väärtusena. XML-i faili struktuur on hea ja tore, et olete kasutanud CDATA elemente sõne väärtuste korral. Samuti valideerub XML vastavalt skeemile.
XSD
Skeemifailis on märgitud elementide Id-de väärtuseks unsignedInt, mis ei ole sobiv andmebaaside korral. Tuleks kasutada int-i, sest uint ei vasta CLS (Common Language Specification) nõutele. Ilmumisaasta puhul ei ole mõistlik kasutada unsignedInt-i, sest vastav väärtus mahuks ära ka näiteks uShorti.
Küsimus: Miks on elemendi "laul" attribuut "pikkus" kohustuslik, kuid attribuut "yhik" on valikuline?
Transformatsioonid
Transformatsioonid töötavad kõik ja kuvavad seda, mida nad peaksid kuvama. Sellegipoolest oleks võinud kasutada ka IF-tingimuslauseid, näiteks attribuuti "aktiivne", mis oleks transformatsiooni korral kuvanud ainult aktiivseid artiste. Kaks viimast transformatsiooni teevad põhimõtteliselt sama sisu, ainult vorming on teine.
---
Kokkuõtvalt on ülesanne täidetud, kuid kui soov on kasutada antud XML faili, siis tuleks sisse viia mõningaseid parandusi!
Tegi meeskond VariableMoods
Kuupäev: 11. märts 2015
Retsensioon meeskonnalt Vertigo
Meeskond KRTT on oma esimeseks XML ülesandeks koostanud artistide ja nende albumite kataloogi.
XML
Tehtud töö vastab esitatud tingimustele. XML-il on isegi rohkem dimensioone, kui 4, seega on koostatud mudeli keerukus piisav. On kasutatud piisaval kogusel dimensioonidel atribuute, mis on enamad, kui id, näiteks nagu ilmumisaasta, pikkus, kogus jne. Tegutsemisaja elemendi puhul oleks võinud läbi mõelda sisemise liigenduse, et ei tekiks sellist olukorda, nagu näites toodud “Meie mehe” artisti puhul, kus on tegutsemisaeg 1997-..., kuna artist tegutseb ka täna. Sellisel juhul ei anna 3 punkti erilist lisainfot. Lisaks ei ole sellisel juhul võimalik teha lihtsalt väljavõtteid kataloogis olevate artistide tegutsemisaja järgi kronoloogiliselt. Tegutsemisaja elemendile oleks võinud teha 2 atribuuti, näiteks “alates” ja “kuni” ning “kuni” määrata “not required”, mis võimaldaks kirjeldada olukorda, kus artist on tegutsemas ka hetkel, mil kataloogi muudetakse. Atribuudi “žanr” kasutamise võiks üle kaaluda, kuna ž-täht võib tekitada probleeme loodu ootuspärases toimimises. Hea, et on kasutatud CDATA-t artisti ja laulu nimedes.
XSD
On arusaamatu, miks “yhiku” atribuut on mõnes kohas “optional” ja mõnes kohas “required”. Sisuliselt ei näe põhjendust selleks.
XSLT
Transformatsioonid töötavad. Kasutatud on ilusti for each-tsükleid. Viimase kahe transformatsiooni erinevus seisneb esitlusviisis. Kolmanda transformatsiooni oleks võinud teha sisuliselt põnevama, näiteks ära kasutades mõnda muud atribuuti, mis XML elemntidele lisatud, näiteks sorteerida andmeid žanri järgi vms.
Retsentsioon meeskonnalt Liisa ja Poisid
Valisime retsenseerida meeskond KRTT. KRTT oli otsustanud teha Xml-i artistide kohta. Milles kuvatakse välja artistid, nende albumid ja albumites olevad laulud.
- Vaatades esialgselt peale nende Xml-ile, tundub see üpris kena ja puhas. Pärast kiiret ülevaatamist, kasutasime ka xml validaatorit, et kindel olla, et ei oleks mingeid väikseid vigu. Xml läbis puhtalt validaatori.
Xml-i tehes on mõeldud läbi xml-i arhitektuur, mis tagab selle, et ei ole üleliigset pahna. Samuti on läbi mõeldud atribuudid mis on kasutatud elementidel. Xml-i töös oli nõutud, et elementidel oleks rohkem atribuute kui id, siin on see tingimus ilusti täidetud.
- XSD-st on natuke raske aru saada, kuid tundub, et kõik on õige. unsignedInt asemel võiks olla int kuid antud ülesande puhul ei ole see niivõrd oluline. Tundub et required atribuuti on kergelt lambist kasutatud ja seda ei ole läbi mõeldud, sest tekib vastuoluline situatsioon näiteks atribuudika yhik. Kuid vist on mõeldud koodi kirjutades nii, et tegutsemisaasta pole just kõige olulisem, aga see mis ühikus laul on, on kindalsti vajalik, kuna see määrab ära kas on tegemist tunniga või minutiga.
- XSLT on hästi koostatud. Kood teeb täpselt seda mis öeldud on ja kood lugedes saab ilusti aru mis seal tehtud on. Kasutatud on for tsükkleid, mis tagavad lühema ja mõistetavama koodi. Sama lugu on ka teise ja kolmanda xslt-ga. Kõik töötavad nii nagu peavad ja vigu ei tundu olevat. Puudu on neid ainult üks koodi osa. Kood mis muudaks Xslt Xml-iks. Kuid kui seda ignoreerida siis nende tehtud töö on üpris hea.
Rakenduse retsensioon meeskonnalt Taandarendajad
Meeskond on loonud WPF klientrakenduse enda poolt arendatud veebiteenusele. Välimuselt on tegemist väga lihtsakoelise disainiga, mis täidab aga oma eesmärgi ja võimaldab rakendust kasutada. Mis aga tõsiselt kasutusmugavust häirib, on asjaolu, et iga erinev vaade esitatakse eraldi hüpikaknana ja see on probleem, mille lahendamisega võiks WPF rakendust arendades hakkama saada (kasutada võiks nt. tab-e või sisemisi vaateid). Teisalt on see pigem viimistluse valdkond ja kasutusfunktsionaalsus on rakenduses olemas ja lahendatud. Paroolide sisestamiseks oleks võinud kasutada spetsiaalseid elemente, mis ei kuva sisestatavat parooli ekraanile.
Rakendus ise tundub olevat mõne koha pealt „katki“. Esineb olukordi, kus mõned nupud ei tööta ega kuhugi vii, samas rakenduses ringi klõpsides hakkavad need nupud mingitel hetkedel tööle. Kõige problemaatilisem koht tundub olevat kasutajate registreerimine ja sisse logimine – registreerimine annab mingitel hetkedel veateadet millele järgneb login nupu mittetöötamine. Sisse logimine ei vii ka kuskile edasi ja sellest, et sisse logimine on õnnestunud, võib aimu saada vaid muutunud sisuga vaadetest. Üritus autosid lisada lõppeb edutult – rakendus jookseb kokku ja sulgub. Sarnaseid näiteid esineb veelgi. Võib öelda, et meeskond on küll esmase rakenduse loonud ja mingisuguse funktsionaalsuse tööle saanud, aga nii rakenduse välimus/toimimine ja sisemine loogika ning veahaldus on jäänud silumata ja vajab veel tõsist tööd.
Meeskond on kasutanud arendusmustreid – kasutatud on projektides nõutud uow ja repo mustreid, suure plussina on tegeletud ka BLL kihi loomise ja DTO-de kasutamisega, WPF rakendus kasutab ära MVVM mustrit. Pöördumiseks veebiteenuse poole on tehtud serviceclass-id, mis sellise mahuga ülesande puhul ka igati piisav programmikoodi struktureerimise tase (võrrelduna näiteks DAL projektiga, mis on oluliselt keerulisema ülesehitusega). Tänu sellele on ka vaadete kood äriloogikast puhas ja selgesti hallatav.
Rakenduse kood on suures plaanis suhteliselt korralikult vormistatud. Silma hakkasid aga kaks veidrat tava programmeerimise poole pealt. Esiteks täiesti üleliigne „this.“ kasutamine väga paljudes kohtades, kus seda absoluutselt vaja ei lähe. Teiseks mõned veidrad loogikakontrollid, kus if – else kasutamise asemel on tõesuskontroll lahendatud kahe järjestikuse if kontrolliga ja hüüumärgi kasutamisega (stiilis if(istrue) ….. if (!istrue)…. Selle asemel, et kasutada if(istrue)….else….)
Kokkuvõtvalt saab öelda, et tööd on tehtud ja veebiteenuse peale klientrakendus valmis arendatud. Samas esineb rakenduse töös palju vigu ja seda just rakenduse silumise ja viimistlemise poole pealt.
Meeskonna Vertigo retsensioon klientrakendusele
Klientrakendus on lahendatud WPF-kujul ning on loodud enda loodud veebiteenusele.. Kujundusele suurt rõhku pole pandud, kasutajamugavuse poole pealt on kujunduses tegeletud väljade paigutamisega. Rakenduse loomisel on kasutatud MVVM mustrit.
Äriloogika poole pealt, oleksime tahtnud, et meeskond oleks kirjeldanud, mis on erinevate rollide võimalused. Oleksime soovinud ka meeskonnapoolset sisulisemat analüüsi, miks on seda rakendust hea kasutada ja kuidas ta abistab kasutajate tööd. Oleksime tahtnud näha ka mõnes kohas koodi kommentaarimist. Küll aga kohtas koodis mitmeid koodijuppe, mis oli välja kommenteeritud ning poldud lisatud selgitusi, miks on need alles jäetud. Võib eeldada, et koodi silumise ja viimistlemise jaoks ei jäänud meeskonnal aega. Lisaks oleks olnud hea, kui oleks olnud lisatud mõningad näidisandmed.
Sisselogimine ja registreerimine peaksid sisuliselt töötama, kuid omavad mitmeid puudujääke. Näiteks kasutaja registreerimisel läksime “Account” ja “Register”, misjärel avaneb ilusti vorm “Register”. Olenemata sellest, kas infot sisestada lahtritesse, on võimalik vajutada “Register” nuppu ning järgmisena avaneb kasutaja ees vaade “AdminView”, kus ei kuvata midagi peale menüüriba. Kindlasti oleks pidanud siia infot looma, et kasutaja saaks aru, kuhu ta on sattunud, kas registreerimine õnnestus ning mida saab edasi teha. Kuigi, kui proovida registreerida ja see ei õnnestu, siis saab minna “Cars” ja “Manage Cars” ja sealt alt autosid lisada, mis muidu peaks olema koht, kuhu ei saa ligi, kui pole sisse logitud. Segadusse ajav on ka rakenduses toimiv siis, kui sisestada registreerimisel väljadesse infot, mis ei peaks sinna käima. Näiteks, kui üritada registreerida ning sisestada lahtritesse info, mis ei ole valiidne (nt pole @-märki e-maili rea peal), siis ütleb rakendus, et “Something went wrong”, aga ometi on järgmine vaade selline, kus saab sisse logida. Registreerimisvormil on parool näha, kui seda sisestada (sisestatu ei muudeta nt tärnideks, et oleks turvalisem), mistõttu iseenesest väga hea lähenemine - sisestad parooli ja siis siestad uuesti parooli, et kindel olla, et tead, mida sisestasid - kaotab oma mõtte, kuna mõlemal korral kasutaja näeb igat sümbolit, mis ta on sisestanud.
Ebaloogiline on lahendus, et rakenduse avamisel kuvatakse esimese lehena “Cars”, kuid menüüreal on näha “Menu” all alammenüüd “Home”, millele klõpsates ilmub vaade, mille põhjal võib järeldada, et sinna peaks tekkima ettevõtte nimi ning info selle kohta. Samas on “Cars” ise alles 4. valik alammenüüna. Kui meeskond otsustas, et “Home”-leheks, mis tavapäraselt on ka esimene leht ning see, kust kasutaja alustab enda toiminguid, on leht, mis kuvab infot ettevõtte kohta, siis oleks nad pidanud üleüldiselt rakenduses ka sellest lähtuma. Vastasel juhul oleks meie meelest olnud loogilisem, et praegune “Home”-leht sobiks enda sisu poolest hästi “About”-lehe alla ning “Cars” võiks olla olemuselt “Home”-leht, kuid mitte seda nime kanda.
Kasutajal on võimalik autosid sisestada ja need lisatakse andmebaasi ning kuvatakse ka "Cars" lehel.
Küll mitte oluliselt häiriv, kuid kasutajamugavuse koha pealt oleks olnud mõnusam, kui iga vaade ei oleks avanendu eraldi aknas, mis tähendas ka seda, et rakenduse aken liikus desktopil.
Tundub, et klientrakenduses pole kasutatud võimalust kuvada veebiteenuses nõutud funktsionaalsust - teenuse kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes. On näha, et rakenduse viimistlemisele ei jäänud palju aega. Klientrakenduses on mitmed kohad jäänud läbi mõtlemata. Kasutajale on selgusetu mitmes kohas, miks ta kuhugi tegevuste jadas satub ning, mida edasi teha. Lisaks, mõnel juhul rakenduses toodud nupud ei reageeri ning rakendust on võimalik suurt vaeva nägemata kokku jooksutada.
Kokkuvõttes, on näha töö tulemusel valminud klientrakendus omaloodud veebiteenuse peale, on nähtud omajagu vaeva. Selge on ka see, et rakendust saaks veel oma jagu lihvida ning kasutajaloogikat läbi mõelda.
