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

jenv ja virtuaalikoneiden ihanuus

Olen ihastunut.

Työssäni tulee käyteltyä Javan eri versioita vieläkin, koska vaikka maailma alkaa olla Java8-valmis, vieläkin tulee vastaan ympäristöjä jotka eivät toimi kuin vanhemmilla versioilla. Toisaalta uutta on aina kiva kokeilla. Java 9 tekee tuloaan ensi vuonna, ja siitä on jo esiversiota tarjolla.

Ikuinen ongelma on ollut useamman virtuaalikoneen, saati sitten JDK version hallinnoiminen koneessa – tai edes sen pääasiallisimman valitseminen oikein jos useampi JDK on asennettuna. Homman salaisuus on alkanut JAVA_HOME ja PATH ympäristömuuttujien hyvästä hallinnasta, mutta asiaa sotkevat myös erinäiset rekisteriasetukset ja/tai symboliset linkit. Kysymys kuuluu: kun kirjoitat komentoriville

java -version

javac -version

… niin mikä sieltä vastaa? Ja onko se mitä haluat? Vai vastaako mikään?

Windows maailmasta huonoja uutisia: Windowsin rekisteriin tallettuville jämille on vaikeata tehdä mitään. Java Windowsilla, sen kanssa voi pärjätä, mutta ei se hauskaa ole. Tokkopa on tarkoituskaan olla.

Nykyisin Mac-käyttäjänä olen onneksi päässyt rekisterihelvetistä eroon. Mutta koska tälläkin alustalla problematiikkaa riittää, eksyin tutustumaan jenv-työkaluun, joka osaltaan helpottaa hommaa. Valitettavasti vaatii toimiakseen bash-valmiin käyttöjärjestemän, eritoten Mac OSX tai Ubuntu pelittää hienosti.

Jenv löytyy osoitteella http://www.jenv.be/ – ja toki myös GitHubista suoraan. Itse tuikkasin sen Maciini Homebrew:llä, kuten monet muutkin kivat jutut. Jahka se löytyy komentoriviltä, tärkeimmät komennot ovat:

jenv add /PATH/TO/VM

jenv versions

jenv shell java-version-that-i-want-to-use

Noista on paljon hyviä esimerkkejä heti pääsivulla. Toki voi myös asettaa pysyvämmin default virtuaalikoneen käyttöön, mutta esim. tuo jenv shell-komento antaa mahdollisuuden kokeilla Java 9 prereleasea turvallisesti sotkematta silti vakaampia projektejaan. Ja mikä mukavinta- toimii myös ANT ja Mavenissä suoraan.

Jenv ja JDK 9 vauhdissa

Edellämainitun lisäksi toki on monta muutakin virtuaalikone-ulottuvuutta: Mitä virtuaalikonetta selaimesi käyttää (jos käyttää), entä IDE ympäristösi? Maven? Eli ei ihan yksinkertainen asia. Hyvä kuitenkin aloittaa perusteista, eli siitä että ainakin yhdessä paikassa homma toimii juuri kuten haluat.

Toinen jenv löytyy muuten osoitteessa http://jenv.io/ – näyttäisi tukevan myös Windows hommeleita.

JSON serialisointi: Pois Circular Reference – manalasta

En tiedä onko tuttu tilanne, mutta itselleni harmillisen usein tavattu. Otetaan oliorakenne, esim. Order -> OrderItem, eli tilaus ja tilausrivejä. Rakenne menisi näin:

class Order {

  List<OrderItem> orderItems;

}

class OrderItem {}

Tähän asti kaikki loistavasti. Nyt kuitenkin on useita syitä miksi haluaisimme myös linkin OrderItemistä Order-luokkaan, esim. jos item-riveissä on assosiaatioita muuallekin ja niistä pitäisi näppärästi päästä header-tietoihin kiinni. Tai jos käyttää serialisointiin JPA-tekniikkaa eikä halua tehdä turhia välitauluja (One-to-Many assosiaatiossa tieto assosiaatiosta on many-päässä eli OrderItem luokassa)

