Olin itse joitakin vuosia sitten hieman vastaavan sertifikaatin suorittanut, joten sinänsä koejärjestelyt ja itse koetilanne olivat entuudestaan tuttuja. Aihekin oli lisäksi viiden vuoden työkokemuksen pohjalta tullut tutuksi, joten ajattelin, että tiedossa olisi sangen kevyttä iltaopiskelua yhtenä, ehkä kahtena iltana viikossa. Todellisuus kuitenkin iski vasten kasvoja jo muutaman kappaleen jälkeen. Vaikka asioita oli työn puolesta käsitellyt paljon, huomasin, että kokeesta ei todellakaan ole tulossa mikään läpihuutojuttu. Toisin kuin edellisessä sertifioinnissa, tällä kertaa kirjan aiheita ei tarvinnut kuitenkaan pähkäillä yksin. Firman sisällä perustettiin opintopiiri, johon ilmoittautui neljä innokasta opiskelijaa. Ideana oli, että joka viikko käydään muutama kappale kirjaa läpi ja jokainen keksii kappaleiden aiheista muille yhden harjoituskysymyksen, jotka viikoittaisessa kokoontumisissa käydään yhdessä läpi. Kysymysten laatiminen osoittautui ainakin itselleni haastavaksi. Se mittaa yllättävän tehokkaasti onko aiheen lukenut ja ennen kaikkea sisäistänyt. Tämän lisäksi ryhmän paine piti huolta siitä, että motivaatiota ja aikaa löytyi aina kappaleen lukemiseen sekä kysymysten laatimiseen. Itseopiskelussahan hyvin yleistä on, että innostus laantuu huomattavasti alun jälkeen ja helposti tulee tuudittauduttua ajatukseen ”kyllä minä sitten illalla / viikonloppuna / kesälomalla opiskelen…” Monesti käykin niin, että ilman säännöllistä rytmiä lukeminen jää yhä vähemmälle ja lopulta painuu täysin unohduksiin. Toki myös tällaisessa kollektiivisessa valmistautumisessa tarvitaan panostusta jokaiselta ryhmän jäseneltä varsinkin, kun kokeen suorittaminen ei ole millään muotoa pakollista.

Itse uhrasin opiskeluun aiheen vaikeudesta ja laajuudesta riippuen pari kolme tuntia per aihealue. Yleensä luin materiaalin ensin läpi, jonka jälkeen kävin läpi kirjan kappalekohtaiset kysymykset. Heti lukemisen jälkeen kysymykset tuntuivat helpohkoilta, mutta jos niiden läpikäynti siirtyi seuraavaan päivään, huomasin, että sangen moni asia olikin unohtunut. Useimpien kappaleiden kohdalla kirjoittelin myös omia koodiesimerkkejä, sillä pelkkä lukeminen meni helposti pelkäksi selaamiseksi eikä pidemmän päälle ollut kovin motivoivaa tai tehokasta. Koodiesimerkeissä saattoi vierähtää helposti pari tuntia (välillä tosin myös aiheesta eksyen), mutta se antoi hyvät valmiudet keksiä kysymyksiä muille ryhmän jäsenille kappaleen sisällöstä. Viikoittaisissa läpikäynneissä kysymyksien vastaukset käytiin läpi ja tarvittaessa vaikeimmista aiheista keskusteltiin enemmänkin. Tällä tyylillä käytiin läpi kaikki kirjan 22 aihealuetta, mihin kului yhteensä aikaa noin neljä kuukautta (tunnustettakoon siis, että joinain viikkoina läpikäynti jäi väliin).

Miten sitten itse koe meni? Jatkoin valmistautumista aina viimeiseen iltaan asti paniikin jo hiipiessä uhkaavasti . Ennen koetilannetta jännitys kasvoi lähes sietämättömiin mittoihin, vaikka vastaavissa tilanteissa en yleensä jännitä. Koe meni kuitenkin läpi, tosin valmistautumiseen nähden tulos olisi voinut olla parempikin: 68% vastauksista meni oikein, läpäisyn rajan ollessa 61%. Kaikki kuitenkin lasketaan eikä prosenttimäärällä niin suurta merkitystä ole, sillä koe arvioidaan hyväksytty/hylätty –periaatteella. Mitään tarkkaa kirjanpitoa opiskeluun käytetystä ajasta en pitänyt, mutta kollegan kanssa arvioimme, että kokonaisuudessaan lukemiseen, kysymysten laatimiseen ja yhteisiin läpikäynteihin kului yhteensä noin 15 – 20 henkilötyöpäivää. Jälkeenpäin ajateltuna tuntuu melko suurelta uhraukselta, sillä opiskelu tapahtui siis yhteisiä läpikäyntejä (noin 30min / viikko) lukuun ottamatta omalla ajalla. Vaikka konkreettisena tuloksena kokeen suorituksesta on vain komea plakaatti toimiston seinällä, antoi opiskelu itselleni paljon lisää intoa jokapäiväiseen työhön sekä myös motivaatiota kehittää itseään ammatillisesti jatkossakin. Ehkäpä seuraavaksi hyökätään Sertifioitu arkkitehti –materiaalin kimppuun.

