Kulkurin valssi

Pojat kylillä ovat viime aikoina kehuneet Vagrant-työkalua vuolaasti. Kuulemma parantaa kehitystehokkuutta. Kuulemma se myöskin suoraviivaistaa päivittäistä toimintaa. Ja ennen kaikkea Vagrantin ahkera käyttö palauttaa mielenrauhan. Kovia väitteitä, enkä usko ennen kuin itse nään. Siispä kokeilemaan.

Raakasti yksinkertaistaen Vagrant automatisoi Oraclen VirtualBoxin toiminnallisuutta. Tähän päälle tulee paketoitava konfiguraatio, automaattinen provisiointi sekä nippu kehittäjäystävällisiä ominaisuuksia. Vagrant on suunnattu pääasiassa kehitys- ja testaustiimien käyttöön.

Ensimmäisellä vilkaisulla suhtauduin Vagrantiin vähätellen. Kyllähän minä, sormistani näppärä insinööri, osaan itse tehdä virtuaalikoneeni. Toisella vilkaisulla neuronini alkoivat tunnistaa työkalun etuja. Automatisointi vähentää virheitä ja parantaa toistettavuutta. Paketointi taas mahdollistaa konfiguraation tallentamisen versionhallintaan. Provisioinnilla saan helposti systeemin haluamaani tilaan— jälleen automaattisesti! Kolmas vilkaisu jatkui neljäntenä ja viidentenä ja…

Kehittäjähattu päähän

Mitä paremmin kehitys- ja testausympäristöt vastaavat tuotantoa, sitä parempi. Ideaalisessa maailmassa “toimii mun koneella” tarkoittaisi sitä, että se toimisi myös tuotannossa. Virtuaalikoneet ovat kaventaneet tätä kuilua, mutteivät kokonaan. Tuotantoympäristöt koostuvat useasta erikoistuneesta palvelimista. Yksittäinen virtuaalikone on yksinäinen.

Vagrant helpottaa asiaa kahdella tavalla. Se vähentää uusien virtuaalikoneiden luomiseen liittyvää kitkaa merkittävästi. Uudet koneet voi speksata kuin pitsatilauksen: “Yksi Ubuntuano, mutta ilman sieniä ja laita sinne yks MySQL ja Munin”.

Vaan entäs jos haluaisin saada kokonaisen ympäristön pystyyn? Vaikka yksittäisiä koneita olisi miten helppoa tahansa käynnistää, laajempien järjestelmien monimutkaisuus kasvaa koneiden määrän kasvaessa. Tämä osuu suoraan siihen, missä mielestäni Vagrantin suurin potentiaali piilee.

Vagrantilla voi määritellä myös useammasta virtuaalikoneesta koostuvia ympäristöjä, joiden käynnistys ja alasajo sujuvat samalla vaivalla kuin yksittäistenkin koneiden. Saan siis pienellä vaivalla pystyyn tuotanto-olosuhteita vastaavan hajautetun ympäristön. Tähänkin ominaisuuteen pätevät samat attribuutit mitä yllä jo kehuin. Toistettava. Versioitava. Automatisoitu. Kuolleen projektin koko ympäristön saa Lasaruksen lailla takaisin henkiin.

Nipotettavaa

Idea on hyvä ja potentiaalia on valtavasti. Mutta. MUTTA. Laitan nipottajalasit silmilleni.

Vagrant on nuori projekti. Versio 0.1 tuli ulos vasta viime vuoden maaliskuussa; tuorein versio 0.7 julkaistiin tammikuussa hieman uuden VirtualBox-julkaisun jälkeen. Edelläkävijät joutuvat siis jälleen elämään epävakauksien ja suoranaisten bugien kanssa.

Tuettu työkaluvalikoima on vielä hyvin rajattu. Vagrant saattaa sitoa käsiäsi teknologioihin ja työkaluihin, joita et halua käyttää. Virtualisointiin on käytössä vain VirtualBox. Provisiointityökaluina tarjolla on Chef ja Puppet. Ja koko paketti on toistaiseksi hyvin Unix-only.

Julkisesti tarjolla virtuaalikonepohjia ei ole hirveästi tarjolla. Hyllyltä löytyy suunnilleen vain Ubuntua ja 32-bittistä Debiania.