Pysyitkö mukana? Hyvä, muutamme siis rakenteen tällaiseksi:

class Order {

  long id;
  List<OrderItem> orderItems;
}

class OrderItem {
  long id;
  Order order;
}

Ja tästä päästääkin syklisten referenssien helvettiin. Tämä on oliorakenteena ihan kelvollinen ja mahdollistaa juuri edellämainitun navigoinnin molempiin suuntiin (bidirectional one-to-many association). Tähän voisi iloisesti läpsäyttää JPA annotaatiot ja antaa sen valua kantaan ja kannasta triviaalilla koodilla.

Ongelmia tulee siinä vaiheessa kun haluttaisiin serialisoida tätä rakennetta johonkin hierarkiseen puurakenteeseen, esim. XML tai JSON. Ongelma johtuu siitä että dynaaminen sarjallistaja, esim. JAXB tai Jackson, käy läpi olion ominaisuudet yksi kerrallaan, ja kutsuu gettereitä, kerää tiedot, ja muuttaa ne tekstimuotoiseksi siirtokelpoiseksi dataksi. Siinä käy siis näin:

  1. Tallennetaan order, hienoa. Order on oliorakenne, joka sisältää orderItems listan, käydään se läpi
  2. Käsitellään jokainen orderItem vuorollaan. OrderItem on oliorakenne, joka sisältää viittauksen Order olioon
  3. Käsitellään jokainen viitattu Order vuorollaan. Order on oliorakenne joka sisältää OrderItems listan

Ja niin edelleen. Ikiliikkuja on keksitty. Tästähän saa palkakseen yleensä jonkun hienon kaatumisen ja cyclic/circlar reference errorin. Tai jos hauskasti käy, kone puuskuttaa hetken ja antaa stack overflow errorin tai out of memory errorin.

Mitä sitten on tehtävissä? Tämä artikkeli koskee JSON vaihtoehtoa, jos olet vielä XML parissa, olet pysyvästi helvetissä vailla poispääsyä, pahoittelen.

Jos käytät tätä esim. Jacksonin puitteissa, vaikkapa REST-rajapinnassa, ratkaisutapoja on muutama (tosiasiassa osa näistä sopii XML hommiinkin, jos edellisestä kohdasta tuli paha mieli):

  1. Katkaise syklinen referenssiketju merkkaamalla jommassakummassa päässä referenssi ei-serialisoitavaksi. Tapoja tähän on monia, Jackson taitaa tukea esim. Javan transient avainsanaa, @JsonIgnore annotaatiota, ja luokkatasolla voi myös listata ohitettavat kentät @JsonIgnoreProperties-annotaatiolla
  2. On myös mahdollista merkitä master-dependant suhde Jackson annotaatioilla @JsonManagedReference ja @JsonBackReference
  3. Tehdään aina value/transfer object johon normalisoidaan kulloinkin tarvittavat tiedot
  4. Myös voi merkitä identity-kentät Jackson annotaatioilla, @JsonIdentityInfo kertoo mikä kenttä on uniikki avain, jonka jälkeen serialisoinnissa voidaan viitata vain id arvoon, ei käydä läpi koko sisältöä.
  5. @JsonView annotaation käyttö näkymien muodostamiseen

Kahdessa ensimmäisessä kohdassa on yksi ongelma: Ne eivät salli talsimista edestakaisin, vaan vain yhteen suuntaan. Mutta ne ratkaisevat syklisen referenssipulman katkaisemalla rekursioketjun, eli sopivat moneen tilanteeseen. Kolmas kohta sisältää potentiaalisesti hurjan paljon virhealtista käsityötä ja myöhemmin ylläptoa ja en ole ollut koskaan kummankaan suuri fani. Neljäs kohta generoi kauheaa huttua serialisoinnista, ja en ole vielä löytänyt sille hyötykäyttöä. Neljäs kohta on näistä oma suosikkini. Se voisi olla vielä parempikin mutta sillä ainakin pääsee alkuun. Ja uusin Spring, Spring Boot, ja JAX-RS yhdistelmä tukee näitä ihanasti.

