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.

Meeskonna Error405 retsensioon meeskonna KRTT veebiteenusele

Meeskond kelle valisin retsenseerimiseks on KRTT või siis nüüd KTT. Retsensioon on tehtud selle meeskonna veebiteenusele Veebiteenus. Veebiteenuse otsustas meeskond kasutada ASP.NET WEB API’t. Esmapilgul tundub, et nad on selle korralikult teinud. Projekti on nad kenasti jaganud ära mitmetesse kihtidesse. Olemeid on neil piisavalt. Nõutud oli 6 aga nad on lisanud neid lausa 10 ja lisaks ka kasutajate olemid on nad siina Olemeid lähemalt uuride näen, et nad on kasutanud vähe annotatsioone. Mõnes olemis rohkem mõnes vähem ja mõnes ei ole nad neid üldse kasutanud. Selle kohapealt miinus, kuna andmebaasi efektiivseks kasutamiseks on see oluline ning nende ära jätmine võib saada kurjalt ärakasutatud nende käest kes oskavad sellele tähelepanu pöörata ehk häkkerid. Näiteks olemis „firma“ saab seal lisada lõpmata pikka firma nime mis võib omakorda andmebaasi neil kokku jooksutada. Nad on oma veebiteenuse teinud kasutades RESTful tehnoloogiat ja mitte SOAP'i. Veebiteenus neil töötab ja annab välja JSON objekte. Kuna katsetamisel oli andmebaas tühi andis ta siiski välja tühja JSON objekti. DAL kihis on kasutusele võetud repositooriumid, interface’id, ja helpersid mis väga hea. Sellega on nad teinud oma projekti paindlikumaks ja AB’st sõltumatuks. DomainBLL kihis on nad kasutanud data transfer objekte. Märkasin, et neil dto’des on kasutusel need objektid mida nende web api välja annab ja lisaks ka need, milliseid objekte see web api vastu võtab, kui ma olen nende objektide kirjeldusest õigesti aru saanud. Ausalt öeldes ei saa ma aru kas see on vajalik. Kui nad on teinud get ja post siis miks mitte sinna lisada put ja delete. See oli koht mis jäi natuke mulle arusaamatuks. Äriloogika kihis on neil välja toodu ka loogika milles nad on ära kasutanud unit of work’i. See on hea, kuna annab jällegi projektile ehk teenusele rohkem paindlikkust juurde. WebAPI controllerid on enamvähem korras. Kasutatud on Ninjecti mis on hea. Tundub, et nad ei ole Status koodidega midagi ette võtnud. Kõik tunduvad olevat generic’ud, ehk sellised millised nad uue controlleri tegemisel. See on halb kuna vigade juhtumisel on debuggimist raske teostada. Controllerites on näha vähemalt rohkem kommenteerimist. See on hea, aga ikkagi kuidagi Controllerites on ka kenasti ära kirjeldatud CRUD operatsioonid. Üks suur miinus oleks ka see kommenteerimise asi. Kui mina arendajana saaksin kätte sellise koodi kus kommentaare on vähe siis läheb ikka natuke aega, et aru saada kuidas see teenus täpsemalt toimib. Terves projektis oleks tahtnud, et koodi oleks rohkem kommenteeritud. Pannes teenus käima ja minnes sinna avalehele ja sealt edasi Help lehele siis on välja toodud kenasti need entiteid ja nende käsud mida nendega teha saab. Kuigi neid on vähem kui nende olemeid andmebaasis siis jääb mulje, et nad on nagu midagi sealt välja jäänud, aga mina seda ei tea kas see oli neil niimoodi meelega või nad lihtsalt unustasid. Võttes kasutusele abi tööriista fiddler, et nende teenust katsetada siis peab tõdema, et see neil töötab. Mina oma katsetustes sain edukalt seal andmeid sisestada ja muuta ja kustutada. Meeskond on teinud ära suure töö, et kogu see teenus käima saada. Andmebaas on neil ikka väga suur arvestades teiste meeskondade omadega. Minu silmis on neil edukalt töötav teenus ja kohad mis minus tekitasid mure kohti ongi alustuseks kommenteerimine ja dokumenteerimine. Kuna meeskonna liikmed sooviksid kindlasti tulevikus edukateks arendajateks saada siis tuleks juba varakult hakata harjutama seda kuidas koodi korralikult ja põhjalikult kommenteerida. Nii mahuka töö ülevaatamine võtab ikka parasjagu aega ja arvatavasti jäid väiksemad vead mul kahesilma vahele. Kenasti on ära kasutatud neile õpetatud teadmisi ja projekt on edukalt lõpuni viidud. Minu arvamuse kohaselt väärib see projekt kuskil 85 - 95% max tulemusest. Natuke tuunimist ja rohkem tähelepanemis nende poolt ja oleks 100% ära.