Lisäys 2.4.2013:  Ja sieltähän ne suomennokset löytyivät. Kiitos Aki.

Erinäisten twiittien, blogien ja blogikommenttien kautta päädyin tälläiseen blogahdukseen. Siinä Cédric Beust (mm. Java TestNG-testiframeworkin kehittäjä) väittää, että me (te, ne) agilehipit eivät saa sitä vaan ovat ottavana osapuolella, epäonnistuvia idealisteja, jotka eivät ymmärrä käytännöstä mitään. No, kaikkihan tietävät, että tämä on diibadaabaa ja täyttä potaskaa. Vanha PL1-koodarikin ymmärtää, että ketteryys määrää ja TDD on pop ja tuottaa puhdasta koodia. Mutta tämä fakta ei ole tämän blogahduksen pointti.

Kirjoitus minut miettimään mikä on olennaista ja mikä ei, mikä tekee ketterän hipin, kehittäjän, tiimin tai yrityksen? Vai onko ketteryys ajattelutapana kuollut tai niin viime vuosikymmentä, kuten eräässä käytäväkeskustelussa kollega huomautti, joko tosissaan tai sitten ei. Tekeekö TDD ketteräksi, pelastaako Scrum kiireisen projektin tai järjestääkö Kanban ylityölistetyn ylläpitotiimin työjonon? Olenko ketterä, kun minulla on CSM-plakaatti seinällä roikkumassa. Oletko sinä ketterä, kun tiedät mikä on “story point” ja osaat “gruumata” perälokia?

Vuosituhannen alussa törmäsin ensimmäisen kerran tähän sivuun (mikä kertoo siitä että ei tämä ketteryys ja muu hippeily nyt niin kovin tuoretta enää ole). XP-käytännöt olivat cooleja jo silloin. TDD, “test first”, refactoring jne. Niistä oli kiva puhua ymmärtämättä mitään tai mitä hyötyä niistä on. No, Javaa tuli opeteltua pariohjelmoimalla. Pari viikkoa meni mukavasti, kunnes pohjalaisen kollegani kanssa menivät sukset niin pahasti “disainista” ristiin, että oli pakko repiä napanuora irti ja jatkaa sinkkuna. Mutta kieltämättä hyötyä tuon “ketterän” työtavan jalkauttamisesta oli: softa saatiin valmiiksi, yhteistyöllä.

Vaihdoin työpaikkaa, ja “ketteryys” ja muu hapatus unohtuivat vähäksi aikaa, koska näistä ei ko. organisaatiossa puhuttu tai ainakaan se ei meikäläiselle näkynyt. Hommia tehtiin ja ne saatiin valmiiksi. Jälkeenpäin ajateltuna, homma oli ajoittain hyvinkin ketterää lukuunottamatta sitä, että suoria asiakaskontakteja ei minulla ollut. Meillä oli speksi joko paperilla tai sitten projektipäällikön päässä, ja sen mukaan koodattiin. Välillä joku kävi kysymässä, että onko valmista. Jos oli, toimitettiin. Itse tuli jo tuolloin koodattua niin, että homma oli koko ajan “paketissa” ts. aina oli jotain näytettävää, jos statusta kysyttiin. Toisaalta, tulipa törmättyä ihan aitoihin vesiputoustyyppisiin projekteihinkin: speksiä oli kilotolkulla ja sieltä sitten ensimmäiseltä sivulta lähtien alettiin koodaamaan.

Puhelin pärähti ja siirryin seuraavaan organisaatioon. Nyt “ketteryyttä” kaadettiinkin niskaan oikein kansiokaupalla, RUPin muodossa. Oli eri vaiheita, oli manuaalia josta “voidaan implementoida vain tarpeelliset osat”. Syntyi testejä (lieviä ongelmia oli kyllä talon sisällä tehtyjen stub-objektien kanssa: ne generoivat invalidia dataa, mikä asia selvisi minulle 2 päivää liian myöhään). Syntyi “vain tarpeellinen” dokumentaatio. Huolimatta hyvin koulutetusta ja dokumentoidusta prosessista tilanne oli kuitenkin ajoittain kaoottinen, eikä aina ollut täyttä ymmärrystä siitä mitä tehtiin. Lopulta päädyttiin siihen, että heitettiin RUPpi roskiin ja mietittiin tosissaan mitä tarvitaan ja mitä ei. Viimeisestä projektista muistan päällimmäisenä sen, kun projektipäällikkö antoi tiimille speksin ja tuli parin kuukauden päästä noutamaan hyvin toimivan, virheettömän softan. Ilman iteraatioita, ilman daily scrumeja, ilman mitään “ketterää”. Tässä välissä oli myös muutama välivaihe ja pari muuta projektia, mutta mielestäni kaikki kulminoitui tuohon viimeiseen.

