Talk:Miisiiks

Veebiteenuse retsensioon meeskonnalt RaamatuRiiul

Meeskond Miisiiks on teinud projekti juhutööde pakkumise ja otsimise jaoks. Inimesed saavad vaadata ja lisada juhutöö otsimise ning pakkumise kuulutusi.

Esimese asjana panime tähele, et puudub README fail, kust saaks lugeda tutvustust projekti kohta ja seda, kuidas projekti tööle panna ning mida projekti tööle panemiseks vaja on. Antud aine kontekstis on küllaltki selge, kuidas midagi kasutada, aga laiemas plaanis vaadates oleks oluline see kirja panna.

Domeenimudelis on piisav arv olemeid, et täita kodutööks ettenähtud tingimused. Domeeni klassid on selged, hea ülesehitusega, väga põhjalikult kommenteeritud (millegi pärast on küll jäänud JobCategory kommenteerimata). Mudelite puhul on kasutatud korrektselt annotatsioone - enamik väljadele määratud korrektselt pikkused, kuid on ka mõned, millele on pikkus määramata jäänud, näiteks ContactType puhul string ContactTypeName on ilma pikkuse määranguta. Paika on pandud ka kohustuslikud väljad ja välisvõtmed. Meeldib, et osa domeeni klasside puhul on jagatud klass regioonide abil mitmeks osaks. Domeenimudelites on selgelt näha olemite vahelised seosed. Mudelites ühtegi sisulist viga ei leidnud.

Projekt on hästi struktureeritud, arhitektuuriliselt on kasutatud kihte. Kood on jaotatud eraldi BL, DAL, Domain ja WebAppi vahel. Kogu projektis on läbivalt klassidel ühtne kirjutamisstiil ja kaustade jaotus on loogiline ja kood on lihtsasti hoomatav.

DAL on jagatud neljaks erinevaks osaks ja need on tehtud väga põhjalikult. DAL’is on kasutatud repositooriume ja Unit Of Worki. Repositooriumite puhul on hea, et on tehtud universaalne repositoorium, mida teised kasutavad ja sellega lihtsustatakse oluliselt koodi. BL all asuvad DTO’d, Factorie’d, Interface’d, Service’d. Service’te puhul on kasutatud Unit Of Worki ja Factory’eid.

Veebiteenust käima pannes ja toimimist katsetades märkasime, et niisama ei saa ligi kõikidele api kontrolleritele. Uurisime api kontrollerite koodi lähemalt ja nägime, et osa neist on kaitstud kasutaja autentimisega. Kuna README fail on puudu, siis ei leidnud ka infot, mismoodi neid kasutada üldse saaks. Võtsime ühendust projekti autoritega ja saime teada, et tuleb kasutajaga sisse logida ja siis saab nendele apidele ka ligi.

API puhul leidsime mitmeid asju, mis ei tööta ootuspäraselt. Post on ainult asünkroonne, Get ja GetById on mingil põhjusel mitte asünkroonsed. Hetkel saab mitmeid asju lisada suvaliselt, näiteks kui reklaami lisada, siis saab suvalist kasutajanime panna, kui just ei ole sisse logitud mõne teisega. Muutmise puhul on jällegi ilusti kontrollitud, kas on ikka õige kasutaja. Sama probleem on ka AdvertisementPicture puhul – saab lisada suvalise kasutaja reklaamile pilte. Järgmiseks avastasime, et AdvertisementDTO sees on UserName ja seda saab täiesti avalikult GetAll’ida, mis ei tohiks aga nii olla. Segaseks jäi ka see, et miks on reklaamide saamine ApplicationUser kontrolleris. Täitsa hästi on tehtud Contacts kontroller, eriti GetAllContacts. Seal tagastab automaatselt ainult need kontaktid, mis kuuluvad hetkel autoriseeritud kasutajale ja see on väga hea. Id järgi ei kontrollita aga, et kontakt, mida küsitakse, kuuluks kasutajale. Samuti probleemne koht on see, et lisada saab kontakti suvalisele kasutajale.

Projekti visioon on kergelt segane, ei tule hästi välja. Vaatasime, et JobCategory vajalikkust me ei mõista, seda ei kasutata justkui kuskil. Sõnumite kohta võib positiivsest küljest öelda, et saadetud ja kätte saadud sõnumid on ilusti turvaliseks tehtud, aga halb on jälle see, et Id järgi turvalisust tehtud ei ole. Sõnumeid saab millegi pärast lisada suvaliste inimeste vahele. Kui sõnumeid kustutada, siis sõnum kustub ära nii sõnumi saatjalt kui saajalt, võimalik, et see ongi tahetud nii teha, aga tasuks võib-olla üle mõelda. Lisaks vaatasime, et IDE ütleb, et Message Delete ei kontrolli tegelikult kasutaja identiteeti. Konto loojal on ebapiisav tagasiside, vähemalt parooli keerukuse kohapealt.

