During the last six months, I’ve been thinking more and more how grateful I am for being able to contribute to the WordPress project. It has taught me so much on so many levels. Helping event organizers allows me to go (virtually) around the world and learn from different cultures. I get to work with amazing and super talented persons. New friendships and connections have been established. I’ve been trusted to take care of complex things and resolve those on my own.

It always gives a long-lasting good feeling, when you see someone you helped to make a blast out of their event or success in their contribution. But the utmost valuable thing has been endless warmth and respect for each other. Even if we wouldn’t always agree, everyone’s opinion is heard and taken into consideration. We work together towards the same goal.

Without my involvement in the project and without the discussion with thoughtful individuals, I wouldn’t be the person I’m today. WordPress project has given me the feeling of being part of something bigger and far more important than I’ve felt ever before, although I have been involved in too many soups to this age.

For a few years now, there has been silent, but a continuous bad feeling in my head about how much I use and depend on services of Google and Facebook. I’ve have fantasized about the idea of burning the bridge between me and these two giants. But as said before, my everyday life really depends on their products. Even thinking the amount of work on burning bridges has gotten me forget the plans.

Kirjoitus on julkaistu alunperin Duden blogissa.

Duden blogissa on puhuttu viimeaikoina suhteellisen paljon siitä, paljonko nettisivut maksavat ja mistä se hinta sitten koostuu. Jokaisessa kirjoituksessa olemme kertoneet sivuston olevan aina räätälöity 100% asiakkaan tarpeita varten, tuo räätälöinti ulottuu aina visuaalisesta ilmeestä syvälle konepellin alle.

Roni tiivistikin aiemmin osuvasti tuota konepellin alla olevaa osuutta. Ajattelin nyt avata tätä teemaa hieman enemmän näin back-end kehittäjän roolissa kahdessa erillisessä kirjoituksessa.

Kehitämme projektia mieluusti eteenpäin ja ainakin rakennamme sivustomme sellaiseksi, että niitä pystyy kehittämään eteenpäin.

Ensimmäisessä osassa käsittelen tietorakenteen suunnittelun tärkeyttä ja kerron miten me Dudella hoidetaan asia. Seuraavassa osassa kerron minkä takia ja miten kiinnittää huomiota myös hallintapaneeliin.

Kävijä näkee sivustosta ainoastaan ns. julkisen puolen, sen miltä kaikki tieto näyttää hienosti ja visuaalisesti aseteltuna. Tuskinpa kukaan tulee ajatelleeksi millä tavalla jokin tieto on tallennettu tietokantaan tai minkälaisilla palikoilla visuaalisuus on kasattu.

Käytännössä projektin koodaamisen aloitus alkaa aina tietorakenteen suunnittelusta. Yhtään riviä koodia ei kirjoiteta, ennen kuin tietorakennetta on mietitty vähintään päässä, mieluusti jopa analogisella paperilla.

Miksi suunnitella tietorakennetta?

Selkeyden vuoksi samaan asiaan liittyvän tiedon hallinnoiminen on hyvä olla mahdollista yhdestä paikkaa. Sivuston sisällön ylläpitäjälle on paljon selkeämpää päivittää yhden ominaisuuden kuvausta itse ominaisuuden muokkasnäkymästä, kuin erikseen jokaisella sivulla missä kyseinen ominaisuus näkyy tavalla tai toisella.

Tietorakenteen suunnittelu liittyy hallintapaneelin käyttömukavuuden ja selkeyden lisäksi vahvasti jatkokehityksen ennakointiin. Kuvitellaan tilanne, jossa esimeriksi ominaisuuksia listataan ainoastaan etusivulla ja etusivulle on luotu lisätietokentät ominaisuuksien lisäämistä varten. Mitä sitten kun asiakas haluaakin listata ihan samoja ominaisuuksia, edes osaa niistä muilla sivuilla tai jokaiselle ominaisuudelle oman laajan esittelysivun?

Kaikki aiempi ominaisuuksiin liittyvä back-end koodi muuttuu turhaksi ja hommat joudutaan tekemään tältä osin nollasta uusiksi. Jos tietorakennetta on taas mietitty etukäteen edes hieman ja luotu ominaisuuksille oma sisältötyyppinsä (custom post type, CPT), on homma todennäköisesti paljon kivuttomampi.

Miten Dude tekee tämän käytännössä?

Projekti käydään vielä kerran läpi yhdessä graafikon kanssa, jotta saadaan vastauksia seuraaviin kysymyksiin: minkälaisia sisältötyyppejä sivustolle tarvitaan? miten sen artikkelit jäsennellään? tarvitaanko kategorioita? onko sisältötyypillä arkisto tai sen yksittäisillä artikkeleilla julkista näkymää? linkittyykö joidenkin sisältötyyppien tiedot keskenään? mikä on sisältötyypin osoiterakenne (slug)? mikä on koko projektin kaiken sisällön osoiterakenne?

Vasta kun nämä asiat alkaa olla selvillä, aletaan kasaamaan sisältötyyppejä, niiden lisätietokenttiä (metadata) ja sivupohjia.

Käytännössä Duden back-end kehittäjän workflow lisäkenttien luomiseen ja sivuston julkiselle puolelle saamiseksi on seuraava:

1. Huomataan että esimeriksi etusivulla on nostoja tuotteen ominaisuuksista ja jokainen nosto sisältää otsikon, ikonin sekä lyhyen kuvauksen.
2. Selataan leiskat läpi ja katsotaan onko joillain toisella sivulla samanlainen elementti tai samat sisällöt esitettynä hieman eri tavalla.
3. “Ahaa, kaikki ominaisuudet esitellään yhdellä koontisivulla ja siellä näyttäisi olevan sama otsikko sekä ikoni, mutta eri kuvaus ja erilainen visuaalisuus.”
4. Luodaan ominaisuus -sisältötyypin artikkelille lisätietokentät ikoni, lyhyt kuvaus, lyhyt kuvaus etusivun nostossa ja käytetään otsikkona ominaisuuden nimeä.
5. Luodaan etusivulle lisäsisältökenttä josta voi valita nostettavat ominaisuudet, tai vaihtoehtoisesti luodaan yksittäisen ominaisuuden muokkaukseen valinta tätä varten. Tapa riippuu hieman siitä, miten etusivun muu sisältö rakentuu ja tarvitaanko ominaisuusnostoja myös muualla.
6. Luodaan teemaan osat (template part) erikseen yksittäisen ominaisuuden nostolle koonti- ja etusivulla. Näissä käytetään edellä mainittuja lisätietokenttiä. Ensimmäistä osaa käytetään ominaisuuksien koontisivun listassa ja toista etusivulla.
7. Teeman osissa tulostetaan kaikki olennaiset tiedot, tässä tapauksessa otsikko, edellä mainitut lisätietokentät ja yksittäisen ominaisuuden osoite ilman html-rakennetta (poislukien kuvien, otsikoiden ja linkkien html tagit).

