On kuitenkin joitakin palveluita, joita valitettavasti ei vielä kukaan ole ymmärtänyt myydä pilvipalveluna. Näistä yksi [...]]]> Codentolla on jo useampia vuosia ollut ajoittain intohimoisestikin ajettu tavoite olla halaamatta palvelimia. Tästä johtuen palveluita, joita moni ajaisi omilla palvelimilla itse ylläpidetyllä palvelinsoftalla, ei meillä tarvitse ylläpitää. Riittää, kun maksaa laskun. Esimerkiksi versionhallintaa palveluna myy github, ja hyvin myykin.

On kuitenkin joitakin palveluita, joita valitettavasti ei vielä kukaan ole ymmärtänyt myydä pilvipalveluna. Näistä yksi minua ammatillisesti eniten häiritsevistä (CIO-hattua käyttäessäni) on langaton verkko toimistolla.

Yrityksemme tarve langattomalle verkolle on melkein, mutta ei aivan, yksinkertaisin mahdollinen. Poikkeamat yksinkertaisimpaan mahdolliseen ovat: toimistomme on pitkä ja kapea, ja yhdellä tölkillä on vaikea saada luotettavaa kuuluvuutta joka kulmaan. Haluamme myöskin antaa erillisen verkon satunnaisille vierailijoille, kuin se, jota itse käytämme työntekoon. (Tähän liittyy yksi toinen palvelu, jota valitettavasti ei saa pilvipalveluna: tulostin. Avatkaapas tulostimenne avoimeen langattomaan verkkoon kokeeksi. Ja tarkoitan siis, että älkää avatko. Syyt voi pohtia itse läpi.)

Koska identiteettimme on olla yritys, jossa on jonkinlainen kulukontrolli, aina välillä innostumme tekemään asioita halvalla. Niinpä esim. wlan voidaan toteuttaa siideripalkalla, koska verkostosta löytyy asiaan harrastuneisesti suhtautunut partneri, joka heikkona hetkenä suostuu tällaiseen ehdotukseen.

Pitkäksi venähtänyt johdanto selittää, miksi torstaina viideltä korkkasimme Jessen kanssa toimistolla siideriä, ja varoitimme mattimyöhäisiä verkon mahdollisesta ajoittaisesta toimimattomuudesta. Projektiomistajalle oli annettu kahden siiderin työmääräarvio.

Neljä tuntia myöhemmin kävi mielessä, että projektiomistaja oli ammattilainen, koska siideri ei ollut vielä loppunut kesken.

Viiden tunnin kohdalla langaton verkko toimi vaatimusmäärittelyn mukaisesti. Matkan varrella suunnilleen kaikki oli mennyt eri tavalla kuin suunniteltu, ja useita komponentteja alkuperäisen laajuuskäsityksen ulkopuolelta oli päätynyt mukaan.

Aamulla palasin tapahtumapaikalle inventoimaan vahingot ja kirjoittamaan tilanteen arvokkuutta heijastelevan blogauksen.

Älä käytä halpoja huonoja Post-It® kopioita.

Jos ostat Post-It®-brändiä, käytä Super Sticky -versioita.

En tarkoita että muut tarralaput olisivat huonoja – mutta “muiden” brändit vaihtelevat maittain ja tukkureittain joten niiden suhteen ei pysty antamaan yleisesti pätevää suositusta.

Jos tarralappujen erot kiinnostavat enemmän, kannattaa lukea tarkemmin aiemmin tekemästäni kokeesta [...]]]> Konsultin Niksinurkan Vinkki Numero 3:

Älä käytä halpoja huonoja Post-It® kopioita.

Jos ostat Post-It®-brändiä, käytä Super Sticky -versioita.

En tarkoita että muut tarralaput olisivat huonoja – mutta “muiden” brändit vaihtelevat maittain ja tukkureittain joten niiden suhteen ei pysty antamaan yleisesti pätevää suositusta.

Jos tarralappujen erot kiinnostavat enemmän, kannattaa lukea tarkemmin aiemmin tekemästäni kokeesta jossa tutkin eri tarralappumerkkien seinällä pysyvyyttä – tuloksena mm. että jotkut kloonilaput pärjäsivät aivan yhtä hyvin kuin Post-It® Super Stickyt.

Lähtökohdaksi otin oman olettamukseni siitä, että halvat tarralaput ovat huonoja tarralappuja.

