Talk:TrainSmart

From ICO wiki
Revision as of 00:09, 16 June 2015 by Ttallerm (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Veebiteenuse ja klientrakenduse retsensioon meeskonna VariableMoods poolt

Klientrakenduse retsensioon

Meeskond TrainSmart on õppeaine, Võrgurakendused II: hajussüsteemide ehitamine, raames loonud klientrakenduse projekti, kasutades Microsoft Windows Presentation Foundation (WPF) tehnoloogiat ja Model View ViewModel (MVVM) arendusmustrit. Klientrakenduse puhul on tegemist lihtsa ja üldiselt selge programmiga, millel on aga mõningased järgnevad puudused:

Antud klientrakenduse kasutajaliides vajab kindlasti ülevaatus ja täiendamist. On vaja kindlat ja selget arhitektuuri navigeerimiseks kui ka andmete sisestamiseks ja kuvamiseks. Hetkel tundub asi tehtud olevat nii kuis juhtus. Erinevad nupud on aegajalt kas teksti kujuliselt, nupu kujuliselt või sootuks üldse arusaamatul moel puudu. Mitmeski kohas ei ole võimalik peale andmete vaatamise või sisestamise enam edasi ega tagasi navigeerida - ainuke võimalus on vajutada nuppu/teksti "SignOut", mis kenasti ilutseb paremas ülanurgas. Puudu on ka erinevate veaolukordade haldus. Kui pole eelnevalt lisatud treeningutesse ühtegi treeningut / harjutust ja seejärel vajutada nupu "start workout", siis ei kuvata kasutajale mitte ühtegi veateadet. Kahjuks ei paista olevat realiseeritud ka harjutuste lisamine treeningutele. Olemas on küll kaks dropboxi, kuid info nendes väljades parasjagu puudub. Järjekordselt ei anta veateadet. Mis on my exercise vaate mõte, kui seal loodud exercised ei ole kasutatavad workout vaates? Üldiselt tundub, et enamus Must Have nõudeid, mis on Viki lehele kirja pandud on tehtud või enam-vähem tehtud. Ära on ka märgitud, et peaks olema turvaline logimine. Sellist asja ei tundu hetkel veel eksisteerivat ei klientrakenduse poole pealt ega ka veebiteenuse poole pealt. Ehk on veel pooleli või täiendamata? Projektis ringi liikudes on näha, et olemas on ka administratsiooni vaade, kuid testimise käigus jäi see hetkel testimata. Sest otsest juhendit või võimalust, kuidas see programmitöös käima saada - puudus. Klientrakenduse projekti poole pealt on kõik erinevad kihid kenasti ära kategoriseeritud ja jaotatud vastavatesse kaustadesse. Samuti antud klientrakendus vastab üldjoontes MVVM arendusmustri headele tavadale (on olemas vastavad vaated, mudelit ja vaatemudelid). Lisaks võiks kood olla ka mõne keerulisema koha pealt paremini kommenteeritud ning lisaks võiksid veebiteenuse aadressid olla kusagil vastavates kindlates organiseeritud konfiguratsioonifailides, kus oleks tulevikus või muutuste korral hõlbus asju muuta. Üldiselt on tegemist töötava klientrakendusega, kus esineb eelnevalt kirjeldatud puudujääke, kuid erinevaid tegevusi nagu kasutaja sisselogimine, Workoutide ja päeviku vaatamine ning osade andmete sisestamine täitsa töötab. Seega on meeskonnal mingisugune ettekujutus ja arusaam klientrakenduse arendusest WPF tehnoloogia baasil olemas.

Veebiteenuse retsensioon

Meeskond TrainSmart on õppeaine, Võrgurakendused II: hajussüsteemide ehitamine, raames loonud veebiteenuse projekti, kasutades Microsoft ASP.NET Web API 2 tehnoloogiat ja MVC arendusmustrit. Veebiteenuse puhul on tegemist lihtsa koelise veebiteenusega, mis lubab erinevatel klientrakendustel vastavaid andmeid lisad, muuta ja kustutada andmebaasist. Antud juhul siis erinevaid treeningutega seotud andmeid.

Siin kohal tahaks ära mainida ka mõningased puudused seoses veebiteenuse ülesehitusega.

Projektis on koodi poole pealt arenduses lähtutud Code-First tehnoloogiast, kasutades ära Entity Frameworki võimalusi. Tegemist on kindlasti hea ja kiire lahendusega selliste väikeste projektide loomiseks, samuti aitab see paremini mõista erinevate olemite vahelist suhtlust ning vajadusel saab kiiresti sisse viia ka vajalike muudatusi. Projektis on küll olemid defineeritud, kuid puudu on EntityTypeConfiguration ehk andmebaasi väljade konfiguratsioon (atribuudid). Ei ole ära defineeritud sõnede pikkuseid, kas mõni väli on vajalik või mitte jmt. Hea tava on ikkagist paika panna mingisugused maksimaalsed väljade pikkused (sõnede puhul), et ei kasutataks andmebaasis ära maksimaalset võimaliku andmemahtu. Samuti erinevate mudelite puhul torkas silmas (peaaegu peast välja) asjaolu, et osadel mudelitel on ära defineeritud navigatsiooni väli primaarvõtme puhul kui virtual. Näiteks osad mudelid, mis on seotud just kasutajaga ning seal leidub väli "private virtual int UserId { get; set; }". Samuti on puudujääke kogu nende mudelite ehituste juures, kus näiteks Exercise mudeli klassil puudub navigatsiooni viide ExerciseInWorkout mudelile, kuigi vastupidi on navigatsiooni väli kenasti olemas. Lisaks on ka mitmetes mudelite konstruktorites millegipärast väljakutsutud ka ICollectionite väärtustamine. Milleks küll? Visual Studio IDE annab ise juba automaatselt sellekoha peal veateate, et virtual väljade puhul suudab selle maagia Entity Framework ise ära teha. Veel tekitab küsimusi User mudel, kus võib leida peale primaarvõtme (INT) veel ka teise nö. primaarvõtme või mingi välja, kus väärtustatakse väljale unikaalne väärtus GUID abil - miks?. Kindlasti tuleks tähelepanu pöörata ka ajavööndile (või siis täpselt culture teemale). Rakenduse konfiguratsioonis saab vastavalt vajadusele ära määrata, mis kultuuris rakendus töötab ja vastavalt probleemile, et kui luuakse Workout pannakse workouti loomisel vale kellaaeg, tuleks ka see kenasti ära konfigureerida ning korda seada. Lisaks arvutatakse ka workouti ajaline kestvus (lõpetamise korral) valesti välja. Konkreetset arvutamise loogiat välja ei otsinud, kuid siinkohal on samuti kusagil kohas viga sees. Tasub üle vaadata!

Sellegipoolest on veebiteenusel kenasti vastavad nõuded täidetud. Andmebaasi mudeleid on piisavalt, mis üldiselt tunduvad ka ime korral toimivat. Andmebaasi contexti failid, leiab ka konfiguratsiooni rea, kus üks mitmele suhete korral keelatakse kaskaad kustutamine. Kas selline tegevus on tingitud mingisugusest veateate lahendamisest või ongi see meeskonna siseselt nii vastu võetud? Meeldib ka, et veebiteenuse puhul on kasutatud eraldi mudeleid (DTOsid) andmete serialiseerimiseks ja deserialiseerimiseks JSONis. Ning mudelite vaheline andmete mappimine on samuti viidud eraldi Factory kihti, kus siis kõik vajalikud toimingud läbiviiakse. Näha on ka, et kasutatakse eraldi service (logic) kihti, kus siis tehakse ära põhi loogiline töö teenuses. Kuigi siinkohal võiks ka kogu kontrolleritesse tulev info tulla läbi service (logic) kihi, mitte osa service kihist ning teine osa otse repodest. Idee poolest siis et Controller -> Service (logic) -> Repo -> DAL. See annab jällegi parema ja kiirema ülevaate muudatuste sisseviimiseks ning on mitu kihti ei jookse ühtekohta kokku.


Kokkuvõtteks lisaks veel paar puudujääki mõlema projekti suhtes. Kood on kommenteerimata ja ka lihtsam dokumentatsioon puudub (nt. admin vaate kasutamine). Samuti pole meeskond ära kasutanud Dependecy Injection võimalusi, mida selle kursuse raames kasutati ja õpetati üpriski põhjalikult. Lisaks on ka kõik .NET raamistiku paketid kui ka kolmandate osapoolte paketid NuGet paketihaldussüsteemis uuendamata.

Siinkohal tahaks öelda, et oleks võinud natukene rohkem isu ja võhma antud projektidesse panna. Idee on kindlasti hea ja vajalik ning piisava tegutsemise korral annab välja ka vajaliku mahu. Üldiselt meeskond on suutnud panna klientrakenduse suhtlema veebiteenusega ja teinud lihtsa variandi ka andmete liigutamiseks ning töötlemiseks. Jõudu ja jaksu nii projekti edasises töös kui ka tulevaseks eksamiks! :)


