Talk:LLL

Retsensioon

Mulle tundub, et xml ei lähe kokku selle veebiteenusega, mida tahetakse teha. Võimalik muidugi, et tehtigi lihtsalt hetkel suvaline xml.

XML paistab muidu olevat mõistlik aga ma arvan, et 4-ndas dimensioonis ei oleks ma kasutanud <nimi> väljal atribuute. Jääb mulje, et seda tehti sellepärast, et tööülesanne ütleb järgmist: "Lisaks tuleb kasutada 3-el dimensioonil attribuute, mis on enamat, kui lihtsalt ID".

XML schemale otsa vaadata siis ma vaatan küll, et see on vigane. Miks käiakse üle mitu korda elemendid? Isegi Visual Studios automaatne schema tegemine ei tooda sellist asja, proovisime järgi. Või oskate öelda, miks nii tehtud on?

XSL faile on pandud 3 tükki, aga kõik tunduvad mulle koodi poolelt sarnased. Selle asemel oleks võinud lisada puuduliku XML faili formaadi muutmise XLSLi.

Samas kiidaks veebiteenuse kirjelduse kohapealt tiimi !

Meeskond PhoneBook

Vastus

Xml ei pidanudki veebiteenusega kokku minema. Ehk jah, tegime täiesti suvalise xmli. Schemas oli jah viga sees, kuna kasutasin automaatset schemat ja väike viga oli xmlis sees. Vabandan, et ise seda enne ei olnud märganud ja ära parandanud. Nüüd peaks schmea ok olema.

Retsensioonid veebiteenusele ja klientrakendusele meeskonnalt PhoneBook

Veebiteenus

Esialgu planeeritud teenuse ja rakenduse analüüs/kirjeldus on wikis päris asjalik, kuid selle asemel realiseeritud telefoniraamatu kohta puuduvad mingisugusedki kommentaarid. Õnneks kaitsmisel sai seda nähtud.

Andmebaasi tabelite loomiseks antud skript eeldab, et selle nimeline andmebaas on juba olemas. Väike ebamugavus, sellest sain üle. Rollid tulevad skriptiga kaasa, see meeldis.

Loodud tabelitest on näha, et saab luua erinevates rollides kasutajaid, kellel on igalühel kontaktid ja võimalus neid valikuliselt jagada mingis ajavahemikus. Näeb üsna kena välja, kuid:

• ei võimalda lisada uut tüüpi kontakte ilma andmebaasi ümber tegemata
• auditeerimise poole pealt ei jälgita, kes midagi loob/muudab/kustutab. Ilmselt ei peetud vajalikuks.
• kasutaja username maksimaalne pikkus on 12 tähemärki ja passwordil 15 tähemärki. Tekkis küsimus, et miks need piirangud nii karmid on.

Väljade andmetüübid on minu arvates üsna arukalt valitud.

Service class ja interface on millegipärast ühte faili kokku pandud, selguse mõttes võinuks need eraldi olla. Service klassil on lisatud atribuut [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)], ehk siis teenusest on korraga ainult üks instance. Miks?

Katsetasin teenuse funktsioone WCF Clientiga. Mõned tähelepanekud:

• Kõik meetodid töötavad ja annavad sobivates oludes vastuse.
• Ebaõnnestunud päringu korral ei saadeta mingit vastust. Võibolla õige teguviis, kuid test client ei suuda debug sessionit jätkata ning see jookseb kokku. Lihtsalt väike ebamugavus testijale või ka teenusele rakenduse arendajatele.
• Ükski meetod ei vaja eelnevat logini ja passworde hoitakse plaintext kujul. Sertifikaate ei kasutata. Bindinguks on WsHttpBinding, kuid security pole sisse lülitatud.
• Saab luua sama kasutajanime ja passwordiga kasutajaid. Login õnnestub neist vaid esimesena loodul.
• Kõikidel on vaba ligipääs kõikide kontaktidele. See ei ole probleemiks, kui ongi mõeldud teha ühine telefoniraamat kõikidele kasutajatele.
• Meeldis, et päringutes sai spetsifitseerida soovitud tulemuste arvu.

