Mikä ihmeen serverless?

Serverless on vuoden 2018 hypesana. Muutaman vuoden takaisen Docker-huuman tapaan monet yritykset tulevat tekemään uusia ja siirtämään nykyisiä palveluitaan serverlessiksi markkinoiduille alustoille. Onkin syytä katsoa mistä asiassa on kyse.

Isompi trendi serverlessin takana on erilaisten liiketoimintojen muuttuminen dataintensiivisiksi. Paradigma IT-puolella tunnetaan nimellä Streaming Platform, joka pohjautuu erilaisten datavirtojen hallintaan. Dataa tulee jatkuvasti lisää, saapuvalla datalla sekä jo aiemmin talletetulla tehdään laskentaa ja sitä säilötään myöhemmin käytettäväksi. Data tallennetaan erilliseen tietovarastoon, ja koska sitä ei jatkuvasti muokata tai käsitellä, on käsittely muuttunut erilliseksi toimeksi.

Yksinkertaisimmillaan data otetaan tietovarastosta, sillä tehdään laskentaa ja tulokset lähetetään käyttäjälle tai talletetaan takaisin tietovarastoon. Samoin saapuva uusi data tai yksittäinen API-pyyntö voidaan haluta käsitellä kertaalleen ilman, että sitä varten on jatkuvasti odottamassa yksi tai useampi palvelin.

Streaming Platform -visualisaatio
Streaming Platform -näkemys Confluent-yrityksen blogista.

Serverlessissä onkin kyse ennen kaikkea ohjelmiston tilattomuudesta. Tilattomuus tarkoittaa, että ohjelmisto saattaa olla PHP-koodin tapaan ajossa vain suorituksensa ajan ja tieto sen tekosista on oltava tallessa jossain sen ulkopuolella, kuten vaikkapa tietokannassa. Hajautettujen järjestelmien yleistyessä on yhä tavallisempaa, että ohjelmistosta on ajossa useampia, jopa satoja, kopioita kerrallaan.

“Serverittömät” palvelut ovat viime vuosina ottaneet sellaisia hyppäyksiä, että termin merkityskin on mennyt matkalla uusiksi. Aikojen alussa eli vielä muutama vuosi takaperin serverless tarkoitti puhtaasti Backend as a Service -tyyppisiä ratkaisuja, joissa pilvitarjoajalta ostettiin tietokantoja tai vaikkapa koneoppimisinfrastruktuuria palveluna. Sittemmin serverless on siirtynyt tarkoittamaan enemmän Function as a Service -tyyppisiä palveluita, joissa yksittäinen pieni tai isompi osa koodia siirretään ajettavaksi palveluntarjoajan suoritusympäristössä. Koska koodi on ajossa vain suorituksen ajan, ei sillä ole erillistä tilaa ja kaikki tilaan liittyvä on haettava erikseen tietokannasta tai esim. AWS:n S3-bucketista. Samanlaiset tilattomat palvelut ovat viime vuosina yleistyneet Docker-konttien ja mikropalveluiden myötä, joten aiemmin luodut tilattomat softat toimivat näppärästi myös serverless-ympäristöissä. Näiltä osin yritys voi luopua myös palvelinylläpidosta, sillä tämä hoituu lähes poikkeuksetta serverless-palveluntarjoajan puolelta.

Kriittisiäkin äänenpainoja on kuultu. Yleisin, hiukan kyyninen näkemys on että kyseessä ei ole mitään uutta. Jo mainittu PHP-ohjelmakoodi on suorituksessa vain ajonaikaisesti ja jo ensimmäisistä webhotelleista löytyi Perlin suorittamiseen tarkoitettu cgi-bin-hakemisto. Serverlessin vahvuus tulee kuitenkin ennen kaikkea ympäristöstä, jossa kaikkea ei tarvitse tehdä enää funktiotasolla. Esimerkiksi AWS:ään pystyy helposti rakentamaan ympäristön, jossa mm. autentikaatio ja osin myös autorisointi on hoidettu ennen pyynnön saapumista serverless-ympäristössä olevalle funktiolle.

Yllä olevaan twiittiin viitaten serverless voi olla hyvä ratkaisu myös keittiön kanssa. Vaikka palveluntarjoajilla on halu esittää asian olevan hyödyllinen ainoastaan heidän ympäristössään, voi serverlessistä olla isojakin hyötyjä myös osana omaa palvelinympäristöä.

