Neuroverkot – kuten ne ymmärrän (osa 2)

Reading Time: < 1 minute

Lainasin tuttavaltani Haykinin klassisen perusteoksen neuroverkoista: Neural Networks – a comprehensive foundation.

Nyt uteliaisuus heräsi. Mitä täältä löytyy?

Käy ilmi, että olisi aika ottaa myös selvää, tarkoitetaanko tekoälyllä ~jotakuinkin samaa kuin neuroverkko? Ja mikä sitten on se neuroverkko?

En tiedä muuttuuko tuolloin näkemys tekoälystä jotenkin emotionaalisella tasolla. Tuleeko tekoälystä “tylsempää” kun tietää mistä tarkkaan ottaen on kyse? Vai säilyttääkö menetelmä silti taianomaisuutensa ja jaksaako se innostaa? Näkeekö jostain hype-pölystä läpi, kenties, kun on asiaan vihkiytyneempi?

Millaisia mahdollisuuksia tekoälyn hyödyntämisessä on?

Ainakin tätä kirjoittaessa tuntuisi että kyseessä on jonkinlainen viisastenkivi. Tuntuu, että ei sellaista sovellusaluetta olisikaan, johon ei voitaisi soveltaa tuota maagista AI:ta. Siispä otetaan selvää.

Toivon että blogisarjasta tulee samalla hyödyllinen ja erityisesti yleissivistävällä tavalla myös kiinnostava.

Neuroni -sanan biologinen tausta

Sana ‘neural’ juontuu neuroneista, jotka ovat oikeita biologisia rakennuspalasiamme. Neuronit eli aivosolut ovat pienen pieniä “pusseja”, jotka toimivat hiukan kuin auton akut tai patterit. Niissä oleva liemi (neste) toimii elektrolyyttinä, joka kykenee pitämään noin 0.050 voltin jännitteen “solukalvon yli”. Eli sisällä oleva neste sisältää elektroneja, negatiivisia varauksia, enemmän kuin solun ulkopuolinen aine.

Neuronit muodostavat meidän ihmisten älymme ja tietoisuutemme. Neuroneja on hurja määrä aivoissa. Ne viestivät keskenään verkkona. Neuroni lähettää viestin eteenpäin, kun sitä on riittävästi ‘eksitoitu’ eli sisään on tullut tarpeeksi virtaa toiselta neuronilta (tai neuroneilta).

Osa 3 paljastaa jälleen lisää!

Neuroverkot – kuten ne ymmärrän (osa 1)

Reading Time: < 1 minute

Lähdetään liikkeelle:

‘AI’, tekoäly. Maaginen sana. Jotain mystistä. Mistä on kyse, kun puhutaan tekoälystä?

En tiedä.

Lähden aloittelijan mielellä liikkeelle.

Muutamia kysymyksiä

  • mikä AI:sta tekee niin “erityisen” poikkeavan verrattuna muuhun ohjelmointiin tai laskentaan tietokoneella?
  • ymmärtääkö tekoäly mitä se tekee?
  • saavutammeko ikuisen laiskottelun unelman tekoälyn avulla?
  • riittääkö että joku ohjelmoija tekee riittävän hyvän tekoälyn, joka hoitaa loput tekoälyjen ohjelmoinnit?

Olen ohjelmoinut vuodesta 1984. Tietokone on ollut ihana leikkikalu, mutta olen aina tienyt, että kaikki, mitä se tekee, tulee ohjelmoijan antamina ohjeina – ohjelmina.

Yllä olevasta johtuen tekoäly alkuun tuntuu ristiriitaiselta. “Tekoäly” tuntuu luultavasti niin kauan ristiriitaisena, kunnes sitä ymmärtää. Näin kuvittelisin. Haluan ymmärtää lisää.

Tällä hetkellä käsitän, että tekoäly on jonkinlainen sääntöverkon muodostama laskentaprosessi, joka… X. Niin. Jotain tuollaista. Tätä pidemälle en ole tekoälyyn vielä tutustunut. Koskaan en ole sellaista tai sellaisella ohjelmoinut. Itse asiassa tuossa on hyvä lisäkysymys:

  • voiko tekoälyn ostaa tai kopioida valmiina pakettina?

