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.

Arvoketjukartta hahmottelee toimintaympäristösi – ja visioi herkullisemman tulevaisuuden

Teimme budjetoinnin ja projektien arvioinnin tueksi lean-projektikartan. Olemme nyt käyneet usean asiakkaan kanssa keskusteluja siitä, miten lean-projektikartta auttaa heitä ja miten sitä voi hyödyntää tekemisen suunnittelussa. Vaikka lean-projektikartta on yksinkertainen täyttää, tarvittavat päätökset eivät aina ole itsestään selviä. Useamman kerran olemme päätyneet keskustelemaan siitä, millä perusteilla pitäisi painottaa toiminnan ylläpitoa tai milloin pitäisi tehdä mullistavaa kokeilua asiakkaan kanssa. Kysymyksiin vastaamiseen tarvitaan kaksi asiaa: 1) Missä tilanteessa ollaan nyt ja 2) Mihin tilanteeseen toivotaan päästävän.

Vastaukset eivät selviä täyttämällä lean-projektikarttaa. Tarvitaan näkemystä toimintaympäristöstä yli ajan – tarvitaan visio.
– Toimiva visio johdattaa organisaatiota kohti haluttua tilaa ja auttaa linjaamaan päivittäiset ratkaisut pitkän ajan tavoitteeseen
– Päivittäisessä työssä auttavan vision pitää olla ymmärrettävä, sitä kohti pitää voida edetä ja sen pitää olla motivoiva

Toimintaympäristön kokonaisvaltaisen ymmärtämisen kautta muodostettu tahtotila organisaation paikasta toimintaympäristössä on tukeva pohja visiolle. Kun vielä ymmärretään organisaation kyvykkyys vaikuttaa omaan positioonsa toimintaympäristössä, ollaan jo hyvän vision jäljillä.

Me Codentolla olemme käyttäneet muun muassa Simon Wardleyn arvoketjukarttaa, kun fasilitoimme toimintaympäristön kuvaamista. Tämä malli on tehokas väline kiinnittämään keskustelu yhteiseen viitekehykseen ja luomaan yli keskustelutilanteiden kantava ja asteittain yhä tarkentuva malli toimintaympäristöstä. Wardley map eli arvoketjukartta esittää asiakkaan keskiössä. Asiakas näkee käyttämänsä palvelun muodostavasta arvoketjusta lähinnä itseään olevat osat. Asiakasta ei yleensä suuremmin kiinnosta, millä alustalla palvelu pyörii tai miten palvelu on varmistanut internet-yhteytensä tai sähkönsaantinsa – palveluntarjoajalle tämä on kriittistä tietoa.

Jos liiketoimintasi on tuottaa asiakkaillesi välitöntä nautintoa vaikkapa ketterällä macaron-keksien toimituspalvelulla, sinun kannattaa miettiä hyvin tarkkaan miten palvelua tuotat nyt ja jatkossa. Siinä missä teknologian hype-sykli kuvaa yksittäisten teknologioiden kypsymistä yli ajan, Wardley map auttaa ymmärtämään sitä toimintaympäristöä, jossa organisaatio toimii nyt ja yli ajan. Siksipä arvoketjukartassa organisaation arvontuottoketjun kannalta olennaiset toimijat kuten esimerkiksi kilpailijat, toimittajat ja jakelijat kuvataan yhteen kuvaan. Samalla arvioidaan, millä tahdilla ne ovat kypsymässä uutuudesta massahyödykkeeksi. Lisäksi mietitään, mihin omaa organisaatiota kannattaisi toimintaympäristössä luotsata. Mikä olisi sen visio.

Saattaa olla että ketterä macaron-keksien toimituspalvelu menestyy juuri nyt hyvin – mutta jatkoa suunniteltaessa on vaarallista katsoa sitä mitä tapahtuu juuri nyt. Asiakkaasi sanovat, että haluavat makuja mielialansa mukaan. Lähdetkö toteuttamaan toivetta upouutta tilausdrone-konseptia kehittämällä vai pelaatko korttisi niin, että olet ensimmäisten joukossa käyttämässä Amazonin tarjoamaa “välittömästi mitä vain” -alustaa? Molemmat voivat olla voittava käsi, mutta onko organisaatiollasi varaa tehdä molemmat? Ja jos ei, millä kriteerillä valitset? Arvoketjukartta auttaa hahmottamaan tulevaisuuden menestysvisiot.

