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

 

 

Mainokset

Angular 2 aloitusopas

Jep, lupailin kirjailla jossain vaiheessa vähän Angular kakkosesta lisää, ja nyt on jossain vaiheessa. Alkuvaikutelmat hyvin positiiviset. En lähde vertailemaan Reactiin, molemmat oikein hyviä tekkialustoja, samoin Aurelia, mutta Angular ykkösen hakkaa iisisti kaikki kolme.

Ensiksi projekti pystyyn: Node ja NPM

Miten kannattaa aloitella? Itse sekoittelen Angularia useimmiten Java-pohjaisiin ratkaisuihin, joskus Nodeen. Joka tapauksessa, homma alkaa Java-puolella Maven Eirslett plugarilla joka varmistaa että kun Jenkins päräyttää buildin, buildikoneesta löytyy projekti-paikallisena asennettuna Node 5.3 ja npm. Paikallisena siksi että sama Jenkins voi tarvittaessa vedellä eri buildiversioita, ja on helppoa kokeilla voiko uuteen päivittää ilman oireita tms. Eirslett konffa tällä hetkellä Mavenin pom.xml:ssä näyttää tältä:

<plugin>
  <groupId>com.github.eirslett</groupId>
  <artifactId>frontend-maven-plugin</artifactId>
  <version>0.0.26</version>
  <executions>
    <execution>
      <id>install node and npm</id>
      <goals>
        <goal>install-node-and-npm</goal>
      </goals>
      <configuration>
        <nodeVersion>v5.3.0</nodeVersion>
        <npmVersion>3.3.6</npmVersion>
      </configuration>
    </execution>
    <execution>
      <id>npm install</id>
      <goals>
        <goal>npm</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Sitten kirjastot kasaan

No niin, ajat mvn package tai asentelet noden ihan vain nvm:llä taikka käsin, ja siitä se lähtee. Angular kakkosen kanssa en käytä enää Boweria, se on muutenkin mennyt vähän suosiosta. En ole vielä törmännyt juttuun johon ei npm riitä. Asiaa helpottaa, että Angular kakkoselle ei ole vielä niin paljoa sisältöä, ja saa varautua pioneerihengessä vähän rakentelemaan itse melko karuista komponenteista. Joka tapauksessa, tuikataan package.json pystyyn esim. tähän tapaan:

npm init
npm install --save angular2 es6-promise es6-shim@0.33.3 reflect-metadata@0.1.2 rxjs@5.0.0-beta.0 zone.js systemjs

Noilla pääsee alkuun. Toki angular2 riittäisi, mutta nykyisellään näkee kaipaavan pari lisäkirjastoa kaverikseen, liittyen ES6 tukipalveluihin ja vanhojen selainten tukeen. Nykyisellään Angular2 on vähän versiotarkka, siksi versionumerot yllä – korjaantunee rennommaksi jahka päästään irti betasta. Laitetaan myös pari työkalua buildaukseen:

npm install --save-dev concurrently lite-server typescript

Angular 2 on vahvasti suuntautunut TypeScriptin suuntaan – toki sallitaan myös JavaScript, mutta TypeScript on ihanaa! Joten lähdetään alkuun rakentamalla pari asiaa.

Hakemistorakenne ja tiedostot

Tarvitaan perinteinen index.html, bootstrap, sekä ainakin yksi komponentti. Eli tehdään ihan angular2 tutorialin mukainen hakemistorakenne:

touch index.html
mkdir app
touch app/app.component.ts
touch app/boot.ts

Ensin index.html – sinne tarvitaan perus sivurakenne, sekä kirjastojen lataus. Jostain syystä wordpress tänään nikottelee reippaasti eikä anna laittaa tähän kohtaan koko sivua edes pre-tagien avulla. Joten selitän mitä tarvitaan. Otetaan pohjaksi normaali HTML sivu:

<html>
 <head>
 <title>Blogautus</title>
 </head>
 <body>
 <my-app>Loading...</my-app>
 </body>
</html>

Tähän tarvitaan muutama script-tagi. Ensin head-tagien välissä lataa seuraavat kirjastot script-tagein:

node_modules/angular2/bundles/angular2-polyfills.js
node_modules/systemjs/dist/system.src.js
node_modules/rxjs/bundles/Rx.js
node_modules/angular2/bundles/angular2.dev.js

