GDPR – Tietosuoja ja sovelluskehitys osa 1

Pyydän jo etukäteen anteeksi, tämä jos mikään on TL;DR settiä. Asiaa on vain aika vaikeaa kuvata ytimekkäästi, tahoja on monia. Jos artikkelin pituus haittaa lukemista, asennoidu lukemaan vaikka yksi kappale päivässä. Ota mukaan yhtälöön kupillinen mielijuomaasi, ja hyvää musiikkia taustalle, niin kyllä se siitä. Lupaan että substanssi on rautaa, kuittaa kommentteihin jos olet eri mieltä – saa toki kuitata vaikka olisi samaakin 😉

Totean myös, että en ole lakimies, ja tällä hetkellä tietosuoja-asetuksessa on monia alueita joista edes lakimiehet eivät voi sanoa mitään varmaa. Paras viisaus on jälkiviisaus, ja vuonna 2027 osaan kertoa faktaa. Tässä kohtaa kaikki blogautusten pointit edustavat omia näkemyksiä, jotka ovat ilman muuta ainutlaatuisen arvokkaita ja fiksuja. Mutta osa niistä on väistämättä tässä kohtaa ennustellessa väärin, ja tulkinnat tulevat sen aikanaan todistamaan. Toivon kuitenkin että mahdollisimman pieni osa.

Miksi jotain kannattais tehdä?

Tietosuoja-asetuksen siirtymä-ajan päättyessä 2018, sovellukset jotka eivät tue uusia vaatimuksia ja käyttäjän oikeuksia, muodostavat merkittävän liiketoiminnallisen riskin yrityksille. Olemassaolevien sovellusten, järjestelmien, rekisterien ja infran osalta muutos on kivuliaampi. Helpompi on alkaa tutkailemaan ihannetilaa uusien sovellusten osalta, joita vielä vasta suunnitellaan tai rakennetaan, ja tulevaisuuden sovellusten osalta, joita tullaan rakentamaan jatkossa. Ajatuksena on, että aikaa myöten opitaan ottamaan tietosuojavaatimukset huomioon automaattisesti, ja niistä tulee yhtälailla sisäänrakennettu osa kaikkea tekemistä kuin esim. sovelluksen toimivuuden testauksesta eri selaimissa. Ja tätä myöden myös kuluja saadaan alas/opitaan laskemaan ne luonnolliseksi osaksi tekemistä ja testaamista.

Ok, tylsä johdanto. Terästetäänpä tätä toisin. Kun Harri H Hakkeri eräänä päivänä penetroi systeemin ytimeen, haluamme rajoittaa riskiä siitä miten paljon sakkoja tulee maksettavaksi, ja kuinka laajaa osaa asiakasrekisteriä joudut kontaktoimaan tietosuojamurron osalta, sekä millä sävyllä iltapäivälehdet repostelevat asiaa.

On väärinkäsitys ajatella myös, että tämä koskee vain suuria organisaatioita. Sen verran uskaltaudun ennustamaan tulevaisuutta, että muutamakin keskikokoinen paja tulee ajautumaan konkurssiin jos tietosuojan kanssa ollaan leväperäisiä tai peräti röyhkeitä. Tietämättömyys tai pää puskaan-strutsiefekti ei ole tässä puolustus tai suojautumiskeino, päinvastoin. Se että yrittää vaikkei 100% onnistuisikaan, lasketaan todennäköisesti eduksi ja sakkoja tai sakon uhkaa merkittävästi pienentäväksi tekijäksi.

TL;DR

No, tässä kuitenkin tiivistelmä, mitä tulisi huomioida sovelluskehityksessä vuonna 2017, ja projekti/järjestelmätasolla noin muutenkin. Jos muistan, rupattelen infratason ratkaisuista ja hallinnasta, ja organisaatiotason prosesseista lisää toisella kertaa.

  • Riskilähtöisyys: tunnista, minimoi, dokumentoi
  • Henkilötietojen esiprosessointi: Tunnista, minimoi, dokumentoi
  • Sama juttu 3. osapuolien riippuvuuksien osalta: tunnista, minimoi, dokumentoi
  • Sama juttu henkilötiedon prosessoinnin osalta myös sisäisesti: tunnista, minimoi, dokumentoi
  • Tiedon elinkaari: määrittele,minimoi, toteuta, dokumentoi
  • Varmuuskopiot ja arkistointi, huomioi kaikki edellämainitut
  • Testidata, huomioi kaikki edellämainitut
  • Testiympäristöt, tarkkana myös tämän kautta
  • Verkkoinfra, verkkosegmentointi, minimoidaan vahingot, maksimoidaan jäljet
  • Tietoaineiston suojaus: anonymisointi,pseudonymisointi,salaus
  • Käytön valvonta, monitorointi, hälytykset
  • Kyvykkyys osoittaa tehdyt toimenpiteet, ja prosessien toteutuminen
  • Murtautumistapauksessa: prosessien tuki, forensiikka, hälytykset
  • Tietoturva-ja muut päivitykset
  • CI- ja CD- toimitusputkien suojaus ja tietoturva
  • Huom. Myös availability, saatavuus, on tietosuoja-huolenaihe
  • Henkilön oikeudet uuden tietosuoja-asetuksen alaisuudessa, käytännön toteutus?

 

Oletusarvoinen tietosuoja tähtää aikalailla samaan asiaan kuin itse tietosuoja-asetuskin – riskipohjaiseen lähestymistapaan. Ja se taas tarkoittaa että matalan riskin järjestelmiä voidaan suojata keveämmin kuin korkean riskin järjestelmiä. Eli askel numero 1…

Tunnista henkilötiedot, tunnista riskit

Tietosuoja-asetuksen kannalta riskin näkökulma on vähän eri kuin yrityksen kannalta – mutta riskin kohde on silti sama, henkilötiedot. Aiemmin puhuttiin jo siitä, miten tietoa voidaan tunnistaa, luokitella. Järjestelmissä on paljon tietoa, joka ei ole tietosuoja-asetuksen mielessä kiinnostavaa, mutta on silti ollut – ja tulee olemaan – hyvin tarpeellista suojata, esim. tuotetiedot, strategiat, ennusteet. Se mitä ei tietosuoja-asetus määritä henkilötietoksi, on kuitenkin oman harkinnan mukaan edelleenkin vapaasti suojattavissa ja käytettävissä, miten halutaan. Henkilötiedon suojaamiseen taas löytyy GDPR suunnalta kättä pidempää.

