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.

Sivun ulkoasun suunnittelu

Sivun ulkoasun suunnittelu on luonnollisesti yksi sivuston luomisen mielenkiintoisimmista vaiheista. Asettelu on teknisesti yksinkertaista (wysiwyg, html, jne) koska html kuvauskielenä helpohkosti opittavissa. Ulkoasu on yksinkertaisuudestaan huolimatta yksi tärkeimmistä tekijöistä millä sinä voit erottua muista sivustoista. Uskaltaisin melkein väittää, että sivuston ulkoasu on heti toiseksi tärkein seikka millä voit vakuuttaa käyttäjäsi palvelusi tuomasta lisäarvosta. Kaikkein tärkein on laadukas ja originaali sisältö. Jacob Nielsen [yksi web käytettävyyden pioneereista] on usein sanonutkin "Content rules" eli sisältö hallitsee.

Kun opettelet HTMLn saloja, tutustut CSS:ään, huomaat pian, että sivuston ulkoasun suunnittelussa vain taivas on rajana. HTML sallii sinun taittaa sivusi villeimpien haaveidesi ja visioidesi mukaisesti. Tätä nykyä on mahdollista sijoittaa sivulle melkein mitä tahansa mediaa (kuvia, musiikkia, videoita, sovelluksia [kutenMarcromedian flash]). Mutta varoituksen sana:

Se että jotain voi tehdä, ei tarkoita että sitä pitää tehdä, tai että sitä edes kannattaa tehdä.

Sivustoa suunnitellessa kannattaa tutustua käytettävyyteen ja tiettyihin internetin lainalaisuuksiin. Käytettävyydestä löytyy varmasti paljon materiaalia googlaamalla, mutta jos mitään muuta et jaksa / halua lukea, niin käy katsomassa Jacob Nielsenin ajatuksia useit.com:issa.

Jacob on käytettävyyden pioneeri ja hänen kirjoituksensa jopa 90 -luvun alusta ovat yllättäen yhä pääosin ajankohtaisia ja valideja.

Kehittelen siis www.mutteri.com:ia Linuxissa pyörivässä kehitysympäristössä. Laitteistoni ei ole viimeistä huutoa, joten käytän normaalisti resoluutiota 1280x1024. Mielestäni tämä on verrattain matala resoluutio, joten oletin että suurin osa käyttää ainakin tätä resoluutiota, ellei peräti 1600x1280. Olen kehittämisessä noudattanut Nielsenin oppeja mm. siinä, että sivuston taulukot on tehty skaalautiviksi (ei siis kiinteän levyisiksi, vaan leveydet on määritelty suhdelukuna selaimen leveyteen). Tällä saavutetaan normaalisti hyvä yleiskäytettävyys erilaisilla resoluutioilla. Mutta se mitä en kehittäessäni ottanut huomioon on, että googlen mainosten aseettelu vaikuttaa merkittävästi siihen miten sivustoa voi skaalata. Koska en tietenkään näytä kehitysympäristössäni googlen mainoksia (itselleni), en nähnyt tuota vaikutusta ennenkuin sain aiheesta palautetta loppukäyttäjiltä. Sain kuulla, että sivu ei mahdu kokonaisuudessaan näytölle jos käyttäjällä on resoluutio 1024x768 (tai alhaisempi). Ensimmäinen ajatukseni oli: "no kyse on marginaaliryhmästä". Mutta varmistin asian käyttötilastoista, jotka kertoivatkin karua kieltä: 50% käyttäjistä käyttää 1024x768 resoluutiot.

Älä siis oleta, että tavallisten käyttäjien laitteisto vastaa omaa laitteistoasi.

Itse asiassa, suunnittele sivustosi kaikkein heikoimmalle kokoonpanolle - siten palvelet niin vanhoilla laitteilla selaavia kuin uusimpien laitteiden käyttäjiä.

Olet sivuston 8. kävijä. Laskuri nollattu 15.04.2002

Sivulaskurit ovat verrattomia. Niitä onneksi näkee aika harvassa nykyään. Jos tarkoituksesi on houkutella uusia uskollisia kävijöitä niin luultavasti huonoin keino on laittaa sivulle laskuri, joka kertoo ettei sivuja oikeasti kukaan käytä.

Tämäntyylisillä (kuten sivulaskuri) tempuilla on tarkoitus kertoa kävijöille, kuinka aktiivinen saitti on ja sitä kautta löytää uskollisia kävijöitä ja parantaa sivulatauksia / vierailu -suhdetta. Mutta ennenkuin ryhdyt heiluttelemaan suosion tunnuslukuja kaikille vierailijoille, kannattaa varmistaa että henkseleiden paukuttamiseen on aihetta.

www.mutteri.com:issa en juurikaan levittele tunnuslukuja vierailijoille. Siihen on yksinkertainen syy: vierailijoita ei yksinkertaisesti ole mielestäni riittävän paljoa, että kannattaisi sen suhteen tuulettaa. Tietenkin seuraan jatkuvasti sivuston käyttöä, ja tiedän koko ajan tarkkaan kuinka monta päivittäistä kävijää minulla on, kuinka monta sivua he keskimäärin lataavat jne.

Harkitsin pitkään paljastanko ilmoitusten yhteydessä sitä kuinka monta kertaa ao. ilmoitus on luettu.

Alunperin rakensin näyttölaskuri -toiminnallisuuden niin, että tieto oli saatavilla vain kirjautumalla järjestelmään sisään. Ajattelin, että käyttötilastot olisi hyvä lisäarvopalvelu, joka kannustaisi käyttäjiä rekisteröitymään [en missään vaiheessa suunnitellut rahastaa tällä tiedolla]. Mutta joko tuo ei ollut riittävän arvokas tieto, jotta sen takia oltaisiin haluttu rekisteröityä tai sitten en vain saanut viestiä läpi uusille vierailijoille. Niinpä päätin tehdä ilmoituksen näyttökerrasta sellaista tietoa, mikä näytettäisiin kaikille käyttäjille ilmoituksen yhteydessä.

Tässä kohtaa web maailmaa hyvin tuntevat kaverit saattavat tokaista mielessään: Nuo www.mutteri.com:in luvut ovat niin pieniä, että johan maailmalla seikkailevat hakurobotitkin tuottavat enemmän lukukertoja! Ja kaverit ovat tässä oikeassa. Halusin kuitenkin kertoa käyttäjille ihan oikeaa tietoa, enkä ylioptimistisia satuja, joten rakensin järjestelmään ominaisuuden joka kerää hakurobottien tietoja tietokantaan, ja varmistaa, että robotin vierailua ei lasketa ilmoituksen näyttökertoihin. Ei tämä mikään pomminvarma keino ole, mutta suurimman osan turhista sivulatauksista se kyllä jättää laskematta.

