Single supplier -työkalut

Javaa, erityisesti enterpriseä kehittäessä testisykli käännös- ja deploymentaikoineen on aivan liian pitkä. Tätä paikkaamaan on kehitetty lukuisia ratkaisuja, joista tässä artikkelissa minua kiinnostaa JRebel.

JRebel korjaa Javan (ja JVM:n) ongelman, ettei luokkia voida muuttaa käynnistämisen jälkeen. Tästä seuraa useamman vaiheen kautta JEE:n hitaat turnaround-ajat. JEE-kehittäjät kautta maailman ovat ottaneet sen ilolla vastaan. Aikaisempina vuosina JRebelin lisenssihinta oli vähän yli 50 taalaa vuodessa, mutta nyt se on noussut saman tien 265 dollariin.

On mahdollista että JRebel on edelleen kannattava ostos. Ainakin se on kannattava, jos tekee jatkuvasti JEE-kehitystä. Hintamuutoksen huomattuani tosin alkoi puntti vipattaa pahasti, ja rupesin pohdiskelemaan, että mitenkäs tällainen toiminnallisuus oikeastaan implementoidaan. Taloudellisestihan siinä ei olisi mitään järkeä, mutta juuri näin moni vapaasoftaprojekti käynnistyy.

Mitään ihmeellistähän tapahtuneessa ei ole. Tuotteella ei ole todellista kilpailijaa. Ensin luotiin matalalla hinnalla kysyntä ja markkinat. Sen jälkeen voi alkaa nostaa hintaa. Hinta nousee kunnes kysyntä laskee, tai jostain syntyy kilpaileva tuote. Lopulta joku tekee ilmaisen ratkaisun, ja markkinalta putoaa pohja, jos kaupalliset versiot eivät kykene ripeästi differentioitumaan jollakin tavalla. Kuka muistaa vielä Purifyn? Aikanaan sitä käytettiin paljon, mutta lopulta Valgrind oli riittävän hyvä (ei yhtä hyvä, mutta riittävän), ja motivaatio maksaa Purifysta katosi.

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

Kuinka ostaa ketterästi julkishallinnossa 23.11.

Codento järjestää taas aamiaistilaisuuden, tällä kertaa ketteryydestä julkishallinnossa.

Outi Jousi Hanselista kertoo kuinka ketteriä projekteja voi ostaa hankintalain puitteissa, Karoliina Luoto Sitrasta kuvaa kokemuksia ketterän ohjelmistoprojektin ostajana ja Jorma Turunen Maanmittauslaitokselta kertoo kuinka ketterä ostaminen toimii pitkäjänteisenä osana toimintaa.

Ketterät projektit ovat julkishallinnossa vielä melko uutta. Koska aihe ei ole kaikille vielä tuttu, kansantajuinen ketteryysvalmentaja Lare Lekman selittää mistä agiilissa, scrummissa ja muissa termeissä
oikeasti on kyse.

Ohjelma

8.00–8.30 Maittava aamiainen
8.30–8.40 Tervetuloa
Petri Aukia, Codento
8.40–9.00 Mitä ketterä ohjelmistokehitys on
Ketteryyskouluttaja Lare Lekman, Codento
9:00-9:25 Ketterä projekti tilaajan näkökulmasta
Karoliina Luoto, Sitra
9.25–9.50 Ketterä projekti tilaajan näkökulmasta
Jorma Turunen, Maanmittauslaitos
9.50–10.15 Kuinka ostaa ketterästi hankintalain puitteissa
Outi Jousi, Hansel
10.15– Keskustelua aamun aiheista, tilaisuus päättyy

Aamiaisen suosio ylitti odotukset, joten se on jouduttu rajaamaan lähinnä julkishallinnossa työskenteleville ja silti täynnä. Mutta jos työhösi kuuluu ohjelmien ostaminen julkishallinnossa, ota yhteyttä ja koitamme järjestää paikan.