Noihin vuosiin mahtui enimmäkseen onnistuneita projekteja. Ja jos projektissa kaikki ei toiminut heti alkuunsa, homma saatiin silti jossain vaiheessa pelaamaan. On ehkä syytä miettiä, mikä noissa onnistuneissa projekteissa on yhteistä. Ketterä mies kaivaa naftaliinista tietenkin vanhan kunnon ”Ketterän manifestin”, jota vasten asiaa peilaa.

Individuals and interactions over processes and tool (Ihmiset ja vuorovaikutus ennen prosesseja ja työkaluja)

Kylmä fakta on se, että kaikissa onnistuneissa projekteissa oli mukana vähintään yksi kovan luokan kehittäjä, joka omalla esimerkillään ja teknisellä osaamisellaan veti myös kokemattomampia eteenpäin. Mikään prosessi tai työkalu ei voi korjata ihmisten henkilökohtaista osaamista ja kuten tuo viimeinen esimerkkikin kertoo: jos porukka on tarpeeksi hyvä henkilökohtaisella tasolla, hyvän sovelluksen tekeminen onnistuu käytännössä ilman mitään (muodollista, kuvattua) prosessia suhteellisen kivuttomasti.

Osaamiseen lasketaan toki myös hyvät kommunikaatiotaidot: ilman näitä tiimin työ on mahdotonta. Esim. päivittäiset Scrum-kokoukset saattavat muuttaa tiimin yhteistyötä aivan olennaisesti. Monesti isoissa perinteisellä tavalla toteutetuissa projekteissa on se ongelma, että ihmiset eivät tiedä mitä kaverit tekevät ja em. syystä tekevät esim. päällekkäisiä asioita. Pistä porukka aamulla piiriin kertomaan tekemisistään, niin tilanne helpottuu. Tässäkin on hyvä esimerkki siitä kuinka yksinkertaisesta asiasta ketteryydessä on kysymys ja myös siitä, että kaikkia käytäntöjä ei tarvitse tuoda yhdellä kertaa tiimille. Edetään pienin askelin ja opitaan samalla siitä, mitä ollaan tehty.

Working software over comprehensive documentation (Toimiva sovellus ennen kattavaa dokumentaatiota)

Tässä vaiheessa on syytä korostaa tuota manifestissa esiintyvää englanninkielistä “over”-sanaa. Ketterät menetelmät EIVÄT siis suosittele poistamaan kaikkea dokumentaatiota ja pelkästään koodamaan Post-it-lappujen perusteella, kyse on priorisoinnista. Toisaalta, ei ole mitään sääntöä sille, kuinka paljon dokumentaatiota tuotetaan. Kaikki tehdään tarpeen mukaan, ja jokaisella tuotoksella pitää olla käyttöä ja selkeä kohderyhmä. Mitään ei tehdä vain siksi, että “prosessi niin sanoo”. Jokaista lausetta kirjoitettaessa pitää miettiä a) kuka tätä lukee ja b) miksi. Eräs arvostamani arkkitehti totesi kerran, että jos dokumentaatio muuttuu päivittäin, se on liian tarkalla tasolla. Nyrkkisääntö tuokin, eikä välttämättä ihan huono.

Toisaalta, hyvin menneissä projekteissa on julkaistu paljon ja aikaisin. Ja on keskitytty siihen, että se olennaisin tuotos toimii eli sovellus. Esim. tuossa viimeisessä mainitusta projektista ei julkaisuhetken jälkeen löytynyt kuin yksi bugi puoleen vuoteen, vaikka ko. härveli oli kovassa käytössä. Koodi on ollut keskiössä ja se, että se on ylläpidettävää. On ollut joku joka siitä välittää. Paljon puhutaan siitä, että “koodi on kaikkien omaisuutta”. Toki näin on, mutta monesti on vielä joku, joka välittää muita enemmän. Muuten koodin laadulle saattaa käydä kuin yhteiskäytössä olevan auton siisteydelle.

Jotenkin tämä teesi on mielestäni näistä kaikista naurettavin: eikö pitäisi olla itsestään selvää, että jos ostetaan sovellus, koodi ja valmis tuote on se tärkein asia?

Customer collaboration over contract negotation (Asiakasyhteistyö ennen sopimusneuvotteluja)