Matka jatkuu! Nähdään osassa 2!

Tech spikes – uuden oppiminen ja systemaattinen hyöty

Reading Time: 2 minutes

Tech spikes: pienet ja suuret testit & oppimiset työelämässä

“Spike” on termi joka tarkoittaa pientä normaalista
rutiinikehittämisestä poikkeavaa teknologista testiä / miniprojektia. Kuulin termin ekaa kertaa 2015 tienoilla softahommissa. Spike on mielenkiintoinen konsepti. Erityisesti viehätti sen nivelyminen “legopalikkamaiseen” ajatteluun, missä tavallaan oppimista voi konkreettisesti paketoida ja itse oppimisprosessin voi myös mahdollisesti jakaa muiden kanssa paremmassa muodossa kuin missä itse sen on vastaanottanut.

Varsinaisissa softaprojekteissa tulee usein vastaan oppimista ja epävarmuutta; uusia tuttavuuksia.

Tällöin kannattaa tehdä pieni erillinen testi jolla voidaan todentaa hypoteesit; tai kumota oletukset. Testi näyttää onko jokin asia mielekäs tehdä, tai ylipäätään tehtävissä.

Onko erillinen ‘spike’ perusteltua?

Oman kokemukseni perusteella, kyllä! Suosittelen – eli sen sijaan että antaa erilaisten teknologioiden viedä sivuhuomiota tai jatkuvasti “kyykyttää” aikatauluja, on parempi toisinaan selkeästi keskittyä tekemään yksi hallittu testi.

Älä nipistele perusasioiden kanssa: “plan”

Spike kannattaa mitoittaa normaalisti; se käyttäytyy usein lopulta aika lailla kuten muutkin ohjelmistoprojektin palaset: joskus mennään alle suunnitellun toteutusajan, toisinaan yli. Nipistelyllä tarkoitan sitä, että vaikka kyse on erillisestä oppimisesta, sille kannattaa silti varata myös aikansa ja paikkansa, sekä rakenne.

Jos itse tuotteen roadmap ja tarpeet ovat jotakuinkin selvillä, voidaan myös tällöin helposti napata samaan sprinttiin varmuudeksi myös seuraava spike – kunhan näillä on keskenään jokin looginen yhteys.

Eteenpäin “hiihtämällä” ilman tavoitteita voi helposti käydä niin, että puurot ja vellit menevät sekaisin: tuleekin liikaa uutta kerralla, ja voi olla
vaikea ymmärtää tai hahmottaa mistä jumitus kiikastaa.

Spike selkeyttää asioita tiimissä niin team leadille (projektivastaavalle) kuin tekijällekin.

Ihan konkreettisesti näin voi käydä jos esimerkiksi rakentaa CI -putkea (continuous integration) lätkimällä erilaisia komponentteja järjestelmään mutta ei malta tutustua niiden konfigurointiin, tai esimerkiksi komponentin soveltuvuusalueisiin.

Komponentti saattaa olettaa tiettyjä asioita toimintaympäristöstä, joita itse ei ole huomannut dokumentaatiosta (aina dokumentaatiota ei myöskään ole – asiat pengotaan lähdekoodista ja netin keskusteluista).