Homma toimi näin: Merkataan @JsonView annotaatiolla ne kentät, joita halutaan ehdollisesti serialisoida tai olla serialisoitamatta. Parametrina tulee tyypin nimi, joka on yleensä Java rajapinta. Esim. näin:

class View {

interface GimmeOrderRows {}

interface GimmeOrderHeader {}

}

Nyt voidaan muokata aiempia koodeja näin:

class Order {
  
  long id;
  
  @JsonView(View.GimmeOrderRows.class)
  List<OrderItem> orderItems;

}

class OrderItem {
  long id;

  @JsonView(View.GimmeOrderHeader.class)
  Order order;

}

Nyt pystyt hakemaan assosiaatiot on-demand periaatteisesti, eli voit navigoida kummasta päästä vaan. Jos et anna JsonView-annotaatiota, oletuksena saat kaiken. Heti jos annat yhdenkin @JsonView annotaation, saat kaikki kentät joihin se täsmää tai joita ei ole millään JsonView annotaatiolla varustettu. Eli jos meillä olisi tämän näköinen jax-rs palvelu…

@GET
@Path("order")
@JsonView(View.GimmeOrderRows.class)
public Order fetchOrderWithItems(long id) {
  return orderRepository.getOne(id);
}

… niin syklisen referenssin peikko pysyisi piilossa. Koska Jackson serialisoisi Orderin, ja sen sisältämät OrderItemit id-arvoineen, mutta ei seuraisi enää polkua niiden sisältämiin Order-instansseihin.

Vastaavasti nyt voisi huoletta hakea vaikkapa yhden OrderItem instanssin OrderHeadereineen ilman syklisiä referenssejä:

@GET
@Path("orderitem")
@JsonView(View.GimmeOrderHeader.class)
public OrderItem fetchOrderItemWithOrder(long id) {
  return orderItemRepository.getOne(id);
}

Samalla tekniikalla voi noutaa ehdollisesti esim. salasanatietoja, tai binäärisisältöä, tai muuten vain pitkiä kenttiä. Yhdessä kohtaa voi olla vain yksi JsonView-parametri, mutta koska niillä voi olla perintähierarkioita jotka tunnistetaan, rajoitus ei ole paha. On myös mahdollista säätää sellainen oletus, että mitään kenttää ei palauteta elleivät jsonviewt täsmää – ei myöskään niitä joista annotaatio puuttuu kokonaan.

Nyt kun vielä saisi Javaan luontevan suorastaan sisäänrakennetun JSON rajapinnan….

IoT ja Asimovin kolme lakia

Yksi asia mikä on mietityttänyt jo jonkin aikaa on Internetin otusten tietoturva, ja myös etiikka. Olen samanaikaisesti hieman innoissani tulevaisuudesta jossa asioiden älyllistyminen ja verkottuminen tuo kosolti mahdollisuuksia joita emme vielä edes täysin tajua tai osaa edes kuvitella. Toisaalta asioista tulee monimutkaisempia, ja alttiimpia väärinkäytölle. Robotiikan tehtävä on helpottaa ihmisten elämää arjessa, ja osa sitä tarkoittaa rutiinitehtävien siirtämistä koneille, tehtävien automatisointia, jossa ihminen painaa nappia ja kone tekee monimutkaisen prosessin.

P1000644

Me elämme jo robotiikan aikakaudella. Yksi elämää helpottava robotti on pyykinpesukone. Samaan voi laskea toki auton – sähköhevosen, ja onpa noita oikeita robottipölynimureitakin jo olemassa. Mikä ero on sitten nykypäivän robotiikalla ja tulevaisuuden IoT:lla? Kaksi asiaa, itsenäinen äly ja päättelykyky, ja langattomat verkot. Ensimmäisen myötä valta ja vastuu kasvaa, ja toinen voi potentiaalisesti avata reittejä vihamielisille tai ilkikurisille tahoille. On eri asia, jos mato tunkeutuu palvelinhuoneeseen ja louhii tietoja tietokannasta tai kaataa koneen ylikuormittamalla jotain sen osaa – ja taas eri asia kun pätkä ohjelmakoodia ottaa auton renkaiden ohjauksen haltuunsa – tai ruohonleikkurin – tai pelkästään kosolti voimaa omaavan hydraulisen käsivarren. Eikä edes tarvitse lähteä kehittyneisiin robotiikkaprojekteihin joita on parhailaan käynnissä pelastustarkoituksiin tai sotateollisuuden tarpeisiin – mainittakoon esim. DARPA ja Boston Dynamics projektit.