Tegi meeskond VariableMoods

Kuupäev: 01. juuni 2015

ALTER eGO retsensioon XML ülesandele

XML ülesande jaoks on valitud retseptide kogumiku loomine, mille puhul on tegu ideega, mida on aine varasemas praktikumis samuti käsitletud. Siinkohal võib vaid spekuleerida, kas autor otsustas minna lihtsama vastupanu teed või kindluse mõttes järgida toimivat mudelit. Sellest tulenevalt on ka sarnasusi praktikumis looduga, näiteks atribuutide kasutuse osas.

Retseptikogumikus on kasutusel ka uudne hinnangu andmise viis, mis ei lähtu tavapärastest numbrilistest väärtustest, vaid nii-öelda emotsionaalsematest kirjeldustest. Mina isiklikult lähtuksin hinnangu puhul numbrilistest väärtustest ning praeguse hinnang atribuudi väärtuse tarbeks looksin elemendi kommentaar. Üldiselt on XML fail korrektne ning vastab nõuetele, seejuures valideerub.

XML skeemifaili puhul tundub, et ennist mainitud atribuut hinnang on jalutama läinud ning üritades XML faili ja XML skeemifaili valideerida (http://www.freeformatter.com/xml-validator-xsd.html), siis kuvatakse ka sellekohane veateade.

Loodud on ka üks XML stiilifail, mis annab HTML kujul ülevaate kõigist retseptiraamatus olevatest andmetest, seejuures on natuke lisatud ka kujundust. Kenasti ülesehitatud.

Kokkuvõtteks on tegu rahuldava tööga, määravaks saab valitud teema puhul paar möödalaskmist ning minu isiklik nägemus, kuid tööd on tehtud.

Klientrakenduse retsensioon Bananaphone poolt

Klientrakendus on ilusti eraldi allalaetav ja töötab koheselt aplikatsioonina. Klientrakendus on tehtud WPF rakendusena. Rakenduse käivtamisel tuleb esmalt ette sisselogimis vaade ning vajadusel on vaja registreerida. Registreerimine on kõige tavalisem, mis tähendab, et mingit lisa kontrolli nt sisesta parool uuesti või kasuta parooli sisestamisel vähemalt ühte numbrit või suurt tähte ei ole kasutatud. Siiski ilma sisselogimiseta rakendust kasutada ei saa. Sisselogides tuleb vaade, kus saab ise vastavadi treeniguid ülesse märkida ning ka olemasolevaid treeninguid vaadata. Uuel kasutajal on vaja kõik treeningud ja ülesanded ise luua, kuid võiks olla vaikimisi kasutajal võimalus valida treeningute vahel. Esialgu võib uuel kasutajal natukene keeruline uusi workoute ja exercise luua. Kasutajaliidese pool võib tekitada segadust. Samuti peaks olema olemas admini pool, aga neid õigusi tavakasutaja endale panna ei saa ja adminiks ka registreerida ei saa, sellepärast jääbki admini poolne vaated nägemata. Treeninguid saab salvestada ka avalikuks, mille järel iga kasutaja näeb public workoutide alt treeninguid ning neid kommenteerida. Kõik must have meetodid on rakenduses ära realiseeritud ning ka mõningad nice to have meetodid. Kuigi mõningaid märkusi võib teha kasutajaliidese poolelt, siis kogu rakendus töötab ilusasti ja kõiki vajalikke toiminguid saab teha. Teleb eraldi ära märkida, et rakendus kui ka kogu projekt on tehtud ühe inimese poolt ja kõik on vastavalt tähtaegadele valmis saadud, siis on tehtud väga suur töö ning isegi rohkem kui vaja.