07.12.2021
Simo Hellsten

Töissä Drupal-ylläpidossa – millaista on kehittäjän arki?

Kuvittele, että sinulta kysytään työhaastattelussa, että osaatko jonglöörata. Sanot, että osaat – olet harjoitellut kauan neljän pallon pitämistä ilmassa samaan aikaan. “Hienoa, paikka on sinun”, he sanovat.

Sinulle heitetään ensimmäinen pallo. Se näyttää kuluneelta ja moneen kertaan paikatulta, mutta sinänsä ihan tavalliselta pallolta. Toiseksi palloksi saat pienen metallikuulan, jota ei saa rikki edes yrittämällä. Sen kanssa on helppoa ja huoletonta. Mutta kolmas pallo onkin iso ja painava lasipallo, joka pudotessaan hajoaa miljoonaksi sirpaleeksi. Lisäksi sinulle kerrotaan, että sinulle on myös neljäs pallo, mutta ensin täytyy odottaa turvallisuusluokitusta suojelupoliisilta. Ja osaathan sinä niillä jonglöörata, pidät vaan pallot ilmassa. Sitten kuun kolmantena keskiviikkona sinulle heitetään vielä viisi palloa lisää.

Tervetuloa ylläpito- ja pienkehitystiimimme arkeen!

Omakoodarit takaavat laadukkaan ja tehokkaan ylläpidon

Toimin ylläpitotiimissämme muutaman verkkosivuston omakoodarina, jolloin vastaan yhdessä toisen druidin kanssa sivuston ylläpidosta ja pienkehityksestä. Tällaiseen sivustoon olen perehtynyt huolellisesti ja viestin asiakkaan kanssa yleensä säännöllisesti. Eri sivustot voivat olla hyvin erilaisia. Toisinaan sivustoa on muokattu vuosien varrella useiden eri firmojen ja koodareiden toimesta moneen eri suuntaan. Tällöin vanhan teknisen toteutuksen selvittämiseen kuluu alussa helposti yhtä paljon aikaa kuin muutosten varsinaiseen tekemiseen. Juuri siksi meillä on sivustoille omakoodarit.

Yksinkertainen toteutus tekee sivuston ylläpitämisestä helppoa ja tietoturvasta varmaa. Sen sijaan sivusto, joka keskustelee internetin yli useiden muiden palveluiden kanssa, on teoriassa aina riskialttiimpi tietoturvan suhteen ja herkempi häiriöille. Monimutkainen sivusto on usein myös bisneskriittinen – sen häiriöt vaikuttavat asiakkaan liiketoimintaan suoraan.

Drupal-ylläpidossa monipuolisuus on valttia

Ylläpitotehtävissä vaaditaan monenlaista osaamista – on hyvinkin suotavaa olla jokapaikanhöylä. Hallitsen sekä sivuston ulkoasun muotoilun että palvelimella pyörivän ohjelmakoodin eli olen full stack developer. Osaan myös arvioida sivustojen käytettävyyttä ja saavutettavuutta ja vähän muutakin. Kaikessa ei kuitenkaan voi olla paras, joten lopulta ehkä tärkein taito on osata tunnistaa ongelmakohdat. Kun huomaa, mikä aiheuttaa ongelman tai mitä kohtaa koodissa tulee muuttaa, voi arvioida korjaukseen tai muutokseen tarvittavan työmäärän.

Osa ongelmista ratkeaa kansainvälisen Drupal-yhteisön julkaisemilla päivityksillä, osa taas vaatii koodausta alusta asti itse. Joskus ongelman voi ohjata toiselle koodarille, jolla on sopivampi osaaminen ongelman ratkaisemiseen. Oma yleishyödyllinen koodi julkaistaan vastavuoroisesti Drupal-yhteisön kautta muille.

Miltä näyttää tyypillinen työpäiväni?

Aloitan työpäiväni aina ylläpitotiimin aamupalaverissa. Palaverissa saan tietää, mitä kukin aikoo tehdä päivän aikana. Vaikka iso osa päivästä kuluu tiiviisti oman näppäimistön ääressä, tarvitsen toisinaan apua muilta. Säännöllinen tiimin kesken koordinoitava asia on katselmointien aikataulutus. Kaikille teknisille muutoksille tehdään vertaisarviointi toisen kehittäjän toimesta ennen kuin ne liitetään osaksi sivuston koodia. Katselmoinnit voivat joskus viedä jopa kokonaisen päivän ja aikataulutus pitää suunnitella siten, että projektit etenevät, eikä vertaisarvioinnista muodostu pullonkaulaa toisten työlle.

Suurempien sivustojen ylläpidossa suosimme viikkopalavereja asiakkaan kanssa. Etenkin silloin, kun sivustokokonaisuudessa on mukana monta toimijaa, on syytä pysyä hyvin perillä siitä, mitä kukin on tekemässä. Useimmat säännölliset palaverit pyritään pitämään lyhyinä, vartista puoleen tuntiin.

Oman työskentelyn ohessa käyn keskusteluja Slackissa. Chattaan sekä työtovereiden että asiakkaiden kanssa pyytäen tarkennuksia tai neuvoja. Kun saan jonkin kokonaisuuden valmiiksi, teen koodista PR:n eli pull requestin – lisään muutokset koodivarastoon ja pyydän kollegaa katselmoimaan muutokset: onko koodi toimivaa ja tekeekö se sen, mitä asiakas on pyytänyt. Odottaessani oman koodini vertaisarviointia voin siirtyä tekemään sivustolle seuraavaa muutosta.

