12 years with WordPress

My journey with WordPress started in the year 2008 when I was just 14 years old. We needed a new website for our scout troop and I had some experience with playing around with HTML, CSS and home server old rubbish PC under the bed. Eagerly with no real knowledge of building a website and not to speak about running a one in a production, I took the task.

I don’t remember exactly how we found each other with WordPress and why I ended up using it in the first place. But there’s one feeling that I do remember: excitement.

Excitement on how easy it was to modify the layout and publish content.

Fast forward to 2012. I had learned more PHP and already built numerous sites with WordPress to myself, friends and small associations. My media assistant studies in secondary school contained some web development with WordPress. At this point, I was already quite familiar with it (or at least I thought then) so my teacher ended up asking me to help my classmates in that course.

Almost two years passed by: I graduated from secondary school and worked in an elementary school kitchen (which is its own story). For some time, coding stayed in the background because of totally different kind of day job and depression. I did kick the tires once in a while but didn’t do anything serious.

First job as a developer

This is fine plush doll

In 2014 I landed on my first job in the industry. At the age of 19, I was the only developer in the advertising agency which had some seriously big clients and custom systems built with CodeIgniter. Luckily one previous developer committed to onboard me and provided help for the first few months. Nevertheless, this was a real crash course to the deep end of PHP and databases.

After a couple of discussions with the project managers, we ended up getting a few WordPress projects as well. Around this time I started attending regularly to un-official meetups, WordPress Café, organized by a different company called Exove.

The eleven months I worked for this advertising agency were probably one of the most educational ones I’ve ever had in my career to this day. Thank you, Tuomas for believing in me and taking the risk of hiring me to the position. Also thank you Erkka for being there when I had yet another stupid question. I wouldn’t know as much as today without you two.

Leap in the dark

Random selfie from some years ago

During secondary school, I had done some WordPress freelancing jobs to one digital agency. In late 2014 the owners decided to switch gears, grow the two-man company and hire a developer. They called me because they didn’t know any other skilled developers and offered a gig which would last a few months. If everything goes well, they would hire me full-time. I thought this overnight and jumped aboard.

Imagine being 20 years old, asked to work for a company with owners you admire and given almost free hands on developing the codebase and workflows. It was crazy cool! With the CTO we did amazing things, worked with really exciting projects and pushed ourselves to limits by making things we had no prior experience or idea how to pull it together.

I worked my ass off with creating the WordPress boilerplate theme and staying on top of client project deadlines. We were on some serious speed and growth! Even the workdays were long and the boundary between work and personal life almost disappeared, I still had much fun as I learned something new almost every day. Around this time I reported my first bugs in WordPress Core to Trac and submitted a patch to one.

Then the rumors came in: some group is organizing a full day WordPress event. After talking with my bosses, who almost didn’t allow me to participate, there I was. The first WordCamp organized in Finland: 2015. And it was awesome!

Shortly after that, an official WordPress Meetup started in Helsinki.
Guess if I started to attend those regularly? Hell yea I did!

Moving to the middle of nowhere

In early 2016 I moved to Jyväskylä (which is actually 7. biggest municipality in Finland) and started working in Dude as a second developer. One of the founders is my old friend from IRC and we both shared the passion towards WordPress.

WordCamp Finland 2016

Almost the same time came WordCamp Finland 2016 where I volunteered. I don’t remember much, except for the feeling of being part of something bigger and warm atmosphere during the whole event. It was soon after the WordCamp when I started co-organizing WordPress Meetups in Jyväskylä with Roni and Natanael.

Client projects and months passed by. At work, I was given projects that were complex and developed my skills. At this point latest, I realized that I’m much more into back-end development with WordPress rather than front-end. But with our two-person development team, there wasn’t much of a choice and I had skills on front-end also, so both of us did complete projects instead of splitting the tasks.

How I always find myself involved with something?

After some time, our community started having discussions about the next WordCamp in Finland. I volunteered to be part of the organizing team that works for many months to make the event happen. The team decided to put together WordCamp Helsinki 2017 and I was tasked to take care of speakers, event schedule and swag.

