Millä perusteella teknologia tulisi valita?

Gartnerin malleissa ja menetelmäkäsikirjoissa kaikki menee ihanasti, kun taas käytännön elämässä kehitystiimit ja IT-yksiköt joutuvat tekemään teknologiavalintoja usein puutteellisilla tiedoilla. Erityyppiset hankinnat tulevat eteen niin harvoin, että edellisen kierroksen jälkeen markkina ja sen pelurit ovat ehtineet muuttua täysin. Ostaja on helposti toimittajien mainospuheiden varassa. Vai onko? Ei välttämättä, kun pitää muutaman perusasian valintoja tehdessään mielessä.

 

1 Panosta liiketoimintakriittisyyden mukaan

Ihan ensin hankintaa miettiessä on syytä tunnistaa, minkä verran järjestelmään on perusteltua panostaa. Jos kyseessä on aivan liiketoiminnan keskiössä oleva järjestelmä, jolla etsitään kilpailuetua ja kirkkaampaa tulevaisuutta, sen kehittämiseen voidaan panostaa aivan eri tavalla kuin jos kysymys on toiminnan rutiineista.

Jos tarve kuuluu jälkimmäiseen kategoriaan, hankintaa suunniteltaessa kannattaa saman tien kääntää päälle vaihde, jolla ratkaisut tarpeisiin mietitään vaikka millä ilveellä olemassa olevien valmisratkaisujen ympärille ja kustomointia tehdään minimaalinen määrä.

Seuraavat alaluvut koskevat erityisesti ensimmäisen kategorian teknologioiden valitsemista, niihin kun on todella aihetta keskittyä.

 

2 Varmista käyttäjätarve

Seuraavaksi on ymmärrettävä käyttäjän tarve. Mikä on käyttäjän perusongelma, joka teknologian on syytä ratkaista? Millainen palvelu sen voisi ratkaista, ja miten pystymme varmistamaan että potentiaalisen toimittajan tai meidän itse kehittämämme teknologia oikeasti tekee näin?

Jos mahdollista, ennen investointia on hyvä käyttää viikko-pari sen varmistamiseen, että käyttäjätarve on oikeasti kuultu käyttäjiltä itseltään eikä mielikuviteltu kulmahuoneessa. Ja samalla on hyvä yksinkertaisimmalla mahdollisella prototyypillä myös varmistaa, että löyhästi kaavailemamme ratkaisu oikeasti täyttää tuon käyttäjätarpeen – ennen kuin olemme upottaneet siihen merkittäviä määriä aikaa ja rahaa.

 

3 Analysoi liiketoiminnan tarve

Lähdettäessä toimittamaan käyttäjille sitä mille löytyi toivottavasti huutava tarve, on seuraavaksi selvitettävä liiketoiminnan teknologialle asettamat reunaehdot. Miten asiakkaan toivoma asia aiotaan toimittaa? Onko valintoja, joita on syytä tehdä vaikkapa hinnoittelun tai järjestelmän toimintasyklien suhteen?

 

4 Tutki uudet fiksut työtavat

Käyttäjän ja liiketoiminnan tarpeen lisäksi teknologiaan useimmiten liittyy organisaation työn arkea: teknologialla tehtävää asiakaspalvelutyötä, ylläpitoa tai taustaprosessia. Teknologiaa valitessasi haluat luultavasti varmistaa, että organisaatiosi on hahmottanut työtavan jolla sitä tullaan käyttämään.

Yleensä tässä kohtaa ei haluta menettää sitä mahdollisuutta, että uuden teknologiavalinnan siivin voidaan uudistaa myös työtapa. Kun käytetään hetken aikaa työtavan analysointiin, huomataan, mikä osa tekemisestä oikeastaan tuottaa arvoa asiakkaalle. Arvovirtakartta on tähän hyvä väline. Analyysin jälkeen teknologiavalinnalla voidaan linjata, että työssä saadaan oikeasti keskityttyä asiakkaan saamaan arvoon ja pakolliset rutiinit pystytään hoitamaan mahdollisimman tehokkaasti.

 

5 Kartoita tietojärjestelmäympäristö