Muutostarpeet on kirjattu projektinhallintasovellukseen “tiketeiksi”. Meillä on oma Jira-järjestelmämme, mutta sivustoilla voidaan käyttää myös asiakkaan projektinhallintasovellusta ja koodivarastoa. Sekalainen työkalupakki ei helpota kehittäjän elämää, mutta toisaalta vaihtoehtoiset ratkaisut tulevat näin tutuksi. Jos en ota työn alle uutta tikettiä, voin tehdä katselmointeja toisten koodille.

Iltavuoroja tietoturvan tähden

Keskiviikkoisin, kun työpäivä on ohi ja olen hakenut lapsen iltapäiväkerhosta, palaan työpuhelimelle illalla vielä hetkeksi. Keskiviikkoisin nimittäin julkaistaan Drupalin tietoturvapäivitykset ja se tapahtuu Yhdysvaltojen aikavyöhykkeiden ehdoilla. Drupal-ytimen päivitykset julkaistaan aina kuun kolmantena keskiviikkona. Jos tietoturvapäivityksiä julkaistaan, saan niistä viestin heti, kun tietoturva-aukon paikkaava koodi on julkaistu.

Yleensä julkaistavat päivitykset eivät ole isoja, mutta toisinaan kyseessä onkin kriittinen Drupal-ytimen päivitys. Tällöin teen pikaisen arvion siitä, millä sivustoilla Drupalin ytimestä löytynyt haavoittuvuus on merkittävä – tämä riippuu yleensä teknisen toteutuksen ja asetusten yhdistelmästä – ja tarvittaessa viestittelen kollegoiden kanssa jo illalla. Usein päivitykset eivät ole niin kiireisiä, että työpäivää olisi tarvetta jatkaa yötä myöten. Silloin jatkamme päivityksiä hyvin levänneinä seuraavana päivänä. Työnjaosta sovimme jälleen aamupalaverissa.

Drupal-ylläpidossa työskentelyn parhaita puolia on se, etten ole koskaan yksin, vaikka etätöitä teemmekin. Asiakasta palvellessani tukenani on aina tiimi, tarvittaessa koko muu työporukka ja loppupeleissä Drupalin kansainvälinen yhteisö. Työpäivän aikana näyttöpäätteeni viereen eksyy toisinaan myös kehräävä kissa pitämään seuraa.

Kiinnostaisiko sinuakin työt Drupal-ylläpidon parissa?

Kirjoittaja

Simo Hellsten

Full Stack Developer
28.09.2021
Pasi Järnstedt

Mikä Drupal-ylläpidossa maksaa?

Taas joku päivitys! Sivustonihan toimii aivan hyvin, onko pakko päivittää? Kyllä vaan, tietoturva- ja järjestelmäpäivitykset todellakin on tehtävä, jos haluat verkkosivustosi pysyvän toimivana ja turvallisena. Sivustosi kun toimii hyvin juuri siksi, että järjestelmän tietoturvasta ja kehityksestä huolehditaan.

Mutta miksi sivustoa on päivitettävä niin usein? Ja ennen kaikkea: mikä Drupal-ylläpidossa oikein maksaa?

Älä ota teknologiavelkaa

Jos omistat talon, annatko paikkojen rapistua, ennen kuin lopulta ryhdyt massiiviseen remonttiin (ja pahimmassa tapauksessa joudut toteamaan, että on järkevämpää rakentaa uusi kuin remontoida vanhaa)? Vai korjaatko mieluummin vähän kerrallaan aina tarpeen tullen?

Verkkosivuston teknologiavelan hallinnassa on kyse samasta asiasta. Drupal-järjestelmää – sen ydintä sekä moduuleja – kehitetään jatkuvasti. Jos päivityksistä ei huolehdita, sivustosi jää kehityksestä jälkeen ja sen teknologiavelka kasvaa. Kun sitten viimein ryhdytään suureen päivitysurakkaan, joudutaan usein ojasta allikkoon: päivitykset aiheuttavat ongelmia, kun vanhentuneet moduulit eivät enää suostu tekemään yhteistyötä vaan pistävät sivustosi sekaisin.

Drupal-järjestelmään julkaistaan kahdenlaisia tietoturvapäivityksiä: Drupal-ytimen päivitykset tehdään aina, koska kyse on kirjaimellisesti ydinasioista, moduulipäivitykset silloin, kun kyseinen moduuli on verkkosivustollasi käytössä. Hyvin yleinen on esimerkiksi Webform-moduuli: palikka, jolla voi rakentaa sivustolle lomakkeita.

Vaikka jokin moduuli ei olisi sinulle erityisen tärkeä tai edes aktiivisessa käytössä, on tärkeää pitää se ajan tasalla, jotta sivustosi päivitykset sujuisivat ongelmitta. Kun Drupal-moduuleita kehitetään, niiden toimintalogiikka voi muuttua. Tämän vuoksi vanhentuneet moduulit voivat lakata toimimasta järjestelmäpäivityksen yhteydessä tai rikkoa jotain muuta sivustollasi. Ne myös luovat tietoturva-aukkoja ja näin altistavat sivustosi tietoturvamurroille.

