Talk:TÜC2

XML failide retsensioon meeskonna "Kipsplaat" poolt

Meeskonna TÜC2 poolt tehtud failid on jalgrattapoest. Kõik nõuded (XML fail, XSD fail, 2 XSLT faili) ja nende reeglid on täidetud.

XML andmefail on hästi loetav, meeskond võtnud kasutasele ka <![CDATA[]]> tagi õigetes kohtades, aga esinevad väikesed puudused.

Spetsifikatsioonid oleks mõistlikum lisada <spetsifikatsioonid> tagi sisse. Samuti XML peaks olema natuke universaalsem. Näiteks kui me tahame lisada uut spetsifikatsiooni, näiteks esihark või rehvid, siis meil tekib konflikt XML faili skeemiga. Kui me tahame võib-olla tulevikus hakata müüma ka jalgratta hooldusvahendeid või muud sellist, siis meil on vaja muuta kogu XML faili ja ka skeemifaili ning hiljem peab redigeerima ka transformatsiooni failid, sest teisel juhul võib kõik katki minna.

XSD (XML skeemifail) on korrektne.

XSLT (transformatsioonid) failidega on kõik hästi ja nad teevad seda mis nad ikka peavad tegema.

Kokkuvõteks, tegemist on hea tööga vaatamata väikesele puudusele. Kommentaariumide ning dokumentatsiooni puudumine sel juhul ei ole kritiiline, sest tegemist on väikese tööga ja kood on loetav ning arusaadav ilma ülalmainitute abivahenditeta.

XML failide retsensioon meeskonna "Kirves" poolt

Meeskond TÜC on oma töö aluseks võtnud jalgrattapoe. Loodud on .xml fail andmetega, skeemifail ning kaks .xsl faili, mis mõlemad loovad .xml failist .html faili. Xml fail sisaldab nelja loogilist dimensiooni, kuid hetkel pole täidetud nõue, et kolmel dimensioonil oleks atribuut, mis on enamat kui ID. Xml fail on arusaadav ja loetav, valideerub skeemifaili vastu ning kasutatud on ka CDATA välju. Meeskond on viitsinud otsida ka pildid ning tootjate veebilehed, et jalgrataste hinnakirja elavamaks muuta.

Kood on ilusti trepitud, kuid dimensioonide vahel võiks kasutada tühje ridu, et näha, kus üks algab ja teine lõpeb. See muudaks koodistruktuuri paremini loetavaks.

Skeemifailis on mõeldud ka andmetüüpide peale, näiteks on käikude arvuks kasutatud tüüpi unsignedByte. Muus osas on skeemifail mõistagi automaatselt genereeritud.

Transformatsioonidest üks on lihtsama teostusega ning teine tunduvalt keerulisem. Lisaks tavapärasele elementide ja atribuutide väärtuste kuvamisele on kasutatud ka for-each tsükleid ja vahemuutujaid.

Üldiselt võib öelda, et meeskond on oma töö läbi mõelnud ning mõnest väiksest puudusest hoolimata on aru saada, et on viitsitud vaeva näha. XML fail, skeemifail ja transformatsioonifailid on loogilise ülesehitusega. Soovituseks võiks tuua, et nii .xml-i kui muud koodi kirjutates võiks kasutada inglise keelt, mis jätab koodi poolt terviklikuma mulje, kuna funktsioonid ja muud parameetrid on juba nagunii inglise keeles.

XML failide retsensioon meeskonna "MeilEiOleGrupinime" poolt

Koostatud XML kujutab endast jalgrataste andmebaasi, kus on kõik mida näiteks kodulehel kuivamiseks vaja. Töö vastab nõuetele, dimensioone on täpselt neli. Atribuute on kasutatud, kuid vähe. CDATA-t on kasutatud (on vaieldav kas oleks võinud seda teha rohkemates kohtades).

