Talk:Meeskond: Fontastic: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Ssaks (talk | contribs)
Gvali (talk | contribs)
 
(7 intermediate revisions by 2 users not shown)
Line 34: Line 34:


Koostas: [[Meeskond: Spooky Scary Skeletons]]
Koostas: [[Meeskond: Spooky Scary Skeletons]]
== Veel üks retsensioon prototüübile  ==
Meeskonna Fontastic prototüübi puhul on tegemist lihtsa WPF-i rakendusega. Projekti struktuur on selge ja loogilise ülesehitusega - kasutajaliidese ja DAL-i osa on omavahel eraldatud. Projektis on ka TestIt nimeline programm, mis sisu järgi peaks olema midagi ühiktesti laadset. Kohane on mainida, et Visual Studio sisaldab ühiktestimise võimalust ja seega saab vajadusel ka korralikke teste mugavamalt kirjutada.
Funktsionaalsuse poole pealt vastab prototüüp valdavalt wikis olevale prototüübi kirjeldusele ja analüüsile. Fontide nimekirja uuendamise probleemile on meeskond Spooky Scary Skeletons oma retsensioonis juba tähelepanu juhtinud. Iseenesest on seda probleemi lihtne parandada ja prototüübi puhul ei ole see ka oluline puudujääk. Samas oluline erinevus wikis oleva prototüübi kirjelduse, analüüsi ja prototüübi funktsionaalsuse vahel on fondile tagide lisamises. Nimelt paistab, et ühele fondile ei ole võimalik mitut tagi lisada, kuid prototüübi kirjelduse (“''[---] Fondi peale klikkides on võimalik tage lisada või kustutada (alumises servas). [---]''”) ja analüüsi (“''[---] Ühel fondil võib olla mitu tagi - näiteks #looks-good-on-red või #web-friendly. [---]''”) järgi peaks see võimalik olema.
Prototüübi koodis ei ole kasutatud MVVM arhitektuurimustrit, kuid nii väikese rakenduse puhul olekski see praktikas võib-olla üleliigne abstraktsioon. Samas muudaks MVVM arhitektuurimustri kasutamine kasutajaliidese osa arendamise paindlikumaks ja mis õppeaine kui teooria omandamise seisukohalt kõige tähtsam - annaks arendajatele kogemuse sellise arhitektuuriga.
Koodis on fontide, tabide ja tagide teenused eraldi klassides, kuid kõik need klassid ja neis olevad meetodid on märgitud static’uks. Selline lähenemine on kahtlemata mugav ja ehk isegi ülemäära laisk, kuid OOP-i seisukohalt oleks mõnevõrra ilusam kasutada näiteks [https://en.wikipedia.org/wiki/Singleton_pattern singleton’i mustrit].
Kokkuvõttes prototüüp töötab ja mõnede eranditega vastab analüüsis ja kirjelduses toodule.
Retsenseeris [[Meeskond: Nocturne No. 20 in C-sharp Minor]]
== Silduri retsensioon prototüübile ==
Retsenseeris meeskond [[Sildur]]
Meeskonna „Fontastic“ prototüüp valmis 13.12.2015 ning lahendusfaili importimine Visual Studiosse möödus komplikatsioonideta ning lisaks töötas ka kompileerimine.
Rakenduse loomiseks on kasutatud WPF tehnoloogiat. Rakenduse käivitamisel kuvatakse keskmise suurusega aken, milles põhivaade on jagatud erinevate „tab“-ide ehk lipikute vahel. Lipikuid on 3 tükki nimedega „Default“, „Piret“ ja  „Erik“. Tabi sees päises on 2 tekstikasti, millest üks on kasutatud fondi otsinguks ning teisel kuvatakse 4 tähte valitud fondis. Lisaks on kahes veerus loendikastid, milledest esimeses kuvatakse fontide nimekiri ning teises nö fontide siltid. Fontidele siltide loomiseks on vaate alumises osas on tekstikast tekstikirjutamiseks ja 2 nuppu siltide järgi nimekirja filtreerimiseks ja filtri eemaldamiseks.
Üldmulje rakendusest on hea. Selle kasutamisel kõik nupud funktsioneerisid ja töötasid, välja arvatud „Example text“ kastis näidisteksti uuendamine uue fondi valimisel. Väga hästi oli realiseeritud siltide lisamine ja kustutamine – tekstikasti tuli kas tekst juurde kirjutada või ära kustutada.
Rakenduse suurimaks miinuseks on selle lihtsus – kasutatakse ainult ühte põhivaadet, millel andmeid kuvatakse. Lisaks, ei ole tabide loomine kasutajate järgi hea mõte, kui kasutajate arv peaks suurenema.
Tabide asemel tuleks pigem kasutada muud lahendust kasutaja valimiseks. Nimelt, kui kasutajate arv läheks andmebaasis suureks, siis ei oleks võimalik enam "õiget" tabi üles leida. Samas, kasutajate nimekiri loodi automaatselt rakenduse käivitamisel – ka see on väga positiivne, sest mõningate meeskondade prototüübid lõpetasid sellel hetkel töö, kui andmebaasi ei leitud.
Rakenduse kood on kirjutatud mingis mõttes omapäraselt. Ühest küljest ei ole kasutatud vaatemudeleid, kuid see-eest on kasutatud „binding“ funktsiooni näiteks fontide siltide nimekirja kuvamiseks või fontide nimekirja kuvamisel. Samas, jäi binding tegemata „Example text“ kastile, mistõttu ei muutunud ka näidistekst fondi valimisel. Teisest küljest ei ole kasutatud ka BLL tehnoloogiat otsingute sooritamiseks ning service ehk teenindus andmebaasiga ühendumiseks asus DAL moodulis „FontasticDB.cs“ klassifailis.
Kokkuvõtvalt võib öelda, et „Fontastic“ meeskonna rakenduse prototüüp oli viimistletud pea viimse detailini. Ainsaks miinuseks on vaadete vähesus, sest muudetakse ainult tabide arvu vastavalt kasutajate arvule ning kuvatavate andmete hulka. Põhivaade on muutumatu.

Latest revision as of 21:12, 9 February 2016

Retsensioon analüüsile

Käesolev retsensiooni on koostatud meeskonna Fontastic analüüsile fontidest ülevaate saamiseks ja nende haldamiseks loodavale töölaua rakendusele. Analüüsi retsenseerimisel on lähtutud juhendis “Kodutöö aines “Programmeerimine CSharp keeles” (2015)” projekti analüüsi kohta toodud nõuetest ning võrreldud analüüsi vastavust nendele.

Rakenduse eesmärk on analüüsis selgelt välja toodud. Leitud on aktuaalne probleem, seda on põhjalikult käsitletud erinevatest aspektidest ja esinemisvormidest lähtudes ning selle põhjal koostatud nägemus lahendusest. Siiski ei saa nõustuda väitega, et kuigi Adobe on graafikadisaini tarkvara tootmises peaaegu monopoolses seisus, oleks tema poolt pakutav Typekit justkui ainuke fontide halduse lahendus. Fontide halduse tarkvara käsitlev Wikipedia lehekülg pakub üle 30 alternatiivi, millega oleks meeskonnal ideede kogumiseks ja lihvimiseks kindlasti mõistlik tutvuda. Samuti on Google’il veebipõhine fontide halduse lahendus Google Fonts.

Analüüsis on toodud loodava rakenduse funktsioonina põhiliselt erinevad viisid fontide kuvamiseks, otsimiseks ja valimiseks. Seoses funktsionaalsusega jääb arusaamatuks, mida täpsemalt mõeldakse “[---] Fonte kuvatakse kaartidel, mida on ühes reas näiteks 4 tükki [---]” all. Kas mõeldud on näiteks reas olevaid pilte või hoopis tabeli rida. Üldjoontes võib öelda, et analüüsi eesmärgis toodud probleemi pakutud funktsionaalsus tõenäoliselt lahendab ehk pakub süsteemis installeeritud fontidest parema ülevaate ja võimaluse neid organiseerida.

Sellegipoolest võiks kõnealune rakendus tegeleda ka tegelikult fontide haldamisega ehk kindlasti peaks olema võimalik muuta konkreetseid fonte vastavalt vajadusele aktiivseks ja mitteaktiivseks, nt. liigutades neid operatsioonisüsteemi fontide kataloogi ja rakenduse hallatava fontide kataloogi vahel. Selline vajaduspõhine fontide lülitamine aitaks lahendada ka analüüsi eesmärgi all käsitletud n.n. 500 fondi ja pika valiku kerimise probleemi - aktiivsed oleks ainult konkreetse graafikaprojekti või dokumendi teostamiseks vajalikud fondid. Samuti oleksid fonte kasutavad rakendused kiiremad, kuna neil puuduks vajadus kõigi süsteemi fontide laadimiseks, milleks võib suure süsteemi fontide kataloogi puhul kuluda väga palju aega.

Seoses võimalike takistustega rakenduse arendamisel on meeskond toonud välja ühilduvusprobleemi erinevate Windows’i versioonidega. IT-maailmas kahtlemata väga tavapärane olukord ja probleemi ilmnemisel on tõenäoliselt mõistlik keskenduda ainult paarile viimasele Windows’i versioonile.

Lõpetuseks peatume ka formaalsetel nõuetel. Kodutöö juhendi järgi peaks andmebaasis olema vähemalt 6 andmebaasi tabelit. Meeskonna poolt koostatud analüüsi ja projekti logi põhjal võib järeldada, et plaanitakse kasutada andmebaasi, kuid kahjuks puudub otsene kirjeldus, kas üldse ja kui, siis kuidas, seal fontide nimekirja ning muid tegevustega seotud andmeid hoidma hakatakse. Ülevaatlikkuse huvides oleks võinud andmebaasi skeemi olemasolul lisada ka selle analüüsi juurde.

Kodutöö juhendis on toodud ka nõue, et analüüsi minimaalne sõnade arv peab olema 700, kuid retsenseeritavas analüüsis on ainult 597 sõna. Siiski andis analüüs lahendatavast probleemist ja loodavast rakendusest konkreetse ülevaate.


Fontastic meeskonnale rakenduse arendamisel jõudu soovides

Meeskond: Nocturne No. 20 in C-sharp Minor

Retsensioon prototüübile

Esiteks märkasin kohe, et andmebaas initsialiseeritakse automaatselt selle puudumisel. See on prototüüpi avaldades kahtlemata vajalik funktsionaalsus ja palju meeldivam oli prototüüpi hinnata. Samas, märkasin sellega seoses ka kohe bugi: süsteemi installeeritud fontide nimekiri loetakse andmebaasi loomisel andmebaasi, kuid hiljem süsteemi fonte lisades seda nimekirja andmebaasis ei uuendata. Usun et kindlasti peaks rakendus ka fontide nimekirja vähemalt taaskäivitusel vajadusel uuendama.

MVVM arendusmustrist ei ole kinni peetud, kogu kasutajaliidese kood asub MainWindow codebehindis. Kuna tegu on WPF rakendusega, siis MVVM on tugevalt soovitatav arendusmuster mida kasutada.

Üldine mulje kasutaja seisukohalt rakendusest on hea, rakendus töötab piisavalt kiiresti ning kasutajaliides on arusaadav. Rakendus võiks meeles pidada muudetud Example text-i käivituste vahel. Samuti jääb pisut selgusetuks hetkel tab-ide mõte. Kui tabid on ainult tagide grupeerimiseks, siis võiks kindlasti olla ka võimalus luua tage mis ei ole otseselt ühegi tabiga või on seotud mitme tabiga. Näiteks tagid serif/sans-serif võiks olla nähtavad igas tabis.

Aine seisukohalt tekitab muret rakenduse lihtsus. Juhul kui rakendusele mingit suuremat funktsionaalsust enam juurde ei ole planeeritud, siis usun et vähemalt MVVM mustri kasutamine oleks korralike punktide saamiseks vajalik.

Samas, juba prototüübifaasis on peaaegu kogu planeeritud funktsionaalsus saavutatud, nii et hästi tehtud.

Koostas: Meeskond: Spooky Scary Skeletons

Veel üks retsensioon prototüübile

Meeskonna Fontastic prototüübi puhul on tegemist lihtsa WPF-i rakendusega. Projekti struktuur on selge ja loogilise ülesehitusega - kasutajaliidese ja DAL-i osa on omavahel eraldatud. Projektis on ka TestIt nimeline programm, mis sisu järgi peaks olema midagi ühiktesti laadset. Kohane on mainida, et Visual Studio sisaldab ühiktestimise võimalust ja seega saab vajadusel ka korralikke teste mugavamalt kirjutada.

Funktsionaalsuse poole pealt vastab prototüüp valdavalt wikis olevale prototüübi kirjeldusele ja analüüsile. Fontide nimekirja uuendamise probleemile on meeskond Spooky Scary Skeletons oma retsensioonis juba tähelepanu juhtinud. Iseenesest on seda probleemi lihtne parandada ja prototüübi puhul ei ole see ka oluline puudujääk. Samas oluline erinevus wikis oleva prototüübi kirjelduse, analüüsi ja prototüübi funktsionaalsuse vahel on fondile tagide lisamises. Nimelt paistab, et ühele fondile ei ole võimalik mitut tagi lisada, kuid prototüübi kirjelduse (“[---] Fondi peale klikkides on võimalik tage lisada või kustutada (alumises servas). [---]”) ja analüüsi (“[---] Ühel fondil võib olla mitu tagi - näiteks #looks-good-on-red või #web-friendly. [---]”) järgi peaks see võimalik olema.

Prototüübi koodis ei ole kasutatud MVVM arhitektuurimustrit, kuid nii väikese rakenduse puhul olekski see praktikas võib-olla üleliigne abstraktsioon. Samas muudaks MVVM arhitektuurimustri kasutamine kasutajaliidese osa arendamise paindlikumaks ja mis õppeaine kui teooria omandamise seisukohalt kõige tähtsam - annaks arendajatele kogemuse sellise arhitektuuriga.

Koodis on fontide, tabide ja tagide teenused eraldi klassides, kuid kõik need klassid ja neis olevad meetodid on märgitud static’uks. Selline lähenemine on kahtlemata mugav ja ehk isegi ülemäära laisk, kuid OOP-i seisukohalt oleks mõnevõrra ilusam kasutada näiteks singleton’i mustrit.

Kokkuvõttes prototüüp töötab ja mõnede eranditega vastab analüüsis ja kirjelduses toodule.

Retsenseeris Meeskond: Nocturne No. 20 in C-sharp Minor

Silduri retsensioon prototüübile

Retsenseeris meeskond Sildur

Meeskonna „Fontastic“ prototüüp valmis 13.12.2015 ning lahendusfaili importimine Visual Studiosse möödus komplikatsioonideta ning lisaks töötas ka kompileerimine.

Rakenduse loomiseks on kasutatud WPF tehnoloogiat. Rakenduse käivitamisel kuvatakse keskmise suurusega aken, milles põhivaade on jagatud erinevate „tab“-ide ehk lipikute vahel. Lipikuid on 3 tükki nimedega „Default“, „Piret“ ja „Erik“. Tabi sees päises on 2 tekstikasti, millest üks on kasutatud fondi otsinguks ning teisel kuvatakse 4 tähte valitud fondis. Lisaks on kahes veerus loendikastid, milledest esimeses kuvatakse fontide nimekiri ning teises nö fontide siltid. Fontidele siltide loomiseks on vaate alumises osas on tekstikast tekstikirjutamiseks ja 2 nuppu siltide järgi nimekirja filtreerimiseks ja filtri eemaldamiseks.

Üldmulje rakendusest on hea. Selle kasutamisel kõik nupud funktsioneerisid ja töötasid, välja arvatud „Example text“ kastis näidisteksti uuendamine uue fondi valimisel. Väga hästi oli realiseeritud siltide lisamine ja kustutamine – tekstikasti tuli kas tekst juurde kirjutada või ära kustutada. Rakenduse suurimaks miinuseks on selle lihtsus – kasutatakse ainult ühte põhivaadet, millel andmeid kuvatakse. Lisaks, ei ole tabide loomine kasutajate järgi hea mõte, kui kasutajate arv peaks suurenema.

Tabide asemel tuleks pigem kasutada muud lahendust kasutaja valimiseks. Nimelt, kui kasutajate arv läheks andmebaasis suureks, siis ei oleks võimalik enam "õiget" tabi üles leida. Samas, kasutajate nimekiri loodi automaatselt rakenduse käivitamisel – ka see on väga positiivne, sest mõningate meeskondade prototüübid lõpetasid sellel hetkel töö, kui andmebaasi ei leitud.

Rakenduse kood on kirjutatud mingis mõttes omapäraselt. Ühest küljest ei ole kasutatud vaatemudeleid, kuid see-eest on kasutatud „binding“ funktsiooni näiteks fontide siltide nimekirja kuvamiseks või fontide nimekirja kuvamisel. Samas, jäi binding tegemata „Example text“ kastile, mistõttu ei muutunud ka näidistekst fondi valimisel. Teisest küljest ei ole kasutatud ka BLL tehnoloogiat otsingute sooritamiseks ning service ehk teenindus andmebaasiga ühendumiseks asus DAL moodulis „FontasticDB.cs“ klassifailis.

Kokkuvõtvalt võib öelda, et „Fontastic“ meeskonna rakenduse prototüüp oli viimistletud pea viimse detailini. Ainsaks miinuseks on vaadete vähesus, sest muudetakse ainult tabide arvu vastavalt kasutajate arvule ning kuvatavate andmete hulka. Põhivaade on muutumatu.