Kukaan ei halua olla sivustosi 9. vierailija viimeisen kahden vuoden aikana.

Älä siis näytä sivulaskureita tai muita liikennetietoja, ellei sinulla ole ihan oikeasti jotain kerrottavaa ao. tiedolla.

Opetus 11: Standardien Viidakko

Selainvalmistajat ovat tehneet webin käyttäjille suuren palveluksen rakentamalla html parserit niin virhesietoisiksi, että melkein mikä vain missä on "<" ja ">" -merkkejä, muokkautuu web sivuksi. Samalla kun palvelus on ollut suuri satunnaiselle surffaajalle, on se ollut enemmänkin karhunpalvelus koodaajille. Melkein kuka vaan, joka on joskus katsonut web sivujen sorsaa (source code), pystyy tuottamaan jonkinnäköistä html koodia. Itse kuulun juuri tähän "tehdessä oppii" -koulukuntaan.

Mutta kun alkaa ohjelman vääntäminen ja layoutien tekeminen sujumaan, sitä huomaa samalla minkälaista html sotkua tehdessään tuottaa. Siinä menee html standardit ja css standardit ja - versiot sekaisin sulassa sovussa. Ja kun selaimet pyrkivät palvelemaan käyttäjiä, ei ne juuri valita. Jos käyt katsomassa mutteri.com:in sourcea, huomaat, että ei se mitään siistiä ja standardia ole. Tässä pitääkin sanoa: tee niin kuin mä sanon, älä niin kuin minä teen.

Ttutustu html standardeihin, xhtml, xml, ja css:ään. Vertaile niiden tarjoamia mahdollisuuksia ja valitse itsellesi sopiva standardi ja noudata sitä mahdollisimman tarkasti. Seuraamalla standardia tarkasti, vältät varmasti ulkoasuun liittyviä ongelmia.

Ja mikä parasta, voit jättää sen "saitti toimii parhaiten IE:llä" disclaimerin laittamatta saitillesi.

Kyllä sitä toimivaa html:ää saa ilman standardien orjallista noudattamistakin varmaan aikaan, mutta itse uskon johdonmukaisen kuvauskielen noudattamisen olevan pitkällä aikavälillä kannattavaa.

www.mutteri.com:in kanssa olen hieronut html koodia niin moneen otteeseen, että ihan hirvittää. Ja koska koodia on aika paljon, ei tuloksena ole kovinkaan johdonmukainen html.

Siistin ja standardin koodin ylläpito ja debuggaus on melkein mukavaa puuhaa.

Jos tunnet nuo html ja css (ja muut) määritykset, pystyt helpommin päättämään mitä kannattaa tehdä html:llä ja mitä stylesheeteillä.

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.

Myydään: tuntematon kirpputori

Kuten jossain vaiheessa tuli esiin, jos haluat ansaita (edes jotain) palvelullasi, kannattaa rakentaa liiketoimintasuunnitelma. Tähän taiteenlajiin löytyy tietoa useista eri lähteistä. Ja jos havittelet riskirahaa hankkeesi kehittämiseksi, on raudanluja liiketoimintasuunnitelma yksi perusedellytyksistä. Minulla ei ole riskirahan haalimisesta kokemusta, joten jätän sen kommentoinnin ja selvittämisen muille; ainakin toistaiseksi.

Vaikka et kaipaisi ulkopuolista rahoitusta palvelusi kehittämiseen, on ihan aiheellista miettiä ja arvioida edellytyksiä rahan ansaitsemiselle. Kannattaa miettiä avoimin mielin minkälaisia tapoja sinulla voisi olla ansaita. Alla muutamia mitkä ovat mahdollisesti käväisseet mielessäsi:

• Mainostila. Tämä on näinä Googlen kulta-aikoina varmasti ensimmäinen mieleentuleva ansaintamalli. Googlen Adsense:n hyödyntäminen on tehty sivuston ylläpitäjälle erinomaisen helpoksi, joten tämä kannattaa ottaa vakavasti huomioon. Mutta Google ei tietenkään ole alansa ainoa toimija: Tradedoubler on tarjonnut mainostilan välityspalveluita jo pitkään, ja sitä näkee aika paljon sivustoilla käytettävän. Yahoo ja MSN haluavat haastaa Googlen, joten heillä on tietenkin omat mainosohjelmansa. Ja mikäänhän ei estä sinua myymästä suoraan mainostilaa halukkaille mainostajille.


• Jäsenyysmaksut. Kannattaa harkita onko sinun tarjoamasi palvelu niin elinvoimainen ja addiktiivinen, että ihmiset ovat valmiita maksamaan siitä, että pääsevät tarjoamaasi sisältöä lukemaan. Esimerkiksi Keltainenporssi.fi toimii tämäntyylisellä periaatteella. Tosin keltaisenpörssin varsinainen liiketoiminta lienee painetun lehden myymisessä.


• Lisäpalvelut. Ehkä voisit tarjota osan toiminnallisuuksista ilmaiseksi mutta lisäarvopalveluiden käytöstä pitäisi maksaa. Huuto.net tarjoaa jonkinverran maksullisia lisäarvopalveluita - kuten tunnistuspalvelu, näyteikkunat, jne.
• Tai ehkä Google ostaa palvelusi. Onhan joillekin yrityksille käynyt jopa niin. Mutta kannattaa tehdä hieman laajempi (kansainvälinen) kilpailijatutkimus, ennen kuin lähtee palvelua pystyttämään ostetuksi tuleminen mielessä. Tietääkseni Google ei ole vielä suomalaisia yrityksiä ostanut. Mahtaakohan sinulla olla sellaista pääomaa, minkä hankkiminen on helpointa ja halvinta ostamalla sinun palvelusi? Ellei sinulla ole asiakkaita, ei kukaan halua palveluasi ostaa. Miksi haluaisi?

www.mutteri.com siis perustuu puhtaasti harrastuneisuuteen ja mainostuloihin. Ennen kuin aloitin mutteri.com:in ei minulla ollut mitään aavistusta siitä kuinka paljon internet mainonnalla voisi tienata ja mitä esimerkiksi yksi klikkaus maksaa. Tästä kun koittaa tietoa etsiä ei sitä tahdo löytää. Kotimaisesta optimointifoorumista voi koittaa kaivaa jotain vihjeitä mistä rahoista puhutaan. Selvitystyötä ei helpota se, että Google ei suhtaudu kovin positiivisesti mainoksien maksuista puhumiseen.

Mainostulojen kannalta arvokkaita sivulatauksia ovat sellaiset, missä käyttäjä löytää sivultasi sen mitä hän etsii. Spammin perässä sivuillesi eksyvät tuskin klikkailevat mainoksiasi.