Aina on myös tilaa sille joka käyttää videokameraa. Eli jos haluat tulla streamaamaan tilaisuuden nettiin(ja tuot välineet mukanasi), tervetuloa!

(Korjaus 23.11.: Korjattu Karoliina Luodon nimi oikein.)

 

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

Demoefekti

Ohjelmistokehitys on kuin standup-komiikkaa. Jotta vitsit toimisivat, niitä pitää esittää yleisölle. Yhä uudestaan, kunnes naurua alkaa kuulua. Yksin kopissa harjoittelemalla ei pääse rajaansa pidemmälle.

Samalla efektillä voidaan selittää laajalti ketterien menetelmien idea: Softaa esitellään asiakkaalle yhä uudestaan ja uudestaan, kunnes se on mitä asiakas haluaa.

Kutsukaamme tätä demoefektiksi.

Demoefekti on sitä, että kun softa pitää jatkuvasti esitellä toimivana autenttisessa ympäristössä, siitä kuin huomaamatta tulee itse asiassa toimiva autenttisessa ympäristössä. Efektin voi muotoilla hypoteesiksi, että softaprojekti onnistuu sitä todennäköisemmin, mitä enemmän sitä demotaan.

Mikä tahansa powerpoint-demo ei riitä, vaan demolle on ehtonsa. Toimivaa softaa pitää esitellä asiakkaalle säännöllisesti lopullisessa tai sitä vastaavassa käyttöympäristössä.

Toimivaa

Softaa pitää esitellä niin, että se oikeasti tekee ne asiat joita esitellään eikä vain kääntele vipuja käyttöliittymässä.

Asiakkaalle

Demoja ei tehdä sisäisesti, vaan ne suunnataan asiakkaan edustajalle, jolla on valta päättää muutoksista projektin tavoitteissa, tuoteomistajalle.

Säännöllisesti

Demoja järjestetään usein, yleensä kahden viikon välein. Alkaen heti projektin alusta.

Lopullisessa tai vastaavassa ympäristössä

Jos järjestelmässä on kolme erillistä klusteria, demossa on kolme erillistä klusteria, tosin ne voivat olla yhden pienen virtuaalikoneen kokoisia. Taustajärjestelmiä ei korvata stubeilla, vaan ne (tai niiden kopiot) ovat jatkuvasti käytössä.

Ketteryyden hyödyt voidaan nähdä lähinnä seurauksina siitä, että softaa demotaan tarpeeksi usein ja tarpeeksi aikaisin.

Demo ohjaa tekijät korjaamaan softaa, ei selittämään sen puutteita

Kun yksi demo menee pieleen, sen kanssa voi elää. Kun sama virhe toistuu, se on noloa. Kolmatta kertaa samalla tavoin toimimatonta softaa ei voi demota, vaan se on oikeasti pakko jo korjata.

Demo paljastaa ongelmat

Jos lippukauppaa ensin koodataan kaksi vuotta ja sitten testataan viisi kuukautta ennen kun sitä demotaan, ei liene yllätys kenellekään, että luvassa on ongelmia. Jos samaa kauppaa demottaisiin kerran kuussa kahden vuoden ajan, eikä se toimisi, ongelmat huomattaisiin paljon aiemmin, ja niille tehtäisiin jotain. Ks. edellinen kohta.

Demo auttaa asiakasta ymmärtämään

Kun asiakkaan päättäjä näkee softan toiminnassa säännöllisesti, hänen on paljon helpompi suunnitella sen tulevaa käyttöä ja huomata mahdolliset muutostarpeet organisaatiossaan tai softassa. Tämä helpottaa käyttöönottoa. Lisäksi erilaiset sidosryhmät voidaan kutsua esittämään kommenttejaan joihinkin demoihin, mikä antaa arvokasta palautetta sekä sitouttaa organisaatiota.

Kaikki ketterät käytännöt, ajattelutavat ja menetelmät ovat itse asiassa tapoja sopeutua demoamiseen kahden viikon välein.

