Talk:KK without K

Meeskond „V“ retsensioon meeskond „KK without K“ teenuse kohta – 3.06.2013

Meeskond KK_without_K on võtnud eesmärgiks luua teenus LanParty haldamiseks, kahjuks on teenuse pakkumise eesmärgid wikis väga lühidalt kirjeldatud ning rohkem ei täpsustata. Esmalt tekib kohe küsimus, mis on teenuse skoop, kas vaid kohapeal kohtunike jaoks või ka kasutajate registreerimiseks. Wikis on siiski kirjeldatud kõik teenuse meetodid, millest kahjuks samuti ei loe välja täpsemat skoopi. Teenuse meetodite dokumentatsioonist loeb välja, et teenus võimaldab kasutajate tuvastamist, haldamist, rollihaldust ning samuti mängude, võistluste ja meeskondade haldamist. Dokumentatsioon on hästi struktureeritud.

Teenuse lähtekoodi uurima asudes ilmneb, et teenuse loomisel on kasutatud Entity Framework kood enne lähenemist ning seega on teenuse ja andmekiht selgelt eraldatud. Andmemudeleid uurides jääb silma, et enamus string väljadel on maksimaalne pikkus määratud, kuid mudelite kood võinuks olla paremini struktureeritud, näiteks klassi atribuudid ning viited eraldada. Lisaks on mudelitel enamjaolt puudu niinimetatud navigeerimisväljad, mis on mingil põhjusel välja kommenteeritud. Samuti ei ole kasutatud laiska väärtustamist ning puudub ka võimalus niiöelda virtuaalseks kustutamiseks, sest puudub kustutamise kuupäeva väli. Andmekihi projektis on kasutusel repositooriumite muster ning iga andmemudeli jaoks on loodud oma repositoorium, mis põhineb baas-repositooriumil. Repositoorimite puhul kasutatakse ka korralikult liideseid. Web API teenuses on kasutatud niinimetatud sõltuvuse süstimise mustrit, täpsemalt siis Ninject nimelist lisa.

Controllerites riivab pisut silma repode rohkus ning nende mitte-konstantne nimetamine. Samuti jääb silma „ContestControlleris“ üksiku Contest objekti pärimisel selle alamobjektide täitmine otse kontrolleris, minu arvamusel oleks selleks olnud õige koht repositoorium, kus oleks saanud asja palju elegantsemalt lahendada. Märkata võib ka, et kontrollerid on peamiselt Visual Studio poolt automaatselt genereeritud ning „DbContext“ asendatud repositooriumitega. Viimane teguviis näitab, et tuntakse Visual Studiot ning keskenduti vajalikule, kuid samas on ka siit tulenevaid kummalisi koodiosi. Näiteks Contest objekti pärimisel päritakse see esmalt repositoorimist ja seejärel täidetakse selle alamobjektid (Games, Teams jms), selles täitmisest edasi on aga kontroll „if(contest == null)“.

„LoginController“´is on samuti näha, et parooli hashimine, et võrrelda seda andmebaasis oleva hashitud parooliga, on samuti otse kontrolleris ja oleks võinud olla paigutatud repositooriumi. Hea külg asjal on, et paroole üldse hashitakse, seega on nende hoidmise turvalisusele mõeldud. Küll aga tekib küsimus miks ei kasutata .net raamistiku poolt pakutavaid autentimise vahendeid täielikult ära. Kasutatud on küll rollide haldamist, kuid rolle lisada ei ole võimalik ning rollidesse lisamine toimub hetkel kasutajanime alusel : „if (user.UserName != "Karhu") Roles.AddUserToRole(user.UserName, "User"); else Roles.AddUserToRole(user.UserName, "Admin");“. Samuti ei ole teenuse poolel kuskil näha teenuse piiramist vastavalt rollile. Kasutatud on osaliselt ka sisseehitatud kasutajahaldust, kuid samas on kasutajate info dubleeritud ka teenuse autorite poolt genereeritud andmebaasi ja klassidesse.

Teenuse poolelt on puudu ka turvaline ühendus (sertifikaatidega) ja kasutajate päringute/tegevuste logimine ning sellele vastavalt teenuse kasutamise piiramine. Seetõttu jääb selle osa retsenseerimine puudu. Samuti jääb mitmes kohas silma väljakommenteeritud koodi ning üldine ülesehitus on kohati häiriv. Samas on võimalik Wiki logist välja lugeda, et teenus on välja töötatud enamjaolt 7 päeva jooksul. Mis iganes põhjused autoritel sellele porjektile suhteliselt vähese aja pühendamiseks olid,siis lühikese aja kohta hindaksin ise saavutatut siiski päris heaks, kuid kulunud aega mitte arvestades oleks autoritel veel tükk tööd, et jõuda asjaliku teenuse pakkumiseni.

Meeskond "V"

Meeskond „V“ retsensioon meeskond „KK without K“ klientrakenduse kohta – 3.06.2013