Mutta tämä on vain oma oletukseni. Onko näin oikeasti?

Tein siis testin. Laitoin [...]]]> Tein vähän pseudotieteellisiä tutkimuksia tarralappujen pysyvyydestä seinällä. Pseudotiedettä siksi, että tämä saattaa näyttää satunnaisen ohikulkijan silmään tieteeltä, mutta ei sitä oikeasti ole. Tai ehkä on, mutta aika huonoa sellaista.

Lähtökohdaksi otin oman olettamukseni siitä, että halvat tarralaput ovat huonoja tarralappuja.

Mutta tämä on vain oma oletukseni. Onko näin oikeasti?

Ensimmäinen koe

Tein siis testin. Laitoin neljän eri valmistajan tarralappuja sähkökaapin oveen. Sitten odotin.

Päivä 1

Päivä 4

…

Päivä 21

Papukaijamerkki sille, joka keksii trendin tuloksista.

Yksikään ei suostunut tippumaan (siellä ne ovat kaikki kiinni edelleenkin tätä artikkelia kirjoittaessa). Mikä pettymys!

Nollatulos siis. Hypoteesi ei saanut vahvistusta kumpaankaan suuntaan. Mikä on tietysti alkuperäisen hypoteesin testaamisen kannalta ongelmallinen – miten verrata tarralappujen tarrautumisominaisuuksia, jos ne eivät suostu ollenkaan tippumaan?

Kokeen epäonnistumiseen löytyi käytävältä heti hyviä spekulaatioita:

• Oven maalattu pinta on hyvin sileä. Neukkareiden seinät harvemmin ovat sileitä, joten testi olisi syytä toistaa joko maalatulla kivi- tai kipsilevyseinällä.
• Monesti työpajoissa lappuja siirrellään useasti. Ehkä lapun irrottaminen ja uudelleenkiinnittäminen vaikuttaa tuloksiin.

Toinen koe

Ei muuta kuin toimeen. Kohteeksi päätyi neukkarin harmaaksi maalattu betoniseinä. Viisi eri tarralappumerkkiä päätyi testiin, jokaisesta 9 lappua jaettuna kolmeen ryhmään: suoraan seinälle laitetut, 3 kertaa seinälle laitetut ja 10 kertaa laitetut. Tässä siis ”laitettu” tarkoittaa sitä, että lappu laitetaan kiinni, irrotetaan … ja toistetaan. Tarkoitus on simuloida työpajaa, jossa lappuja siirretään ja ryhmitellään toistuvasti uudestaan.

Tulokset? No, katso alla oleva video.

Kokonaisuudessaan testi kesti muutaman tunnin vajaa 8 päivää. Lopputulos oli joiltain osin selkeä, joiltain yllättävä.

Toisen kokeen lopputulos. Eri merkit on numeroitu 1-5.

Miksi suoraan seinälle laitetut lapun tippuivat ensin? Hypoteesina kun oli, että lappujen irroittelu kerää seinältä pölyä liimapintaan, jota kautta niiden tarrautuvuus heikkenee. Tässä näytti käyvän täysin päinvastoin.

Mahdolliseksi virhelähteeksi käytäväkaarti päätyi ehdottamaan liimapinnan ikääntymistä. Nipun ylimpien lappujen liima on ollut eniten alttiina ympäristölle, eli on mahdollista että ne ovat kuivuneet. (Liiman kuivumisen hitaus on toki yksi tarralappujen laatuominaisuus, mutta lappujen ikä oli tässä kokeessa kontrolloimaton muuttuja.)

Toinen yllätys oli, että originaalit Post-It® tarrat eivät ole automaattisesti muita parempia. Merkki 1 (vasemmanpuoleisin) ei ole 3M:n tuote. Toisaalta merkki 5 (oikeanpuoleisin) on Post-It® Super Sticky -tarralappu. (Muut mallit aivan tämän kirjoituksen lopussa.)

Mitä opimme tarrojen pysyvyydestä?

• Kiinnityspinnalla on merkitystä.
• Tarralappumerkeillä on eroja.
• Lappunipun iällä saattaa olla merkitystä.

Ainakin minulla oli alunperin olettamus, että ”originaalit 3M:n tuotteet” olisivat automaattisesti kilpailijoitaan parempia. Näin ei ole. Super Sticky on selvästi hyvä, mutta merkki 1 oli tässä kokeessa aivan vastaavalla tasolla.