Tietoturvan osalta asia on oikeastaan helpompi. Me olemme oppineet tekemään palvelimista yltympäriinsä suojattuja  – etenkin jos niissä kulkee rahaa tai luottamuksellisia tietoja. Mikään suojaus ei ole sataprosenttinen – mutta IoT puolella on merkittävästi suojausta parannettavissa ihan soveltamalla jo opittuja periaatteita luottamuksellisuuden, autentikoinnin, autorisoinnin, ja ohjelmistopäivitysten suhteen. Hyvä muistaa myös DDoS-hyökkäykset ja niiden seuraukset suunnittelussa. Tuntuukin siltä, että kun elämme ensimmäisen sukupolven innovaatioaaltoa, nämä asiat ovat vain jotenkin unohtuneet, tai niitä ei kiireessä ehditä tehdä – ennen kuin jotain vakavampaa tapahtuu ja on pakko huomioida tietoturva. Jos selaa vuoden verran taaksepäin uutisia, löytää useitakin tarinoita laitteiden tietoturva-aukoista jotka ovat alkeellisia, helposti hyödynnettävissä, ja monesti jo hyödynnettu. Tämä alue on kuitenkin otettavissa haltuun sille joka haluaa – ja tulevaisuudessa ei ole varaa olla haluamatta.

Chuck Norris ei pelkää muistivuotoja. Muistivuodot pelkäävät Chuck Norrisia.

Mielenkiintoisempi kysymys on sitten laitteiden etiikka. Kun päätäntävaltaa siirretään ihmiseltä koneille, tulee moraalisiakin kysymyksiä vastattavaksi. Ja ennen niitä muutama harmaan alueen toiminnallinen kysymys. Ne tulevat heti mietintään kun laitetta ei käytä ihminen sormi aktiivisesti napilla. Jos auto pysäköi itsenäisesti, ja ohjelmointivirhe saa sen kolhimaan toista autoa, tai eläintä, tai ihmistä – kenen vastuulle se menee? Tämä on vielä helpomman pään kysymys. Vaikeammaksi menee kun täytyy tehdä valintoja. Itseohjautuva auto ajaa moottoritiellä satasta, ja havaitsee eläimen tiellä. Jarrutusmatka ei riitä hallittuun pysäytykseen. Säästetäänkö kaikkea elollista ja tehdään lukkojarrutus, otetaan riski että auto lähtee luisuun ja ihmishenki on vaarassa? Vai priorisoidaanko pienikin riski ihmishengelle yli kaiken muun? Tämäkin menee yhä mielenkiintoisemmaksi jos tielle astuukin yllättäen toinen ihminen. Auto on ilmiselvä esimerkki ja vaikuttaa aika tieteistarinalta – mutta parin vuoden päästä itsenäisesti pysäköivät autot ovat markkinalla, ja varmasti vuosikymmenen sisään itsenäisesti ajavat – niitä on jo muun liikenteen seassa useammassa maassa. Ollaan melko kaukana vielä keinoäly-humanoidi-roboteista, mutta itsenäistä päättelyä analogisen sensoritiedon pohjalta nopeissa tilanteissa tehdään jo nyt.

Hazelcast Lego-Pi cluster