On totta, että sopimuksia tarvitaan luomaan turvallinen ympäristö toteuttaa projektia, turvallinen sekä asiakkaalle, mutta myös toimittajalle. Toisaalta ei myöskään ole kenenkään etu se, että pilkuntarkasti noudatetaan sovelluksen jokaista pykälää sillä hinnalla, että asiakas ei saakaan sitä, mitä oikeasti tarvitsee vaan sitä, mitä jollain ajanhetkellä menneisyydessä halusi. Tämä saa myös toimittajan näyttämään hölmöltä. “Eihän me tätä haluttu?”, on usein kuultu lausahdus ei niin ketterästi toteutetuissa projekteissa. Sitten pohditaan kenen syy oli: oliko vika epätäydellisessä “speksissä” vai toimittajassa, joka ei toimittanut sitä mitä tuossa “epätäydellisessä speksissä” määriteltiin. Ja tästä päästään siihen vanhaan totuuteen, että yleensä se mitä haluaa selkenee vasta siinä vaiheessa, kun nähdään valmiina jotain konkreettista. Ja täydellisen, kaikki yksityiskohdat huomioiva määrittelyn kirjoittaminen on kutakuinkin mahdotonta. Asiat muuttuvat, asiat nähdään eri valossa projektin eri vaiheissa, tärkeysjärjestys muuttuu jne.

Mieleenpainuvin kommentti menneisyydestä liittyy juuri tähän yhteistyöhön asiakkaan kanssa. Aiemmasta “dokumentoi koko maailma”-tyylistä siirryttiin ylläpitovaiheessa jatkuvaan, liki päivittäiseen asiakkaan kanssa kasvokkain kommunikointiin. Muutaman viikon kuluttua kuulimme kommentin: “munhan ei tarvitse tehdä enää mitään.” Asiakkaan ei enää tarvinnut yksin miettiä speksiä, vaan mietimme sitä yhdessä päivittäin, pienissä paloissa. Homman vaikeustaso laski inhimilliseksi.

Responding to change over following plan (Muutoksiin vastaaminen ennen suunnitelman noudattamista)

Tämä on ehkä vaikein asia käsiteltäväksi. Muutoksen hyväksyminenhän on rakennettu sisään syvälle ketteryyden ajatusmaailmaan. Jo vuosia sitten ketteryyden kritiikissä, toisaalta myös perusteluna käytettiin sitä, että sallitaan muutos, kunhan koodataan, ei suunnitella ja saadaan valmiiksi tai sitten ei saada. Joitakin päiviä sitten kuulin kommentin, että ketterä projektimalli tarjoaisi “avoimen valtakirjan” toimittajalle: kunhan tehdään mitä tehdää ja vaikkei valmista tulisikaan, lasku lähtee silti.

Väitän, että ketterä projektimalli tarjoaa ENEMMÄN kontrollia projektin kulkuun asiakkaan näkökulmasta kuin perinteinen vesiputousmalli (no, eipä tuo ketterä mallikaan enää mikään uusi asia ole, kuten jo aiemmin tuli mainittua). Asiakas voi projektin edetessä priorisoida asioita, pyytää uusia ominaisuuksia, joita ei ole aiemmin määritelty tai jopa muuttaa koko projektin suuntaa tai laajuutta tarpeidensa mukaan. Mikään ei tietenkään tule ilmaiseksi: ketterässä mallissa ei tehdä mitään ylimääräistä, tehdään vain tarpeellinen. Tällöin saattaa jäädä osa alkuperäisen suunnitelman ominaisuuksista toteuttamatta, toisaalta yleensä saadaan enemmän tarkoitukseen sopiva sovellus ja saatetaan jopa säästää rahaa, kun ei tehdä mitään turhaa. “Inspect and Adapt”, vanha iskulause. Eikä vain paineta höyryjunan lailla eteenpäin, suoraa raidetta.

Vesiputousmallin tarjoama kontrolli projektiin ja toimittajaan on näennäistä, “toivotaan, toivotaan” kontrollia. Mitäs jos suunnitelmassa oli vikaa? Mitä jos toimittaja ei osaakaan? Mitä jos asia ymmärrettiin väärin? No, lopputulos selviää julkaisuvaiheessa. Itse ainakin jännittäisin vatsa kuralla, mitä tuleman pitää.

Aloin kirjoittamaan tätä viikkoja sitten. Olen vääntänyt ja kääntänyt tätä moneen kertaan ja miettinyt, että onko tämä niin triviaalia huttua että tätä ei kannata julkaista. Miksi julkaista itsestään selviä, yksinkertaisia asioita? Kun näitä teesejä miettii, tajuaa mistä nämä kumpuavat: käytännöstä, käytännön järjestä ja kokemuksesta. Näitä prinsiippejä ovat olleet latomassa ihmiset, joilla on vuosikymmenten kokemus menestyksekkäästä sovelluskehityksestä. Näitä ei ole kehitetty komiteoissa tai johtoryhmissä ja annettu resursseille impelemetoitaviksi. Nämä ovat päätelmiä, joihin jokainen meistä voi omassa työssään päätyä saatuaan riittävästi kokemusta erilaisista projekteista.