Mitä ongelmia kokeessa oli?

Kokeessa käytettiin mitä tahansa eri valmistajien lappuja joita satuin toimistotarvikehyllyltä ja laatikoiden pohjilta löytymään. Tässä suhteessa ne eivät esimerkiksi liiman kuivumisen suhteen ole samalla lähtöviivalla. Liiman kuivuminen – tai sen hitaus – on toki hyvän tarralapun ominaisuus, mutta tällöin pitäisi vertailla yhtä tuoreita lappunippuja eikä satunnaisia säkin pohjan löytöjä.

Seuraavia asioita voisi tutkia tarkemmin jatkossa:

1. Poistaa lappujen ikääntymisen vaikutukset käyttämällä vain samanikäisiä pinkkoja.
2. Vertailla pinkan päältä ja keskeltä otettujen lappujen ominaisuuksia keskenään.
3. Tutkia ikääntymisen eli toimistoilma-altistuksen keston vaikutusta tarralapun ominaisuuksiin.

P.S. Ei kenelläkään olisi käsillään mN-alueella toimivaa voimamittaria ja olisi valmis lainaamaan sitä?

P.P.S. Uteliaille tiedoksi: Eri merkit olivat siis (vasemmalta oikealle):

1. Corporate Express
2. Talex
3. Stick
4. Post-It® (Regular)
5. Post-It® Super Sticky

Älkää suinkaan tulkitko tätä niin, että X on parempi kuin Y. Ainoa tulos oli, että jotkut ovat parempia kuin toiset. Jos lappusi siis tippuvat maahan, tiedä että vaihtoehtoja on. Jos lappusi pysyvät paikoillaan, ei vaihtaminen välttämättä kannata.

Epätyypillinen työviikko 10-luvulla koostuu neljästä päivästä armotonta koodausta ja perjantaina tajuamisesta, että työaikakirjanpitoon tulee “koodausta, 30 tuntia” ja toteutusta ei saada ikinä dokumentoitua kunnolla. Tyypillisempi viikko menee niin, että [...]]]> Tyypillinen työviikko 90-luvulla saattoi koostua neljästä päivästä armotonta koodausta ja perjantaina tajuamisesta, että sekä työaikakirjanpito että toteutuksen dokumentointi on viikon todellisuudesta jäljessä. Tässä vaiheessa korjasin asian.

Epätyypillinen työviikko 10-luvulla koostuu neljästä päivästä armotonta koodausta ja perjantaina tajuamisesta, että työaikakirjanpitoon tulee “koodausta, 30 tuntia” ja toteutusta ei saada ikinä dokumentoitua kunnolla. Tyypillisempi viikko menee niin, että kirjoitan sekä dokumentit että projektikirjanpidon etukäteen, koska muuten en muista edes mitä suunnittelin tekeväni.

Jälkiviisaana olen aika varma, että kukaan kaksikymppinen ei toimi tällasissa asioissa järjestyksessä, joka meille neljääkymmentä lähestyville on täysin pakollinen.

Parikymppiset lukijat jakautuvat nyt kahtia: toiset eivät pysty edes kuvittelemaan näin huonoa muistia, ja toiset ovat kauhuissaan eivätkä pysty kuvittelemaan miten ilman muistia voi tehdä töitä. Tähän liittyy toinen ero. Niin kauan, kun muistaa suunnilleen kaiken, mitä elämässä on tapahtunut, ei sisäistetyn tiedon ja sattumanvaraisen tiedon välinen ero ole käsitteellisesti välttämätön. Tieto kuin tieto. Tosiasiassa kuitenkin sisäistetty tieto käyttäytyy eri tavalla. Vaikka en muista mitään, muistan kuitenkin kuinka C:tä koodataan, koska osaan koodata C:tä. En muista mitä söin keskiviikkona lounaalla. Se ei kuulu osaamiseen.

Santtu piirsi tähän kuvan, mutta vanhemman ohjelmoitsijan päässä on jo niin paljon kaikkea muutakin. Hyvää Vappua.

Vastasin, että en yhtäkään. Sen sijaan satsaan hyvin nukuttuihin öihin, joiden jälkeen ymmärrän heidän arkkitehtuuriaan paljon paremmin kuin katkonaisten unien jälkeen.