Sama rumba toistetaan sivupohja kerrallaan ja sivun elementti kerrallaan.

Käytännössä Duden työmallilla, jossa jokaisessa projektissa on erikseen back-end ja front-end kehittäjät, sivuston julkinen puoli näyttää hyvin rujolle näiden työvaiheiden jälkeen, ennen kuin front-end kehittäjä rakentaa asettelun visuaaliseen muotoon. Kaikki sisältö on näkyvissä kuten kuuluukin, mutta ei kovin nätisti.

Front-end kehittäjä rakentaa projektista riippuen html-rakenteen ja css-tyylit sisällön ympärille ennen tai jälkeen taustatyön, usein antaen lisätehtäviä, korjaustöitä tai muita muutoksia back-end kehittäjälle. Loppu projektista etenee siis samaan aikaan front-end sekä back-end kehittäjän pöydillä yhteistyötä tehden.

PS. Ollaan Ronin kanssa höpöttämässä marraskuussa Tampere WordPress Meetupissa meidän tavasta tehdä sivustoja, tulehan ihmeessä paikalle!

Kirjoitus on julkaistu alunperin Duden blogissa.

Suomalaiset WordPress-kehittäjät sekä -käyttäjät kokoontuivat kolmatta kertaa yhteen täydeksi seminaaripäiväksi sekä lauantain työpajoihin WordCamp Helsinki 2017 tapahtumaan. Koko Duden edustus oli paikalla (kyllä, koodipuoli sai suostuteltua graafisen osaston aamujunaan) ensimmäistä kertaa, kahtena aiempana vuonna ainoastaan koodarit olivat mukana. Allekirjoittanut ei itseasiassa ollut osallistuja, vaan yksi henkilö kolmatta kertaa järjestetyn tapahtuman takana.

Roni kirjoitti mainioin koosteen ensimmäisestä vuonna 2015 järjestetystä WordCampista, johon itse osallistuin vielä toisen yrityksen palkkalistoilta. Toisena vuonna olinkin jo Duden palkkalistoilla sekä vapaaehtoisena auttamassa WordCampin pääpäivänä, tuolloinkin kertaa Roni kirjoitti kattavan koosteen menosta. Tällä kertaa ajattelimme jättää koosteet sikseen ja pistää minut kirjoittamaan kokemuksesta olla järjestämässä WordCampia ensimmäistä kertaa. Inspiraatiota antoi Sami Keijosen viimevuotinen kirjoitus samalla kulmalla.

Tiimi kasaan ja suunnittelu käyntiin

Tämän vuoden WordCampin suunnittelu alkoi jo syksyllä 2016 kun yhteisöstä alettiin etsimään halukasta kaupunkia, pääjärjestäjää sekä tiimiä. Pallottelua käytiin paljon Jyväskylän ja Turun välillä, toivoen seuraavan WordCampin suuntaavan jälleen uuteen kaupunkiin. Pääjärjestäjiä ja tiimejä ei kuitenkaan löytynyt näistä kaupungeista, joten Niko Pettersen ja Helsingin yhteisö otti kopin loppuvuodesta.

Pääjärjestäjänä toimineen Nikon ympärille löytyi nopeasti tiimi edellisen WordCampin järjestäjistä ja Jyväskylän sekä Turun kiinnostuneista järjestäjistä. Tässä vaiheessa onkin mainio hetki antaa iso kiitos tyypeille jotka tekivät WordCampin kanssani; pääjärjestäjä Niko, Kenda, Kirsi, Marco, Mayank, Sami, Sonja ja Teemu. Teidän kanssa työskentely oli huippua!

Kaupungin päättämisen ja tiimin kasaamisen jälkeen oli aika laittaa iso pyörä pyörimään. WordCampit eivät nimittäin synny pelkästä yhteisön aktiivisuudesta, vaan taustalla on satoja tunteja työtä sekä byrokratiaa. Niin, byrokratiaa. Vaikka WordPressiä saa sekä voi käyttää kuka tahansa ja yhteisö on hyvinkin vapaamuotoinen, WordCamppeja ei voi järjestää kuka tahansa “virallisella” nimellä kutsuen sitä WordCampiksi ja saaden tukea kansainväliseltä yhteisöltä.

WordCamp Centralille jätetään hakemus jossa kerrotaan yhteisön taustoista, järjestäjätiimistä sekä vastataan suurin piirtein 20 kysymykseen joilla kartoitetaan valmiuksia järjestämiseen. Koska suomessa oli järjestetty jo kaksi aiempaa WordCamppia ja WordCamp Centralin Jenny Wong oli jo näyttänyt alustavaa vihreää valoa, uskalsimme aloittaa tapahtumapaikan etsimisen ilman virallista Centralin hyväksyntää.

Hakemuksen hyväksymisen jälkeen suunniteltiin tapahtuman budjetti ja hyväksytettiin se vielä erikseen WordCamp Centralilla. Budjetti on sen verran monimutkainen asia, että en edes lähde selostamaan siitä. Knoppitietona kerrottakoon kuitenkin budjetin olleen karvan verran yli 13 000 euroa.

Tapahtumapaikka

Kokopäivän seminaaria järjestäessä suhteellisen pienellä budjetilla, tapahtumapaikalle asettuu yllättävän monta kriteeriä: ns. tapahtumainfran on oltava suhteellisen valmiina tai paikan tulee hoitaa kaikki tuolien vuokraamisesta aina lavaan ja lavatekniikkaan saakka, lavalle tulee olla kaikkialta hyvä näkyvyys, sponsoreille sopivaa tilaa tulee löytyä, kahvien ja lounaan tulee järjestyä ilman suuria lisäpanostuksia ja kommunikaation on toimittava hyvin tapahtumapaikan edustajan kanssa.

WordCamp Helsinkiä järjestäessä varovaisena tavoitteena oli kasvattaa osallistujamäärää hieman ja ehkä saada kaksi lavaa, koska jo edellisvuoden kokemusten perusteella odotettiin suurta kysyntää.

Sami kartoitti mahdollisia paikkoja suhteellisen intensiiviset pari viikkoa etsien tilaa, jossa olisi varaa laajentua, mutta ainakin iso osa tarvittavasta tapahtumatekniikasta olisi valmiina. Ja tietenkin budjettiin sopivalla hinnalla. On muuten yllättävän hankalaa, joten päädyttiin Virgin Oiliin joka toimi myös WordCamp Finland 2016 tapahtumapaikkana ja yhteistyön tiedettiin sujuvan ensiluokkaisesti.

Jälkiviisana voi todeta, että meidän olisi ehkä pitänyt olla vähän rohkeampia ja valita paikka, joka olisi ollut kalliimpi ja vaatinut enemmän järjestelyjä tekniikan sekä lounaan suhteen. Liput myytiin nimittäin loppuun minuutin päälle kahdessa tunnissa.