Harvoin teknologiaa päästään valitsemaan puhtaalle pöydälle. Yleensä ympärillä on elinkaaren eri vaiheissa olevia tietojärjestelmiä joihin uuden teknologian pitää liittyä, ja palapeli rajoittaa valintoja. Näiden mallintamisen tapaa tärkeämpää on, että ne ja niiden integrointitarpeet tunnistetaan ennen teknologian valintaa. Esimerkiksi: millaisia rajapintatarpeita teknologian pitäisi täyttää?

 

6 Huomaa muut rajoitukset

Edellä mainittujen lisäksi on olemassa yleensä vielä muitakin ulottuvuuksia, jotka rajoittavat teknologiavalintaa. Joskus teknologian käyttöönotolla on aikataulu, joka rajoittaa ratkaisuvaihtoehtoja – kehitykseen panostamiseen ei yksinkertaisesti ole aikaa, vaan pitää rakentaa olemassa olevien ratkaisujen päälle. Joskus toimintaan liittyy lainsäädäntöä, joka asettaa teknologialle rajoituksia, esimerkiksi tietojen sijainnin tai muiden tietoturvatekijöiden muodossa.

 

7 Mieti elinkaaritarpeet

Useimmiten tässä pohdinnan tässä kohtaa vaatimusten yhdistelmä ajaa jo kohti melko harvalukuista joukkoa teknologia- ja toteutustapavaihtoehtoja. Yksi pohdinta on kuitenkin vielä jäljellä: teknologian elinkaari. Useimmiten halutaan välttää joutumista tuoreen teknologian ensimmäisten kokeilijoiden joukkoon.

Kun teknologia on ollut jo jonkin aikaa olemassa, tarjolla on ilmaista etua muiden tekemistä virheistä ja kehittämistä perusasioista eli hienosti sanoen ekosysteemin kypsymisestä. Toisaalta jos kysymys on kriittisestä teknologiasta ja haetaan kilpailuetua, joskus kannattaa myös maksaa oppirahat ja olla eturintamassa.

Joka tapauksessa on hankittava markkinaymmärrystä ja joskus myös meediopalveluita hahmottaakseen myös elinkaaren loppupää: Miten pitkälle tulevaisuuteen teknologialle voi olettaa jatkuvuutta vs. käyttötarpeen mitta? Miltä ekosysteemin kehitys näyttää, vaikuttaako siltä että teknologialle on tarvittaessa löydettävissä ylläpitäjiä myös tulevaisuudessa? Olemmeko investoimassa kisojen voittajahevoseen vai näyttäkö uhkaavasti siltä että kyseessä on häviäjätallin kaakki?

 

Työkaluja:

Tarpeen pikadokumentointiin voit käyttää ohjelmiston visiolakanaa, ks. https://www.codento.fi/lataa-lean-visiolakana-ohjelmistoprojektiisi/

Lisää prosessien analysoinnista ks. https://www.codento.fi/2017/08/hyvaa-halvalla-nopeasti/

 

Lataa opas: Uuden verkkopalvelun teknologiavalinnat

Onko blockchain yrityksellesi pelkkä troijan hevonen?

Harvat uudet teknologiat ovat yhtä kiinnostavia ja samalla yhtä vaikeita hyödyntää olemassaoleviin liiketoimintamalleihin kuin lohkoketju, eli blockchain. Lohkoketjun kansikuvajutut bitcoin-kurssikäyrän kera ovat helposti kirjoitettavia, teknologiaan on sijoitettu valtava määrä rahaa ja näyttää siltä, kuin lohkoketjulla olisi todella helppo tienata miljoonia tai miljardeja. Lohkoketju on vieläpä todella hienoa teknologiaa!

Väitän silti voimakkaasti, että useimmille yrityksille lohkoketju on tässä vaiheessa pelkkä kangastus tai troijan hevonen, vaikeasti kaupallistettava superkiinnostava teknologia, joka häiritsee aivan yhtä kiinnostavien mutta nopeasti kaupallistettavien teknologioiden kehitystä.

Blockchain-hypestä tulee Itselle mieleen Ford-autovalmistajan Nucleon -konsepti, kuvankaunis amerikanrauta, jonka moottorina piti olla ydinreaktori. Kun ydinreaktorit olivat kuuminta hottia, niitä ajateltiin asennettavan autoihin, lentokoneisiin, juniin ja jokaiselle asuinalueelle. Todellisuus olikin sitten jotain muuta.

