GDPR – tieto suojatuksi

No niin, pitkästä aikaa. Aika murtaa myyttejä, parantaa moraalia, ja avata uusia mahdollisuuksia.

Ensi vuonna loppuu siirtymäaika EU tietosuoja-asetuksen (EU) 2016/679 osalta. Asetushan on jo voimassa, mutta 25.5.2018 loppuu siirtymäaika, ja siitä alkaen henkilötietojen käsittelyn on oltava asetuksen mukaista, tai muuten…

Mielenkiintoista kyllä liikkeellä on taas monenlaista vipellystä tämän tiimoilta. Tuntuu löytyvän kosolti ääripään reaktioita: Joko taivas putoaa niskaan ja mitään ei saa tehdä, tai sitten ei koske meitä, pää puskaan ja eteenpäin kuin ennenkin.

 

Screenshot 2017-06-28 10.01.52

Olen itsekin viettänyt aikaa kosolti asian parissa ja ajattelin kirjoitella vähän mietintöjä. Oma lähestymistapa on ehkä vähän erilainen: Mitä kannattaa jatkossa huomioida että ollaan sovellus- ja ratkaisukehityksessä yhteensopivia asetuksen hengen kanssa, ja mitä mahdollisuuksia se jatkossa luo.

20 miljoonaa tai 4% vuotuisesta maailmanlaajuisesta liikevaihdosta

Merkittävimpiä uutisaiheita asetuksen suhteen on ensimmäistä kertaa tiukennettu sakkoja, toisin sanoen määritetty uhkasakko joka voidaan asettaa jos tietosuoja-asetuksen vaatimuksia ei ole toteutettu. Sakon yläraja on törkeimmissä rikkomuksissa 20 miljoonaa euroa, tai 4% vuotuisesta maailmanlaajuisesta liikevaihdosta, kumpi onkaan suurempi. Aika monellakin isommalla firmalla, jopa Suomessa tuo 4% voi helposti olla 20 miljoonaa suurempi, moninkertaisestikin, ja vähän pienemmille pajoille 20 miljoonan sakko voi olla aika kova pala.

Tätä vipua on helppo viuhutella pelotteena, ja sillä on puolensakin. Sekä tietosuoja että tietoturva vaativat investointeja järjestelmiin, infraan, palveluihin, ja edellyttävät tarkempaa seurantaa sille missä tieto liikkuu ja miten sitä käsitellään – todennäköisesti huomiointia prosessi ja liiketoiminta-tasolla. Monet sovelluskehitysprojektit ovat sellaisia, että siellä keskitytään vain toimintoihin ja ominaisuuksiin, ja tietoturva tulee siellä jossain perässä, jos tulee. Usein tietoturvaan investoidaan vasta kun jotain tapahtuu – ja se on huonoin mahdollisin hetki investoida. Tämän asetuksen myötä alkaa löytymään rahaa parantaa tietoturvaa ja tietosuojaa, ja se taas laskee riskejä mahdollisen tietomurron tai tietosuojaloukkauksen tapahtuessa.

Niille jotka ajattelivat painaa päänsä puskaan ja jatkaa kuten ennenkin, lienee hyvä huomioida että tuo uhkasakko siis pamahtaa kohdalle esim. sillä hetkellä kun järjestelmiin tapahtuu tietomurto, ja sana siitä kiirii tietosuojaviranomaisille. Sakko voi myös uhata jos tulee jostain syystä muu epäilys siitä että tietoja ei käsitellä asetuksen mukaisesti. Ensimmäinen asia mitä siellä kysytään on miten sensitiivistä ja laajaa tietoa murto koskee, miten laajaa joukkoa, ja mitä toimenpiteitä on tehty tiedon suojaamiseksi suhteessa riskeihin. Sakko tirahtaa rankimman kautta, jos vastaus tähän on: HÄ?

No, niille jotka ajattelivat kieltää kaiken ja vetää paniikkimoodin päälle, sen verran lohtua että sakkoa säädetään sen mukaan mitä toimenpiteitä on tehty tiedon dokumentoimiseksi ja suojaamiseksi, ja miten nopeasti on pystytty reagoimaan, ja miten yhteistyöhaluisia on oltu. Ensi vuonna näemme miten tuota käytännössä tulkitaan viranomaisten toimesta – olisin kuitenkin aika isosti yllättynyt ellei jo ensi vuoden puolella tulisi ainakin muutama tapaus tarkasteluun.

On myös äärimmäisen todennäköistä, että asetuksen siirtymä-ajan päättyessä tulee jonkunmoinen purske ihmisiä harjoittamaan oikeuksiaan, ainakin mielenkiintoisimmissa rekistereissä. Miten pystyt tällä hetkellä vastaamaan esim. pyyntöön tulla unohdetuksi? Tai pyyntöön saada kaikki kerätyt tiedot itsestään konekielisessä siirtomuodossa?

Riskeistä puheenollen

Uusi tietosuoja-asetus puhuu useassakin kohtaa riskeistä, ja riskilähtöisestä lähestymistavasta. Tämä on hyvä pitää mielessä kun tulkitsee asetuksen vaatimuksia suhteessa omiin rekistereihinsä tai järjestelmiin. Ideana ei ole, että kaikki henkilöön liittyvä tieto pitäisi nyt varastoida raskaimmin mahdollisin kontrollein suojattuna holvien uumeniin, tai olla käyttämättä sitä tai tekemättä mitään. Ideana on analysoida millaisen riskin ko henkilötieto muodostaa, mitä uhkia sen varastointiin ja käyttöön voi liittyä, ja valita sopivat kontrollit jotta riski vähenee. Toisin sanoen, on tunnistettavissa selkeästi eri sensitiivisyydellä olevia tietoja joita tulee suojata eri tasoilla.