Puhujat

Jokaisella järjestäjällä oli oma vastuualueensa tai vähintään tuki/takahenkilön rooli, muutamilla useampi rooli. Itse vastasin tapahtuman puhujavalinnoista, esitysten sisällöistä ja oikeastaan lähes kaikesta puhujiin liittyvästä. Sen lisäksi kilpailutin ja tilasin tapahtuman oman swagin, jonka Sonja suunnitteli.

Oikeastaan puhujista vastaaminen ei ole pelkästään heidän valitsemista, ohjeistamista, esitysten läpikäymistä ja tapahtumapäivänä heistä huolen pitämistä. Puhujista vastaavan henkilön harteilla on myös pitää huoli järjestäjätiimin kanssa sovittujen aihepainotusten toteutumisesta sekä esitysten monipuolisuudesta. Koska WordCamp Helsinki on vuoden ainoa suuri WordPress-tapahtuma, haluttiin ohjelmiston olevan mielenkiintoinen niin sisällöntuottajille, projektipäälliköille kuin myös seniorillekkin devaajalle. Toivottavasti tässä onnistuttiin.

Kirjoitin puhujavalintaprosessista ja kriteereistä aiemmin WordCamp Helsingin blogiin, joten en lähde avaamaan niitä tässä sen enempää. Kerrottakoon kuitenkin, että saimme 35 ehdotusta esityksistä yhteensä 28 ihmiseltä ja tapahtumaan pystyttiin valitsemaan 12 puhujaa.

Välittömästi puhujavalintojen varmistumisen jälkeen alkoi tiivis kommunikaatio puhujien kanssa. Aikataulujen varmistelua, ohjeita laadukkaan esityksen tekemiseksi, käytännön asioiden viestittämistä, esitysten jalostamista yhteistyössä ja niin edelleen. Omalta osaltani kiireisin aika alkoi puolitoista kuukautta ennen tapahtumaa, sillä kaiken edellämainitun lisäksi piti diilata swagitilausten sekä tapahtuman aikataulun rakentamisen kanssa.

Itse tapahtuma

Pariin yöhön ei meinannut tulla uni, kun stressasi ja jännitti niin paljon, olihan vastuullani kuitenkin tapahtuman onnistumisen kannalta yksi tärkeimmistä asioista.

Tapahtuman rakentaminen aloitettiin torstaina alkuillasta, kun pääsimme Virgin Oiliin pörräämään, laittamaan tavaroitamme paikoilleen, varmistelemaan seuraavan päivän kulkua henkilökunnan kanssa sekä vihdoin tapaamaan kaikki puhujat, vapaaehtoiset sekä paikalliset sponsorit kasvotusten.

Sitten koitti perjantai, aikainen herätys ja tapahtumapäivä. Heti matkalla sain harmikseni viestin, että Viljami Kuosmanen on kipeänä eikä pääse puhumaan. Bussissa asialle ei voinut kauheasti muuta, kuin kommunikoida asia muulle tiimille ja alkaa miettimään mistä löytää uusi puhuja Viljamin tilalle. Jännitystä lisäsi myös Aki Björklundin edellisiltana tullut viesti, että hänkin on kipeänä ja ei pysty 100% varmuudella takaamaan tulemistaan.

Ennen ovien aukeamista säädettiin vielä aivan viimeisiä asioita kasaan Virgin Oilissa, etsittiin ratkaisua puhujatilanteeseen sekä juotiin kahvia. Paljon. Ovien auettua alkoikin täysi tohina rekisteröintitiskillä, puhujia sekä sponsoreita vastaanottaessa sekä lukuisia tuttuja morjestaessa. Aamupalaksi tilatut leivät eivät itselle uponneet kaiken jännityksen sekä innostuksen keskellä, kävijöille näytti kuitenkin maistuvan!

Ilokseni ja onnekseni heti aamulla muutama henkilö ilmoittautui vapaaehtoiseksi puhumaan jos joku puhujista ei pääse paikalle. Näin saimme Petya Raykovskan, joka muuten järjestää WordCamp Europea, paikkaamaan Viljamia. Aamupäivän aikana varmistui myös Akin pääseminen paikalle, joskin puolikuntoisena. Ei voi muuta ku hattua nostaa Petyalle ja Akille! Kaikki muutkin puhujat ansaitsevat suuren suuren kiitoksen.

Kaikki esitykset meni itseltäni enemmän tai vähemmän ohi, koska suhasin ympäri tapahtumapaikkaa, huolehdin puhujien viihtyvyydestä sekä valmistelusta lavalle, aikataulussa pysymisestä ja kaikenlaisista muista pienistä asioista. Olen vaan luonteeltani sellainen, että järjestäessä stressaan ja murehdin niitäkin asioita jotka eivät ole vastuullani, vaikka tiedänkin luotettavan henkilön vastaavan niistä. Isona apuna puhujien viihdyttämisen ja valmistelun sekä aikataulun kanssa oli lavamanagerit Sami ja Liisa, kiitos teille! Onneksi voin katsoa kaikki esitykset myöhemmin WordPressin televisiosta.

Aikataulullisesti pyrimme antamaan enemmän aikaa osallistujien keskinäiselle jutustelulle ja verkostoitumiselle, mikä onnistui ehkä liiankin hyvin. Muutaman hieman suunniteltua lyhyemmän esityksen ja sattuman takia tauot olivatkin pidempiä kuin olimme suunnitelleet. Ainakin järjestäjänä ns. tyhjää aikaa tuntui muodostuvan jonkin verran liikaa.

Kaikenkaikkiaan koko järjestäjätiimi tunsi tapahtuman onnistuneen hyvin, toivottavasti kävijöillä oli samanlainen fiilis! Tavoitteena oli kuitenkin järjestää mukava ja rento, mutta asiapitoinen tapahtuma jossa kaikki viihtyvät.

Speaker’s dinner, afterparty ja contributor day

Virallisen ohjelman loputtua ja nopean tapahtumapaikan purkamisen jälkeen suuntasimme puhujien, vapaaehtoisten sekä järjestäjien kanssa SMYGiin syömään. Oli hyvvee ja tältä suunnalta irtoaakin vahva suositus SMYGin ensiluokkaiselle palvelulle sekä todella maittavalle sapuskalle!

Illasta jatkui vielä virallinen ohjelma afterpartyn merkeissä, josta meni taas iso osa itsellä ohi koska tyypilliseen tapaani pörräsin huolehtimassa asioista joista ei välttämättä olisi tarvinnut edes stressata. Tästä huolimatta ilta oli oikein mukava ja siihen mahtui muutamia todella hyviä keskusteluja sekä paljon lyhyitä kohtaamisia. Muut duden pojat saikin kuulemma osakseen enemmän juttuseuraa, huomiota ja taputuksia olalle. Paljon kuulemma vaihdettiin juttua meidän alalle ehkäpä epätyypillisestä, erilaisesta ja rouheasta meiningistä. Aina on jotenkin jännä kuulla, miten Dudea fiilataan vaikka itse koetaan ainoastaan tekevämme töitä kuten tykätään, eikä olla suunnitelmallisesti tai tarkoituksella erilaisia.

