Programming in Scala vastaan Programming Scala

Luin yleisestä mielenkiinnosta molemmat toimistolla olevat Scala-kirjat [1]. Ne ovat Programming in Scala (Odersky, Spoon, Venners) ja Programming Scala (Wampler, Payne). Nimet ovat hämäävän samankaltaiset, toisaalta tämänlaisessa tietokirjallisuudessa näin vain käy. Ensimmäisen kirjoittajista yksi, Martin Odersky, on Scalan pääasiallinen suunnittelija ja liikkeellepaneva voima.

Lyhyesti, Oderskyn et. al. Programming in Scala on minulle olennaisesti sopivampi kirja. Syyt ovat monimutkaiset.

Molemmissa kirjoissa on itse asiassa sama sisältö korkealla tasolla tarkasteltuna. Odersky on hieman paksumpi, mutta tyyli on niin paljon monisanaisempaa, ettei tästä seuraa yhtään sen suurempaa asiamäärää.

Myös kirjojen rakenne on samanlainen: ensin kerrotaan miten saadaan koneelle käännösympäristö, sitten parinkymmenen sivun nopea kielen läpikäynti, kolmanneksi (suurimman osan kirjasta käsittävä) perusteellinen kielten ominaisuuksien käsittely, ja lopuksi valikoima kirjastomaisempia ominaisuuksia ja pohdintaa liittymistä erilaisiin Java-frameworkeihin.

Tuntuva ero syntyy siitä, että Oderskyä on miellyttävä lukea, ja Wampleria ei. Kirjojen vaatima keskittyminen on luonteeltaan täysin erilainen. Odersky vie flow-tilaan, Wampleria joutuu pureskelemaan samalla tavalla kuin lakimiehen kirjoittamaa sopimusta. Tämän seurauksena Wampleria jaksaa lukea korkeintaan kymmenen minuuttia kerrallaan, kun taas Oderskyn voi lukea kerralla läpi, vaikka siihen meneekin koko päivä.

Tätä vertailua tehdessä tulikin vasta mieleen kuinka tärkeä tekstin tyyli on myös tietokirjallisuudessa. Jos tyylin käsittely vaatii lukijalta työtä, se on pois substanssin käsittelystä, mikäli substanssi vaatii aivotyötä. Ja sitä se vaatii, jos kyseessä on esimerkiksi uuden ohjelmointikielen opettelu.

Pidän kuitenkin täysin mahdollisena, että joku toinen lukija saattaa kokea näiden kirjojen luettavuuden täsmälleen päinvastaisena. Tämä lukija tulee silloin juuri päinvastaiseen lopputulokseen kirjojen paremmuudesta, koska sisällöllisesti teokset ovat kutakuinkin samanarvoiset.

[1] Scala on Java-bytekoodiksi kääntävä kohtuullisen hyvin Java-kirjastojen kanssa interoperoiva ohjelmistokehityksen vakavasti ottaville ohjelmoijille suunnattu ohjelmointikieli.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Hiljaa virtaa Amazon

Amazonin Web Services -osasto on syksyn aikana julkaissut paljon uutta ja mielenkiintoista tavaraa. Muutokset lisäävät EC2- että S3 -palveluiden houkuttavuutta reilusti.

Syyskuussa Amazon esitteli uuden mikroinstanssityypin. Ne ovat pienitehoisia, mutta naurettavan halpoja. Tunnin kapasiteettisiivun saa noin neljäsosalla small-instanssin hinnasta eli parilla sentillä tunnilta. Kuukauden yhtäjaksoinen käyttö maksaa reilun kympin. Vääntöä löytyy noin kolmannes small-instanssiin verrattuna, minkä lisäksi mikroja saa myös 64-bittisinä.

Mikrot vääntyvät luontevasti esimerkiksi kuormitustestaajiksi: Bees With Machine Guns.

Erityisen mielenkiintoisiksi mikroinstanssit tulevat uusille asiakkaille suunnatun ilmaiskampanjan myötä. Marraskuun alusta alkaen uudet asiakkaat saavat jokaisesta AWS-palvelusta tuntuvan läjän ilmaisnäytteitä:

  • 750 tuntia / kk mikroinstanssia (eli käytännössä yksi ilmainen instanssi!)
  • 10 gigatavua EBS-tilaa
  • 5 gigatavua S3-tilaa ja 20 000 hakua / kk
  • ja muuta SQS:lle, SNS:lle, SimpleDB:lle, yms.

Jos tilaat joululahjakirjasi Amazonilta, niin naksuta samalla itsellesi ilmainen pilvipalvelin. Laskutustiedotkin menevät kätevästi yhdellä kertaa.

Se tietojenkäsittelystä. Seuraavaksi niiden siirtoa ja säilytystä: S3 ja CloudFront.

Edellä mainitun ilmaiskampanjan lisäksi Amazon laski S3:n hinnoittelua hieman ja laski volyymihinnoittelun alarajaa.