Tässä kohtaa kukaan ei pysty varmasti sanomaan missä rajat menevät – valitettavasti tietosuoja-asetus ei tätä kerro, ja opimme asiaa vasta tulkintojen kautta. Mutta tietosuoja-asetus määrittelee erikseen sensitiivistä tietoa, esim. alaikäisten tiedot, tiedot joissa käsitellään esim. terveystietoja, sukupuolista suuntautumista, rotua, uskontoa, rikoshistoriaa, jne ovat selkeästi sensitiivisiä. Sen ohella voi tietysti käyttää tervettä järkeä: Jos Harri H Hakkeri murtautuu juuri tähän kantaan, lataa sieltä dumpin tietoa, ja se julkaistaan Internetissä tai iltapäivälehdissä, miten suuri vahinko siitä voi tulla. Suhteessa siihen kannattaa soveltaa kontrolleja.

Toteennäyttäminen

Aika monessa paikkaa asetuksessa puhutaan toteennäyttämisestä. Se tarkoittaa, että tiedon suojaaminen ei riitä, vaan asetuksen toteuttaminen tulee olla näytettävissä toteen, pääpiirteittäin dokumentaation avulla.

Mitä sieltä dokumentaatiosta pitäisi löytyä? No, osapuilleen kaikki. Päätasolla olisi syytä olla jossain muodossa kuvaus järjestelmistä ja rekistereistä, ja siitä mitä tietoa ne sisältävät. Kun on kuvattu mitä tietoa varastoidaan, tietokannoissa ja tiedostoissa (tähän olisi hyvä liittää vähän luokittelua), on tarpeen myös kuvata tietovirrat, eli tässä tapauksessa mihin tieto liikkuu järjestelmissä. Asetuksen kannalta kiinnostaa eritoten, missä ylitetään maiden rajoja, ja kenen käsittelijöiden kautta tieto liikkuu. Tässä käsittelijöitä ovat esim. pilvipalvelualustat. Kokemus on osoittanut, että voi olla tarpeen/hyödyllistä viedä näitä kuvauksia teknisemmällekin tasolle, jotta saadaan näkyviin esim. protokollat ja muut data-in-motion suojaustarpeet.

Sopimukset on toinen alue mihin tulee kiinnittää huomiota. Asetuksessa tullaan hakemaan vastuullisuus-alueita, ja enää ei myöskään riitä että pestään kädet siinä kohtaa kun maa/organisaatioraja ylittyy. Tiedon alunperäinen kerääjä ja varastoija tulee olemaan ensisijainen vastuullinen koko ketjusta. Esim. pilvipalvelualustoilla tulee olla sopimukset kunnossa. Tähän ovatkin jo suurimmat pilvipalvelualustat reagoineet, ja esim. AWS pilvessä tulee olemaan sopimuspäivityksiä vuoden sisään, ja lisäapua vaatimusten täyttämiseen.

Prosessit tulee luultavasti tuoda tarkempaan syyniin. Tietosuoja-asetuksen yksi tärkeä nurkka on oikeutus henkilötiedon käsittelyyn. Aiemmin oikeutusta ei ole niinkään mietitty, monessa paikkaa. On vain kerätty kaikki mitä saadaan, ja käytetty sitä vapaasti miten voidaan. Nyt jos käsittely ja keruu tulee valokeilaan, tai peräti auditin alaiseksi, pitäisi pystyä näyttämään toteen myös minimaalinen pääsy ja minimaalinen keruu, eli kerätään vain mitä tarvitaan, keräämiselle on hyväksyttävä oikeutus (sopimukset, luvat, lain vaatimukset, jne), ja tietoon pääsevät käsiksi vain minimissään ne joille se on tarpeen, ja oikeutettua. Tämä karsii pois kaikki villit uusiokäytöt joille ei ole oikeutusta, tai tuotantodatan dumppaamisen muistitikuille tai tiedostoihin esim. testausta varten. Ja edellyttää prosessien kehittämistä ja dokumentoimista. Ne jotka ovat tätä jo tehneet ovat tietysti jo hyvällä alulla.

Edelleen yksi dokumentoinnin alue on kyetä esittämään, mitä tietoturvakontrolleja on toteutettu, ja miten toteutuu asetuksen edellyttämä data protection-by-default vaade. Tämä lienee alue joka isoimmin hakee muotoaan. Toisaalta tämä on ollut alue jossa perinteisesti on jo tietoturvanäkökulmasta aina dokumentoitu jotain, eli jonkunmoista pohjaa löytyy jo.

Asetuksen henki

Tulkittaessa lakipykäliä ja vaatimuksia, ja väistellessä uhkasakkoja, usein helposti unohtuu, miksi tätä asetusta on alettu puuhailemaan. Sen taustalta löytyy hyvin kauniita ajatuksia, ja potentiaalista liiketoiminnallista hyötyä myös, ei pelkkiä kulueriä. Seuraamalla asetuksen henkeä mennään jo aika pitkälti oikeaan suuntaan.

Mikä sitten on asetuksen henki? Se tiivistyy pariin ajatukseen:

  • Lisää oikeuksia rekisteröidyille, henkilöille joista tietoa kerätään
  • Läpinäkyvä ja oikeudenmukainen tietojen käsittely
  • Lisää valtaa siihen miten ja mihin omia tietoja saa käsitellä
  • Sisäänrakennettu ja oletusarvoinen tietosuoja, aina järjestelmiä rakentaessa ja hankittaessa

