Talk:Givela

XML retsensioon Double Trouble meeskonna poolt

Kõigepealt mainiks ära selle, et meeskonna Givela idee on väga huvitav ja kindlasti koguks populaarsust. On näha, et meeskond on teinud põhjaliku eeltöö selleks et projekti hea funktsionaalsus oleks tagatud. On loodud andembaasi tabel ja välja kirjutatud vaated, mis saavad projekti töös olema. XML on väga konkreetne ning sisaldab nõuetele vastavalt vähemalt neli dimensiooni. Iga elemendi juures on kasutatud on ka CDATAt, mis on samuti väga hea. Nõuetes oli ka kirjas, et kasutusel peavad olema attribuudid, mis on rohkem kui id, kuid neid ma kahjuks siin failis ei näe. Lisaks olemasolevale lisaksime enda poolt ka mingisugune algelise hinna, mille kasutaja saab sisestada ja ostja või siis nö annetaja otsustab ise, kas ta tahab seda annetussummat suurendada või mitte. XSD tundub korras olevat. XSLT faili on meeskonnal vaid üks, kuid kriteeriumiks oli vähemalt kaks transformatsiooni. Positiivne on, et kasutatud on rohkem tingimuslauseid kui oli nõutud ning et kasutatud on ka CSSi.

Retsenseeris meeskond DoubleTrouble.

Retsensioon veebiteenusele (Travo 2.0 poolt)

Givela serveri ülesseadmine on ülimalt lihtne, kui taustsüsteem on juba vastavalt konfigureeritud (töötav Microsoft SQL server, kompileerimiseks vajalikud .NET teegid olemas). Andmebaasi täitmisel näidisandmetega tekkis logisse küll üks välisvõtme konflikt, kuid see ei takistanud edukat demoks piisavate näidisandmete loomist.

Veebiteenuse süsteem on jaotatud nelja kihti: BLL, DAL, Domain ja Web-API. Käin läbi iga kihi eraldi.

Web-API kiht

Siin kihis peaksid asuma kontrollerid ja üldine API (veebiteenuse) konfiguratsioon. Koheselt torkab silma, et lisaks eeltoodule on siia pandud ka veebipõhine (AngularJS baasil) klientrakendus. Kiht on ka põimitud ASP.NET MVC tehnoloogiaga. Lühidalt tähendab see seda, et Web API kiht on segu kolmest tehnoloogiast: API teenusest, veebipõhisest klientrakendusest ja ASP.NET Web MVC-st (mille ainus reaalne ülesanne antud juhul on CSS ja JavaScript failide nimistute automaatne loomine (MVC enda tehnoloogiaid ei kasutata ja tegemist on puhtalt Angularil põhineva SPA-ga)). Siinkohal mainin, et samasse ämbrisse astusin eelmine aasta Meeskond: Travo projektiga.

Web API puhul leiavad reaalset kasutust neli kontrollerit: Bid-, Charity-, Product- ja AccountController. Edukalt on tööle saadud küpsistel põhinev autentimine ja sessioonihaldus (tokeni eluea pikkuses). Autoriseeritavad endpointid töötavad vastata annotatsiooniga. See on ilmselt kõige keerukam projekti osa ning on antud projektis edukalt funktsioneerima saadud.

Domain kiht

Siin asuvad mudelid on hästi kirjeldatud ning on tõrkeid takistavate annotatsioonidega.

BLL kiht

BLL kihis on jälgitud eeskujukalt Servicite loomise ja DTO-de tagastamise loogikat. DTO-d luuakse läbi tavapärase Factory klassi kasutuse. Kihi ülesehitus on eeskujulik; ainus norimiskoht oleks see, et Factoryd võiksilt vabalt olla static klassid.

DAL kiht

DAL kihis asetseb ootuspäraselt EntityFrameworkile vastav DbContext klass ja migratsioonid. Kasutatud on ka repository patternit. Repository pattern on realiseeritud korrektselt, luues igale repositoryle vastavat interfacei, mis võimaldab suuremat koodi eraldatust ning tõstab testitavust. Küll aga on näha, et üleminek pole veel lõpule viidud, kuna repositorydes asuvad vaid meetodid kõikide olemite tagastamiseks. See peegeldub ka vastavates service klassides.

Kokkuvõte

Kokkuvõtvalt öeldes on veebiteenuse struktuur hea ning lausa eeskujulik. Tööle on saadud peamised funktsionaalsused: kasutajate haldus ja kasutajatele mõeldud sisu haldus. Selle kõige realiseerimiseks on kasutatud nelja kihti, kuhu on olnud plaan implementeerida service ja repository mustritega andmete lugemine ja jäädvustamine. Töö on veel poolik, nagu on kinnitanud ka projektijuht, kuid seni tehtud töö on suures mahus siiski äärmiselt pädev ning ollakse kindlasti õigel teel.