Spike: pre-flight check list

  • Mihin tarpeeseen opettelet?
  • aseta tekniselle testille selkeä maali ja polku: palasista kokonaiseksi
  • selvitä suurinpiirtein teknologian taustat; milloin ja millaiseen
    käyttöön kyseinen teknologia syntyi?
  • esimerkiksi:
    • “Karma” oli alunperin Googlen sisäinen yksikkötestaustyökalu, nimeltään Testacular
    • keskeisenä voimahahmona kehittäjä nimeltä Vojta Jina
    • Vojta esittelee v. 2012 tekniikan tällä videolla:
      https://www.youtube.com/watch?v=5mHjJ4xf_K0
    • videon katsomalla ymmärtää taustat helposti
  • saatat esimerkiksi tarvita syvempää osaamista aihepiiristä..
  • tai tiedät, että pitää oppia täysin uusi teknologia
  • esimerkkinä: en osaa Djangoa (Python framework)
  • asetetaan maalit:
    1. ymmärrän Djangon perusperiaatteet ja kykenen selittämään ne alle 1 minuutissa
    2. käsitän, miten Django eroaa ja toisaalta on yhtenäinen “kilpailijoiden”
      suhteen
    3. saan Python-serverin (paikallinen) pyörimään
    4. Djangon framework asennettuna omalla läppärilläni
    5. osaan koodata Djangon päälle pienen testiohjelman, jolla näytän sen että osaan myös
      käytännön
  • säilö opetusreissut toisille tiimissä
  • laita “git”:llä pakettiin
  • sopiva määrä committeja -> esimerkiksi ainakin
    1. initial commit -> aivan perusasiat, voi olla vaikka pelkkä README tai TODO lista
    2. infra kunnossa -commit
    3. kirjoita myös README.md (dokkariin) miten tarkkaan ottaen tuleva käyttäjä
      voi kävellä askeleesi omalla koneellaan
    4. jne
  • tee koko spike siten kuin “oikeasti tekisit” myös projektia
  • ennen kehittämistä, tee aikamääräarvio: hyödyt myöhemmin, vie vain hetken
  • pilko projekti selkeisiin aliosasiin
    • sub tasks
  • määrittele funktionaalinen selkeästi mitattava maali
  • tutki miten hyvin tai huonosti arviosi osuu maaliin
  • jaa myös tämä kokemus ja mahdolliset opit itse arviointimenetelmän suhteen muille
  • mitä odottamatonta tapahtui matkalla?

SIM, kuokka ja Jussi

Reading Time: 3 minutes

Tietyt asiat muuttuvat oikeasti aika hitaasti. Vaikka elämme tietyllä tapaa teknologisesti pitkälle kehittyneessä yhteiskunnassa, on mielenkiintoista palata juurille, ja tarkastella perusasioita. Käydään mobiilimaailman historia nopeasti läpi. Päästään rautakaudesta lasijakson kautta uusien tuntemattomien äärelle.

SIM-kortti pikafaktat

  • sanoista “Subscriber identity module”
  • se pikkuinen “siru” joka laitetaan kännykkään sisälle, kun otetaan kännykkä käyttöön ensimmäistä kertaa
  • SIM-kortti teknisesti tunnistaa mobiiliverkkoon tilaajansa (eli kännykkäliittymän omistajan) identiteetin
  • ensimmäiset SIM-kortit luotiin 1980-luvun lopulla
  • SIM kaupallistettiin osana matkapuhelinteknologiaa 1990-luvulla
  • Suomessa Radiolinja -niminen operaattori
  • SIMmejä käytetään sekä prepaid-liittymissä että kuukausimaksullisissa vakio

Pala elektroniikkaa, joka on kuin paita ja peppu kännykälle. SIM-kortti on kenties konkreettisesti näkyvin osa meidän digitaalista identiteettiämme. Kortti on muuttanut hieman muotoaan ajan saatossa. Sen ydinalue on edelleen aivan sama, mutta ympärillä olevaa hyödytöntä muovia on leikattu pois. On saatu 3 erilaista SIM-kortin kokoa.

  • Ovatko perusongelmat ratkenneet, vai joudutaanko niitä vain muuttamaan muodosta toiseen, ja kiertämään, kun varsinaisesti “täydellistä” ratkaisua ei tunnu löytyvän?
  • Jos lisäämme kerroksia digitaaliseen “täytemaahan”, miten se vaikuttaa tuotteen ominaisuuksiin ja hintaan?
  • Säästetäänkö koodin (modulien) kierrätyksellä työaikapohjaisissa kustannuksissa, siten kuin erityisesti tietoteknologian unelmana / tarkoituksena on ollut?

Tekniikka on aina kokonaisuus. Tuotesuunnittelun tärkeimpiä kulmakiviä esimerkiksi kännyköissä on ymmärtää se, missä tilanteessa oikeasti puhelinta käytetään. Puhelin ei koskaan ole yksin, toisinsanoen kokemuksen laatu riippuu myös esimerkiksi tukiasemien ja teleoperaattorien luomasta ympäristöstä.