Kun nämä ynnää yhteen, hyväähän siitä tulee. Läpinäkyvyys toteutuu kun rekisteröity voi nähdä tarkasti mitä tietoja hänestä kerätään, ja mihin niitä käytetään, ja miksi. Kun rekisteröity voi lisäksi helposti tarkistaa käyttötarkoitukset, ja hallita niitä itse, päättäen esim. mitä tietoja voidaan käyttää profiloinnissa ja analyyseissä, voimaantumisen tunne vain kasvaa. Lopulta kun tiedot voi poistaa rekistereistä kun niitä ei enää tarvita, ja siirtää ne helposti toiselle prosessoijalle tai vaikka itselleen, luulisi henkilökohtaisen tiedon alkavan jo kiinnostaa.

Tässä piilee business mahdollisuuksia, luottamuksen lisääntyessä ja itsepalvelun helpottaessa luvitusta, voidaan saada potentiaalisesti paljonkin enemmän tietoa ja lupia kuin aikaisemmin, läpinäkyvästi. Kun tietosuoja ja tietoturva järjestelmissä kehittyy, niihin liittyvät liiketoiminnallisetkin riskit pienenevät. Viime aikoina on ollut aika massiivisia tietomurtoja, joissa kantoihin varastoituja tietoja on vuotanut maailmalle, esim. salaamattomia luottokorttitietoja, salasanoja, ostoshistoriaa, jne. Tällaiseen tilanteeseen on aina ankeaa herätä, etenkin jos asiaa penkoessa löytyy rumaa aluetta jossa ei ole tehty ollenkaan tarpeeksi eikä oikeastaan edes uskallettu tarkastella.

Yksi kulma miettiä asiaa on että useimmilla firmoilla pitäisi nyt olla ainakin 20 miljoonaa euroa käytettävissään pistää vähän asioita kuntoon. Sillä saa jo ostettua viipaleen jos toisenkin tietoturvaa.

Sähköinen identiteetti

Asetuksessa hiipii sisään yksi piilo-feature joka on sekä uhka että mahdollisuus. Jotta henkilö voi harjoittaa oikeuksiaan, ja esim. vaatia kaikkien tietojensa poistamista järjestelmästä asiakassuhteen päätyttyä, hänet pitää luonnollisesti tunnistaa, ja pystyä liittämään kaikkiin tietoihin.

Miten tunnistetaan riittävän vahvasti, ettei tässä kohtaa tapahdu väärinkäytöksiä? Jos käytössä on jo sähköinen tunnistaminen kaikille rekisteröidyille, tässä ollaan pitkällä. Jos ei ole, nyt taitaa olla aika kehittää. Mitenkäs se kantojen tietosisältö? Mitä varmasti identifioivaa tietoa sieltä löytyy? Voiko email osoitteen perusteella varmasti tunnistaa että pyyntö tuli samalta Matti Möttöseltä joka löytyy rekisteristä? Entä jos se on vanhentunut? Voiko puhelinnumerolla tunnistaa? Voiko tunnistautua tulemalla paikan päälle ja näyttämällä passinsa?

Vastaus kaikkeen tähän: Tunnistamista ja sähköistä identiteettiä pitää luultavasti kehittää. Luultavasti pitää kuvata ja kenties parantaa henkilö/asiakastiedon laatua, sitä miten taulut ja järjestelmät liittyvät toisiinsa. Luultavasti tämän tekeminen on epämiellyttävää jumppaa, johon kuluu rahaa.

Luultavasti kun se on tehty, kyvykkyys tarjota asiakkaalle tehokkaita itsepalveluita on huimasti kasvanut, ja samoin on datan laatu.

Oma odotus on myös, että kun pöly vähän laskeutuu, sekä tietoturvan että tietosuojan oletusarvoinen taso sovelluskehityksessä on taas pykälän korkeammalla, ja kun se on jokapäiväistä, se ei merkittävästi lisää edes tekemisen kustannuksia. Nostetaan vain taso korkeammalle kuin ennen, ajan vaatimusten mukaisesti.

Perästä kuuluu?

Tietosuoja-asetus on massiivinen mittaluokaltaan, se tuo muutoksia aika moneenkin ulottuvuuteen. Tarkoitukseni on käsitellä sitä palasina, sovelluskehityksen vinkkelistä tässä blogissa. Aika näyttää löytyykö siihen aikaa, mutta toivon että palataan asiaan täsmäiskujen merkeissä aiheen tiimoilta.

Tässä vähän linkkivinkkejä sitä odotellessa:

http://eur-lex.europa.eu/legal-content/FI/TXT/HTML/?uri=OJ:L:2016:119:FULL&from=FI

http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

http://www.tietosuoja.fi/material/attachments/tietosuojavaltuutettu/tietosuojavaltuutetuntoimisto/oppaat/1Em8rT7IF/Miten_valmistautua_EUn_tietosuoja-asetukseen.pdf

 

AWS Certified Solutions Architect – Associate

Kävin viime viikolla suorittamassa tuon otsikossa mainitun sertifikaatin – vaikeampi kuin odotin mutta läpi meni. Ajattelin kirjailla tähän vähän fiiliksiä, ajatelmia ja vinkkejäkin tuohon liittyen.

Nykyisessä pajassani (Solita) ollaan aika pilvinatiiveja. Meillä on omaa pilveä, ja aina kun projektit sen sallivat, pyritään tarjoamaan alustaksi jotain pilven nurkkaa. Syyt tähän ovat ilmeisiä. Pilvi tarjoaa parhaimman DevOps kokemuksen (tai ainakin mahdollistaa sen), koska on mahdollista välttää siiloutumista, ja pääsy ja työvälineet ja hallinta ovat ensiluokkaisia. Pilvi tarjoaa loistavan alustan kokeilulle edukkaasti, investoimatta raskaaseen rautaan, ja sieltä saa resursseja nopeasti, nappia painamalla. Pilven skaalautuvuus on myös (hyvin tehdyille sovelluksille) lähes rajaton, ja vikasietoisuutta saa globaaleilla pilvillä ruuvattua todella erinomaiseksi. Juuri mitään näistä hyödyistä ei saa paikallisesta konesalista, ja siihen on monissa paikoin suorastaan totuttu.