Virallisen afterpartyn jälkeen käytiin vielä kollegoiden kanssa nappaamassa muutamat yömyssyt, kylläpä muuten upposi!

Lauantaina aamua aloiteltiin hotellin runsaalla aamupalalla, jonka jälkeen muut ukot suuntasi junaan ja minä contributor dayhin. Suurin osa ajasta meni WordCamp Centralin Jenny Wongin ja muiden paikallisten meetuppien (Helsinki, Tampere, Turku, Oulu) järjestäjien kanssa puhumassa kokemuksista, haasteista ja vinkeistä meetuppien järjestämiseen liittyen. Keskustelua käytiin myös tulevista WordCampeista ja niiden järjestämisestä.

Suurimpana contributor dayn saavutuksena taisi olla WordPress.orgin lisäosahakemiston kääntäminen suomeksi.

Mitä seuraavaksi?

Nurkan takana kurkkii jo kesäkuussa Pariisissa järjestettävä WordCamp Europe, joka on tänäkin vuonna maailman suurin yhteisön tapahtuma. Lippuja on vielä jokunen sata saatavilla 😉

Jos kolmetuhatta osallistujaa ja Pariisi ei houkuttele, löytyy ihan kotikulmilta kerran kuukaudessa järjestettäviä WordPress -meetuppeja, tällä hetkellä niitä tapahtuu täällä Jyväskylässä, Helsingissä, Tampereella, Turussa ja Oulussa. Huhujen mukaan Seinäjoellakin alkaa pian meetupit, mikä on aivan mahtavaa! Jos omilta kulmiltasi ei löydy vielä WordPress -meetuppia ja haluaisit asian olevan toisin, tule yhteisön Slackiin #meetups kanavalle ja autamme oman paikallisen meetupin pystyttämisessä 🙂

WordCamp Jyväskylään?

Seuraavassa Jyväskylän meetupissa 13.5. keskustellaan mahdollisuudesta järjestää hieman pienimuotoisempi ja kehittäjille suunnattu WordCamp Jyväskylässä. Tule ihmeessä paikalle jos WordCampin tuominen Keski-Suomeen kiinnostaa! Samalla suunnitellaan tulevia Jyväskylän meetuppeja ja niiden aiheita.

Mielenkiinnolla jään myös odottamaan tapahtuuko seuraava isompi WordCamp Turussa, kuten on hieman uumoiltu viimepäivinä. Vai kerätäänkö 2018 kasaan yksi iso pohjoismainen WordCamp. Selvää on ainakin se, että kiinnostus WordPressiä kohtaan ei ole laskemassa ja yhteisö jatkaa tasaista mutta vauhdikasta kasvuaan!

PS. Jos suomalaisen WordPress-yhteisön syntyhistoria ja stoori ensimmäisen WordCamp Finland tapahtuman järjestämisestä kiinnostaa, kannattaa kuunnella SAWP-podcastin seitsemäs jakso. Vieraana on Daniel Koskinen, jota voidaan pitää suomalaisen yhteisön alkuunpanijana.

Kirjoitus on julkaistu alunperin Duden blogissa.

Viime vuoden puolella kirjoitin vastineen avoimen lähdekoodin WordPressiä ja suljetun koodin ProcessWireä vertailevalle blogaukselle. Tällöin keskityin lähinnä kumoamaan vääriä väittämiä sekä olettamuksia WordPressistä.

Tällä kertaa aion kirjoittaa yleisemmin avoimen ja suljetun lähdekoodin järjestelmien eroista, kumoten Whitestonen blogissa esitettyjä väittämiä sekä tuomalla niihin toista näkökulmaa. On toki syytä muistaa, että Whitestonen päätuote on toteutukset heidän oman suljetun järjestelmän päälle ja Duden päätuote taasen laadukkaasti toteutetut sivustot sekä verkkokaupat avoimen WordPressin päälle.

Yleisesti lienee syytä sanoa, että mielestäni suljetun lähdekoodin järjestelmiä pitäisi välttää mahdollisuuksien mukaan kuin ruttoa.

Suljetun lähdekoodin järjestelmän kanssa olet toimittajalukossa, ja voin kertoa että se lukko ei tunnu hyvälle. Olet poikkeuksetta täysin riippuvainen järjestelmän toimittajasta ja hänen tahtotilastaan kyseisen järjestelmän kanssa. Usein myös maksat siitä että asioita ei kehitetä jatkuvasti, vaan järjestelmää käytetään pelkästään rahantekokoneena kalliiden lisenssi- ja/tai tukimaksujen “ansiosta”.

Kaikkihan tuntee surullisen kuuluisat Tiedon, Accenturen ja muiden vastaavien isojen toimijoiden epäonnistuneet ja kustannuksiltaan kohonneet suljettujen järjestelmien projektit. Avoimen lähdekoodin järjestelmien kanssa näitä ongelmia on hyvin harvoin.

Sitten sukelletaan väittämiin joihin on jotain sanomista, pitäkää penkeistänne kiinni.

Suljetun lähdekoodin keskeisimmiksi eduiksi listattiin mm.

Tietoturvariskien ja muiden haavoittuvuuksien hallitseminen johtuen juuri siitä, että lähdekoodi ei ole avoin kaikille tutkittavaksi.

Ei pidä laisinkaan paikkaansa. Suurin osa järjestelmien haavoittuvuuksista löydetään, vaikka lähdekoodista ei ole nähty pätkääkään. Järjestelmissä on aina erilaisia rajapintoja ja muita liikkuvia osia, joita sinnikkäästi tai onnekkaasti kokeilemalla löytää toisinaan helpostikkin haavoittuvuuden.

Koska ihminen on erehtyväinen, jokaiseen järjestelmään jää luonnollisesti aina haavoittuvuuksia ja tietoturvariskejä. Sen takia ei tule liiaksi tarkastella kuinka paljon niitä löytyy, vaan kuinka niiltä pyritään välttymään ja miten toimitaan kun sellainen löydetään tai raportoidaan.