Paljastamatta kenenkään liiketoiminnan suuria salaisuuksia voisin kuitenkin antaa seuraavat arviointia helpottavat määreet:

• Noin 5% sivulatauksista johtaa mainoslinkin klikkaamiseen. HUOM: tämä riippuu tietenkin myös siitä millaista sisältöä tarjoat, miten olet mainokset sijoittanut ja kuinka paljon sivullasi on mainoksia
• Jokainen klikkaus "tuottaa" ehkä 10 senttiä, tai ehkä 5 senttiä

Triviaali laskutoimitus antaisi arvion: Jokainen 1000 sivulatausta tuottaa sinulle jotain 2.5 USD:n ja 5 USD:n välillä. Oman kokemuksen pohjalta sanoisin, että tuhat arvokasta sivulatausta (siis sellaista, missä käyttäjä oikeasti löytää sivultasi sen mitä hän etsii) on työn, työn ja työn takana.

Opetus 10: Järjestä teksti-elementit viisaasti

Jossain kohtaa tulee varmasti kaikille ylikunnianhimoisia tai megalomaanisia ajatuksia siitä kuinka suosituksi uusi palvelu voi kasvaa. Tässä kohtaa pitää miettiä millä kielillä palvelu pitää tehdä ja miten.

www.mutteri.com:in lähtökohta oli ehdottomasti tehdä siitä suomenkielinen. Mutta niin vain kävi minullekin, että kotimaisen markkinan pienuus alkoi askarruttaa. Sitä alkoi laskeskelemaan potentiaalia mitä maailmalla on. Katselin Adsense:stä saatuja tuloja (aiheesta lisää myöhemmin) ja vertailin niitä kävijämääriin ja potentiaalisiin kävijöihin. Suoraviivainen johtopäätelmä oli, että jos saisi palvelun tehtyä englanniksi ja lentämään Amerikassa, niin sitä voisi alkaa katselemaan itselleen eläkepaikkaa. Onnistuihan Craigslist kasvamaan todella suosituksi USA:ssa - ja jos tuota ulkoasua katsoo, niin se on vähintäänkin sekava.

No, onneksi oli minullakin realismia sen verran, että en ole lähtenyt leikkimään maailmanvalloitusta, kun Suomikin on jäänyt valloittamatta.

Mutta sehän ei haittaa ketään, jos rakentaa järjestelmään valmiuden monikielisyydelle.

Itseasiassa tässä piilee myös ohjelmointia helpottava seikka - jos pidät esityselementit (eli palvelun kieliasun) erillään itse ohjelmasta, on sanamuotojen ja tekstien muuttaminen jälkikäteen helpompaa, nopeampaa ja riskittömämpää kuin siinä tapauksessa, että tekstit ovat osana ohjelmakoodia.

Kieliresurssit voi hoitaa usealla eri tavalla, ja mutteri.com:in suhteen tuli tämäkin ratkaistua kahteen otteeseen.

• Ensimmäisessä vaiheessa pistin kaikki käännökset tietokantaan. Mikä sen loogisempi paikka? Mutta sen suhteen alkoi ilmetä ongelmia. Käytössä olevat työkalut eivät oikein suostuneet toimimaan luotettavasti ja mysql:n web pohjaiset hallintatyökalut jostain syystä rikkoivat UTF-8 enkoodauksen aina kun olin lisäämässä uutta elementtiä. Lisäksi tietokantaan uuden elementin luominen oli aina hieman hankalaa, ja kun sama elementti piti lisätä vielä tuotantojärjestelmään, oli tuska kaksinkertainen.


• Niinpä tuli ajankohtaiseksi siirtää layout -tekstit tietokannasta ns. kieliresurssi tiedostoihin. Tiedoston muokkaaminen on vaivatonta, ja siirtäminen tuotantopalvelimelle vaivatonta ja ongelmatonta.

Suosittelenkin siis, että vaikka et aikoisi tehdä palveluasi kuin yhdellä kielellä, kannattaa kieliresurssit pitää erillään ohjelmakoodista.

Uskon, että tällä vältät monta sudenkuoppaa ja monta turhaa virhettä jää tekemättä.

Opetus 9: Kerralla tuskin tulee valmista

Ainakin minulle tämä oli itsestäänselvyys, mutta se kuinka monta kertaa olen käynyt ja kahlannut koodin läpi on ollut taas yllätys. Mikäli päätät ohjelmoida samassa moodissa mitä minä olen tehnyt, kannattaa varautua siihen, että kirjoitat saman koodin monta kertaa.

Valmistaudu koodaamaan samat toiminnallisuudet useampaan kertaan.

Välillä on koodia siirretty pääohjelmasta funktiohin, ja sitten taas takaisin. Tämän voi mahdollisesti välttääkin, mutta väitän, että se onnistuu vain joko

• Huolellisella ja perinpohjaisella suunnittelulla


• Pitkällä kokemuksella


• tai näiden yhdistelmällä

Uudelleen koodaamisessa ei ole mitään vikaa - joka iteraatiolla koodin laatu luultavasti paranee ja luotettavuus kasvaa. Mutta tähän kuluu aikaa yllättävän paljon. Aina kun koodiin kosketaan, kannattaa se testata jollain tasolla. Jos et testaa, voi tulla odottamattomia yllätyksiä.

Kuinka ollakkaan, olin edellisellä kerralla koodia siivotessani onnistunut rikkomaan kuvan lisäys ominaisuuden.

Itselle kävi mm. siten, että ihmettelin miksei rekisteröityneet käyttäjät lisänneet kuvia. (no ihmettelen sitä välillä vieläkin, mutta se on hieman off-topic). Jonkin aikaa ihmeteltyäni, päätin varmistaa, että toiminnallisuus yhä toimii. Kuinka ollakkaan, olin edellisellä kerralla koodia "siivotessani" onnistunut rikkomaan kuvan lisäys ominaisuuden. Ei ihme, ettei kuvia tullut.

Opetus on siis se, että varaudu siihen, että samaa ohjelmakoodia pitää kirjoittaa useampaan kertaan.

Opetus 8: Syötteiden validointi

Vaikka sinä teetkin palvelua hyvällä tahdolla ja suurin osa internetiä käyttävistä ihmisistä on liikkeellä vilpittömin aikein, on olemassa pienen pieni vähemmistö jonka tarkoituksena on kartuttaa omaa mainettaan vahingoittamalla sinua. Jotkut moiset tahot (hakkerit ja krakkerit) selittävät tekojensa oikeutusta sillä, että he pyrkivät esimerkiksi tuomaan esini tietoturvan tärkeyttä konkreettisin keinoin. Henkilökohtainen mielipiteeni on, että tämän kaltaiset yritykset oikeuttaa vahingontekoa ovat silkkaa hevonpaskaa. Mutta koska moisia tahoja on olemassa, pitää sinun palvelua kehittäessäsi ottaa tämäkin huomioon.

