Talk:Meeskond:vertigo: Difference between revisions
| Line 149: | Line 149: | ||
WebService - loodud ASP.NET Web API tehnoloogia põhjal. | WebService - loodud ASP.NET Web API tehnoloogia põhjal. | ||
Lahendus ei ole kirjutatud otse andmebaasi vastu vaid on ära kasutatud Reposid, mis muudab vajaduselt andbaasi tehnoloogia muutmise väga lihtsaks. Kasutatud on ära erinevaid mustreid(repod, factoryd ja Uow-d). Probleeme võib siiski tekkida, kui andmebaasis olevate andmete maht läheb väga suureks(päringute tegemine aeglustub tunduvalt). | Lahendus ei ole kirjutatud otse andmebaasi vastu, vaid on ära kasutatud Reposid, mis muudab vajaduselt andbaasi tehnoloogia muutmise väga lihtsaks. Kasutatud on ära erinevaid mustreid(repod, factoryd ja Uow-d). Probleeme võib siiski tekkida, kui andmebaasis olevate andmete maht läheb väga suureks(päringute tegemine aeglustub tunduvalt). | ||
'''Üldisemalt''' | '''Üldisemalt''' | ||
Revision as of 20:52, 14 June 2015
Meeskonna Valar Morghulis retsensioon meeskonnale Vertigo
Meeskonnale Vertigo xml-faili sisuks on IMBD andmete sarnane filmiandmete nimekiri. Kindlasti võib see kasutamist leida ka antud aine järgnevate osade juures.
Main.xml - vastab igati nõuetele. Rohket CDATA kasutamist mina veaks ei pea erinevalt kuna filmide kirjeldused, kompaniide nimed jm võivad sisaldada keelatud märke.
Main.xsd- ga on palju vaeva nähtud, peale atribuudi id tüübi "unsignedInt"-iks muutmise on määratud ka andmetüüpide miinimumpikkusi ja (vajaduse korral) ka nende maksimaalset esinemiste arvu.
Actors.xslt - on kasutatud if-testi sorteerimaks näitlejaid atribuudi väärtuse järgi kahte gruppi.
ShorterMovies.xslt - on loovalt kasutatud if-testis XSLT funktsioone position() ja last(), et tekitada komadega eristatud nimekiri. Kui antud koht koodis oleks kirjutatud kujul
<xsl:if test="position() != last()">, </xsl:if>
mitte
<xsl:if test="position() != last()"> , </xsl:if>
siis oleks saanud vältida ka ebavajalikku tühikut enne koma.
SmallVersionXML.xslt - on valitud alamhulk Main.xml-is olevatest andmetest.
HTML transformatsioonidel (Actors.xslt ja ShorterMovies.xslt) on vaid üks viga. Neil pole deklareeritud dokumenditüüpi. Kui kasutada W3C HTML validaatorit http://validator.w3.org/check tuleb see selgelt välja.
Line 1, Column 1: no document type declaration; implying "<!DOCTYPE HTML SYSTEM>"
Sellest saaks üle lisades xslt-failidesse vahetult enne <html> elemendi algust järgmise rea
<xsl:text disable-output-escaping='yes'><!DOCTYPE html></xsl:text>
Muidu väga hea töö mis väärib maksimumpunkte.
Veebiteenuse retsensioon meeskonna Taandarendajad poolt
Lisaks Identity kasutamisele on meeskond loonud 6 mudelit veel juurde. String tüüpi atribuutidel on ära määratud ka maksimaalsed pikkused, aga pole lisatud veateateid. See võib tekitada pärast andmete sisestamisel arusaamatusi, et miks ei õnnestu mingit stringi sisestada. Muidu on kõik atribuudid nimetatud korrektselt.
WebAppEFContexti failis on näha, kuidas luuakse mängu jaoks andmebaas. Hetkel tundub, et kasutajatel on võimalus ainult mängu mängida, mitte uusi küsimusi postitada. See võiks muidu tore funktsionaalsus olla, mida kunagi juurde lisada. Artworkide filelocationi atribuudist jääb silma, et meeskond on pildid ise kuhugi üles laadinud, et vältida imelike olukordade teket, kus näiteks google-ist leitav pilt on ära kustutatud vahepeal. Kasutusele on võetud interface-d, repod ja UoW, nagu nõutud oli. Ühestki interface-ist ainult ei õnnestu mul leida custom meetodeid.
Meeskond on loonud ka BLL projekti. Iga mudeli jaoks on eraldi DTO loodud, mis pole seotud virtuaalsete listidega. Kahju on näha, et taaskord toimuvad ainult ALL päringud ja ei ole mingit sorteerimist enne. Väikse andmebaasi puhul sellega probleemi ei teki, aga suurema projekti juures muudaks see päringute tegemise väga aeglaseks. Näiteks GetAllWorkNamesByCategory meetodi esialgse päringu võiks teha ära DAL-is, kus oleks võimalik peale DbSeti kohe sorteerida Where-iga. Hea on näha muidu, et meetoditele on ka kommentaarid lisatud.
Web API-s on kasutatud ninjecti nagu nõutud. Siin tundub, et on juba rohkem vaeva nähtud. Kasutatud on ka admini teenuse turvamiseks, mis on suur pluss. Igas meetodis tagastatakse ka BLL-is loodud DTO-sid.
Kokkuvõttes on loodud veebiteenus väga hea. Sellest andmebaasi päringute filtreerimisest võib hetkel mööda vaadata, sest hetkel pole seal palju kirjeid. Kõige rohkem meeldis mulle see, et BLL-i oli kasutatud otstarbekalt, mitte ei loodud seda lihtsalt sellepärast, et ta olemas oleks.
Veebiteenuse retsensioon meeskonna Tab poolt
Vertigo veebiteenuse solution sisaldab 5 projekti. Kohe on näha, et kasutusele on võetud Andres Käveri näide Identity kohapealt aines ASP.NET, mis on igati loogiline. Projektis on 6 erinevat mudeli klassi ja lisaks ka identity mudelid. Kõik stringi pikkused on piiratud ja kohati on ka kasutatud required annotatsiooni. Lisaks on domeeni projektis ka üks klass, kus on kirjeldatud ära ka admin kasutajanimi, parool ja ka ühenduse minutiline ja nädalane rate. Selle kasutajaga saab siis veebilehe aadressilt sisse logida ja erinevatele kasutajate admin õigusi määrata ja ka piiranguid muuta.
DAL projektis on korrektselt viidud sisse repository, factory ja uow muster. DAL projekti kihist leiab ka EFConfiguration folderi. Seal sees toimub juba mappimine ja see pärineb identity näitest. WebAppEFContextis on lisaks kasutatud ka Nloggerit ja seed meetodid. Seed meetodi puhul on sisestatud mingisugune põhi andmeid, et jälgida kuidas rakendus siis teenuse peal töötaks. Piltide kohapealt on hea, et pildid on vertigo kuskil endal olemas, mitte kuskil googlis. Selle tõttu on pilt koguaeg kättesaadav ja ei teki olukorda, et keegi on pildi kustutanud.
BLL kihis on samuti kõik nii nagu peaks. Positiivsest küljest võiks kohe välja tuua, et DTO service kihis on tehtud hulgaliselt Linq selekteerimist, et kontrollerite meetodisse anda juba sisse vajalikke andmeid.
WEB-API kohapealt torkab kontrollerite osapealt kohe silma, et DTO puhul ei ole kasutatud interface lahendust ja läbi ninjecti pole kohe konstruktorisse vajalikke service interface klasse sisse antud. Positiivse kohapeal torkab kohe silma, et kontrollerites on kasutatud lisaks ka cachemist.
Kokkuvõtlikult võib öelda, et tegemist on hea tööga. Vertigo on enda maksimaalsed punktid igati ära teeninud.
Klientrakenduste retsensioon meeskonna Tab poolt
Vertigo rakendus
Rakenduse kohapealt on selles meeskonnas rohkem vaeva nähtud. Ilmselt oli vaja tekitada rohkem tööd, kuna liikmeid on antud meeskonnas 5. Nimelt on Vertigo meeskonnal 2 rakendust. Üks neist on WPF rakendus ja teine on MVC rakendus.
WPF rakendus:
Rakendust käima pannes oli vaja kohe esmalt kasutaja luua, kuna WEB-API admin kontoga ei olnud võimalik sinna sisse logida. Kasutaja registreerimise osas külvas natukene segadust veateade, kuna registreerimine kohe esimestel kordadel ei õnnestunud. Nimelt veateade väitis mulle korduvalt "Oops! Something went wrong. Check if you have correct e-mail and your passwords match". Tegemist on väga üldise veateatega ja tegelik probleem oli selles hoopis, et minu valitud parool ei olnud piisavalt pikk. Muidu oli igati mõnus antud rakendust kasutada ja igati kasutajasõbralik. Logout nupu oleks võinud tuua ka main lehele, kuna kohe kõige esimese asjana ei leidnud seda ülesse.
Koodi kohapealt on rakendusel andmete vastuvõtmise kiht eraldi projektis nimega APIClient. APIClient projektis on lisaks mudelitele ka siis service klassid, et andmeid veebiteenusega vahetada. Service klasside osas on hea, et on loodud Base service ja siis ülejäänud service klassid pärivad seda. Config klassi on vastavalt sisse kirjutatud ka kõik urlid, mille poole pöördutakse. URL-ide kohapealt oleks võinud localhost osa kuskile eraldi muutujasse panna, et ei oleks korduvalt selle väljakirjutamist.
MVC Client
MVC rakenduse kohapealt polegi midagi erilist välja tuua. Ehk näiteks seda, et WPF rakenduses oli kasutajal võimalik parooli muuta, aga MVC-s pole seda võimalust antud. Muus osas toimis rakendus korralikult.
Koodi osas kasutab MVC klientrakendus samuti APIClient projekti. Esimesena tekkis kohe küsimus, et kuna antud MVC klientrakendus on ka ASP.NET aine raamis, et miks seal ei kasutata nõutud mustreid? Kontrollerite osas torkab kohe silma, et service klasside sisse toomine kontrolleris on kuidagi lohakas. Oleks võinud ilmselt seda realiseerida kuidagi läbi konstruktori. Positiivsest küljest on kontrollerites kasutatud vaatemudeleid ja on vabanetud nendest "halbadest" viewbagidest. Lisaks on ka kotrolleritele peale pandud role annotatsioonid, mille tulemusena ei saa näiteks registreerimata kasutaja lihtsalt urli "/games" abil mängima hakata.
Kokkuvõtlikult võib siiski väita on mõlemad klientrakendused on hästi tehtud. Antud mängu ja disaini natukese edasi arendades on potentsiaalselt vaffa mäng valmis! :)
Meeskonna Valar Morghulis retsensioon meeskonna Vertigo veebiteenusele ja klientidele
Projekt on eelmisest aastast tuttav. Tore näha, et ühe õppejõu trikk kes kogu koolis viibitud aja kõigis ainetes sama projekti tegi, tuleb ka teistele tudengitele kasuks.
Veebiteenus
Domain
Nagu minu projektis on siingi kasutatud Identity Useri stringidega Id varianti. Vertigo projektis on aga nende endi kasutaja Identity kasutajaga integreeritud. Andmemudel sisaldab 6t tabelit mis on piisav. Juurdepääs veebiteenusele on piiratud kasutades sissehitatud võimalusi.
Identity
Projekt on kõigile niigi tuttav
DAL
Sisaldab hulgaliselt projekti liikmete poolt kirjutatud meetodeid ilma milleta on normaalse rakenduse loomine mõeldamatu. Ainuke miinus siin on fakt, et LINQ kirjutamisel on sageli kasutatud query expression’eid mitte method LINQt. Projektis on meetod testandmete sisestamiseks.
BLL ja WebService
Kontrollerid on kaitstud. Rakendatakse sisu cache’imist.
Kliendid
Mõlemad kliendid kasutavad ühist veebiteenuse projekti. Varem koodi kvaliteedi kohta öeldu kehtib siingi.
Üldine
Tundub, et projektis on kasutusele võetud kõik loengutes ja praktikumides õpetatu kaasa arvatud minifitseerimine. Kood on põhjalikult kommenteeritud. Ilmselt Resharperit kasutades on eemaldatud isegi liigseid usinguid.
Kasutamine
Ebamugavuste poolest võib mainida, et WPF kliendi kaudu polnud võimalik kasutajat registreerida (tagastatakse vaid üldine veateade millest pole mingit kasu), ühtlasi oleks võinud mainida kus paiknevad projekti seadistused (mul oli vaja muuta webapi porti, sest ma ei tahtnud oma projekti IIS serveri seadistusi üle kirjutada, see aga nõudis URLide muutmist).
Kuigi WPF kliendi kaudu pole võimalik uut kontot luua on aga võimalik veebikliendi kaudu, loodud kontoga saab seejärel sisse logida ka WPF klienti. Mäng on sisuliselt sama mis eelmise aasta projektis. Silma jäi bugi, et WPF kliendis pakuti kasutajale ainult neid „Artworke“ mis olid selles mängus. See annab WPF kliendi kasutajatele eelise. Väljapakutavate „Artistide“ seas seda bugi polnud.
Üldkokkuvõttes võib tehtu võtta kokku sõnaga „Suurepärane“. Projekt (ja selle tegijad) väärivad kindlasti kõrgeimat hinnet.
Veebiteenuse retsensioon meeskonnalt Iread
Esmasel pealevaatamisel on koheselt märgata, et projekti loomisel on kasutatud õppejõu Andres Käveri aine ASP.NET Identity näidet. Kasutusel on kuus erinevat mudeli klassi koos identity mudelitega. String-tüüpi atribuutidel on kenasti pikkused piiratud kuid vigade korral puuduvad korrektsed vastused. Üldjoontes on kõik atribuudid nimetatud mõistetavalt ja korrektselt. Eraldi on välja toodud Admin kasutaja ja parool klassis kus on veel lisaks kasutaja ühendus teenusega minutiliselt ja nädala lõikes ära toodud. Ühtlasi on võimalik sama kasutajaga teenusesse sisse logida ning teistele juba süsteemis olevatele kasutajatele õigusi määrata ja piiranguid sättida.
Korrektselt on kasutatud repository, factory ja UoW mustrit DAL projektis. Küll aga ei leidnud ühtegi omaloodud meetodit. Samast kihist leiab ka Identity näite EFConfig. Peab mainima, et koheselt jäi silma meeskonna valik meediafailid ise eraldi üles laadida vältimaks nende mitte ilmumist või kadumist. Ise enesest oleks saanud selle ka lahendada lokaalselt. WepAppEFContextis on kasutatud Nloggerit ja Seed meetodit. Viimast on kasutatud põhiandmete sisestamisek, et hiljem jälgida teenuse töötamist andmete korral.
Kasutusel on ka BLL projekt kus on iga mudeli jaoks eraldi DTO. Koheselt hakkab silma, et meeskond on vaeva näinud ja aega kulutanud meetodide kommenteerimisele mis annab kõrvalt vaatajale (ja ka projekti meeskonna siseselt) hea ülevaate olukorrast ja asjade toimimisest. Küll aga paneb muretsema päringute ülesehitus. Hetkeline lahendus on küll kenasti töötav ja kiire kuid kahjuks pole ta aga skaleeruv. Andmemahu suurenedes baasis või hetkel teenust kasutavate kasutajate arvu järsk tõus toovad kaasa kindlasti probleeme.
Web API tundub väga hästi üles ehitatud olevat. Ühtlasi on see ka töö suurimaid osasid. Silma torkab teenuse kaitsmiseks sisse viidud osad mis on väga õige lähenemine asjale. Cache'mise kasutamine ei lisa mitte ainult stiilipunkte vaid ka palju muudki. Üldjoontes võib öelda, et töö on hästi sooritatud ning meeskond on kindlasti palju vaeva ja higi näinud.
Veebiteenuse retsensioon meeskonna R0ds poolt
Vertigo – Veebiteenus
Meeskond Vertigo on teinud oma veebiteenusele väga hea analüüsi, kust on juba näha, et andmebaas eeldusena on olemas ning olemeid on seal kohe kindlasti üle kuue. Analüüsis on välja toodud ka „must have“ asjad, mida loodud teenus peab võimaldama. See aitab mõista, millega on täpsemalt tegu. Lahendus on täitnud kõik nõutud punktid: teenuse pakkumine, kasutajate tuvastus ja haldus, kasutajate ja statistika üle arve pidamine, pöördumiste arvu piiramine ja haldamine, mitme kasutaja võimalus, ASP.NET Web API tehnoloogia ja vähemalt 6 olemiga andmebaas. Lahendus ise on kenasti ära jaotatud erinevateks projektideks, nagu:
BLL - mille näol on tegu äriloogika kihiga,
DAL - andmebaasiga suhtlemiseks(entity framework ja NLog).
Domain - erinevate mudelite jaoks(mudelites kasutatud andmete annotatsioone, mis võimaldavad muuta mõne välja kohustuslikuks ja stringidele määrata pikkus piiranguid: MaxLength ja Required. Ligipääsu on piiratud juba varasemalt integreeritud võimalusi kasutades), Identityle on lisaks tehtud veel omaltpoolt kuus mudelit.
Identity - identiteedi loogika(A.Käver’i tehtud töö põhjal).
WebService - loodud ASP.NET Web API tehnoloogia põhjal.
Lahendus ei ole kirjutatud otse andmebaasi vastu, vaid on ära kasutatud Reposid, mis muudab vajaduselt andbaasi tehnoloogia muutmise väga lihtsaks. Kasutatud on ära erinevaid mustreid(repod, factoryd ja Uow-d). Probleeme võib siiski tekkida, kui andmebaasis olevate andmete maht läheb väga suureks(päringute tegemine aeglustub tunduvalt).
Üldisemalt
Kood on üsnagi hästi kommenteeritud pole midagi ülearu ega ka liiga vähe, isegi kasutamate jäänud usingud on eemaldatud. Nii põhjalikust koodi puhastamisest on selgelt näha, et meeskond on loonud väga põhjalikult läbi töötatud veebilahenduse, selline pühendumus lööb välja ka lahenduse erinevates osades(N: cache’i kasutamine), mitte ainult koodi dokumenteerimises. On näha, et on kasutatud loengutes ja praktikumides läbi võetud materjale. Isegi pildid on omaltpoolt üles laetud, et vältida vigade tekkimist, kui need kuskilt saitidelt maha võetakse.
Kokkuvõte
Meeskond Vertigo väärib igati tehtud töö eest maksimumpunkte. Kogu lahendus on kenasti koostatud,esineb vaid väiksemaid vigu, üldiselt ei ole mittemillegi üle väga nuriseda.