Pohjimmiltaan tässä on kyse siitä, halutaanko työntekijältä (alihankkijalta, jne) [...]]]> Asiakas kysyi minulta, leikillään totta kai, montako unetonta yötä olen viettänyt heidän projektinsa parissa. Ikään kuin uneton yö osoittaisi, että töitä tehdään tosissaan ja täysillä.

Vastasin, että en yhtäkään. Sen sijaan satsaan hyvin nukuttuihin öihin, joiden jälkeen ymmärrän heidän arkkitehtuuriaan paljon paremmin kuin katkonaisten unien jälkeen.

Pohjimmiltaan tässä on kyse siitä, halutaanko työntekijältä (alihankkijalta, jne) panoksia vai tuloksia. Mitataanko sitä, kuinka suurta vaivaa nähdään ja kuinka suuria uhrauksia tehdään, vai sittenkin sitä, kuinka hyvää jälkeä saadaan aikaiseksi.

Oikea vastaus on tietenkin päivänselvä. Siksi ketterissä menetelmissä keskitytään saamaan mahdollisimman nopeasti toimivaa softaa eli tuloksia, eikä piitata niinkään paljon tarkoista työmäärä-arvioista tai niiden pitävyydestä eli panoksista. Siksi myyntiä palkitaan kaupoista ja johtoa voitosta, eikä sankarillisista työsuorituksista.

Työn sankari

Yleensä bisneskirjallisuudessa asia jääkin sitten tähän, teoreettisestihan asia on selvä. Todellisuus on kuitenkin monimutkaisempi. Erityisesti softa-alalla tuloksia on nimittäin yllättävän vaikea mitata.

Konsulttitoiminnassa myydään oleellisesti työtunteja asiakaalle. Luulisi siis, että olisi helppoa mitata myytyjen tuntien määrää ja palkita sen mukaan. Mutta ongelmaksi tulee, että on myös yrityksen sisäisiä töitä, ja nekin pitää tehdä. Jos ne lasketaan asiakastyön tapaan “palkittaviksi”, niin sitten palkitsematta jääneet tunnit ovatkin äkkiä palkattomia tunteja, eikä niiden tekeminen kiinnosta juuri ketään. Pian kaikki tunnit kirjataan asiakasprojektin puolelle, tehtiin todellisuudessa mitä hyvänsä. Seurauksena tuntikirjanpidosta ei voi enää päätellä mitä on oikeastaan tehty ja paljonko siihen meni aikaa. Sen arvo yrityksen ohjaamiseen tai kannattavuuden laskentaan lähenee siis nollaa. Tämän olen nähnyt myös toteutuvan käytännössä.

Vielä hankalampi on mitata keskeneräisen projektin edistystä. On helppo katsoa, montako suunnitelluista toimenpiteistä on tehty ja ollaanko niiden suhteen aikataulussa, mutta se on taas panosten mittaamista: listalta puuttuvat ne toimenpiteet, joita ei arvattu tarvittavan. Scrumin vauhtipisteetkään eivät ole juuri parempia. Ne kertovat lähinnä miten hyvin tiimi osaa ennakoida seuraavan kahden viikon töiden vaativuutta. Arvokasta tietoa tiimille, mutta ei kerro siitä, paljon tuloksia lopulta tuotetaan. Ja jos korkeasta vauhdista alettaisiin palkita, numerot kasvaisivat hyvin äkkiä, koska ei ole mitään estettä vaikka tuplata kaikkia pistemääriä. Tämä veisi mittaamisesta taas kaiken hyödyn.

Lähes kaikki mittarit luovat mittauksen kohteille tarpeen siistiä käytöstään näyttämään paremmalta mittarissa. Erityisen vahvana tämä efekti toimii, jos mittauksen tuloksista vielä palkitaan jotenkin. Sitä saa mitä mittaa, eli mittaustuloksia. Asiakastunteja, vauhtipisteitä tai vaikka commit-rivejä. Yksikään niistä ei ole projektin tavoite. Harkitsematon palkitsemisjärjestelmä tai edes mittaaminen aiheuttaa merkittävää oheishaittaa.

