Koodihommia

Digilasku on tehty täysin asiakkaan toiveiden mukaiseksi. Saimme asiakkaalta listan halutuista ominaisuuksista jotka priorisoimme. Lähdimme implementoimaan järjestelmää hyvin lyhyen (varmaankin noin kahden tunnin) suunnittelun jälkeen. Tarkoituksena oli scrum-tyyliin demota järjestelmää usein ja hakea siten lopullista muotoa. Homma ei aivan haluamallamme tavalla sujunut. Kesälomien takia pääsimme näyttämään järjestelmää vain muutaman kerran kolmen kuukauden aikana. Tämä vaikutti järjestelmään varmasti paljon. Käyttäjäpalautteen puutteen takia jouduimme arvailemaan toteutuksessa jonkin verran. Jotkut arvauksista osui oikeaan, toiset väärään. Käyttäjäkokemusten puuttuessa, teimme järjestelmän sisään oman osion, jossa käyttäjä voi kertoa parannusehdotuksista ja bugeista käytön ohessa. Tästä on ollut huomattavaa hyötyä, sillä olemme saaneet tätä kautta merkittävän osan bugiraporteista ja parannusehdotuksista. Asiakkaan mukaan kynnys yhteydenottoon on merkittävästi pienempi,

Tutkin diplomityössäni älypuhelinten hyödyntämistä maatalouskäytössä. Tutkimukseen liittyy GPS träkkäysohjelma, jota olen ollut kehittämässä jo lähes vuoden. Ohjelman tarkoitus on automatisoida maatalouteen liittyvän tyokirjanpidon muodostamista Ohjelman on pystyttävä seuraavaan maanviljelijän liikkeitä koko vuorokauden. Ohjelman virrankulutus on pidettävä sellaisena, ettei se kuluta koko akkua loppuun ainakaan kymmeneen tuntiin. GPS palvelu on siis pystyttävä katkaisemaan väliajoin eikä muu puhelimen käyttö saa katkaista träkkäystä. Android-implementaatiossani GPS kuuntelusta vastaa oma Androidin Service. Servicet sinänsä eivät ole erityisen soveltuvia tähän käyttöön, koska ne ajetaan samassa säikeessä muun ohjelman (käyttöliittymä) kanssa ja myös Servicen säie lopetetaan, jos laite menee näppäinlukkoon tai on käyttämättä jonkin aikaa. Ongelma ei poistu, vaikka Servicessä luotaisiin uusia säikeitä. Ratkaisuna käytin WakeLockia, joka mahdollistaa näytön sammumisen ja

Digilaskussa on jo nyt yli kaksikymmentä erilaista lomaketta. Syötekenttiä on noin 200. Yksi digilaskun onnistuneimpia osioita on näiden hallinta: syötekenttien validointi on pysynyt kohtuullisen hyvin kasassa. Jokainen lomake on omassa luokassaan, joka perii Vaatimen Form-luokan. Laskujen, lähetteiden ja tarjousten formit perivät vielä tätä ennen abstraktin luokan, joka määrittelee näille yhteiset ominaisuudet. Lähes kaikki formit käyttävät suoraan Vaatimen datamallia, eli Java Beanit tai POJOT asetetaan suoraan formeihin. Datan tallennus onnistuu siis helposti ilman manuaalisia parsimisia, sillä formista tulee suoraan ulos ehjä objekti tietokantaan tallennettavaksi. Formin syötekentissä käytetään useita erilaisia validaattoreita, jotka ovat myös omissa luokissaan. Syötekenttiä on yleistetty aina kun mahdollista, jotta vältytään perusvalidointien turhalta toistolta syötekentän luomisessa. Vaatimen vahvuuksia on ehdottomasti monipuolinen syötekenttien validointi. Päädyi

Lauantaina 8.12 Aki Salmi piti oikein miellyttävän koodaustapahtuman Turun ICT talossa. Coderetreatissa on tarkoituksena parantaa koodauksen perustaitoja ja kysenalaistaa pinttyneitä tapoja. Koodausongelmana oli mallintaa Conwayn Life-peli. Pelin säännöt ovat yksinkertaistettuna seuraavat (Wikipedia lainaus) Solu muuttuu eläväksi, jos sen naapureista tasan kolme on eläviä. Solu pysyy elävänä, jos sen naapureista tasan 2 tai 3 on eläviä. Muuten solu kuolee. Koodia kirjoitetaan aina 45 minuuttia kerralaan, ja tämän jälkeen pidetään 15 minuutin jälkipalaveri. Jokaisessa sessiossa on jonkinlainen rajoitus, esim. ei ehdollisia ilmauksia. Koodaaminen suoritetaan pareittan, jotka vaihdetaan joka session jälkeen. En ole tehnyt juurikaan parikoodausta ennen, mutta opin siihen uuden hauskan tavan. TDD Ping Pongissa ensimmäinen parista kirjoittaa testin, joka ei mene läpi. Toinen parista kirjoittaa testin läpäisevän koodin ja puolestaan kirjoittaa uuden testin, j

Keskustelimme asiakkaan kanssa, mitä mieltä he ovat Googlen pilvipalvelun käytöstä. Heillä ei ollut ongelmaa sielunsa myymisessä kansainväliselle yhtiölle. Asiakkaan tulevaisuudensuunnitelmiin ei kuulu oman hakukonepalvelun aloittamista, joten päätimme luottaa Googleen. Tietokanta on toki kryptattu, mutta kryptausavain on koodissa, joka on Googlen hallussa. Käytimme tietokantaratkaisuna App Enginen omaa NoSQL tietokantaa. App Enginen datastore tarjoaa JDO standardoidun DataNucleus merkintöjä syövän ORM tallennustilan. Päädyimme ratkaisuun, koska se nopeuttaa tietokannan suunnittelua. Toisena perusteena on helppo datan integraatio Vaatimeen, koska pystymme käyttämään POJOja sekä tallennukseen, että itse applikaation komponenteissa. Tietokannasta tuli melko "ei-relaatiomainen" ja lopulta aika huono. Suurta hämmennystä aluksi herätti App Enginen indeksointiquota. Kun testailimme aplikaatiota ensimmäisiä kertoja varsinaisella alustalla, ihmettelimme miksi indeksointio

Jee, uusi koodariblogi! Enpä usko, että voin tarjota lukijalle mitään tajuntaaräjäyttävää lukukokemusta. Voin kuitenkin tarjota kuivaa insinööritekstiä kokemuksistani ohjelmistokehityksen parissa. Insinööriteksti tekee elämästä kuitenkin niin paljon mielenkiintoisempaa, ainakin sitäkautta voi avautua ja purkaa kokemuksiaan muille samanmielisille. Aion ensimmäisissä postauksissani käsitellä toukokuussa 2012 aloitettua laskutus- ja asiakasrekisterijärjestelmäprojektia, joka on implementoitu yhteistyössä opiskelukaverini kanssa. Tarkoituksenani on kertoa kaikista kehtysprosessiin liittyvistä vaiheista koodauksesta käyttäjäkokemuksiin asti. Aloitan juttusarjani kertomalla hyvin paljon projektin käytännön implementoinitiin vaikuttavasta asiasta: App Engine alustasta. Meille oli projektin alkuvaiheesta lähtien selvää, että haluamme toteuttaa sen Vaatimella. Mitään järkevää syytä tälle ei ollut, ratkaisu oli enemmän mututuntumalla tehty. Siispä ensimmäisiä käytännön asi