Itse olen puljaillut AWS EC2 koneiden kanssa jo pitkiä aikoja, mutta oikeastaan vasta nykyisissä hommissa havahduin siihen, mitä muuta AWS tarjoaa. Kiitokset siitä Data Science-puolen väelle. Yksi ensimmäisiä hommiani Solitalla oli tukea Data Science projektia teknisessä mielessä, jossa haluttiin vertailla kalliin kaupallisen datan rouskutusvälineen kyvykkyyksiä open source pinoon. (Kallis kaupallinen veti kokonaiskustannuksiltaan liput kotiin mennen tullen tässä skenaariossa). Myös firman HipChat kanavalla huhuillaan aika ajoin kiinnostavia juttuja mm. Lambdoista ja Serverless-malleista, tai S3-website hostauksesta. Vanhana hardcore koodinvääntäjänä jolle aiemmin oli kunnia-asia tehdä kaikki työkalut itse, olen sittemmin kokenut tietynlaista tuottavaa laiskuutta, ja näin tällaiset ovat nykyään kiinnostavia huhuiluja, kun pyritään tekemään entistä enemmän entistä fiksummin.

Mitäs niitä serttejä löytyy?

No niin, joka tapauksessa, AWS pilvestä löytyy sertifiointeja joka lähtöön. Kovan ytimen muodostaa viisi sertifikaattia, joista kolme on perustasoa, ja kaksi on professional-tasoa. Jenkkien palkkavertailuissa jo perustason arkkitehtisertifikaatti oli arvostetuin ja paraspalkkaisin mitä sertifiointeihin tulee. Pro-tason arkkitehtisertifikaatti on jo käytännössä hyvän työpaikan tae, etenkin jos sen mukana tulee kykyä kommunikoida ja oikeasti ratkoa ongelmia. Näiden viiden päälle löytyy sitten erikoistumissertifikaatteja, mm. tietoturvasta, ja verkoista.

Sertifikaatit ovat vain monivalintakysymyksiä, ja niitä usein kritisoidaan. Ne eivät ole hyvä osaamisen ja soveltamisen mittari. Mutta samoin kuin aikanaan Java-sertifikaateissa, itse puolustan niitä silti. Koska jos on henkilö, joka on suorittanut tietyn sertifikaatin, se kertoo minulle, että hän on ainakin jossain vaiheessa hallinnut kokonaiskuvan teknologia-alustasta, yksityiskohtia myöden. Henkilö jolla ei sertifikaattia ole, voi osata jonkun nurkan erinomaisesti, toisen surkeasti, ja kolmatta ei ollenkaan. Hänestä en tiedä siis mitään.

Jos työhaastattelussa haastateltavalla on esittää sertifikaatti, se ei kerro että hän on loistava ohjelmoija, mutta antaa silti tietyn baseline-tason laadulle. Henkilö jolla ei sertifikaattia ole, vaatii huomattavasti pidempää tenttausta jos haluaa päästä osaamisesta selville. Projekteissa olen havainnut, että sertifioitumattomat henkilöt voivat olla suorastaan hasardeja: Tehdä enemmän vahinkoa kuin hyvää. Tämä johtuu siitä, että työkalupakki on, metaforaa käyttääkseni, vajavainen. Siellä voi olla yksi upea, kiiltävä vasara, mutta ei mitään muuta. Palkkaan mielummin työmaalle tyypin jolla on kulunut pakki jonka kaikkia perustyökaluja on käytetty tasapuolisesti. Häneltä löytyy hihasta vaihtoehtoja ja joustavuutta. Se kiiltävän vasaran kaveri etsii vain kaikkialta nauloja.

No liittyykö sertifikaatti sitten juuri tähän? Ei välttämättä, sama oire voi olla sertifioituneillakin. Mutta käytännnössä olen suuri fani sille että jos haluaa syvälle tekkiin, aloitetaan sertifikaatista, ja siitä alkaa opiskelu. Vähän kuin taistelulajeissa, musta vyö aloittaa varsinaisen oppimispolun – ei päätä sitä.

Vinkkejä

Vinkkejä opiskeluun? AWS sertifikaatit ovat huomattavasti vaikeampia kuin esim. SUN/Oracle Java-sertifikaatit, vaikka puitteet ovat suunnilleen samat. Perustason sertifikaateissa on yleensä n. 60 kysymystä, ja muutama tunti aikaa. Läpäisyyn piisaa 65-70% oikein. Mutta AWS on yhä vain laajempi kokonaisuus, palveluiden määrä lisääntyy koko ajan, tätäkin kirjoittaessa. Ja sertifiointikysymykset ovat todella yksityiskohtaisia, sieltä voi tulla esim. kysymyksiä koskien kapasiteettia, kaistaa, jne. Osa on onneksi ihan terveen järjen kysymyksiä, niistä selviää jos on oikeasti tehnyt jotain AWS konsolissa.

Mutta tässä pari vinkkiä:

  • Kaikkein tärkeintä on mock exam/testi-testit, että totut kysymyksien tyyppeihin, tapaan, ajoitukseen. Niitä löytyy jonkun verran ilmaisia, mutta parhaat maksavat jonkun verran. Amazonin kautta saa ’virallisen’ harjoitustestin, mutta itse löysin loistavia harjoitustehtäviä myös android-sovelluksista, joita voi mukavasti naputella tabletilla läpi vaikka työmatkalla
  • Valmistautumiseen tärkeintä on lukea AWS Whitepaperit ja FAQ lätyskät, ainakin tärkeimpien palveluiden osalta. Core palveluita ovat EC2, S3, VPC, RDS, ja DynamoDB, mutta niiden ohella yllättävät paljon tulee myös kysymyksiä myös esim. SNS, SQS ja SWF osista.
  • Ehdottomasti kannattaa investoida johonkin online-preppaukseen koskien sertifikaattia. Niitä saa alennus-aikaan muutamalla kympillä, itse käytin acloud.guru kursseja (jotka ovat itsessään tehty AWS Serverless+Lambda arkkitehtuurilla, kustannustehokkuussyistä)