Eräänlaisena nollatasona tulosten mittaamiselle toimiikin arvioijan fiilis, perstuntuma. Projektin etenemistä ja sen jäsenten suoriutumista voi arvioida niin, että juttelee ihmisten kanssa, ja sitten vaan luottaa omaan intuitioonsa. Yleensä varsinkin epäonnistumiset ovat olleet tunnetasolla tiedossa jo kauan ennen kun ne näkyvät missään mittarissa.  Fiilismittarissa on ilmeiset riskinsä (suosikit, väärinymmärrykset, valehtelu…) mutta niin on kaikessa muussakin.

Ennen kun otat jonkin metriikan käyttöön, perustele itsellesi, miten tämä metriikka antaa parempia tuloksia ja tuottaa pienemmät haitat kuin perstuntumalla arviointi. Useimmat mittaus- ja palitsemisjärjestelmät kun häviävät tuolle nollatasolle.

Suorat, kestävät ja tussitaulua tuhoamattomat viivat saat tehtyä viivateipillä.

Ketteriä ohjelmistonkehitysmenetelmiä käyttäneet ovat tuttuja scrum-seinän kanssa. Minimissään sellainen ei tarvitse kuin seinän, tarralappuja ja tussin. Tästä voi hifistellä eteenpäin lisäämällä viivoja osioiden ja/tai tarinoiden ajokaistojen välille (“swim lane”):

Jos kuitenkin haluaa oikeasti hifistellä ja tehdä suorat ja kestävät viivat scrum-seinään, [...]]]> Konsultin Niksinurkan Vinkki Numero 2:

Suorat, kestävät ja tussitaulua tuhoamattomat viivat saat tehtyä viivateipillä.

Ketteriä ohjelmistonkehitysmenetelmiä käyttäneet ovat tuttuja scrum-seinän kanssa. Minimissään sellainen ei tarvitse kuin seinän, tarralappuja ja tussin. Tästä voi hifistellä eteenpäin lisäämällä viivoja osioiden ja/tai tarinoiden ajokaistojen välille (“swim lane”):

Yhdenmallinen scrum-seinä. (Kuva Denis Des Mesmaeker.)

Jos kuitenkin haluaa oikeasti hifistellä ja tehdä suorat ja kestävät viivat scrum-seinään, tämä onnistuu viivateipin avulla. Tätä ihmettä saa autojen maalaukseen erikoistuneista liikkeistä – sen alkuperäinen käyttötarkoitus on nimenomaan viivamaisten maalausten tekemiseen autoihin (ensin pohjamaali, sitten teippi päälle, uusi maalauskerros, teippi pois).

Viivateippi toimii erinomaisesti scrum-seinien ruudukoinnissa vaikka käyttötarkoitus onkin kaukana alkuperäisestä. Ratkaisuna se on pysyvämpi kuin taulutussiviivat muttei silti yhtä lopullinen kuin permanenttitussi.

Itse olen ostanut viivateippiä täältä, mutta eräs nimeltämainitsematon hakukone kyllä auttaa hakusanoilla “viivateippi” ja “pinstripe tape“.

(Huom! Suorien viivojen tekemiseen kannattaa varata kaksi ihmistä ja muutama iteraatio.)

Konsultin Niksinurkan Vinkki Numero 1:

Irrota laput vetämällä sivuttain, ei kulmittain tai pystyyn.

Siis näin (ks. myös alkuperäinen blogikirjoitus):

Lapun irrottamisen [...]]]> Jokainen arkkitehti, fasilitaattori, konsultti ja vastaava on tuttu 3M Post-It® -tarrojen kanssa. Niitä voi käyttää vaikka mihin hauskaan… mutta ihan normaalissakin käytössä on omat niksinsä, kuten:

Konsultin Niksinurkan Vinkki Numero 1:

Irrota laput vetämällä sivuttain, ei kulmittain tai pystyyn.

Siis näin (ks. myös alkuperäinen blogikirjoitus):

Lapun irrottamisen tekniikkaa voi varioida, mutta tärkeää on estää lapun käpristyminen. Litteänä pysyvä tarra jakaa lapun irrottamiseen pyrkivät voimat (eli lapun painon) tasaisesti koko liimapinnalle, käyristynyt lappu jakaa tämän epätasaisesti*.

Miksi tämä on tärkeää? Koska lattialle tippuvien tarralappujen jatkuva noukkiminen nyt vain on noloa…

(* Caveat: Tämä on massiivinen yksinkertaistus, mutta riittävä.)