www.mutteri.com:in tapauksessa olen törmännyt kahdenlaiseen vahingontekoon / -yritykseen.

1. Robotit, jotka seikkailevat pitkin Internetiä hakukoneiden tapaan etsien heikkoja sivustoja. Nämä harvemmin ovat kovin älykkäitä (tai ne mihin minä olen törmännyt ovat olleet verrattain yksinkertaisia). Näiden tarkoituksena on lähinnä syöttää järjestelmääsi tarpeetonta sontaa. Mutteri.com tapauksessa alkoi yhdessä vaiheessa järjestelmään tulla robotti käyttäjiä (rekisteröinnin kautta) ja turhia ilmoituksia (jotka ei vaadi rekisteröintiä).


2. Pahantahtoiset käyttäjät, jotka etsivät (käsin tai koneellisesti) heikkouksia ohjelmastasi tavoitteena esimerkiksi kaataa koko palvelu, tai esimerkiksi korvata etusivu jollain julistuksella.

Tuntemattomalle palvelulle, näiden aiheuttama haitta on pientä. Kun ei ole mainetta mitä menettää, ei sen suhteen tarvitse olla huolissaan. Mutta tämäntyyliset ongelmat helposti pitävät myös vilpittömät käyttäjät kaukana.

Syötteiden tarkistaminen on tärkeää virheiden karsimiseksi, ja pahantahtoisten vierailijoiden eliminoimiseksi.

Näitä kahta vastaan olen pyrkinyt taistelemaan kahdella helpohkolla aseella.

1. Kuvatunnisteet. Rekisteröitymisen yhteydessä käyttäjät joutuvat osoittamaan sen, että he ovat ihmisiä eikä koneita siten, että rekisteröitymissivulla on kuva mihin on kirjoitettu merkkijono. Rekisteröitymisen yhteydessä käyttäjän tulee syöttää tuo merkkijono henkilötietojen lisäksi. Suosittelen tämäntyylistä lisävarmistusta sivuille jossa voidaan syöttää tietoa järjestelmään ilman, että syöttäjä tunnistautuu (esim kirjautuu sisään).


2. Syötteiden validointi. Kaikki kentät mitä käyttäjät täyttävät lähettäessään tietoa järjestelmään käydään läpi tietyin säännöin (erityyliset kentät validoidaan eri säännöillä). Tällä pyritään varmistamaan, että järjestelmää ei esimerkiksi kaadeta tahallisesti.

Näiden validointien jälkeen on järjestelmä pysynyt turvassa robottien suhteen. Myöskään hakkerit eivät ole (vielä) vaivanneet.

En yritäkään väittää, että www.mutteri.com olisi hakkerivarma - en usko, että sellaista järjestelmää onkaan.

Mutta uskon, että varotoimenpiteet vähentävät ongelmia ja käsipelillä tehtävää siivousta. Huomaa, että roboteille on täysin yhdentekevää kuinka tunnettu tai tuntematon palvelusi on - niille kaikki on vapaata riistaa. Siksi syötteiden validointi on syytä hoitaa kuntoon jo alkutaipaleella.

Käyttäjätulva - missä sinä olet?

Tässä yksi kauppapaikkani suurimmista dilemmoista... kumpi oli ensin: muna vai kana?

Kumpi oli ensin muna vai kana? Tulevatko myyjät kun on käyttäjiä, vai käyttäjät kun on myyjiä?

Lähdin koko hommaan sillä ajatuksella, että käyttäjät (tai vierailijat) tulevat, kunhan torilla on ilmoituksia ja tavaraa myynnissä. Tämä oli myös yksi kehittämisen lähtökohta - systeemi pitää kehittää siten, että se on ilmoittajille helppo.

Mutta valitettavasti tässä piilee noidankehä. Miksi ilmoittaa kauppapaikalla, missä ei ole kävijöitä eikä kamalasti ilmoituksia. Ja jos siellä ei ole ilmoituksia, mistä ihmeestä niitä kävijöitä oikein tulisi.

Valitettavasti tuo dilemma on yhä akuutti. Eli pitäisi keksiä tapa millä tuo negatiivisin kierteen saisi rikottua.

Hienoinkin palvelu on turha, jos kukaan ei tiedä sen olemassaolosta.

Ajatuksia kyllä on, mutta niiden toteuttaminen vaatisi ponnisteluita millä alueella minulla ei juurikaan ole taitoja: Markkinointia. Markkinointiin varmasti palaan myöhemmin. Se on nimittäin sillä lailla, että hienoinkin palvelu on turha, jos kukaan ei tiedä sen olemassaolosta.

Opetus 7: Panosta käytettävyyteen

Jos luomasi palvelu on haastajana markkinalla missä on jo vakiintuneita toimijoita, on sinun löydettävä kilpailu etua pienimmistäkin asioista. Sinun pitää pystyä onnistua houkuttelemaan käyttäjät pois jo olemassa olevasta järjestelmästä - ja käyttämään sinun sovellustasi. Tämä tuskin onnistuu, jos sinun järjestelmääsi ei ole kehitetty käyttäjille.

Koko Web 2.0 buumi on tuonut (mielestäni) verkkopalveluiden fokukseen käytettävyyden.

Palvelun pitää olla helppokäyttöinen. Se että sinä olet valmis käymään läpi viisisivuisen rekisteröitymisprosessin, ei tarkoita sitä, että keskiverto käyttäjä olisi siihen valmis.

Käyttötilastot ovat erinomaisen tärkeä tiedonlähde palvelun parantamiseksi. www.mutteri.com tapauksessa olin ajatellut, että käyttäjä kulkisi seuraavanlaisen polun:

1. Klikkaa "Rekisteröidy" -linkkiä


2. Käyttäjät täyttää henkilötietonsa (joista vain osa oli pakollisia).


3. Käyttäjä viedään rekisteröinnin vahvistamissivulle


4. Käyttäjä kirjautuu järjestelmään sisään


5. Käyttäjä klikkkaa "Luo ilmoitus" -linkkiä

Mielestäni tuo flow oli selkeä, intuitiivinen ja pomminvarma. Mutta kun seurasin käyttötilastoja ja käyttökaavoja (tietolähteinä Google analytics, tietokanta, palvelimen logit) huomasin, turhan usein kävikin näin:

1. Käyttäjä rekisteröityi palveluun


2. Käyttäjä loi ilmoituksen