Meeldiv oli näha, et on kasutatud kategooriaid (tag „Kategooria“ kus sees olid erinevad jalgrataste liigid). Seda kasutatakse XSLT juures, kus otsitakse ja sorteeritakse kategooriate järgi. Tegelikult oleks sama võinud teha ka värvustega.
Eespool sai mainutud, et atribuute on vähe kasutatud. Ühe oleks saanud pildi lingiga, kuna seda on vaid üks. Võimalik, et ka tootja oleks saanud panna atribuudiks. Seda seepärast, et ühe ühe jalgratta puhul oli see puudu ning seepärast võiks see ka olla valikuline atribuut. Samuti oleks võinud panna atribuudina mudeli nime ning seisukord tag asendada booleaniga „onUus“.

XSD failis vigu ei märka. Kõik on paistab olema korralik ning andmetüüpe on kasutatud mõistlikult.

Nõutud oli kaks XSLT faili ning need on ka olemas. Esimeses tuuakse välja kõik jalgrattad koos mudeli nimega ja kirjeldusega. Kaasa on pandud ka pilt. Teises oli kasutatud kategooriaid. Kõik kategooriad ja kui mõni jalgratas on selle kategooriaga siis on seal all tema link. Kui lingile vajutada siis minnakse selle täpsema informatsiooni juurde. Võib öelda, et XSLT-d on väga hästi tehtud.

Hoolimata mõnest väikesmast veast on tehtud töö korralik.
Meeskond "MeilEiOleGrupinime"

Teenuse ja klientrakenduse retsensioon meeskonna "Vargamäe" poolt

Meeskond TÜC on loonud veebiteenuse ja klientrakendused süsteemile, mis kannab nime Kyyt. Süsteemi eesmärk on lasta autoga Eestis reisivatel inimestel postitada kuulutusi, otsimaks auto peale kaassõitjaid, kellega kulutusi jagada. Ühele sõidukuulutusele on võimalik märkida, kust kuhu sõidetakse, millal ajal seda tehakse, kui palju on autos vabu kohti ning mis on ühe koha hinnaks. Samal ajal kui ühes otsivad kaassõitjaid, on süsteemil ka teine oluline kasutajaskond: inimesed, kes otsivad küüti.

Teenus

Süsteemi Kyyt Web API tehnoloogiat kasutades loodud teenus vastab kõigile projektikirjelduses teenusele esitatud nõudmistele.

Esimese asjana meeskonna TÜC solution’it avades, hakkab silma hästi struktureeritud kihiline arhitektuur. Nimelt on järgitud koolis õpetatud häid tavasid hoida eraldi projektides äriloogika mudeleid, andmebaasikihti (DAL), repositooriume, transpordiloogikat ja transpordimudeleid.

Kood üldiselt on kirjutatud loetavalt ja hästi struktureeritult (treppides). Kommentaare on retsenseerijate arvates kirjutatud piisavalt ja vajalikud meetodid on ka dokumenteeritud. Eriti tõstaks esile eeskujulikult kommenteeritud äriloogika mudelid, mida on lihtne lugeda ja mõista.

Sügavamalt transpordimudeleid uurides, võib näha, et tehtud on eraldi mudeleid erinevat liiki andmete liigutamise jaoks, mis on kindlasti mõistlik lahendus. Näiteks kuulutse objekti kohta on olemas kolm andmete liigutamiseks mõeldud klassi (DTO’d), üks detailse kuulutuse saatmiseks teenusest välja, üks saatmiseks tervet hulka (listi) kuulutusi teenusest välja ja veel üks võtmaks vastu kliendi poolt teenusele saadetavat kuulutust. Selline lähenemine on hea, kuna optimeerib pidevalt üle võrgu saadetavat andmehulka, pannes kaasa iga operatsiooni juures ainult neid andmeid, mida võiks vaja minna.