Year after year the WordCamps in Finland grew. In WordCamp Helsinki 2017 we had 250 attendees and 12 speakers covering a wide range of topics from development to business. I started to feel that it would be nice to have a bit smaller and 100% developer-focused WordCamp.

So started the project WordCamp Jyväskylä 2018 where I was the lead organizer. Our small but effective team did a truly awesome job on gathering 140 attendees and 13 speakers to the heart of Central Finland. We had a few international speakers and attendees, which was nice for a WordCamp of this size. And the feedback from the community was just pure love and honey. I’m biased to say, but I think the event was the best WordCamp I’ve ever attended.

WordCamp Jyväskylä 2018 organizer and volunteers.

Yet again, I don’t remember (if you do, please tell me!) what sparked me to take the next step with my involvement in the WordPress project. But nevertheless, I applied to be a Community Deputy right after the WordCamp Jyväskylä and got approved.

Global Community Team deputies are the persons that volunteer their time to keep WordPress event series running; Meetups, WordCamps and do_action hackathons. We do onboard new organizers, help them with all the possible questions they might have on organizing the events, oversee that everything goes smoothly, process the payments, keep our documentation for organizers up to date, provide helpful resources to make the event best possible and so on. You get the idea, we do a lot to support organizers of over 150 WordCamps and 700 Meetup groups around the world.

WordCamp Turku speaker badge

After I started as a deputy, my fellow community member told me that they were planning on organizing a second smaller WordCamp in 2018 focused on a wider audience and not just for developers. I helped the team to get started with planning, became the mentor for WordCamp Turku 2018 organizers and actually gave my first talk (which was ironically targeted for developers) there.

In 2018 I also mentored my first overseas event, WordCamp Nijmegen.

Big things (and events)

Some of our community members have had a dream of organizing a bigger WordCamp for few years. It started to come true in 2018 when they reached out to active community members on other Nordic countries. This lead to the forming of the WordCamp Nordic 2019 organizing team, which I became part of.

A calm moment before WordCamp Nordic starts

We sold out sponsor packages in 35 minutes, had mind-blowing 600 attendees and 26 speakers and the event was three days long. On the third day, we experimented on arranging activity day, where attendees had the possibility to enjoy nature in Seurasaari island or attend to city tour which visited also National Museum of Finland. At the end of the day, attendees got to experience the traditional sauna.

Organizing WordCamp Nordic did take a lot of free time away and was a tiring experience, but seeing all the Nordic communities come together was worth it. It almost felt like a small WordCamp Europe; everywhere you looked at were happy smiling attendees networking, enjoying the sessions or planning their contributions to WordPress. When we do this again?

Me and my friend Roni at WCEU16

In 2019 I also mentored my second event overseas: WordCamp Dhaka 2019 and had a big change in my life, as I became a partner in Dude. We hired a second employee – a fourth person working in the company. The size of the projects and clients increased, bringing a more complex and different type of development to my table. At this point, I focused my time and expertise only to complex back-end development. Since the first day of the company, we have stayed with WordPress and that’s also our plan for the future.

Coming back to WordCamps. I’ve attended one of the flagship events, WordCamp Europe, in 2016, 2017 and 2019. This year I have the privilege to be part of the organizing team and it’s super exciting! My responsibilities in the Community Events team are ensuring that the event is accessible for everyone and that the food will be good. Those are actually quite big tasks when considering the scale of the event, we expect thousands of attendees. Hope to see you in Porto!

Along these years at some points that I don’t recall, I’ve also given a few talks with my friend Roni in different WordPress Meetups. There was also an experiment to start the first Finnish WordPress podcast. Contributions to WordCamp.org site and tools. Translated versions of release posts on fi.wordpress.org. I don’t even remember all, go and check my WordPress.org org profile.

Some concluding thoughts

Contributing from holiday hammock

Congratulations if you read this full lengthy post, which didn’t have any other purpose than tell my story how I started contributing to the WordPress project. At the same time, you heard about my professional growth and how WordPress has played an important part to this day in my life.

There’s a lot of WordPress related activities filling my weeks and I’m really happy about that. The community has given and taught me so much. I wouldn’t be the person I am today without it. My plan for this post was to talk about that, but maybe until next time… 👋

