by Jani Nurmi | 27.09.2018 | Kokeilukulttuuri, Koodausta ja kohellusta
Ei nyt sentään kohellusta
Järjestimme halukkaille mahdollisuuden imeä Lean Startup-oppeja rennossa ”Koodausta ja kohellusta” iltatilaisuudessamme. Tällä kertaa ei oltu lavean viitekehyksemme koodauspäässä, mutta ei sentään pelkkää kohellustakaan ollut tarjolla.
Playing Lean peli toimii parhaiten alle 10 hengen ryhmällä ja saimme kasaan pienen mutta sitäkin monipuolisemman porukan. Rentoa iltaa tuli viettämään Hubblelaisten lisäksi pari toimitusjohtajaa, projektitutkija ja senioritason koodari. Allekirjoittanut sai toimia tilaisuuden sertifioituna Game Masterina.
Pelaamista ja vähän oppimista
Illan pääpaino laitettiin ajan puutteessa pelaamiselle ja tiettyjä pelin esiin tuomia oppeja Lean Startup ”metodologiasta” käytiin aika pikaisesti läpi ennen pelin aloitusta ja pelin aikana. Tarkoitus oli herättää mielenkiinto ja mahdollistaa pelin myötä oppiminen. Pöydällä olleet voittopokaalit tietysti haittasivat hieman keskittymistä, mutta pelin moninaiset säännöt saatiin kuitenkin käytyä hyvin läpi.
Peli sai näin työpäivän jälkeenkin kaikkien tarkkaavaisuuden vireille. Olikohan kyseisen päivän aikana kukaan keskittynyt yhtä tarkkaan pohtimaan mitä kannattaa kehittää, koska myydä ja kuinka paljon tehdä kokeiluja todellisten asiakastarpeiden selvittämiseksi.
Retro
Pelin jälkeisessä retrossa esiin tuli odotettu asia. Vielä enemmän oppimista olisi saatavissa, jos aikaa olisi enemmän ja esimerkiksi pelin aikana tehdyistä kokeiluista voitaisiin keskustella tarkemmin. Tämän tyyppinen tilaisuus toimisi esimerkiksi reilun aamupäivän mittaisena hienosti.
Peliä analysoitaessa voittavaksi tekijäksi muodostui strategia, joka ei painottanut erityisen vahvaa teknologista kehitystä, vaan asiakastarpeiden systemaattista selvittämistä ja tarpeeseen tehtyä tuotekehitystä. No, koska pelistä on kysymys, tuurillakin oli ehkä joku osuus.
Jälkipuheita, totta kai
Kovat panokset synnyttävävät aina kovat jälkipuheet. Pelin päätyttyä himoitut pokaalit saivat aikaan syytöksiä Game Masteria kohtaan. Pelissä oli kuulemma vuorot seonnut jossain kohtaa. Kuvitteellisen videotarkistuksen jälkeen tulokset pysyivät ennallaan.
Oli kiva ilta! Onnittelut voittajille ja kiitos osallistujille!
P.S. Lue Jukan tuuletuksista Linkedinissä
by Jani Nurmi | 31.08.2018 | Osaaminen, Yleinen
Hubble on koko ”pitkän” historiansa ajan hyödyntänyt AWS:n palveluja toteuttaessaan asiakasratkaisuja. Matkan varrella on osaamista tarttunut ja onhan sitä oikein ajatuksella hankittukin. AWS:n tarjoama on niin laaja, ettei siitä opiskeleminen kesken lopu.
Itseään toteuttava suunnitelma
Kesällä mieleen juolahti, että pitäisikö tuota tarttunutta osaamista täydentää ja käydä mittaamassa sitä sertifiointikokeen merkeissä. Varaamalla testiaika siitä tuli heti itseään toteuttava suunnitelma. Kokemuksen tuomia tietoja alettiin täydentämään muutamalla online-kurssilla, sekä erilaisilla testikokeilla. Kolmannen osapuolen testikokeista tuli esiin AWS:n valtava kehitysnopeus, kun yllättävän tuoreissakin kokeissa oli vanhentunutta tietoa. Ylemmän tason periaatteet ei tietysti muutu yhtäkkiä, mutta joitakin yksityiskohtia oli muuttunut.
Testitilaisuus
Itse testitilaisuus oli Helsingissä etävalvotussa ”kioskissa”. Etävalvonta tarkoitti kahta kameraa ja chätin välityksellä tavoitettavaa valvojaa. Ennen tilaisuuden alkua luettiin käyttäytymissäännöt ja esimerkiksi tunnistamiseen käytetyt passi ja ajokortti piti tunnistuksen jälkeen poistaa pöydältä.
Testisofta sinänsä tuntui aikaa nähneeltä ja kesken tullut jQueryn muistiongelma keskeytti kokeen hetkeksi. Sovelluksen uudelleenkäynnistyksen jälkeen homma jatkui kuitenkin normaalisti.
Koeohjeissa mainittiin, että WC-tarpeet piti ilmoittaa chätin kautta valvojalle ja pyytää lupa. Kun koetta oli vielä tunnin verran jäljellä, ei junamatkan aikana juotu kahvimäärä helpottanut olotilaa. WC-lupa-anomukseen tuli valvojalta tyly vastaus, tästä kokeesta ei kesken poistuta. ”Kupla otsassa”-henkisesti ja kiukulla testi loppuun.
Tulokset
Parin päivän päästä tuli tulokset. Koe oli läpäisty ja minkään osa-alueen osaaminen ei tarvinnut (kokeen mukaan) lisäopiskelua. Ennen testiin menemistä pohdin kuinka paljon se sisältää ulkoa opeteltavaa nippelitietoa. Testikokeissa sen tyyppisiä kysymyksiä oli, mutta varsinaisesta kokeesta ne puuttuivat lähes täysin. Koe keskittyi selkeästi olennaiseen ja pitkillä skenaariopohjaisilla kysymyksillä monivalintakysymyksistä oli saatu erittäin haastavia.
Oppiminen jatkuu
Nyt pitäisi tuon perusteella olla tiedot ja taidot suunnitella tietoturvallisia, vikasietoisia ja skaalautuvia ratkaisuja asiakkaillemme. Fakta tietysti on, että uuden oppiminen AWS teknologioiden tai minkään muunkaan teknologian puitteissa ei lopu koskaan.
Jani
P.S. Pidätyskyvystä pitäisi kyllä saada jokin oheissertifikaatti.
by Jani Nurmi | 29.01.2018 | Yleinen
Kävimme Samin kanssa AWS:n kehittäjäpäivillä Helsingissä tutustumassa mielenkiintoiseen kattaukseen. Sama setti oli tarjoiltu paria päivää aikaisemmin Tukholmassa. Tapahtumassa oli tarjolla mielenkiintoiset workshopit serverless arkkitehtuureista ja mobiilikehittämisestä AWS työkaluilla. Mutta kolmelle träkille jaetut luennot/demot palvelivat omaa tiedonnälkää enemmän. Träkit olivat serverless arkkitehtuurit, konttiteknologiat ja tietysti AI. Noista itseäni kiinnosti eniten serverless arkkitehtuurit ja AI.
Liikkeelle Porin seudulta pitää tietysti lähteä ennen kuin kukko on laulanut ja fakta on, että se ottaa hiukan tehoja pois iltapäivästä. Kattaus oli jo agendan mukaan sen verran hyvä, että ei annettu sen haitata. Päivä alkoi tietysti rekisteröitymisellä ja sen yhteydessä T-paitojen jaolla ja aamupalalla. Ensimmäiset sessiot kullakin träkillä oli yleisluontoinen katsaus aiheen nykytilaan. Katsoimme alkusetin AI-träkillä ja se vaikutti niin mielenkiintoiselta, että päätimme pysyä samassa huoneessa koko päivän.
Sessioiden taso vaihteli yksinkertaisista esittelyistä aina 8 GPU:n, 488 muistigigan monsterin säikeiden ja muistin käytön optimointiin mallien opettamisessa. Kuten muillakin osa-alueilla AWS:n palvelut koostuvat tasoista, joissa oma vastuu ja vaikutusmahdollisuudet vaihtelevat. Ylimmällä tasolla on täydelliset palvelut joita voi ruveta heti käyttämään APIen kautta. Toisella tasolla on palvelut, jotka kootaan itse pienemmistä palasista. Ja kolmannella tasolla on täysin räätälöitävät kokonaisuudet, joissa ainoastaan infran ylläpidon ja skaalaamisen huoli on poistettu.
Ylin taso, valmiit palvelut
Ylimmän tason esimerkit olivat kuvien, videoiden, tekstin ja puheen analysointia valmiiden palvelujen avulla. Demoissa analysoitiin em. materiaaleja, sekä luotiin yksinkertainen botti käyttäen Amazon Lex palvelua. Ylimmän tason palveluissa on esiopetetut mallit joiden avulla omaa materiaalia voi analysoida. Tällä tasolla liikkeelle pääsee hyvin nopeasti ja tutustuminen AI:hin voi alkaa.
Toinen taso, palasista kootut kokonaisuudet
Esimerkeissä käytettiin Amazon SageMakeria jonka avulla päästään nopeasti analysoitavaan dataan käsiksi esim. S3:n kautta ja voidaan käyttää valmiita algoritmeja (eli algoja). SageMakerissä homma lähtee liikkeelle Jupyter notebook instanssista, joissa on valmiina hyviä esimerkkejä. Mallien opetuksen ja testauksen jälkeen deployment vaiheessa mallille tulee oma API-osoite, jota voi alkaa käyttämään tuotannossa. Eri vaiheisiin voi tietysti määritellä erilaiset instanssit tarpeen mukaan. Tämä taso vaatii selvästi enemmän osaamista kuin ylimmän tason palvelut, mutta mukana on paljon valmista kuten 12 yleisintä ML algoritmia.
Kolmas taso
Alimmalla tasolla AWS:n avut kohdistuvat oman kustomoidun infran luomiseen omia Deep Learning tarpeita varten. Tällä tasolla ollaan tekemisissä suoraan eri instanssityyppien kanssa, jotka voi perustaa valmista AWS Deep Learning AMIn (Amazon Machine Image) käyttäen. Tällä tarve on tyypillisesti erittäin vaativien mallien ja suurien datamäärien analysointi. Tällä tasolla voi esimerkiksi säästää suuria summia rahaa käyttäen oikealla tavalla eri tyyppisiä instansseja ja niiden CPU tai GPU ominaisuuksia, unohtamatta suuren datamäärän siirtämisen tarpeita. Tällä tasolla saattaa tulla hyödylliseksi AWS:n spottihinnoittelu, joilla on mahdollista saada suuriakin kustannussäästöjä.
Kokemus
Hotelli Clarionissa järjestelyt toimivat hyvin. Omalle kohdalle päivän annista jäi erityisesti mieleen:
- Tietynlainen mystiikka aiheen ympäriltä väheni huomattavasti hyvien esimerkkien kautta.
- Erilaisia käyttökelpoisia valmiita malleja löytyy verkosta mitä ihmeellisimpiin tarkoituksiin.
- Jos valmiit mallit ei miellytä, valmista dataa oman mallin opettamiseen löytyy sitäkin paljon ja demoissa niitä hyödynnettiinkin.
- Mutta tärkeintä AI:n ihmeellisessä maailmassa on se, että kaiken A ja O on kuitenkin sen ongelman tai kysymyksen kuvaaminen mihin vastauksia halutaan.
Hoodies
Päivän piristys oli, kun yhden keskustelun päätteeksi kaveri totesi jotakuinkin näin ”Your company is only less than a year old and you already have hoodies. We had to wait for four years to get hoodies…” Satakuntalaisen positiivisessa hengessä voisi kai todeta, että ainakin yksi asia meillä Hubblessa on kohdallaan.
by Jani Nurmi | 11.12.2017 | Koodausta ja kohellusta
Meillä Hubblessa on jonkin aikaa kytenyt idea erilaisista koodaukseen tai softakehitykseen muutenkin liittyvistä tilaisuuksista joita voisi järjestää. Ja vähän ”kateellisina” seurattu muissa kaupungeissa järjestettyjä juttuja. Koska ollaan niin kokeiluhenkisiä, niin ei muuta kuin kokeilemaan. Santerilla olikin jo idea ensimmäisen tilaisuuden aiheesta, ”Git peruskoulutus ja keskustelu”. Satakunnan tietojenkäsittely –yhdistys innostui ajatuksesta ja päätti olla mukana sponsoroimalla tarjoilua.
Vaikka kovin monimutkaisesta asiasta ei ollut kyse, haluttiin sopivasti rakennetta kokeiluun. Otettiin ”Build – Measure – Learn” työkaluksi. Pohdittiin asiaa hyvin nopeasti takaperoisesti, eli mitä halutaan oppia, kuinka mitataan oppiminen ja viimeiseksi toteutus. Näin homma lyhykäisyydessään järkeiltiin.
Learn
Haluttiin oppia, onko koodaushenkisille tilaisuuksille tilausta. Mikä olisi hyvä ajankohta ja mitä tarjoiluja haluttaisiin. Kaikkia näitä voisi vaan kysyä, mutta kokeilemalla voi validoida ensimmäisiä arvauksia paremmin. Ja kokeilemalla näkee oikeasti, onko kiinnostusta vai ei. Pelkällä kysymisellä voi innostusta olla yllin kyllin, mutta ovipumppu ei vaan käy.
Measure
Mittaamiseen käytämme Google Formsia maksimissaan viiden kysymyksen setillä, jotta saamme oikeasti palautetta. Tietysti osallistumisintokin toimii mittarina.
Build
Sitten järjestämään. Ilmainen tilaisuus EventBriteen, jossa 10 lippua A-katsomoon arki-iltaan klo 18 alkaen. Sitten jaettiin EventBriten tapahtumaan linkkiä joillakin Slack-kanavilla, muutamalla Facebook-suvulla sekä LinkedInissä. Paikkana oli Hubblen toimisto ja tarjottavana kahvi, teetä ja Satkyn sponsoroima Sub Way –tarjotin for meat lovers.
Järjestelyt saatiin hoidettua järkevällä effortilla. Ilta sujui Gitin perusteisiin tutustuen ja keskustellen. Tietoa tuli laajalti ja paljon Gitin käytöstä esimerkkeineen. Keskustelua oli myös paljon. Ilmapiiri oli rento ja Subit maistui. Jo tilaisuuden loppupuolella todettiin, että koska seuraava Git-koulutus on. Great!
Palaute
Kaikkia kymmentä lippua ei varattu (8). Ne jotka varasivat paikan, myös saapuivat paikalle. Kahdeksasta osallistujasta viisi jätti palautetta.
- 100% vastaajista haluaa lisää Git-aiheisia tilaisuuksia.
- 60% vastaajista piti tilaisuutta erittäin hyödyllisenä tai hyödyllisenä ja loput 40% melko hyödyllisenä.
- 100% haluaisi ehdottomasti osallistua muihinkin koodausaiheisiin tilaisuuksiin.
- 80% pitää arki-iltaa noin klo 18 alkaen parhaana ajankohtana, 20% arki päivää 08-16 ja 20% viikonlopun päivää noin klo 12 alkaen.
- Päälimmäisenä mieleen jäi innostus Gitin kokeilemiseen, Santerin vankkumaton ammattitaito, branchit, repot ja hookit.
- Vapaassa sanassa todettiin, että leipä oli hyvää ja annettiin kouluttajalle muutamia vinkkejä tuleviin vastaaviin tilaisuuksiin.
Tästä opimme, että kyllä tämän tyyppisille tilaisuuksille on kysyntää. Ja helppo päätös Hubblessa oli, että vastaavia järjestetään jatkossakin. Mutta minkä yhteisen otsikon alle nämä tilaisuudet pitäisi laittaa. ”Koodausta ja kohellusta”. Se liittää tilaisuudet koodaukseen, mutta jättää vähintäänkin riittävästi liikkumavaraa muidenkin aiheiden käsittelemiseen.
Tilaisuus meni hyvin ja heikoin lenkki koko hommassa oli allekirjoittanut, joka ei tajunnut ottaa oheista kuvaa tapahtumasta ennen osallistujien poistumista.
Myöhemminkin pääsee aiheisiin tutustumaan koosteesta.
Kommentoi ja anna vaikka ehdotuksia ”Koodaus ja kohellus”-iltojen aiheiksi.
Ilmoittaudu myös ”Koodausta ja kohellusta” sähköpostilistalle, niin saat tiedot tulevista tapahtumista useita päiviä ennen muita.
by Jani Nurmi | 08.10.2017 | Kokeilukulttuuri
Senkus räpläätte
Valtakunnallisen kokeiluviikon innoittamana päätin kirjoittaa hiukan kokeiluista ja validoidusta oppimisesta. Kokeilukulttuuria syydetään lähes joka tuutista, enemmän tai vähemmän edellytyksenä menestykselle. No sitähän me Hubblessakin toitotetaan. Mielestäni usein kuitenkin unohdetaan validoitu oppiminen, ja sitä pitäisi korostaa enemmän kuin vain kokeiluja. Validoidun oppimisen pitäisi olla yksi tärkeä peruste kokeilujen tekemiselle. Kun puhutaan vain kokeilemisesta, tulee helposti mieleen hallitsematon räpläily minkä tahansa asian ympärillä. Toisaalta kokeiluihin mahdollistava johdon kommentti ”senkus räpläätte” voi olla se ainoa tarvittu palanen suurten innovaatioiden syntymiseen. Historia sen kertoo, että paljonhan niitä vahingossa on syntynytkin.
Pyrstö edellä puuhuun
Yksi kokeiluajatusten lähde ja itseänikin asian tiimoilta innoittanut kirja on Eric Riesin Lean startup. Ericin kuvaama malli on sangen yksinkertainen ja siksi pidän siitä. Sitä on helppo soveltaa lähes mihin tahansa toimialaan, kunhan ajattelee luovasti eikä asettele itse keinotekoisia rajoituksia. Build – Measure – Learn mallia käytetään paljon ja joskus haastan itseänikin ajattelemaan tuota mallia takaperoisesti. Eli pyritään ensin miettimään mitä halutaan oppia, miten se oppiminen saadaan validoitua ja sen jälkeen tehdään MVW (Minimum Viable Whatever).
Naama edellä
Normaali tapa on edetä toteuttamalla iteraatio rakentamalla ensin MVW, mittaamalla onnistumista ja keräämällä opit. Vaikka asiaa ajattelisi näin, haastan silti miettimään asiaa myös takaperoisesti. Kun päästään kiinni ajatukseen mitä halutaan oppia, on huomattavasti helpompi löytää sopivia ”määreitä” onnistumisen mittaamiseen.
Ja ensin se idea
Lean startup mallia voi käyttää, kun ensin on se idea. Digitaalisen tilannekuvan työpajoissa olen havainnut, että kyllä niitä ideoita löytyy, kunhan on hyviä tapoja saada niitä esiin. Erilaiset Game storming mallit ovat hyviä. Peleissä päästään eroon erilaisista ideointia haittaavista ongelmista, kuten esimerkiksi itsekritiikistä, desibeli ideoinnista (kovaäänisimmän idea on paras) tai HIPPO priorisoinnista (highest paid person’s opinion). Idean perusteella muodostetaan hypoteesi, jota lähdetään validoimaan kokeilumallilla.
Byrokratiaa peliin, not
Koska kokeiluissa halutaan olla nopeita ja ketteriä voi dokumentointi ja kokeilumalli jäädä pohtimatta. Kun palataan validoituun oppimiseen, on hyvä päästä asiaan uudestaan kiinni myöhemminkin. Ajatellen esimerkiksi tilannetta, jossa uusi työntekijä tulee taloon ja yrityksessä on hiljalleen saatu kokeilukulttuuria edistettyä. Kevyt dokumentaatio tehdyistä kokeiluista, validointitavoista ja oppimisesta on erittäin arvokasta tietoa uudelle kaverille. Pääsee heti kiinni ajatukseen, kuinka omia ideoita voisi kokeilla. Tai kun ajan saatossa jokin aikaisemmin kokeiltu hypoteesi nousee uudestaan pintaa, voidaan asiaa ensin lähestyä ajatuksella ”kuinka maailma hypoteesin ympärillä on muuttunut”. Kevyellä ja avoimella dokumentaatiolla on paikkansa. Ei hommaa tietenkään tule kuormittaa liian byrokraattisella rakenteella, mutta jokin kevyt toistuva tapa kokeilujen käsittelyyn tulisi olla. Tuo tapa tietysti kehittyy jatkuvasti. Liika byrokratia tunnetusti hoitaa koko homman niin, ettei validoitavia ideoita ja hypoteeseja ole eikä tule.
Fail fast, fail cheap
Kannustan teemaviikon mukaisesti kokeilemaan. Mielenkiintoa saa lisää, kun miettii miten asian saa kokeilemalla validoitua nopeasti ja halvalla.
Jani