Uskallan väittää, että avoimen lähdekoodin järjestelmissä on vähemmän haavoittuvuuksia ja tietoturvaongelmia kuin suljetuissa järjestelmissä – ja juurikin koska lähdekoodi on kaikkien tutkittavissa. Tämän ansioista kymmenet, ellei sadat, silmät käy lähdekoodia läpi jo testausvaiheessa ja iso joukko huomaa mahdolliset riskit todennäköisemmin. Suljetun järjestelmän koodia saattaa pahimmillaan käydä läpi yhdet silmät. Eikä ole muuten kerta tai kaksi, kun olen kuullut tutuiltani heidän löytäneen vakavan haavoittuvuuden suljetusta koodista ja kehittämisestä vastaavan yrityksen painaneen asian villaisella. Toisinaan jopa yli puolen vuoden jatkuvan haavoittuvuudesta muistuttelun jälkeen.

Avoimen lähdekoodin järjestelmään jääneet haavoittuvuudet huomataan myös suuremmalla todennäköisyydellä, koska käyttäjä- ja kehittäjäkunta on suurempi. Löydetyt haavoittuvuudet tulee myös korjatuksi nopeammin, koska se ei ole kiinni kenenkään työajan riittävyydestä ja mukana on useampi kehittäjä tekemässä korjausta samanaikaisesti.

Tiivis kumppanuus järjestelmätoimittajan kanssa, yhdessä asetetut pitkän ja lyhyen matkan tavoitteet. Palvelun räätälöinti ja toteuttaminen asiakkaan yksilöllisten toiveiden sekä tarpeiden mukaisesti.
>
Ohjelmistolisenssiin kuuluu virallinen palvelun ylläpito ja muut tukipalvelut.

Avoimen lähdekoodin järjestelmä ei sulje mitään näistä pois, vaan usein jopa mahdollistaa ne paremmin. Toteutus avoimella koodilla ei tarkoita sitä, että lopputulos hylätään projektin valmistumisen jälkeen. Esimerkiksi me Dudella teemme jatkuvasti tiivistä yhteistyötä asiakkaittemme kanssa sivustojen sekä verkkokauppojen jatkokehityksen suhteen. Tarjoamamme ylläpito näkyy harvoin asiakkaalle, sillä kaikki tapahtuu taustalla automaattisesti meidän toimesta. Asiakkaan tarvitessa tukea, vastaamme 90% tapauksista alle puolessa tunnissa.

Räätälöinti ja jatkokehittäminen voi olla suljetussa järjestelmssä hyvinkin hankalaa, jos alkuperäistä koodipohjaa kehittäessä ei ole otettu huomioon tulevaisuuden laajennustarpeita. Harmillisen usein ei ole otettu ja tällöin kustannukset voivat nousta suuremmiksi kuin räätälöinnillä ja jatkokehittämisellä saavutetut edut. Suljetut järjestelmät on usein sidottu myös sitä kehittävän yrityksen palvelininfrastuktuuriin, jolloin huonosta ympäristöstä johtuvan järjestelmän hitauden sekä kaatuilun korjaaminen on hidasta tai jopa olematonta. Avoimen koodin järjestelmän voi siirtää huonolta palveluntarjoajalta toiselle täysin vapaasti.

Suljetun lähdekoodin järjestelmiä toimittavien yritysten asiakaspalvelusta en sano muuta, kuin totean sen olevan usein ala-arvoista. Huonolla tuurilla saat Postiltakin parempaa palvelua.

Avoimen lähdekoodin haasteina nähtiin mm.

Omat tai kolmannen osapuolen järjestelmään tekemät muutokset, jotka aiheuttavat palvelun toimimattomuutta tai aiheuttavat tietoturvariskin.

Täysin sama ongelma on suljetun lähdekoodin järjestelmissä. Ihminen on jälleen erehtyväinen, ja suljetun järjestelmän koodaaja voi källätä rikkoen koko järjestelmän tai huomaamattaan tehdä uuden haavoittuvuuden toteuttaessa uutta ominaisuutta. Oikeastaan asia mikä tässä ratkaisee, on yrityksessä työskentelevien kehittäjien ammattitaito – täysin riippumatta siitä onko lähdekoodi avointa vai suljettua.

Kolmannen osapuolen tekemät muutokset testataan luonnollisesti aina kehitysympäristössä, juurikin sen takia että asiakkaan varsinaista järjestelmää ei hajoteta toimimattomaksi. Jos kehitysympäristössä tulee ongelmia kolmannen osapuolen muutosten takia, ratkaistaan ne joko muuttamalla omaa koodia, tekemällä korjaava fork kolmannen osapuolen koodista sekä raportoimalla ongelma sen kehittäjälle. Ongelma ei pääse missään vaiheessa heijastuman asiakkaalla käytössä olevaan järjestelmään.

Avoimen lähdekoodin mahdollistamat haavoittuvuudet/tietoturvariskit ja niiden aiheuttamat mahdolliset lisä- ja/tai ylläpitokustannukset.

Edellä mainitsemistani syistä, avoimen lähdekoodin järjestelmässä haavoittuvuudet ja riskit on todennäköisesti korjattu jo ennen kuin asiakas edes kuulee niistä. Mikä on hyvä asia – se kertoo korjaamisen nopeudesta. Koska lähdekoodi on kaikkien vapaasti käytettävissä, saa nuo yhteisön tekemät korjaukset käyttöönsä täysin ilmaiseksi. Nimenomaan suljetuissa järjestelmissä päivityksistä voi joutua maksamaan, riippuen toimittajan kanssa tehdystä sopimuksesta.

Avoimen lähdekoodin palvelun kehityksen loppuminen, palvelun suosion, kiinnostuksen tai tekijöiden siirtyessä muualle.

Jos avoimen lähdekoodin järjestelmän kehitys loppuu, voit jatkaa sitä itse – vaikka todennäköisesti järjestelmän suuresta yhteisöstä nousee useampikin henkilö tekemään sitä eikä sinun tarvitse. Suljetun lähdekoodin järjestelmän kanssa olet suoraan sanottuna kusessa, jos sit kehittävä yritys menee konkurssiin tai päättää keskittyä toisen suljetun järjestelmän kehittämiseen. Silloin joudut vaihtamaan koko järjestelmän uuteen, mikä on raskas ja kallis projekti.

Palvelun versioiden yhteensopivuus edellisten versioiden kanssa, koska kehitys on helposti suosion perusteella ohjautunutta.

Varsinkin suosituimmissa avoimen lähdekoodin järjestelmissä versioiden taaksepäin yhteensopivuutta pidetään suuressa arvossa. WordPressin historiasta tulee mieleeni ainoastaan muutama tapaus, jolloin taaksepäin yhteensopivuus on jouduttu hajoittamaan tietoisesti – tällöinkin muutoksista on kerrottu hyvissä ajoin ja isosti, jotta kehittäjillä on aika valmistautua muutokseen. Suljetun koodin järjestelmissä esimeriksi integraatiorajapinnat voivat muuttua mielivaltaisesti lyhyelläkin varoitusajalla ilman varoitusta kehittäjille, tällä voi olla vaikutusta esimerkiksi verkkokaupan maksuväylien toimivuuteen.