Ekologista ja eettistä sähköä etsimässä

Vanha määräaikainen sähkösopimukseni on umpeutumassa pian ja se herätti kilpailuttamaan uuden sopimuksen. Viimeksi kaksi vuotta sitten sähkösopimusta tehdessäni elämäntilanne oli sellainen, että halusin lähinnä helpoimman järkevähintaisen sopimuksen.

Tällä kertaa halusin kiinnittää huomiota myös sähkön tuotantotapaan ja valitsemani sähköyhtiön taustoihin.

Continue reading “Ekologista ja eettistä sähköä etsimässä”

Going Google and Facebook free

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.

Continue reading “Going Google and Facebook free”

Sivuston tekemisen näkymätön osuus – tietorakenteen suunnittelu

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!

WCHEL17 järjestämisestä ja yhteisön tulevaisuudesta

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.


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.


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.

Miksi edes pohtia, valitseeko avoimen vai suljetun lähdekoodin julkaisujärjestelmän?

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.

Duden harharetki palvelinmaailmassa

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.

Pihakadulla kävelijä tosiaan on kunkku

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.

Onnettomuus joka ei ollut onnettomuus

Kirjoitus on julkaistu alunperin kaupunkifillarissa.

Onnettomuus on hassu sana, sitä käytetään kuvaamaan jos jonkinlaisia tilanteita. Viimeksi kiinnitin asiaan huomiota Helsingin sanomien uutisoidessa taksikuskista joka ajoi kahden pyöräilijän päälle.

”Useiden silminnäkijöiden mukaan henkilöauto on ajanut punaisia päin ennen onnettomuutta.”


Molemmat pyöräilijät loukkaantuivat onnettomuudessa, ja heidät kuljetettiin Töölön sairaalaan. Poliisi ei kommentoi pyöräilijöiden saamien vammojen laatua tarkemmin.

HS tavoitti kuljettajan, joka oli pysähtynyt toiselle ajokaistalle punaisiin valoihin Nordenskiöldinkadulla, kun taksi ajoi ohi. ”Taksi ajoi vähintäänkin reippaalla tilannenopeudella meidän ohi suoraan edessä katua ylittäneiden pyöräilijöiden päälle. He vain katosivat näkökentästä”, kuljettaja kertoo.

Kyseessä ei ole onnettomuus, vaan päälleajo. Punaista liikennevaloa ja toisia tienkäyttäjiä päin ajaminen ei tapahdu vahingossa, se on tahallinen teko jota kuljettajan ei olisi tarvinnut tehdä.

Toinen uutisointi jossa muistan kiinnittäneeni asiaan huomiota, koski tapausta jossa pyöräilijä kuoli.

Keskiviikkona tapahtuneen henkilöauton ja polkupyörän välisen liikenneonnettomuuden uhri menehtyi vammoihinsa tänään. Onnettomuus tapahtui eilen iltapäivällä Helsingin Mannerheimintiellä.

…silminnäkijän mukaan autoilija olisi törmännyt miespyöräilijään tahallisesti.

Silminnäkijän mukaan pyöräilijä ja autoilija lähtivät yhtä aikaa liikennevaloista, jonka jälkeen autoilija kiihdytti vauhtiaan ja koukkasi niin, että auton takakulma osui polkupyörään. Autoilija poistui paikalta törmäyksen jälkeen.

Kyseessä ei ole onnettomuus, vaan henkirikos. Toista tienkäyttäjää ei ohiteta, tämän eteen koukata ja sen jälkeen äkillisesti jarruteta vahingossa. Kuljettaja olisi voinut valita jatkaa omalla kaistallaan ajamista.

Onnettomuus on vahinko, tahattomasti tapahtuva, ei-toivottu sekä suunnittelematon tapahtuma. Kumpikaan edellä olevista esimerkeistä ei sovi tähän määritelmään, sillä niissä kuljettajat ovat itse päättäneet toimia tietyllä tavalla. Kummankaan esimerkin ajoneuvojen kuljettajat ovat tuskin suunnitelleet tekoaan, mutta vahinkoja tai tahattomasti tapahtuneita ne eivät varmasti ole.

