Kierroksen 5 purku

Toiseksi viimeisen tapaamisemme alussa käsittelimme kuvan varsinaisesti piirtämiseen liittyviä aiheita. Olimme jälleen kahden viikon ajan keränneet informaatiota erinäisistä asioista, ja tässä ovat lopputulokset tiivistettyinä:

Animaatio:

Animaatiot ovat käytännössä peräkkäin näytetty sarja kuvia, joita tarpeeksi nopeasti vaihtamalla saadaan ihmiselle luotua illuusio liikkeestä. Usein sanotaan, että kuvia on tietty määrä sekunnissa (frames per second), ja sen avulla voidaan hieman vertailla animaatioiden sulavuutta. Toteutustapoja on Scalassa useita, mutta yksinkertaisinta lienee päivittää näytölle piirrettävien Image-olioiden kuvaa tarvittaessa. Siinä on kuitenkin lukuisia puutteita – uudelleenpiirrettäessä ei voida suorittaa muuta ohjelmakoodia, animaation ajoitus oikeaan aikaan on vaivalloisempaa ja etenkin pelien toteuttaminen näin on ongelmallista.

Monella tapaa parempi ratkaisu olisi hyödyntää säikeitä. Luomalla Thread -olio ja jättämällä animaatioiden ylläpitäminen täysin sen huoleksi, saadaan ajoitus paljon helpommin toteutettua, samanaikaisesti suoritettua muiden objektien ohjelmakoodia sekä renderöidä kuvaa efekteillä haluttaessa. Kuitenkin sykronointi pääohjelman koodin suorittamisen vaiheiden kanssa voi olla erittäin olennaista tällä tavoin.

Canvasia käyttävä Graphics2D on hidas, kun piirrettäviä kuvaolioita on paljon. OpenGL on nopeampi monissa tilanteissa, ja muut menetelmät voivat olla tilanteesta riippuen vielä nopeampiakin. Tämä tuskin tulee kuitenkaan ongelmaksi, ellei luoda ohjelmia esimerkiksi puhelimille tms.

2D-grafiikka Scalassa

Scalassa ei ole natiiveja grafiisia ominaisuuksia, vaan kaikki piirtämistoiminnot tulevat suoraan Javan kirjastoista. Abstract Window Toolkit eli AWT ja Swing ovat Javan kaksi 2D-grafiikan kannalta erittäin olennaista pakettia. Niissä on paljon samanlaisia piirto-ominaisuuksia ja ne osittain käyttävät samoja luokkiakin, mutta erittäin olennainen ero tulee käyttöliittymän suunnittelun kanssa.

AWT ottaa käyttöliittymän ikkunaelementtien tyylit suoraan käyttöjärjestelmän omista tyyleistä, kun taas Swing piirtää ikkunaelementit omista tyyleistään. Muun muassa ongelmia aiheuttaa AWTia käyttävien ohjelmien porttaus, sillä eri käyttöjärjestelmissä ikkunaelementit voivat näyttää hyvinkin erilaisilta. Swingillä tehdyt ohjelmat sen sijaan näyttävät huomattavasti yhtenäisemmiltä eri käyttöjärjestelmien välillä. Tästä on etua, sillä ikkunaelementtien tyyli sisältää informaatiota mm. siitä, minkä kokoisia ja näköisiä erilaiset napit ja valikot ovat. Jos ero on kovin suuri, voi tarkkaan suunniteltu käyttöliittymä näyttää huonolta tai jopa aiheuttaa hankaluuksia muilla tietokoneilla käytettäessä.

Swing

Swing on Scalan peruskirjasto, jonka avulla on helppo rakentaa monenlaisia käyttöliittymiä. Sen luokat sisältävät määrittelyjä ja metodeja mm. nappuloiden, tekstikenttien, valikoiden ja valintalaatikoiden luomiseen ja käyttöön. Nämä käyttöliittymäelementit sitten jaetaan paneeleihin, joilla voidaan tarkemmin valikoida niiden sijaintia ruudulla.