Itse ajattelin jatkaa sertifioitumista tällä suunnalla, koska tämä on hyvin kiinnostava suunta, ja viimein antaa mukavan oppimishaasteen. Osa asioista on jo käytännön tasolla tuttuja, mutta osa ei. Bonuksena kakun päällä olen myös kiinnostunut AWS Alexa rajapinnoista, ja harrastepuolella olen jo niiden kanssa näperrellyt. Acloudguru sitella on tehty muuten Alexan päälle botti joka kyselee AWS sertifiointiin testikysymyksiä 😉

 

 

 

 

Docker + Java Trixx

Sattuneesta syystä Docker työkalupakin käyttö on itsellä lisääntynyt suorastaan räjähdysmäisesti viime aikoina. Se ei ole aina helppoa, mutta on kyllä palkitsevaa. Kun ensi kertaa saa hallittua kunnon könttiä palveluita parilla komentorivikomennolla, sensijaan että aiemmin seikkaili siellä ja täällä ja saastutti konettaan X kappaleella erilaisia asennuksia… Ja kun aiemmin Vagrant-koneet haukkasivat suurimman osan muistista, IntelliJ loput, ja nyt docker-kontteja voi läiskiä samaan tilaan tusinan.. Niin olen myyty.

Miten kontit juttelevat?

Pari niksiä on tullut opittua – tai oikeastaan luettua manuaalia tarkemmin. Niksi yksi oli, miten saada docker-compose alla docker-palvelut näkemään toisensa? Ratkaisu oli häkellyttävän yksinkertainen: Käytä docker-compose.yml versiota 2.0, tähän tapaan:

version: '2'
 services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

That’s all you need. Versiossa yksi piti linkitellä palveluita, mutta versiossa kaksi oletuksena saman docker-composen osat ovat samassa virtuaaliverkossa. Se tarkoittaa että ne näkevät toisensa suoraan imagen nimen mukaan, esim. jos web haluaa viitata redis-palveluun http protokollalla porttiin 6379, homma hoituu:

http://redis:6379

Tietysti voi olla että ajat palveluita välillä dockerissa, välillä ei. Itse olen havainnut käteväksi Spring Boot sovelluksissa käyttää tähän profiileja, docker-profiili ylikirjoittaa tarvittavat url viitteet tai vastaavat palvelinviitteet näillä image nameilla, ja perusprofiilissa voi olla että viitataan vielä localhostiin, testiympäristössä voidaan viitata taas ihan muualle.

Dockerin verkkoja voi hallita myös manuaalisesti, ja niistä voi koostaa haluamiaan kokoonpanoja. Kuitenkin, oletuksena siis kontit näkevät toisensa kunhan ovat samassa verkossa. Ei tarvitse avata mitään portteja, ellet sitten halua niihin ulkoapäin viitata.

Miten kontti viittaa hostiin?

Nogh, kaikkea ei saa konttiin vieläkään. Omassa OSX koneessa esim. Windows SQL server ei konttina pyöri, vaikka konttina löytyykin. Docker for Mac antaa vain herjaa, ympäristön pitäisi olla Docker for Windows. Joten joudun tekemään vähemmän ideaalin ratkaisun: Viittaamaan kontista ulospäin.

Onneksi homma hoituu, pitää vain välittää Dockerille tieto siitä ip-osoitteesta jossa host toimii. Se onnistuu esim. näin (OSX kone):

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

Dockerfilessa ei voi valitettavasti viedä ihan helpolla sisään env muuttujia, ja oletuksena kontit eivät näe ympäröivien hostien muuttujia. Vaan eipä hätää. Olen itse siirtynyt enenevässä määrin käyttämään docker-composea, ja siellä homma hoituu. Määritellään env muuttuja uudestaan docker-composessa, sitten käytetään sitä java-komentorivillä, viedään todellinen url sisään joka siis viittaa env muuttujan mukaiseen ip-osoitteeseen.

mah_service:
  environment: 
    - HOST_ADDRESS="localhost"
  build: ./mah_service
  command: echo "HOST ADDRESS FOR SQL SERVER $HOST_ADDRESS"
  command: java -Dspring.profiles.active=docker -Dspring.datasource.url="jdbc:jtds:sqlserver://${DOCKERHOST}:1433;DatabaseName=demo" -jar mah_app.jar
  ports:
    - "8080:8080"

Tah-dah, magic happens. Joka tapauksessa, tämä ei ole nätti ratkaisu, vain workaround. Windows dockesterijat eivät tarvitse tätä, vaan käyttävät mieluiten sql serveriä kontissa. Se on aina paras vaihtoehto. Lienee ihan reilua että MacOS puolellakin saa joskus kärvistellä. MS SQL Server for Linuxia ootellessa…

No, siinä tällä kertaa havainnot. Postailen tänne itselleni muistiin jatkossakin niksejä, ettei unohdu. Pian tulee Docker 1.3 ja lisää kivaa… 😉

 

Kotlin ja JavaFX – ihanaa!

Aloin kesäloman ratoksi perehtymään hiukan Kotlin ohjelmointikieleen – kirjailin siitä jo ensivaikutelmia aiempaan blogiini. Koska en näillä näkymin pääse hetikohta käyttelemään Kotlinia työprojekteissa, päätin harrastella sillä jotain muuta ominpäin.