Tämän blogautuksen otsikossa viittaankin useimpien tuntemiin Isaac Asimovin robotiikan kolmeen sääntöön, jotka tieteiskirjallisuudessa nähtiin aikanaan loogisiksi tavoiksi ratkaista näitä ongelmia: Itsenäinen päättelykyky sallitaan, mutta se rajoittuu aina kolmeen rikkomattomaan sääntöön jotka ohjelmoinissa otetaan huomioon, ja näillä pääsäännöilläkin on keskinäinen prioriteetti. Näitä sääntöjä on sittemmin lisäilty ja modifioitu, ja tokkopa näillä pärjätäänkään nykymaailmassa, mutta mielenkiintoista ajatusten ruokaa joka tapauksessa:

  • A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  • A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
  • A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

Hyvä kuitenkin muistaa että IoT ei ole vain autoja. Tulevaisuudessa tulee olemaan älykelloja, älyvaatteita, älyreppuja, äly-uuneja, älypesukoneita, älykyniä, älyvaloja, älyvedenlämmittimiä, älykameroita, älykoptereita, ja kaikkea muuta älytöntä ja ihanaa. Ja kun sanon tulevaisuudessa, tarkoitan nyt. Sitä mitä on kymmenen vuoden päästä en osaa rehellisesti edes kuvitella. Mutta äly ja verkot mahtuvat jo kaikkialle, ja ne tulevat olemaan kaikkialla mihin mielikuvitus voi ne viedä. Ja mitä tulee tietoturvaan tai älyn etiikkaan, voimme oppia nämä asiat kaikki kantapään kautta, tai yrittää kerrankin olla fiksuja jo alusta alkaen ja tehdä ne mahdollisimman oikein.

Tulevaisuutta ei voi estää – vaikka haluaisikin – sen voi vain kohdata.

Solitalla on myös meneillään Think Tank IoT-teemalla, joten jos aihe ja muut näkökulmat muutokseen kiinnostavat laajemminkin, tuosta voi navigoitua eteenpäin: http://www.solita.fi/ajankohtaista/solitan-viides-think-tank-ryhma-pureutuu-teollisen-internetin-murrokseen/

Edit: Hauskasti osuva artikkeli tähän liittyen: http://www.tekniikkatalous.fi/tekniikka/google-korjasi-robottiautojaan-osaavat-nyt-rikkoa-liikennesaantoja-6000962

NodeJS 4.0 on ulkona

Vain nopea päivitys itseä kiinnostavasta asiasta tähän väliin: NodeJS 4.0 julkaistiin tänään. Jos joku ihmettelee rajua hyppyä versionumerosta 0.12.7 tähän uuteen – kyseessä on historiallinen mergetys jossa nodejs ja iojs yhtyvät, siksi raju pomppu.

Suositusta myös sen käytöstä: Ellet jo ennestään käytä nvm versiomanageria node versioiden ajoon, hanki se! OS X:ssä esim. brew install nvm tuottaa tuloksen – jahka säädät vielä vähän lisää ohjeiden mukaan. nvm:llä voit asennella iloisesti vanhaa ja uutta rinta rinnan ja vaihtaa nopeasti kokeillaksesi. Olisin yllättynyt jos 4.0 sujahtaisi ongelmitta vanhan tilalle joka paikkaan.

Linkkivinkkejä:

https://nodejs.org/en/

https://medium.com/node-js-javascript/4-0-is-the-new-1-0-386597a3436d

http://apmblog.dynatrace.com/2015/09/05/all-you-need-to-know-about-node-js-4-0/

https://github.com/creationix/nvm

IoT: Go home PI, you’re drunk!

Internet of Things on kiehtonut omaa mieltä jo pitkään ennen kuin termi edes keksittiin: Se on pääosin se asia joka nykypäivän communicator/mobile device kategorian laitteissa ja älypuettavissakin kiehtoo. Älykkäiden verkottuneiden laitteiden mahdollisuudet ja uhat. Nyt tuli sitten aika pistää äly pyörille.

2015-07-05 17.27.22