Maksulliset lisä- ja tukipalvelut.

On ne lisä- ja tukipalvelut maksullisia suljetunkin koodin järjestelmissä, usein jopa kalliimpia. Yritykset jotka markkinoivat suljettua järjestelmää lisä- ja tukimaksuttomana, ovat leiponeet kyseiset kustannukset kalliisiin lisenssi- ja/tai kuukausimaksuihin.

Sitä paitsi, usein avoimen lähdekoodin järjestelmillä on hyvin aktiivinen yhteisö josta voi saada neuvoa ja tukea etenkin pienemmissä asioissa. Esimeriksi WordPressillä on lukuisia yhteisön ylläpitämiä kanavia tuen tarjoamiseen.

Loppukaneettina todettakoon, että avoin lähdekoodi voitti taistelun jo aikapäiviä sitten.

Kirjoitus on julkaistu alunperin Duden blogissa.

Syksyllä 2016 sattui tilanne jota ei toivoisi edes pahimmalle kilpailijalleen, joka piti Duden teknisen tiimin hereillä lukuisia öitä viikko toisensa jälkeen, vaikutti käynnissä oleviin projekteihin, firman yleiseen mielialaan ja ennen kaikkea asiakkaittemme internetnäkyvyyteen. Uusi palvelinympäristö alkoi oireilla pahasti ilman selvää syytä, eikä mikään tehty toimenpide tuntunut auttavan.

Lopulta tilanne äityi niin pahaksi, että rakensimme uuden palvelinympäristön toiselle palveluntarjoajalle ja siirsimme kaikki sivustot sinne yhden yön aikana.

Tämä on (pitkähkö) kirjoitus siitä mitä tapahtui, kuinka korjasimme pahan tilanteen ja mitä opimme. Jos pidemmän tekstin lukeminen ei nappaa, alustuksen jälkeen on tarjolla mahdollisuus hypätä lukemaan suoraan mitä opimme.

Aluksi on kuitenkin pohjustettava hieman sitä, miten tähän tilanteeseen päädyttiin.

Duden alkuaikoina 2013-2014 asiakkaille tarjottiin sivutilaa hostingkumppanin kautta, sillä kahden miehen puulaakin ei kannattanut laittaa paukkuja palvelinylläpitoon jo ihan resurssisyistä, vaikka Ronilla palvelimista kokemusta onkin taustalla. Homma skulasi, keskityttiin sivustojen vääntämiseen ja asiakkaat olivat tyytyväisiä.

Vuosien saatossa entistä useampi asiakas vaihtoi sivustoudistuksen yhteydessä vanhan sivutilansa Duden pakettiin hostingkumppanin palvelimelle, kehittämiseen käytetyt työkalut kehittyivät harppauksin ja firmakin kasvoi.

Entistä kehittyneemmät työkalut ja vanhan hostingkumppanin palvelinympäristö eivät kuitenkaan pitkällä jänteellä pelanneet aina yhteen parhaimmalla mahdollisella tavalla. Lisäksi haluttiin kehityksen kärjellä olevaa teknologiaa käyttöön, ja olipahan sattunut myös muutama ikävämpi katkokin sivustojen toiminnassa.

Näiltä pohjilta uusien asiakkuuksien sivustoja ryhdyttiin pystyttämään Duden itse ylläpitämille DigitalOceanin virtuaalipalvelimille, jotka olivat odottamassa asiakkaita vuodenvaihteessa 2015. Tuotantoon saatiin pitkään kaivattuja uudemman teknologian ratkaisuja, kuten HHVM:ää ja Nginxin tuoreinta versiota ryyditettynä Googlen PageSpeed moduulilla nopeamman sivulatauksen saavuttamiseksi.

Paletti uusiksi

Keväällä 2016 palvelinkuviota pysähdyttiin miettimään uudestaan, tavoitteena yhtenäistää asiakkaiden sivutilojen ympäristöt, helpottaa ylläpitoa, löytää ratkaisu joka skaalautuu tulevaisuudessa paremmin ja laskea useasta Dropletista aiheutuneita kustannuksia.

Pohdinnan tuloksena päädyimme rakentamaan kahden edustapalvelimen, kahden tietokantapalvelimen ja yhden tiedostopalvelimen ympäristön ranskalaiselle palveluntarjoajalle nimeltä OVH. Uuteen ympäristöön siirrettiin kaikki sivustot jotka sijaitsi hostingkumppanilla sekä DigitalOceanin virtuaalipalvelimilla. Suurin piirtein samaan aikaan allekirjoittanut, eli Timi, tuli mukaan Duden remmiin ja palvelinosaamisen määrä tuplaantui.

Uudessa palvelinympäristössä on lähes aina aluksi pientä tuunattavaa ja viritettävää, kun nähdään miten se reagoi tuotannossa oikeaan käyttöön. Niin tälläkin kertaa, jopa sen verran että tajusimme alkuperäisen useaan konesaliin hajautetun kokoonpanon olleen hieman huono veto ja pistimme palvelinympäristön OVH:lla kokonaan uusiksi vaihtaen virtualisointitekniikkaa sekä siirtäen kaikki palvelimet samaan fyysiseen laitesaliin.

Uudelleen kasatun ympäristön kanssa olimme tyytyväisiä viikon aktiivisen virittelyn jälkeen ja siirryimme normaaliin ylläpitosykliin, eli prosessien automaattiseen monitorointiin usealla eri työkalulla, varmuuskopioiden automaattiseen rullaukseen ja säännöllisesti suoritettaviin manuaalisiin palvelinohjelmistojen päivityksiin.

Sitten se paska osui

Syyskuun alkupuolella se ruskea möhnä alkoi sitten osua tuulettimeen, alkuun salakavalasti lirahdellen. Automatiikkamme havaitsi useampana satunnaisena alkuyönä asiakkaiden sivustojen hitautta sekä satunnaista lyhyitä putoamista savuttamattomiin. Tekniikan tiimi ryhtyi selvittämään asiaa ja poissulkemaan mahdollisia aiheuttajia yksitellen, samalla kun OVH:lle lähetettiin tukipyyntö selvittää onko heidän infrastruktuurissa tai palvelinlaitteistossa vikaa.

Loppukuuta kohden ruskeaa alkoi osua tuulettimen lapoihin kiihtyvää vauhtia ja ongelma alkoi paisua kuin pullataikina. Duden tekninen tiimi ja ulkopuolinen konsultti poissulki mahdollisia aiheuttajia hurjaa tahtia, kokeillen kaikkia mahdollisia skenaarioita ongelman aiheuttajaksi ja sen poistamiseksi. Syyksi alettiin epäillä tiedostopalvelinta. Kuitenkaan OVH:n omat, epäselvästi ja -tarkasti kommunikoidut, tutkimukset eivät paljastaneet mitään vikaa.