Se, minkä voi rajata pois tietosuojalain tarkoittaman henkilötiedon piiristä, voidaan salata – tai jättää salaamatta – vapaasti miten halutaan.

Tietosuoja-asetuksen välineenä käytetään pitkälti DPIA analyysiä. DPIA, eli Data Protection Impact Analysis, on vaikutusten arvioinnin malli, jolla voidaan analysoida riskikulmaa. Ennestään käytössä on monessa yrityksessä ollut PIA, Privacy Impact Assessment, joka on tähdännyt samalle alueelle, mutta hieman laveammalla pensselillä. Molemmissa on ajatuksena määrämuotoinen ja kattava tarkastelu järjestelmässä kerättävälle tiedolle. Molemmat perustuvat riskien hallinnan ajatukseen. Eli analysoidaan kerättävän tiedon riskien taso, ja sen jälkeen, riskipohjaisesti, sovelletaan sopivia kontrolleja, kunnes riski saadaan laskettua hyväksyttävälle tasolle.

DPIA mallia ei tarvitse soveltaa joka järjestelmään, mutta jonkinmoinen esikarsinta olisi tietysti aina hyvä tehdä. Periaatteessa järjestelmän tavoiteltu tietosuojataso määräytyy aika yksinkertaisesti sen mukaan, mikä on sen sisältämä riskialttein yksittäinen tieto, eli vaikka muu järjestelmä olisi aika tylsä, jos yhdestä taulusta löytyy sairauspoissaolojen syitä, se määrittää aikalailla järeimmän kautta suojaustarpeen.

Tähän väliin on hyvä todeta oma lempiteesini. Sataprosenttista tietoturvaa ei ole. Sataprosenttista tietosuojaakaan ei ole. Jokainen järjestelmä voidaan murtaa, jokaiseen dataan päästä käsiksi, jos tarkastellaan asiaa rajattoman ajan, ja rajattoman budjetin suunnasta. Lisäksi tietojärjestelmät elävät mutatoituvassa maailmassa – järjestelmä joka on tänään 99% turvallinen, kokee muutoksia vuoden aikana, ja voi ensi vuonna ollakin vain 70% turvallinen, koska sen ympäristöön on vuoden aikana tullut uusia komponentteja, avauksia, muutoksia, tai vanhoista komponenteista on löytynyt haavoittuvuuksia. Yksi suurimmista tietoturva-haavoittuvuuksista on security misconfiguration, eli virhe ympäristöjen asetuksissa, ja niitä pujahtaa sisään helposti myös järjestelmiin jotka olivat luotaessa arkkitehtuurisesti kauniita ja täydellisiä. Kun huomioidaan prosessit, ympäristöt, teknologiat, muuttujia on vain niin paljon, ettei kukaan voi väittää hallitsevansa niitä kaikkia, nyt ja aina, ja vaikka istuisit palvelimen päällä haulikko kädessä vahdissa 24 tuntia vuorokaudessa, niin mörkö pujahtaa sisään heti jos herpaannut hetkeksi. Ja ensi vuonna voi olla että istut väärän palvelimen päällä.

Eli, ainoa oikea lähestymistapa on tunnistaa suurin riski, madaltaa sitä sopivin keinoin, ja jatkaa kunnes ollaan hyväksyttävällä riskitasolla. Lisäksi tätä ei voi tehdä kertarysäyksenä, projektina, vaan tietosuojan täytyy olla jatkuva prosessi.

Tai vielä mielummin sisäänrakennettu, läpinäkyvä osa prosesseja, kaikkea tekemistä. Siihen on vielä useimmilla yrityksillä pitkä aika. Valitettavasti monet ottavat lähtölaukauksen tekemiseen vasta ensi kesänä, kun uhat alkavat toden teolla realisoitumaan.

Tietosuoja-asetuksen kannalta erityisriskin muodostavia tietoja, joihin tulee kiinnittää erityistä huomiota, ovat mm.

  • Alaikäisistä rekisteröidyistä kerätyt tiedot (vaikka rekisteröity sittemmin olisi jo täysi-ikäinen)
  • Rotu,uskonto,politiikka,terveydentila,rikosrekisteri eli eiheet jotka monen mielestä eivät ole hyviä ruokapöytäkeskustelun aiheita (mutta omasta mielestäni niitä kiintoisimpia, moukka kun olen!)
  • Biometriset tunnisteet

Eli näitä tietysti suojataan rankimman kautta. Hyvä huomata kuitenkin, että ns kovan ja yksilöivän henkilötiedon ohella, myös identiteettiin liittyvää tietoa koskee moni tietosuoja-vaatimus, esim. henkilön oikeudet. Ja se mikä liittyy identiteettiin voi joissain tapauksissa olla yksilöivää, ’jos yksilöinti voi tapahtua kohtuullisella vaivalla tietoja yhdistelemällä’ – esim. muutama erillinen paikkatieto, tai erityinen tietopaketti harvaan asutulla alueella, jne – eli samalla lailla kuin itse identifioivaa tietoa, voi varautua suojaamaan myös identiteettiin liittyviä tietoja.

Toinen tapa lähestyä riskiä on miettiä ihan terveellä järjellä, miten suuren riskin REKISTERÖIDYLLE muodostaa, jos tämä tieto julkaistaisiin iltapäivälehden etusivulla. On hyvin tärkeää muistaa, että tietosuoja-asetuksen riskianalyysissä riskin näkökulma on aina rekisteröity, ei rekisterinpitäjä. Se näkökulma määrää, miten raskaasti tietoa tulisi suojata ja vartioida.

Toisaalta samoja periaatteita voi myös soveltaa muuhun sensitiiviseen tietoon, vaikka ei henkilötietoa olisikaan. Se ei ole tietosuoja-asetuksen kannalta mielenkiintoista, mutta voi olla liiketoiminnan kannalta hyvinkin mielenkiintoista.

Minimoi ja dokumentoi kerättävä tieto

No niin, nyt tulee se hyvä uutinen. Paras tapa keventää kuluja ja suojauskontrollien tarvetta, on olla keräämättä sitä henkilötietoa alunperinkään. Ennen vanhaan oli tapana keräillä kaikenlaista ihan vain varmuuden vuoksi, ties vaikka sitä jossain raportissa tai analyysissä kaivattaisiin, ja miksikäs ei. Sellainen lähestymistapa ei enää tietosuoja-asetuksen aikana kanna pitkälle.

