Nordic Business Forum, 1 päivä, kasvu

Nordic Business Forum 2019 käsitteli tänä vuonna kasvua. Ensimmäisenä päivänä tarkasteltiin kasvua lisäämällä liikevaihtoa. Keskeiseksi tekijäksi nostettiin innovaatiot. Costas Markides, tohtori Lontoon Business Schoolista, aloitti kysymyksellä: Miten teen yrityksestäni innovatiivisemman? Jos joku kysyy tätä, ampukaa hänet, Costas sanoi.

On olemassa kaksi innovaatiotyyppiä: kasvu- ja disruptio-innovaatio (incremental ja disruptive). Kasvuinnovaatioiden avulla tehostetaan olemassa olevaa liiketoimintaa. Esimerkiksi antamalla asiakkaalle pahvilappu kouraan, jossa joka 9. käynti on ilmainen. Tätäkin voi säätää, koska asiakkaan pitää kerätä kahdeksan leimaa. Innovaatio on antaa erityisille asiakkaille kymmenen leiman lista, josta jo kaksi ensimmäistä on leimattu valmiiksi.

Onko tässä mitään järkeä? Molemmissa tapauksissa asiakkaan pitää kerätä kahdeksan leimaa. Ihmisen psykologia kuitenkin yllättää, koska ihmiset haluavat saada asiat valmiiksi. Näin ollen perinteinen kahdeksan leiman kanta-asiakkuus tuo noin 17 % kasvun liikevaihtoon, mutta kymmenen leiman kortti jopa 35 % kasvun liikevaihtoon! Innovaatio!