Tässä vaiheessa Ronin ja Timin illat sekä yöt sujuivat toisensa jälkeen Netflixin tai nukkumisen sijaan komentoriviä näpytellen, kummankin koittaen epätoivoisesti löytää ongelman tarkempaa syytä ja samalla taata asiakkaiden sivustojen toiminta. Tällöin ryhdyimme tiedottamaan tilanteesta aktiivisesti asiakkaita.

Sanomattakin selvää, että tässä vaiheessa palvelinympäristön ongelmista oli tullut tekniikan poikien ykkösprioriteetti ja oikeastaan kaikkien asiakasprojektien kehitystahti hidastui niin minimiin kuin luvattujen aikataulujen puitteissa oli mahdollista.

Aamut alkoi muutamien tuntien yöunien jälkeen palvelinten tilanteen tarkistamisella, työpäivät ja alkuillat kului suorittaen erinäisiä diagnostiikkoja, lukien lokeja ja tehden toimia jotta tilanne ei toistuisi. Illat sekä yöt tilanne oli niin sanotusti päällä ja tällöin paukkuja laitettiin aiheutuvan haitan minimoimiseksi sekä reaaliajassa tutkimiseen. OVH:n asiakaspalvelusta ei ollut tässä vaiheessa apua nimeksikään ja tilanne alkoi käydä sietämättömäksi.

Lopulta lokakuun 2016 alussa päätimme siirtää palvelimet ja rakentaa palvelinympäristön uudestaan jälleen kerran, tällä kertaa toiselle palveluntarjoajalle sillä OVH:n reagointi ja asiakaspalvelu ei ollut ollut toivotulla tasolla. Muutaman päivän sisäisten keskustelujen ja mahdollisten palveluntarjoajien kartoittamisen jälkeen päädyimme tilaamaan uuden palvelinympäristön sekä sen pystytyksen Multimilta, joka on kotimainen toimija.

Tämän päätöksen jälkeen asiat lähtivät rullaamaan suhteellisen nopeasti eteenpäin. Suunnittelimme yhdessä Multimin asiantuntijoiden kanssa uuden palvelinympäristömme parissa päivässä ja sovimme että se pystytetään mahdollisimman pian.

Uudet fyysiset koneet sekä niiden välille rakennettu privaattiverkko oli pystyssä lokakuun toisella viikolla, jonka jälkeen ryhdyimme pistämään pystyyn virtuaalikoneita ja asentamaan palvelinohjelmistoja. Seuraavat seitsemän päivää testasimme uusia palvelimia huolellisesti ja viritimme niiden säätöjä kohdilleen tiiviissä yhteistyössä Multimin asiantuntijoiden kanssa.

Kuun puolivälissä olimme vakuuttuneita uudesta palveluntarjoajastamme sekä -ympäristöstä, joten pistimme härdelliksi ja siirsimme asiakkaittemme sivustot suomessa sijaitseville uusille palvelimille. Yhdessä yössä.

Ongelman pitkittyminen ja sen parissa vietetyt pitkät päivät olivat aika lailla syöneet jaksamisen finaaliin, joten sivustojen siirto tuntui ylitsepääsemättömän isolta työltä vaikka kaikki tiesivät että se on tehtävä.

Colaa kului pullokaupalla kun ensin suunniteltiin toimenpiteet jotka tulee tehdä siirron yhteydessä, kirjattiin sivustot ylös jotta yksikään ei unohtuisi, sivustoja siirrettiin sekä testattiin yksi kerrallaan ja kaiken tämän jälkeen palvelinten tilaa valvottiin aamuyön pikkutunneille saakka.

Voitte muuten olla varmoja, että palvelimia monitoroitiin erityisellä tarkkuudella koko loppuvuosi 2016, vaikka väsymys oli kaikilla huipussaan. Ja monitoroidaan edelleen, vaikka yhtäkään ongelmaa ei ole ilmennyt Multimille siirtymisen jälkeen.

Nykyinen palvelinympäristö

Multimin kanssa rakennettu palvelinympäristö muistuttaa suurelta osin sitä, minkälaisen pistimme alunperin OVH:llakin pystyyn. Poikkeuksena se, että palvelimet sijaitsevat ranskan sijaan nykyisin suomen armeijan vanhaan (perus)kallioluolastoon rakennetussa korkean turvaluokituksen konesalissa ja käyvät 100% ekologisella tuulivoimalla.

Itse kokoonpanoon kuuluu kaksi fyysistä mikropalvelinta jotka on virtualisoitu yhteensä neljäksi palvelimeksi; kahdeksi edustapalvelimeksi ja kahdeksi tietokantapalvelimeksi. Lisäksi on kaksi erillistä fyysistä tiedostopalvelinta, toinen asiakkaiden sivustojen tuotantoversioita varten ja toinen varmuuskopioille. Kaikkien näiden fyysisten palvelinten välille on toteutettu oma sisäverkko nopeampaa ja häiriötöntä liikennöintiä varten. Julkinen liikenne kulkee taasen suoraan kolmen suurimman verkko-operaattorin runkoverkkoon.

Palvelinten virtualisointi on toteutettu vikasietoisuutta ja skaalautumista silmällä pitäen. Tarvittaessa virtuaalipalvelimet voidaan siirtää fyysiseltä palvelimelta toiselle ilman huomattavaa katkoa, jopa nostaa pystyyn toisella palvelimella vaikka toinen olisi vikaantunut ja täysin poissa pelistä. Fyysisten palvelinten resurssit on mitoitettu siten, että ne pystyvät hoitamaan yksinäänkin neljän virtuaalipalvelimen aiheuttaman kuorman ongelmitta.

Mitä tästä kaikesta opittiin?

Nyt kun syksyn koitoksista on kulunut jo hyvä tovi, meillä on ollut aikaa pohtia mikä meni vikaan ja mitä olisi voinut tehdä toisin. Paljon on mielessä, mutta seuraavista asioista on toivottavasti hyötyä myös muille.

Valitse palveluntarjoaja huolella

Päädyimme OVH:n asiakkaaksi hieman heppoisin perustein, luottaen siihen, että OVH isona palveluntarjoajana osaa asiansa. Jälkiviisaana on hyvä todeta, että tätä olisi pitänyt kaivella vielä tarkemmin ja kysyä useamman ihmisen mielipidettä.

Multimista taasen ei ole kuulunut lukuisilta henkilöiltä muuta kuin hyvää ja Timin aiemmat henkilökohtaisen asiakkuuden perusteella palvelut sekä asiakaspalvelu ovat toimineet moitteetta vuosia.

Tee suunnittelu yhteistyössä palveluntarjoajan kanssa