Kontaktide jagamise realiseerimiseks pole ilmselt aega jäänud.

Failide Auth.cs ning AuthData.cs põhjal võib arvata, et autentimise ja muu turvalisusega seonduva lisamine on plaanis olnud, kuid pooleli jäetud.

Userite / kontaktide salvestamine on pandud vastava andmetüübi kirjelduse faili, ülejäänud operatsioonid eraldi – andmetüübile vastavasse meetodifaili. Arvan, et oleks olnud loogilisem ka salvestamine ülejäänud meetoditega kokku panna.

Meetodeid on palju rohkem kui teenuses võimalik välja kutsuda, kaasa arvatud kontakti jagamise funktsionaalsus. Üldjuhul on kõik päringud korralikult kirjutatud, päris kõiki jupphaaval läbi töötama ei hakanud. Märkasin, et näiteks uue kasutaja salvestamisel kontrollitakse eelnevalt selle olemasolu ja vajadusel hoopis uuendatakse seda – väga tubli!

Kokkuvõttes on teenus planeeritud põhjalik ja olemasolevad osad tehtud üsna kenasti. Miinustena näen täielikku turvalisuse puudumist, teostatud funktsioonide vähest hulka ja mõningaid pisivigu. Andmete valideerimiseks ei tehta teenuse poole pealt midagi ja statistikat või kasutajate haldust ei eksisteeri.

Klientrakendus

Esimesena torkas silma WPF page-ide kasutamine. See on mulle kui kasutajale väga meelepärane. Ka ülejäänud kasutajaliidese disain on lihtne ja selge. Üks väike ebamugavus – login aknas pole defaultina username kastis kursor aktiivne ja enteriga ei saa login nuppu vajutada. Arvan, et enamikele kasutajatele oleks programmi selline käitumine ootuspärane.

Registreerimine toimib väga edukalt, lausa nii edukalt, et võib luua lõputul hulgal kasutajaid, kellel pole ei kasutajanime, passwordi ega emaili. Andmebaasis on need tühja stringina, ehk siis mitte null väljad, vältides edukalt teenuse/andmebaasi poolt kehtestatud piiranguid. Siinkohal võiks olla kontroll nii teenuse kui rakenduse küljes, kuid kahjuks pole kummaski.

Login on edukas tüüpkasutaja korral, kuid annab nullpointer exceptioni, kui üritada sisse logida mõne eelnevalt loodud vigase kasutajaga. Ka vale kasutajanime/parooli korral jookseb rakendus unhandled exceptioniga umbe.

WPF page-kontrollidega navigeerides (vasak ülemine nurk, nooled ja rippmenüü) sai peatselt selgeks, et nuppe vajutades luuakse kogu aeg uusi lehti, vanadele saab navigeerida rippmenüüst ning neis säilib ka eelnevalt sisestatud info. Kasutajana oleks oodanud, et liigeldakse olemasolevate lehtede vahel (login ja registreerimine). Koodi lähemalt uurides (nt. registreeri_page.xaml.xs) selgub, et ka teenusega luuakse kogu aeg uusi ühendusi. Jõudluse seisukohalt ei tundu see hea lähenemisena.

Nii search, browse kui add contact töötavad. Loomulikult saab lisada tühjade stringidega kontakte, nagu ka kasutaja registreerimise korral. Search näitab detailides enne tulemuse valikut mingit kuupäeva miinimumväärtust, see ei peaks seal ilmselt olema.

Mõne otsingu korral esines sama väärtuse topelt kuvamist, ka selectionina olid nad korraga aktiveeritud. Põhjust otsides seda esimese hooga ei leidnud, jätan selle arendajate hingele.