JavaFX on entuudestaan suuri rakkaus – harmillisen vähän käytettyä tekniikkaa sekin, mutta toimivaa. Ajattelin yhdistellä näitä ja katsoa mitä siitä syntyy, voi olla että peli vielä jossain vaiheessa. Peliohjelmointi ei ole oma vahva lajini – mutta huonommankin pelin koodailusta tulee opittua paljon. 😉

No niin, joka tapauksessa, kaikki alkaa hello worldistä. Eli miltä näyttää Kotlinilla tehty pääohjelma joka käynnistää JavaFX ikkunan?

import javafx.application.Application
import javafx.scene.Scene
import javafx.scene.layout.Pane
import javafx.stage.Stage

class Test : Application() {

  override fun start(stage: Stage) {
    var pane = Pane()
    var scene = Scene(pane, 200.0, 200.0)
    stage.scene = scene
    stage.show()
  }

  companion object {
    @JvmStatic
    fun main(args: Array<String>) {
      launch(Test::class.java)
    }
  }

}

Mitä juuri tapahtui? 😉 Kotlinissa on tosiaan vähän yksinkertaistettu syntaksi Javaan verrattuna. Kuten kuvasta näkyy, muutama modifieri puuttuu, tyyppejä ei tarvitse toistaa, vaan ne päätellään fiksusti tarvittaessa. Funktiot määritetään fun avainsanalla. Ehkä kiintoisin osa tässä on Scalasta tuttu Companion Object. Static avainsanaa kun ei Kotlinissa ole, Companion Object on luokan ’automaattinen instanssi’. Tämän lisäksi tietysti ilmeistä, että Kotlinista käsin voi käyttää kaikkia Java kirjastoja, mukaanlukien Java 8 sisältämä JavaFX.

Miten tuon sitten voi kääntää, paketoida, ajaa? Mavenin voi opettaa prosessoimaan Kotlinia. Oma pom.xml sisältää seuraavia osia:

<dependencies>
  <dependency>
    <groupId>org.jetbrains.kotlin</groupId>
    <artifactId>kotlin-stdlib</artifactId>
    <version>${kotlin.version}</version>
  </dependency>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.jetbrains.kotlin</groupId>
    <artifactId>kotlin-test-junit</artifactId>
    <version>${kotlin.version}</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Ylempänä on tietysti määritetty property-muuttujat kotlin.version ja junit.version (1.0.3 ja 4.12 tällä hetkellä). Kotlin käännöksiä varten tarvitaan tietysti kotlin-stdlib riippuvuus. Ilman etukäteen kirjoitettuja yksikkötestejä ei voi ihminen elää, joten siksi junit riippuvuus. Ja lopuksi vielä kotlin-test-junit riippuvuus tuomaan vähän lisämukavuutta liitokseen. Seuraavaksi veivataan build prosessi käsittelemään kotlin-koodit src/main/kotlin, ja src/test/kotlin kansioiden alta:

<build>
  <sourceDirectory>${project.basedir}/src/main/kotlin</sourceDirectory>
  <testSourceDirectory>${project.basedir}/src/test/kotlin</testSourceDirectory>

  <plugins>
    <plugin>
    <artifactId>kotlin-maven-plugin</artifactId>
    <groupId>org.jetbrains.kotlin</groupId>
    <version>${kotlin.version}</version>
    <configuration/>
      <executions>
        <execution>
          <id>compile</id>
          <phase>compile</phase>
          <goals>
            <goal>compile</goal>
          </goals>
       </execution>
       <execution>
         <id>test-compile</id>
         <phase>test-compile</phase>
         <goals>
           <goal>test-compile</goal>
         </goals>
       </execution>
     </executions>
    </plugin>
  </plugins>
</build>

Jep, ja näin Maven kääntää Kotlin-koodit pluginin avulla bytecodeksi, tavanomaiseen paikkaan, normaaleissa Maven vaiheissa. Lopuksi säädetään vähän paketointia.

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <archive>
      <manifest>
        <mainClass>game.Pong</mainClass>
      </manifest>
    </archive>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
  </configuration>
  <executions>
    <execution>
      <id>make-assembly</id>
      <phase>package</phase>
      <goals>
        <goal>single</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Eli, tämä Maven Assembly plugin tekee lopputuotoksesta mega-jar paketin, jossa on kaikki tarvittava. Oman maun mukaan voi tehdä fiksumman käyttäen manifest riippuvuuksia, tai Java 9 moduuleita, mutta tässä kohtaa tämä on ihan bueno, ja helpottaa levitystä ja testausta.

Vein koodia vähän pidemmällekin, otin käyttöön game loopin, animaatiota, piirtoa, mutta puidaa niitä toisella kertaa. Pistin koodit Git repositoryyn, josta löytyy välivaiheita. Nykyinen koodi ei tee vielä paljoa, mutta on hauska tutkimuspöytä sille mitä JavaFX on nykymuodossaan, ja miten Kotlin helpottaa koodin kirjoittelua.

Linkki Gittiin: https://github.com/crystoll/kotlinfx

 

 

Kuolema nullpointerexceptioneille: Kotlin ftw!

Lomaillessa ja sairastaessa on hyvin aikaa leikkiä jollain jolle ei ole ollut kysyntää ns oikeissa, hiellä ja tuskalla väännetyissä Wakavissa Projekteissa. Tällä kertaa tutkaan osui Kotlin, johon on ollut tarkoitus perehtyä tilaisuuden tullen.

Kotlin on tuorein lisäys JVM-perheen kieliin; Eli kuten Scala, Clojure, ja Groovy, se on ihan oma erillinen kielensä, syntaksinsa, ja filosofiansa, mutta kun se menee kääntäjän läpi, putkesta ulos tulee Java-virtuaalikoneen bytecodea – vaatii tosin minimitasoksi Java 6 myllyn.

