Pröng ottaa osumaa taitaja-jutuista

Nyt on kevät: jo toinen blogiposti tulossa tänään!

Tarkoitukseni oli siis kerrata viime postissa mainitsemastani PHP-raamatusta enterprise- ja tietokanta-patterneja. Eihän siitä mitään tullut! Olin läpikäynyt pari ekaa patternia näistä luvuista, ja olin tajunnut mikä Pröngissä minua nykyään häiritsee: se alkaa taas muistuttaa hallitsematonta sekametelisoppaa. Tämän syy on helppo jäljittää: liian lepsu arkkitehtuuri. Miksi dataolioiden pitäisi hakea tietonsa erilliseltä tietokantakerrokselta, kun tietokantaan pääsee käsiksi suoraan perimällä DB - luokan? Noh, olisiko yksi syy se, että oikeassa elämässä ei ole dataolioiden tehtävä tehdä muuta kuin pitää dataa sisällään!? Lisäksi esim. Luonnos - luokan määritelmä (class Luonnos extends DB{}) kuulostaa äärimmäisen typerältä! Luonnos is-a DB? Mikä pälli pitää ihmisen olla päästääkseen tällaistä laadunvalvontansa läpi!?

Ylemmät on kuitenkin helppo refaktoroida, mitä hittoa se onkaan suomeksi. Tämä onnistuu tekemällä Tehdas-luokka, joka sylkee ulos dataoliota samanlaisella rajapinnalla kuin vanhat dataluokat ovat luoneet itseään. Samalla voisi selkeyttää vanhaa tietokantarajapintaa joko tarjoamalla suoraan puolisuojattua PDO-liittymää tai toteuttamalla joku datamapperi (select()->from() - pattern) joko suoraan tekstipohjaisena (jolloin tämä olisi käytännössä puolityyppiturvallista SQL:ää) tai jollain jännemmällä tyypityksellä, jossa tietokantaan menevään SQL-lauseeseen ei ulkopuolelta pääse suoraan käsiksi, vaan se muodostetaan parametrina tulevien olioiden pohjalta.

Pröngissä minua häiritsee myös useat sisääntulopaikat. Jos oikein innostun, refaktoroin kaiken liikenteen kulkemaan index.php:n kautta, näin luoden hyvän Front Controllerin käyttöömme. Tämä ratkaisu vaatisi Command - patternin hyödyntämistä, jonka jälkeen komennot ja näkymät eivät enää olisi riippuvaisia URLin osoittamasta tiedostosta ja $_GETiä sekä $_POSTia sörkkivistä ehtopuista, vaan rakentaisin seuraavanlaisen systeemin:

• Request-luokan abstraktoimaan suoran $_GETin ja $_POSTin nätin rajapinnan taa
• CommandResolverin, joka palauttaa parametrina saamastaan Request - oliosta päätellyn läjän Command - olioita, jotka Front Controllerimme sitten ajaa
• Lopulta Controller päättelee Command - olioiden käsittelemästä Requestista ( tai jos loogisia halutaan olla, pitäisi varmaan muodostaa Response - olio) mikä näkymä ladataan

Näkymät ovat myös yksi päänvaiva. Nämä ovat yhä melko sottaisia. Nämä pitäisi rakentaa niin, että näkymä on silkkaa HTML:ää. Tässä HTML:ssä sitten on linkit tyylisivuihin (joita voisi sovittaa näkymiin, sen sijaan että iskee kaikki tyylit samaan tiedostoon), sekä javascript-tiedostoihin (tällä hetkellä kaikki näkymälogiikka päivystää <head> - osan sisällä, document.ready():ssä). Javascript sitten hakisi palvelimelta XML:n ja populoisi staattisen html:n sen pohjalta. Lisäksi näkymistä pitäisi kaikki legacy-koodi portata jQuerylle.

XML:ää sylkevät sisällöntuottajatkin vaatinevat vähän refaktorointia. Niille pitäisi tehdä oma kontrolleri, joka päättelee Requestin, eli URL-parametrien, perusteella A) mitä tuottajaa haetaan B) Mitä parametreja sille annetaan. Tällaisen rakennelman jälkeen pitäisi olla suhteellisen helppoa tuoda luonnostuottajan rinnalle esim. lautatuottaja, joka sylkee XML:nä dataa liittyen keskusteluihin, tai mahdollinen kalendaarituottaja tai profiilituottaja, jos tarve vaatii.