Sitten laitetaan Angular2 bootstrap kohta, myös script-tagien väliin:

 System.config({
   packages: { 
   app: {
     format: 'register',
     defaultExtension: 'js'
   }
 }
 });
 System.import('app/boot')
   .then(null, console.error.bind(console));

Ja lisäile vapaasti kaikki muu mitä haluat. Sivulla ladataan tässä vaiheessa kaikki scriptit, sitten homma käynnistyy app-kansion boot-moduulista, mitä ikinä tekeekään. Tässä tapauksessa potkaisee ensimmäisen, my-app komponentin käyntiin, näin:

import {bootstrap} from 'angular2/platform/browser'
import {AppComponent} from './app.component'
bootstrap(AppComponent);

Siinä oli siis boot.ts tiedosto. Angular2 pohjautuu ES6 malliin ja tuo sieltä hyviä piirteitä mukaan, kuten esim. moduulit. Bootstrap koodi ottaa käyttöön Angular2 bootstrap funktion, ja lataa app-kansiosta component moduulin, ja käynnistää sen. Siitä käynnistyy kaikki muu. Component.ts tiedosto voi näyttää vaikkapa tältä:

import {Component} from 'angular2/core';
@Component({
 selector: 'my-app',
 template: '<h1>Blogautus</h1>'
})
export class AppComponent { }

Tätä  on ehkä jo helpompaa seurata aiemman pohjalta. Käyttöön Component niminen kapistus, jota Angularissa kutsutaan decoratoriksi, mutta muistuttaa myös muiden kielten annotaatiota/metadataa. Tässä tapauksessa on tyhjä komponenttiluokka, johon decorator lisää metadataa kuten komponentin tag-koodin (selector), ja template-osion, jossa on komponentin generoima koodi. Komponenttiluokka itse on tässä tyhjä koska ei ole vielä tilaa eikä funktioita.

Angular ykkösen kanssa puuhastelleet saattavat huomata että tämähän muistuttaa jollain lailla direktiiviä – ja se on totta. Mutta angular ykkösen direktiivi oli aikamoinen hirvitys jota useimmat käyttivät väärin. Angular kakkosen komponentti on lähtökohdiltaan yksinkertainen ja helpommin käytettävä.

Tässä voi myös huomata että jos template-osio on pidempi, voidaan käyttää sensijaan templateUrl-parametria, ja hakea template erillisestä tiedostosta. Tähän ei kuitenkaan kannata haksahtaa – IT’S A TRAP! Suurikokoinen template on nimittäin Code Smells-kohta – oiretta siitä että komponentti kannattaisi rikkoa alikomponenteiksi. Tämä on nimittäin Angular kakkosen yksi parhaista oivalluksista – ja muistuttaa paljon React ajattelutapaa. Sivu on komponentti, joka koostuu komponenteista, jotka koostuvat komponenteista, jotka ovat kaikki uudelleenkäytettäviä, testattavia, ja pieni.

Buildaus ja ajaminen

No niin, mitä tarvitaan että tämän voi pistää prosessoiden ja ajaen? Ensin tarvitaan typescript konfiguraatio ja käännös, esim. näin:

node_modules/.bin/tsc --init
node_modules/.bin/tsc

Ensimmäinen luo tsconfig.json tiedoston, jota voit editoida halusi mukaan. Se määrittää miten typescriptiä prosessoidaan Javascriptiksi. Toinen kääntää koodit. Voi olla että haluat muokata vähän tsconfig.json tiedostoa, tässä versio mitä angular tutorial käyttää:

{
 "compilerOptions": {
 "target": "ES5",
 "module": "system",
 "moduleResolution": "node",
 "sourceMap": true,
 "emitDecoratorMetadata": true,
 "experimentalDecorators": true,
 "removeComments": false,
 "noImplicitAny": false
 },
 "exclude": [
 "node_modules"
 ]
}

Alunperäinen tiedosto generoi ES3 tasoista kamaa, ja laittoi ne built-kansion alle. Nyt jos ajat tsc-kääntäjän uudestaan, tulee vähän modernimpaa tavaraa, samoihin kansioihin .ts alle. Joka ei ole hyvä, mutta palataan siihen myöhemmin. Se on nyt aluksi helppo. Voit poistaa built-kansion.