Nyt kannattaa aloittaa miettimällä, mitä tietoa todella tarvitaan, ja millä oikeudella sitä kerään, varastoin, prosessoin. Tämä osa kannattaa dokumentoida hyvin, ja keskustella niistä harmaista alueista, joista ei olla varmoja. Voi myös miettiä sitä, voiko henkilötietoja eristää esim. omaan erilliseen järjestelmään, palveluun, kantaan, tauluun, jota voidaan suojata järeämmin kuin muita.

Sen ohella että minimoidaan siis ’leveyssuunnassa’ kerättävää tietoa – kyseenalaistamalla jo alun alkaen mitä kenttiä laitetaan, mitä tietoja kysellään – kannattaa myös huomioida aikadimensio, eli minimoida miten pitkään tietoja säilytetään. Minimointi ei tarkoita, että kaikki tieto pitäisi heti pyyhkiä, mutta tiedon elinkaaren suunnittelu on erittäin hyvä käytäntö ottaa mukaan tietomalliin alusta alkaen. Elinkaari voi olla vaikkapa puoli vuotta, tai viisi vuotta, kymmenen vuotta, jne. Mutta kun se ymmärretään, dokumentoidaan, ja toteutetaan, on taas pienennetty merkittävästi hyökkäyspinta-alaa.

Jos tapahtuu se pahin, eli huomataan tietomurto tai väärinkäytös järjestelmän ytimessä, muualle arkistoitu ja erikseen suojattu, tai täysin poistettu tieto voi olla sellaista, jota tietomurron ei katsota koskevan, ja näin ollen joudutaan kontaktoimaan vain niitä, joiden tiedot ovat aktiivisessa kannassa. Lisäksi tämäntyyppinen elinkaariajattelu ja suojauskontrollit lasketaan eduksi jos joudutaan jotain sakkorangaistuksia tai muita sanktioita miettimään.

Mutta siis, vanha tapa kerätä kaikki mahdollinen, ja säilyttää sitä ajan tappiin on huono käytäntö, ja sitä ei enää pitäisi harrastaa. Ja jos tiedon pinta-alaa tai säilytysaikaa ei pysty fiksusti minimoimaan, ainakin se kannattaa dokumentoida. Dokumentaatiota tulisi tuottaa sekä järjestelmäkehityksen ja ylläpidon tarpeisiin, että myös rekisteröidyn selosteeseen, jotta läpinäkyvyyden periaate toteutuu. Ja jos rekisteröity pystyy ymmärtämään kerätyn tiedon laajuuden, syyt, ja elinkaaren sen perusteella, pyynnöt esim. poistaa tietojaan järjestelmästä saattavat harventua.

Varaudu kuvaamaan MITÄ kerätään, MIHIN tarkoitukseen, ja MITEN sitä prosessoidaan (aka keiden toimesta). Varaudu tarjoamaan yhtä helpot keinot myöntää lupia tiedon keruuseen ja käyttöön, kuin lupien tarkistamiseen ja poistamiseen.

Minimoi pääsy

Tietosuojassa ei ole kyse vain ulkoisista tietomurroista, yli 30% väärinkäytöksistä tapahtuu verkon sisäpuolella, usein omien työntekijöiden, nykyisten tai entisten, toimesta. Huonosti suunnitellussa (tai monimutkaisessa, suurikokoisessa, iäkkäässä) verkossa voi olla myös pääsyä partnereilla, ulkoisilla työntekijöillä, konsulteilla, vuokratyöntekijöillä, tai miksei myös sovelluskehittäjillä, ylläpitäjillä, järjestelmätoimittajilla, jne.

Motiiveja voi olla esim. uteliaisuus, pyrkimys hyötyä, vandalismi, jne. Tietosuoja-asetus on tältä osin hyvin yksinkertainen. Henkilötietoon ei tulisi olla pääsyä enempää kuin mitä on tarpeen. Se mitä on tarpeen tulisi olla dokumentoituna. Eli ei ole kiellettyä että ylläpitäjillä on pääsy tietoon, kunhan se on läpinäkyvää. Eri asia on millaisen riskin se muodostaa.

Jos jotain tapahtuu, pääsyn minimointi myös voi rajoittaa vahinkoja, tai parantaa mahdollisuuksia näyttää toteen, mitä osaa tietoja tietomurto tai tietosuojaloukkaus koskee.

Näissä on hyvä suunnata huomiota terveydenhuollon järjestelmien suhteen, Suomessa ja muualla. Niissä on jouduttu jo iät ja ajat huomioimaan potilastietojen luottamuksellisuus, ja sieltä löytyy hyvin ideoita, käytäntöjä, toimintatapoja. Eri asia on, onko niitä terveydenhoidon järjestelmissäkään aina toteutettu ideaalisti. Mutta siellä on jouduttu jo pitkät ajat vastaamaan tällaiseen vaatimukseen.

3. osapuolen prosessointi

Tietosuoja-asetus ei estä sitä että dataa voi nyt ja jatkossakin prosessoida myös 3. osapuoli. Itse asiassa, prosessoijaksi kun lasketaan myös esim. pilvipalvelutarjoajat, kuten Amazon AWS, ja Microsoft Azure, enenevässä määrin toimitaan ympäristössä jossa on useampia osapuolia prosessoijina.

Nyt mennään alueelle joka ei ole omaa vahvinta aluetta: Lakipykälät ja niiden tulkinta. Mutta vapaasti oman ymmärryksen mukaan tärkeää on huomioida tämän osalta dokumentointi, ja sen mukana tulee luonnollisesti muut hyveet, kuten tiedon ja pääsyn minimointi ja suojaus, sekä sopimukset. Sopimustekniikka tulee varmaan tässä vielä kehittymään vuoden sisään, esim. Amazon on luvannut että ensi vuoden kesään mennessä tulee olemaan tietosuoja-asetuksen edellyttämät asiat huomioituna palvelusopimuksissa.