Nykypäivänä on helpompaa kuin koskaan näperrellä ja prototypoida näiden parissa: Raspberry Pi tietokoneet ovat halpoja ja niihin saa kiinnitettyä oikeastaan mitä vain mielikuvitus loihtii. Olen itse rakennellut niihin aiemmin kokeilumielessä full stack raskasta Java EE ratkaisua, milloin MySQL kannan, milloin MongoDB:n kera ohjaamaan kodin automaatiota. Tuli kokeiltua sekin miten Glassfish sovelluspalvelin pyörähtää käyntiin: Ihan hienosti, jopa ihan ykkösgeneraation Raspissa.

Tällä kertaa halusin kokeilla jotain uutta. Muutama vuosi takaperin JavaOne seminaarissa osallistuin autokilpailuun jossa koodailtiin autoihin algoritmia jolla ne ajaisivat lujaa mutta pysyisivät radalla. Siitä jäi ajatus itämään. Hiljattain tutkin Lego Mindstorm EVO paketteja, mutta ne tuntuivat rajoittuneilta, ja kalliilta kokeiluun nähden. Niihinkin löytyy toki nykyään BrickPi-laajennus jolla voi laittaa Raspberryn käskemään EVO kontrollereita ja sensoreita. Mutta itselleni haaviin jäi GoPiGo-alusta. Moottorit, pieni kontrolleri joka kytkeytyy suoraan Pin kylkeen, virtapaketti joka toimii pattereilla ja irrottaa laitteen virtapiuhan tyranniasta. Go, Pi, Go, feel the wind in your electronic hairs! 😉

2015-07-05 17.27.05

Eli tilaukseen napsahti, ja ei kun testailemaan. GoPiGo web sitelta sai latailla valmiin imagen joka pohjautui jo tuttuun Raspbianiin, ja toimi ihan ok, kunhan viritin sen langattomaan kotiverkkoon ja kävin läpi alustusrutiinit. Sieltä löyty esimerkkejä mm. Pythonilla, Javalla, ja testailin niiden avulla että olin koonnut kaiken oikein ja piuhat olivat paikallaan. Mutta kuten sanottua, tällä kertaa oli tarkoitus tehdä jotain uutta.

Joten päädyin viritykseen, jossa ytimen muodostaa node.js palvelin. Viritin sen automaattikäynnistymään Raspin myötä. Automaattikäynnistys tapahtuu ihan init.d scripteillä, ja apuna käyttelin forever + nodemon yhdistelmää, jotta prosessi päivittää itsensä kun koodeja päivitetään, ja myös jos se sattuisi kaatumaan.

Palvelin initialisoi GoPiGo osan, ja kiinnittää pari tapahtumankuuntelijaa, mm. varoittamaan jos virta käy vähiin pattereissa. Ja lataa html-sivun jonka kautta raspia voi ohjailla. Tuossa vähän maistiaista miltä sen pään koodi näyttää:

socket.on('status', function(msg){
  $('#messages').append($('<li>').text(msg));
});
$('#forward').click(function() {
  socket.emit('command','move forward');
});
$('#backward').click(function() {
  socket.emit('command','move backward');
});

Halusin rivakkuutta ohjaukseen joten websocketeilla mennään. Tarkemmin, socket.io nykyisellä inkarnaatiolla. Käyttöliittymä on tässä kohtaa karu – pelkkää html:ää ja jquerya. Vähän kutkuttaisi päästää Aurelia irti tässä kohtaa. Käytännössä siis websocket kanavalla liikkuu kahteen suuntaan tavaraa: status viestit menevät ’status’ kanavalle, ja näytetään ’client’ päässä. Komennot lähetetään ’commands’ kanavalle, ja voivat olla esim. mene eteenpäin, pysähdy, käänny, laita ledejä päälle, jne.

Ja sehän toimii. Hienosti. Jopa ihan Android kännykästä käsin. Sillä oli kiva kiusata kissoja ja koiraa 😉

2015-07-05 17.33.55

2015-07-01 22.21.13