Ajonaikaiset virheet ohjelmissa ovat nykypäivän ohjelmistokehityksessä niitä kalleimpia virheitä – koska ne löytyvät vain kattavalla testauksella, voivat vaatia hyvinkin eksoottisia tiloja ja kombinaatioita ilmentyäkseen, ja mitä myöhemmin ne löytyvät, sitä enemmän ne maksavat. Esim. käyttöönottovaiheen jälkeen löytyvä bugi pitää ensin havaita, sitten raportoida, sitten toistaa, sitten ymmärtää, sitten korjata, sitten testata korjaus, ja testata ettei korjaus rikkonut mitään muualla, jne. Tästä kertyy ihan kohtuullisesti hintaa pienille asioille. Java-kielessä on alusta alkaen ilmennyt kahta eri virhettä yli kaiken muun: ClassCastException, sekä NullPointerException. Java 5 onnistui aikanaan hävittämään edellisen lähes sukupuuttoon Generics tyypitettyjen kokoelmien myötä. Mutta NullPointer on edelleen valitettavan yleinen virhe. Ja kun se paukahtaa, se usein valuu pinossa ylöspäin, ja voi ilmentyä hyvin mielikuvituksellisin tavoin – tai voi aiheuttaa seurauksia jotka näkyvät jossain aivan muualla myöhemmin. Eli pirullisia virheitä.

Nullpointereita on jahdattu eri tavoin. Olen itse opettanut ja kirjoitellut siitä miten Java-kielellä koodatessa voi tiedostaa tämän, ja koodata fiksusti. NullPointer paholainen iskee tyypillisemmin kun metodi palauttaa kokoelman sijasta null-arvon. Eli parempi filosofia on palauttaa aina ei-null arvo, esim. tyhjä. Jos jossain oikeasti tulee vastaan niin harvinainen tapaus, että null ja tyhjä ovat eri asia ja molemmat tarpeen palauttaa, niin se poikkeus on hyvä dokumentoida ja nimetä selkeästi, jotta kutsuja osaa käsitellä arvot oikein. Scala ja Groovy hoitavat nulleja omilla tavoillaan, mutta molemmat kielet edelleen sallivat null arvoja. Java 8 esitteli uuden Optional-tyypin, josta olen myös kirjaillut, ja se tuo vähän helpotusta ongelmiin oikein käytettynä – mutta ei sekään ongelmaa poista, ja mikään ei sitä pakota käyttämään.

Joten – long story short – Kotlin kielen mainostetuin uutuuspiirre on juurikin kuolema nullpointtereille, taas uudella ja tuoreella näkökulmalla. Mutta ei mennä asioiden edelle. Kotlin on syntaksiltaan ja toiminnaltaan eniten lähellä Scala-kieltä, ja Java-koodaajillekin tuttu.

fun main(args: Array<String>) {
  print("Kuolema NULLPOINTEREILLE!")
}

Jeah, puolipisteet valinnaisia, pääohjelman voi tehdä ilman luokkaa. Itse asiassa on myös mahdollista tehdä Kotlin scriptitiedosto, joka sisältää vain pääohjelman koodin:

print("Kuolema NULLPOINTEREILLE scriptissä!")

Kotlin käännetään kotlinc-kääntäjällä, joka voi suoraan paketoida java-kirjastot mukaan. Lopputuotos voi olla .class tiedostoja, tai suoraan ajettava .jar. Kotlin voi vapaasti importoida ja kutsua Java-kirjastoja, sekä JVM sisältä että mitä hyvänsä lisäkirjastoa mitä on tehty sitten vuoden 1995.

kotlinc app.kt -include-runtime -d app.jar

Miten Kotlin sitten auttaa nullpointerien kanssa? Kotlin ei salli normaalien tyyppien asettamista null-arvoon: kääntäjä estää sen. Esim. tyyppi String vaatii aina ei-null arvon. Jos haluat asettaa null-arvon, tyypin perään tulee kysymysmerkki merkiksi, esim. String?

var name:String?
var email:String
name = null
email = null // This line does not compile at all!
print("HELLO " + name + "!")
print("Your email is " + email)

Ylläolevassa koodiesimerkissä näet molemmat käytössä. Jos halutaan siis varata oikeus käyttää null-arvoja, se pitää näkyä jo alunperin tyyppimäärityksessä. On siis varsin mahdollista käyttää null-arvoja – mutta useimmiten ne ovat vain puhdasta laiskuutta. Useimmiten kun on mielijohde palauttaa null-arvo, onkin fiksumpaa palauttaa ns tyhjä arvo, esim. tyhjä String, tyhjä List, jne, tai heittää poikkeus. Niihin harvoihin tapauksiin kun null arvo on oikeasti kätevä, se on helppo ottaa käyttöön.

Mitä muuta jännää on Kotlinissa, verrattuna Java/Scala kieliin esim? Aika paljolti paletti molempien parhaita puolia. Primitiivityypit on poistettu: Kaikki ovat oliotyyppejä. Ei ns checked exceptions poikkeuksia, kaikki ovat nykymuodin mukaan runtime exception tyyppiä, eli käsitellään kun halutaan, ei ole pakko. Nykymuodin mukaan myös kielessä on paljon älykkyyttä ja päättelyä: esim. muuttuja/vakiotyyppiä ei tarvitse määrittää jos kääntäjä sen jo osaa päätellä arvon perusteella. Erikseen löytyy val ja var avainsanat immutable/mutable käyttöä varten. Tottakai lambda expressionit pelaavat mainiosti.