Kuitenkin edelleen näihin asioihin liittyy väärinkäsityksiä ja -ymmäryksiä, ketteryydestä tehdään monimutkaisempaa kuin se onkaan. Itselleni ketterä maailma näyttäytyy yksinkertaisena ja suhteellisen selkeänä. Tosin katson maailmaa ruohonjuuritasolta, koodarin näkökulmasta. Kaikki näkökulmat ovat tervetulleita, joten päätin kuitenkin julkaista tämän kirjoituksen, jotta asiaan saataisiin muitakin näkökulmia. Joten kommentit ovat enemmän kuin tervetulleita!

Jotta ketterien menetelmien tuomat hyödyt olisivat paremmin ymmärrettävissä, haastattelimme asiakaskuntamme ulkopuolelta Kelan verkkoviestinnän kehittämispäällikkönä toimivaa, kela.fi-verkkopalvelun uudistuksen parissa parhaillaan puurtavaa Marika Leedsiä, joka vastaavan koulutuksen käytyään toimii nyt Product Ownerin roolissa kyseisessä projektissa.

Kuka olet, minkälaisessa tehtävässä työskentelet?

Olen Kelan verkkoviestinnän kehittämispäällikkö. Työskentelen parhaillaan Product Ownerina kela.fi-uudistuksessa. Olemme siirtämässä palvelua Liferay-alustan päälle.

Mikä on Product Owner ja kuinka sinusta tuli sellainen?

Product Owner on liiketoimintaa edustava ihminen, joka omistaa tuotteen ominaisuudet ja vaatimukset. Hän päättää ja priorisoi, mitä toiminnallisuuksia tietojärjestelmään tulee sekä osallistuu tarvittaessa ominaisuuksien tarkempaan määrittelyyn ja testaukseen.

Mitkä ovat Product Ownerin tärkeimmät tehtävät ja vastuut?

PO:n tärkein tehtävä scrum-projektissa on tuotteen kehitysjonon ylläpitäminen ja priorisointi. PO käy kehityslistaa viikoittain läpi ja priorisoi jonon kärkeen ne asiat, jotka haluaa seuraavaksi toteutuslistalle. Hän istuu samassa työtilassa kehitystiimin kanssa ja allokoi työaikansa (ainakin projektin alusssa) n. 80-100 % kehitysprojektille.

Mikä on hyödyllisin asia mitä olet Product Ownerin rooliin liittyen oppinut?

Jokainen toiminnallisuus maksaa! Priorisoi release 1:stä kaikki sellainen pois, joka olisi ”ihan kiva” saada tuotteeseen mukaan, mutta joka ei ole vättämätön julkaisun kannalta. Tärkeää on saada ulos ensimmäinen tuoteversio mahdollisimman nopeasti, jotta siitä saadaan businesshyöty heti irti.

Miten vertailisit scrum-menetelmiä perinteiseen kehitysmalliin?

Kun työskennellään scrumilla, pystyn tilaajan puolella paljon enemmän vaikuttamaan tekniseen toteutukseen. Työskentely ei ole yhtään sen helpompaa tai vähemmän työlästä kuin perinteisissä projekteissa, mutta väitän, että lopputuotteen laatu erityisesti ylläpitäjän näkökulmasta on huomattavasti parempi.

Minkälaisissa projekteissa scrum-malli toimii parhaiten?

Tähän en osaa vastata, koska tämä on vasta toinen scrum-projektini. Mutta ainakin se sopii hyvin verkkopalveluiden uudistamiseen ja tilanteisiin, joissa otetaan käyttöön valmis julkaisujärjestelmätuote.

Miksi mielestäsi asiakkaan osallistuminen projektiin muutenkin kuin tilaajana on tärkeää?

Asiakkaan osallistuminen projektiin on tärkeää, jotta tilaajan ja toteuttajan välinen raja-aita hälvenee. Kun PO seuraa samassa työtilassa päivittäin kädet savessa sitä, kuinka tietojärjestelmiä tehdään, hänen ymmärryksensä ja asiantuntemuksensa kasvaa. Työskentely yhdessä vahvistaa myös keskinäistä luottamusta ja projektista tulee aidosti yhteinen ponnistus.

Jos nyt aloittaisit uuden vastaavan projektin, tekisitkö jotain toisin?

En aloittaisi sisällöntuotantoa julkaisujärjestelmään viisi viikkoa sen jälkeen, kun scrumtoteutus on käynnistynyt. Odottaisin 2 tai 3 kuukautta, jotta tuote ehtisi hieman enemmän kypsyä ja ympäristöt olisivat paremmassa kunnossa (ts. niissä olisi vähemmän bugeja).

Terveiset Product Owner -koulutusta harkitseville?

Älä ryhdy Product Owneriksi ilman koulutusta! Ja ensimmäisessä projektissasi tee kaikki ”by the book”. Sitten, kun sinulla on scrumista kokemusta, voit alkaa soveltaa menetelmää enemmän. Mutta vasta sitten, kun olet hankkinut peruskokokemuksen.

Ambientian ja Tieturin yhteistyössä järjestämästä koulutuksesta voit lukea lisää Ambientian verkkopalvelusta.