Jokainen palveluntarjoaja tuntee itse parhaiten tarjoamansa paletin, sen rajat sekä tavat saada siitä suurin hyöty irti. Suunnittelimme ja pystytimme OVH:n palvelinympäristön itse, mistä aiheutui ylimääräistä työtä sekä säätöä. Multimin kanssa suunnittelimme ympäristön tiiviissä yhteistyössä ja jätimme suosiolla sen pystyttämisen paremmin osaavien hoidettavaksi.

Reagoi asioihin nopeasti ja tarmokkaasti

OVH:lla ilmenneisiin ongelmiin olisi tullut reagoida paljon vahvemmin heti alkuun. Lukuisia tunteja yöunta olisi säästynyt, jos emme olisi jääneet odottamaan palveluntarjoajan omia, vaillinaisia, selvityksiä.

Toisaalta kupletin suunnittelu ja sivustojen siirto uudestaan ei ollut erityisen houkutteleva vaihtoehto, johon kuitenkin päädyimme lopulta kun ongelmat alkoivat käydä sietämättömiksi ilman näkyvissä olevaa muutosta tilanteeseen.

Jos tarjoat hostingia, pidä kaikki langat käsissäsi

Duden hostingpaketin hintaan kuuluu verkkotunnusten nimipalvelu, jota suurin osa asiakkaistamme hyödyntää. Tämä osoittautui suhteellisen suureksi pelastukseksi, sillä sivustojen siirto ja palvelinten vaihto vaatii aina myös muutoksia verkkotunnuksen nimipalveluun. Jos nimipalvelut eivät olisi olleet meidän hallussa, olisi nuo muutokset vieneet pahimmillaan lukuisia päiviä emmekä olisi pystyneet suorittamaan siirtoja toimiville palvelimille yhtä tehokkaasti.

Onneksi myös ne asiakkaat, joiden verkkotunnuksen nimipalvelu on heidän omassa hallinnassa tai kolmannella osapuolella, ymmärsivät asian kiireellisyyden ja suorittivat muutokset poikkeuksellisen nopeasti.

Viesti aktiivisesti sekä rehellisesti

Yksikään asiakkaistamme ei ollut erityisen näreissään ongelmista, vaikka heidän sivustot olivatkin lukuisina alkuöinä pimeänä. Tulikivenkatkuisten viestien sijaan asiakkaat tsemppasivat ja toivottivat jaksamista, vaikka toki toivoivatkin meidän tapaan ongelmien nopeaa loppumista. Tähän oli varmasti yhtenä hyvin suurena tekijänä Duden valitsema tie tiedottaa tilanteesta ja sen aiheuttamista toimenpiteistä todenmukaisesti sekä mahdollisimman seikkaperäisesti.

Ainoa hieman pieleen mennyt asia oli aika joka kesti tämän viestimisen aloittamiseen, se olisi tullut tehdä heti ongelman toistuessa toisen kerran.

Lopuksi pitää vielä kerran pyytää ongelmia nöyrimmästi anteeksi asiakkailtamme ja samalla kiittää heitä tsemppaamisesta sekä ymmärryksestä. Iso kiitos kuuluu myös Multimin asiantuntujoille, joiden avulla saimme suomeen palvelinympäristön jonka toimintaan voi luottaa sekä ongelmien selvittämiseen osallistuneelle konsultille.

Alla oleva mielipidekirjoitukseni on julkaistu Keskisuomalaisessa 28.11.2016.

Lea Airaksinen kirjoitti mielipidepalstalla kävelijäkunkkujen ja autovihan Jyväskylästä (KSML 24.11.). Kuitenkin hän itse viljelee vihaa kestäviä liikennemuotoja kohtaan ja levittää vääriä tietoja pihakadulla kulkemisen liikennesäännöistä.

Toisin kuin Airaksinen väittää, pihakadulla ei ole erillistä ajorataa. Pihakatu on samaa väylää aina julkisivujen oikeasta reunasta vasempaan asti.

Kaupunki ei kuitenkaan ole poistanut pihakaduiksi muutetuilta väyliltä erillisiä korkeuseroteltuja jalkakäytäviä. Se olisi pitänyt tehdä. Muuten syntyy juuri tämän kaltaisia harhakuvitelmia siitä, että pihakaduilla olisi erillinen ajorata autoilijoille.

Airaksinen toteaa myös, että jalankulkija on kunkku pihakadulla. Suomen tieliikennelaki on samaa mieltä.

Ajoneuvon kuljettajan on annettava jalankulkijalle esteetön kulku ja ajonopeus on sovitettava jalankulun mukaiseksi. Tämä tarkoittaa juuri sitä, että jalankulkija saa “lorvia” keskellä pihakatua. Laissa todetaan kuitenkin epämääräisesti, että jalankulkija ei saa tarpeettomasti estää liikennettä.

Asiaan perehtyneenä ja lukuisia liikennesuunnitelmia kommentoineena, oman tulkintani mukaan tällä tarkoitetaan autoliikenteen estämistä kokonaan, ei sen hetkellistä hidastamista.

Väinönkadun muuttaminen pihakadusta kävelykaduksi olisi järkevää. Muutos lisäisi ydinkeskustan viihtyisyyttä, turvallisuutta sekä tukisi sitä eniten käyttäviä liikennemuotoja.

Läpiajoliikenne Väinönkadulla on jo kielletty ja liikenne koostuu lähinnä parkkihalleihin ajosta, rahti- sekä saattoliikenteestä.

Airaksisen mainitsema huoli saattoliikenteestä on oikeutettu – tämä liikenne tulee mahdollistaa. Näin Kauppakadun kävelykadulla on jo tehty.

Jokainen järkevä ihminen päästää hälytysajoneuvot kulkemaan myös piha- sekä kävelykaduilla vapaasti.

Kauppakadun somisteet on suunniteltu tarpeeksi väljiksi myös paloautoille ja roska-autoille. Airaksisen huoli tästä on turha ja tuntuukin siltä, että hakemalla haetaan syitä vastustaa ihmisille paremman keskustan syntymistä.

Kaupunkikeskustoja ei tule suunnitella 1960-lukulaisen ihanteen mukaan autoliikenteelle vaan sinne sopivammalle ja vähemmän tilaa vievälle jalankulku- sekä pyöräliikenteelle. Ajat ovat muuttuneet.

Leveät ajoradat eivät ole enää moderneja. Maailmalla on lukuisia hyviä esimerkkejä siitä, kuinka kaupunkikeskustat ovat muuttuneet elävämmiksi autoliikenteen rajoittamisen seurauksena.

Autoilijat eivät tee keskustan alueesta viihtyisämpää, ihmisläheisempää eikä sosiaalisempaa nököttämällä yksityisautoissaan.

Ainakin itse haluan keskustan mahdollistavan sosiaaliset, satunnaiset ja spontaanit tapaamiset, eväsretket ja kahvittelut terasseilla. Raikkaasta ulkoilmasta nauttimisen, penkillä kirjaan hukkumisen ja syvälliset keskustelut kanssaihmisten kanssa.