Tässä aion lyhyesti kertoa kolme eri tapaa ratkaista sen, miten AWS:n resursseja voidaan tuotekehitystiimin tasolla ottaa käyttöön.

Ihan ensimmäiseksi kuitenkin pari perusasiaa AWS:n, sen laskutuksen ja pääsynhallinnan perusteista:

Unohdin asian täydellisesti, kunnes löysin levyn maanantaiaamuna hyllyn päältä. Yhä kaupan muoveissa.

Kuulemma levyn käyttöönotto olisi ollut kauhean vaivalloista. S3:sta tilan sai käyttöön paljon helpommin. Paketti lojui [...]]]> Rakas asiakkaamme, startup, tarvitsi äkillisesti teran tai kaksi levytilaa. Koska meillä on hyllyssä aina muutama varalevy, annoimme herralle kahden teran ulkoisen usbilevyn yhä kaupan muoveissa muistoksi hyvästä suunnittelupalaverista.

Unohdin asian täydellisesti, kunnes löysin levyn maanantaiaamuna hyllyn päältä. Yhä kaupan muoveissa.

Yhä muoveissa

Kuulemma levyn käyttöönotto olisi ollut kauhean vaivalloista. S3:sta tilan sai käyttöön paljon helpommin. Paketti lojui asiakkaan toimistolla kuukausia, kunnes tuli taas asiaa meidän toimistollemme, ja levy löysi tiensä takaisin kotiin.

Tapahtuneella herkutellessani Santeri kertoi, että ennen hän lähetti Codenton aamiaistilaisuuksien raakavideot editoijalle ulkoisella kovalevyllä. Tähän liittyi vaivalloinen fyysisen esineen toimittamisvaihe. Nykyään he kuulemma käyttävät Dropboxia.

(Codenton menneiden aamiaistilaisuuksien esitykset ovat muuten pääsääntöisesti verkossa katseltavissa.)

Eivät uudet tavat tietenkään välttämättä voita. Perinteinen tapa viedä data pilveen Antonov AN-225:llä täynnä irtolevyjä on kustannustehokkuudeltaan ja kaistanleveydeltään parempi kuin Amazon, kunhan ne levyt ovat täynnä. Useimmiten vain eivät ole.

Go tuntuu marsilaisten versiolta C:stä. Olen käyttänyt Gota viime aikoina harrastusohjelmointiin. Vanhakin koira voi [...]]]> Tällä viikolla Google julkaisi Go-kielestään version 1.0 ensimmäisen julkaisukandidaatin; tuote kulkee tuttavallisesti nimellä Go 1 RC1. Lopullinen 1.0 versio tulee kevään aikana. Optimistisesti voisi sanoa, että Go pääsee versioon 1.0 alle vuoden ikäisenä. Marsilaisen vuoden, nimittäin.

Go tuntuu marsilaisten versiolta C:stä. Olen käyttänyt Gota viime aikoina harrastusohjelmointiin. Vanhakin koira voi oppia uusia ohjelmointikieliä, mutta kyllä se pari kertaa haukkuu oudosti sijoitetuille suluille tai erikoisille vaatimuksille.

Teemu kommentoi tuoreeltaan blogissamme vastasyntynyttä Gota. Hänen analyysinsä keskittyi itse kielen ominaisuuksiin. Parametrisoidut tyypit puuttuvat. Slicet ja mapit käyttäytyvät vieraalla tavalla. Nollaosoitin on sallittu.

Käytännön tasolla en ole kuitenkaan näihin rajoituksiin törmännyt. Jotkin tyypit ovat tasa-arvoisempia kuin toiset, mutta itse sopeuduin siihen ensimmäisen sadan koodirivin jälkeen. Kerran huomasin toivovani lampun hengeltä tyyppiparametreja… mutta hetken pohdinta osoitti tämänkin tarpeettomaksi.

Go:n erikoiset valinnat vaikuttavat käytännön työssä perustelluilta, vaikka ne paperilla pelottaisivatkin. Eniten käytännön työtä rajoitti kehno työkalusetti. Puoli (Maan) vuotta vanhassa stabiilissa versiossa (r60) oli käytössä vielä alkuperäinen gomake/goinstall/gotest -työkalusarja. Nämä olivat hieman kankeita; ne nojasivat määrämuotoisiin Makefileihin, jotka saivat omat karvani pystyyn. En minä Makea vastaan sinällään ole. Boilerplate-Makefile minua ärsyttää! Antakee armoa, C-mestarit!