Ne osaavat myös kuunnella erilaisia inputin tapahtumia, kuten hiirellä klikkausta tai näppäimistön käyttöä, ja heittävät tiedon käyttäjän tekemistä asioista tapahtumakuuntelijalle. Kuuntelija sitten suorittaa erilaisia metodeja riippuen siitä, mitä tapahtui ja missä. Tällä tavoin saadaan esimerkiksi toimintoja käyttöliittymässä olevaa nappia painettaessa.

OpenGL ja renderöinti

Open Graphics Library, eli OpenGL on ohjelmistorajapinta, joka sisältää lukuisan määrän funktioita 2D- ja 3D-grafiikan luomiselle. Se on käyttäjästä ja käyttöjärjestelmästä riippumaton, sillä OpenGL-funktiot pelkästään käsittelevät kuvien tehokasta renderöintiä. Puhtaasti grafiikkaa käsittelevänä kirjastona OpenGL:n avulla ei siis pysty hoitamaan esimerkiksi standardien mukaisten ikkunakomponenttien tekoa, elementtien kuuntelemista tai muita vastaavia toimintoja. Vaihtoehtoisia rajapintoja on myös; pienempiä kuvien renderöintiin pureutuvia kirjastoja on lukuisia, ja eräs olennainen kilpailija on Microsoftin DirectX.

Renderöinti on kuvadatan luomista aiemman datan avulla, noudattaen tietynlaista mallia. 3D-grafiikan yhteydessä termillä viitataan mm. realististen valoefektien kirkkauksien laskemiseen. Videoiden renderöinnissä voidaan kuvasarjan jokaiseen kuvaan lisätä jonkinlainen efekti erilaisten filttereiden avulla, jotta saadaan esimerkiksi kuvasta terävämpää tai poistettua epähaluttuja asioita siististi. Esimerkiksi pelien yhteydessä reaaliaikaisesti useita kuvia peräjälkeen renderöidessä joudutaan säästelemään efektien hienoudesta, sillä aikaa yksittäisen kuvan luomiseen saattaa olla vain sekunnin murto-osa.

– Esa Koskinen

Advertisements

Loppupuheenvuoro

Kurssi alkaa olla paketissa, joten nyt on aika kerrata vähän tapahtunutta ja purkaa omia mietteitä.

Täytyy sanoa, että ensivaikutelma kurssista oli nihkeä. OLO-tapaamiset pistivät vähän epäilyttämään ja pari ensimmäistä harjoitustehtävää tuntuivat aikamoiselta pakkopullalta. Niissä opittiin aika paljon yleistä siitä miten tietotekniikassa ja ohjelmoinnissa asiat ovat suhteessa toisiinsa. Käsitekarttaan tuli läträttyä vähän sitä sun tätä, mutta en kyllä enää muista mitä uutta opin siitä. UML-työ tuli kasattua hammasta purren ja tässä vaiheessa alkoi jo tulevat työtunnit pelottaa mielessä. Epäilykset osuivat kieltämättä oikeaan, MUTTA sanoisin, että kurssi lähti UML:n jälkeen ehdottomasti nousuun.

Ensimmäinen ohjelmointitehtävä oli nimittäin aidosti kiinnostava ja motivoiva. Sitä tehdessä oppi esimerkiksi silmukoiden idean todella hyvin. Sitä seurannut kuva-tehtävä olikin sitten työmäärältään aika hirviö, mutta sekin aiheeltaan ihan mielenkiintoinen. Siihen upposi työtunteja huolella, mutta samalla tuli opeteltua aika paljon ohjelmointia. Muistelen lämmöllä sitä kun koitin valehtelematta viisi tuntia jäljitellä tehtävänannon mallikuvaa vaikka koodini oli ollut koko sen ajan oikein…. jep. Virheen etsiminen toimivasta koodista on aika vaikeaa, voin sen teille kertoa D:

Esseetehtävä oli itselle aika hankala, koska en tiennyt etukäteen kovin tarkasti web-teknologioista. Oppi siitä aihealueesta aika paljon uutta, mutta samalla osa tiedosta jäi kyllä kunnolla sisäistämättä. Tiedon kirjoittaminen kun ei sinänsä vaadi mitään valtavaa sovelluskykyä. Silti ihan hyödyllinen tehtävä, vaikka ei itselle kovin mielekäs.