Myös itse komentorivityökalu loukkaa esteettistä tajuani. Se yhdistää saman komennon alle sekä systeemitason komennot että yksittäistä virtuaalikonetta koskevat komennot.

Nämä miinukset kuitenkin koskevat vain toteutusta. Itse idea — paketoitu virtuaaliympäristö — on niin  hedelmällinen, että jokin sen ympärille rakennetuista toteutuksista tulee olemaan muutaman vuoden sisällä vakiotyökalu. Hyvä ratkaisu tähän ongelmaan palkittaneen runsaasti. Samaan kun saisi vielä ympättyä saumattoman ympäristöjen siirron esimerkiksi Amazonin pilveen…

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

Miksi C:llä on kivempi koodata

Viime aikoina on tullut työstettyä kahtakin projektia, joissa edes jokin osa kehitystyöstä on C:llä kirjoitetun komponentin muokkaamista. Ei ehkä aivan sattumalta molemmissa tapauksissa päädyin olemaan se kehittäjä, joka tämän tehtävän saa. Vaikka projektien substanssit olivat kovin erilaiset, molemmissa tapauksissa silmään oikein erityisesti pisti, että C:llä on oikeastaan kivempaa koodata kuin esimerkiksi Javalla tai Pythonilla. Jäin välittömästi miettimään mistä ihmeestä tämä voi johtua.

Yleisestihän on hyväksytty, enkä sitä aio kiistää, että nykyaikoina käytettävistä ohjelmointikielistä C on ehkä se fossiilisin jäänne, ja sillä minkään substantiaalisen toiminnallisuuden aikaansaaminen on kaikkein hitainta. Kaiken mahdollisen joutuu tekemään itse. Vaikkei tekisikään kaikkea itse, vaan käyttää jotakin kirjastoa sen tekemiseen (ja nykyään on hyvälaatuisia C-kirjastoja asioiden tekemiseen, verrattuna tilanteeseen esim. 20 vuotta sitten), pelkästään niiden kirjastojen käyttäminen on C:ssä tavattoman verböösiä. Erityisesti poikkeusten puute johtaa tuotantolaatuisen C-koodin tilaan, jossa puolet koodista on virheenkäsittelyä varten. Tämä aiheuttaakin jo kerrannaisvaikutuksen, kun pöhöttynyt ohjelmakoodi on jo hitaampi lukeakin, eikä pelkästään kirjoittaa. Lukeminen voi olla nopeampaa kuin kirjoittaminen, mutta sitä tehdään koodille niin monta kertaa enemmän, että itse asiassa lukemisen vaiva usein dominoi huonojen käytäntöjen aiheuttaman sakon suuruutta, ei niinkään kirjoittamisen.

Ohjelmoijan hyvä olo taas syntyy siitä flow-tilasta, johon ohjelmoija pääsee saadessaan jotakin aikaan.

Miten siis C:llä on kivaa koodata, vaikka noin suhteellisesti ottaen ei saa kovinkaan paljon aikaan? Onko perimätiedossa vikaa?

Tavallaan on, ja tavallaan ei ole. Virhe yllä oli väittämässä, että pitäisi olla aikaansaannoksia päästäkseen flow’hun. Luulen, että kirjoitusintensiivisillä välineillä flow syntyykin pelkästään kirjoittamisen määrästä. C:llä käy niin, että käyttääkin tavanomaista suuremman osan ajastaan kirjoittamiseen yksinomaan siksi, kun kirjoittamista on niin paljon. Tämä väistämättä vähentää sitä osuutta, jossa tuijotetaan tyhmänä tyhjää ruutua ja ihmetellään.

Tyhmänä tuijottamisen määrä per aikaansaatu toiminnallisuus ei toki vähene mihinkään. Se saattaa jopa lisääntyä. Mutta tyhjänä tuijottamisen määrä per aika vähenee kyllä.

Pahinta tässä ilmiössä on se, että yhdistettynä ihmisten taipumukseen hyperboliseen diskonttaukseen moni saattaa ruveta suosimaan C:tä toteutuskielenä lyhyen tähtäimen palkintojen takia. Tämä on eduksi minulle tässä ja nyt, mutta huomista itseäni kohtaan ei kovin kohteliasta — puhumattakaan siitä kuinka epäkohtelias tällainen valinta on tiimin muita jäseniä kohtaan. Ohjelmistotuotanto nyt harvemmin on yksinäistä puurtamista. Itse asiassa kaikenlaisten tuottavuus- ja muiden hyvyysmetriikoiden soveltaminen ohjelmistotuotannossa yksilöön on vähintäänkin kyseenalaista, ja mahdollisesti vahingollista puuhaa.