Se missä tulee olla tarkkana, on yhteisen vastuualueen kasvu, ja se missä rajat kulkevat. Moderni tietojärjestelmä on kokonaisuus jossa on aika monia tahoja. Jos nyt sattuisi että esim. AWS vastuunjakomallin mukaisesti tietosuojaloukkaus on tapahtunut 3. osapuolen tontilla, esim. medioiden huolimattoman hävityksen, tai fyysisen tietoturvan puutteen vuoksi, kantaako Amazon myös rahallista vastuuta sakoista, ja minkä firman liikevaihdon mukaan se menee? Entä jos 3. osapuoli ei olekaan AWS, joka sinällään on rutinoitunut ja ison talon koneisto, vaan autotallissa majaileva analytiikkafirma?

Mitä ajan takaa tässä, on pari huomiota. Tulkinnat tulevat elämään ja muotoutumaan vielä vuosia, sitä mukaa kun ikäviä asioita tapahtuu. Ja jatkossa ei riittäne pestä käsiään tietoturvasta ja tietoturvasta siinä kohtaa kun data siirtyy 3. osapuolen käsiin. Yhteisvastuullisuus on päivän sana, ja hyvä niin.

 

Jatkuu ensi numerossa…

No niin, kuten varoittelin, tästä tulee pitkä juttu. Kulmia on monia. Kirjailen lisää ajatuksia toisella kertaa, mennen lähemmäs kehittäjän konkretiaa. Osa näistä asioista, kuten 3. osapuolen sopimukset, eivät ole välttämättä heti toimittajan mielestä ehkä asioita joihin voi vaikuttaa, mutta softaprojektissa tulisi asianmukaisen matkaopastelijan kiinnittää huomiota siihen, miten asiat kokonaisuutena tehdään. Jos joku osa-alue on rempallaan, siitä kannattaa keskustella, ja kiinnittää huomiota, vaikka sieltä voisikin löytyä lisäkuluja.

Osittainen tietoturva on hyödytöntä tietoturvaa.

 

Mainokset

RESTAssured ja Istuntokeksit

REST ja istunnot ovat aikalailla paradoksi. Mutta silti joskus löytää itsensä tilanteesta jossa tilattomat REST palvelut ovat tilallisen autentikoinnin takana, esim. JSESSIONID evästeellä seurattuna (Ja kyllä, Suomen Kielitoimisto suosittaa nykyisin Cookielle termiä eväste, aiemmin keksi, ja uskokaa tai älkää, alunperin Taikapipari). Jos vielä heikommin käy, edessä voi olla joku single-signon hirviö joka tokenien sijasta käyttää useampaa istunto-evästettä. Ja jotenkin pitäisi saada kirjautumisen jälkeen istunnot säilymään.

Jos kyseessä on vain yksinkertainen JSESSIONID case, alkaen RestAssured versiosta 2 sille on tuki valmiina, parillakin eri tavalla. Nopein tapa saada sessio-cookie lähetettyä edestakaisin on tähän tapaan:

RestAssured.filters(sessionFilter);

Tuo pitää huolen, että sessio-eväste kaapataan vastauksista, ja liitetään pyyntöihin. Toimii heittämällä jos nimi on JSESSIONID – kunhan vain pidät huolen siitä, että sessionFilter on kaikissa kutsuissa sama, esim. luomalla sen staattisena:

public static final SessionFilter sessionFilter = new SessionFilter();

Entä jos evästeen nimi ei ole JSESSIONID? No, sen voi helposti muuttaa RESTAssured konfiguraatiolla:

RestAssured.config = newConfig().sessionConfig(new SessionConfig().sessionIdName("KOTLINSESSIONID"));

Entä jos pitäisi puljata useampia tracking cookieita, ja niiden nimet muuttuvat välissä? No ei hätää, sen voi hoitaa omalla custom filterillä, tähän tapaan:

public class CookieResenderFilter implements com.jayway.restassured.filter.Filter {

  private Map<String, Object> cookiesMap = new HashMap<String, Object>();

  @Override
  public Response filter(FilterableRequestSpecification filterableRequestSpecification,
                         FilterableResponseSpecification filterableResponseSpecification,
                         FilterContext filterContext) {
    filterableRequestSpecification.cookies(cookiesMap);
    Response response = filterContext.next(
      filterableRequestSpecification,
      filterableResponseSpecification);
    Map<String, String> cookiesReceived = response.getCookies();
    if (cookiesMap.size() == 0 && cookiesReceived.size() > 0) {
      for (String key : cookiesReceived.keySet()) {
        cookiesMap.put(key, cookiesReceived.get(key));
      }
    }
    return response;
  }
}

Ja tuo rekisteröidään käyttöön kuten yllä, taas pitäen huolta siitä että kyseessä on aina sama instanssi, ei aina uusi – koska sen jäsenmuuttujia käytetään tiedon varastointiin testisession ajan.

Oikeastihan tilallisuus + REST rajapinnat ovat helvetin seitsemännen tason keksintö ja jo tätä artikkelia kirjoittaessa tuli likainen olo, mutta aina ei pääse valitsemaan työkalupakkiaan. Kun pääsee, käyttäkää BCRYPT Token headereita, ihmiset!

Angular2 + NPM + Webpack

Lupailin kirjailla vähän lisää fiksusta Angular2 setupista tuotantohommiin. Tarkoitus oli tunkkailla minimaalinen paketti jossa on helppo erottaa eri tekniikoiden tehtävät. Valitettavasti Angular2 on aika liikkuva kohde tällä hetkellä – ja kiirettäkin on pitänyt, joten yksinkertainen POC projekti on jäänyt haaveeksi.

Onneksi joku muu on tehnyt sellaisen. Tällä hetkellä fiksuinta on aloittaa kokeilut ylläpidetystä Angular2 Webpack Starter projektista: https://github.com/AngularClass/angular2-webpack-starter

Valitettavasti tuo projekti ei ole yksinkertainen eikä siisti, mutta hoitaa homman. Ja se on kuitenkin hyvin linjassa sen kanssa mitä itse ajattelen. Angular2 kehittyy vauhdilla juuri nyt, ja joka releasen myötä se on siistimpi ja eheämpi ja vähemmän tarvitaan purkkaa taustalle. Sitä myöten voisin kuvitella että tämä webpack starterkin yksinkertaistuu.

Joka tapauksessa, vähän saatesanoja projektin suhteen. Senhän saa käyttöön nätisti kokeiluun (kun nodet on asennettuna), esim. näin:

 

