Backend developer and WordPress enthusiast
Earlier today I needed to get posts across the entire WordPress Network installation into ACF post object field. To my surprise, this isn’t possible with ACF itself and few plugin implementations found from Github were abandoned or didn’t fit fully to my needs.
So what developer does in this kind of situation? Writes a plugin that adds a new field type.
Continue reading “ACF field for network post relations”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.
Continue reading “Three years on Contributing to WordPress project”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.
Continue reading “12 years with WordPress”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ä”I have had multiple websites for myself created in various ways; static HTML files, number of WordPress sites with dozens of different themes, flat-file CMS’s like Kirby and Grav…
Continue reading “Returning back to home”For a few years now, there has been silent, but a continuous
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.
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.
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:
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.
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.
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.
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.
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ä 🙂
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
