About Arto Santala

Olen töissä räätälöityjen ohjelmistoratkaisujen parissa Solita- nimisessä firmassa, tämä blogi on kuitenkin omia, henkilökohtaisia mietteitäni varten. Käsittelen pitkälti ohjelmistokehitykseen liittyviä teemoja kuten Agile, SOA, ja erilaisia Java kirjastoja ja trendejä. Blogi on ennen muuta muistio itselleni, mutta sitä saa myös kernaasti kommentoida ;)

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… 😉

 

Java 9 on kymmenen kertaa nopeampaa!

Törmäsin mielenkiintoiseen ilmiöön taannoin. Valmistelin esitystä suorituskyvystä ja Java muistimallista, ja ajoin eräänlaista benchmark sovellusta Dockerin avulla eri virtuaalikoneissa. Sovelluksen ideana on sisältää aika typerästi kirjoitettua mutta varsin tavanomaista Java-koodia. Silmukoita, ehtolauseita, merkkijonojen käsittelyä, laskentaa, kokoelmien käsittelyä, ja kellottaa paljonko kaikkeen menee aikaa. Tällä voidaan myös nähdä nykyaikaisen virtuaalikoneen itseään optimoiva vaikutus – kun ajo jatkuu, nopeus yleensä kasvaa. Tässä on sovelluksen mittaustuloksia Oracle Java 6 Docker kontissa ajettuna:

Screenshot 2016-10-16 13.19.54.png

Eli, yhden kierroksen aika on n. 84 sekuntia, laskien 82 sekuntiin jahka virtuaalikone vähän ”lämpenee” eli käytännössä jit-kääntää enemmän koodia ja tekee muita tarvittavia optimointeja.

 

Tässä on OpenJDK+Java 8 ajotulokset:

Screenshot 2016-10-16 13.23.31.png

Kuten tuloksista näkyy, uudempi virtuaalikone optimoi usein tehokkaammin. Tässä kierrosajat pyörivät n. 62 sekunnin pinnassa – Java 6 verraten on irronnut noin 20 sekuntia, tai 1/4 suoritusajasta. Paras kierrosaika oli jopa 52 sekuntia. Aika hyvä tulos!

Kokeillaanpa G1 roskankeruualgoritmilla:

Screenshot 2016-10-16 13.35.12.png

Oops! Vaikka G1 on teoriassa kauneinta ja uusinta mitä roskankeruualgoritmeihin tulee, se ei ole joka ongelmaan optimaalinen ratkaisu. Suoritusajat vaihtelevat 98 ja 104 sekunnin välillä ja ovat nousemaan päin. Tällä sovelluksella ja tämän koneen muistilla tässä tuli takapakkia, huonompi suorituskyky. Varmaan tästä syystä G1 ei ole vielä oletusalgoritmina vaan pitää erikseen kytkeä päälle lisäparametrilla -XX:+UseG1GC.

Java 9 julkaistaan vasta pitkällä ensi vuonna. Siitä on kuitenkin jo prereleaseja liikkeellä, ja jopa Docker virtuaalikuva. Tämän ansiosta on lasten leikkiä ajaa sama koodi Java 9:llä. Tulokset tässä:

Screenshot 2016-10-16 13.36.26.png

WUT? Sama koodi, tekee saman asian, sama koneympäristö ja resurssit. Suoritusajat vaihtelevat 9 ja 12 sekunnin  välillä. Karkeasti ottaen noin kymmenen kertaa nopeampaa kuin useimmat muut testiajot, ja yli viisi kertaa nopeampaa kuin paras tulos tähän asti.

Jotain on muuttunut. Mitä, en tiedä vielä. Epäilen että yksi tekijä voi olla Jigsaw moduulimallit. Toinen tekijä lienee, että on taas opittu tunnistamaan joku negatiivinen koodaustapa, ja optimoimaan sen suoritus. Tulokset tuskin ovat yleispäteviä, ne pätevät lähinnä tähän tyypilliseen koodiesimerkkiin mitä käytin, ja tähän ympäristöön. Docker välissä voi myös vaikuttaa jotain, tuskin kuitenkaan paljoa. Niin tai näin, koodi otti taas kerran hurjan tehokkuushypyn. Tätä herkkua olisi luvassa ensi vuonna.