Meeskond on loonud WPF rakenduse, mis kasutab nende endi loodud Web API teenust. WPF rakenduses on hea tava kasutada MVVM (Model-View-ViewModel) mustrit, millest on C# programmeerimise aines korduvalt räägitud. Antud WPF rakenduses aga MVVM mustrit järgitud pole, mis on suureks miinuseks.

Rakenduse kihtideks jaotamisest tundub olevat tehtud niipalju, et vaated ja kollektsioonid on pandud eraldi kausta. Esmapilgul jääb arusaamatuks miks kollektsioonide jaoks on tehtud eraldi klassid, kuid lähemal uurimisel selgub, et igale kollektsioonile, antud kaustas, on lisatud üks meetod „CopyFrom“, mis võtab sisendiks „IEnumerable<T>“ tüüpi listi ja tõstab sellest ükshaaval T objektid „ObservableCollection<T>“ tüüpi listi ümber, siinkohal T on kindel tüüp ning iga rakenduses oleva tüübi kohta tundub olevat eraldi kollektsioon. Siinkohal oleks kindlasti võinud kasutada üld-klassi ehk niinimetatud „Generic“ tüüpi. Tagasi põhjuse juurde, miks rakenduse autorid on teinud, siis jääb mulje, et põhjuseks ongi „IEnumerable" tüüpi listi sisu kopeerimine „ObservableCollection“ sisse, millele ei ole vist muud lahendust leitud. Lahenduseks oleks olnud ka märksa lihtsam kood: „ObservableCollection<T> list = new ObservableCollection<T>(Siia IEnumerable tüüpi list);“, mille võib leida kiirelt google abiga.

Leidnud, et kollektsioonid on tegelikult antud rakenduses üleliigsed siis teine eraldamine ehk vaadete eraldi kausta panemine on igati hea otsus. Vaateid lähemalt uurides selgub, et nende visuaalne pool on üles ehitatud väga korrapäratult, jääb mulje, et elemendid on enamjaolt lihtsalt paika lohistatud ja suurus samuti hiirega paika tõmmatud. Leidub mõni üksik näide StackPanel´i kasutamisest, kuid oleks WPF rakenduse vaate disainimisel oodanud Grid´i kasutamist. Antud juhul on sellise XAML koodi tulemusel disaini muutmine tulevikus kohmakas ning aeganõudev. Positiivse poole pealt, vaadetes on kasutatud sidumist ehk „Binding“. Lisaks vaadete kaustas olevatele vaadetele on veel põhivaated. Põhivaates on näha taas sidumise kasutamist, kuid jällegi on XAML elementidest alakasutatud Grid võimekust ning selle asemel pistetud elemendid StackPaneli sisse. Autorid on kasutanud erinevate vaadete jaoks TabControl elementi mille tulemusel on kõikide vaadete kood ühes XAML failis. Koodi parema loetavuse mõttes oleks võinud iga vaate koodi tõsta siiski eraldi faili ja TabControl elemendis neile viidata. Põhivaated on samuti dubleeritud, eraldi vaatefail tavakasutaja ja administraatori jaoks. Siinkohal oleks võinud kindlasti mõelda koodi taaskasutuse peale, kuid mingil põhjusel on autorid läinud teist teed.

Vaadates teenusega suhtlemist, siis positiivne on, et on kasutatud baasaadressi lisamist ning koodis kutsutakse välja vaid kindel kontroller, mitte ei trükita igalpool täispikka aadressi. Ebamugav on aga vaadata vaadetes korduva struktuuriga proovi-püüa ehk „Try-Catch“ lauset, mille oleks võinud kindlasti viia eraldi meetodite klassi ning ehk isegi kasutada „Generic“ tüüpi, et koodi taaskasutada.

Rakendust käivitades ja natuke testides ilmneb, et mõnes kohas on tehtud ka kontrollid, et rakendus kokku ei jookseks. Näiteks antakse veateadet, kui üritatakse ühtki mängu valimata mängu redigeerima hakata. Kuid kahjuks ei ole veahaldusega ning veateadetega eriti kaugele jõutud. Rakendust natuke uurides tekib probleeme mängu lisamisega, sest mängu lisamiseks on tarvis valida ka mängu žanr, kuid viimast ei ole võimalik rakenduses endas lisada või vähemalt minul ei õnnestunud antud kohta leida. Žanri taha jääb kinni mängu lisamine, viimase puudumisel takerdub ka võistluse loomine ning nende kahe puudumisel ei ole ka meeskondadel mingit mõtet.

Kokkuvõttes on tegemist kasutuskõlbmatu rakendusega, milles on küll võimalik autorite endi poolt loodud teenust kasutatud, kuid mitte täisväärtuslikult. Kood on rakenduses samuti halvasti loetav, sest puudub korralik struktuur. Oodates retsenseerimisest ka millegi uue õppimist, siis antud juhul pidin kahjuks pettuma.

Meeskond "V"

Meeskond BitByBit Retsensioon - Kliendirakendus