Vauhtia fronttiin Vuella

Aloitin tammikuussa Codentolla uutena työntekijänä, ja ensimmäisten viikkojen aikana pääsin mukaan mielenkiintoiseen sisäiseen projektiin, jossa tarkoituksena oli tuottaa nopeasti prototyyppi avoimia rajapintoja hyödyntävästä business casesta. Vaikka tällä alalla uuden oppiminen ja uusiin teknologioihin tutustuminen on jatkuvaa, ensivilkaisulla projektin palvelinpuoli näytti silti mukavan tutulta: käytetyt backend-teknologiat olivat Node.js ja Express. Suorastaan ydinmukavuusaluetta!

Käyttöliittymässä tulikin sitten vastaan Javascript-framework, josta en ennalta tiennyt mitään muuta kuin nimen: Vue.js. Se lupaa olevansa progressiivinen, asteittain käyttöönotettava framework reaktiivisten käyttöliittymien rakentamiseen. Tämä tarkoittaa, että Vue integroituu helposti olemassaolevaan web-sovellukseen pala kerrallaan. Esimerkiksi Gitlab on kirjoittanut paljon omista hyvistä kokemuksistaan Vuen käyttöönotossa.

On tosin huomattava, että tämä siirtymä tapahtui melko vanhanaikaisesta, puhtaasti JQueryllä toteutetusta sovelluksesta nykyaikaiseen frameworkiin, ja tässä kohtaa mikä tahansa ratkaisu olisi tarjonnut merkittäviä parannuksia. Heidän tapauksessaan valinta osui silti Vueen – paljolti niistä syistä, jotka ovat olleet sen suosion takana laajemminkin: yksinkertaisuus ja helppokäyttöisyys. Viimeisimmän State of Javascript -raportin mukaan Vuen suosio vaikuttaisikin olevan selkeässä kasvussa.

Usein kehittäjien keskusteluissa Vue vertautuu ennen kaikkea Facebookin tukemaan Reactiin. Vue ja React ovat osapuilleen saman ikäisiä, ja niissä molemmissa tieto liikkuu sovelluksen sisällä esimerkiksi AngularJS:ää kurinalaisemmin. Reactin tapaan Vue käyttää virtuaalista dokumenttipuuta, joka mahdollistaa paljon sujuvamman käyttökokemuksen laajoissa webbisovelluksissa. Vue onkin ominaisuuksiltaan riittävän samankaltainen suhteessa Reactiin, että teknologiavertailu menisi tämän tekstin laajuudessa liian pikkutarkaksi, joten vertaillaan mielummin sitä miltä työkalu tuntuu käteen ja millainen tuntuma sen käytöstä on jäänyt – eli toisin sanoen keskittykäämme kiistelemään makuasioista.

Templatointi tuntuu olevan mielipiteitä jakava kysymys. Vuen tapa käyttää templatointia on hyvin selkeä ja johdonmukainen: .vue-komponentti rakentuu templatesta, ohjelmakoodista ja valinnaisista muotoilumäärittelyistä, jotka ovat kaikki samassa tiedostossa, ja jotka hyvin rakennettuina pystyy hahmottamaan yhdellä vilkaisulla. Vuen templatointikieli tuskin on kenellekään kehittäjälle vaikeaa opetella, koska Vue kehittää eteenpäin monia aiempien ratkaisujen hyviä puolia.

Vue on tällä hetkellä Reactiin verrattuna pitkälti yhden ihmisen projekti. Tästä huolimatta kirjastotuki alkaa olla tuotantokäyttöön riittävä, ja projekti tarjoaa omasta puolestaan useita oleellisimpia peruskirjastoja, kuten esimerkiksi monista muista kirjastoista ja frameworkeista tutut router- ja store-kirjastot. Vuessa vetoaa ennen kaikkea se, miten nopeasti prototyyppejä saa luotua, ja miten helppoa prototyypistä on kasvattaa toimivia webappeja. Sisäisessä projektissamme sekä uuden teknologian haltuunotto että prototyypin tekeminen sujui tuskin paljon viikkoa pidemmässä ajassa, ja kokemukset maailmalta kertovat, että prototyypin jalostaminen tuotantokypsäksi tuotteeksi onnistuu Vuella myös varsin ketterästi.