Pohditaan ideaalista scrum-tiimin kokoa, seitsemää henkilöä. Oletetaan, että tiimissä on fiksu ja taitava ohjelmoija, joka ulosmittaa oman tuottavuutensa täysillä cowboy-koodaamalla. Toimintatapa aiheuttaa ajoittain harmia muille jäsenille koodin spontaanisen rikkoutumisen muodossa. Ei kovin usein, ehkä kerran viikossa jokainen tiimin jäsen ihmettelee, miksi koodin invariantit eivät säily. Selvittelyyn menee pari tuntia kultakin ja ongelma saadaan korjattua. Jos aiheuttajan tuottavuus on huonojen käytäntöjen ansiosta kaksi kertaa suurempi kuin muiden, ollaan vielä saamapuolella.

Varsinaiset ongelmat alkavat vasta siinä kohdassa, kun tiimin muutkin jäsenet rupeavat miettimään, että mitä tässä oikein mitataan. Jos professionalismi ei ole sillä tasolla, että estää huonoihin käytäntöihin vajoamisen metriikoilla pelaamisen vuoksi (erityisesti jos tuottavuusmetriikoita käytetään bonusperusteena), kuukauden päästä toinenkin jäsen päättää optimoida oman tuottavuutensa ja uhrata tiimin tuottavuuden. Lopulta käy niin, että kaikki aika tiimissä käytetään sen kanssa painimiseen, ettei vedetä samaan suuntaan.

C ohjelmointikielenä vaatii tavallista suurempaa professionalismia välttääkseen poteroitumisen. C:tä ei kielen minimalistisuuden vuoksi tyypillisesti käytetä sellaisenaan, vaan sen päällä on jos jonkinlaista kirjastoa ja kehystä sellaistenkin asioiden tekemiseen, jotka muut kielet hoitavat oletusarvoisesti. Se, että nämä eivät ole kielen standardiominaisuuksia helposti vähentää niiden tunnettuutta kehittäjien keskuudessa. Niinpä riski siitä, että matalan tason kielellä tehty koodi sisältää käytäntöjä, jotka eivät ole yleisesti ymmärrettyjä, on suurempi kuin korkean tason kielessä.

Hyvillä tiimikäytännöillä näitä riskejä voidaan toki minimoida. Tämän jutun aikana on jo varmaankin käynyt selväksi, että pidän tärkeänä tiimin jäsenten merkityksen alaspelaamista ja tiimin identiteetin nostamista. Kun koodin omistajuus on tiimillä eikä jäsenellä, voidaan pitää kiinni siitä, että myös huonommin standardoidut kehitysympäristöt standardoidaan edes tiimin sisällä. Menetelmien ei tarvitse olla formaaleja jos, ja vain jos, tiimi kokee tavoitteet yhteisiksi ja ylipäänsä on olemassa tiimin identiteetti. Seitsemän soolokoodaria samassa huoneessa ei ole tiimi, vaan katastrofi täydessä vauhdissa.

Yhä laajempien kokonaisuuksien de facto standardointi (kts. Javan ja Pythonin standardikirjastot) ja ohjelmistoprojektien suurenemisen myötä tapahtunut kehitystiimien koon kasvaminen eivät ole ole missään tapauksessa toisistaan riippumattomia tapahtumia, jotka vain ovat sattuneet tapahtumaan yhtaikaa. Modernit välineet sekä mahdollistavat että edellyttävät moderneja käytäntöjä. C:llä koodaaminen saattaa olla hauskaa, mutta se on eri asia kuin että se olisi fiksua.

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

Uusi sosialistinen ihminen

Tässä on sen verran monta kertaa tullut jo kirjoitettua jostain bisneksestä, että nyt on aika puhua Marxista.

Tiedättekö nimittäin mistä pilvessä on oikeasti kyse? Karl Marx (1818-1883) tietää, ja haluaa sen meille kertoa. Älkää kuitenkaan suotta rynnätkö lukemaan parta-Kallea, minä kerron sen nyt hänen puolestaan. Eihän kukaan Marxia oikeasti lue, en minäkään, mutta herralta saa kivoja sitaatteja.