Mitäs vielä? Olisi kiva varmaan ajaa ja testata koodia vähän. Se onnistuu ajamalla:

node_modules/.bin/lite-server

Kevyt testiserveri käynnistyy porttiin 3000 ja avaa selaimen näyttämään mitä sieltä löytyy.

Screenshot 2016-01-17 20.59.28.png

Jep, ei ole vielä kovin kummoinen, mutta on se alku. Angular tutorialin tapaan voit vielä laittaa kääntämisen ja ajamisen fiksummin package.jsoniin npm taskeiksi, tähän tapaan:

 "scripts": {
  "tsc": "tsc",
  "tsc:w": "tsc -w",
  "lite": "lite-server",
  "start": "concurrent \"npm run tsc:w\" \"npm run lite\" "
 }

Tässä tulee käyttöön concurrent-moduuli, joka ajaa rinnakkain kahta taskia. tsc -w valvoo muutoksia kansioihin ja uudelleekääntää muuttuneet tiedostot. lite-serveri valvoo koodia ja virkistää selaimen kun käännetyt koodit ovat muuttuneet. Voit ajaa tässä kehitysmoodissa komennolla:

npm start

Kokeile vaikka! Tämä on jo aika päheä setti, mutta toisaalta vain ensi osa Angular2 omissa tutorialeissa – ehkä hiukan eri vinkkelistä selitettynä vain. Mutta se on hyvä alku ponnistaa, ja ajattelin kirjailla jatkossa lisää esim. testauksesta ja webpack käytöstä Angular2 kanssa. Saatan myös avautua siitä miksi TypeScript on ihanampaa kuin JavaScript, ja miten homma pelittää vanhemmissa selaimissa.

Oma mielipide siis on ytimekkäästi:

+++Angular2
+++Node5 ja npm
+++Webpack
+++Typescript

Lue myös: https://angular.io/docs/ts/latest/quickstart.html

 

 

 

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^*

 

 

Internet of Messed-Up Things

Kirjailin taannoin kokeiluista mitä tein GoPiGo botilla. Viikonloppuna tuli firman bileissä filosofoitua taas kerran kaikenlaisista älyhärveleistä, niistä jotka lentävät, ja niistä jotka huristavat maata myöden. Vaikka dronet ovat juuri nyt pop, perinteiset maata pitkin mönkivät botit ovat helpompia (ja halvempia) kokeiluun ja opiskeluun.

2015-07-05 17.27.22

Minä tekäisin aikanaan nodejs:llä karun komentoliittymän gopigo-softan ja raspberry pi-ympäristön päälle. Siinä on websocket serverikomponentti, joka ottaa yksinkertaisia käskyjä vastaan ja välittää ne servoille ja moottoreille – ja vastavuoroisesti antaa takaisin mittatietoa. Sitten siinä on ugly as hell-tyyppinen poc-käyttöliittymä, joka on koodattu html-sivun sisään. Nodejs serveri käynnistää molemmat, ja kun tähän ottaa yhteyttä esim. kännykällä, hupi voi alkaa. Tosiaan toistaiseksi botin suurin saavutus on kiusata perheen koiraa ja vierailevia kissoja.

2015-07-01 22.21.13

Ajattelin kuitenkin avata tämän vähäisen näperryksen jos joku on myös kiinnostunut vastaavista. Valitsin noden pohjaksi juuri nopean ja joustavan kokeilun vuoksi. index.js tiedosto käynnistää yhteyden gopigo kerrokseen, ja potkaisee käyntiin pienen websocket sekä web serverin porttiin 3000, ja lataa index.html sivun. Se on verkkainen mutta riittävän nopea, jos haluaa turboahtaa lisää voi käytellä pi v2 myllyjä. Itselläni sattui juuri olemaan ylimääräinen 1st gen Pi tähän kokeiluun, kakkosgeneraatiolla on ylväämpiä tehtäviä 😉

Screenshot 2015-09-11 19.27.32

Jeah, ux suunnittelua mahdollisesti voisi vielä viedä pidemmälle. Kokeile kännykässä niin huomaat sen 😉