git clone https://github.com/angularclass/angular2-webpack-starter.git
cd angular2-webpack-starter
npm install
npm start
curl http://localhost:3000

Curlin sijasta voit luonnollisesti tyypittää oikealla selaimella. Kuten kynäilin viimeksi, Bower on vähän menemässä muodista pois, samoin Grunt – paljon kuin sitä ja Gulpia rakastankin. Jos haluaa, voihan molempia noita käytellä vieläkin, ja voi olla joku tehtävä jossa Gulp voi olla esim. hyödyllinen. Mutta vanilla on päivän maku näissä asioissa, ja aikalailla paljon saa aikaan ihan vain puhtaalla JavaScriptillä ja NPM:llä.

Kannattaa luoda silmäys package.json tiedostoon. Se on tässä kaiken avain. Ja voi olla pelottava kokemus tässä vaiheessa jos on tottunut että se on vain kirjastomanifesti. Tosiaan devdependencies-lista on aika kattava näinkin yksinkertaiselle projektille, mutta tulee yksinkertaistumaan jatkossa. Ja toki siinä on jo aika kattavasti testaustyökaluja mukana. Pääjuju kuitenkin, että riippuvuudet on fiksuinta hakea kaikki npm keinoin, softan omat riippuvuudet ovat dependencies kohdassa, ja Boweria ei käytetä.

Mielenkiintoinen osio on kuitenkin scripts-osio. Vielä pari vuotta sitten oli tavanomaista että tämä oli tyhjä tai siinä oli 1-2 kohtaa, build ja test. Nyt tässä näkyy hyvin painopisteen muutos. Perinteiset grunt/gulp työvaiheet on nyt npm scripts työvaiheina, ja ne ovat modulaarisia ja ketjutettuja. Tarvittaessa käytetään noita dpm dev moduuleja, esim. rimraf poistaa tyylikkäästi tarvittavat hakemistopuut. Jos tuosta poimii muutaman mehukkaan ja keskeisen komennon niin ne ovat:

"clean": "npm cache clean && rimraf node_modules doc typings coverage dist"
"build:dev": "webpack --progress --profile --colors --display-error-details --display-cached"
"server:dev": "webpack-dev-server --progress --profile --colors --display-error-details --display-cached --content-base src/"

Näitä pääsee ajamaan komennolla npm run, esim.

npm run build:dev (ajaa kehitysversion buildin)

Samaan listaan on myös määritetty oikopolkuja yleisimpiin, esim:

"build": "npm run build:dev"
"server": "npm run server:dev"

Siinäpä nuo yleisimmät. Ja loput hoitaa webpack. Webpackillä on tässä kaksi keskeistä tehtävää: Tärkein on lähdekoodin prosessoiminen halutuksi paketiksi (sisältäen tarpeen mukaan babelifioinnit, minifioinnit, obfuskoinnit, jne), ja sen ohella myös sisäänrakennettu testiserveri on mukava. Konfiguraatiot käännöksiin löytyvät projektin juuresta, esim. tsconfig.json ja webpack.config.js. En pui niiden sisältöä tässä sen enempiä, mutta ne ovat aika selkeitä ja tehtäväänsä keskittyneitä. Ehkä hyvä mainita että toisin kuin Angularin omassa yksinkertaisessa tutoriaalissa, moduulijärjestelmänä SystemJS on korvattu CommonJS:llä.

Mitäpä muuta? Sain aiemman artikkelin suhteen vähän kommenttia/kysymystä tuosta Mavenin käytöstä. Itsehän tyypillisesti teen backendit Javalla/Spring Bootilla, ja frontend on vain osa kokonaisprojektia. Ja koska asiat on kiva pitää yksinkertaisena, samalla kun buildataan Mavenillä backend hyväksi, on mukava rusauttaa läpi myös frontend buildit. Käytän tähän tosiaan eirslett maven plugaria, joka voi yksinkertaisimmillaan näyttää tältä:

<plugin>
  <groupId>com.github.eirslett</groupId>
  <artifactId>frontend-maven-plugin</artifactId>
  <version>0.0.27</version>
  <executions>
    <execution>
      <id>install node and npm</id>
      <goals>
        <goal>install-node-and-npm</goal>
      </goals>
      <configuration>
        <nodeVersion>v5.5.0</nodeVersion>
        <npmVersion>3.3.12</npmVersion>
      </configuration>
    </execution>
    <execution>
      <id>npm install</id>
      <goals>
        <goal>npm</goal>
      </goals>
    </execution>
    <execution>
      <id>npm build</id>
      <goals>
        <goal>npm</goal>
      </goals>
      <configuration>
        <arguments>run build:prod</arguments>
      </configuration>
      <phase>compile</phase>
    </execution>
  </executions>
</plugin>

Käytännössä siis tuo tarkoittaa:

  • Varmista että node ja npm ovat asennettuna paikallisesti
  • Aja npm install
  • Aja npm run build:prod scripti – automaattisesti Mavenin Compile vaiheessa, eli samalla kuin backend kooditkin käännetään

Yksinkertaista. Webpack on konfiguroitu puskemaan prosessoidut .js tiedostot, html:t ja muut staattiset osat sopivaan kansioon, josta Mavenin paketointivaihe ne sitten nappaa mukaan .war pakettiin.

Huomaa että jos haluat ajaa Mavenin läpi muitakin npm taskeja, se onnistuu määrittämällä sopiva Maven property jonka voit komentoriviltä ylikirjoittaa, ja käyttämällä sitä tuon npm taskin konfiguraatiossa, esim. näin:

<execution>
  <id>npm build</id>
  <goals>
    <goal>npm</goal>
  </goals>
  <configuration>
    <arguments>${npm.argument}</arguments>
  </configuration>
  <phase>compile</phase>
</execution>

En kuitenkaan nykyisellään koe tälle erityistä tarvetta. Mavenin päätehtävä on varmistaa että riippumatta koneen varustuksesta paketti osaa buildata itsensä eheäksi itsenäisesti, oli sitten kyseessä Jenkins ympäristö tai uuden projektiin tulevan kehittäjän kone, tai vanhan devaajan uusi kone. Eli toiminta varmistetaan kaikissa olosuhteissa. Mutta noita muita npm käskyjä voi hyvin ajaa ohi mavenin esim. frontend-painotteisten kehittäjien toimesta, esim.watch on varsin hyödyllinen kun haluaa saada käyttöliittymäkehityksessä jatkuvaa palautetta. Siksi perusbuildi Mavenin kautta ajettuna usein riittää, ja oletuksena production buildi on tietysti hyvä.