Melkein sama mitä minä olin ajatellut, paitsi että käyttäjät eivät kirjautuneet sisään rekisteröitymisen jälkeen. Muuten ihan hyvä, mutta koska he eivät olleet kirjautuneina sisään, jäivät he paitsi niistä lisäominaisuukista miksi he ylipäätään halusivat rekisteröityä (muokata ilmoituksia, lisätä kuva, poistaa ilmoitus, etc).

Mielestäni asialle piti tehdä jotain. Siispä mietin tulisesti missä vika on... minussa, palvelussa vai käyttäjissä. Enismmäisen karsin syyllisten listalta käyttäjät - palvelussa oli jotain vikaa. Havaitsin pari asiaa, kun tutkailin palvelua (muutaman kuukauden tauon jälkeen) tuoreilla silmillä.

1. Sisäänkirjautuminen oli mahdollista jokaiselta sivulta. Sivun oikeassa yläkulmassa oli kaksi kenttää ja "sisään" nappi. Kentillä ei ollut nimikettä (label), vaan olin toteuttanut tuon nimikkeen itse kenttään siten, että käyttäjätunnus kentässä luki oletusarvoinen sähköpostiosoite ja salasanakentässä luki "salasana" joka siis näkyi tähtimerkkeinä. Minulle tuo oli erittäin looginen juttu, mutta luulen, että käyttäjät sekoittivat tuon jonkinlaiseen "tilaa uutiskirje" toiminnallisuuteen (www.mutteri.com käyttäjätunnus on käyttäjän sähköpostiosoite).


2. Sisäänkirjautumis -lomakkeella ei ollut otsikkoa. En siis missään indikoinut, että näillä kentillä kirjaudutaan palveluun sisään. En kertonut missään mitä näillä kentillä tehdään.


3. Miksi palveluun pitää kirjautua erikseen sisään rekisteröitymisen jälkeen? Käyttäjähän on jo kertonut kertaalleen kaiken mitä sisäänkirjautumiseen tarvitaan. Muutin siis logiikkaa siten, että rekisteröitymisen yhteydessä ensin tallennetaan käyttäjän tiedot käyttäjätietokantaan - ja sen jälkeen heti perään kirjataan käyttäjä sisään käyttäen rekisteröintitietoja. Jos käyttäjä nyt heti rekisteröitymisen jälkeen luo ilmoituksen, luodaan se käyttäjän nimiin, ja hän pystyy hyödyntää rekisteröityneen käyttäjän lisäpalveluita.

Tyyliseikat ratkaisevat

Kehitys siis tapahtui Linux ympräistössä. Samoin tietenkin testaus. Testasin kaikilla käytössä olevilla selaimilla vähäsen. Ja mutteri.com näytti suunnilleen samalta kaikilla selaimilla. Tässä kohtaa tein yhden virheen - oletin [vaikka tiesin toisin], että Internet Explorer toimisi suunnilleen samalla tavalla. Koska minulla ei kotona ole Windows pohjaisia tietokoneita, pääsin testaamaan IE:llä vasta töissä, ja sekin tapahtui sattumalta.

Sillä hetkellä veret seisahtuivat. Palvelu näytti verrattain kamalalta (ja täysin erilaiselta) kun käyttelin IE:tä.

Muista testata valtaselaimilla. Vaikka IE 5 ja 6 ovat susihuonoja, on niiden osuus selainmarkkinoista maailmanlaajuisesti vielä ylivoimainen. Suomessakin IE pitää hallussaan noin 50% selainmarkkinoista.

Tämän hirveyden huomattuani oli aika ruvet siivoamaan tyylejä koodista. En koskaan (ennen tätä) ollut perehtynyt CSS:ään (cascading style sheets), mutta nyt oli senkin aika. Eli aloin siirtämään layoutteja pois ohjelma koodista. Tämä periaate on vanha ja tuttu (sovelluslogiikka ja User Interface pitää olla erillään), mutta se ei ollut minulle tärkeätä ennen tätä.

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 6: Webmetriikka

Valitetettavasti hommat ei lopu siihen, että palvelu on julkaistu. Normaalisti tässä kohtaa on valmiina vain pieni osa suunnitelluista/ajatelluista toiminnallisuuksista. Näin oli tietenkin mutteri.com:inkin kanssa. Tekemistä olisi ollut vielä vaikka kuinka.

Mutta tässä kohtaa kannattaa pitää pieni tauko omien ajatusten ja suunnitelmien toteuttamisessa. On aika varmistaa, että palvelua aletaan käyttää. Pitää seurata miten palvelua käytetään. On täysin mahdollista, että kuvittelemasi "maailman loogisin" toiminnallisuus ei olekaan niin itsestään selvä muille. Seurantaa voi tehdä usealla eri tavalla. Voit rakentaa oman loggerin, joka tallentaa kaiken mitä järjestelmässä tapahtuu [minä tein mm. tämän]. Voit seurata web-serverin logeja. Mutta viisas ottaa käyttöön valmiit työkalut. Itse otin googlen Analytics palvelun käyttöön. Se oli ilmainen (muitakin ilmaisia on, mutta niistä suurin osa pitää asentaa omalle palvelimelle). Googlen analytics tarjosi perusraportit juuri sillä tasolla mitä tässä vaiheessa tarvitsin.

Seuraa palvelun käyttöä heti alusta webmetriikka työkalujen avulla. Ole valmis hylkäämään omia hienoja ajatuksia, jos ne eivät toimi.

Tässä vaiheessa suosittelen sitä, että seuraat järjestelmän käyttöä ja muutat sovellusta sitä mukaan kun opit käyttötilastoista jotain. Eli vanha kunnon: yritys ja erehdys -strategia. Koska kävijämäärät ovat mahdolliseti alhaisia, ei muutosten seuraukset ole aina niin ilmeisiä, mutta ainakin sinun pitää pystyä havaitsemaan ongelmat käyttötilastoista.

Ensimmäinen versio valmis

Joskus heinäkuun lopussa sain ensimmäisen version valmiiksi ja tuotantokäyttöön. Ensimmäisenä tietenkin pistin omat romuni myyntiin.

Oli tietenkin selvää, että mitään ryntäystä saitille ei tullut. Eihän kukaan tiennyt mikä ihme se www.mutteri.com oikein on. Muutaman päivän seurailin liikennettä, mutta ei...

Muista ilmoittaa sivustosi hakukoneille. Hakukoneiden kautta tulee suurin osa uusista kävijöistä.

Googlailin lämpimäkseni eri hakusanoilla millä kuvittelin vierailijoiden saapuvan. Mutta Top 10:iin on vaikea murtautua. Esimerkiksi Kirpputori -hakusanalla www.mutteri.com oli jossain sijalla 200+. Eipä sinne saakka hakutuloksia kovin moni jaksa selata.

Positiivisena pilkahduksena voi todeta sen, että hakusana "kirpputori +tuote" yhdistelmällä alkoi tulla parempia sijoituksia googlessa.