Kevyt speksaus

Kun softan speksi voi muuttua kahden viikon välein, ei sitä ole mitään järkeä kirjoittaa kovin tarkasti. Muutama sana paperilla ja käsin piirretty kaavio riittävät siihen, että yhteinen käsitys tavoitteesta säilyy kaksi viikkoa.

Automaattinen käännös ja testaus (CI)

Kun softa pitää saada toimimaan aina kahden viikon välein, ei erillisille integraatiovaiheille ole aikaa. Softan on pakko toimia koko ajan, joten jokainen commit pitää testata automaattisesti oikeassa ympäristössä.

Vertikaalinen työnjaottelu

Kaksi viikkoa on lyhyt aika. Jotta siinä saa tehtyä jotain asiakkaalle näkyvää, työtehtävät (user storyt) täytyy jäsentää asiakkaalle näkyvien osien mukaan, ei kerroksina tai komponentteina. Uusia API-kutsuja on ikävä demota, jos niitä käyttävä käyttöliittymä puuttuu.

Kevyt hallinto

Kahta viikkoa varten ei piirellä GANTT-kaavioita. Tiimin jäsenten on pakko työskennellä oma-aloitteisesti yhteistyössä. Perinteinen projektipäällikön rooli lähes poistuu ja korvautuu scrum masterilla, jonka tehtävä ei ole ohjata työtä, vaan poistaa esteitä sen edestä. Esteet nimittäin pitää poistaa heti, tai seuraavassa demossa ei ole mitään uutta näytettävää.

Koko tiimi mukana alusta asti

Kun kaikki pitää saada toimimaan heti ja koko projektin ajan, tarvitaan jokaista spesialistia alusta loppuun asti. Vielä parempi, jos tarvitaan mahdollisimman vähän erilaisia spesialisteja.

Demot selittävät ketteryyden hyödyt, ja ne selittävät ketterät työtavat. Seuraavan kerran kun joku kysyy, mitä ketteryys on, tiedät vastauksen: se on sitä, että softaa demotaan kahden viikon välein, kunnes yleisö nauraa.

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

Seikkailuja editorimaassa

Tilapäisessä mielenhäiriössä aloin taas toteuttaa pientä kirjastoa
C:llä. Ajattelin kokeilla samalla (olihan kyseessä puhdas
harrasteprojekti, ja näissä on hyvä aina kokeilla) namespace-ratkaisua
nimitörmäysten välttämiseksi.

No, aloin kirjoittaa:

#ifndef G
#define G(symbol) pieni_ ## symbol
#endif

typedef struct G(foobar) *G(foobar_t);
                         typedef ...

Ja cc-moden autoindent hajosi pyytämättä ja yllättäen jo viidennellä
rivillä.

Mitäs tässä tapahtui? No, C:n preprosessori mahdollistaa tietysti
kaikennäköisen huonosti motivoidun temppuilun, mutta eroon siitä ei
enää päästä, ja C:tä indentoivan järjestelmän on jollakin tavalla
elettävä preprosessorin olemassaolon kanssa. Vaikkakin se tekee
täydellisestä syntaktisesta analyysista vähintäänkin hyvin vaikeaa,
ehkä jopa mahdotonta (jos kaikkia relevantteja headereita ei
esimerkiksi pystytä jostakin syystä löytämään).

Tapaus on erityistapaus yleisemmästä ongelmaluokasta. Joskus ongelmaa
ei voida ratkaista täydellisesti, ja täydellisyyden yrittäminen johtaa
siihen, että ero toteutuneen ja tavoitetilan välillä ärsyttää
käyttäjää erityisesti. Voi olla kaikkien kannalta parempi etsiä
paikallinen optimi huomattavan yksinkertaistuksen keinoin.

