Opetus 12: Virheiden käsittely

Tämä saattaa olla oppimistani tärkein: Virheiden käsittely ja -raportointi. PHP on tehty käyttäjälleen / ohjelmoijalle varsin helpoksi. PHP:stä voi sanoa melkein ihan samaa mitä sanoin nykyajan selaimista.

PHP suorittaa melkein mitä ohjelmakoodia tahansa kunhan rivi päättyy puolipisteeseen

No, saattaa olla, että lausunnossa on hieman liioittelua. Mutta joka tapauksessa PHP on hyvin virhesietoinen, ja oletuskonfiguraatioilla (ainakin Linuxissa) ei ohjelmoijaa juuri häiritä turhilla virheilmoituksilla. Tähän minäkin tuudittauduin ja ajattelin, että kun ohjelma koodi menee läpi, on koodi valmista. Asiaan hieman perehdyttyäni voin todeta: höpöhöpö. Vaikka ohjelmakoodi menee hienosti läpi, ja se näyttää jopa tekevän mitä koodaaja ajatteli, voi pinnan alla muhia melkoinen virheiden suma. Siispä suosittelen muutamaa temppua, millä tähänkin ongelmaan voi puuttua.

1. Tutustu ohjelmointikielesi ja -alustasi tarjoamiin virheenkäsittelyrutiineihin.
   
2. Kehitysympäristössä suosittelen, että virheiden raportointi tapahtuu ruudulle (ja varmista, että myös mitättömät varoitukset raportoidaan). Luultavasti kannattaa jälkiselvittelyn kannalta kirjoittaa kaikki virheet myös logitiedostoihin.
   
3. Tuotantojärjestelmässä virheitä ei tietenkään kannata raportoida käyttäjän ruudulle. Mutta pidä raportointitaso tiukkana - eli pienimmätkin varoitukset talteen. Ja loggaa kaikki virheet ja varoitukset logitiedostoon.
4. käy läpi tuota logia säännöllisesti (ja mahdollisimman usein).

Tästä seuraa se, että keskeneräinen koodi jää julkaiseematta.

Ja kun olet mielestäsi valmis, kirjaantuu testauksen ohi päässeet virheet logeihin, mistä ne on jälkikäteen helppo huomata JA korjata.

Mutteri.com:ista voisi kertoa muutaman hyvän esimerkin. Kun käänsin loggaus tasot sellaisiksi, että varoituksetkin näytetään, huomasin kuinka paljon pieniä virheitä olin tehnyt. Suurin osa virheistä oli lähinnä kosmeettisia (kuten viittauksia taulukon indekseihin joita ei ollut alustettu tai olemassa) mutta muutamia pahojakin löytyi. Toinen esimerkki sattui kun olin saanut kaikki virheet (mielestäni) korjattua. Siirsin taas totuttuun tapaan koodin tuotantopalvelimelle. Loggaus on siellä ohjattuna logitiedostoon. Parin päivän kuluttua kävin katselemassa logeja. Yllätyksekseni logeihin oli muutama rivi ilmestynyt. Kuinka ollakaan, yksi virhe pisti silmään: Virhe tuli sivulta, minne ei normaalioloissa käyttäjä menisi [tai pitäisi voida mennä] ja tuo oli tapahtunut keskellä yötä suomalaista aikaa. Virhettä selvittäessäni huomasin virheen autentikoinnissa yhdellä sivulla. Ja tuon virheen seurauksena robotti (näin ainakin luulen käyttäytymisen perusteella) oli sivua käynyt pari kertaa ihmettelemässä. Ei muuta kuin samantien sormet koodiin ja virheet ojennukseen - tulipa siinä samalla katselmoitua koko koodi vastaavien virheiden varalta. Eli

• robotti oli päätynyt sellaiseen paikkaan minne en uskonut sen pääsevän.
  
• Ja koska luulin, että autentikointi oli ok, oli tuo jäänyt huolellisen testaamisen ulkopuolelle.
  
• Ja kuinka ollakaan siellä tuli PHP varoituksia, mitkä kirjautuivat logiin.

Kun loggaus on kunnossa ja varoituksia ei normaalisti tule - löytyy virhelogeista kummallisuuksia mitkä muuten saattaisivat jäädä huomaamatta.

Tarinan opetus on siis

• Älä piilota virheitä ja varoituksia kehitysvaiheessa.
  
• Tuotantovaiheessa kirjaa pienimmätkin virheet / varoitukset logeihin.
• Seuraa logejasi säännöllisesti ja riittävän usein.

Lisää toiminnallisuuksia: CSV tiedoston käsittely

Sainpahan valmiiksi toiminnallisuuden millä käyttäjät voivat ladata useampia ilmoituksia kerralla. Toteutus nojaa CSV tiedostoihin. CSV:n käyttöön vaikuttivat useat eri tekijä. Ensinnäkin halusin luoda toiminnallisuuden joka helpottaa ilmoitusten jättäjien elämää. Itse olen vakaasti sitä mieltä, että Excelin (tai vastaavan taulukkolaskentaohjelman) käyttö on helpompaa ja nopeampaa kuin esimerkiksi Web lomakkeiden. Leikkaa-liimaa sujuu taulukkolaskentaohjelmalla helposti ja nopeasti.