Koska minulla oli tarve myydä tuotteet, pistin myynti-ilmoituksia myös ns. "kilpailijoiden" kanaviin, kuten uutisryhmiin jne. Jokaiseen ilmoitukseen tietenkin linkki mutteri.com:iin.

Tällä "kikalla" alkoi tulla satunnaisesti hieman enemmän kävijöitä. Mutta niitä kaikkia vaivasi sama "vika": Ne tulivat, lukivat sen ilmoituksen mitä etsivät ja poistuivat. Tämä ei tietenkään ollut mikään veret seisauttava yllätys, mutta kuvittelin että ns. "sticky" kävijöitä tulisi edes vähän paremmalla prosentilla.

Vääränlainen markkinointi tuo vääränlaisia vierailijoita.

Joskus elokuussa tuli ensimmäinen ihan rehellinen ostajakin - joku tiedusteli minulla myynnissä ollutta sohvaa. Viestissä oli viite juuri www. mutteri.com:iin.

Ensimmäisen viikon vierailijasaldo oli jossain 10:n erillisen kävijän tasolla (siis viikossa, ei päivässä).

Huomio ohjelmakoodista: Tässä vaiheessa ohjelmointi prioriteettini oli selkeä: saada jotain toimivaa käyttöön. Ohjelmakoodi oli hirveää (tietokanta oli ok).

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.

Design haasteita horisontissa

Kuten ideointivaiheessa tuli esille, minä en ole graafinen suunnittelija. Itse kukin haluaisi olla visuaalisesti erinomaisen taitava - moni saattaa jopa luulla olevansa. Tässä suhteessa olen ollut suhteellisen realistinen ja tunnistin sekä tunnustin omat rajoitukseni.

Yksi minulle suuria ongelmia aiheuttava alue on värimaailma. Minulla ongelma on suurempi kuin monilla muilla, sillä olen värisokea. Punaiset, vihreät, ruskeat ja oranssit menevät turhan helposti sekaisin. Koska minulla on ollut tällä saralla hieman haasteita, en ole siihen juurikaan perehtynyt edes niissä puitteissa mihin minulla olisi ollut mahdollisuuksia. Siispä en rehellisesti sanottuna osaa sanoa mitkä värit sopivat yhteen ja mitkä eivät.

Tikkurilan värilastuilla saitille toimiva väritys.

Mutta kun into on kovaa, niin hätä kyllä keinot keksii (vai mitenkäs se nyt menikään). Minä keksin Tikkurilan värilastut. Tikkurilalla on asiantuntijoita jotka kuluttavat aikaansa pohtimalla trendivärejä ja väriyhdistelmiä - miksi siis yrittää keksiä pyörää uudestaan. Hain Tikkurilan web-sivuilta värikartan ja siitä valitsin www.mutteri.com:in värimaailman.

Tuumasta toimeen

Nyt oli asiaa märehditty riittävästi. Suunnitelmat www.mutteri.com:ista olivat suunnilleen valmiit ja kaikki kritiikki oli sujuvasti unohdettu tai painettu villaisella. Päätös palvelun perustamisesta oli valmis. Sitten ei muuta kuin kehitysympäristö pystyyn Linux:iin, muutama rivi html:ää, php:ta ja tietokanta pystyyn. Eihän siinä sen kummempaa. Kaksi viikkoa (iltaisin) ja homma valmis... Tai sitten ei.

Arvioin kehittämisen vaatiman ajan todella pahasti väärin. Pyrin koodaamaan jonkinlaisessaa sovelletussa XP eli extreme programming moodissa, missä aina tehtiin yksi toiminnallisuus valmiiksi, niin sitä pientä tekemistä vain riitti ja riitti ja riitti (ja riittää yhä). Jossain kohtaa kirjoittelen lisää kehitysmetodeista(ni) ja kaikesta mitä siinä olen oppinut.

Tässä kohtaa elettiin muistaakseni kesä-heinäkuuta 2006.

Kehitysympäristö
Kehitysympäristönä käytän Linux Fedora Core versiota 6. Apachesta taitaa olla versio 2.x, phpsta 5.x ja taitaa MYSQL:kin olla viitos versiota.
Työkaluina käytän:
- tekstieditori (jep, kaikki on käsin koodattu) Quanta+ [aivan loistava editori KDE ympäristössä]
- selaimena Firefox, Moxilla, Konqueror ja Opera. Koska teen kehitystä Linux:illa, saattaa tulos IE:llä olla sillointällöin ei niin kaunista. Mutta pyrin tarkistamaan sillointällöin jollain windows koneella miltä näyttää - ja korjata kun ongelmia löyty.
- FTP sovelluksena ja tiedostonhallintaan soveltuu erinomaisesti tuo Konqueror (siinä on myös selain samassa mikä on välillä ihan kätevä ominaisuus).
- versionhallinta: ei mitään koska teen järjestelmää yksin, ja jokaisen session jälkeen käteen jää toimiva / julkaisukelpoinen järjestelmä.
- backupit: ei oikeastaan mitään - jokaisen session jälkeen koodi heitetään tuotantojärjestelmään joten siellä on backup, jos kotikone hajoaa.

Opetus 4: Testaa ideasi

On äärimmäisen helppoa kehittää maailman paras järjestelmä omassa päässä. Mielikuvitusmaailma kun sallii sinun kontrolloida ympäristöäsi ja jättää huomioimatta sinulle epäedulliset seikat. Ja koska sinulla on kova innostus päällä, jää kaikki vaikeudet huomioimatta. Tässä kohtaa apuun rientävät tuttavat ja kaverit. Älä testaa ideoitasi julkisilla palstoilla, ellet halua että joku kaappaa ideasi.

Kun vihdoin olet saanut oman ideasi mielestäsi riittävän selväksi, ymmärrät kilpailutilanteesi (omasta mielestäsi ainakin) ja olet keksinyt miten palvelullasi tehdään myös rahaa; tässä kohtaa kannattaa alkaa juttelemaan asiasta tuttujen kanssa. Kerro heille ideasi - ja pyydä heiltä vilpitöntä ja rehellistä palautetta. KUUNTELE tuo palaute menettämättä hermojasi. Nämä mielipiteet tulevat ihan oikeilta käyttäjiltä ja ihmisiltä (vaikka sinä heidät tunnetkin). He eivät elä sinun pääsi sisällä olevassa "laa-laa-landiassa".

Itse tein www.mutteri.com:in suhteen tuota testausta muutamien liiketoiminnasta jotain ymmärtävien ystävieni kanssa. Ja palautetta tuli. Keskusteltiin mm. ansaintamallista (www.mutteri.com ansaintamalli perustuu mainostuloihin), kilpailijoiden vahvuuksista ja heikkouksista (muista, että sinun tekemäsi lista on subjektiivinen ja vaaleanpunainen).