Mietin tapausta C:n sisennys. Jos unohdetaan jäsentäminen C:n
sääntöjen mukaan, ja keksitään oma, yksinkertaisempi, täydellisesti
jäsennettävissä oleva syntaksi, josta C on vain
erityistapaus. (Lisäbonuksena tämän syntaksin erityistapauksia ovat
C++, Java ja Javascript, puhumattakaan sadoista vähemmän tunnetuista
kielistä.)

kieli ::= lauseke*
lauseke ::= atomi | "{" lauseke "}" | "(" lauseke ")" | "[" lauseke "]"
atomi ::= [^{}()[]] | merkkijono
merkkijono ::= """ [^"]* """

Ohjelmointikielen sisällön tulkinnan kannalta tämä syntaksi on
hyödytön, mutta emme tulkitse sisältöä, vaan sisennämme.

Jokaista riviä sisentäessä katsomme edellisen ei-tyhjän rivin
ensimmäistä ei-whitespacemerkkiä. Selvitetään siitä kuinka monien
sulkujen sisällä se on, ja monenteenko sarakkeeseen se on sisennetty.
Seuraavaksi katsomme monienko sulkujen sisällä sisennettävän rivin
ensimmäinen ei-whitespacemerkki on. Lisätään edellisen rivin
sisennyssarakkeeseen niin monta sisennysaskelta kuin sulkutasoilla on
eroa.

int foo(int x) {
    bartholomew(exp(1/(x+1), 2)*10*exp(1-(1/(x+1)), 2),
        + exp(1-(1/(x+1)), 2));
    while (quux(x + really_long,
            other_parameter)) {
        repeat_this(x);
    }
    return x;
}

Pieniä kauneusvirheitä. Varsinainen haitta on funktiomäärittelyn
parametrilistan jatkorivien sisennys samalle tasolle kuin funktion
leipäteksti. Parametrilista olisi parempi sisennettynä enemmän, jotta
nämä erottaisi toisistaan.

int quux(int x,
    int y) {
    return x + y;
}