Pari viimeistä ohjelmointityötä olivatkin sitten aika raskaasti käyttöliittymään liittyviä. Niistä sai aika hyvät perustaidot siihen, miten yksinkertaisia ikkunoita ja 2D-grafiikoita luodaan Scalalla. Osottautui, että kyseisellä kielellä sitä yksinkertaista grafiikkaa saa pöydälle yllättävänkin nopeasti. Käyttöliittymiin sitten liitettiin erilaisia pelejä, joiden logiikan tekeminen oli myös pirun hauskaa. Esimerkiksi ping pongin fysiikkamallin itsenäinen suunnittelu ja sen vaiheittainen testaaminen oli oikein mukavaa hommaa.

Viimeiseen tehtävään anettiin siis käytännössä jo täysin vapaat kädet ja siitä ominaisuudesta pidin. Siinä vaiheessa kurssia oli kuitenkin jo riittävät taidot omatoimiseen tekemiseen. Juuri tämä soveltaminen oli studio -kurssin vahvuuksia. Ohjelmointi 1 opetti enempi ohjelmointiteknisiä asioita ja Scalan käyttöä kun taas studiossa näitä taitoja hyödynnettiin oman koodin suunnittelussa. Toki samaa tehtiin ohjelmointi 1:ssä, mutta siellä tehtävänannot pitivät enemmän kädestä kiinni ja dokumentaatiot olivat tarkkoja. Kurssit toimivat tämän takia mielestäni hyvin yhdessä vaikka välillä olikin vähän synkronointiongelmia (silmukat ja gui käsiteltiin ensin studiossa).

OLO-tapaamisista voin sanoa, että vaikka alkuun tuntuivat turhauttavilta, niin niihinkin alkoi ajan kanssa suhtautua ihan positiivisesti. Ryhmässä oli hyvä meininki ja assarimme oli hyvä tyyppi. Valitettavasti suuri osa ryhmästä lopetti kesken kurssin, mutta toisaalta se toi vähän eloa ryhmäkeskusteluihin. Pienessä ryhmässä juttu ja läppä lensi herkemmin kun tapaamiset eivät tuntuneet enää niin ‘virallisilta’ ja muutaman henkilön kesken oli muutenkin kevyempää jutella. OLOista oppi yleisesti ihan kivaa lisätietoa.

Voisin vielä lopuksi itkeä siitä miten kurssissa oli liikaa työtunteja, mutta siitä on jo tarpeeksi jauhettu opiskelijoiden keskuudessa. Olen kyllä samaa mieltä siitä, että työtä oli vähän turhan paljon suhteessa 5op:hen, mutta toisaalta ymmärrän sen, että aloittelijoille voi olla aika vaikea suunnitella ohjelmointitöitä. Jollekin kokeneelle kodaarille (tehtävän suunnittelijalle) naurettavan helpolta vaikuttava homma saattaa olla toiselle kymmenien tuntien duuni. Ja sitä on vaikea tietää/huomata ellei anneta palautetta. Onneksi siis kritiikkiä on kuunneltu ja studio -kurssia tullaan varmaan modaamaan tulevaisuutta varten.

Kiitos vielä ryhmälle.

— Karri Haranko

Tehtävä 1 – Luokat ja oliot

Toisen harjoitustehtävän tarkoituksena oli tutustuttaa opiskelijat UML-mallinnuksen perusteisiin. Tehtävänantona oli luoda luokkakaavio, joka kuvaa puhelinlaskuja hallitsevan järjestelmän toimintaa sekä kirjoittaa sen kylkeen pienimuotoinen essee. Tekstissä piti avata oman kaavion toimintaa ja kertoa yleisesti UML:n ominaisuuksista kuten esimerkiksi niistä käytännöistä, joilla kaavioissa merkataan luokkien välisiä yhteyksiä.

