Talk:Team SPOT: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 36: | Line 36: | ||
Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud. | Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud. | ||
=Retsensioon meeskonna Team SPOT veebiteenusele= | |||
Retsensioon meeskonna [https://wiki.itcollege.ee/index.php/Team_SPOT Team_SPOT] veebiteenusele meeskonna [https://wiki.itcollege.ee/index.php/A$unik A$unik] poolt. | |||
Taaskord (nagu meeskonna [https://wiki.itcollege.ee/index.php/Ticketer Ticketer] klientrakenduse retsensiooni tehes) jäi esimese asjana silma rakendust alla laadides see, et pole eemaldatud obj ja bin faile. See teeb lähtekoodi paki mõttetult suureks: antud rakenduse puhul ~200MB. Lihtne variant oleks need kaustad välistada (GIT korral) .gitignore failis ja siis linkida repo kloonimiseks. | |||
Veebiteenuse eesmärgiks on väljastada ning vastu võtta andmeid treeningute kohta. Järgnevas retsensioonis lähtutakse SPOT meeskonna lehel olevast analüüsist, projekti koodi vaatamisest ning Postman-iga tehtud päringutest teenuse vastu, et hinnata tehtut (vähesel määral sai ka klientrakenduse abil brauseri võrguliikluse kaudu veebiteenusele tehtavaid päringuid uuritud). | |||
'''„Peaks olema“ sektsiooni analüüs vaadates veebiteenuse koodi''' | |||
Implementeeritud on: | |||
1. kasutajate loomine; | |||
2. autentimine; | |||
3. klubide, treenerite ja treeningute info väljastamine; | |||
4. tunniplaani info väljastamine; | |||
5. treeningutesse registreerimine; | |||
6. registreeringu tühistamine; | |||
7. piirangute haldamine (autoriseerimise näol – heites aga kiire pilgu klientrakendusse, siis seda ei kasutatud seal või siis polnud realiseeritud selles funktsionaalsusi, mis seda vajaks). | |||
Puudu on: | |||
1. teenuse poole pöördumiste arvu piiramine (sellega seotult on küll määratud IdentityConfig.cs failis MaxFailedAccessAttemptsBeforeLockout muutuja, kuid detailsemaid kontrolle selle nõude lahendamiseks ei märganud). | |||
Enam-vähem olemas: | |||
1. kasutajate ja kasutusstatistika logimine – kasutusstatistikat saab vahetabelitest kätte küll, aga seal on abiks olevaid välju, mida ei kasutata (nt CancelledAtDt, CancelledBy, CreatedBy jne). | |||
Veebiteenuses on lisaks jõutud implementeerida ka „Võiks olla“ sektsioonist funktsionaalsusi nagu: | |||
1. klubide, treenerite, treeningute lisamine ja muutmine; | |||
2. tunniplaanis treeningute tühistamine. | |||
'''Praktiline teenuse testimine ja avastatud vead:''' | |||
Klientrakenduse põhjal ja brauseri tööriistade alt päringuid vaadates selgus, et GET päringud töötavad ning töötab ka sisselogimine ja registreerimine (viimased kaks on muidugi peamiselt Identity templiitidega juba realiseeritud funktsionaalsus). Püüdes Postman-iga POST, PUT, DELETE päringuid teha õnnestusid enamused neist, mis on hea. Mõned vead siiski avastatud sai TrainersController-is ja RegistrationsController-is. | |||
1. POST /api/trainers ehk treeneri loomine ebaõnnestub. Andmebaasi kirje küll luuakse, aga DTO tagastamisel tundub, et mapping on vigane. | |||
2. PUT /api/trainers/:id küll töötab täis andmekomplekti korral, kuid JSON-ist trainerId eemaldamisel taaskord tagastatav Dto ''mapping'' ei arvesta sellega ja server tagastab staatuse 500. | |||
3. PUT/DELETE api/registration – siin võiks olla lisaks GetByIdForUser kontrollile "admin" rolli kontroll, kes saaks siis nii või teisiti neid andmeid muuta. Lisaks, kui GetByIdForUser on mõeldud selleks, et kasutaja saaks ainult omi andmeid muuta, siis miks siin teenus lubab muuta userId välja, mis tähendab, et üks kasutaja saab registreerimise määrata endalt teisele kasutajale. | |||
See tähendab, et puudu on pisut veahaldust, kui kõik ei toimu nö ''happy path'' viisil, kus tuleb täpselt oodatud andmekogum kontrollerisse. Üldmulje praktilisest testimisest on aga hea. Kontrollerite järgi sai hästi pildi ette, mis andmeid nad ootavad ja mida kontrollitakse nende juures ning neid polnud raske Postman-iga tööle saada. | |||
'''Projekti struktuur, koodi ülesehitus ja kasutatud mustrid''' | |||
Positiivsed aspektid: | |||
Projekti üldine struktuur on loogiline. On eraldi projektid põhiosade jaoks - DAL, Domain, Identity, WebApi, DTO-ga seonduv projektis BL. | |||
Kasutatud on ''dependency injection''-it Ninject näol. Andmebaasiga suhtlus kontrollerites toimub Service ning UOW objektide abil. UOW-s on defineeritud ilusti kõik vajalikud repositooriumid. Repositooriumites on kohati ka lisameetodeid ja mitte kasutatud ainult neid, mis tulevad projektipõhjaga kaasa. Kasutatakse liideseid objekti tüübina ja mitte implementatsiooni ennast. Kontrollerites võetakse vastu ja tagastatakse DTO-sid, mitte otse andmebaasi minevaid objekte. Olemitel „Domain“ projektis on kasutatud valideerivaid annotatsioone. Neid võinuks ehk lihtsalt rohkem olla. | |||
Oleks võinud parem olla: | |||
Äkki oleks võimalik see MVC projekt, mis WebApi sees on ja mõeldud API dokumenteerimiseks, tõsta eraldi kausta? See on tõenäoliselt lihtsalt templiidiga loodud, aga teeb taolisel kujul WebApi projekti struktuuri segaseks. Eriti häirib seejuures need MVC poolt kasutatavad frontend faile hoidvad kaustad nagu „Content“, „Views“ ja „Scripts“. | |||
Domain, Interfaces ja DAL projektis võiks kasutada objektide kaustadesse jaotamist, et tekiks ülevaade seotud funktsionaalsusega klassidest. Lisaks on mõnel pool jäänud sisse palju väljakommenteeritud koodi (ja need pole TODO-d, mida kunagi ehk hakatakse kasutama). Siin oleks näiteks (tõenäoliselt A. Käveri projektipõhja jäänuk) DataBaseContext.cs, kus võinuks eemaldada „PK – string“ versioonis Identity olemite sektsioonid. Lisaks leidus pisemaid tähelepanematusi nagu DAL all on üks tühi klass ServiceMap.cs ning klassides on palju mittevajalikke „using“ direktiive – nende ebavajalike asjade eemaldamisel aitab tavaliselt IDE mõni tööriist. | |||
'''Kokkuvõte''' | |||
Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele. | |||
= Meeskond CoverMe retsensioon meeskonnale SPOT = | |||
Meeskonna eesmärk oli luua veebiteenus, mis võimaldab saada infot pakutavate treeningute kohta, sisestada ja kuvada tunniplaani andmeid, registreerida osalejaid tundidesse ning end sealt eemaldada. Samuti oli ette nähtud, et administraatorid saavad lisada, muuta ja kustutada kõike sprodiklubiga seonduvat ning treenerid ja spordiklubi esindajad saavad toimetada treeningutega seotud andmete sisestamise ja muutmisega. Andmebaasimudel on tehtud väga põhjalikult ning tabelite kirjeldused on samuti välja toodud. | |||
Meie hinnangul on eesmärk põhiosas täidetud, realiseeritud on enamus kavandatud must-have funktsionaalsusest (välja on jäänud logimine). Loodud on veebiteenus, mis kasutab REST arhitektuuri ja ASP.NET MVC Web Api tehnoloogiat. | |||
Veebiteenuse struktuur on üles ehitatud kihiliselt, mis võimaldab vajadusel süsteemi osasid lihtsamini muuta, täiendada ja vajadusel välja vahetada. Kihid on jaotatud järgmiselt: | |||
BL - sisaldab DTO-sid ja nende koostamiseks vajalikke Factoreid. Samuti on siin Service klassid, milles on kirjas kõik päringud andmebaasist (Get mitmesugustes variantides, Add, Edit, Delete). Lisaks tavalistele CRUD meetoditele on tehtud ka spetsiifilisemad päringud , näiteks GetByIdForUser jne. Päringuid tehakse uow-de kaudu. Service’tele ja Factory’tele on loodud Interface’d. | |||
DAL - kasutatakse EFRepositoryFactory ja EFRepositoryProvidery põhimõtteid. DbInitializeris antakse ette lähteandmete seed’imine. Repositooriumid on omaette kaustas, kuhu on lisaks EFRepository-st päritud meetoditele juurde kirjutatud palju erinevaid meetodeid funktsionaalsuse täiendamiseks. | |||
Domain - andmebaasi mudelis on kokku 12 olemit, mis on nõuetele vastav. Üldine andmebaasimudeli ülesehitus on loogiline ning listid on algselt väärtustatud, mis tagab selle, et ei pea NullReference Exceptione kontrollima. Vajalikesse kohtadesse on annotatsioonid juurde lisatud ja nendega ei ole üle pingutatud, et süsteemi liiga kirjuks ajada. Tõstame esile asjaolu, et kasutatud on Base Entity’t, millest kõik ülejäänud olemid pärinevad. See ühtlustab rakenduse koodi ja on üldse väga hea mõte. Kasutatud on palju nullable tüüpi muutujaid, mis on antud juhul õigustatud, andes andmete sisestamisel paindlikkust, samas lisades mõneti riskantsust. | |||
Interfaces - Kõikide repositooriumide jaoks on loodud ka interface´d. Samuti leidub seal UOW jaoks interface. | |||
WebApi - Kokku on kasutusel 6 kontrollerit, milles on realiseeritud CRUD meetodid koos mõne spetsiifilisema meetodiga (näiteks GetFilteredForPeriod). Kontrollerid saavad oma sisu vastavatest service’itest. Identity rakendamiseks on kontrollerite meetoditel kasutatatud Authorize annotatsioone. Samuti on läbi mõeldud, et mõnda meetodit on autoriseeritud kasutama ainult “Admin”-kasutaja. Näiteks ainult “Admin”, saab salvestada treenereid andmebaasi. Kontrollerites on kenasti kasutatud erinevaid Http-staatuskoode, mitte ainult Ok(), vaid ka Forbidden(), NotFound() jne. Samuti kasutatakse edukalt sõltuvuste süstimist (Dependency Injection). Kasutatud on OAuth bearer token authentication’it. | |||
Lisaks peame oluliseks märkida, et kood on kirjutatud heas stiilis, kõikjal inglise keeles, ei esine keelte segunemist. Paljudes kohtades oli kood kommenteeritud, kuid see tundus olevat ise kaasa tulnud. Meeskonna enda kommentaare ei paistnud. | |||
Kokkuvõtteks võib öelda, et tegemist on väga hästi kavandatud ja realiseeritud veebiteenusega ja meeskonnaliikmete panus on olnud märkimisväärne, eriti arvestades seda, et tegemist oli vaid kahe liikmega. | |||
Latest revision as of 08:06, 15 June 2017
Retsensioonid
Retsensioon meeskonnalt Ticketer
XML fail
Faili üldstruktuur on projekti wiki lehel hästi lahti kirjutatud (norida saab selle kallal, et kõiki tekstis viidatud linke wiki lehel ei ole). XML-fail vastab kirjeldusele. Failis selgitavad kommentaarid puuduvad. Samas on fail loogiliselt struktureeritud ja kergesti arusaadav. Elementide nimed on loogilised. Elementide ja atribuutide nimedes on kasutatud ühtset stiili.
Võib-olla tasuks märkida treenerite juures välja tuua, millise treeningstiili treeninguid iga treener teeb / saab läbi viia.
Andmete paigutus atribuutidesse ja elementidesse tundub mõistlik. Võimalik, et litsentside info võiks eraldi elemendina olla. Kui tähte närida, siis toimumiskoha atribuudis määramine välistab treeningud, mis toimuvad mitmes ruumis.
Kirjeldusi ja nimesid sisaldavate elementide sisu on näitefailis esitatud ohutult CDATA lõikudena.
Näidisfail valideerub ning vastab struktuuri keerukuskirteeriumitele - on vähemalt neli loogilist dimensiooni; vähemalt kolmel dimensioonil on kasutatud ID-st informatiivsemaid atribuute.
XML schema
Näidisfail vastab schema tingimustele. Andmetüübid vastavad andmete sisule ja eeldatavale kasutusele.
Mõnes kohas tundub, et elementide ja atribuutide kohustuslikuks tegemisega on liialdatud. Vaieldav, kas treeneri reiting, treeningut kirjeldav video või treeningu kirjeldus peavad kindlasti kohustuslikud olema. Samuti pole lubatud ilma ühegi scheduledItemita treeningud.
Transformatsioonid
XML -> HTML transformatsioon
Transformatsioon vastab esitatud keerukuse tingimustele. Kasutatud on mitut foreach tsüklit, tingimuste kontrolli, stringitöötlust, defineeritud muutujaid.
Andmed on esitatud loogiliselt ja arusaadavalt. HTML on keerukam kui XML-st välja nopitud teksti listis välja kuvamine. Kujunduses on kasutatud CSS-i. Andmete esitamiseks on kasutatud tabeleid ja iframe’e.
XSLT fail valideerub. Väljundiks olev HTML annab W3C validaatoris kaks errorit (“no document type declaration; implying "<!DOCTYPE HTML SYSTEM>” ja “required attribute "TYPE" not specified <style>”)
XML -> XML transformatsioon
Transformatsioon on piisavalt keerukas (nested foreache’id; tingimuskontrollid jne). Transformatsioon vastab kirjeldusele ning on teostatud korrektselt.
Nii XLST fail kui väljundiks olev XML fail valideeruvad.
Mõlema transformatsiooni loetavusele oleks kommentaarid abiks tulnud.
Retsensioon meeskonna Team SPOT veebiteenusele
Retsensioon meeskonna Team_SPOT veebiteenusele meeskonna A$unik poolt.
Taaskord (nagu meeskonna Ticketer klientrakenduse retsensiooni tehes) jäi esimese asjana silma rakendust alla laadides see, et pole eemaldatud obj ja bin faile. See teeb lähtekoodi paki mõttetult suureks: antud rakenduse puhul ~200MB. Lihtne variant oleks need kaustad välistada (GIT korral) .gitignore failis ja siis linkida repo kloonimiseks.
Veebiteenuse eesmärgiks on väljastada ning vastu võtta andmeid treeningute kohta. Järgnevas retsensioonis lähtutakse SPOT meeskonna lehel olevast analüüsist, projekti koodi vaatamisest ning Postman-iga tehtud päringutest teenuse vastu, et hinnata tehtut (vähesel määral sai ka klientrakenduse abil brauseri võrguliikluse kaudu veebiteenusele tehtavaid päringuid uuritud).
„Peaks olema“ sektsiooni analüüs vaadates veebiteenuse koodi
Implementeeritud on:
1. kasutajate loomine;
2. autentimine;
3. klubide, treenerite ja treeningute info väljastamine;
4. tunniplaani info väljastamine;
5. treeningutesse registreerimine;
6. registreeringu tühistamine;
7. piirangute haldamine (autoriseerimise näol – heites aga kiire pilgu klientrakendusse, siis seda ei kasutatud seal või siis polnud realiseeritud selles funktsionaalsusi, mis seda vajaks).
Puudu on:
1. teenuse poole pöördumiste arvu piiramine (sellega seotult on küll määratud IdentityConfig.cs failis MaxFailedAccessAttemptsBeforeLockout muutuja, kuid detailsemaid kontrolle selle nõude lahendamiseks ei märganud).
Enam-vähem olemas:
1. kasutajate ja kasutusstatistika logimine – kasutusstatistikat saab vahetabelitest kätte küll, aga seal on abiks olevaid välju, mida ei kasutata (nt CancelledAtDt, CancelledBy, CreatedBy jne).
Veebiteenuses on lisaks jõutud implementeerida ka „Võiks olla“ sektsioonist funktsionaalsusi nagu:
1. klubide, treenerite, treeningute lisamine ja muutmine;
2. tunniplaanis treeningute tühistamine.
Praktiline teenuse testimine ja avastatud vead:
Klientrakenduse põhjal ja brauseri tööriistade alt päringuid vaadates selgus, et GET päringud töötavad ning töötab ka sisselogimine ja registreerimine (viimased kaks on muidugi peamiselt Identity templiitidega juba realiseeritud funktsionaalsus). Püüdes Postman-iga POST, PUT, DELETE päringuid teha õnnestusid enamused neist, mis on hea. Mõned vead siiski avastatud sai TrainersController-is ja RegistrationsController-is.
1. POST /api/trainers ehk treeneri loomine ebaõnnestub. Andmebaasi kirje küll luuakse, aga DTO tagastamisel tundub, et mapping on vigane.
2. PUT /api/trainers/:id küll töötab täis andmekomplekti korral, kuid JSON-ist trainerId eemaldamisel taaskord tagastatav Dto mapping ei arvesta sellega ja server tagastab staatuse 500.
3. PUT/DELETE api/registration – siin võiks olla lisaks GetByIdForUser kontrollile "admin" rolli kontroll, kes saaks siis nii või teisiti neid andmeid muuta. Lisaks, kui GetByIdForUser on mõeldud selleks, et kasutaja saaks ainult omi andmeid muuta, siis miks siin teenus lubab muuta userId välja, mis tähendab, et üks kasutaja saab registreerimise määrata endalt teisele kasutajale.
See tähendab, et puudu on pisut veahaldust, kui kõik ei toimu nö happy path viisil, kus tuleb täpselt oodatud andmekogum kontrollerisse. Üldmulje praktilisest testimisest on aga hea. Kontrollerite järgi sai hästi pildi ette, mis andmeid nad ootavad ja mida kontrollitakse nende juures ning neid polnud raske Postman-iga tööle saada.
Projekti struktuur, koodi ülesehitus ja kasutatud mustrid
Positiivsed aspektid:
Projekti üldine struktuur on loogiline. On eraldi projektid põhiosade jaoks - DAL, Domain, Identity, WebApi, DTO-ga seonduv projektis BL. Kasutatud on dependency injection-it Ninject näol. Andmebaasiga suhtlus kontrollerites toimub Service ning UOW objektide abil. UOW-s on defineeritud ilusti kõik vajalikud repositooriumid. Repositooriumites on kohati ka lisameetodeid ja mitte kasutatud ainult neid, mis tulevad projektipõhjaga kaasa. Kasutatakse liideseid objekti tüübina ja mitte implementatsiooni ennast. Kontrollerites võetakse vastu ja tagastatakse DTO-sid, mitte otse andmebaasi minevaid objekte. Olemitel „Domain“ projektis on kasutatud valideerivaid annotatsioone. Neid võinuks ehk lihtsalt rohkem olla.
Oleks võinud parem olla:
Äkki oleks võimalik see MVC projekt, mis WebApi sees on ja mõeldud API dokumenteerimiseks, tõsta eraldi kausta? See on tõenäoliselt lihtsalt templiidiga loodud, aga teeb taolisel kujul WebApi projekti struktuuri segaseks. Eriti häirib seejuures need MVC poolt kasutatavad frontend faile hoidvad kaustad nagu „Content“, „Views“ ja „Scripts“.
Domain, Interfaces ja DAL projektis võiks kasutada objektide kaustadesse jaotamist, et tekiks ülevaade seotud funktsionaalsusega klassidest. Lisaks on mõnel pool jäänud sisse palju väljakommenteeritud koodi (ja need pole TODO-d, mida kunagi ehk hakatakse kasutama). Siin oleks näiteks (tõenäoliselt A. Käveri projektipõhja jäänuk) DataBaseContext.cs, kus võinuks eemaldada „PK – string“ versioonis Identity olemite sektsioonid. Lisaks leidus pisemaid tähelepanematusi nagu DAL all on üks tühi klass ServiceMap.cs ning klassides on palju mittevajalikke „using“ direktiive – nende ebavajalike asjade eemaldamisel aitab tavaliselt IDE mõni tööriist.
Kokkuvõte
Üldmulje jäi veebiteenusest väga hea. On kasutatud aines õpetatud arendusmustreid ning rakenduse kihtideks jaotamist ning neist ka aru saadud. Arvestades, et tegemist on kaheliikmelise meeskonnaga, vastab veebiteenuse teostus kindlasti aine kodulehel ülesloetud nõudmistele.
Meeskond CoverMe retsensioon meeskonnale SPOT
Meeskonna eesmärk oli luua veebiteenus, mis võimaldab saada infot pakutavate treeningute kohta, sisestada ja kuvada tunniplaani andmeid, registreerida osalejaid tundidesse ning end sealt eemaldada. Samuti oli ette nähtud, et administraatorid saavad lisada, muuta ja kustutada kõike sprodiklubiga seonduvat ning treenerid ja spordiklubi esindajad saavad toimetada treeningutega seotud andmete sisestamise ja muutmisega. Andmebaasimudel on tehtud väga põhjalikult ning tabelite kirjeldused on samuti välja toodud.
Meie hinnangul on eesmärk põhiosas täidetud, realiseeritud on enamus kavandatud must-have funktsionaalsusest (välja on jäänud logimine). Loodud on veebiteenus, mis kasutab REST arhitektuuri ja ASP.NET MVC Web Api tehnoloogiat.
Veebiteenuse struktuur on üles ehitatud kihiliselt, mis võimaldab vajadusel süsteemi osasid lihtsamini muuta, täiendada ja vajadusel välja vahetada. Kihid on jaotatud järgmiselt:
BL - sisaldab DTO-sid ja nende koostamiseks vajalikke Factoreid. Samuti on siin Service klassid, milles on kirjas kõik päringud andmebaasist (Get mitmesugustes variantides, Add, Edit, Delete). Lisaks tavalistele CRUD meetoditele on tehtud ka spetsiifilisemad päringud , näiteks GetByIdForUser jne. Päringuid tehakse uow-de kaudu. Service’tele ja Factory’tele on loodud Interface’d.
DAL - kasutatakse EFRepositoryFactory ja EFRepositoryProvidery põhimõtteid. DbInitializeris antakse ette lähteandmete seed’imine. Repositooriumid on omaette kaustas, kuhu on lisaks EFRepository-st päritud meetoditele juurde kirjutatud palju erinevaid meetodeid funktsionaalsuse täiendamiseks.
Domain - andmebaasi mudelis on kokku 12 olemit, mis on nõuetele vastav. Üldine andmebaasimudeli ülesehitus on loogiline ning listid on algselt väärtustatud, mis tagab selle, et ei pea NullReference Exceptione kontrollima. Vajalikesse kohtadesse on annotatsioonid juurde lisatud ja nendega ei ole üle pingutatud, et süsteemi liiga kirjuks ajada. Tõstame esile asjaolu, et kasutatud on Base Entity’t, millest kõik ülejäänud olemid pärinevad. See ühtlustab rakenduse koodi ja on üldse väga hea mõte. Kasutatud on palju nullable tüüpi muutujaid, mis on antud juhul õigustatud, andes andmete sisestamisel paindlikkust, samas lisades mõneti riskantsust.
Interfaces - Kõikide repositooriumide jaoks on loodud ka interface´d. Samuti leidub seal UOW jaoks interface.
WebApi - Kokku on kasutusel 6 kontrollerit, milles on realiseeritud CRUD meetodid koos mõne spetsiifilisema meetodiga (näiteks GetFilteredForPeriod). Kontrollerid saavad oma sisu vastavatest service’itest. Identity rakendamiseks on kontrollerite meetoditel kasutatatud Authorize annotatsioone. Samuti on läbi mõeldud, et mõnda meetodit on autoriseeritud kasutama ainult “Admin”-kasutaja. Näiteks ainult “Admin”, saab salvestada treenereid andmebaasi. Kontrollerites on kenasti kasutatud erinevaid Http-staatuskoode, mitte ainult Ok(), vaid ka Forbidden(), NotFound() jne. Samuti kasutatakse edukalt sõltuvuste süstimist (Dependency Injection). Kasutatud on OAuth bearer token authentication’it.
Lisaks peame oluliseks märkida, et kood on kirjutatud heas stiilis, kõikjal inglise keeles, ei esine keelte segunemist. Paljudes kohtades oli kood kommenteeritud, kuid see tundus olevat ise kaasa tulnud. Meeskonna enda kommentaare ei paistnud.
Kokkuvõtteks võib öelda, et tegemist on väga hästi kavandatud ja realiseeritud veebiteenusega ja meeskonnaliikmete panus on olnud märkimisväärne, eriti arvestades seda, et tegemist oli vaid kahe liikmega.