Olin näet tiistaina Viestintäviraston “Post-pilvi-seminaarissa”, jossa taloustieteen professorit Alf Rehn ja Saara Taalas puhuivat post-modernista post-pilvestä. Ei teknologiasta, eikä edes siitä, miten sitä ostetaan, vaan miten se muuttaa yhteiskuntaa. Salakavalammin, kuin alkuun huomaammekaan.

Yhteiskuntaa määrittää se, kenen hallussa tuotantovälineet ovat. Ja sosialismissa pilvessä tuotantovälineet ovat suoraan yhteiskunnan, eli kaikkien käytössä. Esimerkkinä tästä Suomen viime viikkojen virallinen vientitoivo, Angry Birds tippui AppStoren ykkössijalta, kun 14-vuotiaan teinin tekemä fysiikkapeli ohitti sen. Tavallinen 14-vuotias pystyy näet kaikkeen mihin globaali firmakin. Globaali palvelinverkosto? Hoituu. Globaali jakeluketju? Hoituu. Taloushallinta miljoonabisnekselle? Hoituu.

Sähköverkkovertaukset voi unohtaa, tässä puhutaan nyt paljon perustavanlaatuisemmasta muutoksesta.

Muutoksen ytimessä on hallinnan menettäminen. Talousajattelumme lähtee siitä, että yritys hallitsee tiettyjä resursseja, ja tiettyjä markkinoita. Tuotteet työnnetään loppukäyttäjille, jotka sitten käyttävät niitä kiltisti. Mutta kun ei se mene niin. Tuotantoresursseja saa kilohintaan minuutissa, ja kuluttajia nyt ei hallitse enää kukaan. Fanitus ja viraalipilvet ovat kohta tuupanneet kaikki muut markkinointitavat yli laidan. Ja faneja ei kannata kuvitella ohjailevansa. Sitäpaitsi suurimman osan arvosta tuottaa joka tapauksessa verkostoefekti, ei yritys itse ensinkään.

Eikä uusi sosialistinen, äh eikun siis pilvi-ihminen ole mikään passiivinen kuluttaja, ei ehkä kuluttaja ollenkaan, vaan aktiivinen toimija, joka sekä tuottaa että kuluttaa samoja resursseja osana verkostoa, tai siis pilveä. Mathias, 5v, ei halua lähteä ostamaan Star Wars -pyssyjä kaupasta, koska paljon siistimpää on tehdä ne itse. Ei muuta kuin isä käyttämään Autocadia ja MakerBot laulamaan. Kuka sanoi, että tavarat pitäisi ostaa kaupasta, kun ne voi saada pilvestä?

Mutta miten tämä enää liittyy Codentoon, tai siihen pilveen, josta me puhumme?

No jos fanitat meitä, tuotamme yhä lisää – hmm, sisältöä – tähän merkityspilveen! Rahaa vastaan sen sijaan puhumme vähän kuivempia juttuja… Eivät ne yritystalouden realiteetit nyt ihan kokonaan ole vielä kadonneet.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Wikipedian analysointi pilvessä Amazon Elastic MapReducella

MapReduce on Googlen kehittämä laskentamalli ja ohjelmistokehys rinnakkaislaskennalle. Se mahdollistaa suurien tietomäärien helpon käsittelyn esittämällä ohjelmointimallin jonka ohjelmat ovat rinnakkaistettavia ja tarjoamalla valmiin alustan näiden rinnakkaistettavien ohjelmien suorittamiselle. Noudattamalla tätä mallia kehittäjä säästyy rinnakkaislaskennassa toistuvista päänsäryistä, ja pystyy keskittyä varsinaiseen sovellukseen. MapReduce-malliin sopivia sovelluksia ovat muun muassa suurien tietomäärien lajittelu, haku, tilastointi ja logien analysointi.

Apache Hadoop on avoimen lähdekoodin toteutus edellä mainitusta MapReduce-ohjelmistokehyksestä joka mahdollistaa oman MapReduce-klusterin pystyttämisen. Amazon Elastic MapReduce -palvelun avulla ei tarvitse edes pystyttää tai ylläpitää omaa MapReduce-klusteria: rinnakkaislaskentatehtäviä voi suorittaa välittömästi pilvessä.