Kun verkkosivustosi on teknisesti stabiili ja ajantasainen, päivitysten yhteydessä harvemmin tulee yllätyksiä. Vähemmän yllätyksiä tarkoittaa tietysti vähemmän lisätyötä meille ja vähemmän yllättäviä kustannuksia sinulle.

Omakoodari palveluksessasi

Meillä Druidilla Magical Supportin kiinteä kuukausihinta takaa sinulle tarvittavat resurssit verkkosivustostasi huolehtimiseen – toisin sanoen omakoodarin tai useamman.

Tällä resurssivarauksella pystymme varmistamaan riittävän nopean reagoinnin etenkin kriittisissä tilanteissa tai tietoturvapäivityksissä. Ripeä toiminta on tärkeää, sillä tietoturva-aukot ovat helposti hakkereiden hyödynnettävissä. Valvomme myös sivuston tietoturvapäivitysten tilaa sekä hostingin toimivuutta automaattisen valvonnan avulla.

Omakoodari oppii tuntemaan sivustosi hyvin, mikä näkyy ylläpidon ja pienkehityksen tehokkuutena ja virheettömyytenä. Slack-kanava on aina auki ja voit keskustella omakoodarisi kanssa suoraan ilman turhia välikäsiä.

Varsinaisen koodaustyön laskutamme erikseen tuntityönä. Työmääräarviomme ovat sitä tarkempia, mitä tutumpi sivustosi meille on. Tässäkin mielessä omakoodarista on paljon hyötyä puolin ja toisin. Vaikkei henkilövaihdoksilta aina voi välttyä, aktiivisella yhteistyöllä pysymme hyvin kartalla sivustosi tilanteesta.

Drupal vaatii huomiota mutta palvelee hyvin

Drupal on ohjelmistotuotteena hyvin joustava ja monipuolinen. Se räätälöidään aina asiakkaan tarpeiden mukaiseksi, ja näitä räätälöintejä on muokattava ja päivitettävä.

Jos sivustosi ei ole alun perin meidän rakentamamme, on vaikea tietää etukäteen, miten päivitykset vaikuttavat räätälöinteihin – ennustajia emme sentään ole, vaikka paljon Drupalista tiedämmekin. Joskus sivuston taustalla voi olla hyvinkin erikoisia ratkaisuja, jotka paljastuvat meille vähitellen, kun tutustumme sivustoon yhä paremmin. Ennustettavuuden haaste ei toki koske vain Drupalia vaan se on räätälöityjen ratkaisujen kohdalla yleinen.

Myös Drupalin ympäristö muuttuu, mikä usein edellyttää muutoksia myös Drupal-järjestelmään. Esimerkiksi selaimet ja näyttöjen resoluutiot kehittyvät, ja teknisen maailman ulkopuoleltakin kumpuaa uusia vaatimuksia ja tarpeita: saavutettavuus, evästeiden hallinta ja analytiikka ovat nyt ajankohtaisia kehityskohteita.

Pyrimme aina rakentamaan mahdollisimman pitkäikäisiä ja helposti muokattavissa olevia verkkosivustoja. Täysin tulevaisuuden kestävää valmista Drupal-ratkaisua ei kuitenkaan ole olemassa vaan sivuston säilyttäminen ajanmukaisena vaatii aina työtä. Jos työn tekee hyvin, Drupal palvelee muuttuvia tarpeitasi uskollisesti vuosikausia, ellei vuosikymmeniä.

Haluatko tietää lisää ylläpito- ja pienkehityspalveluistamme?

Kirjoittaja

Pasi Järnstedt

Director, Production
DrupalCon Seattle ryhmäkuva
25.05.2020

Drupal 9 on täällä – päivitys voi olla pikkujuttu tai suuri ponnistus

Drupal-sisällönhallintajärjestelmästä julkaistaan uusi versio 3.6.2020. Drupal 9 -versioon on siirryttävä viimeistään marraskuussa 2021, jos käytössäsi on nyt Drupal 8. Sen sijaan Drupal 7 saa pidemmän siirtymäajan marraskuuhun 2023 asti. Näiden takarajojen jälkeen tuki aiemmille 7- ja 8-versioille loppuu eli tietoturvapäivityksiä ei enää ole niihin saatavilla. Mikä muuttuu uuden version myötä? Kuinka suuri työ järjestelmän päivittäminen on?

Drupal logo


Parhaat uutiset heti alkuun: järjestelmän päivitys käy tuossa tuokiossa, jos käytössä on ajantasainen Drupal 8. Mikään ei käytännössä muutu. Tämä meidän sivustomme esimerkiksi pyörii jo Drupal 9:n beta-versiolla eikä päivityksessä kauan nokka tuhissut. Kaikki tapaukset eivät kuitenkaan ole yhtä suoraviivaisia, ja etenkin Drupal 7 -pohjaisten sivustojen päivitys tulee olemaan iso ponnistus.

Drupal 8 päivittyy riskittömästi ja helposti 

Monet Drupalin aiemmat suuret versiopäivitykset ovat kieltämättä olleet melkoisen työläitä ja hankaliakin, kun verkkopalvelu on päivityksen myötä täytynyt käytännössä täysin uudistaa teknisesti. 

Nyt kaikki on kuitenkin toisin. Drupalia ei tällä kertaa keksitä uudelleen ja kyseessä on vuosikymmenen helpoin iso versiopäivitys – edellyttäen, että verkkopalvelunne pyörii tällä hetkellä uusimmalla Drupal 8 -versiolla. Drupal 9 ei nimittäin juurikaan eroa siitä.