Mennään ajassa taaksepäin. Otetaan esimerkiksi Kontakti. Ammoisina aikoina GSM-puhelimissa niiden eräs suurimmista innovaatioista oli – kyllä, digitaalinen henkilökohtainen puhelinluettelo. Siis jokainen puhelimen omistaja pystyi tallentamaan kätevästi puhelimeen tuttaviensa ja palvelujen puhelinnumerot:

Jukka 0400635966

Iskä 0400123987

Äiti 0400567812

Kaveri 0400999112

Pizzeria 091234888

Kaikki oli hyvin, kunnes tuli ensimmäinen raja vastaan: muisti loppui! Jep. Kuulit oikein. Useissa puhelinmalleissa oli silloin käsittämättömän vähän pysyvää, haihtumatonta muistia eli tallennustilaa. Puhelimissa oli esimerkiksi tilaa vain noin 100 kontaktitiedolle. Ja nyt tulee iso salaisuus: tuo muisti ei ollut puhelimen, vaan SIM-kortin rajoite!

Miksi yhteystieto tallennettiin SIM-kortille, eikä puhelimeen?

Tallentamalla kontaktitiedot SIM-kortille, varmistettiin että vaikka vaihtaisit puhelinta, tietosi olisi automaattisesti myös uudessa puhelimessa – ja mikä tärkeintä, poissa vanhasta – mikäli vanha puhelin meni uudelle omistajalle. Kätevää!

(Tiedätkös mitä? Ei aivan pidä paikkansa. Usein puhelimessa oli mahdollisuus käytettävyyden lisäämiseksi, eli mukavuussyistä, kopioida kontaktit puhelimenkin muistiin – ja tietysti näin tuli ensimmäinen tietoturvaongelma GSM-puhelimeen! Jos ei muistanut itse pyyhkiä kontakteja pois puhelimesta sitä myytäessä tai hävittäessä, kontaktisi jäivät seuraavalle käyttäjälle… Sama asia tekstiviestien kanssa)

Usean kuluttajalaitteen ongelma

Kännyköiden lisäksi alkoi ilmestyä myös PDA-laitteita. Ne olivat pieniä taskutietokoneita. PDA-laitteista usein puuttui tosin eräs keskeisimpiä GSM-puhelinten ominaisuuksia, nimittäin juuri tuo mobiiliverkon tuki. Eli käytännössä PDA:lla pystyi käsittelemään ja tallentamaan isohkoja tietomääriä, muttei siirtämään niitä “livenä” Internetin yli, ja ei myöskään pystynyt useinkaan tekemään lainkaan normaaleja digitaalisia puheluita.

Myöhemmin syntyvä tuntemamme älypuhelin oli oikeastaan kännykkä + PDA yksissä kuorissa = yksi laite. Ja tämä oli hyvä asia!

Käytettävyys + design = tae menestyksestä?

Laitteet älykkyys ja hyödyllisyys riippuu lopulta oikeastaan siitä, miten hyvin laitteen suunnittelu- ja toteutustiimi on osannut asettua kuluttajan sukkiin, ja nähdä ennalta erilaisten tilanteiden esiintymisen. Hyvässä ratkaisussa myös huomioidaan tuntemattoman ennakoimisen vaikeus jättämällä sovelluskehittäjille avoimet ovet tehdä parannuksia.

Älylaitteiden kehittely on jatkuvasti myös äärirajoilla elämistä. On arvioitava ja ennakoitava tulevaa. Myös tarpeita, joita ei vielä ole. Steve Jobs sanoi, hieman Fordia mukaellen, että jos käyttäjiltä olisi kysytty liikaa ennen Applen iPhonen markkinoilletuloa, sitä tuskin olisi syntynyt nykyisenlaisena. iPhone löi ällikällä teknologiamaailman spektaattorit. Se oli eräänlainen unelmien ruumiillistuma, paljon maailmalla liikkuneita ideoita konkretisoituneena oikeassa ja erittäin hyvin yhteen toimivassa paketissa.