S3 sai myös juuri kyvyn vastaanottaa tiedostoja useammassa osassa. Tätä on kerran jos toisenkin toivottu. Viimeeksi vasta tällä viikolla jouduimme asiakkaalle toteamaan, ettei S3 nykyisellään tähän taivu. Tilanne muuttui seuraavana päivänä.

Lähetettävän tiedoston voi pilkkoa ziljardiin palaan ja siirtää ihan missä järjestyksessä haluaa. Rinnan, sarjassa, viikon välein, etuperin, takaperin… S3 ei välitä. Siirto täytyy kuitenkin muistaa erikseen merkitä valmiiksi tai peruutetuksi. Hinnoittelun osalta huomautan vielä, että laskutus lähtee käyntiin ensimmäisestä palasta ja jatkuu osittaistenkin tiedostojen osalta siirron peruuttamiseen asti.

Olen tähän saakka käyttänyt CloudFrontista kuvausta “S3:n päälle rakennettu semi-CDN”. Vaan näin se maailma muuttuu. CloudFront heitti tällä viikolla “public beta”-viitan harteiltaan ja irroittautui S3:sta. Nyt voit käyttää myös omia palvelimiasi origin-palvelimina. Oman palvelimen käytöstä ei tule mitään lisäkuluja. Samalla Amazon takaa CF:lle 99.9% tavoitettavuuden.

Tekniset detailit oman palvelimen käytöstä löytyvät dokumentaation liitteestä.

Tämän artikkelin on kirjoittanut Antti Rasinen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Ohjelmistoprojektin säilyttäminen ehjänä yhteisessä kehitystyössä

Suurempia ohjelmistoprojekteja kehitetään yleensä ryhmissä, joihin kuuluu useita kehittäjiä. Jokainen kehittäjä tekee jatkuvia muutoksia ja lisäyksiä lähdekoodiin, jotka integroidaan jollakin versionhallintajärjestelmällä kuten esim. Git tai Subversion. Tavallinen ongelma tällaisissa järjestelyissä on, että muutokset usein sisältävät erilaisia virheitä, jotka väliaikaisesti ns. hajottavat kehityksessä olevan ohjelmiston – saattavat sen tilaan, jossa sitä ei pysty käyttämään osittain tai kokonaan.

Tällaiset tilanteet ovat tuhoisia kehittäjien tuottavuudelle: kaikki ryhmän jäsenet joutuvat joko osallistumaan virheen etsimiseen ja korjaamiseen, tai ottamaan tauon kunnes virhe on korjattu jonkun muun kehittäjän toimesta. Epävarmuutta tilanteessa lisää usein myös se, ettei ole selvä kenen aiheuttama virhe on ja sikäli kenen vastuulla sen korjaaminen ensi kädessä on. Pahassa tapauksessa virheen aiheuttaja – ja todennäköisesti paras korjaaja – on jo ehtinyt lähteä paikalta, ja palaa ehkä vasta tuntien tai päivien kuluttua. Hankalan virheen etsintään voi tällöin mennä runsaasti aikaa muilta ryhmän jäseniltä. Lyhyesti sanoen: nämä virheet aiheuttavat tuskaa ja madaltavat ryhmän tuottavuutta.

Viime vuosina yksikkötestaus, hajautetut versionhallintajärjestelmät ja jatkuva integraatio ovat nousseet yhä enemmän suosioon. Yksittäin näillä työkaluilla ja menetelmillä on oma arvonsa, mutta niitä voi myös yhdistää saavuttaakseen yhä enemmän hyötyjä ohjelmistokehityksessä. Yksi tällainen esimerkki on versionhallintasäiliö, joka hylkää muutokset, jotka eivät läpäise ohjelmistoprojektin yksikkötestejä. Olettaen, että yksikkötesteillä on hyvä kate, kehittäjä ei yksinkertaisesta vahingosta tai tahallaankaan saa levitettyä virheellisiä muutoksia muille kehittäjille. Tämä johtuu siitä, että tällainen versionhallintasäiliö hylkää ja siten ei integroi muille jaettavaan lähdekoodiin virheellisiä muutoksia, mikä vuorossaan johtaa siihen, että muut kehittäjät ovat suojautuneet virheellisiltä muutoksilta. Ja mitä suurempi ryhmä, sitä suuremmat hyödyt tästä suojasta.

Virheellisiä muutoksia hylkäävät versionhallintajärjestelmien viritykset näyttävät kuitenkin olevan vasta kehityksen alussa. Esimerkkejä tosimaailmasta löytyy muun muassa Jane Street Capitalin blogista, jossa kerrotaan miten OCaml-lähdekoodi suojataan versionhallintasäiliössä automaattisilla yksikkötesteillä. Tämänkaltaisia ominaisuuksia kaupallisissa tuotteissa on ainakin TeamCityn pre-tested commit. Avoimen lähdekoodin projektissa Hudson vasta suunnitellaan pre-tested commit -ominaisuutta. Enemmän tällaisen menetelmän hyödyntämistä ja varsinkin enemmän valmistuotteita tähän tarpeeseen toivotaan kuitenkin. Kerrothan kirjoituksen kommenteissa jos itselläsi on kokemusta asiasta!

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.