Teknisesti Drupal 9 on ikään kuin Drupal 8:n viimeinen versio, josta vanhentunut koodi on siivottu pois ja riippuvuudet kolmansien osapuolten järjestelmiin päivitetty. Siirtymä on siis todennäköisesti helppo ja sujuva, eikä isoja uudistuksia verkkosivustolle tarvitse tehdä.

Perussivuston päivitys 9-versioon sujuu tuosta noin vain, kunhan sivuston päivitykset ovat ajan tasalla eikä käytössä ole vanhentuneita moduuleja tai rajapintoja. Jos sivustollanne on käytössä lisämoduuleja, on ensin tarkistettava, ovatko ne päivitysvalmiita. Myös itse tehty, räätälöity koodi on tarkistettava ennen versiopäivitystä.

Entä jos käytössä on vielä Drupal 7?

Lyhyestä virsi kaunis: verkkosivu-uudistus kannattaa pikkuhiljaa ottaa pohdintaan ja agendalle, sillä tiedossa on suurehko projekti, jonka deadline häämöttää 1.11.2023 Drupal 7 -version tuen loppuessa*. 

Drupal 7 on sekin yhä laajassa käytössä, mutta päivitys siitä 9-versioon on väistämättä aika paljon mutkikkaampi homma, tai ainakin työläämpi. Drupal 7 -verkkosivusto on uudistettava teknisesti, jotta siirtymä 9-versioon on mahdollinen. Tämä johtuu siitä, että versioiden 7 ja 8 välillä Drupalin teknologia uudistettiin täysin. 

Hyvä uutinen on kuitenkin se, että tämä jää hyvin todennäköisesti viimeiseksi suureksi versionpäivitysurakaksi, joka verkkopalveluunne on koskaan tehtävä. 

Drupalin tuotekehityksessä on nimittäin siirrytty kankeahkosta, projektiluontoisesta kehitystyöstä nykyaikaisempaan ja ketterämpään jatkuvaan kehitykseen. Sen sijaan, että rysäytetään koko järjestelmä uuteen uskoon muutaman vuoden välein, uusia ominaisuuksia ja parannuksia julkaistaan nopeammalla syklillä ja pienemmällä päivitysvaivalla.

Miksi Drupal 9:ään kannattaa siirtyä nyt eikä myöhemmin?

Ominaisuuksiltaan Drupal 9 on samanlainen kuin Drupal 8. Sen tarkoitus on tarjota mahdollisimman vaivaton siirtymä Drupal 8:sta, joten uudistuksia on tehty vain konepellin alla tietoturvatuen mahdollistamiseksi marraskuusta 2021 eteenpäin. Eli eipä tässä vielä kiirettä?

No, ei ehkä tulipalokiirettä, mutta vahvasti suosittelemme päivittämistä mahdollisimman pian, sillä jatkossa uusia ominaisuuksia ja parannuksia julkaistaan kahdesti vuodessa pienemmissä päivityksissä. Seuraava tällainen päivitys, Drupal 9.1.0, on määrä julkaista tämän vuoden joulukuussa. 

Esimerkiksi admin-käyttöliittymän modernisointi on parhaillaan loppusuoralla, mikä tuo parannuksia sivuston ylläpitoon ja sisältöjen hallintaan. Kun päivitätte verkkopalvelunne Drupal 9:ään hyvissä ajoin, pysytte mukana järjestelmän kehityksen aallonharjalla ja pystytte hyödyntämään jatkuvan kehitysprosessin tuotokset. 

Me autamme Drupal-järjestelmän päivityksissä

Olemme Suomen kovimpia Drupal-tekijöitä ja tunnemme Drupalin kuin omat taskumme. Ota yhteyttä niin katsotaan, miten teidän kannattaa edetä päivityksissä.


*Edit 4.5.2022: Drupal 7 -järjestelmän tukea on päätetty jatkaa 1.11.2023 asti. Aikaraja on päivitetty tekstiin.

Yläkuva: “Preparing for the group photo at DrupalCon Seattle” / Rob Shea / CC BY-SA 2.0


 

laptop table coffee light
12.03.2019
Marko Korhonen

And now for something completely different

Druid tunnetaan Drupal-kehittäjänä. Sitä me olemmekin. Useimmat projektimme voidaan sijoittaa Drupal-kategoriaan, kun sisällönhallintajärjestelmää tarvitaan. Drupal ei kuitenkaan aina ole oikea työkalu tehtävään. Kuten Dries Buytaert sanoi Wienissä järjestetyssä DrupalCon-tapahtumassa: “Drupal ei ole enää tarkoitettu yksinkertaisiin sivustoihin”, eikä Drupal yleisesti ottaen sovi jokaiseen käyttötarkoitukseen. Se on kuitenkin erittäin hyvä vaihtoehto oikeanlaisissa projekteissa.

Olemme viime aikoina tehneet joitakin ei-Drupal-projekteja, joten nytpä kerron teille yhdestä sellaisesta. Tässä tapauksessa ei-Drupal kuitenkin tarkoittaa, että teknologiapaketti ei ollut meille aivan uusi, sillä tunnemme jo entuudestaan ohjelmointikielet (PHP ja JavaScript) hyvin.

Tarve  – say no more, say no more