Design kaipaa siis ymmärrystä antropologiasta, meidän ihmisten tavoista tehdä ja tavoista käsittää asioita. Laitteen käyttäjä on kuin se kuuluisa asiakas, joka valittaa sopassa olevasta kärpäsestä; vaikka kyseessä on pippuri, asiakas on aina oikeassa. Paitsi teknologian kohdalla on myös eräs valitettavan kavala ansa: asiakas ei usein jaksa valittaa ongelmista. Koska tarjoamaa eli kilpailijoita yleensä aina on saatavilla, tyytymätön asiakas voi äänestää jaloillaan ja valita kilpailijan.

Mobiilimaailmassa käytiin kiivasta “rautajaksona” tunnettua kehityskautta. Sitten tuli iPhone I. Vuosi oli 2007. Jobs leikitteli yleisönsä kanssa ajatuksella, että Apple julkaisisikin tällä kertaa kolme erillistä laitetta. Tämä oli näpäytys kilpailijoiden ajattelulle. Ei – laitetaan kaikki yhteen. Tehdään paras laite maailmassa. Nyt loppui insinöörisäätäminen!

Olisiko iPhone sitten aloittanut lasijakson? Puhelimesta otettiin pois kaikki ylimääräinen, ainoastaan iso, kaunis ja kirkas ruutu jäi jäljelle – kaikki oli kosketusnäyttöä.

Kuluttajia kutkuttavia oikeita sovellusalueita oli vaikea löytää ennen lasijaksoa. Toki oli merkittävää, että ihmiset kykenivät keskustelemaan mistä vain ja milloin vain. Ja lähettämään tekstiviestin. Silti, edessä oli vielä paljon nähtävää!

Ennen lasijaksoa teknologian kehityksessä oli kyse propellipäiden teknologiafetisismeistä, jotka puettiin muotoon joiden toivottiin myös houkuttelevan suurempaa yleisöä. Mobiliiteknologian ympärillä oli valtavasti kuhinaa.

Kehityksessä tapahtui vaihe, jossa käyttöjärjestelmät vakiintuivat ja löysivät oman “riittävän” kehitystasonsa. Perustavanlaatuiset ongelmat eivät enää olleet tukkeena todellisten sovellusten syntymiselle. Muistia (RAM) alkoi riittää, oli nopeita mobiiliverkkoja tiedonsiirrolle, ja tukiasemapeitto kasvoi. Silti kustannukset pystyttiin pitämään kurissa. Massatuotannossa pystyttiin tuottamaan laitteita, joiden hintalappu olisi vain muutama vuosi aiemmin ollut helposti 10-kertainen.

Kolmannen osapuolen sovelluksia oli helppo tuottaa markkinoille. Ainakin toistaiseksi operaattorien rooli sovelluskaupassa on minimaalinen. Eräs skenario oli, että teleoperaattorit tulisivat saamaan huomattavasti suuremman jalansijan appien markkinoista. Teleoperaattorit nimittäin ennakoivat kiristyvän kilpailun alueella, jossa pelkästään myydään GSM-verkkoa, SIMmejä ja mobiilia bittiputkea 4G-verkossa.

Palautteen käsittely: 3 kultaista periaatetta

Reading Time: < 1 minute

Organisaation tulee kyetä 3 asiaan, kun se saa palautetta:


a) palkitse palautteen lähettäjä
– tai ainakin kannusta palautteen antamiseen jatkossakin
– henkilökohtainen kiitos tai julkinen meriitti on myös eräänlaista palkitsemista. Ole kohtelias ja huomaavainen jos julkaiset palautteen antajan nimen – kysy lupa.
– antiteesi: älä torju palautetta. Voit keskustella siitä, mutta palaute on aina hyvä asia

b) kannustaa palautteen mahdollisesti vastaanottavaa tahoa olemaan vilpitön ja läpinäkyvä (organisaation työntekijä, voi olla conflict of interest eli välttämättä työntekijä ei koe olevansa “turvassa” palautteen ollessa negatiivista sävyltään)

c) organisaation pitää kyetä itse muuttumaan ja oppimaan, mikäli palaute on aiheellinen ja selkeästi asia joka kannattaa korjata