Talk:Meeskond "Unusual Suspects"

Töö vastavus esitatud tingimustele:

1) Ülesande täitmiseks tuleb luua XML fail andmete edastamiseks - olemas!

2) selle XML faili skeemifail - tehtud!

3)2-3 sobivat XSL faili loodud XML failis olevate andmete transformeerimiseks HTML formaati ja XML faili formaadi muutmiseks. Nagu näha githubist, töö käigus loodi mitu XSL faili – lihtne, combo-boxidega ja tabelikujuline.

4)XML andmefaili sisu on vabalt valitav, kuid andmed peavad olema üksteisega loogiliselt seotud ja struktuur otstarbekas. Andmed on loogiliselt seotud, kuid esialgu tundub, et sugugi kõiki andmeid ei ole veel kasutatud. XMLi lõpu poole algab Peatuste blokk, kus korduvad üleval kord juba toodud peatuste nimed, kuid nüüd sisalduvad alamelementides mingit sorti koordinaadid. Võib-olla saaks siin struktuuri kuidagi ühtlustada, nii et andmed oleksid kõik korraga peatuste juures juba liinide all.

5)XML-il peab olema vähemalt 4 loogilist dimensiooni. On, suutsin loendada vähemalt viienda dimensioonini. Lisaks tuleb kasutada 3-el dimensioonil attribuute, mis on enamat, kui lihtsalt ID. Vähemalt kahel elemendil leidub muid atribuute kui ID (aktiivne, alates, kuni). Küllap saaksid nad vajadusel ka kolmanda tekitada.

6) Programmikoodi loetavus ning kommenteeritus, programmikood on loetav. Koodi lihtsuse tõttu ei ole nähtavasti kommenteerida olnud vaja. dokumentatsioon – loen dokumentatsiooniks Wiki ja ghithubi, sellises arendusstaadiumis on see piisav. Kirjeldada puudusi - kuna olen lugenud ka teiste arvustusi, siis midagi suurt sisulist esialgu välja ei ole tuua.

Unusual suspects teenuse retsensioon

Projekti käivitamine peale allalaadimist ja laialipakkimist sujus tõrgeteta. Esmapilgul võttis natuke aega, et aru saada mis on mis. Unusual Suspects nimeline solution sisaldas peamiselt xml faile. Reget proovis aru saada, kas veebiteenus on tehtud ühe- või mitmeosalisena ja millisest kohast millised asjad kasutusse võetakse. Projekt on lihtne ja ökonoomne, mis sellise pisikese teenuse puhul ongi mõistlik, ära on kasutatud esimese tööna tehtud XML failid. Teenus on tehtud ühe solutioniga, näitab Edela-Raudtee sõiduplaani. Õppejõud soovitas back-endi ja front-endi eraldada, aga siin projektis on need kokku pandud. Meil näiteks oli turvaline kasutajahaldus eraldi hostis. Nõuti (boldis!) teenuse kasutajate tuvastaminst ja haldamist. Leidsime isegi ASP.NET/SQL andmebaasi, mis tähendab, et kasutajahalduse saaks vajadusel realiseerida. Päevikust lugesime, et Mari ja Anu olid püüdnud kasutajatehaldust luua, leidsime isegi ASP.NET/SQL andmebaasi, kuid teenus ja klient seda praegu ei kasuta. Kuna kasutajatehaldust ei toimu, siis on täitmata ka kasutusstatistika realisatsiooni nõue. Kaitsmisel kuulsime, et sellise teenuse puhul oleks kasutajate haldus mõttetu, millega oleme nõus, teisalt on aga koolitöö nõue täitmata. Teenuse kohta on kirjutatud viis eraldi klassi. Info jaamade ja liinide kohta on teenuses realiseeritud klassidena. Jaama kohta kaks klassi: Station, mis hoiab endas jaama identifikaatorit ja nime; teine on StationSchedule nimeline klass, mis oskab konkreetsele jaamale lisada lahkumisajad (vist). Liini hoiab klass Line, mis sisaldab identifikaatorit ja nime. LinewithSchedule klass oskab endale AddStop meetodi abil lisada jaamad ja peatusajad (eeldatavasti).