Asiakkaallamme oli projektin alussa jokseenkin strukturoimaton tarve, sillä asiakkaan kohdemarkkina on suuren mullistuksen kourissa. Tämän kyseisen markkinan digitaalinen ympäristö on muutostilassa, ja – kuten aina – muutokseen on osattava sopeutua. Projektin alkaessa meillä oli tiedossa, että sovelluksen tulee olla mobiiliystävällinen ja sen päätoimintona tulisi olla käyttäjien välisen kommunikaation mahdollistaminen. Siitäpä sitten kehitysjonoa luomaan!

Mobiili? Ajattelimme, että PWA on oikea valinta. Me Druidilla olemme olleet PWA:n faneja jo hyvän tovin ja olemme kirjoittaneet kyseisestä hienosta konseptista ennenkin. Progressiiviset verkkosovellukset ovat tulevaisuutta, ja niissä on paljon potentiaalia. PWA on myös hyvä vaihtoehto silloin, kun sovelluksia halutaan jakaa ilman App Storea tai Play Kauppa -palvelua. Jotkin sisäiset työkalut voitaisiin toimittaa esimerkiksi intraneteistä. Kerron PWA:sta lisää tuonnempana. Joka tapauksessa ajattelimme, että PWA sopisi tarkoituksiimme erinomaisesti.

Kommunikaatio? Wink wink nudge nudge. Say no more, say no more. Tämä herätti ideoita tietorakenteista ja käyttöliittymästä.

Teknologiapaketti – And Now for Something Completely Different

Päätimme olla rohkeita ja kokeilla aivan uusia komponentteja uudessa projektissa – frontendissä, backendissä, tietokannassa ja infrastruktuurissa. Tokihan taustalla oli tietoa ja oppimista soveltuvuusselvitysten ja vastaavan kautta. Ja kuten sanoin, teknologia oli meille jo tuttua. Tai ainakin osalle tiimimme jäsenistä.

Jos aloitetaan ihan pohjalta, valitsimme Dockerin liimaksi, joka pitää komponentit ja ympäristöt kasassa. Luonnostelimme nopeasti Docker-osuudesta avoimen lähdekoodin version ja julkaisimme sen omana juttunaan nimellä Stonehenge. Stonehenge on usean projektin paikallinen kehitysympäristö ja työkalusetti Dockerissa. Projektissa käytetään Stonehengeä kehittäjän työkaluna homman pyörittämiseen. Koska paikallinen kehitysympäristö on melko yleinen ongelma kehittäjille, ajattelimme, että tästä voisi olla hyötyä muillekin. Sen vuoksi erottelimme tämän toiminnallisuuden projektista ja julkaisimme sen erillisenä työkaluna.

Pohjimmiltaan Stonehenge tarjoaa meille paikallisia URLeja ja välityspalvelimen käsittelemään liikenteen projekteissamme. Välityspalvelin tehtiin Traefikilla, joka on suoranainen tuulahdus raikasta ilmaa verrattuna aiempiin samaa tarkoitusta varten käytettyihin teknologioihin. Voin sanoa, että se toimii ja suoriutuu oikein mainiosti tuotantopuolellakin!

Projekti itsessään määrittelee sovelluksemme tarjoamat palvelut – perusjutut, kuten Nginxin, PHP:n, tietokannan ja komentorivin, sekä kaikkien niiden suhteet. Tähän käytämme Docker Composea.

Sovellukseksi itsekseen valitsimme Symfony 4:n backendiin ja Reactin frontendiin. Symfony periaatteessa luo standardin JSON-ohjelmointirajapinnan, jonka React-sovellus sitten käyttää. Yksi syy Symfonyn valintaan oli tietokantamme (mikä se voisi olla?) tukeminen Doctrinen kautta. Kun arvioimme eri kehikkoja backendiin (PHP), tutkimme muiden kehittäjien käyttökokemuksia, ja vaikutti siltä, että kenelläkään ei ollut pahaa sanottavaa Symfony 4:stä. Ja sen käyttö olikin todella mieluisaa. Joillakin meistä oli jo kokemusta Symfonystä, sillä Drupal 8 on rakennettu Symfony 3:n päälle. Siitä huolimatta meillä oli vielä paljon uusia asioita opittavaksi.

Tietokanta. MySQL, MariaDB, PostgreSQL vai jotakin muuta? Päädyimme valitsemaan MongoDB:n, jotta hyppymme tuntemattomaan olisi täydellinen. MongoDB on niin kutsuttu NoSQL-tietokanta, missä data tallennetaan objekteina rivien sijaan. Tämä on hyödyllistä sellaisen datan kanssa, joka voi olla rakenteeltaan hyvin erilaista (lue: dokumentissa voi olla dataa, jota muissa samaa tyyppiä olevissa dokumenteissa ei ole). Lisäksi skeemaa ei tarvitse määritellä etukäteen (ja päivittää), vaan se elää sen mukaan, kuinka käytät dokumentti-objekteja.

Reactista en itse osaa kirjoittaa kovinkaan paljoa, mutta kollegani Kristian on kirjoittanut alle pienen kertauksen sen käytöstä projektissamme. Varoituksen sana kuitenkin: Javascript-maailman riippuvuushelvetti ja valtaisa määrä samanlaisia mutta erilaisia työkaluja saattavat joskus tehdä kehittäjän elämästä ikävää.

Lainaus Kristianilta:

“Oli aika mahtavaa päästä käyttämään Reactia isossa projektissa. Yleisesti ottaen React oli varsin mutkaton. Teimme toki joitain virheitä aikaisessa vaiheessa projektia, mikä pakotti tekemään refaktorointeja.