No niin, pidemmittä puheitta: https://github.com/crystoll/gopigo

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

Sosiaaliturvatunnuksen tarkistus Angular-direktiivillä

Jep, tuli tarpeeseen ihmetellä Angularin direktiivejä ja validointia – miten sosiaaliturvatunnuksen oikeellisuus validoidaan? Tähän ei löytynyt pikaisella haulla valmista ratkaisua joten ei muuta kuin tekemään oma.

Suomalaista sosiaaliturvatunnusta kun ihmetellään, niin osan tarkistuksista voi hoitaa ihan olemassaolevilla direktiiveillä. Esim. pituus tasan 11 merkkiä, aina. Tunnuksen muodon osalta voi olettaa siinä olevan numeroita ensin kuusi, sitten välimerkki jossa on muuutamia mahdollisuuksia, sitten kolme numeroa, ja tarkistuskoodi joka voi olla numero tai kirjain tietystä valikoimasta. Tämä hoituu komeasti esim. Angularin regex-patternilla.

Mutta syy miksi kirjoitan tätä blogia itselleni muistiin on nimenomaan tuon viimeisen merkin tarkistussumman laskeminen, ja oman custom validation direktiivin teko. Se menee nimittäin näin:

(function() {
  angular.module('app').directive('validSsn', validSSN);

  validSSN.$inject = ['$log'];

  function validSSN($log) {
    var checksumChars = 'abcdefhjklmnprstuvwxy';

    var validateSSN = function(value) {
      if (value === undefined || value.length != 11) {
        return false;
      }
      var datePart = value.substr(0, 6);
      var individualNumber = value.substr(7, 3);
      var checkSumCharacter = value.substr(10).toLowerCase();
      var dividedValueModulo = parseInt(
          String(datePart) + String(individualNumber)) % 31;
      var expected;
      if (dividedValueModulo < 10) {
        expected = String(dividedValueModulo);
      } else {
        expected = checksumChars.charAt(dividedValueModulo - 10);
      }
      if (checkSumCharacter === expected) {
        return true;
      } else {
        $log.debug('Expected checksum ', expected,
          ', got checksum ', checkSumCharacter);
        return false;
      }
    };

    return {
      restrict: 'A',
      require: 'ngModel',
      link: function(scope, elem, attr, ctrl) {
        ctrl.$parsers.unshift(function(value) {
          var valid = validateSSN(value);
          ctrl.$setValidity('valid-ssn', valid);
          return value;
        });

        ctrl.$formatters.unshift(function(value) {
          var valid = validateSSN(value);
          ctrl.$setValidity('valid-ssn', valid);
          return value;
        });

      }
    };
  }
}());

No niin, tuossa on vielä paljonkin siistittävää ja optimoitavaa, mutta jätetään se itsekunkin omaksi harjoitukseksi. Idea käy silti ilmi. Katsotaan ensin että arvo on olemassa ja oikean mittainen – ellei, se automaattisti ei läpäise validointia. Jos mitta on oikea, otetaan kaikki data-osan numerot, 9 kappaletta, merkkijonona, ja jaetaan alkuluvulla 31. Jakojäännös kiinnostaa – jos se on alle 10 se on suoraan tarkistuskoodi, jos se on 10 tai yli, verrataan kirjaintaulukkoon josta on muutama kirjain selvyyden vuoksi poistettu.

Sitä voi testata esim. näin:

it('should pass validation with valid ssn', function() {

  var element =
        $compile(
          '<form name="form">' +
            '<input valid-ssn name="ssn" ng-model="value" />' +
          '</form>')($rootScope);
  var form = $rootScope.form;

  $rootScope.value = '140785-940X';
  $rootScope.$digest();
  expect(form.ssn.$valid).toBeTruthy();

  $rootScope.value = '140785-940x';
  $rootScope.$digest();
  expect(form.ssn.$valid).toBeTruthy();

  $rootScope.value = '140785-9143';
  $rootScope.$digest();
  expect(form.ssn.$valid).toBeTruthy();

});

Tällaista tällä kertaa. Jos hommaa haluaisi vielä kehittää. voi toki tarkistaa että päivämäärä on oikea, sukupuoli vastaa muualla annettua tietoa, if any, jne.