We have been building one kind of dashboard to one of our customers, or actually customer’s customers, and it’s intranet. Maps, charts and lists and interactions between them. And part of the data comes from Splunk instance. As I said before, Splunk can view some pretty cool data visualizations too, but in our case we need centralized authentication (SSO) and authorization and also combination of charts with other views, like maps and lists. So we decided to do visualizations at Liferay’s side of system. At POC phase we used Leaflet API for map (leaflet offers very pretty interface for maps and layers on them) and Google Chart api for charts. And Splunk’s cool Java api for querying data from background.

Why it’s cool? In my opinion, it’s quite simple but still versatile. You can find usage examples from here. But basically you can do asynchronous or synchronous queries using Splunk search language, select how to format your result (JSON, XML, CSV), integrate results to your application and of course login into that system. We did little transformation at the portlets controller class and that’s it: we could return JSON to our portlet’s view.

At the view (which is actually JSP-page) we used some pretty cool JavaScript trick, that Liferay offers us: client side inter-portlet communication with using Liferay JavaScript event system. We have map portlet which have map view with some markers on it. When you click that marker, it fires event. Every portlets on that page can register itself to listening that particular (or other) event. At the chart portlet that event triggers asynchronous ajax call to controller, which does query to Splunk and returns results in JSON format. Google chart api uses that JSON data to draw chart. Actually, with that event system you can add other portlets too, which are updated using that event system. And they are very loosely coupled: sending end doesn’t know anything about them.

These very lightweight technologies offer clean way to do some pretty cool interactions and visualizations in a portal. And there is not so much job to do if you want to move all that stuff on other platform like Grails or plain old Spring MVC.

Liferay and Splunk are a beautful combination. If you want to know more about the combo, just e-mail me or ask me on twitter,

Juha

On Feb 22nd, a dozen of inspired software programmers from 4 local companies met at Tiedepuisto in Joensuu 8am in the morning. Their goal being to code for the whole day a simple program for Conway’s game of life. You’d expect that a dozen of programmers would not need a whole day for it.

And there’s the catch. We started from the scratch six times. That is, six times we started to solve the problem from the start! Why on earth, why would I want to spend a whole day programming while not getting anything done? And that’s the whole point of coderetreat. To practice.

Coderetreats often have a certain structure. Day starts with breakfast and while drinking morning coffee I often sense the excitement within the attendees.

In the first 45 minute session, we get to know to the domain – to Conway’s game of life. While attendees are implementing their first code snippets, the facilitator often circles around, looking over the programmer shoulder, quite literally. The facilitator tries to find issues to tackle over the next 5 sessions.

Are we using boolean flags for describing state? Are we using an array of array to describe the world? With the observations done during the 45minute programming period, we end up sessions with a short reflection.

In the last 5 sessions, the facilitator decides some constraints for the attendees. The goal is to make the attendees to code in a way they normally don’t with production code. Or, to say as it is, to take people out of their comfort zone into the zone where there’s a huge opportunity to learn.

The constraints often are selected based on the observations during the previous sessions:
Are the developers using too much mouse? How about constraint that no-one is allowed to use mouse (or trackpad). You better learn to use your IDE to get anything done.
Are the developers using language provided collections? How about a constraint for using first-class collections!
Primitive Obsession -> No primitives
overly used if-statements -> Single Responsibility Principle/No if-statements
Long methods -> at max 4 lines per method.

You get the drill.

After the fifth session, we are often exhausted. The programmers have been pushed and pushed to try to follow the rules. And maybe even more. As the last session, many facilitators give the programmers a chance to select (at least) one of the constraints we had during the day.

Giving a chance to practice the one they liked the most. The closure for the day, for the learning.

After the last session reflection, we do still have one important task: reflect the whole day.
During the reflection, programmers answer to the three following questions:
1) What, if any, did you learn today
2) What, if any, did surprise you today
3) What, if any, will you take with you from the event

As facilitator, I’ve seen that two constraints are those that come up in all the three questions.
Firstly, there’s the constraint of ’single responsibility / no if-statements’ that makes programmers to really focus on objects.
Secondly, there’s the constraint of ’Baby Steps’ that often drives people nuts in the beginning. And that often, to our biggest surprise, seems to make sense.

Were you there? Have you been to other coderetreat events?
I’d appreciate your experiences and thoughts on this kind of deliberate practice.

What can I say, it was an amazing experience.. Great speakers who really knew what they were talking about, good facilities, good beer (though very limited amounts) from Atlassian.

There were quite an abundance of presentations about functional programming, which seems to gain large amounts of hype currently. I attended most of these and they proved quite interesting. Other things I found interesting were a peek to Java memory model & GC logging output, Java concurrency synchronizers and some Raspberry Pi thingies (I happen to own one).