Alkuperäinen suunnitelma oli renderöidä suurin osa sovelluksesta Twigillä, jolloin vain kommunikaatiopuoli olisi ollut Reactin alaisuudessa. Lopulta päädyimme siirtämään suurimman osan sovelluksesta Reactiin. Se tarkoittaa, että emme luoneet minkäänlaista reititysjärjestelmää emmekä suunnitelleet storen arkkitehtuuria. Onneksi refaktorointi onnistui melko tuskattomasti ongelmien ilmetessä.

Minulle hauskin osa projektia oli MobX:n käyttäminen. Olen halunnut kokeilla sitä jo pitkän aikaa, joten olen tyytyväinen, että sain tilaisuuden käyttää sitä kaupallisessa sovelluksessa. MobX on pohjimmiltaan tilanhallintatyökalu, joka perustuu tarkkailijamalliin. Kaikki tarkkailijat, jotka seuraavat tarkkailtavaa muuttujaa, päivittyvät kuin taikaiskusta aina kun tarkkailtava arvo muuttuu.

Jos voisin muuttaa yhden asian seuraavaa kertaa varten, käyttäisin varmaankin mieluummin MobX State Tree -kirjastoa, joka on kantaaottavampi versio MobX:stä. Se käyttäytyy Reduxmaisesti, mutta ilman Reduxin kuormaa.”

Siinäs kuulitte.

Kun hyppäsimme PWA-remmiin, loimme Reactin avulla yhden sivun sovelluksen, joka auttaa joissain PWA:n puolissa. No mitä PWA sitten tekee? Sitä voi ajatella sovelluksena, joka on periaatteessa verkkosivu. Se tarkoittaa, että App Storea tai Play Kauppaa ei tarvita jakeluun. Sovellus päivittyy, kun verkkosovellus päivitetään. Siinä on muutamia ominaisuuksia, jotka tekevät kokemuksesta “sovellusmaisen”: tiedon tallentaminen välimuistiin prosessin nopeuttamiseksi, standalone-tila (oman, ilman selainkomponentteja toimivan käyttöliittymän tekemiseen), pääsy joihinkin mobiiliohjelmointirajapintoihin sekä offline-toiminnot. Lisäksi on mahdollista käyttää Push-ilmoituksia, mutta ne toimivat vain Androidilla. Lisätietoa voi lukea 2018 State of Progressive Web Apps -artikkelista.

PWA on huvittavaa kyllä jotakin, mitä Apple visioi jo vuonna 2007 julkistaessaan alkuperäisen iPhonen. Google ajaa yhä vahvasti nykyistä hommaa, joten periaatteessa PWA toimii paremmin Android-luureilla.

Onni suosii rohkeaa, ja uskon vahvasti, että PWA on sovellusten tulevaisuus – ja se on erityisen hyödyllinen, kun luodaan työkaluja organisaatioille ja yrityksille.

Siinä oli teille melko pitkä avautuminen teknisistä jutuista. Eiköhän vedetä vähän henkeä tässä välissä.

“And now a film about a man with a tape recorder up his brother’s nose.”

GDPR-aspekti

Niin, se pahamainen GDPR. Tällä hetkellä meillä ei ole varsinaista käyttäjädataa, joten meillä ei ole hätää. Me suunnittelimme koko kehitystyön mallidatalla, mikä osoittautui hyvin hedelmälliseksi projektin aikana. Lisäsimme datafikstuureja, jotka täyttivät tietokantamme mallidatalla. Joten siinä mielessä noudatamme täysin GDPR:ää kehitystyötä tehdessämme. Emme tarvitse tuotantodataa.

Tästä oli myös odottamatonta hyötyä. Testatessa huomasimme pian, että kykenimme käyttämään tätä luotua dataa testeissämme. Aika siistiä, eikö? Todellakin!

“In this picture, there are 47 people. None of them can be seen.”

Seuraavat vaiheet

Projekti on tällä hetkellä MVP-vaiheessa ja on siirtymässä “kenttätesteihin”. Toivottavasti loppukäyttäjät pitävät siitä, mitä olemme tehneet. Testaukset toteutetaan kontrolloidusti pienissä ryhmissä. Se tarkoittaa, että käytämme määrättyä, generoitua dataa, joka sopii kullekin testiryhmälle. Lisäksi kontrolloimme MVP-vaiheen PWA-puolta. Tällä hetkellä se toimii parhaiten Androidilla, joten käytämme sitä alustana testeissämme.

“Now, what’s to be done? Tell me sir, have you confused your cat recently?”

Kookospähkinästä

Olemme oppineet paljon! Tämä tarkoittaa, että opitut asiat vaikuttavat jo uusiin projekteihin ja jonkin verran myös tapoihin, joilla hoidamme vanhoja projekteja. Aiomme kopioida backend-kaman uuteen API-keskeiseen projektiin ja Docker-jutut ovat kehittyneet jo hyvinkin käytettävään muotoon. Lisäksi avoimen lähdekoodin projektin (Stonehenge) julkaiseminen oli plussaa!

Hienoin osa ainakin minulle on ollut kaiken tämän jakaminen yhä suuremmalla joukolle druideja, jolloin kaikkea opittua voidaan hyödyntää laajemmalla mittakaavalla.

“Wait a minute — supposing two swallows carried it together?”