Mutta miksi CSV? Onhan tarjolla muitakin formaatteja, kuten Excelin oma natiivi formaatti, samoin kuin OpenOffice spreasheetin käyttämä avoin formaatti. XML olisi myös ollut aika luonnollinen valinta. Koska itse teen sovelluskehitystä Linuxissa, ei minulla ole käytössä Microsoftin työkaluja [Excel on varmaankin ainoa Windows puolen sovellus mitä kaipaan]. Tämä siis sulki Excelin pois. Openofficen tukema avoin formaatti ei ilmeisesti ole täysin tuettuna Excelissä, joten sekään ei käynyt [www.mutteri.com:in käyttäjistä ylivoimainen enemmistö käyttää Windowsia]. XML on ehkä hieman liian monimutkainen peruskäyttäjälle [rehellisyyden nimissä voin sanoa, että ei se ole riittävän tuttu minullekaan]. Jäljelle jäi CSV, mikä on alustariippumaton, sitä tukevat useimmat taulukkolaskentaohjelmat, ja sen lukeminen palvelinpuolella olisi luultavasti helppoa, kun kyse on kuitenkin vain tekstitiedostosta.

CSV on alustariippumaton ja sitä tukevat useimmat taulukkolaskentaohjelmat.

Aloin tuon csv tiedoston parsimisen alkamalla kirjoittaa omaa funktiota aiheesta. Koska kyse oli tekstitiedostosta, ajattelin tehtävän olevan helppo. Eikä se vaikeaa ollutkaan, mutta ongelmaksi (tai suurityöiseksi) osoittautui virhetilanteiden käsittely ja syötteen validointi. Hetken asiaa pyöriteltyäni, aloin etsimään webistä josko joku olisi kirjoittanut valmiin funktion csv:n parsimiseen. Pienen googlailun jälkeen päädyin sivulle missä viitattiin ... php:n omaan csv tiedoston parseriin.

Tutustu aina ensin käyttämäsi ohjelmiontikielen tarjoamiin mahdollisuuksiin. Näin säästyt turhalta työltä.

Ja kuinka ollakaan, tuo valmis csv parseri teki kaiken mitä halusin - ja enemmänkin. Sitten vielä muutama rivi omaa koodia, omat validoinnit ja testaamaan. Omissa testeissä sain ladattua helposti 2000 riviä kerralla. Lataamiseen ei kulunut kuin muutama sekunti omalla kotikoneella joten olettamukseni on, että palvelin hoitaa homman vielä liukkaammin. Mutta koska tässä kului kuitenkin muutama sekunti halusin välttää mahdolliset konfliktit siltä varalta, että kaksi ihmistä yrittäisi syöttää tietoa systeemiin samaan aikaan.

Rajoitin tässä vaiheessa syötettävien ilmoitusten kertamäärän 50:een.

Toinen mitä onnistuin todistamaan (itselleni) tällä massalatauksella on se, että järjestelmän pitäisi kestää runsasta tietomäärää. Ehkä tietokantani on (kuten olen väittänyt) hyvin suunniteltu ja oikein indexoitu. [tulen varmasti käsittelemään tietokantasuunnittelua vielä erikseenkin.]

CSV tiedostolla tiedonlisääminen toi esiin kuitenkin uuden haasteen. Käytännössä csv tiedostolla lataaminen pitäisi olla sama asia, kuin usean erillisen web -lomakkeen lähettäminen peräkkäin. Nyt rakensin aika paljon päällekkäistä logiikkaa, jotta sain syötteen validoinnit edes suunnilleen samalle tasolle mitä ne ovat web lomakkeen käsittelyssä. Tähän on pakko tehdä muutoksia jatkossa, sillä en halua ylläpitää samaa koodia usempaan otteeseen.

Use cases vs. user experience - virheitä metsästämässä

Kuten jossain vaiheessa mainitsin kehitin järjestelmää tietynlaisella sovelletulla ad-hoc xp mallilla. Ensin ideoin, sitten koodasin toiminnon. Sen jälkeen testasin sitä niin paljon kun viitsin, pystyin ja jaksoin. Ja sitten vain koodi käyttöön.

Mikä tässä tavassa on hyvää:

1. Toimivaa koodia valmistuu koko ajan. Tämä mahdollistaa sen, että sovellusta voi kehittää omassa tahdissa. Tunti silloin tällöin toi aina uusia toiminnallisuuksia.
2. Perus "use case" tuli testattua aika hyvin. Eli toiminnallisuus teki juuri sen mitä sen oli tarkoituskin.
3. Motivaatio pysyi korkealla, kun näki käden jäljen koko ajan.
   