Tehtävää tehdessä monet olivat vielä opiskelun ja koodamisen suhteen aika alkutaipaleella, mikä aiheutti ainakin minulle (ja kuulemani mukaan muutamalle muullekin..) päänvaivaa. Tehtävä löi lievästi korville, koska tässä kohtaa joutui ensimmäistä kertaa opiskeluaikana tekemään astetta haastavamman ja työläämmän tehtävän. Olio-ohjelmointi ja yleiskäsitys ohjelmien rakenteista oli vielä vähän hakusessa ja asiaa ei helpottanut se, että tehtävänanto oli tarkoituksella melko avoin, minkä ansiosta olennaisen asian suodattaminen lopulliseen työhön jäi itselle mietittäväksi.

Tästä tehtävästä sai kuulla kovaa purnausta aika monen kanssaopiskelijan suusta ja se on helppo ymmärtää. Työ oli hämmentävä, työläs eikä kovinkaan mielenkiintoinen. Aihealue oli toisaalta ihan hyödyllinen, mutta tehtävän ajoitus meni mielestäni vähän pieleen. Ehkä jos sama homma olisi tarjottu yksi tai pari kuukautta myöhemmin, olisi työ tuntunut kevyemmeltä ja oppiminen olisi ollut vähän hedelmällisempää.

Se mitä työstä jäi itselle käteen, oli parempi käsitys olioiden välisestä toiminnasta. Lisäksi pääsi tutustumaan täysin uuteen asiaan eli UML-mallinnukseen. Täytyy kuitenkin todeta, että tehtävä ei ehkä tarjonnut ihan tarpeeksi vastinetta sille ajalle, minkä tähän joutui kuluttamaan.. ellei sitten tulevaisuudessa joudu enemmänkin tekemisiin UML:n kanssa?

— Karri Haranko

Tapaus 6 – Avaus

Tällä kertaa pureuduimme tarkemmin käyttöliittymään liittyviin asioihin ja erityisesti sen suunnitteluun. Ryhmämme oli jälleen pienehkö ja koostui neljästä henkilöstä, mutta se ei menoa haitannut. Ilmeisesti aihealue oli kaikille läheinen ja kiinnostava tai jotain, koska keskustelua riitti läpi avauksen ja se rönsyili mukavasti. Puheenaiheiksi nousivat esimerkiksi shakkitekoälyt, pelien huijauskoodit sekä YouTuben käyttöliittymä, joka aina vaan jatkaa ihmisten suututtamista päivityksillään. Innostuimme lopulta jauhamaan erinäisistä asioista niin pitkään, että aika karkasi käsistä ja päätimme poikkeuksellisesti skipata stormauksen ja fläppitaulut. Tutkittavat aiheet päätettiin jakaa suoraan henkilöille ja ne menivät seuraavasti:

Esa – käyttöliittymäsuositukset pelikonsoleille
Karri – käytettävyystestit
Antti – hiddentest ja perustelut pelien koodeille ym. salaiselle sisällölle
Markus – käyttöjärjestelmien interaktion suositukset

— Karri Haranko

Tapaus 4 – Purku

Neljännen tapauksen aiheena oli web-teknologiat ja sitä lähdettiin purkamaan yhden miehen vajauksella. Tero sai kuitenkin lähetettyä esityksensä verkon kautta, joten hänenkään aiheensa ei jäänyt käsittelemättä. Aiheista löytyi niin vertaisverkkoa kuin URL:n ja MVC:n toimintaa. Oheen on kasattu töiden muistiinpanoja, joista ilmenee olennainen.

MVC (model-view-controller)

– tapa järjestellä koodia
– useat frameworkit toteutettu käyttäen
– ongelmana, että kontrolleriin kasautuu liikaa kamaa

– model (malli), määrää sen, miten asiat näytetään
– view (näkymä), luo mallin luomasta datasta lopullisen visuaalisen esityksen
– controller (ohjain), vastaanottaa käyttäjän komennot, prosessoi ne ja ohjaa mallia ja näkymää

Sekä hyvä havainnollistava kuva:
mvc

URL