Marko Korhonen
CTO, The Ministry of Silly Walks

Kirjoittaja

Marko Korhonen

Platform Engineering Lead
GDPR auditointi
20.02.2017
Mikko Hämäläinen

GDPR kiristää tietosuojavaatimuksia – aloita valmistautuminen jo nyt

GDPR (General Data Protection Regulation) on EU:n uusi tietosuoja-asetus, joka koskee kaikkea henkilötietojen käsittelyä. Omien järjestelmien ja prosessien päivittäminen voi olla monelle yritykselle vuoden 2017 suurin investointi ja todennäköisesti se sivuaa jollain tasolla myös sinun toimintaasi. GDPR tuo mukanaan ison muutoksen yrityksille.

Tietosuojalaki on astunut voimaan jo keväällä 2016, mutta sen soveltaminen alkaa vasta ensi vuoden toukokuussa. Käytännössä viimeistään silloin systeemien on oltava ajan tasalla, asetuksen rikkojalle lankeavat maksimisanktiot kun ovat miljoonaluokkaa. Atk-amatöörin on hankala käsittää, mitä kaikkea käyttäjätietoa omat järjestelmät tallentavat ja louhivat. Tietosuoja-asetus koskee niin intranettiin excelissä tallennettua henkilöstölistaa, verkkosivuston Google-analytiikkaa kuin verkkopalvelusi käyttäjädataa. Ja myös kaikkien edellisten varmuuskopioita.

Mitä GDPR tarkoittaa käytännössä?

GDPR peräänkuuluttaa ennen kaikkea läpinäkyvyyttä henkilötietojen käsittelyyn. Henkilötietoa on kaikki sellainen tieto, josta henkilön voi tunnistaa suorasti tai epäsuorasti – myös esimerkiksi evästeet ja paikkatieto ovat henkilötietoja.

Verkkopalvelun käyttäjältä tarvitaan ensinnäkin aktiivinen suostumus henkilötietojen keräämiseen. Esimerkiksi valmiiksi ruksittu “hyväksyn käyttöehdot” -laatikko ei enää kelpaa. Käyttäjällä on oikeus tietää, mitä tietoja hänestä on kerätty sekä oikeus päästä käsiksi näihin tietoihin. Hänellä on myös oltava mahdollisuus muokata, siirtää ja poistaa tietojaan sekä rajoittaa niiden käsittelyä.

GDPR vaatii myös nopeaa reagointia. Yritysten on esimerkiksi pystyttävä poistamaan käyttäjän tiedot ja ilmoittamaan tietomurroista viranomaisille ilman aiheetonta viivytystä. Myös käyttäjille, joiden yksityisyyden suojaan tietomurto vaikuttaa, on ilmoitettava.

Yritysten on pystyttävä osoittamaan, että ne noudattavat GDPR-lainsäädäntöä. Tämä on merkittävä muutos, sillä tällaista osoitusvelvollisuutta ei Suomessa ole ennen ollut, ja niinpä se edellyttää uusia toimintamalleja. Tietojärjestelmät tulee lähtökohtaisesti suunnitella niin, että ne tukevat tietosuojaa.

Nykytilanteessa henkilötietojen käsittely tietojärjestelmissä ei välttämättä ole läpinäkyvää. Eksplisiittisesti tallennettujen tietojen lisäksi järjestelmät voivat täydentää tietoja automaattisesti esimerkiksi analytiikan tai antureiden avulla. Lisäksi järjestelmät tallentavat tietoa useisiin eri paikkoihin, kuten välimuisteihin, varmuuskopioihin ja liitettyihin ulkoisiin järjestelmiin.

Miten tietosuojalain muutokseen voi valmistautua?

Oman pesän selvittely kannattaa aloittaa pikimmiten, sillä tietämättömyys ei enää vuoden päästä pelasta lakituvalta. Omat asiakkaamme saavat ennen takarajaa sopimustäydennykset, joilla selkeytetään tiedonkulkua ja vastuita osapuolten välillä: joissain tapauksissa meillä ei ole roolia asiakkaan henkilötietorekisterien käsittelyssä, ja joissain tapauksissa kehittämissämme verkkopalveluissa käsitellään arkaluontoistakin henkilötietoa.

Lakimiehet ja asiantuntijatahot tarjoavat erilaisia GDPR-kartoituksia ja -selkeytyksiä, niin myös me. Olemme lähteneet selvittelemään asetuksen vaikutuksia omaan ja asiakkaidemme toimintaan jo hyvissä ajoin.

Drupal GDPR -auditointimme on vastaus Drupaliin liittyviin epäselvyyksiin. Kartoitamme auditointiprojektissa muun muassa järjestelmän käsittelemän henkilötiedoksi laskettavan datan ja sen tallennuspaikat sekä tiedon hallintaan liittyvät prosessit. Tilaaja saa projektin jälkeen käteensä selväkielisen raportin, jonka hän voi tarvittaessa antaa eteenpäin organisaationsa tietosuojavaltuutetulle tai lakimiehille. 

Olemme myös aloittaneet GDPR-yhteensopivuutta edistävän Drupal-moduulin kehitystyön, jolla on tarkoitus automatisoida osa tarkistuksista. Avoimen lähdekoodin projektin sivut löytyvät drupal.orgista täältä.

