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.

Teenuse ja klientrakenduse retsensioon meeskonna "MRPD" poolt

Teenus: Lahendus on jaotatud erinevatesse projektidesse vastavalt aine käigus õpitule, mis annab selge ülevaate selle ülesehitusest ja võimaluse mooduleid tulevikus mujal lahendustes kasutusele võtta. Eraldatud on mudelid, andmekiht, repositooriumid, transpordimudelid, transpordiloogika ja teenus. Veebiteenuses on kasutusel 7 olemit, andmebaas on loodud “code first” põhimõttel kasutades ‘entity framework”-i. Repositooriumid on jaotatud eraldi failidesse, erimeetodeid üheski kasutatud ei ole. Transpordiloogika on piisaval määral kommenteeritud – üheselt mõistetavalt on aru saada, mida iga meetod teeb. Veebiteenus on loodud .NET 4.5 raamistikus, autentimine on implementeeritud, kuigi testimisel ei töötanud (võib-olla andmebaasi seadistamise viga). Andmed tagastatakse json kujul (korralikult joondatud). Veebiteenuse api lehekülg on osaliselt kommenteeritud, kuigi võiks olla põhjalikumalt, et teenuse kasutajatele oleks kasutamine lihtsam. Leida ei õnnestunud statistika osa, paistab, et see on jäänud versioon 2-e. Idee on ärilise poole pealt hea, Eesti turg jääb väikseks, aga suurema rahvaarvuga keskmise arenguga riigis annaks seda ehk kasumlikult turustada. Kood ise on korralikult joondatud ja enamjaolt kommenteeritud, kasutatud on kursuse käigus õpitud mustreid – see kõik teeb koodi lugemise ja ülesehituse lihtsaks ja arusaadavaks. Soovitaks pohjalikumalt API dokumentatsiooni kommenteerida.

Klientrakendus:

TÜC tegi klientrakendusi kaks Web.API ning WPF rakenduse, mis tundus veidi poolik ja vähem tähelepanu saanud, kui Web.Api, mille vaated teenuselt infot pärivad. Kirjeldades neid kahte erinevat klientrakendust, siis Web.Api puhul on võimalik nii sisselogitud kui ka mittelogitud kasutajaga lehelt infot pärida. Web.API projektis lisab kontoga kasutajale võimaluse ka ise kuulutusi lisada, kustutada ning muuta. WPF projekt on sarnane, kuid lisandväärtusena on kalender.

Kood on kirjutatud klientrakendustele järgides häid arendusmustreid ning ka arusaadavalt. Olulist rõhku on pandud ka vaadete - vaatemudelite kui ka controllerite eraldamisele ning nende loogika loomisele. Kood on kommenteeritud, et hõlbustada koodi arusaadavust ning meetodite tööpõhimõtet täpsustada.

Kontrollides päringuid, toimuvad need korrapäraselt ning üksi REST-päring ei ebaõnnestu.

Klientrakenduse kontrollerite loogika on lahendatud läbi ühe baaskontrolleri, millest infot päritakse. Enim funktsionaalsust kannab endas kuulutuse ( AdvertController ) kontroller, milles on actionid ning igaleühele neist on olemas ka vaade, mis on tugevalt tüübitud.

Põhifunktsionaalsus toimib ning võib öelda, et käesolev klientrakendus on loodud ning teostatud nõutud tasemel, olles eeskujulik nii koodi kui ka arendusmustri poolest.

Teenuse ja klientrakenduse retsensioon meeskonna "Kirves" poolt

Teenus:

Meeskond TÜC on loonud RESTFUL teenuse Web API 2.0 platvormile. Projektis on kasutatud erinevaid arendus mustreid, mis annab hea loetavuse ja struktuuri koodi poolelt.

Kasutatud on järgnevaid mustreid eraldi projektides:

• DAL – Data access layer
• Models – Code first lähenemisega loodud andmebaas
• Repositories – EF jaoks loodud tühjad konstruktorid
• Transport logic
• Transport models

DAL