Palutteesta voisin korostaa seuraavia seikkoja:

- minä en ole ohjelmoija, joten teknisesti palvelu ei välttämättä olisi edistyksellinen ja/tai hyvä (aiheesta lisää myöhemmin)
- minä en ole graafinen suunnittelija (minun tekemäni design ei siis olisi välttämättä oikeasti kovin hääppöinen - aiheesta lisää myöhemmin)
- tunnettujen kilpailijoiden haastaminen on vaikeaa ja vaikeampaa mitä minä kuvittelen
- ansaintamalli on hutera (totta - ja tästäkin lisää myöhemmin)

Jos olisin kuunnellut saamaani palautetta, ei www.mutteri.com:ia olisi - eikä olisi tätä blogiakaan. Sinä voit päättää valitsinko oikein vai väärin.

Opetus 3: Liiketoimintamalli

Tavoitteestasi riippuen on tärkeätä miettiä miten palvelu tuottaa. Se on varmaa, että kuluja palvelun pystyttämisestä symtyy. Itselläni oli ensisijainen tavoite luoda järjestelmä jolla minä saisin myytyä omia tavaroitani. Uskoin, että jos minä pystyn sitä käyttämään, niin kyllä pystyy muutkin (tämä oli/on virheolettamus). Mutta olennaista tässä on se, että en lähtenyt luomaan www.mutteri.com:ia rikastuminen mielessä. Tavoitteeni oli tehdä palvelu ensisijaisesti itselleni ja halvalla. Toissijainen tavoitteeni oli, että palvelu tuottaisi sen verran, että saisin tuloilla katettua kiinteät kustannukseni (eli palveluntarjoajan vuosittaisen laskun). Ja vasta kolmantena tavoitteena (tai haaveena) oli se, että homma lähtee lentämään tavalla, että www.mutteri.com elättää minut.

Jos palvelun tuotto on sinulle tärkeää, suunnittele liiketoimintamallisi huolella. Aiheesta löytyy varmasti paljon tietoa webistä, ja aiheesta on tehty paljon kirjoja - itse luin mm. McKinseyn kustantaman helppolukuisen kirjan kasvuyrityksen perustamisesta.

Harrastelijallekin tärkeitä aiheita ovat kuitenkin:
- toiminnan kulut (kuinka paljon järjestelmän kustannukset ovat)
- kuinka paljon sinulla on aikaa järjestelmän kehittämiseen
- miten palvelu tuottaa rahaa? (mainokset, jäsenyysmaksut, maksulliset lisäpalvelut,...)
- kuinka paljon voit / olet valmis sijoittamaan mainostamiseen [eli oman palvelun brandin luomiseen]
- jne

www.mutteri.com tapauksessa
- kulut ovat pienet ja kiinteät (hosting palvelun kustannukset)
- omaa aikaa tämä vie PALJON
- tuloja vain mainostamisesta
- brandin luominen ja tunnettavuutta tavoittelen hakukoneiden kautta (siitä lisää myöhemmin)
- en ole mainostanut vielä palvelua lainkaan - mutta suunnitelmissa on käyttää esim. googlen adwords:iä.

Älä lopeta päivätyötäsi ennenkuin palvelu todella tuottaa rahaa! Ja mielellään on tuottanut sitä jo pidemmän aikaa - enemmän kuin sinä tarvitset.

Opetus 2: Kilpailijoiden arviointi

Kuten sanottua, ei olemassaolevat palvelut tarkoita sitä, että niitä vastaan ei kannattaisi / voisi kilpailla. Mutta se tarkoittaa ehdottomasti sitä, että sinun pitää tuntea kilpailijoidesi palvelut ja niiden vahvuudet. Lähtemällä tekemään tismalleen samaa mitä he jo tekevät - on lähes varma palveluitsemurha.

Arvioi mitä ominaisuuksia kilpailijasi tarjoavat, kenelle ne on tarkoitettu, miten hyvin ne täyttävät tarpeen mitä varten ne on luotu. Arvioi niiden vahvuudet JA heikkoudet. Heikkoudet ovat sinulle tärkeitä, koska se on se juuri se mitä sinä voit omassa palvelussasi hyödyntää.

Tässä www.mutteri.com:in kilpailijoiden vahvuuksia ja heikkouksia oman arvioini perusteella:
Huuto.net
Vahvuudet: Suosittu ja vakiintunut, luotettava, toimiva nippu toiminnallisuuksia, Suosittu (tämä on niin suuri vahvuus, että se kannattaa mainita kaksi kertaa :), ilmaiset perustoiminnallisuudet.
Heikkoudet: Käytettävyys, design (vuodelta 2000 - eli auttamatta vanha), kyse on huutokaupasta - eikä siten sovellu kaikkeen myymiseen, heikko haku, jäykkä luokittelu, rajoitettu ilmoitusaika (2 viikkoa?)
Puutteet: rss syötteet, ilmoitusten massalataus

keltainenporssi.fi
Vahvuudet: suhteellisen suosittu, painettu lehti, verrattain toimiva järjestelmä, Ilmoita ilmaiseksi.
Heikkoudet: ansaintamalli (internet palveluiden odotetaan olevan pääsääntöisesti ilmaisia), web palvelu lehden varjossa

uutisryhmät
Vahvuudet: täysin vapaa tapa ilmoittaa
Heikkoudet: organisoimaton (ei luokkia), kohderyhmä enemmänkin nörtit/tietokoneharrastajat

tuntemattomat kirpputorit tms
Vahvuudet: innovatiivisia?,
Heikkoudet: haastajia kuten mutteri.com, useissa design ja käytettävyys erittäin heikkoja, tuntemattomia ja useimmiten rajalliset resurssit (kuten mutteri.comissakin).

Lisäksi huomiona sellainen, että myyntipalstat ja kirpputorit ovat hyvin hajaantuneita - usein erityisalueiden sivustoilla on omat myyntipalstat ja ilmoituspalstat - mutta niiden käyttäjäpiiri on usein pieni, ja niiden löydettävyys on heikko (mistä sinä etsisit vaikka arvokelloja käytettynä?)

Tämä arvion perusteella lähdin suunnittelemaan mutteri.com:ia siten, että sen kilpailuvaltteja olisivat: ilmaisuus käyttäjille, korkea käytettävyys, tyylikäs ja toimiva design, joustava luokittelu, myyjän ehdoilla (teoriani mukaan myyjät tuovat mukanaan ostajat), ilmoitusten voimassaoloaika vapaa.

Opetus 1: Taustatutkimus