Enne sisse logimist sulgub programm ristist sulgedes edukalt, debug lõppeb. Peale sisselogimist see enam ei õnnestu, ka logout tehes jääb midagi mällu ja debug sessioon ei lõppe. Millegipärast jääb kliendi .exe jooksma (ka task manageris on näha). Koodi uurides on justkui igalpool vajalikes kohtades this.Close() käsud olemas, võibolla on asi visual studios endas.

Koodis kasutatakse mõistlikke muutujanimesid ning aeg-ajalt esineb ka mõni rida kommentaari funktsiooni kirjelduseks. Üldjoontes on ülesehitus selge. Rakendus ei ole mahult suur ning on hoolsa inimese käes isegi päriselt kasutuskõlbulik. Disain, nagu juba mainitud, on piisavalt hea. Eeskujulikust kasutusest kõrvale kaldudes tekivad probleemid, millega programm pole arvestanud. Mingit andmete valideerimist ei ole. Arvestades ajanappust selle rakenduse loomiseks, pean tulemust piisavalt heaks.

Retsensioon veebiteenusele ja klientrakendusele meeskonnalt Hello Kitty

Klientrakendus

Kui ma vaatasin koodi, siis panin kohe tähele, et on kirjutatud nii eesti keeles kui ka inglise keeles ja see tegi koodi lugemise kohe palju raskemaks. Suureks plussiks on, et kasutati WPF'i ehk mõeldi uute tehnoloogiate peale. Kuid sellega olid ka omad probleemid. Alguses oli raske aru saada kasutajaliidesest. Puudus igasugune valideerimine kasutaja sisestamise poole pealt. Sa võisid jätta täitmata nii kasutajanime kui ka parooli väljad ning registeerida, kuid hiljem ei saanud sedasi sisse logida. Minul jooksis selle peale rakendus kohe kokku.

Nagu ka kasutaja loomisel, puudus otsingul kontroll. Võisid sisestada tühja teksti sinna. Võibolla arendaja mõtleski, seega selle kallal norida ei saa.

Programmiga oli veel üks probleem. Kuna see jooksis vahete vahel kokku, sain süsteemi poolt veateateid. See näitab, et ei ole piisavalt kontrollitud, mida kasutaja teha saab.

Veebiteenus

Andmebaasi tabelite väljad on kirjutatud nii eesti kui ka inglise keeles. See teeb lugemise palju raskemaks. Andmebaasi poolt siis veel väike soovitus: kui rakendus peaks minema kasutusele ja populaarseks saama, siis oleks hea kasutada int asemel Guid primary key'na. Ja küsimus tekkis parooli turvalisuses - miks on parool tavalisel tekstikujul ning on lubatud nii väheste tähemärkidega. Enda kogemusest kasutan parooliks vähemalt 19 tähemärgilist parooli.

Koodi poolt siis faili nimed võiksid alata suure tähega. See on hea tava. Teiseks, kood võiks olla kommenteeritud, kuna osadest funktsioonidest ei saa kuidagi aru. Kolmandaks, funktsioonide nimed samamoodi: kui on avalik, siis võiks alata suure tähega. Tegelikult kõik funktsioonid võiksid alata suure tähega. Ja täpselt nii nagu andmebaasis, on funktsioonides kirjutatud eestikeelseid sõnu.

Üldjoontes programm töötas nende parameetritega, mis olid nõutud. Siiski vajaks kõvasti üle vaatamist ja parandamist ning eriti turvalisuse poole pealt.

Retsenseeris meeskond Hello Kitty.

Retsensioon XML'ile meeskonnalt Hello Kitty

Xml koha pealt vaadates paistis asi korras olevat. Ei oskagi väga midagi soovitada, kuidas paremaks teha.

XML schemat vaadates paistis olevat asi kuidagi vigane. Sama küsimus, mis on ka eelnevatel inimestel - miks käiakse mitu korda üle ühtesid ja samasid elemente.

Kui üldiselt vaadata, siis on asjad hästi tehtud. Arvatavasti inimene alles õppis selle projektiga. Tulevikus ehk enam samu vigu ei tee.