Lienee aika ampua tässäkin blogissa uudenvuodenraketit. Pam! Kiitos
Kuten ainakin naamakirjan puolelta on saanut lukea, allekirjoittanut sai tammikuussa idean. Tähän ideaan liittyy tämä koulu. Tarkemmin sanoen ideani liittyy tuon pdf-dokun sivulle 44.
Siltä varalta että joku ei tästä ymmärtänyt, olen siis pohtinut kolmivuotista yliopistoreissua tuonne britteinmaalle. Tämän suunnitelman tiellä on käytännössä enää rahoitus. Kävin tänään keskustelemassa kv-tädin kanssa koululla, ja ilmeisesti hakemisella ei vielä ole kiire, vaikka tahtoisikin syyskuussa opiskelemaan. En siis rynni ihan vielä pankkiin tekemään mitään seksikästä rahoitussopimusta, joka paremmissa piireissä tunnettaisiin hiton isona lainana, vaan tutkiskelen vielä jos joku säätiö tai firma (Äiti? :) Isi? :) Jussi? :)) voisi rahoittaa edes osan tästä projektista. Jos joku haluaa investoida tulevaisuuden tekijään, minuun, rahasummia otetaan vastaan 10€-50 000€ - väliltä. Laitelkaa sähköpostia feuer.smith ät gmail.comiin aiheesta :)
Nyt kun johdanto on alta, voinen siirtyä varsinaiseen asiaan. Minulta on kyselty viime aikoina, että miksi oikein haluan englantiin. Kysymys on väärin. Tässä projektissa, kuten elämässä, ei ole kyse haluamisesta. Jos elämässä olisi kyse haluamisesta, heräisin arkiaamuisin kympiltä. Aamurituaaleihin kuuluisi myös parin tunnin pyöräily- ja pleikkarisessiot (missä pleikkari on synonyymi kaikille joukon {psX (missä X kuuluu joukkoon {2, 3, Vita}), Wii, PC} jäsenille), hieman ehkä vuodenajasta riippuen. Tämän jälkeen olisi sopiva hetki avata joku MERPGiin liittyvistä projekteista. Tätä voisi sitten työstää parista kuuteen tuntia. Sen jälkeen voisi olla sopiva hetki jätskille ja uudelle pyörä- tai pleikkarisessiolle. Sitten ruokaa! Riippuen siitä onko oikeassa maailmassa jotain ohjelmaa, voisi ruoan jälkeen joko lähteä kaupungille jonkun seurassa, tai jäädä katsomaan telkkaria. Seittemän tai kahdeksan maissa voisi sitten tulla koneelle, avata jonkin projektin taas, ja alkaa iltaisen innovointikierroksen.
Viikonloput seuraisivat samaa kaavaa... Tosin aamu-päivä - akselille sijoittuisi harrastamista ja ilta-yö - akselille koodailua. MERPG vaatii säännöllisen epäsäännöllisesti Tässin kanssa Öiden hyödyntämistä. Nämä sijoittuisivat kuten nykyäänkin, ehkä vähän pienemmällä intervallilla.
Kuten sanottua, englantiprojektinkaan kanssa kyse ei ole haluamisesta. Kyse on siitä tunteesta, joka ajaa lapsen rautatien ääreen, joka laittaa lapsen opiskelemaan uusia ohjelmointikieliä ja -tapoja, joka ostaa lapselle lippuja mitä kummallisimpiin paikkoihin. Tämä tunne, kiinnostus, on kiinnostava! Minua kiinnosti alunperin, 11-vuotiaana, tietää miten pelejä ja nettisivuja tehdään. Sitä kysymystä tutkin ja analysoin vieläkin. Rautatie-innostukseni lähti siitä liikkeelle, kun koulumatkoilla, Leppävaaran ja Pasilan välillä, etsin virikkeitä. Jostain syystä kiskoilla kulkevat yksityiskohdat tarjosivat niitä ja paljon. Oikeastaan niin paljon, että olen vasta vähän aikaa ymmärtänyt kuinka laajan alueen "rautatieharrastus" käsittää. Matkailu taas on ihan oma lukunsa.... :D Siihen sisältyy kiinnostavia paikkoja, jännää historiaa ja inspiroivaa matkaseuraa.
Niin, toimintani todennäköisesti-väliaikainen siirtäminen saarivaltioon todennäköisesti tarjoaisi kiinnostukseen ja innostukseen perustuvia elämyksiä... toivottavasti. Toki tämä toisi mukanaan myös huonoja puolia, taakse jäisi iso-kone laskentatehoineen (en todellakaan ottaisi mukaan muuta kuin max 2 päpää, toinen muistiinpanokoneeksi (nykyinen pienpäpä pärjäisi tässä todennäköisesti hyvin), ja ~15 tuumaisen läppärin, jossa akku kestää ohjelmointia vähintään viisi tuntia ja rauta kestää Dragon Age IIa ja Assassin's Creed Revelationsia täysillä asetuksilla), Yöt siedettävillä intervalleilla, ja naamatuskommunikointi nykyisten porukoiden kanssa. Puhumattakaan Suomen kiehtovasta rataverkosta!
Joku voisi loukkaantua siitä että isokone mainittiin ennen ihmisosaa, mutta ihmisosaa varten on olemassa mese, skype, naamakirja, sekä ainakin kolme blogia. Koneesta taas ole mitään hyötyä, jos sen jättää kotiin happanemaan :P
Kiitos taas siitä, jos joku jaksoi tuon lukea loppuun. Nyt voin loputalkin vastata kysymykseen "Miksi englantiin?" käskemällä lukemaan blogista :)
Monday, 16 April 2012
Friday, 13 April 2012
Miltä kartta näyttää
Hahmottelenpa tänne hieman edellisen viestin karttasuunnitelmia, koska en jaksa avata Netbeansia.
Ylimmällä tasolla meillä on lista MEMAP-olioita. Tiedän että tämä saattaa tehdä latausajoista melko seksikkäitä, mutta väittäisin että ainakin suunnitelmien protoiluasteella karttatiedostot ovat serialisoituja tällaisia listoja. Jos latausajat ovat pahoja, voi tiedostoformaattia muuttaa serialisoidusta listasta, joka tallennetaan ja ladataan yhdellä käskyllä, headeriksi, joka kuvaa tiedoston rakennetta (monesko kartta on mikäkin kartta), ja jonoksi kartta-olioita, joiden lataus rinnakkaistetaan tai johon kirjoitetaan joku luovuutta uhkuva algoritmi.
Varsinaista MEMAP-luokkaa taas muutetaan niin, että siihen lisätään lista vektoreita. Nämä vektorit kuvaavat tilejä, joilta pääsee liikkumaan seuraavalle kartalle. Tämä vektoriluokka on tietysti peritty perinteisestä Vector2-luokasta, jonka "lainasin" droidipeliraamatustani, Tähän perittyyn luokkaan pitäisi laittaa myös viite karttaan, johon vektorin kuvaamasta tilestä pääsee. Tämä viite on todennäköisesti kohdekartan hashcode sarjallistaessa ja editorissa suora viite kohdekarttaan... Tai toisaalta voisihan pelkkä viitekin toimia. Täytyy tutkia miten oliot käyttäytyvät tiedostoon tallentaessa.
Lisäksi vektoreihin pitäisi myös merkitä kohdekartan saapumistile. Tiivistettynä nämä siirretilet kuvaavat siis:
Ylimmällä tasolla meillä on lista MEMAP-olioita. Tiedän että tämä saattaa tehdä latausajoista melko seksikkäitä, mutta väittäisin että ainakin suunnitelmien protoiluasteella karttatiedostot ovat serialisoituja tällaisia listoja. Jos latausajat ovat pahoja, voi tiedostoformaattia muuttaa serialisoidusta listasta, joka tallennetaan ja ladataan yhdellä käskyllä, headeriksi, joka kuvaa tiedoston rakennetta (monesko kartta on mikäkin kartta), ja jonoksi kartta-olioita, joiden lataus rinnakkaistetaan tai johon kirjoitetaan joku luovuutta uhkuva algoritmi.
Varsinaista MEMAP-luokkaa taas muutetaan niin, että siihen lisätään lista vektoreita. Nämä vektorit kuvaavat tilejä, joilta pääsee liikkumaan seuraavalle kartalle. Tämä vektoriluokka on tietysti peritty perinteisestä Vector2-luokasta, jonka "lainasin" droidipeliraamatustani, Tähän perittyyn luokkaan pitäisi laittaa myös viite karttaan, johon vektorin kuvaamasta tilestä pääsee. Tämä viite on todennäköisesti kohdekartan hashcode sarjallistaessa ja editorissa suora viite kohdekarttaan... Tai toisaalta voisihan pelkkä viitekin toimia. Täytyy tutkia miten oliot käyttäytyvät tiedostoon tallentaessa.
Lisäksi vektoreihin pitäisi myös merkitä kohdekartan saapumistile. Tiivistettynä nämä siirretilet kuvaavat siis:
- Lähtökartan tileä, josta siirtymä tapahtuu
- Kohdekarttaa, jolle siirtymä tapahtuu
- Kohdekartan tileä, jolle siirtymä tapahtuu
Saturday, 31 March 2012
Merpattuja ajatuksia
Hehheh, sanaleikki.
Tulinpa ajatelleeksi. Olen mieltänyt MERPGin kartta-arkkitehtuurin sellaiseksi, että yhteen karttaan sijoitetaan aina yksi looginen alue (kaupunki, reitti tjsp). Näitä karttoja pidettäisiin sitten muistissa niin paljon, että kaikki ruudulla oleva maasto on yhtenäistä. Muistimanageri sitten yrittää esiladata muistiin karttoja pelaajan liikkeiden perusteella niin, ettei missään tulisi lataustaukoa tai tyhjää tilaa, johon ilmestyy kartta muutama sekunti alueelle astumisen jälkeen.
Tässä on ymmärrettävästi omat haasteensa. Miten määritellä karttojen suhde toisiinsa, toivomalla että koodari hahmottaa kartan ja laittaa ne pikselintarkasti toisiaan vasten, niin kuin kartturi on suunnitellut? Tuskinpa. Entä algoritmi, jonka perusteella esiladata karttoja lennossa? En tiedä, voisi olla helppo jos innostuisin pohtimaan, sitä, mutta näin yötä vasten kuulostaa pelottavalta.
Tämän voisi siis tehdä fiksumminkin. Jos ruudulla näytetään koko ajan yksi ainoa kartta, jossa on tileihin upotettu data siitä mihin karttoihin mihin kohtiin kyseiset tilet vievät, voi kartturi määritellä karttojen suhteet vaivaamatta koodaria tällaisillä vaikeilla asioilla. Tämän pitäisi onnistua lisäämällä kartta-rakenteen tile-olioihin Stringillä kohdekartan tiedostonimi ja 2D-koordinaattina tile, jolle siirtymän kokenut hahmo spawnaa. Lisäksi tälle pitäisi rakentaa memapperiin käyttöliittymä ja moottoriin logiikkaa tarkistamaan tämän datan.
Toinen mitä pohdin on hahmojen jatkuva liike. Vanha käsitykseni oli, että yksi hahmo voisi olla yhden tilen, ja hahmot liikkuisivat aina tilen verran suuntaansa. Näin hahmojen sijainti olisi jaollinen 50 pikselillä. Tällä saattaisi olla jotain hyötyjä, joita ei nyt tule mieleen, mutta etenkin läheisyystarkistus tarvitsisi hassumpaa matikkaa. Jos hahmojen sijainti olisi jaollinen 1 pikselillä, läheisyyden tarkistuksesta tulee paljon helpompaa, kun ei tarvitse muuttaa koordinaatteja yksiköstä toiseen. Lisäksi kamerasysteemi saattaisi olla helpompi toteuttaa, jos hahmo on liian lähellä ikkunan jotain reunaa, liikuta kameraa samaan suuntaan, jolloin hahmo keskittyy taas.
Täytyy pohtia, täytyy toteuttaa, nyt hyvää yötä!
Tulinpa ajatelleeksi. Olen mieltänyt MERPGin kartta-arkkitehtuurin sellaiseksi, että yhteen karttaan sijoitetaan aina yksi looginen alue (kaupunki, reitti tjsp). Näitä karttoja pidettäisiin sitten muistissa niin paljon, että kaikki ruudulla oleva maasto on yhtenäistä. Muistimanageri sitten yrittää esiladata muistiin karttoja pelaajan liikkeiden perusteella niin, ettei missään tulisi lataustaukoa tai tyhjää tilaa, johon ilmestyy kartta muutama sekunti alueelle astumisen jälkeen.
Tässä on ymmärrettävästi omat haasteensa. Miten määritellä karttojen suhde toisiinsa, toivomalla että koodari hahmottaa kartan ja laittaa ne pikselintarkasti toisiaan vasten, niin kuin kartturi on suunnitellut? Tuskinpa. Entä algoritmi, jonka perusteella esiladata karttoja lennossa? En tiedä, voisi olla helppo jos innostuisin pohtimaan, sitä, mutta näin yötä vasten kuulostaa pelottavalta.
Tämän voisi siis tehdä fiksumminkin. Jos ruudulla näytetään koko ajan yksi ainoa kartta, jossa on tileihin upotettu data siitä mihin karttoihin mihin kohtiin kyseiset tilet vievät, voi kartturi määritellä karttojen suhteet vaivaamatta koodaria tällaisillä vaikeilla asioilla. Tämän pitäisi onnistua lisäämällä kartta-rakenteen tile-olioihin Stringillä kohdekartan tiedostonimi ja 2D-koordinaattina tile, jolle siirtymän kokenut hahmo spawnaa. Lisäksi tälle pitäisi rakentaa memapperiin käyttöliittymä ja moottoriin logiikkaa tarkistamaan tämän datan.
Toinen mitä pohdin on hahmojen jatkuva liike. Vanha käsitykseni oli, että yksi hahmo voisi olla yhden tilen, ja hahmot liikkuisivat aina tilen verran suuntaansa. Näin hahmojen sijainti olisi jaollinen 50 pikselillä. Tällä saattaisi olla jotain hyötyjä, joita ei nyt tule mieleen, mutta etenkin läheisyystarkistus tarvitsisi hassumpaa matikkaa. Jos hahmojen sijainti olisi jaollinen 1 pikselillä, läheisyyden tarkistuksesta tulee paljon helpompaa, kun ei tarvitse muuttaa koordinaatteja yksiköstä toiseen. Lisäksi kamerasysteemi saattaisi olla helpompi toteuttaa, jos hahmo on liian lähellä ikkunan jotain reunaa, liikuta kameraa samaan suuntaan, jolloin hahmo keskittyy taas.
Täytyy pohtia, täytyy toteuttaa, nyt hyvää yötä!
Thursday, 29 March 2012
MERPG elää yhä
Positiiviset otsikot jaksavat lämmittää mieltä :)
Allekirjoittanut on vähän flunssainen, joten tästä tekstistä tuli hieman huonolla kieliopilla varustettua tajunnanvirtaa. Onnea sille, joka jaksaa lukea ja ymmärtää kaiken :P
Jos en ole sitä vielä tehnyt, teen tästä nyt virallista. Merpgtarina.blogspot.com oli paska ratkaisu, jolle ainoa peruste oli ettei kukaan (devtiimistä) ollut tuolloin kuullutkaan mistään Dropboxista, puhumattakaan professionaaleista dokumenttien- ja sorsanhallinnoista. Vaikka Tässi eilen rikkoikin sen blogin hiljaisuuden, olen tehnyt jo pidempään puhtaaksikirjoittanut tarinaa word-dokumenttiin. Tähän dokuun olisi tarkoitus speksata kaikki muutkin pelin yksityiskohdat, lukuunottamatta yksityiskohtaista karttasuunnittelua. Siitä nähdään vain painajaisia ennen kuin Tässi pääsee väsäämään tilesettejä ;)
Aloin pitkästä aikaa protoilemaan moottorin kanssa. Tein aikaa sitten projektin ainoana koodarina päätöksen toteuttaa kaiken javalla, mm. monta iteraatiota nähneen karttaohjelman java-koodipohjan ja bugiherkän käsin-serialisoinnin vuoksi. Tässä moottorissa, jonka sorsat voi kiinnostunut ladata Sourceforgesta, on valmiina tällä hetkellä vain pelkkää Swingin abstraktointia ja karttojen toimivuuden testailua. Swingiä voisi joku väittää loistavaksi GUI-kirjastoksi, mutta edes 2D-peleihin se ei niin vain taivu. Sen sijaan että olisin huijannut SDL:n javaporttauksella, abstraktoin Swingin piiloon tekemällä ikkunaluokan, johon lisätään JPanelista periytettyyn luokkaan pohjautuva "sisältö". Ikkunaluokka piilottaa myös Swingin vähintäänkin kummallisen näppäinkuuntelusysteemin, ja tarjoaa ENUMillisen nappeja, joiden pohjassaoloa voi pollata ikkunalta. Käytännössä siis ylänuolen alhaallaoloa kysytään seuraavasti:
if(getKeyListener().keyDown(KEY.UP_KEY)) //Teejotain
getKeyListener() on sisältöluokan metodi, joka palauttaa Keys-rajapinnan toteuttavan olion (eli ikkunan). KEY - enum on mielenkiintoinen yksilö, joka johtuu käytännössä laiskuudestani. Kuuntelijalta voi polalta vain nuolinappien, escin, returnin, F5:n ja shiftin tilaa. Tämä siksi, että enum-näppäinkoodit ovat tyyppiturvallisempia ja selkeämpiä kuin Swingin int-vakiot. Jos uusille näppäimille tulee tarve, lisätään KEY-enumiin sille vakio, joka lisätään myös seuraavaan switchiin
private KEY eventToKey(KeyEvent e)
{
switch(e.getKeyCode())
{
case KeyEvent.VK_UP:
return KEY.UP_KEY;
case KeyEvent.VK_DOWN:
return KEY.DOWN_KEY;
case KeyEvent.VK_RIGHT:
return KEY.RIGHT_KEY;
case KeyEvent.VK_LEFT:
return KEY.LEFT_KEY;
case KeyEvent.VK_ESCAPE:
return KEY.ESCAPE;
case KeyEvent.VK_ENTER:
return KEY.SELECT;
case KeyEvent.VK_F5:
return KEY.SAVE;
case KeyEvent.VK_SHIFT:
return KEY.RUN;
default:
return null;
}
},
minkä jälkeen kuuntelija tuntee kyseisen vakion.
Sisältöluokka tarjoaa abstraktit Present() ja Update() - metodimääritykset. Luokan paintComponent() kutsuu näitä, antaen Presentille parametreina millisekunteina edellisestä päivityksestä kuluneen ajan ja grafiikkakontekstin, sekä Updatelle pelkän ajan. Presentin tarkoitus olisi piirtää ikkunan sisältö, ja Updaten pitäisi päivittää pelitilanne.
Tällainen arkkitehtuuri mahdollistaa sen, että sisältöluokasta voidaan periyttää oma luokka, jonka konstruktorissa ladataan media sisältöluokan kokoelmiin, luodaan pelin tila jonnekin mallitasolle, joka yhä odottaa kirjoittamistaan, ja jonka present-metodi hakee mallilta tilan ja piirtää sen, sekä antaa updaten päivittää mallia piirron jälkeen. Tämän jälkeen muutetaan ikkunan luonnissa, main-metodissa, sisältö-olion määritys vastaamaan uutta luokkaa, ja kaiken pitäisi toimia suoraan. Ei tarvitse huolehtia ikkunan luonnista.
Allekirjoittanut on vähän flunssainen, joten tästä tekstistä tuli hieman huonolla kieliopilla varustettua tajunnanvirtaa. Onnea sille, joka jaksaa lukea ja ymmärtää kaiken :P
Jos en ole sitä vielä tehnyt, teen tästä nyt virallista. Merpgtarina.blogspot.com oli paska ratkaisu, jolle ainoa peruste oli ettei kukaan (devtiimistä) ollut tuolloin kuullutkaan mistään Dropboxista, puhumattakaan professionaaleista dokumenttien- ja sorsanhallinnoista. Vaikka Tässi eilen rikkoikin sen blogin hiljaisuuden, olen tehnyt jo pidempään puhtaaksikirjoittanut tarinaa word-dokumenttiin. Tähän dokuun olisi tarkoitus speksata kaikki muutkin pelin yksityiskohdat, lukuunottamatta yksityiskohtaista karttasuunnittelua. Siitä nähdään vain painajaisia ennen kuin Tässi pääsee väsäämään tilesettejä ;)
Aloin pitkästä aikaa protoilemaan moottorin kanssa. Tein aikaa sitten projektin ainoana koodarina päätöksen toteuttaa kaiken javalla, mm. monta iteraatiota nähneen karttaohjelman java-koodipohjan ja bugiherkän käsin-serialisoinnin vuoksi. Tässä moottorissa, jonka sorsat voi kiinnostunut ladata Sourceforgesta, on valmiina tällä hetkellä vain pelkkää Swingin abstraktointia ja karttojen toimivuuden testailua. Swingiä voisi joku väittää loistavaksi GUI-kirjastoksi, mutta edes 2D-peleihin se ei niin vain taivu. Sen sijaan että olisin huijannut SDL:n javaporttauksella, abstraktoin Swingin piiloon tekemällä ikkunaluokan, johon lisätään JPanelista periytettyyn luokkaan pohjautuva "sisältö". Ikkunaluokka piilottaa myös Swingin vähintäänkin kummallisen näppäinkuuntelusysteemin, ja tarjoaa ENUMillisen nappeja, joiden pohjassaoloa voi pollata ikkunalta. Käytännössä siis ylänuolen alhaallaoloa kysytään seuraavasti:
if(getKeyListener().keyDown(KEY.UP_KEY)) //Teejotain
getKeyListener() on sisältöluokan metodi, joka palauttaa Keys-rajapinnan toteuttavan olion (eli ikkunan). KEY - enum on mielenkiintoinen yksilö, joka johtuu käytännössä laiskuudestani. Kuuntelijalta voi polalta vain nuolinappien, escin, returnin, F5:n ja shiftin tilaa. Tämä siksi, että enum-näppäinkoodit ovat tyyppiturvallisempia ja selkeämpiä kuin Swingin int-vakiot. Jos uusille näppäimille tulee tarve, lisätään KEY-enumiin sille vakio, joka lisätään myös seuraavaan switchiin
private KEY eventToKey(KeyEvent e)
{
switch(e.getKeyCode())
{
case KeyEvent.VK_UP:
return KEY.UP_KEY;
case KeyEvent.VK_DOWN:
return KEY.DOWN_KEY;
case KeyEvent.VK_RIGHT:
return KEY.RIGHT_KEY;
case KeyEvent.VK_LEFT:
return KEY.LEFT_KEY;
case KeyEvent.VK_ESCAPE:
return KEY.ESCAPE;
case KeyEvent.VK_ENTER:
return KEY.SELECT;
case KeyEvent.VK_F5:
return KEY.SAVE;
case KeyEvent.VK_SHIFT:
return KEY.RUN;
default:
return null;
}
},
minkä jälkeen kuuntelija tuntee kyseisen vakion.
Sisältöluokka tarjoaa abstraktit Present() ja Update() - metodimääritykset. Luokan paintComponent() kutsuu näitä, antaen Presentille parametreina millisekunteina edellisestä päivityksestä kuluneen ajan ja grafiikkakontekstin, sekä Updatelle pelkän ajan. Presentin tarkoitus olisi piirtää ikkunan sisältö, ja Updaten pitäisi päivittää pelitilanne.
Tällainen arkkitehtuuri mahdollistaa sen, että sisältöluokasta voidaan periyttää oma luokka, jonka konstruktorissa ladataan media sisältöluokan kokoelmiin, luodaan pelin tila jonnekin mallitasolle, joka yhä odottaa kirjoittamistaan, ja jonka present-metodi hakee mallilta tilan ja piirtää sen, sekä antaa updaten päivittää mallia piirron jälkeen. Tämän jälkeen muutetaan ikkunan luonnissa, main-metodissa, sisältö-olion määritys vastaamaan uutta luokkaa, ja kaiken pitäisi toimia suoraan. Ei tarvitse huolehtia ikkunan luonnista.
Saturday, 3 March 2012
Jaarittelua Pröngistä
Teinpä lopultakin sinne etusivun. Viitaten lupaukseeni tehdä se palattuani kauniiseen suomeen, voidaan siis päätellä suomen kaunistuneen merkittävästi kevään ensimmäisen sväärin alettua.
Juu, eli etusivulle tuli tervetulotoivotus, uusimmat luonnokset paljastava widgetti, sekä uusimmat kommentit paljastava widget. Laudalta ei ollut järkeä tulostaa uusimpia viestejä, koska lauta omaa nykyään topicit, eikä ole yksinäinen jono viestejä. Mietin että voisi rakentaa widgetin, joka tulostaisi topicit, joihin on tullut uusimmat viestit, mutta se kaatui siihen että tietokannan suunnitteli joku idiootti viime kesänä. Nykyinen rakenne ei taivu sellaiseen... tosin jos laittaisi topictauluun kentän ilmaisemaan uusimman viestin aikaleimaa, ja tämä kenttä päivitettäisiin aina topicin saadessa uuden viestin....
Joka tapauksessa, jos joku toivoo jotain dataa näkyviin etusivulle, nyt olisi hyvä hetki lausua ajatuksensa. Ajattelin seuraavaksi laittaa keskustelujen viestien aikaleimat näkyviin, nämä aikaleimat löytyvät kyllä tietokannasta, mutta jostain syystä niitä ei tulosteta. Sen jälkeen voisin tutkia vakavissani noita topicien viimeisten viestien aikoja. Kun väsyn laudan tekemiseen, implementoin lopultakin luonnostagit. Tietokannassa on alusta asti ollut valmiina rakenteet niille, mutta niistä on tullut ominaisuus, johon keskityn kun ehdin. Jossain vaiheessa pitäisi rakentaa myös tarkistus tuplapostien välttämiseen tarkastus, ettei käy kuin tämän kommenteissa.
Koska Pröngin tehtävä on täyttää tosi pienen piirin sosiaaliset vaatimukset, voivat palvelun vaatimukset elää mielivaltaisesti. Jos joku on odottanut rekisteröitymismahdollisuutta, joudun pettämään teidät. Joskus tulevaisuudessa vieraskommentointi ja postailu laudalle saatetaan sallia, mutta rekisteröitymismahdollisuutta pitää pyytää minulta kasvotusten.
Lounastin Tässin kanssa tässä viikolla. Lounaan keskustelujen tuloksena päätimme myös että blogisuunnitelman voisi tappaa, sillä lauta taipuu käytännössä samaan kuin Fairandcruelin blogit. Okei, WYSIWYGiä ei ole, eikä muotoiluja taida olla toteutettu laisinkaan, mutta nyt olisi hyvä hetki vihjailla millaisiin muotoiluihin luonnosten, kommenttien ja viestien pitäisi taipua. Kursiivi, lihavointi ja linkit pitäisi ainakin toteuttaa olemassaolevan LIDxxx - syntaksin rinnalle.
Muita ajatuksia Pröngistä?
Juu, eli etusivulle tuli tervetulotoivotus, uusimmat luonnokset paljastava widgetti, sekä uusimmat kommentit paljastava widget. Laudalta ei ollut järkeä tulostaa uusimpia viestejä, koska lauta omaa nykyään topicit, eikä ole yksinäinen jono viestejä. Mietin että voisi rakentaa widgetin, joka tulostaisi topicit, joihin on tullut uusimmat viestit, mutta se kaatui siihen että tietokannan suunnitteli joku idiootti viime kesänä. Nykyinen rakenne ei taivu sellaiseen... tosin jos laittaisi topictauluun kentän ilmaisemaan uusimman viestin aikaleimaa, ja tämä kenttä päivitettäisiin aina topicin saadessa uuden viestin....
Joka tapauksessa, jos joku toivoo jotain dataa näkyviin etusivulle, nyt olisi hyvä hetki lausua ajatuksensa. Ajattelin seuraavaksi laittaa keskustelujen viestien aikaleimat näkyviin, nämä aikaleimat löytyvät kyllä tietokannasta, mutta jostain syystä niitä ei tulosteta. Sen jälkeen voisin tutkia vakavissani noita topicien viimeisten viestien aikoja. Kun väsyn laudan tekemiseen, implementoin lopultakin luonnostagit. Tietokannassa on alusta asti ollut valmiina rakenteet niille, mutta niistä on tullut ominaisuus, johon keskityn kun ehdin. Jossain vaiheessa pitäisi rakentaa myös tarkistus tuplapostien välttämiseen tarkastus, ettei käy kuin tämän kommenteissa.
Koska Pröngin tehtävä on täyttää tosi pienen piirin sosiaaliset vaatimukset, voivat palvelun vaatimukset elää mielivaltaisesti. Jos joku on odottanut rekisteröitymismahdollisuutta, joudun pettämään teidät. Joskus tulevaisuudessa vieraskommentointi ja postailu laudalle saatetaan sallia, mutta rekisteröitymismahdollisuutta pitää pyytää minulta kasvotusten.
Lounastin Tässin kanssa tässä viikolla. Lounaan keskustelujen tuloksena päätimme myös että blogisuunnitelman voisi tappaa, sillä lauta taipuu käytännössä samaan kuin Fairandcruelin blogit. Okei, WYSIWYGiä ei ole, eikä muotoiluja taida olla toteutettu laisinkaan, mutta nyt olisi hyvä hetki vihjailla millaisiin muotoiluihin luonnosten, kommenttien ja viestien pitäisi taipua. Kursiivi, lihavointi ja linkit pitäisi ainakin toteuttaa olemassaolevan LIDxxx - syntaksin rinnalle.
Muita ajatuksia Pröngistä?
Friday, 24 February 2012
Sosiaalista Kehitystä, tai jotain
Koska seuraan muotia, ja halusin uudelleenkokeilla sitä mitä harrastin jo Pröngin kanssa syksyllä, on MERPGillä nyt oma sivu naamakirjassa. Sinne sitten tulee hehkutuksia saavutuksista nopeammalla tahdilla kuin tänne blogiin, joka noudattaa perinteistä, nykyään kolme kertaa vuodessa päivittyvän CB-blogin linjaa, jossa tekstejä kirjoitellaan kun jotain tosi suurta on tapahtunut.
Noh, nyt on jotain suurta tapahtunut. MEMAPPERin kolmas iteraatio on saavuttanut sen pisteen, jossa jotain on sopivaa julkaista. En noudattanut julkaisun kanssa kuitenkaan vanhaa periaatetta, jossa olisin upannut zipin FTP:llä _johonkin_ ja linkannut urlin fairandcrueliin. Sen sijaan rekisteröin itseni Sourceforgeen, jonne uppasin käännetyn ohjelman lisäksi lähdekoodin Netbeans - projektina. Koska sourceforge tukee Mercurial - versionhallintaa (...itse asiassa niin paljon, että ainoa tapa saada lähdekoodit on kloonata memapper-projekti sourceforgen repositorystä...), pysynevät Dropboxissa sijaitseva lähdekoodipaketti ja julkinen koodi hyvin synkronoituina.
Sourceforgen etu vanhaan verrattuna on myös yhteisölliset työkalut, jotka se tarjoaa. Siinä missä f&cssä globaalille laudalle luotiin projektille pyhitetty topic, sourceforge tarjoaa projektikohtaisen laudan, jonne voi luoda pienemmille, projektiin liittyville aiheille topiceja. En ole vielä aivan varma kannattaisiko meidän pysyä Pröngin laudalla vai siirtyä tuonne, mutta Fairandcruelista on oikeasti aika ajanut ohi.
Projektiin voi luoda myös pienen wikin. Sitä tulen ehdottomasti hyödyntämään (kun ehdin :D), sillä se voittanee klassisen word-dokumentaation. Wikiin pitäisi kirjoitella ohjelman käyttöohjeiden lisäksi myös ohjelman /lib - kansiossa olevan kirjaston käyttämisestä, siltä varalta että joku haluaa käyttää nykyistä versiota MEMAP-kartoista jossain omassa java-projektissaan.
Joka tapauksessa, jos kuulutte potentiaaliseen käyttäjäryhmään, ladatkaa MEMAPPER täältä ja testailkaa karttojen tekoa. Sen jälkeen antakaa minulle palautetta.
Noh, nyt on jotain suurta tapahtunut. MEMAPPERin kolmas iteraatio on saavuttanut sen pisteen, jossa jotain on sopivaa julkaista. En noudattanut julkaisun kanssa kuitenkaan vanhaa periaatetta, jossa olisin upannut zipin FTP:llä _johonkin_ ja linkannut urlin fairandcrueliin. Sen sijaan rekisteröin itseni Sourceforgeen, jonne uppasin käännetyn ohjelman lisäksi lähdekoodin Netbeans - projektina. Koska sourceforge tukee Mercurial - versionhallintaa (...itse asiassa niin paljon, että ainoa tapa saada lähdekoodit on kloonata memapper-projekti sourceforgen repositorystä...), pysynevät Dropboxissa sijaitseva lähdekoodipaketti ja julkinen koodi hyvin synkronoituina.
Sourceforgen etu vanhaan verrattuna on myös yhteisölliset työkalut, jotka se tarjoaa. Siinä missä f&cssä globaalille laudalle luotiin projektille pyhitetty topic, sourceforge tarjoaa projektikohtaisen laudan, jonne voi luoda pienemmille, projektiin liittyville aiheille topiceja. En ole vielä aivan varma kannattaisiko meidän pysyä Pröngin laudalla vai siirtyä tuonne, mutta Fairandcruelista on oikeasti aika ajanut ohi.
Projektiin voi luoda myös pienen wikin. Sitä tulen ehdottomasti hyödyntämään (kun ehdin :D), sillä se voittanee klassisen word-dokumentaation. Wikiin pitäisi kirjoitella ohjelman käyttöohjeiden lisäksi myös ohjelman /lib - kansiossa olevan kirjaston käyttämisestä, siltä varalta että joku haluaa käyttää nykyistä versiota MEMAP-kartoista jossain omassa java-projektissaan.
Joka tapauksessa, jos kuulutte potentiaaliseen käyttäjäryhmään, ladatkaa MEMAPPER täältä ja testailkaa karttojen tekoa. Sen jälkeen antakaa minulle palautetta.
Friday, 3 February 2012
Hyvää uuttavuotta ja sillee
Julkaisin sitte Pröngin uuden vuoden aikaan! Ongelmana Pröngissä on vain se, että se on varjo suunnitellusta. Blogeja? Ei ole! Rekisteröintimahdollisuus? Ei ole! Luonnostagit? Ei niitäkään! Mutta ne mitä on, AJAXiin perustuvat luonnokset ja kehittyneempi lauta, ne vasta ovatkin kauniita. Kun innostun taas PHP:stä, teen sinne heti alkuun vanhaa etusivua muistuttavan etusivun ja korjaan merkistökoodaushäröt. Sen jälken pitäisi perehtyä laudan aikaleimoihin ja luonnostageihin.
Aloitin tammikuun puolessa välissä työssäoppimisen eräässä softapajassa. Tehtäväkseni siunaantui PHP-keskustelupalstaohjelmien tutkiminen ja viilailu. Se on ollut silmiä avaavaa. Koulussa vietettiin vuosi opiskellen miltä näyttää hyvä koodi, ja jos joku joskus tulee muokkailemaan minun koodejani niin hän tulee kiittämään minua siitä, ja sitten päädyn oikeaan elämään, jossa ainakin phpBB on aivan kaameaa koodia. Pröngin kanssa pelatessa olen tottunut siihen, että tiedostoihin rakennetaan joko näkymät tai logiikkaa. Ei molempia, eikä missään nimessä sotketa mukaan dataa tai sen hakulogiikkaa. Lisäksi jokaisen tiedoston rooli on tarkoin määritelty. Oikeassa elämässä on ohjelmia, jotka noudattavat samoja periaatteita, mutta ainakaan phpBB, jonka olen ymmärtänyt olevan melko suosittu ja pidetty käyttäjien ja ei-ohjelmoivien ylläpitäjien keskuudessa, ei todellakaan noudata. Siinä tiedostoja on paljon ja suurin osa tiedostoita on tuhansien rivien mittaisia. Yksikään näistä jättiläisistä ei ole esim. laaja luokka tai hiton iso funktiokirjasto, jota olisi voinut pätkiä, vaan ne ovat proseduaalista, ylhäältä alaspäin kulkevaa logiikkaa. Kuten voitte arvata, tämä tarkoittaa myös sitä että tiedostojen vastuut eivät ole yksinkertaisia, vaan mm. posting.php hoitaa postinkirjoituslomakkeen luonnin, postin asetusten parsimisen, postin tallentamisen, muokkauksen, poistamisen, ja oikeuksienhallintakin on spagettina ympäri koodia täysin abstraktoitumattomana.Oli kieltämättä melko järkytys että softa, jonka käyttö on ollut ihan kivaa, on tuollainen hirviö koodiltaan.
Sitäpaitsi, en tiedä paljonko sitä olen blogissa hehkuttanut (en varmaan paljoa, kun en ole mitään muutakaan turhan paljoa hehkuttanut :D), mutta ilmoittauduin viime syksynä taitajakisojen verkkosivujen tuottamisen sarjaan. Semifinaalipäivä oli perjantaina, enkä sanoisi että tuotokseni olivat mitään hyviä, mutta pääsin kuudenneksi, ja kun kahdeksan parasta pääsevät Jyväskylään kisaamaan, niin sinne vie myös minun tieni huhtikuussa. Sieltä viimeistään tullee jotain raporttia, ellei huominen Yö tuo jotain uutta MERPGin suhteen.
(Viime vuonna taisin luvata olla aktiivisempi D&W:n puolella, ja se johti siihen että molemmat blogit hiljenivät. Jos tänä vuonna lupaisi olla lupaamatta mitään, niin tiedä vaikka saisi jotain aikaiseksikin :P)
Aloitin tammikuun puolessa välissä työssäoppimisen eräässä softapajassa. Tehtäväkseni siunaantui PHP-keskustelupalstaohjelmien tutkiminen ja viilailu. Se on ollut silmiä avaavaa. Koulussa vietettiin vuosi opiskellen miltä näyttää hyvä koodi, ja jos joku joskus tulee muokkailemaan minun koodejani niin hän tulee kiittämään minua siitä, ja sitten päädyn oikeaan elämään, jossa ainakin phpBB on aivan kaameaa koodia. Pröngin kanssa pelatessa olen tottunut siihen, että tiedostoihin rakennetaan joko näkymät tai logiikkaa. Ei molempia, eikä missään nimessä sotketa mukaan dataa tai sen hakulogiikkaa. Lisäksi jokaisen tiedoston rooli on tarkoin määritelty. Oikeassa elämässä on ohjelmia, jotka noudattavat samoja periaatteita, mutta ainakaan phpBB, jonka olen ymmärtänyt olevan melko suosittu ja pidetty käyttäjien ja ei-ohjelmoivien ylläpitäjien keskuudessa, ei todellakaan noudata. Siinä tiedostoja on paljon ja suurin osa tiedostoita on tuhansien rivien mittaisia. Yksikään näistä jättiläisistä ei ole esim. laaja luokka tai hiton iso funktiokirjasto, jota olisi voinut pätkiä, vaan ne ovat proseduaalista, ylhäältä alaspäin kulkevaa logiikkaa. Kuten voitte arvata, tämä tarkoittaa myös sitä että tiedostojen vastuut eivät ole yksinkertaisia, vaan mm. posting.php hoitaa postinkirjoituslomakkeen luonnin, postin asetusten parsimisen, postin tallentamisen, muokkauksen, poistamisen, ja oikeuksienhallintakin on spagettina ympäri koodia täysin abstraktoitumattomana.Oli kieltämättä melko järkytys että softa, jonka käyttö on ollut ihan kivaa, on tuollainen hirviö koodiltaan.
Sitäpaitsi, en tiedä paljonko sitä olen blogissa hehkuttanut (en varmaan paljoa, kun en ole mitään muutakaan turhan paljoa hehkuttanut :D), mutta ilmoittauduin viime syksynä taitajakisojen verkkosivujen tuottamisen sarjaan. Semifinaalipäivä oli perjantaina, enkä sanoisi että tuotokseni olivat mitään hyviä, mutta pääsin kuudenneksi, ja kun kahdeksan parasta pääsevät Jyväskylään kisaamaan, niin sinne vie myös minun tieni huhtikuussa. Sieltä viimeistään tullee jotain raporttia, ellei huominen Yö tuo jotain uutta MERPGin suhteen.
(Viime vuonna taisin luvata olla aktiivisempi D&W:n puolella, ja se johti siihen että molemmat blogit hiljenivät. Jos tänä vuonna lupaisi olla lupaamatta mitään, niin tiedä vaikka saisi jotain aikaiseksikin :P)
Subscribe to:
Posts (Atom)