Se on onnettomuus, jos kuljettaja saa ennakoimatta sairauskohtauksen kesken matkan. Kyseessä ei kuitenkaan ole koskaan onnettomuus, jos autoilija jättää huomioimatta muun liikenteen, päättää olla noudattamatta liikennesääntöjä tai ajaa ”isomman oikeudella” kuten haluaa. Kyseessä ei ole onnettomuus, jos autoilija jättää katsomatta pyörätielle kolmion takaa ja ei tämän takia havaitse pyöräilijää. Tällöin kyse on piittaamattomuudesta, ylemmyydentunteesta ja typeryydestä joka ei tapahdu vahingossa tai tahattomasti. Jokainen kuljettaja voi vaikuttaa omaan liikennekäyttäytymiseensä, päättää ajaako punaisia valoja päin vai ei ja toimiiko ohjaamansa tappavan metallikasan kanssa varomattomasti.

Uutisoinnissa sanavalinnoilla on merkitystä, sillä ne ovat usein ainoa asia jonka välityksellä saamme tiedon ja joiden perusteella rakennamme mielikuvamme tapahtuneesta. Vaikka onnettomuus on vakiintunut sanana kuvaamaan myös sellaisia tapahtumia, jotka eivät ole vahinkoja tai tahattomasti tapahtuvia, muovaa sen käyttö mielikuvaamme tapahtumien kulusta. Ajattelemme helposti, että päälleajo olisi ollut estettävissä jos X, Y tai Z – vaikka todellisuudessa kyseisen tapahtuman olisi voinut estää ainoastaan yksi asia: kuljettajan parempi liikennekäyttäytyminen.

Sanalle onnettomuus on useita kuvaavampia vaihtoehtoja. Ja ei, toimittajien paljolti käyttämä töytäisy ei kuulu tähän sanavalikoimaan. Töytäisy on sitä, kun joku kävelee liian kovaa kassajonon ohi ja hänen olkapää osuu jonossa oleviin. Töytäisy on lievä muoto tönäisystä. Siinä ei ole mitään lievää, kun autoilija ohjaa ajoneuvoaan siten, että liikenteen heikompi osapuoli kaatuu ja joutuu sairaalahoitoon. Kyseessä on vähintäänkin vakava piittaamattomuus, ellei jopa päälleajo. Usein myös liikennepako.

Lähes poikkeuksetta näissä ”onnettomuuksista” sekä ”töytäisyistä” kertovissa uutisissa, joiden heikompana osapuolena on ollut pyöräilijä, muistetaan myös mainita käyttikö pyöräilijä kypärää vai ei. Kypärä ei estä tappavan metallimöhkäleen kujettajaa ajamasta päälle, mikäli hän on jo tehnyt valintansa liikennesääntöjen noudattamatta jättämisestä. Suomessa ei ole kypärän käyttöpakkoa ja sen tehokkuudesta puhutaan ylistäen sekä korulausein, vaikka todellisuus ei ole niin mustavalkoinen. Miksi samankaltaisissa uutisissa ei mainita oliko ajoneuvon kuljettajalla lain vaatima turvavyö kiinni? Miksi vastaavissa uutisissa, joissa heikompana osapuolena oli jalankulkija, ei kerrota oliko hänellä heijastinliivi? Vastaan itse itselleni: koska se ei muuta tilannetta oleellisesti.

Kypärän käyttö tai käyttämättä jättäminen ei oikeuta autoilijan huonoa liikennekäyttäytymistä ja heikomman osapuolen lanaamista asvalttiin. Kypärän käyttämättä jättäminen ei myöskään vaikuta merkittäviltä osin tilanteen lopputulokseen, jos autoilija ajaa tonnien painoisella ajoneuvollaan kuuttakymppiä punaisia päin.

Näissä uutisoinneissa on myös toistuvana teemana unohdettu se, että tieliikenteessä ei vielä kulje itsenäisiä ajoneuvoja, vaan jokaisella ajoneuvolla on kuski. Tuon tuosta näkee otsikoita sekä uutisia, joissa autonominen auto on töytäissyt liikenteen heikompaa osapuolta tai ajanut päälle. Ei, ajoneuvo ei ole tehnyt sitä vaan sen kuljettaja.