Meie meelest oleks võinud Security kontrolleri sisu Service’i all olla, aga see pigem maitse küsimus. Projektile on lisatud Swagger. Muidu kõik töötab ilusti, aga Swagger on täielikult kommenteerimata. Paremaks testimiseks oleks meeldinud, et programmi esmasel käivitusel ka mõned andmed andmebaasi juba lisataks. See pole aga otseselt vajalik, igaüks saab ka ise lisada ja siis testida. Põhilised ContactType’d oleks võinud juba näiteks lisatud olla.

Kokkuvõtvalt jäi meile tööst üsna hea mulje, vaeva on nähtud, kuid tundub, et tööde jaotusega on osa meetodid poolikuks jäänud. Paljud asjad on aga väga hästi ja korralikult tehtud.

Retsenseeris meeskond: RaamatuRiiul

Klientrakenduse retsensioon meeskonnalt RaamatuRiiul

Meeskond Miisiiks on teinud projekti juhutööde pakkumise ja otsimise jaoks. Inimesed peaksid saama vaadata ja lisada juhutöö otsimise ning pakkumise kuulutusi. Eesmärk oli, et kuulutustel oleks võimalik ära märkida piirkond, kus otsitakse tööd/töötajat. Kuid veebilehel puuduvad APIs loodud võimalused hinnata kasutajakontosid ja lisada kommentaare. Samuti puudub võimalus kuulutuse lisamise märkida ära, kas antud töö eest pakutakse tasu või mitte. Kuulutuse vastuvõtmise vastuvõtmiseks peaks saatma kuulutuse loojale teade kontaktandmetega.

Erinevalt veebiteenusest, on siin README fail olemas, kuid see piirdub Angulari standard loominguga. Seega ei ole õpetust, kuidas rakenduse API aadressi muuta ja tööle panna kui Visual Studio ei käivita APIt täpselt sama pordiga juhtumisi. See tuleks kindlasti juurde lisada. Klientrakendus on tehtud Angulari peal ning kliendis on kasutatud korralikult MVC arhitektuurilist ülesehitust.

Realiseeritud on sõnumite saatmine, kontaktid, reklaamid, kasutajate registreerimine ja sisse logimine. Avastasime, et andmebaasi loomata jätmise korral on status 500 „handlimata“, selle errori tekitamisel tuli välja lehetäis „undefined“ teksti. Kuid muus osas oli uute kontode registreerimine ja sisse logimine kõige täielikumad osad antud klientrakenduses.

Reklaamide lisamise juures meeldib meile see, et reklaami sisu kontrollitakse ja näitab selle järgi, mitu tähte saab sisestada. Nagu ka veebiteenuse retsensioonis mainisime, et puudub andmebaasi initsialiseerimine ning see annab tunda ka klientrakenduse juures. Selle tõttu on näiteks reklaami kategooria drop-down list algselt tühi. Lisasime testimiseks manuaalselt kategooriaid ja sel juhul töötab ilusti, mis on vähemalt hea. Aga enne kaitsmist oleks niikuinii hea lisada andmebaasi juba mõned andmed ja miks mitte teha seda andmebaasi initsialiseerimise kaudu.

Mitmed asjad, mida veebiteenust vaadates segaseks jäid, said nüüd seletuse. Näiteks oli meil segane, kuidas ja milleks JobCategory kasutatakse. Nüüd nägime, et see käib Advertisement’i külge ja see on siiski vajalik, kuigi meie oleks pannud sellele nime, mis paremini teda Advertisement’iga seoks.

Mitmed probleemsed kohad saavad alguse juba veebiteenuse poolest. Näiteks kuna domeenis mõnel väljal olid jäänud pikkused määramata, siis ka klientrakenduses saab neid lõputu pikkusega sisestada. Selliseks näiteks on string kujul reklaami asukoht, mille saab lisada lõputu pikkusega.

Kontakti puhul muutmine (edit) ei tööta, kuid kustutada (delete) saab. Katsetasime enda kasutaja meili ära kustutamist, aga seda ei lasknud, mis on hästi, kuid siis ei tohiks seda nuppu seal samuti olla. Kontakte saab ilusti lisada, aga näiteks ainus kontaktitüüp on e-mail ja kliendi kaudu puudub võimalus teiste kontaktitüüpide juurde lisamiseks.