Kõike suuremaks murekohaks on Web API kiht, kuhu on kokku keedetud supp kolmest erinevast tehnoloogiast: ASP.NET Web API-st, ASP.NET MVC-st ja AngularJS klientrakendusest. Siin tuleks teha kerge puhastus, mille käigus oleks mõistlik eemaldada ASP.NET MVC täielikult ning tõsta AngularJS klientrakendus eraldi projekti (kausta). Kui viia projektis pooleliolevad üleminekud (näiteks repositoride ja service klasside korrektne rakendus) lõpuni ning teha suurpuhastus Web API kihis, siis oleks veebiteenuse osa maksimumpunktide vääriline.

Retsenseeris Meeskond: Travo 2.0.

Retsensioon klientrakendusele (Travo 2.0 poolt)

Givela klientrakendus on kirjutatud AngularJS baasil. See ei nõudnud ülesseadmiseks midagi erilist, kuna on integreeritud Web API projekti solutionisse (mis minu arvates oleks suuremate projektide puhul negatiivseks küljeks).

Analüüsin koodi erinevate aspektide põhjal, mida pean oluliseks.

Kasutajaliides (UI & UX)

Kuna antud projekti eesmärgiks ei olnud vägeva kasutajaliidese ja -kogemuse loomine, siis siinkohal ma pikalt ei peatu. Kasutajaliides on lihtne ning on näha, et tegemist on prototüübiga. Vajav funktsionaalsus töötab ja on ilma kriitiliste vigadeta kasutatav. Samas leiab ka kiiresti mitmeid kohti, kus parandusi võiks teha.

Siinkohal tuleks välja tuua aga ka suure plussi: veebileht on täielikult responsive ning mitmekeelne. Mad props for that.

Koodi struktuur ja edasiarenduse võimaldatavus

Antud AngularJS projekti struktuur on eeskujulik. Kaustade struktuur on lihtsasti loetav ning isegi esmakordsele vaatajale arusaadav: kõik funktsionaalsused on koondatud vastava nimedega kaustadesse. Näiteks 'common' kaustast võib leida ühised singletonid ja/või static klassid nagu 'identity' või 'notifier', mille eesmärkides on vastavalt autentimise haldamine ja kasutajaliideses teavituste kuvamine. Samamoodi on koondatud eri vaated vastavatesse kaustadesse (näiteks 'login' või 'bid' vaated). Vaadete kasutadest leiab MVC-le vastavalt vaate enda ning ka sellega seonduva kontrolleri (vajadusel ka vastav RESTful resource factory). Klientrakenduse liigutamine ja muutmine on lihtne, kõige üldisemad seaded (näiteks tõlked ja routing) on koondatud peafaili 'app.js'. Kui norida, siis tõlked võiks olla eraldi failis, kuid sellise väikesemahulise projekti puhul ei ole see probleemiks.

Koodi puhtus

Kood on pigem lihtsasti loetav ning eeskujulikult trepitud. Kui tegemist oleks production koodiga, siis ma oleks pisarates, kuna sisse on jäetud palju väljakommenteeritud kooditükke. Õnneks on tegemist arendusjärgus oleva rakendusega, mis on pigem mõeldud API töövalmiduse demomiseks kui turule minemiseks. Kui mõttesilmas kustutada väljakommenteeritud koodijupid ära, siis jääb alles puhas kood, kus moodulite ja funktsioonide nimed on arusaadavad ja koodi võib ilma pikema konsulteerimiseta ka kolmas osapool edasi arendada.

Kokkuvõte

Kokkuvõtvalt võib öelda, et klientrakenduse ülesehitus on eeskujulik ning kood on loetav ja hallatav. Kasutajaliides on lihtne ning vastab prototüübi staatusele, lisapunkte annavad kindlasti lehekülje mitmekeelsus ja responsiveness. Demova klientrakenduse jaoks on see pädev ning kuna kood on niivõrd puhas, siis on seda lihtne ka produktsioonikõlbulikuks lahenduseks refaktoreerida. Ainus negatiivne asi on jällegi see, et kood asub Web API layeris (aga see on minu arvamus). Max punktid, läheb!

Retsenseeris Meeskond: Travo 2.0.

Retsensioon veebiteenusele meeskonna Aloha Snackbar poolt

Idee