Tegemist on projektiga, mille eesmärk oli luua rakendus, mida saaks kasutada LAN party haldamiseks. Solutioni esmasel käivitamisel tekkis üks viga. Nimelit ei leidnud projekt faili “MvcApplication3.csproj”. Tundub, et kaustas “MvcApplication3” oli antud fail hoopis nimega “MvcAPI.csproj”. Tegemist on tähtsa osaga projektis, kuna ilma selleta ei ole võimalik isegi sisse logida rakendusse. Rename’ga sai see probleem lahendatud.

Kliendirakendusel on sisselogimis/registreerimis aken. Välimuse poole peale oleks ehk võidud rohkem vaeva näha. Esmapilguga jätab disain natuke nõrkavõitu mulje. Ebamugavust tekitas ka “Username” ja “Password” lahtritega. Tag’ide (või mõne muu viisi) asemel on antud lahtrid märgistatud nii, et nende sisse on kirjutatud vastavalt “username” ja “password”. Ebamugavus kujuneb just sellest, et vajutades lahtri peale ei kao selle esialgne väärust ära ning selle peab use manuaalselt ära kustutama.

Teine pisikene apsakas, mida oli kiirelt märgata oli teate “Logging in...” puhul. Juhul, kui teenusega ühendamisel tekib viga tuleb pop-up veateade “An error occured while sending the request.” Peale “OK” vajutamist aga jääb “Logging in...” teade siiski alles.

Registreerumisel tekkisid sammuti kummalisi erroreid. Ühel juhul tuli exception muutuja “User” kohta ja teisel pop-up error: “Response status code does not indicate success: 500 (Internal Server Error)”. Kuigi mõlemal juhul tundus registreerimine olevat edukas, kuna need kasutajad siiski loodi.

Sisse logides avaneb LanParty haldus leht, kus on võimalik hallata käesolevaid mänge, kasutajaid ja teha meeskondi. Siinkohal mainiks ka, et välimuse poole pealt jääb natuke väheks. Mõne koha peal on nuppude positsioonid ja suurused natuke paigast ära.

Kuigi suurim probleem tundub olevad just veahaldusega.. Näiteks kui vajutada “Details” nupule (nii teams, kui ka contests tab’ides) samal ajal, kui list on tühi, tekib nullpointer exception. Meeskondade tab’i alt vajutades “add team” peale tekib nupppointer exception, kui meeskondade list on tühi ja proovin lisada “tühja” meeskonda.

Siinkohal tekib ka küsimus, et kas antud rakendus on pigem mõeldud LanParty “juhile” mängude, teamide ja võistluste haldamiseks või tavakasutajale. Küsimus tekib, kuna “Users” tab’i alt on kõikide kasutajatega võimalik teiste kasutajate informatsiooni muuta vabalt. Seega tekib segadus, et miks on vaja üldse eraldi paroole ja sisselogimist igale kasutajale, kui kõik kasutajad võivad teiste kasutajate andmeid vabalt muuta.

Projekt iseesenest on väga huvitava ideega, kuid antud seisus ei ole just väga kasutuskõlblik.

Meeskond BitByBit Retsensioon - Veebiteenus

Koodi struktuur ja ülessehitus tunduvad olevad üpriski aksepteeritavad. Problemaatiline tundub olevat aga Vewis’i all AddGameWindow.xaml’is olev funktsioon “public async void AddTeamToContest(object sender, RoutedEventArgs e)”, mis peaks tegelema meeskondade lisamisega võistlustesse.. Nimelt, kui kliendirakenduses proovida lisada mingit meeskonda “Contests” alla, siis ilmneb nullpointer exception. “private async void GetSpecificTeam(object sender, RoutedEventArgs e)”” meetodis (mille ülesanne on teha päringuid meeskondades olevate isikute kohta) tekib sammuti exception kui proovida “detailse” vaadata samal ajal, kui ei ole meeskonda selekteeritud. Seega võib järeldada, et veahaldus on üpriski poolik.

Antud probleemi põhjuseks tundub olevat see, et ei kontrollita nullpointerexceptioni tekkimist. Kuigi try-catch’i kasutatakse paljude erinevate vigade haldamiseks tundub olevat nullpointerexceptioni kontroll puudu.

Autentimise poolt tooks välja ka paar puudulikust. Kuigi proolida on hashitud (mis kiindlasti tõstab ka turvalisust) ei ole rakendatud enamus .Net raamistiku poolt antud võimalusi. Lisaks ei kasutata turvalist ühendust. Samas kui tegu on ainult LanParty haldamiseks thetud aplikatsiooniga, siis tõenäoliselt ei ole autentimine ja üleüldine turvalisus väga olulised. Eriti arvestades, et kõik kasutajad mõnes mõttes käituvad nagu adminnid.

Kokkuvõtteks ütleksin, et kuigi tegu on huvitava programmiga, millel võivad potensiaalselt olla välga pallju huvitavaid rakendusi, on põhi probleemideks just pooleli veahaldus, kehv disain / välimus ja puudulik rollihaldus kasutajate vahel.

Meeskond BitByBit