Kui sõnumi lehele hakata sõnumit saatma, siis lubatakse kirjutada pikemat pealkirja, kui tegelikult aktsepteeritud on. Saadetud kirjadele saab vastata ehk iseendale kirjutada.

Kui reklaami tahta muuta (edit), siis väljad ei ole juba automaatselt olemasoleva infoga täidetud. Proovisime ka muuta teise lisatud reklaami. Reklaami muuta justkui saab, aga õnneks andmebaasi see siiski ei salvestu, aga muutmise koht teise inimese reklaamil tuleks ikkagi ära võtta. Reklaami otsimine (search) töötab väga hästi ja lahedalt, dünaamiliselt ilma nuputa. Reklaamile vajutades sõnumi saatmine ei tööta, klientrakendus ise midagi ei ütle ega kuva, aga konsoolis annab tagasi 500 errorit. Enda kuulutuse muutmine kahjuks samuti ei tööta, võimalik, et selletõttu, et ei anta kaasa kasutajanime. Kuigi see meie arvates halva API kasutaja kontrolli mehhanismide süü rohkem. Enda lisatud reklaame hetkel kustutada ei saa, arvatavasti on see API poolne probleem.

Suurim kahtlusi tekitav funktsionaalsus on meie jaoks see, et MyContacts on minuga kontakteerumise vahendite jaoks, aga meil pole õrna aimugi, kuidas ja kust kaudu teised kasutajad neid nägema peaks.

Kokkuvõttes võib öelda, et ükski edit hetkel ei tööta. Delete töötab ainult ise lisatud kontaktidele ja lisamine töötab kõigele. Väga hästi on tehtud registreerimine ja sisselogimine, need töötavad ilusti. Seega klient loob API teel uue kasutaja ja saab sisse logides vastava tokeni, millega ligi pääseda API’le.

Üldiselt näeb klientrakendus välja kena ja täitsa responsive, aga mõni osa on siiski katki ja oleks hea, kui neid veel veidi täiustaks ja parandaks. Loodetavasti meie retsensioonist on ka selles osas abi. Lisaks puudub klientrakendusel ka dokumentatsioon, aga selle jõuab veel enne kaitsmist lisada. Kasutaja mugavuse pool tundub rakendusel täitsa hea.

Retsenseeris meeskond: RaamatuRiiul

XML retsensioon meeskonnalt RaamatuRiiul

XML-i alguses puudub tutvustav tekst, mille kohta täpsemalt XML on tehtud. Esimese asjana lasime XML-i validaatorist läbi ja vigu sellega ei leidnud. Atribuutidena on ainult ID, seega ei ole atribuute piisavalt nõuetele vastamiseks. Sügavus vastab nõuetele. Hästi on kasutatud CDATA-t. Piltide kasutamine on hea mõte. Meile tundub, et UserName-i on kasutatud liiga julgelt, nii reklaamil kui kontakti küljes. Võiks ainult ühe korra näidata, sisemistes tasemetes pole enam vajalik. Meil jäi natuke tunne, et antud XML ei täida ühtegi mõeldavat reaalset vajadust. Näeb välja nagu masina poolt automaatselt genereeritud XML, millele on lisatud näidisandmed sisse.

XML skeemifail on täitsa hästi tehtud. Skeemifail valideerub, tundub, et on pandud automaatne versioon. HTML-iks transformeerimine on väga ilus. For each tsükleid on piisavalt ja kuvatakse isegi pilte, mis teeb väljanägemise eriti kenaks.

XLS to XML on põhjalikult tehtud. For-each tsükleid on mitmeid, nii nagu olema pidi. Transformeerimine teeb peaaegu samasuguse struktuuriga XML-i nagu esialgne. Kahjuks ei leidnud me koodist ühtegi if või muud for eachist erinevat lauset. Kontaktil on jälle UserName lisatud, ei kasutatud võimalust kärpida UserName-e. Oleks võinud teha midagi erinevat ja huvitavamat esialgsest XML versioonist.

Väga hästi on näha, et teema on põhjalikult läbi töötatud ja korralikult kõik valmis tehtud. Aga natuke reaalelulist poolt on jäänud puudu. Antud XML-l on infoliiasus ID-de ja kasutajanimede kordusest.

Retsenseeris meeskond: RaamatuRiiul