Data access layeri alla on toodud ilusti kõik andmebaasi mudelid, olemas on DB name ning ära on siis kasutatud migratsioone. Migratsioone on küllaltki raske saada viisakalt tööle, seega on positiivne näha, et meeskond on sellega vaeva näinud.

Models

Projekti andmebaas on loodud code first lähenemisega, mis annab paindlikuse projekti arendamisele. Andmebaasi mudelites on loodud vajaminevad seosed. Kahjuks aga paraku jääb silma mõningad puudused. Tabeli olemitel on puudu stringi piirangud, ehk hetkel on kõik maksimaalsete väärtustega. Teiseks, mis jääb silma on topelt väärtustamine ForeignKey-le. Kui ma ei eksi kui tabelite vahel on korrektsed seosed siis selle väärtustamisega saab hakkama Entity Framework ise. Üldiselt aga on andmebaas korralik.

Repositories

Et projektis kaotada otsesed siduvused funktsionaalsete meetodiega on sisse toodud selline muster nagu repositories, mis võimaldab projekti edasi arengut teha paindlikumaks, et mitte kirjutada kõike oma projektist ümber vaid saab asju vahetada välja moodulitena. Väga positiivne lähenemine.

Transport logic

Transpordi loogika kihti on kirjutatud kogu funktsionaalsus, mida soovitakse saada andmebaasit ja edastada teenusena. Samuti ka selline lähenemine annab paindlikuse edasi arenguks. Mugav on ühest kohast muuta koodi või vahetada lihtsalt mingisugune loogika klass välja uuema vastu. Meeskond on väga edukalt selle kihi realiseerinud.

Transport models

Et transpordi loogika saaks toimida on vaja sellele kihile mudeleid. Antud hetkel on ilusti eraldi realiseeritud Class projekti transpordi mudelid, mida loogika kiht kasutab. Kasutatakse ka ära Factory loogikat. Eduakalt realiseeritud.

Web API 2.0

Meeskond kasutas oma teenuse loomiseks Web API 2 tehnoloogiat, mis on väga hea idee, kuna selle peale on selliseid teenuseid mugav luua. Teenus kasutab ilusti ära eelnevalt loodud kihte ja seda õiges järjekorras, ehk siis teenus töötab ilusti.

Teenusel on implementeeritud api endapoolne kasutajate autentimine. Teenus annab välja nõudmise peale tokeni, mida saab hiljem kasutada klientrakenduse poolel. Kontrollerid teenusel on ilusad ja puhtad. Puudub üleliigne sodi ja suurt loogika tööd neis ei tehta, mis on väga positiivne tava.

Teenuse infona antakse välja Jsoni, mis on väga hea, kuna seda on klientrakenduse poolel lihdne töödelda. Samuti võtab teenus vastu ka Jsoni. Kontrollerites on realiseeritud kõik põhi funktsioonid, Get, Post, Put ja delete. See annab paindliku lahenduse klientrakendustele. Üleüldiselt on meeskond TÜC teinud tublit tööd. Projektis olid olemas kõik vahekihid, mida me selle aineraames läbisime ning oli korralikult implementeeritud. Kogu funktsionaalsus teenuse poolt toimib ilusti ja seda on piisavalt. Edasine käik kuidas seda teenust kasutatakse ja mis mahus on juba klientrakenduse ülesanne ja kui mahukalt seda realiseeritakse.

Tooks ka välja, et kood on hästi kommenteeritud ning teenuse enda api dokumentatsiooni on veebis võimalik vaadata. Sealt leiab kiirelt, mis meetodid on olemas ning näha on ka koodi, mis neis kaustatud. See on suur boonus projekti läbiviimisel. Väga hea töö teenuse ehitusel. Tublid!

Klient:

Klientrakendusi on teostatud kaks, neist üks on teenusega samas projektis, teine teostatud eraldi WPF-rakendusena. Selles retsensioonis on keskendutud neist esimesele. Esmalt rääkides rakenduse disainist, peab tunnustama silmale üsna meeldiva kujunduse eest. See tundub baseeruvat juba Visual Studios olemasoleval template’i, kuid kõike ei peagi ise tegema ning valmislahendus võib kodukootud disainist tihti parem olla. Klientrakendust käivitades pakutakse avalehel võimalust vaadata olemasolevaid kuulutusi, sisse logida või registreeruda kasutajaks (trükiviga esilehe lingis :) Kõigepealt lähtungi kliendi retsenseerimisel pelgalt tavakasutajale kättesaadavast infost (black box testing).

Nii sisselogimise kui registreerumise lehel on kliendis kasutusel andmete valideerimine. Sama kehtib ka kuulutuste lisamise ja muutmise kohta. Paraku ei ole valideerimist näiteks selles osas, et sisestada ei saaks negatiivseid väärtuseid kohtade arvu või hinna lahtrisse. Juhul kui samale rakendusele lisada näiteks ka kohtade broneerimine ja maksmine, tuleks kasutada ka nende väärtuste täiendavat validatsiooni. On olemas ka töötav kuulutuste kustutamise funktsionaalsus (sisse loginud kasutajad saavad enda kuulutusi kustutada). Kui esimesel korral rakendust käivitada, võiks kohalikku baasi olla lisatud ka juba mingisugune asulate nimekiri. Hetkel ei ole näiteks võimalik kliendis lisada kohanimesid või aadresse. Valideerimisel on teatud puudujääke ka kuulutuste lisamisel. Näiteks lubatakse lisada kuulutust, kui valitud pole mitte ühtegi sihtkoha ega lähtepunkti nime, kuid selle kuulutuse muutmisel tuleb vastuseks stacktrace kuna sel hetkel kontrollitakse kuskil, et source- ja destinationID=null. Samuti kuvatakse taoliselt puuduva lähte-ja sihtkohaga lisatud kuulutusi valesti, puuduvad väljad jäetakse vahele ning neile järgnevad andmed nihutatakse ülespoole, andmeväljade nimetused ise vasakul pool jäävad aga paika, nii õnnestus kuvada kuulutus kujul “To 1.01.2015 0:00:00; Available seats 20”. Samuti on võimalik lisada kuulutust, millel on lähte-ja sihtkoht samad (seda muideks süsteem ka vaikimisi pakub). Samuti võiks hinnal olla märgitud ühikud. Positiivsena võiks märkida veel et kliendi kaudu on võimalik vaadata veebiteenuse (automaatselt genereeritud) dokumentatsiooni koos json formaadis päringute näidetega.

Kui vaadata loodud klienti koodi poole pealt, on kasutatud MVC5 raamistikku ning scaffoldingi, et tekitada vaated poolautomaatselt. Vaatekontrollerites on kasutatud HttpClienti’t ning asünkroonseid meetodeid, et suhelda eelnevalt loodud veebiteenusega. Samuti on kliendi poolel realiseeritud autentimiseks vajalik baasklass, mille vaatekontrollerid pärivad. Ehkki klient on realiseeritud samas projektis veebiteenusega, on kummalgi täiesti iseseisev koodibaas. Ka kliendi jaoks on eraldi realiseeritud vaatemudelid ning on kasutatud ka annotatsioone andmete paremaks kuvamiseks (näiteks Display(Name = "Label")). Nagu teenuse retsensioonis mainitud, toimub autentimine standardselt token’ i ning cookie baasil. Kliendi poole peal oleks kood võinud olla veidi paremini kommenteeritud, kuid ka siin ei ole erilist põhjust nurisemiseks.

Üldkokkuvõttes on meeskond teinud tublit tööd ning realiseerinud MVC5 raamistikul baseeruva ja töötava klientrakenduse, mis kasutab veebiteenusega suhtlemiseks ära autentimist. Rakendust saaks tunduvalt edasi arendada (selleks vajalikud endpoint’id on olemas ka veebiteenuses), esinevad puudused ei ole tõsised, nende kõrvaldamisel ja funktsionaalsuste lisamisel võiks tegu olla reaalselt kasutusel oleva teenusega.