Disruptiivinen innovaatio sen sijaan yrittää murtaa totuttuja toimintamalleja. Tutkimustiedon mukaan ihmiset käyttävät kuukaudessa 20 dollaria parranajovälineisiin. Tähän saumaan iskee Dollar Shave Club (https://www.dollarshaveclub.com/). Suosittelen katsomaan heidän mainosvideonsa. Se toimii. Se perustettiin 2011 ja myytiin 2016 miljardilla Unileverille. Aika hyvä innovaatio ja tuotto viidelle vuodelle.

Huomaa, molemmat innovaatiomallit poikkeavat toisistaan.

Kasvuinnovaatiot vaativat syntyäkseen vain innovaatiota tukevan ympäristön. Ympäristön, jossa tuetaan kokeiluja, virheiden tekemistä, kysymistä ja kyseenalaistamista, rohkaistaan katsomaan ulospäin ja viimeiseksi rohkaistaan katsomaan siilojen yli.

Disruptiiviset innovaatiot eivät kuitenkaan synny näin.

Niiden syntymiseen löytyy useita eri malleja.

Nespresson tapa. Luodaan muusta yritystoiminnasta erillinen beta, jossa saa tehdä vapaasti mitä haluaa.
Googlen tapa. Investoidaan startuppeihin ja skaalataan ylöspäin se tai ne, jotka menestyvät.
Toinen nopea tapa: Löydä innovatiiviset ihmiset ja innovaation tapauksessa ota innovaatio heiltä.
Innovation accelerator. Yrityksen sisäinen innovaatiomoottori, jossa eri tiimit kehittävät ideoita määritellyssä ajassa. Näistä parhaita kehitetään eteenpäin.

Innovaation luominen vaatii sekä innovoimisen että skaalauksen eli liiketoiminnan laajentamisen.

Seuraavan kerran, kun joku kysyy: Miten teen yrityksestäni innovatiivisemman?
Selvitä mitä hän tarkoittaa!

Päivän kuluessa kerrottiin miten saadan tuotettua innovaatioita. Alexander Osterwalder kertoi miten teet yrityksestä voittamattoman. Hän tiivisti: Innovoi tai kuole.

Kodak Moment nousee yritysmaailmassa vahvaksi esimerkiksi. Kyseinen analogista filmiä myyvä yritys innovoi itsensä ulos markkinoilta. Kodak tuli markkinoille ja tullessaan innovoi kuluttajille suunnatun kameran. Kameroiden yleistyessä Kodak työllisti 180 000 henkeä. Yrityksen tärkein tuote oli analogisen filmin myyminen. Tästä huolimatta yrityksen matka päättyi digitaalikameran tultua markkinoille. Itse asiassa Kodak kehitti ensimmäisen digitaalikameran.

Ostervalder nimesi innovoivan yrityksen voittamattomaksi yritykseksi. Hän nimesi neljä keinoa, joilla siihen päästään.

1. Harmoonisen elämän kulttuuri, innovointi ja toteutus
   Jos haluat ymmärtää kulttuurin, se pitää kartoittaa.
   Business model canvas => Culture map.
   Miten siis siirrytään nykyisestä kulttuurista innovaatiokulttuuriin?
2. Johtajat ymmärtävät ja tukevat innovaatioita.
   Kuinka monta projektia tarvitaan, jotta voidaan tuottaa yksi miljardin projekti?
   

   Miten löydetään innovaatio?
   Pienessä skaalassa,
   10 ideasta 6 epäonnistuu, 3 onnistuu jotenkuten ja 1 menestyy.

   Suuressa skaalassa, tutkimusten mukaan 1000 projektista 4 % nousee miljoonaprojektiksi.
   250 projektista 162 epäonnistuu, 87 onnistuu jossain määrin ja 1 on nespresso.

   Innovaatiokulttuurin löytäneistä yrityksistä hyvä esimerkki on PingAn ja toinen usein esiin nostettu on Amazon. Molemmissa innovoidaan laajasti, kokeillaan ja epäonnistutaan, mutta löydetään myös valtavia innovaatioprojekteja.

3. Organisaatiosuunnittelu luo innovaatioille voimaa toimia
   Logitechin johtaja Bracken Darrell käyttää 40 % – 50 % ajastaan innovaatioiden luomiseen.Heidän maailmassaan löytyy analogia kasvien maailmasta.
   Puita, joiden varassa yritys seisoo, ovat – PC:n oheislaitteet.
   Kasveja, joista voi kasvaa jotain suurta, ovat: Bluetooth kaiuttimet, pelihiiret ym.
   Siemeniä, runsaat innovaatiot.
4. Maailmanluokan keinot innovoida.
   Bosch antaa vuosittain rahaa innovaatiotiimeille, joista parhaat jatkavat aina seuraavaan vaiheeseen, kunnes innovaatiot jalostuvat loppuun asti.

   2 x 25 tiimiä aloittaa, niillä on 12 viikkoa aikaa löytää faktoja miksi heidän innovaationsa toimii.
   70 % tiimeistä karsitaan pois.
   30 % tiimeistä jatkaa 4-6 kk.
   70 % tiimeistä karsijaan
   jne.Vuosien aikana menestyneitä projekteja syntyi 10-20, kun aloittavia tiimejä oli 169.

   Amazon seisoo innovaatiokultturin puolella. Jeff Bezos kirjoitti 2015 osakkeenomistajille:

   One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there. Hardest part is to find feeling that failure is OK! Teams decide who will go on.

Vaikeinta on saada tiimeille tunne, että epäonnistuminen on OK!

Näkyvyyden lisääminen

Haluan kertoa muille mitä teen, millä työkaluilla ja samalla ajattelin löytää mahdollisuuden oppia tekemisen kautta. Motivaattoriksi valitsin tiedon julkaisemisen ja hyvien tiedonmurusten edelleen jakamisen.

Työpaikalla pidetty tiivis somevaikuttamisen kurssi antoi alkusysäyksen. Tajusin kuinka ammatilliset someprofiilini LinkedInissä ja Twitterissä viistivät pohjamutia. LinkedInissä olin sentään käynyt lukemassa kaverien postauksia ja joskus jakanut niitä, silti tulokset olivat … vähemmän mairittelevia.

Kehityksen seurantaa varten nappasin talteen maata viistävät tilastolukemat molemmista.

LinkedIn, 49/100 SSI

Twitter näytti ehkä kauniimmalta, koska olin postannut yhden hyvän työkaverin twiitin.

Näistä lukemista pääsee mukavasti ponnistamaan ylöspäin. Lukuja tärkeämpänä pidän oman osaamiseni kehittymistä ja tiedon jakamista.

Microsoftin TechDays 2018

Miten tulevaisuuden sovelluskehityksessä hyödynnetään nykyisin käytössä olevia työkaluja? 

Maaliskuussa järjestetyssä TechDays 2018 -tapahtumassa tarjottiin vastauksia erityisesti tähän kysymykseen. Tilaisuudessa kuulin vakiintuneista kirjastoista ja niiden seuraavien versioiden herkullisista sisällöistä. Uusimmissa päristimistä löytyy herkullisia mahdollisuuksia ja lastentauteja, alpha-kuumetta.

Tilaisuus tuntui rehelliseltä menolta, asiantuntijalta asiantuntijalle. Kolme  teemaa nousi ylitse muiden: Tekoäly, tietoturva ja pilvipalvelut.

KONEÄLYN KÄYTTÄMINEN

Tekoäly nostettiin esiin kahdesta suunnasta: machine learning eli tilastotieteellinen data-analytiikka ja AI.

Machine learning on jo nyt todellisuutta, kun valmiilla työkalulla pystyy helposti analysoimaan kerättyä dataa ja sovittamaan sitä erilaisiin laskentamalleihin. Esimerkkiesityksessä arvioitiin paljonko maksaisi Ruotsissa 150 m2 asunto tietyllä alueella, kun tiedetään suurempien ja pienempien asuntojen arvo. Näytti helppokäyttöiseltä tilastotieteilijän työkalulta.

Toiselta suunnalta nousee AI. Se käsittelee tietokoneen mahdollisuutta oppia ja tunnistaa erilaisia malleja, kuten kuvien sisältöä, puhetta, vastata yksinkertaisiin kysymyksiin tai ryhmitellä tietoa. Jep, nämä kulkevat nimelläCognitive services. AI-demot näyttivät samalta mitä mikkisofta mainostaa aina. Kuvien tunnistaminen on jo tehty, siis kuvan hymyilyn aste, muut tunteet, sukupuoli, ikä, silmien väri ym. tulevat suoraan analytiikan jsonista, jos sellaista kaipaa.

Se on selvää, että kerättävän datan määrä kasvaa jatkuvasti. Tiedemiehet toivat meille tera- ja petabyten lisäksi exabyten, zettabyten ja yottabyten. Ihmiset eivät pysty käsittelemään näin valtavia datamääriä. Tekoälyn laskentavoima tarjoaa ratkaisua vastausten louhintaan.

Yksi keynote-puhuja kertoi visionsa tulevaisuudesta, jolloin suurin osa sovelluskehittäjistä tulee kirjoittamaan tekoälyyn liittyvää koodia, kymmenen vuoden kuluttua. Muut kuulemma putoavat markkinoilta. Turhauttavaa kuulla pelolla markkinoivia puheita, koska innovaatiot syntyvät kuitenkin innostuksesta ja parhaat kokemukset ovat seurausta positiivisesta tunnelmasta.

Periaatteessa ymmärrän trendin, erikoistutaan syvemmän osaamisen puolelle ja käytetään mahdollisimman paljon valmiita työkalupaketteja. Toisaalta löytyy paljon työpaikkoja, jotka painottuvat alakohtaiseen osaamiseen, mutta eivät vaadi syvällistä teknistä taitoa.

TIETOTURVAKATSAUS

Asiantuntijat Paula Januszkiewicz ja Sami Laiho pitivät jäätävän hyvät esitykset tietoturvasta. Januszkiewiczin kertoi, että heidän yrityksensä käyttämät kräkkäystyökalut ovat kaikkien saatavilla. Laiho puolestaan listasi yksinkertaisia keinoja, joilla pystytään nostamaan oman tietokoneen tietoturvan tasoa.

Molempien esityksistä kävi ilmi, että hakkerit ovat ryhdistäytyneet. Yritysten palvelinten hakkerointi tapahtuu paljon ammattimaisemmin kuin aiemmin. Heikoin lenkki voi löytyä useasta paikasta, joko inhimillisestä piirteestä tai laiskuudesta luoda yrityksen verkosta ja jokaisesta koneesta tietoturvallinen.

Tietoturvaan liittyvä liiketoiminta tulee selkeästi lisääntymään. Tämä on  ymmärrettävää, koska järjestelmät käyttävät vain muutamaa alustaa ja alustoihin liittyvää tietoa saa helposti netistä. Ymmärryksen kasvaessa tietoa voi käyttää monella tavoin.

PALVELUITA PILVEN KAUTTA

Microsoft mainostaa vahvasti palveluitaan sellaisilta tulokulmilta, joita ei löydy kilpailijoilta. Sain kuulla hehkutusta aika paljon parin päivän aikana. Valitettavasti en istunut kuuntelemassa niitä puheita, joissa kritisoitiin Azurea.

Microsoftin palvelut hyppäävät pilveen. Office-perhe pyörii siellä jo. Suurin osa uusista tekniikoista tuntuu tulevan pilvipalveluina. Tekoälypalvelut löytyvät pilvestä. Perinteiset web-softat voi heittää pilveen. Microsoft tarjoaa migraatiotyökalun ja migraation onnistumisen arvioimistyökalun, kun mennään perinteisestä arkkitehtuurista pilveen. Uusia lähtöjäkin esiteltiin, ihan alpha-kamaa ja toivottiin kontribuutiota julkisiin repoihin.

Meille kerrottiin useamman kerran kuinka kannattaa määritellä palvelut pilveen, siten etteivät ne kerrytä turhaan laskutusta. Ruuhkahuippujen aikaan palvelut voidaan skaalata ylöspäin useammalle koneelle, jolla saadaan lisää suorituskykyä palvelemaan pyyntöjä, mutta myös lisää kustannuksia. Kuormitushuipun jälkeen palvelut voidaan skaalata alaspäin, jolloin säästetään kustannuksista.Toki kannattaa myös miettiä miten toteuttaa sovelluksensa pilvessä: virtuaalikoneissa, suoraan palveluina tms. Siis sivuttiin tavanomaista PaaSiin ja SaaSiin liittyvää pohdintaa.

PILVEEN DEVAAMINEN

Pilveen menemisen helppous tuli myös vastaan useampaan kertaan. Tosin pilveen mentäessä ylläpitäjä jää vähän hämäräksi. Periaatteessa devaaja voi tehdä kaiken. Hän päräyttää monitoroinnit pystyyn softan kehityksen oheessa, saa vikatilanteissa viestejä ja normaalitilanteessa analysoi palvelun laadun. Erinomaista tietoa sovelluskehitystä ajatellen, mutta miten ajankäyttö?

Perinteisesti kehittäjät tekevät softan ja ylläpitotiimi jää monitoroimaan sovelluksen vasteaikoja sekä lokeja. DevOps-osaajat tietenkin tunkkaavat monitoroinnit kuntoon ja pistävät CI-putken paikoilleen. Kannattaako pitää erilliset DevOps-kaverit vai tekeekö kehittäjä kaiken? Microsoft tarjosi selkeästi DevOps-tekijöille luentosarjansa, joten toistaiseksi koodaaja pidetään Visual Studion äärellä.

Pilveen siirtymistä helpotetaan. Maakohtaisia rajoitteisiin yritetään vastata luomalla paljon uusia palvelinten sijainteja kartalle. Palvelut tuodaan helposti pilvestä käytettäviksi. Tekemistä yritetään selkeästi siirtää pilveä kohti.

Vanhana koodaajana seison kahden maailman välissä. Ymmärrän täysin vanhat toimijat, jotka haluavat pitää kaikki langat käsissään. He pystyttävät palvelinsaleja, ja on paljon tapauksia, joissa oma palvelinsali on ainoa vaihtoehto. Sen sijaan moni startup, kotiprojekti ja verkkosivuprojekti siirtyy sulavasti pilveen.

TUNNELMAT TAPAHTUMAN JÄLKEEN

Tapahtuman aikana tunsin hermoratani sähköistetyksi. Uusia ihania asioita tulee, vanhat ja toimivat tekniikat pyörivät iloisesti pilven nurkalla. Tehokasta, edullista ja kätevää.

Uskon useiden projektien muuttuvan sisällöltään herkullisemmiksi. Pelkkien verkkosivujen tai yksinkertaisten palvelujen tekijät tulevat vähenemään digitalisaation ensimmäisen aallon jälkeen. Työpaikallammekin selvitetään asiakkaan mahdollisuutta viedä palvelunsa pilveen tai tehdä hybridiratkaisu. Mielestäni lisäarvon tuottaminen on tärkeämpää. Miten kerättyä dataa pystytään hyödyntämään ja jatkojalostamaan tekoälyn avulla?

Omalta osaltani luon paremman huomisen koodaamalla.

Olen koodaaja.

---

Ensijulkaisu tapahtui Goforen blogissa.

Kuinka ujutan lokituksen JavaScriptin nuolifunktioon

Sain eteeni JavaScript frontin, joka on toteutettu ES6 + React Redux Forms -pinolla. Huomasin kaipaavani pientä lokitusta, eli perinteistä console.log(myProperty) -settiä, jotta näen toimiiko koodi siten, kuin aiempi kehittäjä sen tarkoitti.

Löysin seuraavanlaisen funktion, olen vähän yksinkertaistanut sitä esimerkin vuoksi:

const UiComponent = (locale) => (
  <CustomComponent locale="locale">
    {childern}
  </CustomCompnent>
);

Halusin tietää locale:n arvon kun se annetaan komponentille. No, omassa ongelmassani kyse oli eri sisällöstä, mutta locale toimii paremmin esimerkkinä.

Yritin itse ensin kirjoittaa koodin oikein, onnistumatta. JavaScriptille kun ei ole näppärää editoria, joka osaa kertoa miltä funktion pitäisi näyttää. Puhumattakaan VS Codesta, jota käytän.

Onneksi työkaverini osasi kertoa ratkaisun. Se kesti alle minuutin.

Ensimmäiseksi kirjoitetaan nuolen jälkeen return, että funktio palauttaa sen mitä haluat => return( ja ympäröidään koko paketti kaarisuluilla. Tadaa!

Laitoin vielä sisälle console.log:n jotta sain näkymään annetun parametrin arvon.

const UiComponent = (locale) => {
  console.log(locale);
  return (
    <CustomComponent locale="locale">
      {childern}
    </CustomCompnent> 
  );
}

Löydettyäni bugin perinteisen console.log-arvon avulla sain korjattua ongelman.

Nuolifunktioista voi lukea lisää vaikka Wes Bos:lta

 

SOLID-periatteet

Ohjelmiston suunnittelemiseen löytyy useita arkkitehtuuriperiaatteita. Esittelen tässä lyhyesti SOLID-periaatteet. Ne vastaavat olio-ohjelmoinnin haasteisiin.

Ohjelmointiperiaatteet tulevat ajankohtaisiksi, kun samaan sovellukseen kirjoittaa vähän enemmän koodia tai koodia kirjoittaa useampi henkilö. Ymmärrettävyyden ja perusvirheiden välttämiseksi apuun kiiruhtavat arkkitehtuuriperiaatteet. Sehän on hassu sanahirviö.

SOLID-periaatteet tulevat usein vastaan luokkia kirjoittaessa. Avaan lyhyesti nuo viisi periaatetta. Wikipediasta voi lukea ensihätään kattavamman selostuksen ja sieltä löytyvät alkuperäiset lähteet, jos haluat uppoutua syvemmälle.

• S, Single responsibility principle, muistuttaa yhden luokan vastaavan vain yhdestä asiasta. Esimerkiksi yksi luokka vastaa tiedon järjestämisestä oikeaan järjestykseen. Jos siihen livahtaa toinen vastuu, kuten erilaisen tiedon vertailu tai tiedon lähettäminen rajapinnan läpi, niin jokaista vastuualuetta varten kirjoitetaan erillinen luokka.
• O, Open/closed principle, avoimen / suljetun luokan periaate. Luokan pitää olla avoin toimintojen ja ominaisuuksien laajentamiselle. Riippuen periaatteen tulkitsemisesta, periaate on aikanaan tarkoittanut abstrakin perusluokan perimistä toteuttavalle luokalle. Peritty luokka voi aina lisätä metodeja ja propertyjä ja siten olla vanhempana toimiva luokka on avoin laajentamiselle. Toisaalta vanhempana toimiva luokka on suljettu, koska sitä ei voi muuttaa.Myöhemmin samaa periaate haluttiin rajata toimimaan rajapintojen, eikä perinnän kautta. Hyvin määritellyt rajapinnat ovat suljettuja, mutta luokan toimintaa voi laajentaa uusilla toiminnoilla tai lisäämällä siihen toisen rajapinnan.
• L, Liskov substitution principle (LSP), Liskovin korvattavuuden periaate määrittelee, että samaa alatyyppiä olevat oliot voivat korvata toisensa toteuttavassa koodissa. Perintähierarkiaa ajatellen tämä on nykyään itsestään selvää. Jos tytöt ja pojat ovat molemmat lapsia, niin lapsi-olioita sisältävät lista voi sisältää kumman molemman tyyppisiä olioita. Siis poika-olion voi korvata tyttö-oliolla, kun halutaan käyttää oliota lapsi-luokan kautta.
• I, Interface segregation principle, rajapintojen hajoittamisperiaate kertoo, että yhden yleisen rajapinnan sijaan kannattaa luoda useita hyvin määriteltyjä rajapintoja. Näin ollen luokka tulee sisältämään vain metodeja, joita se käyttää, kun se voi toteuttaa hyvin määritellyn rajapinnan. Yleiset rajapinnat sisältävät turhia metodeja.
• D, Dependency inversion principle, riippuvuuden kääntämisen periaate kutkuttelee olioiden perimistä. Vanhempana toimivan luokan ei pitäisi riippua lapsiluokkien toteutuksesta, vaan rajapinnoista. Abstraktioiden ei pitäisi riippua yksityiskohdista. Yksityiskohtien pitäisi riippua abstraktioista.Käytännössä suoran perimisen sijaan luokka sisältää propertyjä, joiden tyyppi on rajapinta. Esimerkiksi lapset-lista on kokoelma olioista, jotka toteuttavat ILapsi-rajapinnan. Tyttö ja Poika -oliot eivät peri suoraan lapsi-luokkaa, vaan ne toteuttavat ILapsi-rajapinnan.

Ihania periaatteita.

Miksi? Luettavan, ylläpidettävän ja testattavan koodin kirjoittamiseksi. Koodi on luettavampaa, kun koodin rakenne tulee samojen periaatteiden kautta. Ylläpidettävyys helpottuu, kun luokkien keskenäinen riippuvuus vähenee. Rajapinnat taas auttavat testattavan koodin kirjoittamista.

Riippumatta siitä, haluatko kirjoittaa testejä tai et, niin SOLID helpottaa kehittäjän elämää. Ennen kaikkea muiden kehittäjien elämää. Koodi kirjoitetaan muita kehittäjiä varten, kääntäjä osaa pyöräyttää siitä ohjelman koodin ulkoasusta riippumatta.

Keskitä vertikaalisesti kolmella koodirivillä

Työkaveri vihjasi törkeän mainion sivun, jossa kerrotaan miten UI-elementin voi keskittää vertikaalisesti kolmella koodirivillä. Taikasana on CSS.

.element {
  position: relative;
  top: 50%;
  transform: translateY(-50%);
}

Saman voi kirjoittaa myös mixininä.

/* Mixin */
@mixin vertical-align($position: relative) {
  position: $position;
  top: 50%;
  -webkit-transform: translateY(-50%);
  -ms-transform: translateY(-50%);
  transform: translateY(-50%);
}

.element p {
  @include vertical-align();
}

Elementti voi sijoittua pikseleiden väliin, jolloin elementin reunat voivat näyttää sumuisilta tai pehmeiltä. Määrittelemällä keskittämisen parin lisämääreen avulla ongelma ratkeaa.

.parent-element {
  -webkit-transform-style: preserve-3d;
  -moz-transform-style: preserve-3d;
  transform-style: preserve-3d;
}

.element {
  position: relative;
  top: 50%;
  transform: translateY(-50%);
}

Korjauksen voi tehdä myös perspectiven avulla (ratkaisua ehdotti alkuperäisessä postissa roydukkey):

.element {
  position: relative;
  top: 50%;
  transform: perspective(1px) translateY(-50%);
}

Nauti keskittämisestä!

Underscore js – JavaScriptin muistilista

Frontin tekeminen ja JavaScript? Underscorejs ratkaisee huolesi tarjoamalla pikaisia vastauksia tyypillisiin ongelmiin. Tavallisesti ongelmiin liittyvät vastaukset joutuu kaivamaan API:sta tai StackOverflowsta, mutta JavaScriptin puolella ratkaisukokoelma helpottaa elämää.

Underscoren kautta löytää hyviä esimerkkejä tyypillisiin funktiokutsuihin. Positiivisena puolena voi mainita funktiot. Jos osaat funktionaalista ohjelmointia, JavaScriptin opetteleminen tätä kautta käy helposti. Mikäli et vielä ymmärrä funktioita, niin esimerkkien avulla opit lisää.

Osaamistasi saat lisättyä codewarsin kautta, kuten kerroin aiemmin.

Riemullista JavaScriptailua!

Code Wars, mahdollisuus oppia

Tutustuin codewarsiin työkaverini suosituksesta yhtenä syksyisenä päivänä. Hän löysi koodiharjoitussivuston, jossa editoria ja testejä voi ajaa selaimen kautta. Toisin kuin exersim.io tai vastaavissa palveluissa, codewarsilla harjoitteleminen onnistuu ilman kehitysympäristöä.

Harjoitusten tekeminen codewarsissa käy helposti. Harjoitusta kutsutaan nimellä kata.

Kata eli harjoitus codewars.com:ssa.

 

Harjoituksen tehtävänanto selviää ruudun vasemmalta puolelta. Koodi kirjoitetaan oikeassa yläkulmassa näkyvään koodinäkymään. Kirjoitettu koodi ajetaan ”paikallisia” testejä vastaan Run Examples -painikkeella. Ne löytyvät Example Tests -otsikon alta. Näitä testejä voi myös muokata omien mieltymysten mukaan.

Lopullinen testi ratkaisulle tehdään ajamalla koodi Attempt-painikkeella. Ratkaisun toimivuus testataan yksikkötesteillä, joita ei näytetä käyttäjälle. Vain testien tulos näytetään. Toisinaan testien nimestä voi päätellä mikä testi epäonnistui. Järjestelmä sallii myös satunnaistettujen testien ajamisen, jolloin tehtävän luojan ei tarvitse kirjoittaa kaikkia testitapauksia käsin.

Ratkaistuasi tehtävän, saat vaikeusasteen mukaan tietyn määrän pisteitä. Helpoimmat testit saa ratkaistua muutamassa minuutissa, vaikeampien ratkaiseminen kestää tunteja.

Ratkaistuasi tehtävän, näet muiden vastaukset ja näistä oppii. Vastauksista voi merkata omasta mielestä parhaan ja nokkelan vastauksen. Vastauksista näkee kuinka paljon ohjelmoijien ongelmanratkaisukyky ja API-tuntemus vaihtelee.

Stats-sivu kertoo mistä olet saanut pisteitä.

 

Olen kerännyt suurimman osan pisteistäni tekemällä harjoituksia. Pisteiden hankkimiseen käytetyt kielet näkyvät oikeasta laidasta ja prosenttiosuus kertoo kuinka paljon pisteitä on kerätty ennen seuraavaa tasoa.

Pisteet päivittyvät muutaman tunnin välein, kun palvelin ajaa ajastetusti pisteiden päivistyskriptit. Itsekin ihmettelin aluksi miksi pisteet päivittyvät viiveellä.

Jos teet vain harjoituksia, pisteillä ei ole merkitystä. Halutessasi voit kirjoittaa harjoituksia muiden ratkaistavaksi tai kääntää niitä kieleltä toiselle. Tällöin korkeampi pistemäärä sallii kevyemmän validointiprosessin ennen kuin kirjoittamasi harjoitus julkaistaan.

Yhteisöllisyyttä yritetään lisätä klaanien avulla. Käyttäjän tiedoissa voi antaa itselleen klaanin. Se on vain merkkijono. Kaikki jotka kirjoittavat saman merkkijonon, tulevat samaan klaaniin.

Klaanit

 

Klaanijärjestelmä ei ehkä ole täydellinen, koska vaihdettuani klaanin, näen edelleen kaikki vanhan klaanini jäsenet.

Codewars on ehdottomasti paras palvelu ohjelmointiharjoitusten tekemiseen. Sen avulla voi ylläpitää kielen osaamista tai opetella uutta kieltä. Toki harjoitusten avulla oppii erityisesti kielen käyttöä, ei niihin liittyvien frameworkkien käyttöä.

Suosittelen kokeilemaan codewarsia, sen avulla voit löytää palon vanhaan rakkaaseen kieleen tai kehittää osaamistasi nykyisen kielen kanssa.

 

 

 

Visual Studio Live Unit Testing

Visual Studio 2017 RC julkisti seuraavan askeleen yksikkötestauksessa, live-tilan. Käytännössä VS ajaa jatkuvasti yksikkötestejä kirjoitettua koodia vastaan ja merkkaa onko koodiriviin osuva testi läpäisty, ei mene läpi tai puuttuuko se.

Silmäilin asiasta kertovan blogin läpi ja katsoin siihen liittyvän videon. Oli mielenkiintoista seurata intialaista kerrontaa. Se selvensi kuinka nopeasti testi heijastui koodiin. Pohdiskelin hetken, vaatiiko tekniikka paljon tehoa tietokoneelta?

Ominaisuus vaatii Enterprise-lisenssin, mikä on sääli. Se maksaa huiman summan, verrattuna tavallisesti käyttämääni pro-versioon.

Mieleeni juolahti vanha kuvio. Microsoft kopioi JetBrainsin ideoita. Tapahtuiko tämä kehitysaskel samoin?

Kyllä!

JetBrainsin dotCover tarjosi continuous testing -konseptin vuonna 2015. Se poikkeaa hieman VS:n natiivista. Se vain ajaa testejä jatkuvasti ja näyttää, menevätkö ne läpi. Tosin dotCoverin muut ominaisuudet näyttävät onko koodille yksikkötestejä.

Vanhaa kauraa siis. Kehittäjälle siis löytyy vaihtoehtoja reaaliaikaiseen testaukseen.

Pari vuotta sitten testasin dotCoveria ja tuolloin kaikilla mausteilla valittuna se hieman hidasti Visual Studiota. Olisi jännä testata onko dotCover ydintä optimoitu tuon jälkeen?

Pitää kokeilla!

Code combat – ohjelmointia nuorille

Halusin antaa maistiaisen 9-vuotiaalle pojalleni ohjelmoinnista, mutten tylsän ”Hello World!”-tekstin muodossa. Onneksi löysin Code Combat -jutun.

Kyseessä on peli, jossa hahmo liikkuu ohjelmoimalla. Oletuskielenä käytetään pythonia, mikä näyttää hyvin läheisesti puhutulta kieleltä. Toki tässä pienenä sivujuonteena olimomainen toteutus, koska tämän pelin mekaniikka vaatii sitä. Kuvakaappauksissani näkyy JavaScript-kieli, koska halusin kokeilla sitä.

Poikani tykästyi peliin. Hän kuunteli alkuun pari ohjetta ja pelasi ensimmäiset 12 kenttää ihan itsekseen. Muutamassa kohdassa ohjasin häntä, kuten muuttujien tai if-lohkojen tapauksessa.

Ensimmäisessä vaiheessa pelaajalle annetaan tavoitteet. Kun ne näkyvät selkeällä suomenkielellä, niin peruskoululainen ymmärtää mitä pitää tehdä. ”Älä koske piikkeihin. Kerää jalokivet. Älä näyttäydy jätille.”

Toisessa vaiheessa pelaaja ratkaisee kentän. Käytännössä poikani klikkaili move-komentoja ruudun keskeltä ja muokkasi niitä tarvittaessa. Tässä kentässä niitä ei tarvitse muokata, mutta joissain kentissä pitää asettaa hyökkäykselle kohde tai koordinaatit liikkumiselle.

Lopuksi ajetaan kenttä. Aikuinen ohjelmoija haluaa ensin suorittaa kentän ja uskaltaa vasta sitten napsauttaa ”Valmis”. Lapsi napsauttaa suoraan valmis.

Ongelma nouse eteen, kun suomenkielinen lokalisointi loppui. Code Combat on jaettu erilaisiin vaiheisiin: linna, metsä jne. Linna on lokalisoitu, se tarkoittaa ilmaisversiossa 12 kenttää. Sen jälkeen seikkailija pääsee metsään, missä tehtävänannot muuttuvat englanninkielisiksi. Huomasin poikani kiinnostuksen tyrehtyvän kielen vaihtuessa.

Poikani ymmärtää englannin alkeita, muttei siinä määrin, mitä pelin pelaaminen vaatisi. Jos pelin kaikki ilmaiset kentät saisi lokalisoitua, hän varmaan jaksaisi rakentaa pieniä ohjelmia pitkään.

Code combat on hyvä avaus ohjelmoinnin maailmaan. Pelillinen maailma tarjoaa timantteja kentän ratkaisemisesta ja erilaisia bonuksia, jos kentän ratkaisee siististi. Tällaisilla ratkaisuilla saa nuoren ohjelmoinnin pariin.