Tiivistetysti sanottuna Vue tuntuu ennen kaikkea kustannustehokkaalta vaihtoehdolta. Näkymistä ja komponenteista on helppo rakentaa selkeitä ja yksinkertaisia hahmottaa. Projektiin ei välttämättä tarvitse etsiä spesifisti Vue-kehittäjiä, kun oppimiskynnys on kenelle tahansa matala. React jatkaa varmasti ansaitusti menestyksekästä taivaltaan käyttöliittymäteknologiana Vuen suosion kasvusta huolimatta, eli “Reactin tappajaa” Vuesta ei tule löytymään. On silti aina eduksi, että hyviä ja keskenään erilaisia vaihtoehtoja on useita. Siili järjestää 21.3. tietääkseni Suomen ensimmäisen Vue.js -tapaamisen – kuhinaa Vuen ympärillä on siis jo meillä Suomessakin.

 

PS Jos olet kiinnostunut Vuesta, on meillä tilaa osaajille! Täältä pääset hakemaan.

Ketterän hankinnan trendit

Ketterä hankinta on teema, josta käydään innokkaasti keskustelua – mutta mitä se oikeastaan tarkoittaa? Suomessa ketterällä hankinnalla viitataan tällä hetkellä yleisimmin kolmeen asiaan: 1. Kokeilujen tai protojen hankinta, 2. Määritellyn pienimmän julkaistavan tuotteen (MVP) hankinta + iteratiivinen jatkokehitys ja 3. Resurssien ostaminen itse johdettavaksi. Suomessa vaihtoehdoista suosituin on tällä hetkellä numero 3 eli resurssien ostaminen itse johdettavaksi. 

Trendinä resurssien ostaminen

Kun resurssit ostetaan itse johdettavaksi, ei siis osteta ohjelmistoa tai lopputulosta, vaan hankitaan ohjelmistokehityksen ammattilaiset omaan ohjaukseen työskentelemään kohti parasta mahdollista lopputulosta. Tähän houkuttelee ohjelmistoalan ympärillä kuhiseva tekemisen into ja halu saada aikaan jotakin omaa.

Resurssiprojektit päättyvät vaihtelevin lopputuloksin. Onnellisimmissa tapauksissa tuloksena on intoa piukassa oleva kehitystiimi ja asiakkaat ennennäkemättömän tyytyväiseksi tekevä palvelu. Masentavammissa tapauksissa juututaan vuosiksi ankeaan junnaukseen: tekemistä tuntuu olevan aivan liikaa ja lopputuotteesta tuntuu tulevan vaikeasti hallittava jouluhimmeli.

Miten ketterässä hankinnassa onnistuu?

Millä sitten voi huolehtia siitä, että pääsee onnelliseen onnistujien joukkoon ja ehkä pokkaamaan palkintopokaalinkin softa-alan gaalassa? Varmistettavia asioita on viisi.

1. Läpinäkyvyys. Läpinäkyvyys on ketterän hankinnan tärkein riskienhallintakeino. Huolehdi, että se otetaan vakavasti kaikilla tasoilla. Sisällytä sopimukseen koodin tallentaminen säännöllisesti versionhallintaan. Etsi mittarit, joiden pohjalta projektissa syntyvää (asiakas)arvoa pystytään seuraamaan jatkuvasti. Ja kun olet löytänyt tiimiisi ohjelmistokehityksen kirkkaimmat tähdet, huolehdi läpinäkyvyydellä ja aktiivisella kommunikoinnilla, että heillä on käytössään tieto, jota projektin tavoitteiden saavuttamiseksi tarvitaan.

2. Visionhallinta. Ketterässä projektissa visionhallinta on muutokseen reagoimista, sillä ketteryyden etu tulee kyvystä hyödyntää projektin varrella löydetyt oivallukset. Huolehdi siis, että on olemassa hyvä tapa hankkia käyttäjäpalautetta ja reagoida siihen. Vie priorisoinnin ajatus äärimmilleen: millaisia ovat ne 20 %:n ratkaisut, jotka täyttävät 80 % tarpeesta? Kun niitä löytyy, jää maksimaalisen paljon aikaa palvelun jalostamiseen käyttäjäpalautteen perusteella ja ketteryydestä saadaan irti oikeaa hyötyä.