Tämän jälkeen pitäisi taas Pröngin koodailun olla kivempaa. Ties vaikka laudan uudelleenkirjoittaisi niin että se jopa toimii :)

Taitajahahmotelmaa

Maanantaina olisi allekirjoittaneen tarkoitus lähteä Jyväskylään Taitaja-kisoihin puolustamaan koulumme, Suomen Liikemiesten Kauppaopiston, kunniaa verkkosivujen sarjassa... Täysin koulun ulkopuolella opiskelluilla PHP-taidoilla :D

Joku opettaja joskus lausui, että minun kannattaisi hahmotella jo julkaistuja tehtäviä etukäteen. Toivottavasti viimeinen viikonloppu ennen kisoja ei ole liian aikaisin! Noista tehtävistä tuoterekisterin pitäisi olla läpihuutojuttu: tietokantoja, tietokannan kanssa interaktointia ja käyttöliittymien suunnittelua on tullut viimeisten vuosien aikana harjoiteltua vaikka kuinka, välillä jopa koulussa. Siinä ei kuitenkaan ole paljoa hahmoteltavaa ja suunniteltavaa ennen kuin saan saan selville mitä yksityiskohtia tuoterekisterin tuotteista pitäisi tallentaa. Voisin valmistautua tuohon tehtävään kertaamalla PHP-patternraamatustani Enterprise- ja tietokantapatternit.

Tuota Windows Phone - tehtävää en uskalla paljoa kommentoida, sillä se tulee kuulemma muuttumaan ja runsaalti. Voisin vinkkien perusteella kuitenkin kerrata XML-LINQin ja XAML-perustaisten käyttöliittymien toiminnan. Koska en ole .NET - maailmassa paljoa seikkaillut sitten viime kesän, voi näiden kertaamiselle olla oikeaakin tarvetta. Väittäisin että nämä tulee kerratuksi lukemalla muutaman viikon vanhan Phone-raamatun ja jouluna hankkimani .NET - raamatun loppuun, ja jos eivät tule, on minulla koko sunnuntai aikaa harjoitella.

Joulukalenteri on sitten tehtävistä jännin. Mietin, että jos laittaisi keskisuomalaisen sivupalkkiin divin, johon tulostuisi tietokantaa hallinnoivalta luokalta saatu päivän tarjous, eli tarjousten syöttökäyttöliittymän muotoilemaa html:ää. Syöttöliittymä taas päättää merkitäkkö päivän tarjous videomatskuksi, kuva(sarjaksi), tekstiksi vai grafiikaksi. Noita pitänee vielä paikanpäällä hieman avata, tai ainakin pohtia että voiko yhteen tarjoukseen tulla kaikkia näitä, vai voidaanko olettaa että jos tarjouksessa on video, siihen ei tule staattista kuvaa, tai jos tarjouksessa on kuvasarja, siihen ei tule tekstiä, jne. Kuvasarjankin tekemisestä voi tulla hassua. Täytynee varautua myös HTML5-raamatu(i)llani ja kerrata <canvas> in käyttöä.

Toinen mietittävä on itse kalenterin käyttöliittymä. Keskisuomalaisen sivulle tulostuisi vähän muotoiltuna päivän luukku tarjouksineen (pitäisikö siihen rakentaa jokin luukku-animaatio?), ja tämän luukkuwidgetin kautta pitäisi ilmeisesti päästä myös kalenterisivulle, jossa on näkyvissä kaiki joulukuun aikana nähdyt luukut (avattuina? suljettuina?). Pitäisikö tästä kalenterista rakentaa yksinkertainen lista? Pitäisikö luukut sijoitella ympäri sivua satunnaisgeneraattoriin pohjautuen? Pitäisikö tähän rakentaa joku perinteistä joulukalenteria muistuttava näkymä?

Pohdinpa näitä. Kirjoitan lisää, jos innostun, kun jaksan :P

Hyvää uutta... tai jotain

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 :)

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:

• Lähtökartan tileä, josta siirtymä tapahtuu
• Kohdekarttaa, jolle siirtymä tapahtuu
• Kohdekartan tileä, jolle siirtymä tapahtuu

Ei pitäisi olla mikään paha toteutettava, edes käyttöliittymällisesti. Kiitos jollekin suunnittelijaparalle, tämä kevät eletään ilmeisesti ilman viimekeväisen kaltaista rakennehärösuunnitelmaa, joka sotki asiat kuukausiksi.

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ä!

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.

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ä?