Tässä mietteitä tällä kertaa. Matka vilkkaassa frontend maailmassa jatkuu….

 

 

Spring Boot Audit Logging

Jotain backendimpää taas vaihteeksi: Projekteissa tulee melkolailla tiheään vaadetta saada aikaan audit loggausta. Vaikkei tulisikaan, se antaa pitkän elinkaaren projekteissa itsellekin mielenrauhaa, että kykenee vastaamaan kysymykseen kuka teki mitä teki milloin teki (miksi teki ei vielä onnistu mutta ehkä IoT avulla sekin ratkaistavissa).

Audit loggausta voi tehdä villistikin eri tavoin ja eri vaatimuksilla. Joissain projekteissa on tultu nähtyä yksinkertainen audit service jota kutsutaan aina tarvittaessa, halutuista paikoista. Tässä on huonoa se, että pitää muistaa kutsua sitä, eli ei ole taattua että suuremmassa projektissa joka koodaaja on laittanut auditit paikalleen, lisäksi se rikkoo DRY periaatetta aika rumasti. Toisaalta on mahdollista tehdä monellakin tapaa filter/interceptor, joka tulee aina väliin ja loggaa vaikka kaiken. Mutta tässä mallissa voi olla ongelmana suuri hälyn määrä, eli voi olla että logi täyttyy tapahtumista jotka eivät ole oikeasti kiinnostavia mutta joita on paljon.

Kirjoittelen tätä blogia koska löysin mielestäni fiksun ratkaisun Spring Frameworkin puolelta, vieläpä Spring Boot yhteensopivana, eli ei xml:ää vaativana. Ratkaisu on fiksu koska se on mukava kompromissi kahdesta mainitusta ääripään tavasta – sisältäen tavallaan molempien huonoja ja hyviä puolia. Mutta ennenkaikkea se on melko kaunis, esteettinen, eikä riko yhtälailla ikävästi DRY periaatetta. Kirjaan näitä ylös myös ennenkaikkea itselleni muistiin, vähentää kivasti tarvittavaa aikaa soveltaa uudelleen, kun on tiedossa testattua luotettavaa ja (tällä hetkellä) ajantasaista tietoa.

Se mitä halusin on oikeastaan mahdollisuus auditoida metoditasolla on-demand, missä haluan. Ei täysautomaattisesti kaikkea, mutta ei myöskään samaa koodia copy-pasteillen joka paikkaan. Lisäksi halusin että voin halutessani määrittää audit eventille nimen, ja/tai kategorian, ja/tai koodin, pelkän metodi/luokannimen sijasta.

Homma lähtee liikkeelle ihan perinteisistä Spring AOP annotaatioista. Eli tarvitaan ensin Spring Boot projekti. Niistä olen kirjaillut jo aiemmin eli en lähde ihan sillä tasolla asiaa avaamaan tällä kertaa. Mutta sen päälle tarvitaan AOP dependency, näin:

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-aop</artifactId>
 <version>${spring.boot.version}</version>
 </dependency>

Ja nyt ollaan jo aika pitkällä 😉 Hyvä huomata että Spring Boot on aika herkkä sille mitä kaikkea automatiikkaa olet kytkenyt päälle, itse olen saanut AOP featuret vahingossa joskus pois päältä esim. väärillä annotaatiolla Application/Configuration-luokassa. Mutta yleisin syy silti AOP toimimattomuuteen on rikkinäiset pointcutit. Joten testataanpa ensin iisisti mahdollisimman lavealla interceptorilla:

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class AuditAOP {
@After("execution(* *.*(..))")
 public void logServiceAccess(JoinPoint joinPoint) {
 System.out.println("AuditAOP: Completed : " + joinPoint);
 }
}

Jep, tuossa on AspectJ joinpoint joka tarraa kiinni ihan kaikkeen, niin kauan kuin mennään Springin läpi eli kohteena on Spring-manageroitu komponentti.Tässä kohtaa vain logataan joinpoint. Hyvä katsoa toimiiko, loggaako. Jos loggaa, erinomaista. Tarvittaessa Joinpointilta voidaan louhia lisääkin tietoja:

@After("execution(* *.*(..))")
public void logServiceAccess(JoinPoint joinPoint) {
  System.out.println("AuditAOP: Completed : " + joinPoint);
  Signature signature = joinPoint.getSignature();
  String methodName = signature.getName();
  String arguments = Arrays.toString(joinPoint.getArgs());
  System.out.println("Method: " + methodName + " with arguments "
    + arguments +  " has just been called");
}

Toimiiko tämäkin? Loistavaa. Nyt on sitten aika siirtyä itse pihviin. Voit nimittäin tehdä tästä annotaatiovetoista, annotaatiota voi käyttää halusi mukaan joko kääntämään auditin pois päältä, tai päälle. Itse tykkäisin että on annotaatio audit, jolla voin valita auditoitavan eventin nimen. Sen käyttö tapahtuisi näin:

@Component
class JokuRandomiSpringService {
  @Audit("ACCOUNT_DELETE")
  public void poistaPirunTarkeeTili() {
    // Jotain ihan järkyn fiksua koodia tähän kohtaan
  }
}

Jeah, aika mukava? Joten tehdään tämmöinen:

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Audit {
  String value() default "";
}

Sitten siihen todelliseen taikuuteen. Eli miten aop interceptor aktivoituu vain annotaation havaitessaan? Näin:

@Before("execution(* *.*(..)) && @annotation(audit)")
public void logServiceAccess(JoinPoint joinPoint, Audit audit) {
  String event = audit.value();
  if ("".equals(event)) {
    event = joinPoint.getSignature().getName();
  }
  Principal user = (Principal) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
  String remoteAddress = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes())
    .getRequest().getRemoteAddr();
  auditEventService.createEvent(new AuditEventEntity(user.getName(), event, remoteAddress));
}

Huomaa myös että annotaation mäpätään joinpointtiin muuttujanimellä, ja tulee parametriksi interceptorille. Annotaation sisältä voidaan kaivaa halutut parametrit, tässä tapauksessa value, joka olisi audit eventin nimi.