Mitähän hittoa tällä sitten tekee? No ei yhtikäs mitään. Mutta mielenkiintoinen harjoite taas keveiden pikku älylaitteiden maailmassa, nodejs tuntuisi olevan mukavan keveä ratkaisu tämäntapaiseen hommaan, ja Raspberry Pi tuntuu Noden kanssa tarjoavan kaikki tarpeelliset palaset että prosessin saa pyörimään luotettavasti ja itsenäisesti.

Seuraavia askelia:

– pistä UI päähän jotain fiksumpaa ja helpompaa kehitysframeworkia, esim. Aurelia.

– Kiinnitä pakkaan sensoreita, esim. mikroaaltotutka, kamera, servoja.

– Opeta robotille Asimovin kolme periaatetta ettei käy kuin Volkswagenin tehtailla

– Laita laite tuomaan kylmä olut kun se aistii sille tarpeen.

– Ja ampumaan raketteja devaajan päähän joka taas /&%/&% rikkoi sen buildin! Tässä voidaan vähän joustaa Asimov-periaatteiden kanssa.

http://www.dexterindustries.com/GoPiGo/projects/python-examples-for-the-raspberry-pi/raspberry-pi-controlled-office-cannon/

ES6: It’s a better monster!

Kirjailin taannoin Aurelia-nimisestä Javascript sovelluskehyksestä joka teki vaikutuksen. Yksi suurimpia osia miksi se kiinnosti oli helppo kyvykkyys alkaa heti käyttämään JavaScriptin/ECMAScriptin versiota 6. Se taas kiinnosti kahdesta syystä: Ensimmäinen on halu pitää nokka aina menosuuntaan: muuten putoaa helposti rattailta. Toinen on, että ES6 tarjoaa lukuisia sovelluskehittäjälle oikeasti laatua parantavia tekijöitä jahka se vain saadaan laajemmin käyttöön. Ja näin inspiroiduin kirjoittamaan vähän sen nykytilasta.

Nykyisellään selaimissa käytetään yleisimmin ECMAScript versiota 5 – tai 5.1 – ja versio 6 on ollut työnimellä Harmony työstettävänä jo jonkin aikaa. ES6 saatiin spesifikaationa viimein valmiiksi tämän vuoden toukokuussa.

Selaintuki on aina määräävä tekijä: Tätä artikkelia kirjoittaessa parhaiten ES6:sta tukee Firefox versio 40 – hurjalla 63% ominaisuustuella. Pienenä yllätyksenä kakkossijan jakavat Firefoxin versio 39 – ja Microsoftin tuleva Edge/Spartan selain joka tulee syrjäyttämään jo tammikuusta alkaen IE8-11 versiot joiden tuki lakkautetaan. Chrome ei ole ihan vielä näissä ajan tasalla – ominaisuuksia on tuettu n. 45% hujakoilla. Safarilta ja IE10/11 versioilta saati sitten vanhemmilta ei kannata näistä edes kysellä – tulee turhaan paha mieli. Ja mobiililaitteiden selaintuki on toki ihan oma lukunsa.

Onneksi on myös Babel/6to5 transpiler jota myös Aurelia käyttää – se osaa tarvittaessa kääntää ES6 syntaksia ES5 yhteensopivaksi jotta piirteet toimivat myös vanhoissa selaimissa – jep, aina pahamaiseiseen IE9:ään asti. Tämän avulla uusia piirteitä voi alkaa jo käyttelemään projekteissa joissa on tarpeen tukea laajaa selainkirjoa.

Mitä sieltä sitten löytyy? Miksi kannattaisi alkaa käyttämään ES6:sta? No siitä taidan tehdä ihan toisen artikkelin, sen verran mehukas aihe. Mutta tuossa itselle muistilistaa:

  • Vakiot (tai siis immutable muuttujat…)
  • Scope käyttö
  • Nuolifunktio (lambda syntaksi)
  • Parannukset this-avainsanaan
  • Tuki moduuleille, import/export
  • Parannukset luokkiin/objekteihin
  • Promise/Rinnakkaisuusmekanismit
  • Iteraattorit
  • Kokoelmaparannukset

Pysykäähän kuulolla…

Linkkejä:

http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf

https://kangax.github.io/compat-table/es6/