Jos haluat sparrausta, ota yhteyttä! miika.kuha@codento.com

 

 

DevOps on kuin robotisaatio

DevOps on mukavan lähestyttävä trendi. Sitä voi tavoitella pienissä pätkissä ja jo ensi askeleista voi olla suuri hyöty, kunhan ne on oikein valittu.

Hyvien tai erittäin hyvien ohjelmistojen kehittäminen oli ennen kuin Rolls Roycen käsin rakentamista. Hidasta, kallista ja jokainen työvaihe vaati erikoisammattilaisen, jotta kokonaisuus ei kärsisi. Jokaisen vaiheen käsityö on asiakkaasta tuntunut tärkeältä, sillä onhan valitulla mallilla ennenkin saatu hyviä rollsseja.

Kokeilua ja yhteistyötä

DevOps on kokeilevan kehityksen toimintamalli, jossa sovelluksia kehitetään pikaisesti iteroiden ja matalalla kynnyksellä. Aiemmin kehittäjät (Development) ja tuotanto (Operations) ahersivat omissa siiloissaan ja yhteistyö ei ollut aina kovin tiivistä. Kehittäjät kehittivät ja tuotanto vastasi järjestelmien pyörityksestä. Siilojen väliin katosi paljon tärkeää tietoa.

Enää edes maailman superrikkailla ei ole varaa tehottomiin työtapoihin. Tehtailla noudatetaan kiltisti tehokkaita Lean-menetelmiä ja ne työvaiheet, jotka voidaan, automatisoidaan robotein ja alihankinnan kautta. Turhat siilot on purettu. Kun kokonaisuus on hyvin hallittu, teknologia ei heikennä laatua vaan itse asiassa parantaa sitä.

“DevOps tarvitsee olutta”, innosti seminaaripuheessaan virolainen DevOps-evankelista Kaimar Karu, tarkoittaen sitä, että kehittäjien ja tuotannon tulee viettää aikaa yhdessä ja tutustua toisiinsa.

DevOpsilla parempaa softaa nopeammin

DevOps on toimiva kattonimi sille, että ohjelmiston kehittämistä, testausta, käyttöönottoa ja ylläpitoa lähestytään prosesseina, jotka kannattaa mahdollisuuksien mukaan saada kerrasta toiseen tehtyä juuri samalla tavalla. Investoimalla alussa työaikaa, ja ehkä vähän työkaluihinkin, saadaan työvaiheet, joiden teko oli ennen työlästä, toimimaan täysin tai osin automaattisesti.

Kun DevOpsissa onnistutaan, yritys menestyy ja paradoksaalisesti Rolls Roycen tai Valmetin autotehtaan tavoin, palkkaa lisää väkeä tekemään yhä enemmän tulosta. Suurin hyöty on usein siinä, että hyvin robotisoitu, eli devopsattu, ohjelmistokehitys tuottaa parempaa softaa nopeampaan tahtiin. Tällaista on mukava kaupata asiakkaille.

Moni uusi johtamismalli on haastava ottaa käyttöön, sillä monista malleista saadaan hyötyjä vasta vuosien kuluttua. DevOps on käyttäjäystävällisempää ja ketterämpää. Useimmissa organisaatioissa ensivaiheet, kuten ohjelmiston automaattinen kääntäminen lähdekoodista ajokelpoiseksi (continuous integration eli CI) tai ohjelmiston automaattinen asentaminen käännöksen jälkeen testilaitteistoon, kuten servereille, on varsin suoraviivaista.

Oletko ottanut jo ensimmäisen askeleen devopsiin yrityksessäsi? Mitä ajattelit tehdä tämän eteen seuraavassa strategisessa suunnittelupalaverissa?

-Petri
Twitter @aukia