Functional programming
As you might already have realized, modern computers come with CPU’s equipped with usually more than one core, e.g. my working laptop has 2 cores / 4 threads (hyperthreading), or even with more than one CPU (e.g. server machines). If we go back in time for about 7-8 years, there were about an even number of multi- and single-core processors in computers out there. The reason of using multiple cores (or CPU’s) over one really fast core is dictated by the laws of physics – you just can’t keep cramming millions of transistors to an ever smaller growing piece of silicon because after a crucial point, the whole thing will just melt down when you power it up. So, to avoid meltdowns (and other side effects), simply multiply the core to gain more processing power.. the only gotcha there is that all this new potential is unleashed only when a program executes it’s operations in parallel – bummer..

This is where functional programming steps into the picture. The key things what is so great about functional programming is the easiness of parallerizing the execution of the code. Then, what is functional programming? It is not really a new concept. It’s actually decades old and has it’s roots in [http://en.wikipedia.org/wiki/Lambda_calculus|Lambda calculus]. There are quite a few programming languages that support the functional programming paradigm such as Groovy, Scala, Clojure, Javascript.. The great thing for Java developers is that the upcoming Java 8 will support the lambda calculus (better sooner than later.. even C++ supports it). Programming functional style, allows one to implement some very handy higher order functions (functions that return functions) such as map and reduce (and filter):

filter = Get a subsequence from a list of values.
map = Apply a function to a list of values and return a list of values.
reduce = Apply a function to a list of values and return a single value.

Java memory model & GC logs
I went to the presentation by Kirk Pepperdine where he explained the Java memory model and the function of the generational garbage collector, regional garbage collector and the output of GC logs. As there are ever increasing memory requirements for applications, it creates considerable strain to the Java Gargabe Collector. Much can be learned through GC logs when profiling an application that has performance and or high memory consumption issues. High memory footprint always creates more work for the GC and it should always be avoided if possible since a full mark-sweep to tenured memory space (the big part of the memory pool) is going to take a long time. During a mark-sweep, the objects in memory are checked for wheter they’re alive or not and during this time any mutator thread is put to a full halt (mutator thread is your application’s thread, doing it’s things).

For alleaviting pains in heavy GC action in an application using a generational GC, one could try using a regional GC that basically functions as the generational one but with regioned memory (1MB – 32MB regions). Regional garbage collectors: Oracle’s G1GC, IBM’s Balance and Azul’s C4.

Summary
All in all, I had a very enlighting and nice time in Jfokus 2013. I recommend. Be sure to check http://www.jfokus.se/jfokus/recordings.jsp every once and a while as this years presentations will be made available there.

If you’re interested in other topics such as Simon Ritter’s RPi toys (a robot arm controlled by a playstation game controller clone or mind controlled lego thingy) or Dr. Heinz Kabutz’s Java concurrency synchronization using Phaser / StampedLock, you can contact me by email (first.last(at)ambientia.fi).

Sources:
Jfokus 2013 presentations
http://pages.cs.wisc.edu/~fischer/cs538.s08/lectures/Lecture16.4up.pdf

Startup-kulttuurin kulmakivi on ihmiset, jotka tekevät omistautuneesti ja intohimoisesti sitä, mihin he itse uskovat. Avoimuus, luottamus ja ideoiden jakaminen niin muiden työntekijöiden kuin yritystenkin välillä on tärkeää. Varsinkin suuret yritykset näkevät kilpailijat usein uhkana, kun startup-yrityksille on luonnollista jakaa kokemuksia keskenään. Menestyksellisen startup-yrityskulttuurin taustalla on myös ketteryys ja joustavuus kaikessa toiminnassa, ilman byrokratiaa ja hierarkioita, mikä mahdollistaa ideoiden nopean kehittämisen ja itse tekemiseen keskittymisen jatkuvan kokoustamisen sijaan. Suurempien yritysten kannattaisikin ottaa mallia startupeille ominaisesta tekemisen meiningistä sekä ilmapiiristä, joka kannustaa työntekijöitä tuomaan ideoitaan rohkeasti esille ja toteuttamaan niitä. Jos jokaisen asian toteuttamista varten tarvitsee suostumuksen, on vaikea saada mitään aikaiseksi. Marika Appel totesikin osuvasti, että  ”on helpompi saada anteeksi kuin lupa”. Toisaalta suuren vastuun antaminen työntekijöille vaatii rekrytoinneissa onnistumista, varsinkin mitä suuremmasta yrityksestä on kyse.

Rohkeus näkyykin vahvasti startup-kulttuurissa. Sekä Erik Pöntiskoski että Marika Appel korostavat epäonnistumisten ja niistä oppimisen merkitystä yrityksen menestykselle. Epäonnistumisen pelko estää monen loistavan idean ja projektin syntymisen eikä ilman riskien ottamista voi menestyä, koska silloin kaikki ei ole pelissä. Epäonnistumisen pelosta voi päästä eroon helpottamalla epäonnistumista vaikkapa juhlistamalla sitä Supercellin tapaan shampanjalla. Supercellissä onkin huomattu, että epäonnistumisessa onnistuminen on tärkeä osa yrityksen menestystä.

Menestyneiden startup-yritysten kulttuuri ja toimintatavat kuulostavat hyviltä, joten miksei samoja piirteitä löydy suurista yrityksistä? Tai voi löytyä, mutta ainakin minun on vaikea keksiä esimerkkejä tällaisista tapauksista. Suurten yritysten kulttuurissa korostuvat usein hierarkkisuus, byrokratia sekä avoimuuden ja itsenäisyyden puute, jotka ovat Bitfestin puhujien mukaan haitaksi yrityksen menestykselle. Tällaisessa yrityskulttuurissa ideoiden syntyminen ja toteuttaminen on hidasta ja hankalaa. Markkinoiden ja taloustilanteiden äkilliset muutokset edellyttävät yrityksiltä ketteryyttä reagoida näihin muutoksiin nopeasti, mutta suurten yritysten heikkoutena on valitettavan usein kyvyttömyys muuttaa suunnitelmia ja toteutusvaiheessa olevien projektien suuntaa joustavasti.

Toisaalta, jos startup-kulttuurin säilyttäminen yrityksen kasvaessa osoittautuu mahdottomaksi, täytyy pysyä pienenä – kuten Supercell aikoo.

… and a post-functional programming-style enlightenment.

Last week we visited Scandinavia’s biggest (and only) Java-conference Jfocus 2013 in Stockholm. I had heard positive rumors about interesting topics and good speakers and after seeing the thing live, I can only say it delivered the promise of bringing world-class speakers and seasoned developers together.

During the two conference days there were constantly four simultaneous tracks of talks from varying topics going on. The main themes circled around functional programming style (coming soon to a Java near you), how to build scalable systems/apps and various common tasks in development and deployment. Fortunately there were also four of us present (and 1500 others), so we had the chance to split and discuss the topics later.

Some crowd-magnet talks were, for example, those from Netflix and Twitter where
they gave us a sneek peek at how to deliver when things get big. Both of the services have millions of users and thus have massively scalable systems. The Twitter talk focused on realtime delivery of content whereas the Netflix talk was about their overall cloud architecture (which, by the way, they are currently open-sourcing one service at a time). An interesting point from the Twitter talk was
that their problem is not the 300 000 tweets coming in every second, but the cha
nges in viewing scope (like starting/stopping to follow someone) which generates 18 million outgoing messages per second.

By far the funniest (and still highly informative) speaker was Dr. Venkat Subramaniam on ”Design Patterns in modern JVM Languages”. His talk focused on the re-emerging functional programming style, which for decades has been mostly of academic interest (because it alone has no high level structures like packages and inheritance which object oriented style offers).

So why introduce functional concepts, like currying and monads, to object-oriented languages? (even if you’re not quite on par with the concepts, just keep reading) Well, in yesterdays apps, everything was run on one computer or on a single system for that matter. In todays apps, we have multiple processors available even in our laptops not to mention cloud platforms. Unfortunately in our current apps, the heritage of procedural programming being taught and used everywhere shows (in many simple operations, like going through lists). Our past has left us with poorly scalable apps, luckily the coming functional programming style has scalability built-in. Yeah, it’s a bit harder at first, but it will pay off with also better re-usability on the method (I mean function) level.

Many of the talks were recorded and will become available online in the coming weeks at:
www.jfokus.se/jfokus/recordings.jsp?lang=en

Disclaimer: I’ve only been at Ambientia for three months and thus I am not making a statement whether Ambientia is, or is not, a learning organisation. What I do describe, instead, is what it could mean for an organisations, generally speaking.

Learning is something to celebrate together!

I went to #LESS2012 to meet new people and to learn. And it did exceed my expectations – both of them. I loved the discussions we had with Claudio, Mark, Stefan, Vasco to name a few. And I went there to learn more about Lean Startup and the ideas behind it.

That learning, regarding Lean Startup, together with my new insight that learning happens in reflection, made me realise something: the concepts indeed seem to have a point.

In Lean Startup, there’s a core concept of creating feedback loops on potential customers – would this thing(y) solve that problem of yours. And as part of that process, in reflection, we learn a great deal about our markets. In Lean Startup, we run many experiments and gather feedback from our potential customers. And in reflection, we learn a great deal about our customers.

In reflection we learn.

A3 – a thinking tool for problem solvers. And what happens in the process of creating A3. It’s about taking time to reflect the problem. Taking time to plan – to create a hypothesis, that is. To run an experiment to validate the hypothesis. And to learn, in reflection, by measuring the results of the experiments.

Some say, PDCA yet again. I say: Yes, and I couldn’t care less.

Since in reflection we learn.

So, what does this bring us with? We started to work with my first-ever A3 report a little while ago here at Ambientia. I hope we learn in this experiment we are running. And I hope there’s a lot more to come of these experiments.

I want to thank Claudio Perrone and Jacopo Romei for making a difference!