Vähän sama tilanne on lohkoketjun kanssa. Valtavan hienoa teknologiaa, jolla voidaan tehdä uusia palveluita, joita ennen ei olisi voinut kuvitellakaan. Valitettavasti suurin osa nykyisen liiketoimintamallin ja lohkoketjun yhdistelmistä on yhtä banaaleja kuin Fordin ydinreaktorilla käyvä henkilöauto – teoriassa mahdollisia, mutta härveleitä, joiden haitat eivät koskaan vastaa niistä saatua hyötyä.

Mistä sitten kannattaisi aloittaa? Itse ehdotan, että nyt on oikea aika jakaa uusien teknologioiden kehitys kolmelle eri tiimille tai striimille, jos tilanne on samanlainen kuin monilla asiakkaillamme.

  • Tiimi I

Useimmat organisaatiot ovat yllättävän käsityövaltaisia, kun niihin kunnolla tutustuu. Arkisia työvaiheita varten tulostetaan A4:ia, tieto siirretään järjestelmästä toiseen käsin tai eri järjestelmissä olevaa tietoa ei saada yhdistettyä fiksumpaa toimintaa varten.

Yritys, jonka tiedot ovat tällä tavalla hujan hajan ei voi onnistua uudistumisessa, mutta onneksi nykyään yhteisen näkymän luominen on halvempaa ja nopeampaa kuin koskaan aiemmin, eikä tätä varten ole pakko ostaa SAP:pia tai mitään muutakaan monoliittista sovellusta.

  • Tiimi II

Toisena striiminä etsisin kaikki ne kohdat, joissa arkisia päätöksiä tehdään täysin prosessin mukaisesti. Jokainen käsityönä tehty, tarkkaa byrokraattista prosessia noudattava päätös kannattaa automatisoida. Tiedon käsittelyn nopeuttaminen tuo yllättäviä hyötyjä, useimmiten sekä asiakkaalle että myynnille ja markkinoinnille.

  • Tiimi III

On vaikea saada rahoitusta tiimeille I ja II ilman vanhoista malleista poikkeavia liiketoimintasuunnitelmia. Asiat ovat rempallaan, koska loppujen lopuksi vanhassa maailmassa on ollut halvempaa teettää enemmän käsityötä kuin automatisoida prosessit loppuun saakka. Tämä on muuttunut viime vuosina. Automatisointi on jatkossa onnistumisen edellytys, eikä siitä voi tinkiä. Uudet tekoälyyn perustuvat liiketoimintamallit vaativat perustuksekseen hyvää tietoa ja organisaation, joka ei tuhlaa aikaa ja rahaa turhaan käsipelillä tunkkaamiseen.

Tekoäly, tai oikeastaan sen koneoppimiseksi kutsutut toteutustavat, ovat jo arkipäiväisiä. Kaikkien suurten internetyritysten, Googlesta Spotifyhyn, onnistumisen salaisuus on fiksussa koneoppimisen käytössä. Useimmilla toimialoilla tekoälyä fiksusti hyväksikäyttävä yritys tulee seuraavina vuosina pieksemään ne, joiden tekoälytiimi ei ole päässyt vauhtiin.

Kolmostiimi toimii myös loistavana kirittäjänä kahdelle muulle tiimille. Tieto, jonka yhdistäminen on vaikeaa tai johon liittyvät päätökset tehdään vielä käsipelillä, tulee yhdistetyksi ja automatisoiduksi, kun kolmostiimi lupaa sellaista, jota kilpailijalla ei ole – automaattisen asuntolainapäätöksen, juuri sinulle halvalla räätälöidyn puvun valmistuksen tai juuri sinun makuusi viritetyn illallisreseptin.

Me Codentossa autamme teknologiavalinnoissa ja olemme ammattilaisia Tiimien I, II ja III työssä. Etsimme jatkuvasti uusia arkkitehtejä teknologiatiimiimme ja teemme niin suuria kuin pieniä teknologiavalinta toimeksiantoja yksityisellä ja julkisella puolella.

 

Banneri Uuden verkkopalvelun teknologiavalinnat 2018

Etätöissä Japanissa