Tämän esimerkin koodi menee vähän pidemmälle. Jos nimeä ei ole annettu, oletusnimi on kutsuttavan metodin nimi, eli value on valinnainen. Lisäksi kaivellaan käyttäjän identiteetti security contextista, ja ip-osoite request contextista. Huom! Esitetty malli ei ole yksikkötestiystävällisintä, voi olla että on elegantimpiakin tapoja injektoida nämä contextit.

Mitäs vielä? Tuossa koodissa oleva auditEventService on ihan tavallinen Spring komponentti/service, jossa on yksi rivi koodia jolla talletetaan audit eventti kantaan, sopivaan tauluun, jossa on halutut sarakkeet. Samoin auditevententity on yksinkertaisesti Entity Object, jossa on kentät username, event, remoteaddress – id ja aikaleima ovat autogeneroituja. Lisätään tietoa sen mukaan mikä on paranoian taso.

Joskus tuli tehtyä sellaistakin järjestelmää jossa haluttiin mahdollisimman iisi tietoturva – yleinen tietoturvan sääntö kun on, että mitä tiukemmin kiristää käyttäjille näkyvää tietoturvaa, ja vaikeuttaa arkea, sitä luovemmin opitaan kiertämään se tietoturva, luoden usein jopa turvattomampi ratkaisu kuin alunperin (salasanoja muistilapuilla, sama salasana kaikkialla, kulunvalvottujen ovien availu kohteliaisuudesta, jne). Hyviä tietoturvaratkaisuja ovat eritoten ne systeemit joissa tietoturva ei hankaloita käyttäjän arkea. (Tämän takia salasanat ovat helvetistä)

Esim. tarkka auditointi tarkkojen roolilokeroiden sijasta, kaikki saavat tehdä lähes kaikkea mutta kaikesta jää jäljet. Tai jos haluaa niin molemmat päälle. Riippuu ympäristöstä mikä on fiksua, tarpeellista tai lainsäädännön sanelemaa.

Hyvä huomata että tämän tason auditointi ei loggaa virheitä jotka johtivat keskeytymiseen jo aiemmin ketjussa, eli jos haluat vielä laveammalla siveltimellä, voit täydentää esim. servlet tason filttereillä ja virhekäsittelijöillä.

 

Angular 2 käyttöön

Viime ajat on tullut vietettyä Angular kakkosen kanssa. Tarkoitus oli alunperin jo joulun aikoihin käyttää kunnolla aikaa tähän uuteen päivitykseen, mutta silloin tuli kaikenlaista pientä tekemistä tielle.

Ensivaikutelma on ihastus. Kirjoittelin taannoin Aureliasta, joka on myös hieno paketti, ja jossa on paljon samaa Angularin kanssa. Mutta Angularin vahvana etuna on pitkät perinteet ykkösversiosta, ja sen myötä laaja käyttäjäkunta. Uusi versio ei heitä kaikkea roskiin, mutta tuo kaikenlaista mukavaa uutta. Tässä muutama highlight poimintana:

  • Typescript – ei ole pakko käyttää sitä mutta onhan se ihanaa
  • ES6 ja moduulit – käytä mitä osia kaipaat, ei tarvitse ladata kaikkea joka projektiin
  • Komponentit – ah miten elegantti ja ketterä lähestymistapa ui kehityskeen

Angular kakkosesta on ehditty jo kirjoittamaan tiukkoja vertailuja toista kuningasta – Reactia vastaan – ja puolin ja toisin. Molemmilla lähestymistavoilla lienee jatkossakin omat faninsa.

Vastaavasti laskukäyrän puolella olisi Bower ja Grunt – tuntuu että Angular kakkosen kanssa luontevaa on yhdistää npm, Webpack, ja tarvittaessa Gulp – jos sitäkään. Keep it simple, stupid! Node vitonen on myös nopea buildihommissa – ja aiemmin taisinkin jo kehaista npm:n nykyistä windows-ystävällistä hakemistorakennettakin.

Lähitulevaisuudessa tulossa jotain katsojaystävällistä getting started-tutoriaaliakin, toki hyviä on ihan Angularin omillakin sivuilla.. Mutta jos haluaa vähän helloworldiä realistisempaan mennä…

Devaajan maccikone tikkiin

Olen pitkien Linux ja Windows kausien jälkeen päätynyt tekemään työhommat Macbook Pro:lla, joka on ollut positiivinen kokemus. Siinä kivasti yhdistyy helppo käytettävyys, ja toisaalta Linux-mainen johdonmukaisuus. Jos joku ei toimi, korjaus on sama kaikilla, ja komentorivi on lähellä ja hyvä.

Pari kertaa on nyt työkone tullut asenneltua. Teen töissä tyypillisesti arkkitehtuurisuunnittelua, prototypointia, ja sekä Java backend koodia että Angular/React/Node JavaScript hommeleita, muutamalla eri kannalla riippuen projektista. Ensimmäisellä kertaa kun Mac oli uusi kokemus, kaikki meni käsityönä ja puolet asioista ihan päin prinkkalaa. Mutta kirjoitin kaiken muistiin, ja toisella kertaa päätinkin sitten automatisoida hommat.

Mac devaajan ihania kavereita ovat Homebrew, NVM, ja JENV. Näistä jälkimmäisistä olenkin kirjoitellut pari artikkelia aiemmin, mutta mainittakoon että laitoin dev-koneeni homebrew scriptit yleiseen jakoon Gittiin. Pohja-asennuksina on meidän IT:ltä tuleva OSX Macbook Pro, Yosemite tai Il Capitano, jossa on perus antivirukset ja officet ja emailit jo viritettynä kuntoon. Hyvä idea asentaa myös perus osx patchit ja java fixit. Sen päälle asennan Homebrew:n, ja sitten ajan tämän scriptin:

https://github.com/crystoll/osxinstall

Ja kuten scriptiä lukemalla käy ilmi, aika paljon kamaa on koneessa sen jälkeen. Yksi kollega vinkkasi vieläkin elegantimman scriptin, niinikään Githubissa, jossa on aikalailla samaa kamaa, mutta toteutus Ansiblella, jolla voi paikata vielä aukkoja joita esim. Homebrewn jäljiltä jää:

https://github.com/hoxu/osx-dev-playbook