Go 1 yhdistää tyypilliset työvaiheet go-komennon alle. Makefilet ovat tarpeettomia, sillä go-komento analysoi kooditiedostoja suoraan. Se kääntää, testaa, benchmarkaa, dokumentoi ja asentaa. Eikä siinä vielä kaikki! GOPATH-ympäristömuuttujan kanssa se tarjoaa yksinkertaisen (mutta riittävän) mekanismin projektin kirjastojen isolointiin.

Pieni esimerkki

Go-työkalu odottaa tietynlaisen hakemistorakenteen (GOPATH osoittaa workspace-hakemistoon):

• workspace/
• src/
• paketti1/*.go
• paketti2/*.go
• paketti3/alipaketti/*.go
• pkg/
• bin/

Ohjelmoijan tarvitsee välittää vain src-hakemistosta. Go-työkalu luo sekä bin- että pkg-hakemistot. Ensin mainittuun asennetaan binäärit ja jälkimmäiseen käännetyt kirjastot.

Näillä oletuksilla testaaminen sujuu komennolla

go test paketti1 paketti2 paketti3/...

Tällöin työkalu kääntää lähdekoodin ja testit ja ajaa syntyneen testibinäärin. Go-kääntäjä on niin nopea, että koodauksen ja testauksen välinen feedback-looppi pysyy tehokkaana.

Pelkkä kääntäminen tapahtuu komennolla

go build <paketti>

Useammin kuitenkin voi suoraan ajaa komennon go install <paketti>, joka kääntää paketit ja asentaa ne bin- ja pkg-hakemistoihin.

Työkalu nojaa pitkälti konventioihin. GOPATH on käytännössä ainoa konfiguraatio, mitä työkalun käyttöön tarvitaan. Erittäin käyttäjäystävällistä!

Muuta miellyttävää

Testauskirjaston mukana tulee yksinkertainen (mutta riittävä) benchmark-työkalu. Suorituskykytestejä on yhtä suoraviivaista tehdä kuin yksikkötestejä. Helppous johtaa siihen, että teen näitä benchmarkkeja, mikä johtaa suorituskyvyn seuraamiseen, mikä johtaa suorituskyvyn parantumiseen. Lordi Kelvinin kuuluisa lause pätee: “Jos asiaa ei voi mitata, sitä ei voi parantaa”.

Rubyn DSL-pohjaisten testityökalujen syntaktiseen eleganssiin Go:n testing-kirjasto ei pääse. Eri XUnit-kirjastojen käyttäjät ovat kuitenkin kuin kotonaan.

Kääntäjä on miellyttävän tosikko. Esimerkiksi käyttämätön muuttuja ei johda varoitukseen, vaan siitä tulee suoraan virhe. Kääntäjän virheilmoitukset ovat pääasiassa ymmärrettäviä ja kohdistuvat oikeille riveille.

Googlen App Engine tarjoaa myös Go-ajoympäristöä. Ympäristö on rajoitettu, kuten kaikki GAE-ympäristöt. Kiusallisimmat rajoitukset koskevat rinnakkaisohjelmoinnin gorutiinien niputtamista yhteen säikeeseen. Tämä tekee gorutiineista hitusen raskaampia kuin mitä niiden pitäisi.

GAE-ympäristön suorituskyvystä on toistaiseksi vielä vaikea löytää numerotietoja. Seuraavat havainnot pohjaavat IRC-anekdootteihin ja sähköpostilistan tarinoihin. Suorituskyky on samalla tasolla Java-ympäristön kanssa. Muistinkäyttö pysyy pienenä ja erityiskehuja annetaan instanssien käynnistysajalle. Uudet instanssit käynnistyvät 50-100 millisekunnissa.

Mutuni vihjaa, että GAE-Go sopisi hyvin SOA-tyyppiseen pienistä palveluista koostuvaan arkkitehtuuriin.

Loppufiilikseni. Go 1 vaikuttaa erittäin lupaavalta. Työkalut ovat käyttökelpoisia. Dokumentaatio on kypsynyt. Windowsiakin tuetaan. Go ei koskaan tule olemaan uusi Java, mutta veikkaan sen valtaavan itselleen muutaman nichen. Jos olet etsinyt tekosyytä kokeilla Gota, kannattaa aloittaa Go 1:stä.