Virtuaalikoneiden ihanuus on siinä, että nautit kaikista edistysaskelista, ilman koodimuutoksiakin. IBM nimesi juuri oman open source JDK 9 versionsa JIT-kääntäjän Testarossaksi, joten veikkaisin että sieltä on myös suurta hyvyyttä tulossa.

p.s. Docker on ihana keksintö!

p.p.s. Niin on Cathode terminaalikin :p

 

Angular 2 pajahti finaaliin asti

Tämän päivän kiinnostava uutinen: Angular 2 on nyt Final, ei enää pelata RC tai Beta-versioilla.

http://angularjs.blogspot.fi/2016/09/angular2-final.html

Minulla on ollut ilo vuoden sisään veistellä ratkaisuja sekä Angular versiolla 1, Angular 2:lla, että Aurelialla. Näistä kolmesta Angular ykköstä en enää käyttäisi. Aureliassa on monta arkkitehtuurisesti ihastuttavaa asiaa, mutta monet kulmat tuntuvat vielä vähän puolivalmiilta. Voi johtua siitä, että se on vielä puolivalmis. Yksi närä on ylimääräisen jspm pakettimanagerin käyttö.

Angular 2 on tästä kolmikosta tuntunut käytössä parhaalta, jo esijulkaisuversioissa. Siinä on React-maista komponenttiajattelua: Ruutu on komponentti, joka pilkotaan osakomponentteihin, jne. Siinä on kaikki hyvä mitä oli Angular 1:ssä, mutta yksinkertaistettuna. Se vaatii välineiltä vähän enemmän, ja hauskasti ollaan tultu täysi kehä siinä miten yhdistetään html+css+javascript tai typescript koodit. Sen dokumentaatio on erinomaisella tolalla.

Odottelen innolla milloin pääsen taas viuhuttelemaan finaaliversion Angular kakkosta, ja tekemään lisää komponentteja.

https://angular.io/

Java 9 viivästyy – saatavana heinäkuussa 2017

Tuoretta uutista, tosin ei yllättävää. Java 9 – jota on jo lykätty useita kertoja, ja jonka ominaisuudet ovat kaikki aiemmista versioista lykättyjä – viivästyy vielä. Tällä kertaa ihan ymmärrettävästä syystä. Se ei vain ole vielä valmis, ei ehdi, ja muutokset ovat merkittäviä.

Mutta käytännössä siis mennään Java 8:lla vielä tovi, ja aikaa on oppia mikä kaikki muuttuu Java 9 myötä. Tämä viimeisin lykkäys ei ole kuin 4kk lykkäys, ja toki nyt jo saatavana olevat EA buildit ovat varsin pitkällä. Mutta kun corea sorkitaan, pienikin muutos on iso muutos ja vaatii aikaa ja rakkautta. 😉

Tieto ei ole toki vielä vahvistettua, mutta lykkäystä on ehdotettu, ja ehdotus menenee läpi koska valmista ei vain tule aiemmalla aikataululla.

Lähde: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html

JavaOne 2016 häämöttää

Viikko vielä aikaa JavaOne seminaariin – viikon päästä paikallista aikaa sunnuntaina olen paikan päällä San Franciscossa, pää pyörällä jetlagista ja sessioista, absorboimassa kaiken tiedon ja vaikutelmat mitä saatavilla on. Pitäisi olla mielenkiintoinen viikko tulossa.

Yli neljästäsadasta sessiosta on jotakuinkin mahdotonta valita edes suurin osa mikä kiinnostaa. Itse priorisoin Java 9 asioita, Docker ja Microservices asioita, ja sitten hiukan Java EE 8 puolta myös. Voisin löydä vetoa että sitä valaistaan muutenkin keynoteissa. Ohjelman ulkopuolella on myös muutama kiinnostava yhteisötapaaminen ja keskustelu luvassa, ja tietenkin yritän bongata mahdollisimman paljon suomalaisia Javastajia.

 

 

Nyt olisi tarkoitus bloggailla paikan päältä päivittäin jotain pientä, vaikutelmia ja highlighteja. Blogaus tapahtuu tällä kertaa englanniksi, Solitan dev-blogin puolella, eli sitä kannattaa pitää silmällä. Sitä kannattaa muutenkin pitää toki silmällä – raudankovaa settiä tulossa usealta muultakin kirjoittajalta taas lähiaikoina:

http://dev.solita.fi/

 

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