Lopputulos kuitenkin: Pistät scriptin jylläämään, otat ison kupin kahvia, tabletista tai kännykästä yoububeen kunnon kissavideokanavan, ja kun kahvi on juotu tai kylmää, työkone on kunnossa. Kivasti säästää aikaa ja energiaa ja takaa että lähtökohdat ovat aina samat. Jos on muutama sata devaajaa talossa, parin htp:n säästö per napa muutaman vuoden välein on ihan kiva. Ja itse tykkään että asiat menee aina samalla tapaa, eikä tarvi uudelleen muistaa mitä kaikkea on syytä tehdä. Toki vähän huoltoa kaivataan, ja tuota ansible scriptiäkin voisi vähän pilkkoa rooleihin, modulaarisuus antaisi mahdollisuuden viritellä vielä paremmin. Joku voisi kaivata jotain kivaa rasti ruutuun käyttöliittymääkin, mutta minä en 😉

Automate everything! *ryystää kahvia^*

 

 

Java One 2015 käynnissä – tynnyritiukkaa Javaa 20 vuoden ajalta

Jokavuotinen Java-kehittäjien ykköstapahtuma pärähti juuri käyntiin San Franciscon suunnilla. Tänä vuonna en ole itse paikan päällä mukana, mutta seuraan mielenkiinnolla uutisia. Ennalta voi arvata jo standardipuolella pääfokuksena olevan tuleva Java 9, Java EE 8, sekä Jigsaw. Mutta mielenkiintoisinta on se, mitä ei voi ennalta arvata. Kyseessä on kuitenkin vuoden ykkösseminaari kaikille maailman Java-kehittäjille – ja heitähän riittää. Hyvä huomata että seuraavat mietinnät ovat ihan puhtaasti vaikutelmia omasta vinkkelistä ja pöhinästä mitä seminaarin ympärillä on tänne asti aistittavissa.

Java täyttää 20 vuotta – ja tämä JavaOne on yhdeksästoista mitä on järjestetty sitten vuoden 1995 kun tämä uusi tuntematon ohjelmointikieli tunki markkinoille ja Appletit olivat se killer app. Viskimitalla tämä 20-vuotias laajalle levinnyt ja maailmaa muuttanut ohjelmointikieli on nyt ’cask strength’ 😉

Hauskaa on se, miten Javan avoimuus puree tässä vähän itseään jalkaan. Open source projekteissa on vaikeata jemmata tai piilotella uusia piirteitä ja julkistuksia – joten niistä puhutaan jo ennen tapahtumaa. Siinä mielessä Java 9 /Jigsaw tavarat ovat aika ilmeisiä ja vähän hype-inflaatiotakin kokeneita.

Kokemuksesta tiedän, että painopistettä on myös teknologioilla jotka itsestä tuntuvat jo muinaisilta – kuten Java 8 ja Java EE 7. Niitä on tullut itse hyödynnettyä tuottavassa softatehtailussa jo vuosien ajan – kun taas monet muut tekevät niihin vasta siirtymää. Isojen valmistajien sovelluspalvelimissa eritoten ei ole aina mahdollistakaan saada tuoreinta versiota, saati sitten päivitellä sitä. Itse taas kun pyörin Spring Boot+Glassfish+JBOSS ympyröissä enimmäkseen, voi nautiskella aika aikaisinkin uusien versioiden eduista. Mutta tuolla seminaarissa siis monessa paikkaa vielä käsitellään vasta siirtymää näihin, mikä on hyvä. Kaikki ajallaan, ja aihe on kiinnostava, monelle myös uusi.

Tuolta löytyy ihan mielenkiintoista dzone tutkimustietoa mm. Java EE 7 käyttöönotoista, samoin kuin esim. Spring Frameworkin osalta: https://blogs.oracle.com/theaquarium/entry/developers_affirm_strong_support_for

Eipä silti, en itsekään ole tuotantoympäristöön tuikkailemassa Java 9:ää. Mutta omaan tyyliin on aina kuulunut perehtyä tulevaan mahdollisimman ajoissa. Yksi Spring Boot alustan kiva piire on, että sinne voi ottaa helpommin yksittäisten rajapintojen ja kirjastojen uusimpia versioita, kunhan vain pystyy elämään potentiaalisten konfliktitilanteiden kanssa. 🙂

Seminaarissa on aina kosolti piiloteemoja, eli jotain yksityiskohtia siitä mitä Javalla tehdään. Näyttää siltä että micro/nano/picoservicet ovat yksi päivän kuumia aiheita. Eikä ihme. Lupaavaa tavaraa, joka monella taholla on vielä lastenkengissään, ja vielä useammassa paikkaa täysin mahdoton ajatus. Adam Bien on aina ollut ajan hermolla, ja piti täälläkin esityksen ”Building Nanoservices with Java EE and Java 8” joka veti jo ennakkoon salin täyteen.

Oracle julkaisi oman Java SE pilvipalvelunsa, joka on myös microservice-yhteensopiva: https://cloud.oracle.com/javase. Siellä voi ajella esim. Tomcat tai Spring Boot sovelluksia modernin kaavan mukaan – ilman raskaita full Java EE stack-sovelluspalvelimia (tai no voihan sellaisenkin varmaan tuonne rakentaa jos ehdottomasti haluaa 😉

Kannattaa jatkossakin pitää silmällä Project Valhallaa – hautomoa radikaalimmille Java kielen/virtuaalikoneen tason muutoksille. Se ei ole varsinaisesti mikään uusi juttu mutta muodostanee pohjan Java 9, 10 ja 11 versioille: http://openjdk.java.net/projects/valhalla/. Hyvä kuitenkin muistaa että hautomossa on ideoita joista osa kypsyy, mutta osa putoaa kylmästi pois.

IoT on yksi piiloteemoja, mikä ei ole suuri yllätys. Javan juurethan ovat syvällä tässä: Network IS the computer. Varmastikin yksi Java 9 modulaarisuuden vaikuttimia on juuri mikrolaitteiden älykkyys, kyky ajaa Javaa muuallakin kuin työasemissa, palvelimissa tai vaikka puhelimissa.

Mutta siinä omia ensivaikutelmia täältä etäältä mitattuna. Tuolta voi kurkata avaus-keynotet, ja show on vasta käynnistymässä…

https://www.oracle.com/javaone/on-demand/index.html#javaonekeynotes