Teha rakendus, kus inimesed saavad oma asju annetada on perspektiivikas ning täidab nõuet, et antud teenus võiks olla kasutatav ka ärilistel eesmärkidel. Lisaks on projekile lisatud paarisõnaline kasutusjuhend mockandmete loomiseks, mis teeb projekti käivitamise ja katsetamise mugavaks.

Veebiteenus

Projekti ülesehitus on selge kasutades korrektseid arendusmustreid.

Veebiteenus on jaotatud nelja kihti: BLL, DAL, Domain ja Web-API. Üldiselt on kood puhtalt kirjutatud, kasutades selgeid ning arusaadavaid nimesid. Vajadusel on lisatud selgitavad kommentaarid.

Positiivne

• Domain kihis on mudelitele lisatud tõrkeid takistavad annotatsioonid, mis on olulised, et mitte raisata ruumi luues code first admebaasi.

• BLL kihis on jälgitud korrektseid mustreid luues vastavad DTO klassid, Service´id ja Factory´id.

• DAL kihis on samuti kõik korrektsed elemendid. Lisatud on migratsioonid ning seed, mis võimaldab katseandmeid kergelt luua.

• WebApi´sloodud controllerid väljastavad vajalikke veakoode.

• Korrektselt töötab ka kasutaja autentimine ning nagu nõutud toetab mitme kasutaja võimalust ning nende haldamist.

• Ebavajalik fluff (tegevused, mida projekt ette ei näe. A la kustutamine) on controlleritest jms välja jäetud.

Puudused

• Domain tundus natukene kõhnavõitu olevat -- nõue kasutada vähemalt 9 olemit ei ole täidetud. Mõningad olemid oleks saanud n-ö katki ja keerulisemaks teha -- teha eraldi tabelid kontaktide ja nende tüüpide jaoks. Kui arv pole ikka täis, käituda veel mõne tabeliga nii.

• Vähene loogika testimine, kuna leidsime vea uute annetuste lisamises. Uut annetust lisades ei saa määrata miinimumannetust (ka ei saa miinimumannetust adminpaneelist muuta).

• Ninject confimine on jäänud poolikuks. Lisaks tundub üksik koodirida Ninjecti RegisterService all mõttetu olevat.

• Mõningad controllerid I ole täielikult BLL teenuste peale üle läinud -- kohati on näha otse database contexti kasutamist controlleris.

• Töö on poolik. Tehtud on ainult mõned üksikud service´id. Võiks saada tooteid veel järjestada, otsida jne.

Kokkuvõte

Veebiteenuse pool on üldiselt vastavalt õpetatule ülesse ehitatud. On näha korrektseid arendusmustreid. Kahjuks on nende kõrval näha ka automaatselt genereeritud koodi(andmebaasi konteksti kasutamine otse kontrolleris). Tööl on palju potensiaali ning võimalusi edasiseks arenguks.

Retsenseeris meeskond Aloha Snackbar

Klientrakenduse retsensioon meeskonna Aloha Snackbar poolt

Klientrakendus

Givela klientrakendus on kirjutatud AngularJS baasil. Anroid rakendust oli väga keeruline käima saada, kuna puudus kasutusjuhend, mis oli nõutes kirjas.

Positiivne

• Prototüübi kohta on kasutajaliidese disain sobiv, lihtne ning selge. Põhifunktsionaalsus töötab ning suuri vigu ei leidnud.

• Veebileht on fully-responsive ning rakendus töötab ideaalselt eriseadmetel, mis on tänapäeva ärilist aspekti silmas pidades MUST nõue.

• Kahekeelsus annab lisaväärtust antud klientrakendusele tuues kaasa lisaväärtust tootele ning laiendades kasutajatebaasi.

• Koodis on kasutatud selgeid nimesid ja erinevad osad on liigitatud eri kasutadesse, mis suurendab kogu porjekti arusaadavaust ning loetavust.

• AngularJS projekti struktuur on selge ja arusaadav.

Puudused

• Rakenduse disainil on algeline, palju arenguruumi. (Nt. näidata kõik pakkumisi väikselt ühel lehel)

• Samuti on sümbolite valik kasutajale segane. (nt. lipp ilma värvideta ei seostu keelevalikuga)

Kokkuvõte

Kokkuvõtteks ütleksime, et klientrakenduse ehitus on korrektne ja arusaadav. Kasutajaliides vastab pigem prototüübi staatusele, kui valmis projektile. Kood on üleüldiselt puhas ning kergesti loetav, mistõttu on seda ka kerge edasi arendada ükskõik, mis arendajal. Rühm on teinud head tööd ning projekt täidab etteantud nõudimised

Retsenseeris meeskond Aloha Snackbar