3. Vastuun ottaminen teknologiavisiosta. Teknologiapäätösten jättäminen kokonaan tiimille johtaa pahimmillaan ylläpito-ongelmiin. Kehittäjät ymmärrettävästi haluavat työskennellä kiinnostavimmilla uusimmilla teknologioilla – ongelmana vain on, että niille ei välttämättä vielä löydy erityisen paljon tukea tai ne voivat jäädä tähdenlennoiksi. Viisaalla ketterällä ostajalla on tukenaan teknologiaa valittaessa joko selvitys markkinatilanteesta tai toinen mielipide, jolla ei ole omaa lehmää projektin ojassa. Niiden avulla kehittäjien mielipiteet loksahtavat osaksi isompaa kuvaa.

4. MVP-budjetointi. Julkaisemalla startup-termein pienimmän julkaistavissa olevan tuotteen (minimum viable product) mahdollisimman aikaisin varmistat, että ketteryydelle eli toiveisiin vastaamiselle jää oikeasti projektissa aikaa. Jos 90 % budjetista käytetään projektin ensimmäisenä päivänä listattuun toiminnallisuuteen, olisit yhtä hyvin voinut ostaa tuotteen toimittajan riskillä ja säästää hermojasi ja resurssejasi. Jos taas pienin julkaistava tuote saadaan julkaistua jo 50 %:n kohdalla budjetista, loppuaika saadaan käytettyä jalostamiseen palautteen pohjalta, ja käyttäjistäsi tulee paljon tyytyväisempiä kuin he olisivat ikinä olleet perinteisellä tavalla tuotetun tuotteen kanssa.

5. Vastuu yhteistyön johtamisesta. Vaikka tiimisi ohjelmistokehittäjät olisivat kuinka lahjakkaita, huono vuorovaikutus pilaa työtehon projektissa kuin projektissa. Testaa siis yhteistyötaidot hankinnan aikana vaikkapa päivän mittaisella koodausleirillä. Varmista, että projektiasi päivittäin johtava tuoteomistaja on vähintään yhtä kokenut kuin kehittäjäsi. Huolehdi, että jatkuvan oppimisen ideaa noudatetaan projektin arjessa ihan käytännössä, vaikkapa retrospektiivien muodossa. Se on ketterä kilpailuetu, josta ei kannata vapaaehtoisesti luopua.

Oletko valmis ketterään hankintaan?

Loppuun ketteryyskonsultin antimainos: Ketterien resurssien ostaminen itse johdettavaksi pitäisi olla aina viimeinen vaihtoehto. Siihen pitäisi päätyä vasta, kun on huolellisen pohdinnan jälkeen todettu, että projektin tuotevisio on niin eksoottinen tai edistyksellinen, ettei sen vaatimuksia mitenkään pystytä muokkaamaan vastaamaan markkinoilla olevaa SaaS-ratkaisua tai valmistuotetta.

Resurssipohjaisen kehityksen ohjaaminen menestykseen vaatii ostavalta organisaatiolta paljon visiota ja energiaa. Molemmat ovat kallisarvoisia voimavaroja, joita ei kannata tuhlata toissijaisiin projekteihin.

Kun tämä varmistus on tehty, ohjelmiston visiolakana on hyvä mittari siitä, oletko valmis ketterään ostokseen. Jos lakanan tiedot on helppo täyttää, kotiläksyt on tehty.

Onnea projektiin (muista myös valmistella se gaalapuhe)!

Voimmeko auttaa?

Ota ketterän hankinnan kysymyksissä yhteyttä joko allekirjoittaneeseen karoliina.luoto@codento.com tai toimitusjohtajaamme petri.aukia@codento.com

Lisää SlideSharessa

Yksityiskohtaisemmin ketterän hankinnan teemoja käsittelee Slideshare-esitys Projektipäiviltä.

 

Lean-projektikartta – miten saan ensi vuoden projekteihin järkeä?

Budjetointirumbaan liittyy paljon kimurantteja haasteita ja vankkoja perinteitä: näin on tehty ennenkin -mallista rahanjako pärstäkertoimen mukaan -malliin. Perinteiset mallit voivat olla epäreiluja ja ne eivät aina kannusta osastoja etsimään optimaalista tasapainoa uuden kehittämisen ja vanhan ylläpitäminen välille.