Kielestä on sitten vastaavasti jätetty pois monia piirteitä, joilla Java/Scala koodaajat ampuvat itseään lahjakkaasti jalkaan, esim. static avainsanat ja osat, implicit conversions, ja rohkaisu on ratkoa ongelmia siten että koodi pysyy luettavana ja selkeänä. Toisin kuin Scala, kieli on myös rakennettu modernin Java 8 pohjalle, eli on lähempänä nykysyntaksia mm. Lambdojen ja Stream käsittelyn osalta. Itse pidän myös esim. funktioparametrien oletusarvoista, ja mahdollisuudesta asettaa parametreille arvot nimen perusteella. Tämä vähentää tarpeetonta polymorfismia – toki kohtuudella käytettynä tämäkin, muuten polymorfisuus korvautuu modaalisuudella joka taas ei ole hyvä vaihtokauppa.

2016-06-10 13.13.59

Firman Flamingo hyväksyy Kotlinin

Kotlin on tosiaan melko tuore tulokas kentällä: JetBrains niminen paja lanseerasi sen vuonna 2011, vuonna 2012 se vapautettiin Apache lisenssillä open sourceksi, ja nyt vuonna 2016 siitä on julkaistu vakaaksi laskettava versio 1.0, vuoden alusta. Sen osuus on sen verran marginaalinen ettei vielä näy esim. TIOBE indeksissä, mutta se ei toki tarkoita etteikö sitä jo kentällä käytettäisi.

Kannattaisiko siis käyttää Kotlinia seuraavaan projektiin? Omalta puoleltani annan vahvan peukutuksen. Clojure uskovaiset tuskin kokevat halua kääntyä tänne, se on edelleen oma maailmansa. Java uskovaisten kannattaisi tehdä seuraava projekti ihan millä hyvänsä modernimmalla kielellä, Java on nykymuodossaan aika rasitettu ja päällelaastaroitu sekamelska, ja Scala, Clojure, ja Kotlin ovat kaikki huimia parannuksia siihen. Scala kielen pieni haitta on se että se oli kentällä aikaisin, ja nyt sen linjaus Java 8 mukaiseksi on vähän isompi operaatio. Scalassa on myös turhankin voimallisia tapoja ampua itseään jalkaan, jotka ovat Kotlinista tahallisesti poistettuja.

Kuten Scala, myös Kotlin on hyvä alusta jossa voit toteuttaa vapaasti haluamaasi yhdistelmää funktionaalista tai olio-ohjelmointityyliä. Voit esim. aloittaa iisisti perinteisemmällä Java oliokoodilla, ja hivuttaa itseäsi kohti korkeamman tason funktioita ja immutable, arvoja. Kotlin käyttöönotto on helppoa, ja sen voi perinteiseen tapaan aloittaa vaikkapa testipuolella. Kotlin toimii myös mukavasti esim. Spring Boot+REST alustana, ja sen saumaton yhteensopivuus olemassaolevien Java-kirjastojen kanssa tuo ratkaisua mm. tietokantojen kanssa pelaamiseen.

Itse ainakin käyttäisin. Rakastuin aikanaan Scalaan, ja Kotlin on Scalalle vähän samaa kuin Scala oli Javalle. Scala on edelleen paljonkin voimallisempi työkalu, ja kypsempi myös, mutta molemmat piirteet ovat kaksiteräisiä miekkoja. Ja Java-kieltä taas kukaan ei varmaan ihan ehdottoman innoissaan halua koodata. Sen paras argumentti lienee Cobol-mainen 20 vuoden tuoma maturiteetti, se on hyvä sveitsin armeijan linkkuveitsi siellä työkalupakin pohjalla. Ehkä sen olisi kielenä jo aika kuolla pois. Mutta toki maailmalta löytyy 10 miljoonaa enemmän tai vähemmän aktiivista koodaajaa jotka sitä ymmärtävät. Digitalisoinnin tarpeiden taas laajentuessa eksponentiaalisesti sekin on hyve.

 

Tuolta lisää:

https://kotlinlang.org/

 

Java 9 ja CORBA

Heh, niinpä. Olen kirjaillut aiemmin useammankin kerran tulevan Java 9:n ihmetyksen aiheista. Silmiin osui hauska artikkeli siitä miten viimeinkin CORBA, Common Object Request Broker, tuo kaikkien väylien ja hajautuksen edelläkävijä ja kaikkien sitä käyttäneiden inhokki, ei enää tule vakiovarusteena perus-Javassa.

Java 9 suuri uudistushan on modulaarisuus, ja sen tärkeimpänä osana ja ajurina Javan n. 20-megainen runtime modularisoidaan, siten että sieltä löytyy tiukka ydin-kernel, ja lukuisia moduuleita joita voi halunsa mukaan ottaa mukaan tai jättää ottamatta. Pitkän tähtäimen strategia on varmasti paluu mobiili ja IoT ympäristöihin uusin voimin.

Eli, oletuspaketti, root moduulit, ei sisällä enää tarpeetonta kuraa, ja osa tarpeellisistakin lähtee erilleen. Jos kaipaat CORBAA, saat sen takaisin kytkimellä:

-addmods java.corba

Hyvä huomata että vastaavia muita moduuleita ovat mm.:

java.activation
java.annotations.common
java.corba
java.transaction
java.xml.bind
java.xml.ws

Näyttäisi siis siltä että viimein Java menee tosissaan tiukalle dieetille. Java 9:stä kuulemme varmaan lisää tämän vuoden JavaOne seminaarissa San Franciscossa – mutta mielenkiintoa näyttäisi olevan. Varmaa on, että jatkossa on syytä opetella käyttämään moduulijärjestelmää ja sen kytkimiä – muuten ei vanhat Java-koodit enää edes käänny.

Toinen tutkaimiin osunut juttu on moneltakin taholta julistettu Java EE 8 kuolema. Oraclen panostus ja mielenkiinto sen suhteen näyttää olevan lopahtamassa. Mielenkiinnolla seuraan mitä tämä tarkoittaa, ja mitä tuo tullessaan. Tutkaimet herkkinä. Tämäkin selvinnee syksymmällä.

 

http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html