Kun syys–lokakuussa huomasimme parin kaverini kanssa, että lennot Japaniin olivat pienessä alennuksessa, päätimme tutkia olisiko mahdollista lähteä sinne porukalla. Olen melko uusi työntekijä Codentolla ja erityisesti tuolloin olin vielä upouusi työntekijä. Tiesin että mahdollisuus lähteä Japaniin olisi joko palkaton reissu tai etätyö.

Codentolla kerrottiin jo hakuprosessin alkuaskeleilla, että mahdollisuuksien mukaan etätyöt myös muualla kuin Suomessa onnistuvat. Päätinkin ottaa Japanin-reissun osalta selvää, kuinka sellainen onnistuisi omalla kohdallani. Codenton etähommissa ei tehdä lainkaan firman omia asioita edistäviä töitä, vaan konsultti keskittyy pelkästään asiakasprojektin edistämiseen. Näin tuetaan asiakkaan tavoitteita sekä edesautetaan asiakkaan mahdollisuutta antaa konsultille lupa lähteä pidemmällekin reissulle etätöihin. Lisäksi yrityksenä ja yksittäisinä konsultteina pyrimme siihen, että hommat tulee tehtyä parhaalla mahdollisella tavalla, olipa konsultti sitten tekemässä töitä missä suunnalla palloa tahansa.

Alkuvalmisteluja ennen matkaa

Keskustelin aluksi toimarimme Petrin kanssa, josko voisin tehdä etähommia matkan aikana. Sain Petriltä siunauksen sillä ehdolla, että myös asiakkaalta tulee vihreää valoa. Meillä Codentolla tehdään pääasiassa asiakasprojekteja, siksi hommia tehdään aina asiakkaan aikataulun mukaan. Seuraavaksi juttelin asiakasprojektin vetäjän kanssa mahdollisesta etätyöstä, kerroin myös että saatan tehdä vajaita päiviä etänä. Projektin vetäjä ei edes epäröinyt vaan lupa tuli saman tien kuin apteekin hyllyltä osaksi varmasti siitä syystä, että luottoa minuun löytyy, mutta myös siksi että luottoa Codentoon löytyy.

Etätyöt matkan suunnittelussa keskiössä

Aloimme suunnittelemaan matkaa hyvissä mielin sekä varasimme lennot. Matkasuunnitelmaa muodosteltiin ja hiottiin, korjailtiin ja muutettiin aikataulujen ja muiden asioiden mukaan. Suunnitteluun kuului oleellisena osana myös etätyöt. Hommat ulkomailla saa varmemmin tehtyä, jos se ei estä näkemästä asioita, joita haluan nähdä. Keskustelin myös muiden codentolaisten kanssa etätöistä ulkomailla, ja parhaaksi vaihtoehdoksi muodostui tehdä osa-aikaisia työpäiviä. Lähempänä lähtöpäivää muistuttelin asiakasta sekä projektityökavereitani lähdöstäni ja osa-aikaisesta työpanoksestani. Muistuttelin ihmisiä myös Codentolla, jotta kukaan ei ihmettelisi missä olen. Sovin meidän markkinointivastaavan Eevan kanssa, että kirjoittelisin blogin kokemuksestani, sekä etätyöstä. Lupasin myös hienoja matkakuvia. Juttelin asiakkaan kanssa vielä tarkemmin työtavoista ja olin valmis lähtemään matkoille.

Ja täällä ollaan!

Olen nyt Japanissa, ja teen noin 2–5 tuntia töitä per päivä. Joka päivä olen ollut yhteyksissä asiakasprojektin tiimiin tavalla tai toisella. Töitä on tullut tehtyä junassa, lentokoneessa, rannalla, hotellissa sekä kahvilassa – sopiva paikka on aina löytynyt tosi hyvin. On ollut mukavaa tehdä välillä omissa oloissa töitä. Vaikka yhteydet internettiin ovat välillä olleet mitä ovat, ja joskus projektin tekeminen on ollut hankalaa, niin haasteista huolimatta on projektissa päästy eteenpäin sovitussa aikataulussa.

Kaiken kaikkiaan kokemus on ollut mahtava ja siitä suurin kiitos Japanille. Mahdollisuudesta tehdä matka ja etätöitä iso kiitos niin asiakkaalle kuin Codentollekin!

Katso Codenton avoimet työpaikat

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.