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.

Retentsioon kliendi ja veebideenus

Kliendi Rakendus

Kui ma vaatasin koodi siis panin kohe tähele, et on kirjutatud nii eesti keelselt kui ka inglise keelselt ja see tegi koodi kirjutamise kohe palju raskemaks. Suureks plussiks on, et kasutati WPF ehk mõeldi uute tehnoloogijate peale. Kuid sellega olid ka omad probleemid algus oli raske aru saada kasutaja liidesest. Ning puudusid igasugused kontrollid, et mida kasutaja sisestab kliendi rakendusse. Sa võisid tühja teksti jätta kasutaja nimeks ja ka parooliks ning registeerida, kuid hiljem ei saanud sedasi sisse logida. Minul jooksis rakendus kokku selle peale kohe.

Nagu ka kasutaja loomisel puudus kontroll otsingul võisid sisestada tühja teksti sinna, kuid ei oska öelda võib olla arendajad mõtlesidki, et asi peab olema sedasi.

Programmiga oli veel probleem kuna see jooksis kokku vahete peal sain süsteemi poolt veateateid. Et see näitab, et ei ole piisavalt kontrolle mida kasutaja teha saab.

Veebiteenus

Andmebaasi tabelitega samma jama, et on kirjutatud nii eesti kui inglise keeles ja mis teeb lugemise palju raskemaks. Andmebaasi poolt siis veel väike soovitus kui rakendus peaks minema kasutusele ja populaarseks saama siis oleks hea kasutada int asemele Guid primary key'ks. Ja küsimus tekkis parooli turvalisusest, miks on parool tavalisel kujul andmebaasis. Ja nii väike pikkus selleks jäetud enda kogemusest kasutan mina enda parooliks vähemalt 19 tähe märgilist parooli.

Koodi poolt siis Faili nimed võiksid algata suure tähega kuna see on hea tava. Teiseks kood võiks olla kommenteeritud kuna osadest funktsioonidest ei saa kuidagi aru. Kolmandaks funktsioonide nimed samma moodi kui on avalik siis võiks algata suure tähega tegelikult kõik funktsioonid võiks algata suure tähega. Ja täpselt nagu andmebaasis on funktsioonides kirjutatud eesti keelseid sõnu. Mis tegi jälle loetavuse raskemaks.

Aga muidu programm töötas nende parameetritega mis oli vaja. Kuid vajaks kõvasti üle vaatamis ja parandamist ning eriti turvalisuse poole lisamist.