Tämä voidaan korjata lisäämällä {:sta aina yksi taso, mutta (:sta ja
[:sta ensin kaksi tasoa ja seuraavasta samasta avaavasta merkistä vain
yksi taso (Eli (( tuottaa kolme tasoa ja ({( tuottaa viisi.)

Nyt esimerkit sisentyvät näin.

int foo(int x) {
    bartholomew(exp(1/(x+1), 2)*10*exp(1-(1/(x+1)), 2),
            + exp(1-(1/(x+1)), 2));
    while (quux(x + really_long,
                other_parameter)) {
        repeat_this(x);
    }
    return x;
}

int quux(int x,
        int y) {
    return x + y;
}

Tätä voidaan edelleen korjata huomioimalla, että jos edellisen rivin
viimeinen efektiivinen avaava sulje (eli jos rivi loppuu a(b()c,
viimeinen efektiivinen avaava sulje on tuo stringin ensimmäinen sulje)
ei ole rivin viimeinen ei-whitespacemerkki, sisennetään suoraan tuon
sulkeen jälkeiseen sarakkeeseen, eikä lasketakaan sisennyksiä
askeleina. Nyt saadaan:

int foo(int x) {
    bartholomew(exp(1/(x+1), 2)*10*exp(1-(1/(x+1)), 2),
                + exp(1-(1/(x+1)), 2));
    while (quux(x + really_long,
                other_parameter)) {
        repeat_this(x);
    }
    return x;
}

int quux(int x,
         int y) {
    return x + y;
}

Ylläesitettyä syntaksia ei varsinaisesti jäsennetä missään välissä,
sisennys perustuu vain sulkulaskentaan. Vain kommentit ja stringit
pitää jäsentää oikein. Kommenttien ja stringien rajoja ei voi edes
sotkea C-preprosessorilla, joten tämä ei palauta meille alkuperäistä
ongelmaa, jota lähdettiin korjaamaan.

C-like-mode:n jatkokehitys jatkuu. Älkää pidättäkö hengitystänne.

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

Pilven olemuksesta

“Mitä pilvi tarkoittaa?” Kysymys kuulostaa helpolta, mutta kovin monen ensimmäinen arvaus jää hieman vajaaksi.

“Se on sitä kun on voit tilata servereitä ja saat niihin yhteyden heti.” Siis datakeskus? “Ei, kun niitä servereitä ei tarvitse itse omistaa.” Liisaus? “Ei, vaan ne koneet on virtualisoituja.” Virtualisoinnistako siis on kyse? “Ei nyt ihan siitäkään…”

Pilvestä on helpompaa sanoa mitä se ei ole kuin mitä se on.

Ongelmaa hankaloittaa se, että pilvi käsitteenä kattaa valtavan laajan kentän. Mietitäänpä pilvipalveluiden kolmea päähaaraa: IaaS, PaaS ja SaaS.

IaaS

IaaS (Infrastructure as a Service) käsittää ne sellaiset palvelut, joiden avulla saadaan hankittua dynaamisesti IT-infraa. Tästä juuri fiktiivinen keskustelukumppanini puhui pari kappaletta sitten. Näitä tarjoavat mm. Amazon ja Eucalyptus.

PaaS

PaaS (Platform as a Service) taas kattaa sovelluskehitys- ja sovellusalustapalvelut. Käyttäjälle tarjotaan virtuaaliympäristöjä, kirjastoja, valmiita palveluita ja niin edelleen, joiden avulla käyttäjä voi rakentaa omia sovelluksiaan. Googlen AppEngine on yksi tunnetuimmista.

SaaS

SaaS (Software as a Service) on käsitteenä ehkä arkipäiväistynyt eniten. Pähkinänkuoressa: kalliiden ohjelmistolisenssien (ja mahdollisen ylläpidon) sijaan yritys tilaa CRM:n tai ERP:n tai monta muuta järjestelmää kuukausimaksulla. Usein tähän liittyy kaunis web-käyttöliittymä.

Ei ihme, jos hoksottimilla varustettua ihmistä tuon jälkeen epäilyttää. Mitä yhteistä on muka myynninseurannalla ja servereillä? Hyvä, mutta harhaanjohtava kysymys.

Ajatellaan vähittäiskauppaa. Yksi kauppa myy kumisaappaita; toinen taulutelevisioita. Näiden myymillä tuotteilla ei ole yhteyttä, mutta myyntitavalla on: tavarat tukusta, myydään kuluttajalle, auki 9-17. Samalla tavalla pilven merkitys siis avautuu toimitustavan ja tilausmallin kautta, ei tarjolla olevien tuotteiden.

Pilven määritelmä

Olin aikeissa yrittää laatia näiden pohjalta oman määritelmäni, mutta löysinkin paremman. Privaattipilviin erikoistuneen Eucalyptus Systemsin CTO Rich Wolski esitteli pari viikkoa sitten “operationaalisen määritelmän” pilvelle:

Cloud computing is the programmatic provisioning of services to a user community whose requests are scaling dynamically through a transactional and asynchronous network-facing interface.

Määritelmä on aika tiivis. Sen saa purettua itsekin, mutta avuksi kannattaa ottaa Wolskin artikkeli.

Pidän tästä määritelmästä. Se kattaa kaikki ylläolevat aaSit. Se on teknisesti tarkka. Ja se vihjailee tulevasta. Se vihjailee, että uusi ja hieno HTML5-saitti on vain yksi “network-facing interface”. Älypuhelinten softat ovat itseasiassa tästä priimaesimerkki.

Kannattaa huomata, että kyseinen määritelmä ei kuvaa pelkkää palveluntarjoajan APIa. Määritelmän avain on nimenomaan palveluiden provisiointi, ei palveluiden käyttö. Jos vähän teen väkivaltaa, niin pilvimalli on metaverkkopalvelu. Toisen kertaluvun verkkopalvelu? Jään raapimaan päätäni, jääkää tekin.

*raaps*