Kehitysmetodologiaa valittaessa arvioi omat mahdollisuutesi reagoida virheisiin ja syntyvän riskin tasosta. Jos teet sovellusta itsellesi, voit varmasti ottaa riskejäkin vapaammin.

Mikäs sitten oli huonoa:

1. Testaus oli/on ehdottoman vajavaista [tästä lisää myöhemmin]. Kuten sanottu, suurin osa testauksesta kohdistui juuri tuohon perus toimintaan. Mutta raja-arvoja ja virhetilanteita ei juurikaan tullut testattua. Tämä sopi hyvin tähän vaiheeseen ohjelmointia, missä prioriteetti oli saada toimivaa softaa ulos mahdollisimman pian.
2. Virheitä alkoi löytymään. Tämä on tietenkin seurausta vajavaisesta suunnittelusta ja puutteellisesta testaamisesta.
   

Se onko tämä ongelma riippuu sinusta, ja palvelun suosiosta. Jos pystyt reagoimaan virheisiin nopeasti, ei todellisia ongelmia pääse syntymään. Ja jos palvelu on vielä alkutaipaleella, ei imagollisia tappioitakaan juuri tule. Tämä on haastajan / pienen palvelun etuoikeus.

www.mutteri.com:in tapauksessa olin varautunut siihen, että lopullinen käyttötestaus tapahtuu vasta oikeilla käyttäjillä. Minä en ollut perehtynyt varsinaisesti testaamiseen, testausmetodologioihin tai testaustyökaluihin. Luotin siihen, että pieni tuntematon palvelu, jolla ei vielä ole hävittävää, saa paljon anteeksi.

Ensimmäiset parannukset: title-tag

Käyttötilastoja selatessani huomasin, että tilastoissa välkkyvät kryptiset URL:it eivät ole kovin helposti luettavia. Mistä ihmeestä minä muistaisin mikä "nimike" on label_id=22. Tämä on tärkeä huomio jos haluat että hakukoneet löytävät sivusi ja tulkitsevat ne oikein. Ei se ole hakukoneenkan helppoa tulkita ja pisteyttää sivuasi jos sieltä ei löydy kuvaavia tietoja.

Analytics työkalussa oli raportteja jotka olisivat pystyneet näyttää sivuvierailuja käyttäen html:n "title" -tagiä. Ensimmäisen vaiheen versiossa kaikilla sivuilla oli sama "title" tagi, joten tämä raportti oli käyttökelvoton.

HTML:n "title" -tag on erinomaisen tärkeä hakukoneille. Sivuotsikon tulee kuvata sivua mahdollisimman hyvin ja rehellisesti.

Ensimmäisenä muutoksena kävin muuttamassa palvelua niin, että tuo "title" -tagi kertoisi jotain olennaista (ja yksilöllistä) näytettävästä sivusta. Myöhemmin olen myös oppinut, että hakukoneoptimoinnin kannalta tämä "title" -tagi on erinomaisen tärkeä. Joten sattumalta lähdin oikeaan suuntaan.

Opetus 5: Tietokantasuunnittelu

Koska mutteri.com oli tarkoitus olla dynaaminen ja sisällöntuottajia olivat käyttäjät tuntui luonnolliselta tietovarastolta relaatiotietokanta. Vaatimus edullisuudesta ohjasi ilmaisen MySQL:n luokse. Tämä oli yksi palveluntarjoajan valintakriteereistä.

Suunnittele tietokantasi huolella

Minun ohjelmoinnin suunnittelu on aina ollut vajavaista. On niin paljon hauskempaa koodata kuin suunnitella. Tässä kohtaa poikkeuksen tekee tietokannat. Aikaisemman kokemuksen perusteella (www.mutteri.com ei ollut ensimmäinen sovellus mitä minä kehitin) oli jotain oppia mennyt kovanpuoleiseen päähän. Ja se oppi koski tietokannan suunnittelua. Koodia on erittäin helppo kirjoittaa uudestaan ja uudestaan. Ja vaikka tietokannan uudelleen suunnittelu on myös helppoa, tulee tietokantojen mukana epämiellyttävä ongelma: mitä tehdä olemassaolevalla datalle? Jos tietokantaa pitää uudelleen organisoida jatkuvasti, menee tarpeettoman paljon aikaa myös tiedon migrointiin (eli siirtämiseen vanhasta rakenteesta uuteen). Ja tämä on virhealtista hommaa.

Toinen tietokantasuunnittelun puolestapuhuva seikka on se, että hyvin suuunniteltu tietokanta sallii helpon laajennettavuuden. Voit siis pienellä vaivalla luoda uutta toiminnallisuutta ja hyödyntää jo tallennettua tietoa.

Onneksi olen aina ollut kiinnostunut relaatiotietokannoista ja niiden tarjoamista mahdollisuuksista (ja onpa sitä joskus yliopistolla tullut opiskeltuakin).

Tietokannat väitän suunnitelleeni hyvin.