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