Ei kannata ruveta tekemään kovinkaan suuria suunnitelmia ellei tiedä millainen tarjonta ideasi kohdealueella on jo tällä hetkellä. Vaikka ideasi tuntuisi kuinka originaalilta, kannattaa tehdä taustatutkimus ja kartoitus siitä mitä on jo tarjolla. Joku viisas (en tiedä kuka, mutta eräs ystäväni muistuttaa tästä jatkuvasti) on sanonut, että oli ideasi kuinka hyvä ja originaali tahansa, on jossain päin maailmaa jo ainakin kolme muuta jotka ovat ajatelleet samaa. Ja on hyvin luultavaa, että joku on jo tehnytkin sen.

Kilpailu- ja markkinatilanteen pohjalta on helpompi päättää kannattaako omaa aikaansa kuluttaa kyseisen idean implementointiin vai ei. Se, että vastaavia paluita on jo olemassa ei tarkoita sitä, että palvelua ei kannata pystyttää. Ainahan sinä voit tehdä sen paremmin kuin muut. Mutta ole realisti - olemassa olevan, suositun palvelun lyöminen on erittäin haastavaa ja viedä aikaa sekä resursseja mahdollisesti enemmän kuin sinulla on käytössä. Mikäli olemassa olevat palvelut ovat pieniä, tuntemattomia ja/tai ominaisuuksiltaan vaatimattomia, voi markkinoille tunkeutuminen olla mahdollista pienelläkin työmäärällä. Mutta Älä aliarvioi kilpailijoitasi.

www.mutteri.com:in kilpalutilanne oli:
Tunnettuja / suosittuja ovat:
huuto.net, uutisryhmät kuten sfnet.tori.myydaan, oikotie, nettiauto, keltainenpörssi, palsta, ...
Tuntemattomampia:
web.fi, verkkokirppis.fi, www.ostajamyy.com, ja niin edelleen.

Eli haastettavia palveluita oli enemmän kuin tarpeeksi. Ja koska minulla on aiheettoman kova usko itseeni, päätin lähteä silti haastamaan...

Ajatus kauppapaikasta

Työskentelin vuodesta 1999 aina vuoteen 2006 eräässä kansainvälisessä yrityksessä web palveluja tuottavassa yksikössä. Seitsemän vuotta samoja hommia sai minulla mitan täyteen ja päätin muuttaa Tampereelle - elettiin kesää 2006. Koko muuttoprojekti oli suhteellisen mutkikas ja päätimme, että pyrimme myymään kaikki sellaiset huonekalut ja tavarat joita emme ehdottomasti halua säilyttää. Aikaa myymiseen oli muutama kuukausi. Siispä rupesin kartoittamaan mitä myyntikanavia minulla olisi tarjolla.

Aika ennen Alkusanoja

Joskus vuonna 2001/2002 tilasin itselleni ensimmäisen domainin. Tuo domain oli www.mutteri.com. Domainin nimen inspiraationa oli juuri hankittu koirani Mutteri (ranskanbulldoggi). Tässä vaiheessa minulla ei ollut ajatusta luoda kirpputoria, kauppapaikkaa tai oikeastaan mitään muutakaan. Ajattelin vain, että nimi on hyvä, joten otetaan siitä domain ja aletaan opettelemaan web sivustojen tekemistä konkreettisesti (teoria oli jo tuttua opintojen kautta).

Sitä voi tietenkin kysyä, miksi kukaan hankkisi domainin oman koiransa nimen perusteella... tähänkin löytyy syy. Aikoinaan kultaisen 90-luvun puolivälissä kävin Helsingin yliopistolla Käyttöliittymät kurssia. Kyseisellä kurssilla otettiin esiin huonona esimerkkinä Unix puolella silloin käytössä ollut Biff -sovellus. [en ole ihan varma oliko nimi juuri Biff tai biff]. Kyseinen pieni sovellus oli käytännössä katsoen sähköpostivahti. Kun biff oli käynnissä, se seurasi sähköpostipalvelinta ja ilmoittu kun uutta sähköpostia ilmestyi laatikkoon. Ohjelman kehittäjä oli antanut ohjelmalle nimen biff, koska hänen koiransa alkoi aina haukkumaan kun posteljooni toi päivän postin. Tämä sovellus oli siis esillä Käyttöliittymät kurssilla huonona esimerkkinä, koska ohjelman nimi ei kuvannut sen käyttötarkoitusta - ja tästä syystä se oli vaikeasti opittava / muistettava. Niinpä minä päätin tilata domainin oman koirani nimen perusteella.

Tuohon aikaan ei ollut juurikaan "edullisia" domain hosting palveluita Suomessa. Kriteerini olivat verrattain selvät: Halusin php tuen, mysql tietokannat ja ftp pääsyn tililleni. Ja koska olin liikkeellä puhtaasti harrastuspohjalta, piti tuon palvelun olla halpa. Palveluntarjoajaa etsiessäni päädyin turkulaisen Daous OY:n (toivottavasti nimi on oikein) sivuille. Heillä oli tarjolla minulle sopiva hosting palvelu ja hintakin oli säädyllinen - muistaakseni domain rekisteröinti vuodeksi, yksi mysql tietokanta ja 20 MB kotisivutilaa oli 36 euroa / vuosi. Siispä tilasin palveluni heiltä.

Alkusanat

Vajaa vuosi sitten (eli kesällä 2006) kuvittelin, että maailma (=Suomi) tarvitsee uuden web palvelun. Kuvitelma syntyi siitä, että minulla oli tarve, enkä löytänyt (omasta mielestäni sopivaa) olemassa olevaa palvelua joka tuon tarpeen täyttäisi. Siispä ryhdyin tuota palvelua luomaan.

Se mitä etsin, oli hyvä ja toimiva kauppapaikka, missä voin myydä mitä haluan. Nyt tuota palvelua on kehitetty (ja pyöritetty) lähes vuoden päivät - ja kaikessa tässä tohinassa on jotain opittukin. Tämä blogi on kertomus siitä miten tuo luomani palvelu on kehittynyt, mitä olen sitä tehdessäni oppinut, jne.

Toivon, että tästä on niille, jotka ovat vakaasti päättäneet pistää palvelun pystyyn - palvelun josta tulee tajuttoman suosittu - ja jolla rikastuu hetkessä.

Tämä on www.mutteri.com:in tarina.

Monilla varmaan heräsi kysymys: Mikä ihmeen mutteri.com? Tämä olkoon vastuuvapautus / disclaimer blogin otsikkoon: Koska palveluni ei ole erityisen tunnettu tai suosittu (ja minä en ole julmetun rikas), ei minua voi pitää alueen merkittävänä asiantuntijana tai guruna. Eli jos päätät lukea lisää - poimi täältä sellaiset asiat, jotka sopivat sinulle ja joihin sinä uskot.