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.