– tietty merkkijono, joka sisältää viittauksen lähteeseen
– rakentuu seuraavasti:
1. ensin protokolla esim. http
2. kaksoispiste ja kaksi kauttaviivaa
3. host, joka yleensä annetaan verkkotunnuksena, mutta joskus myös kirjallisena IP-osoitteena
4. koko loppupolku
– protokolla kertoo miten yhdistää, host määrittää minne yhdistetään ja loput sen, mitä pyydetään

DNS

– nimipalvelujärjestelmä, joka muuntaa verkkotunnuksia IP-osotteiksi
– mahdollistaa helposti muistettavien nimien käytön numeeristen osotteiden sijaan (jolla Internetin laitteet kommunikoivat)
– toimii kuin puhelinluettelo, joka liittää verkkotunnuksia IP-osotteisiin

Nimipalvelun toteuttavia palvelintyyppejä on kaksi:
– resolverit – hakee nimipalvelukyselyihin vastauksia
– auktoritatiiviset nimipalvelimet – antavat vastauksia nimipalvelukyselyihin

P2P -verkot (vertaisverkko, peer-to-peer-verkko)

Markuksen tekemän hienon esityksen voi katosa tästä:
ME-C2110 Kierros 4 – Web-teknologiat – P2P

— Karri Haranko

25.9. OLO1-session Purkumuistiinpanot

Enkapsulointi

-toteutustavan piilottaminen public/private määreillä

-olion sisäisen logiikan voi piilottaa käyttäjältä privatella

-vähentää monimutkasuutta

-estää toimintalogiikan muuttamisen koskematta alkuperäiseen koodiin

-ollennaista esim kirjastoissa joissa tiedonhakua ei tarvitse nähdä, vaan haettava tieto tarvitaan näyttää

-poistaa public puolelta potentiaalista raskasta luettavaa

muuistiinpanot

Interface (rajapinta)

-Antaa ohjelmien käyttää muita ohjelmia kun tiedetään ohjelman kyvyt ja metodit.

-Scalassa ei ole rajapintoja. “Traits” korvaa tämän saman toiminnon

-Tunnetaan myös API:na. Esimerkkejä:

-OpenGL

-DirectX

kalvot

Olio-ohjelmoinnin hierarkia

-On hankala näyttää minkään kielen kaikki hierarkiat ihan yksinkertaisesti koon takia; dataa olisi liikaa

-Scalassa:

-Kaikki ovat olioita

-Kaikkein korkeimmalla on Scala.Any, jonka alla on Scala.AnyRef ja Scala.AnyVal josta sitten kaikki muut oliot periytyvät.

-Null ja None ovat metaforisia “käärmeitä” Scalan maailmassa, kaikista alimpina hierarkiassa.

Tietotyyppien näkyvyys

-Yleisesti muuttujat voi määritellä joko private tai public tyyppisiksi

-Private muuttujat näkyvät vaan sen luokan sisällä tai sen funktion sisällä jossa se on määritelty

-Public:it näkyvät ulkoakinpäin. Näihin voi päästä mistä tahansa käsin.

-Scalassa ei ole julkisia muuttujia, niitä pitää määritellä luokkana tai pitää luoda funktio joka erikseen palauttaa sitä, mitä haluaa.

Perintä 

-tarkoituksena vähentää uudelleenkirjoittamista

-olio-ohjelmoinnissa on tapa luoda ali-luokkia olemassa olevista luokista

kalvot

Oliot ja tietokannat

-Olioita ja dataa halutaan tallentaa tietokantoihin

-tarkoitus ei ole tallentaa jokaista oliota, vaan tiettyjä oleellisia asioita

-voidaan poistaa tallennettuja olioita tietokannoista ja tuoda niitä takaisin muistista käyttäjän halun mukaan

-tyypit ja viittaukset:

-esim string voi olla niin pitkä kun haluaa, joka voi hajottaa tallennusta jos tallennuksessa on rajallinen tila

-dataolioit tulevat yksittäisinä ja eivät peri toisiaan

-pythonissa on django-palikka jossa idea on luoda olio joka kuvastaa jotain taulua ja linkitetään liittyviä indeksejä. Monta oliota voi linkittää samaan aikaan.