Amazon Elastic MapReduce hyödyntää Apache Hadoopia, jonka streaming-moduulilla pääsee tosi nopeasti käyntiin: yhden parin rivin mapper-komponentin toteuttaminen Rubyssä tai Pythonissa riittää, ja reducer-komponentteja toistuville tarpeille löytyy valmiina kirjastosta.

Esimerkkinä rinnakkaislaskentasovelluksesta voi käyttää vaikka Wikipedian pyyntölogien analysointi. Laskenta sisältää seuraavat osat:

  • Analysoitava tieto joka tässä tapauksessa siis on Wikipedian pyyntölogit yhdeltä päivältä (päivämäärälle 2.1.2011 tiedostot pagecounts-20110102-*.gz) tallennetaan Amazonin S3-palveluun josta Amazon Elastic MapReduce sitten lukee sen laskennan alkaessa.
  • Laskennan mapper-komponentti tallennetaan Amazon S3-palveluun jotta se olisi jokaisen laskentaan osallistuvan noodin saatavissa. Pyyntölogit koostuvat riveistä joiden muoto on: [Wikipedia-projektin nimi, esim. “fi”] [sivun nimi, esim. “Suomi”] [osumat tunnin aikana, esim. “100”] [siirretyt tavut, esim. “1000000”]. Alla oleva mapper-komponentti huomioi pelkästään suomalaisen Wikipedian sivut.
    #!/usr/bin/ruby
    
    $stdin.each_line do |line|
      project, page, hits, bytes = line.split
      next if project != 'fi' or project =~ /./ or page =~ /:/
      puts "LongValueSum:#{page}t#{hits}"
    end
    
  • Laskennan reducer-komponentti jätetään oletukseksi (“aggregate”). “LongValueSum” määrittää että jokaisen Wikipedia-sivun eri pyyntölogeissa olevat osumat tulee laskea yhteen reduce-vaiheessa.
  • Laskenta käynnistetään komennolla:
    bucket=samplebucket/samplejob
    elastic-mapreduce --create --num-instances 2 
        --stream --input s3n://$bucket/input 
        --mapper s3://$bucket/mapper.rb 
        --output s3n://$bucket/output
    

Rinnakkaislaskennan tulos ilmestyy jonkun ajan kuluttua Amazon S3 -palveluun tiedostomuodossa. Laskennan tulos on lista sivuja ja vastaavat pyyntömäärät. Lajittelun jälkeen seuraavat sivut ilmenevät suosituimpina suomalaisessa Wikipediassa maanantaina 2.1.2011:

Sivu Pyyntöä
Olli_Johansson 12488
Mikko_Niskanen 5147
Idän_pikajuna 3592
James_Bond 2922
Syyskuun_11._päivän_iskut 2554
Loppiainen 2256
Charme_Asserdal 2099
Harry_Potter 2012
Suomi 1810
Idän_pikajunan_arvoitus 1694

Tässä ei ole tarkoitus sen lähempää analysoida Wikipedia-kävijöiden käyttäytymistä, mutta tuloksiin näyttää vaikuttaneen erilaiset samana päivänä näytetyt TV-ohjelmat ja viihdeuutiset.

Tässä tulee huomauttaa siitä että yhden vuorokauden Wikipedia-pyyntölogit (kooltaan noin 1 gigatavu) eivät ole vielä niin isoja että ne välttämättä vaatii rinnakkaislaskentaa MapReduce-tyyliin – laskennan voisi tehdä yhdelläkin tietokoneella. Mutta kun analysoitava data lähestyy satoja gigatavuja tai jopa teratavuja (esim. kuukauden tai vuosien pyyntölogit) rinnakkaislaskenta alkaa olla tarpeellista. Laskennan suorittaminen yhdellä tietokoneella yksinkertaisesti kestäisi liian kauan: päiviä tai jopa viikkoja. Tälläisessa tapauksessa, jos MapReduce-laskentamalli sopii ongelmaan, Amazon Elastic MapReducen hyödyntäminen on vaihtoehto jolla pääsee nopeasti liikkeelle.

Lisää tietoa kehittäjille löytyy Amazon Elastic MapReducen dokumentaatiosta.

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