Teenus pakub nelja meetodit, mis on kommenteeritud ühe reaga. Näha on, et kood on kirjutaud oskaja programmeerija poolt, sest dokumenteeritus kommentaaride näol on väga napp. Jah, kood peaks end ise seletama, aga praegu seletab ta end peamiselt teistele samasugustele oskajatele. Algaja Anneli on koodi vaadates üpris kurb. Kõikide meetodite juures kasutatakse Xpath tehnoloogiat. Uuemal ajal on kombeks küll kasutada LINQt, kuid saame aru, et vana ja läbiproovitud tehnoloogia on tegijatele rohkem sobinud. GetLines() meetod tagastab XML faili kasutades liinid. Kenasti on hakkama saadud sellega, et XML fail leitakse projektis üles hoolimata sellest, kuskohas see projekt arvutis asub (kasutades AppDomain-i). Meetodis on näha, et osatakse ka natuke keerulisemaid Xpath päringuid koostada ja muutujatega kokku panna. Kohtasime if lause lühikuju (Reget ütleb, et see on ternaarne test nimeline operaator(Lorents, mäletate?)) createLine meetodis. Teistes meetodites me miskit erku ei leidnud, sarnanesid eelnevatele. Tunneme puudust veatöötlusest. Tavaliselt 1/3 koodist peaks olema try...catch... laused jms. veatöötlus! Kiidame veel muutujate nimede camelCase vormist kinnipidamist ning ühtlaselt inglisekeelseid muutujanimesid, mida ei oldud ära segatud eestikeelsetega. Dokumentatsioonina käsitleme veel päevikut ja readme faili, mis info üliküllusega just kumbi ei uhkelda. Samas päevik veenab, et töö on projektimeeskonna liikmete vahel olnud jaotatud. Peamiste puudustena toome välja eelpool toodud mittevastavuse õppeprojekti nõuetele – puudub kasutajahaldus ning kasutajastatistika. Anneli hindab kommenteerituse napiks, Reget jällegi enda jaoks piisavaks. Kuna ettenähtud koolitöö nõuetest on kaks punkti realiseerimata, siis jääb ka retsensioon vastavalt lühemaks, õigemini saab ühendatud kliendi retsensiooniga!

Unusual Suscpects kliendi retsensioon

Klientrakendus oli teostatud Windows vormirakendusena. Vorm koosneb kahest komboboxist, kahest nupust ja ühest ListBoxist ja on askeetliku välimusega. Hea on vaadata, et vormi kontrollid on ilusasti ümbernimetatud, mitte pole jäetud esialgsed, mida VisualStudio ise välja pakub ning mida on hiljem raske koodist üles leida. Lugesime päevikut ja teame, et kliendi valmistas Anu. Seetõttu oli lust vaadata, kuidas korralik dokumentatsioon näkku hüppas. Veebiteenusega võetakse ühendust kohe vormi käivitamise algfaasis FormLoad meetodis. Teenuse käest küsitakse jaamade nimed GetStation nimede abil, mis pannakse listi, sorteeritakse ja seejärel pannakse nad ühte komboboxidest, kusjuures esimesena väljastatakse peatus nimega „Tallinn.“

Kui põhidokumentatsioon oli eestikeelne, siis koodivahesed kommentaarid on inglise keeles. Kena lahendus oli see, et kui lähtekoha kastis oli mingi jaam valitud, siis sihtkoha kastidest me seda enam ei leidnud. Ehk välditi silmust  Leidsime lahenduse, et kui lähtejaamade hulgast uus valida, siis koristati tühjaks ka sihtjaama kombo. Ei tea, kas see ikka on hea? Samas saame aru, et see on seotud silmuse vältimise meetodiga. Reget leidis, et saanuks optimeerida. Selle asemel, et listist ühekaupa RemoveAt meetodiga jaamanimesid eemaldada, võinuks kasutada Clear meetodit, mis töötab ilma tsüklita. Hiljem leidsime, et seda oli searchButton_Click meetodis osatud kasutada. Viimati mainitud meetod pöördub jällegi veebiteenuse poole. Esmalt kontrollitakse, et et lähte ja sihtjaamade nimed oleks välja valitud. Teenuse poole pöördumisel otsitakse jaama nime järgi jaama Id-d. Kui need on käes ja need pole tühjad tehakse teenusele uuesti kaks päringut, kus jaama indeksi järgi tagastab teenus saabumis-väljumisajad järgmise 24 tunni kohta nendes jaamades.

Väljumis- ja saabumisajad pannakse resultsListBox nimelisse kasti. Millegipärast väljastatakse maksimaalselt ainult kaks tulemust, kuigi näiteks Tallinna ja Tartu vahel peaks ikkagi rohkem ronge käima? Kuna soiduplaan.xml sisaldab vaid nelja liini andmeid aitaks siin liinide lisamine xml faili. Meetod vaatab hetke kellaaega ning võrdleb seda sõiduplaanide aegadega. Varasemate kellaaegade ohta lisatakse sõna „homme.“ returnButton_Click realiseerib „Otsi vastupidist suunda“ nupu vajutust. Siis on listi täitmise loogika analoogne eelnevale, lisaks lisab arusaamatuste vältimiseks testilipiku väljastatud väljumis- ja saabumisaegade kohta. Veebiteenuse poole pöördumisel kasutatakse usingut, mis on selleks hea, et paneb automaatselt teenuseühenduse peale tarvitamist kinni. Kiidame veel muutujate nimede camelCase vormist kinnipidamist ning ühtlaselt inglisekeelseid muutujanimesid, mida poldud ära segatud maavillastega. Tunneme puudust veatöötlusest. Tavaliselt 1/3 koodist peaks olema try...catch... jms. veatöötluslaused!