Käytän termiä lean-budjetointi, mutta oikeastaan malli soveltuu kaikille – vaikka et tuntisi leaniä omaksesi, tämä on fiksu tapa tehdä budjetointia.

Perinteisellä tavalla budjetointi on myös loukku – siinä budjetti rakentaa raja-aidat, jonka takaa voi olla vaikea vapautua. Fiksumpi tapa budjetoida vapauttaa ja tekee todellisen kehittämisen ja mullistukset mahdolliseksi.

Ensi vuosi suunnitellaan todellisuudessa jo budjettia laadittaessa ja Codenton lean-projektikartta on työkalu, jolla teet tilaa niille parannuksille, joita organisaatiosi tarvitsee.

Minkätasoinen lean-budjetointi sopii teille?

Organisaatioilla on erilaisia valmiuksia ohjata toimintaansa ja kehitystä vauhdilla muuttuvassa toimintaympäristössä. Tätä kyvykkyyttä jatkuvaan kehitykseen kuvataan myös lean-kypsyystasoksi – eli tasoksi, jolla organisaatio on menossa kohti nopeampaa reagointikykyä, läpinäkyvyyttä ja kokeilukulttuuria. Startupin ketteryysihanne on luonnollisesti eri kuin suuren korporaation tai julkishallinnon organisaation, ja niin pitääkin olla.

Monesti käytännön kehittämismalli on jonkinlainen yhdistelmä toisaalta vuosikellon mukaan pyörivää päätöksentekoa ja budjetointia, toisaalta tiheämpi syklistä, muuttuvampaa ja läpinäkyvämpää kehittämistyötä.

Ketteryyden saavutetusta tasosta riippumatta asettaa budjettikehyksen kehitystyölle. Jos päädytään ultraketterään toimintamalliin, käytössä on täysin lean budjetointi. Siinä koko toiminta on havainnoitavissa mittareiden avulla, ja panoksia pystytään lyhyissä sykleissä laittamaan niihin kohtiin systeemiä, jotka juuri nyt ovat merkittäviä tavoitteiden saavuttamisen hidasteita tai mahdollistajia.

Perinteisemmissä päätöksentekomalleissa leanissä budjetoinnissa lähdetään usein liikkeelle varmistamalla, että budjetointi mahdollistaa kehityksen kohti läpinäkyvyyttä ja jatkuvaa kehitystä, ja että budjetissa löytyy tilaa tehdä kokeiluja.

Kokeilut ovat usein pitkäjänteiselle menestykselle elintärkeitä – ja monesti ajatellaankin, että budjetista pitäisi käyttää jopa 25 % mullistavaan kehittämiseen.

Lean-projektikartta tukenasi

Laatimamme lean-projektikartta on konkreettinen leanin budjetoinnin ensiaskel. Sillä varmistat, että lean-kehityksen pohja ja kokeilut tulevat budjetoinnissa – ja sen myötä projekteissa – huomioiduiksi.

Lean-projektikartassa tasapainotetaan asiakkaan, ympäristön ja toiminnan kehittämisen osa-alueet. Ja on tärkeää, että jokaisella osa-alueella haetaan oikea fokus strategisen kehittämisen, ylläpidon ja kilpailijoita nopeampaan uudistumiseen vaadittavien mullistavien kehityshankkeiden kautta.

Lataa lean-projektikartta täältä >>

Miten onnistua mittaamisessa?

Ilman nappiin osuvaa mittaamista et voi varmistua siitä, parannettiinko jotakin vai ei. Mittaamista pohdittaessa nousevat pintaan keskeiset mitä, miksi, miten -kysymykset. Valitettavasti turhan usein unohtuu tärkeä kysymys: mitä ei tarvitse tai kannata mitata.

Älä mittaa mittaamisen vuoksi

Mittaamisen tärkein funktio on tuottaa tietoa päätöksenteon tueksi (tai perustutkimuksessa maailman ymmärtämisen tueksi). Jos mittaamisen tuloksena syntyvä tieto ei tue tai mahdollista päätöksentekoa tai ei vaikuta päätökseen mitenkään, ei mittausta kannata tehdä.

Muista myös, että mittareihin käytetty panostus, ilman mekanismia päättää tulosten pohjalta, ei hukkaa vain panostusta vaan myös kaikkien mittaamiseen ja tulosten analysointiin osallistuvien aikaa. Se on harmillisesti pois asiakkaalle tehtävästä työstä.