Tietorakenteet 

muistiinpanot 1

muistiinpanot 2

Emme valitettavasti saaneet polymorphismista tietoa kuten suunniteltu.

Olo2 -session avaus

Tämänkertaisessa sessiossa mietimme koodausjuttuja ja post-itestä syntyi seuraavat aiheet:

Virheenkorjaus optisessa mediassa – Martturi

Public / private keys – Tero

Hashit, crc, md5 – Lauri

RLE, Huffman – Sampsa

Viivakoodit, QR – Antti

Wifin salauksesta – Esa

HDMI, Ethernet virheenkorjausmetodit – Markus

Radiokanavan mielenkiintoisuudet – Karri

 

Toinen OLO -sessio (Tapaus 1)

Ensimmäisen session tuotokset purettuamme ryhdyimme pohtimaan olioihin liittyviä asioita. Post-it -lapuille kertyi paljon näkyvyyteen, periytymiseen, pakettistruktuuriin ja olio-ohjelmointiin liittyvää käsitteistöä. Sivusimme myös olioiden ideaa, sekä olio-ohjelmoinnin vaikutusta ohjelmointiin kokonaisuutena.

Itsenäinen opiskelu jaettiin seuraavasti:

Polymorphismi – Terhi

Enkapsulointi – Esa

Interface – Tero

Olio-ohjelmoinnin hierarkia – Matias

Datan näkyvyys – Antti

Perintä – Markus

Oliot ja tietokannat – Sampsa & Lauri

Tietorakenteet – Karri

Portfolion ohjeet

On mielestäni hyvä tässä vaiheessa huomioida blogi-portfolion postien muotoiluun liittyvät seikat, jotka löytyvät portfolio-ohjeesta:

“Muokatkaa portfoliostanne mielekkään näköinen, mutta selkeästi jaoteltu. Kaikki tekstit tulee merkitä tagein. Tekstejä kannatta jakaa arvostelun helpottamiseksi kategorioihin (OLO, Harjoitukset jne.). Käyttäkää tekstien allekirjoituksissa myös selkeästi sellaisia nimiä, jotta teidät voidaan helposti yhdistää teksteihin. Kaikki muut portfolion ulkomuotoon tehtävät valinnat ovat vain teidän mielikuvituksenne rajoittamia! Heti kun tiedätte missä osoitteessa portfolionne tulee olemaan, ilmoittakaa se oman ryhmänne tutorille.”

– Esa

Ensimmäinen OLOsessio (Tapaus 0)

Ensimmäisessä tapaamisessa oli tarjolla vain uuden tehtävän avaus sillä luonnollisesti emme tässä vaiheessa voineet vielä purkaa aikaisempia tehtäviä. Tässä OLOsessiossa meillä oli tapauksena Tapaus 0 – Tieto tietokoneessa, jossa käsiteltiin kantalukujärjestelmiä, mikä on tavu ja näppäimitstön toimintaa.

Kun olimme lukeneet tekstin rupesimme miettimään millaisia asioita meille tuli mieleen kyseisestä tekstistä.  Saimme mm. seuraavia asioita post it lapuille:

– Tiedonsiirto

– ääni ja kuva informaatiosta

– utf-8, ansi

– usb, ethernet

-kovalevy

– pointterit

– transistorit ja kytkimet

– bin vs hex

Pääasiassa asiat jakaantuivat kolmeen pääalueeseen. Muisti ja muistin käyttö, merkistöt ja tiedostomuodot sekä lisälaitteet ja muut ulkoiset asiat.

Seuraavaa sessiota varten jaoimme lopuksi vielä aiheet itseopiskeluun seuraavasti:

Muut näppäimistöjärjestelmät -Matias

Merkistökoodaus – Otso & Lauri

Muistin tallennus -Esa

Muistilaitteet – Tero & Karri

I/O laitteet -Sampsa & Antti

Scan-koodaus järjestelmä – Terhi

Vaihtoehdot scan -koodaukselle  – Markus

-Ensimmäisen session sihteeri Lauri