Teenuse kontrollereid lähemalt vaadates, selgub, et iga kontrolleri juures on realiseeritud küll kõik CRUD operatsioonid ja ka erinevaid süsteemi funktsioneerimiseks vajalikke kohandatud operatsioone, kuid ükski neist ei tagasta kunagi mingit teavet kliendile operatsiooni õnnestumise või luhtumise kohta. Nii on võimalik teenust probleemideta kasutada eeldusel, et kõik teenuse pihta tehtavad päringud on korrektsed ja mingeid vigu esineda ei tohi. See asjaolu teeb teenusele kliendi kirjutamise oluliselt keerulisemaks, kuna mitmesuguseid erandeid, mis operatsioonide käigus võivad juhtuda, ei tagastata päringu teele saatnud kliendile. See tähendab, et kui näiteks mõne objekti uuendamisel juhtub viga (näiteks seda objekti ei leita andmebaasist), siis kontrolleri meetod tagastustüübiga void ei teavita päringu teele pannud klienti ebaõnnestumisest ja kliendi arendaja peab leidma mingi viisi, kuidas kontrollida, kas plaanitud objekti uuendamine päriselt ka läbi läks. Selleks, et hõlbustada teenust kasutava kliendi kirjutamist, tuleks kontrolleri meetodid kirjutada selliselt, et need tagastaks ka veateateid ja ka teateid õnnestumiste kohta HttpResult vormis. Nii on kliendi poolt võimalik kontrollida teenuselt tagastatud vastust ja selle põhjal teha järeldusi, kuidas programmi tööd jätkata.

Klient

TÜC tiimi wikilehel oli küll kirjas, et teenusele on tehtud 2 klienti, WPF ja Web API vaated, kuid retsensiooni kirjutamise ajal tundus WPF projekti seis olevat poolik (või täpsemini alles alustamisel), seega järgnev tekst on kirjutatud Web API vaadete (MVC) kohta.

Kliendi kood on kirjutatud loetavalt – vaated, vaatemudelid ja kontrollerid on arusaadavad. Küll aga ei ole kliendi poolt kommenteeritud päris niisama hästi kui seda oli tehtud teenuse puhul, aga retsenseerijaid see ei häiri.

Kõik klientrakenduse kontrollerid pärinevad ühest baaskontrollerist, kuhu on kirjutatud sisuliselt baasteenus, mille meetodeid kasutades tehakse päringuid veebiteenuse pihta. Kontrolleritega samas kaustas on veel ka klass nimega Constants, milles hoitakse konstantsete muutujatena erinevate teenuste aadresse. Nende kasulikkus jääb pisut arusaamatuks, kuna eraldi muutujasse on salvestatud baasaadress ning erinevate teenuste aadressid nii, et teenuste aadressid on kõik ka üks haaval ise pikalt välja kirjutatud ja ei sõltu baasaadressist, seega kui baasaadress peaks muutuma, tuleb lisaks sellele vastava konstandi väärtuse muutmisele muuta veel ka iga teenuse jaoks eraldi olevat aadressi. Erinevate teenuste aadressid võiksid olla vabalt lühemad ja nende kasutamisel mõnes muus failis võiks täis-pika aadressi saamiseks neid lihtsalt „kleepida“ baasaadressile otsa, nii oleks koodi hallatavuse mõttes kasulikum. Samas on konstantide klassi salvestatud ka üks aadress kuulutuste kohta käiva teenuse jaoks, mida kusagil rakenduses ei kasutata. Hoolimata sellest, et aadressid on eraldi salvestatud teise faili, on rakenduse kõige põhilisema kontrolleri (AdvertController) konstruktorisse kirjutatud teenuse aadress ilma konstanti kasutamata. Klient küll toimib nii, nagu ta hetkel on, aga konstantide kasutamine võiks olla efektiivsem.

Nagu juba varasemalt mainitud, toimub klientrakenduse põhilise funktsionaalsuse juhtimine kuulutuse kontrolleris (AdvertController), kus igale action’ile on olemas vastav vaade ja kõik vaated on tugevalt tüübitud, st põhinevad vaatemudelitel. Klient tuleb hästi toime andmete küsimisega teenuselt ja ka nende posti päringute abil teenusele saatmisega. Sõidukuulutus märgitakse automaatselt vanaks, kui hetkeaeg on möödas kuulutusele kirjutatud väljasõiduajast. Küll aga jääb küsitavaks kommenteerimise osa – nimelt ei õnnestunud leida kliendilt kohta, kust saaks kuulutuse alla kommentaare jätta. Manuaalselt andmebaasi kommentaaride tabelisse ridu lisades, võis näha, et kuulutuse all kommentaaride kuvamine töötab, aga klienti kasutades neid lisada ei õnnestunud.