Tietosuojalain vaatima ponnistus ei vaikuta kohtuuttomalta, mikäli yritys on noudattanut jo nykyisin voimassa olevia lakeja ja asetuksia henkilötietojen käsittelystä. Aina näin ei kuitenkaan ole, ja papereiden parsimiseen lähdetään tuntuvalta takamatkalta. GDPR-seminaareista on syntynyt sellainen vaikutelma, ettei EU:ssakaan vielä tiedetä, miten asetusta kuuluu pilkulleen noudattaa. Ensin tulee laki ja sitten terve järki.

Kannattaa joka tapauksessa olla ajoissa liikkeellä ja ottaa uusi tietosuojalaki tehokkaasti haltuun. Vältyt mittavilta sanktioilta, ja mikä tärkeintä, läpinäkyvyyden ansiosta kasvanut asiakkaittesi luottamus voi tuoda yrityksellesi kilpailuetua. 

Jos kaipaat apua, ota yhteyttä ja kysy lisää Drupal GDPR -auditoinnistamme.

Kirjoittaja

Drupal Magic
25.10.2016

Drupal-magiaa druidien opissa

Oli loppuvuosi 2014 Helsinki Business Collegessa, jossa tuolloin opiskelin. Ryhdyimme työstämään kurssityönä lounaslistahärpäkettä, josta kukaan ei ollut mitenkään innoissaan, mutta pakkohan sitä oli tehdä, jotta pääsisi kurssista läpi. Sitten tapahtuikin ihmeitä: koulu otti yhteyttä Druidiin ja sai järjestettyä meille druidien vetämän Drupal-koulutuksen tylsän kurssimme sijaan. Kuulosti tosi hyvältä!

Aloimme opetella Drupal 7:n perustoimintoja ennen koulutusta: miten järjestelmä asennetaan laitteelle, miten ladataan ja otetaan käyttöön moduuleja ja teemoja, myös hieman gitin käyttöä. Rakensimme pienryhmissä sivustoja, jotta saimme perusteet käytännössä suurin piirtein haltuun.

Drupal-koulutus

Koulutuspäivä ei alkanut kovin vahvasti, sillä druidit eksyivät jonnekin koulumme syövereihin. Lopulta he kuitenkin löysivät paikalle ja pääsimme vauhtiin. Alkuun he kertoivat mitä firmassaan tekevät, miten he käyttävät ketterää työmenetelmää projekteissa ja miten he panostavat kovasti työympäristöön ja sen mukavuuteen.

Krisse aloitti koulutuksen selittämällä mitä ketterä kehitys on ja miten se toimii. Ronin osuus oli näyttää, miten Drupal-sivusto pystytetään ja kuinka Drushia käytetään – valitettavasti emme kuitenkaan päässeet Drushin kanssa leikkimään, koska koululla joku blokkasi sen käytön. Tero puolestaan puhui teemoittamisesta, eli miten luodaan oma teema ja leiskataan sivua.

Koulutuksen aikana Drupal alkoi kiinnostaa minua yhä enemmän ja halusin oppia lisää, joten päätin hakea Druidilta työharjoittelupaikkaa koulutuksen loputtua. Pääsin työhaastatteluun, ja Druidin toimistolla vieraillessani puheet työympäristöön panostamisesta konkretisoituivat. Toimistolla tuli fiilis, että tänne on pakko päästä töihin. Vuoden 2015 lopulla viimein pääsinkin aloittamaan työharjoittelun Druidilla.

Työharjoittelusta työsuhteeseen

Ensimmäisenä päivänä tutustuin taloon ja ihmisiin sekä pystytin työpisteeni. Tehtäväkseni sain druid.fi-sivuston uusimisen upouudella Drupal 8 -järjestelmällä. Se oli haaste, sillä olin siihen mennessä opetellut vain Drupal 7:ää. Uusittu sivusto saatiin kuitenkin julkaisukuntoon ja se näki päivänvalon eräänä helmikuisena perjantai-iltapäivä. Sen jälkeen oli hyvä mieli lähteä viettämään viikonloppua! 

Ajan myötä Drupal 8:sta tuli mukava käyttää ja opin tekemään sillä itsenäisesti töitä. Ilokseni druidit olivat tyytyväisiä tekemääni työhön ja päättivät palkata minut töihin loppuvuodeksi.

Elokuun lopulla alkoi DrupalCon Dublin -matkan järjestely ja sain tietää pääseväni mukaan reissuun. Olin tosi innoissani: uusi matkakohde, ensimmäinen DrupalCon, ja pääsin matkailemaan ensimmäistä kertaa yksin! Matkasta tulikin tähänastisen työsuhteeni kohokohta. Viikon aikana tuli käytyä monella kiinnostavalla luennolla, perinteisessä pubissa ja tietenkin pakollisella vierailulla Guinness-tehtaalla. 

Ympyrä sulkeutuu

Tämän vuoden lopulla Druid järjestää taas Drupal-koulutuksen Helsinki Business Collegen opiskelijoille, ja tällä kertaa olen mukana yhtenä opettajista. Olen oppinut kuluneen vuoden aikana Druidilla valtavasti, ja on mahtavaa päästä nyt jakamaan osaamistani entiseen opinahjooni! 

Mitä tästä opimme? Kannattaa kysyä meitä kouluttamaan, sillä teemme sitä mielellämme aina kun asiakasprojekteiltamme ehdimme. Kannattaa myös hakea meille työharjoitteluun, jos motivaatiosi on kova, Drupalin perusteet on hallussa ja haluat päästä sen kanssa tositoimiin.