Mitä sitten kannattaa mitata?

Kaikki mittaaminen kiteytyy enemmän tai vähemmän päätöksenteon ympärille. Kannattaa mitata asioita, jotka auttavat päätöksenteossa – asioita, joiden mittaaminen mahdollistaa päätöksenteon ylipäätänsä.

Kaikkia asioita voidaan mitata ja mittaamisen pääasiallinen tarkoitus on pienentää johonkin asiaan liittyvää epävarmuutta. Esimerkiksi terassia rakennettaessa voidaan mitata koolaus-kakkosnelospätkää ja todeta, että tasan metrinen on sopiva, epävarmuus silmämääräisesti arvioituna 90 cm-120 cm pätkästä poistuu, eihän se 90 cm pätkä olisi ollut riittävä. Ja siten voidaan tehdä päätös, että tämä pätkä riittää ja puutavaraliikkeessä käynti vältetään. Tai siellä mistä olen kotoisin, sahalla käynti.

Lähempänä alaamme oleva esimerkki voisi olla web-sivulla kävijät aikayksikössä. Kävijöiden määrän perusteella hyväksytään muutokset tai palautetaan vanha layout.

Miksi kannattaa mitata?

Mittaamista kannattaa tehdä, jotta epävarmuus asioista poistuisi tai pienenisi. Kun epävarmuus saadaan pienemmäksi, voidaan tehdä informoidumpia päätöksiä aiheesta kuin aiheesta – jos mittaaminen on osunut oikeaan asiaan.

Esimerkkinä voisi olla vaikkapa Scrum-tiimin koodaamisen nopeus (mitä mitataan, tästä löytyy verkossa vaikka kuinka paljon väittelyitä…). Mutta oletetaan perinteinen story-pointteihin perustuva mittaus. Tällöin voidaan sprintistä toiseen, ainakin jollain tarkkuudella sanoa, kuinka paljon tiimi saa aikaan yhdessä sprintissä. Jälleen voidaan tehdä päätös, riittääkö nykyinen tiimi tekemään halutussa ajassa valmista vai pitääkö ottaa tiimiin lisää koodareita. Vai voidaanko tiimistä vähentää koodareita.

Edellisen esimerkin mittari voi ensin vaikuttaa hyvältä mittarilta, mutta se on itse asiassa huono mittauksen kohde, koska siinä oikeasti mitataan kahta eri asiaa, joilla voi olla yhteys tai sitten ei. Eli esimerkissä mitataan tiimin “suorituskykyä” ja tiimin kykyä arvioida storyihin liittyvä työmäärä.

Miten kannattaa mitata?

Edellä todettiin, että mitattiin huonosti, koska yhdellä mittauksella mitattiin kahta eri asiaa. Toimivampi mittaus onkin se, joka mittaa vain yhtä asiaa. Mittauksen pitää siis keskittyä yhteen asiaan kerrallaan, huomioiden mahdolliset taustalla vaikuttavat asiat.

Edellisessä esimerkissä voisi olla parempi mitata suoraan toteutettujen storyjen määrää, ilman story-pointteja. Tällöin saadaan mitattua epätarkempi arvio (koska storyjen koko vaihtelee), mutta arvio kohdistuu enemmän ”suorituskykyyn”.

Mittauksen kannattaa olla tarpeeksi pitkä/laaja, että mittaukseen liittyvä virhe, eli ”heilunta”, pienenee. Fyysikot käyttävät vanhaa nyrkkisääntöä: mittauksen virhe on mittauspisteiden lukumäärän neliöjuureen verrannollinen suure. Eli kun halutaan puolittaa virhe, pitää mitata neljä kertaa enemmän.

Mittauksen virheeseen tuijottaminen ei kuitenkaan saa varastaa huomiota varsinaiselta mittaukselta ja kannattaa aina muistaa, että mittaamisen tarkoitus on päätöksenteon parantaminen ja helpottaminen.

Douglas W. Hubbard käsittelee kirjassaan How to Measure Anything erinomaisesti kaikkia edellä käsiteltyjä kysymyksiä huomattavasti paremmin ja perusteellisemmin kuin tässä lyhyessä blogahduksessa on mahdollista. Toki Codenton konsultitkin voivat tulla avuksi mainittuja ongelmia pohtimaan.

Kaj Mustikkamäki