BYEBYE WOODS, FOR NOW

 

Code in the Woods Day 5 - Retro

Viikon viettäminen metsässä yksin tuntemattomien kanssa on pelottava ja rohkea päätös keneltä tahansa, saati sitten itsenäiseen työskentelyyn tottuneelta varhaisemman vaiheen koodarilta. Asut viikon poissa mukavuusalueeltasi, pysäytät oman elämäsi ja työsi kotipaikkakunnallasi viikoksi ja tarkka sijaintisi Etelä-Suomen kartalla on tuntematon. Hakemuksia kuitenkin satoi tähän yllätyhulluun ohjelmaan mieletön määrä ja kartanoon valikoitui uskomaton porukka, jonka kanssa lähtöasetelmat yhteiseen viikkoon olivat kohdillaan.

Tämä uskomaton viikko on nyt monen hienon hetken jälkeen takana ja koko tiimi osallistujista, mentoreihin ja ohjelman rakentajaan Lauri Svaniin jättää minut ilosta sanattomaksi. On ainutlaatuinen etuoikeus saada todistaa sitä omistautumista, intohimoa ja lämpöä, jolla nuoret osaajamme ovat työskennelleet. Kuten osallistujamme Teemu sanoikin, 6 viikon opintojakson työ on tiivistetty 4 päivään. Ja, mikä parasta, tiimimme selvisivät siitä ja demot saatiin ulos, älytöntä!

Code in the Woods ei jäänyt tavalliseksi koodaustapahtumaksi. Sulkiessani viimeisenä kartanon oven, joka oli viikon ajan toiminut kotinamme, saatoin varmuudella sano, että me olemme muodostaneet pienen Woods -perheen. Yhteisön, joka on täynnä ystävyyttä, vertaistukea, mentorointia, saunomista, naurua, väsyneitä tunteja ja toivottavasti monia yhteisiä ohjelmointi- ja oluthetkiä myös jatkossakin.

Rosa Smolander,

Code in the Woods koordinaattori, Barona Technologies

4 PÄIVÄÄ

4 TIIMIÄ          

4 DEMOA

Code in the Woods Day 4 - Demonight

80 tuntia, 7 kahvipakettia, 90 teepussia ja 3 enemmän tai vähemmän nukuttua yötä myöhemmin Code in the Woods kartanossa on syntynyt 4 verkkopohjaista applikaatiota, 20 uutta ysävyyssuhdetta, 4 kovaa ohjelmointitiimiä ja yksi yhteinen perhe.

Viikko on ollut haastava jokaiselle tiimille lähtötasoa katsomatta. Moderni teknologia on kaikille uutta, eteentulevat esteet yllätyksellisiä ja aika ohjelmointiin on varsin rajattua. Tästä kaikesta huolimatta jokainen tiimeistä onnistui mahdottomalta tuntuneessa haasteessa. Kaikki saivat demot ulos! Tässä pientä tuntumaa siitä, mitä tiimit YLE Appiksista muotoilivat:

1. Ylen anti

Kova Code in the Woods tiimi Ylen Anti helpotti käyttäjän turhautumista pätkivään nettiyhteyteen. Tiimi rakeni Le Off -applikaation, joka lataa toivotun videomateriaalin käyttäjän laitteelle sekunneissa ja Pasila-jaksoja voidaan nyt katsoa ilman nettiä niin lentokoneissa kuin junissakin. Samalla selvisivät myös viikon mystiset nettikaistan kaappajat.

2. CatCycle

Tiimi CatCycle omien sanojensa mukaan on tehostanut kissavideoiden katsomisen. Applikaatio ajoittaa videon katselun aikana klikatut tykkäykset oikeaan kohtaan videota niin, että katsojan nautittavaksi jäävät vain niiden parhaat palat. Alapeukutetut pätkät voi skipata suosiolla. Tästä löytyy potentiaalia Vine complitation-tuotannon automatisointiin!

3. Fiilis

Fiiliksen demoon pääsivät kaikki osallistujat mukaan. Fiilis sosialisoi TV:n katsomisen etäisyyksien yli ohjelmaa reaaliaikaisesti seuraavalla chattipalvelullaan. Applikaatiossa saman ohjelman fiilistely onnistuu vaikka koko suvun kesken mobiilin välityksellä.

4. Leffalegendat

Leffalegendat taas yhdistivät valtavat elokuvakirjastot ja YLE Areenan sisällöt. Aapplikaation avulla unohtuneet Tauno Palon klassikot ja vanhat venäläiset scifielokuvat löytyvät vaikka pelkän tunnusmusiikin tai pelkistettyjen hakusanojen nimillä.

Lyhyenä aikana ja uusilla teknologioilla tuotetut työt olivat valtavan, mutta onnistuneen puserruksen takana. Ilta päättyi hyvin ansaitusti pikkutunneille juhlittaessa paljun, saunan ja grillin siivittämänä. Onnistumisen ilo ja yhteisön hyvä fiilis oli käsinkosketeltava ja loistava päätös yhteiselle työlle.

Rosa Smolander,

Code in the Woods koordinaattori,  Barona Technologies

HEI ME KOODATAAN!

 

Code in the Woods Day 3 - Prototype

UX-suunnitteluntäyteisen tiistain jälkeen Code in the Woods tiimit pääsivät vihdoin koodaamaan täyttä häkää. Aamulla pohjatiedoiksi otettiin selainkehityksen knoppeja ja API-koodausta, jonka jälkeen tiimit lähtivät toteuttamaan kukin omia projektejaan. Tiimien fiiliksiä kysyttäessä yleisin vastaus meni jotakuinkin näin: “Yllättävän hyvin menee!” Tähän löytyi montakin syytä, joista osa oli tullut monelle tiimille uutena. Tässä muutamat päivän aikana esiin tulleet opit yhdestä kuuteen:

1. Tiedä mitä teet.

Kahden edellispäivän aikana tiimit ovat paitsi huolehtineet ympäristöt ja muut perusasiat kuntoon, myös kristallisoineet ja luonnostelleet ideansa sekä suunnitelleet sen ensimmäisen version varsin tiivistunnelmaisessa designsessiossa. Lisäksi tiimit olivat jakaneet tehtäviä taskeihin ja priorisoineet niitä toimivaan päivän työstöjärjestykseen. Kun tehtävät ovat tiedossa, ei tarvitse jäädä arpomaan mitä tehdä.

“Meillä on tässä hyvin yksinkertainen versio pääideasta: käyttäjä voi reagoida tiettyyn kohtaan videota”. -Code in the Woods tiimi Niina, Tunde, Jami ja Felix

2. Käytä valmiita sapluunoita.

Hyvä pohjatyö auttaa muutenkin: kun API on tiedossa ja dokumentoitu, softalle löytyy pohja ja työkalut valmiina, käyntiin pääsee nopeasti.

Aika harvoin projektia kannattaa aloittaa täysin nollista. Useimmilla frameworkeillä on oma “Hello world”-starttipakettinsa, jossa tärkeimmät riippuvuudet ovat valmiina ja rakenne noudattaa sovittuja konventioita. Se helpottaa paitsi aloittamista myös useamman ihmisen tekemistä: konventiot niin nimeämisessä kuin hakemistorakenteessakin helpottavat tekemistä.

3. Jätä toisto koneelle - buildityökalu on painonsa arvoista kultaa

Ensimmäisiä projekteja yksin tehdessä Gulpin kaltaiset buildinhallintatyökalut voivat tuntua turhanpäiväisiltä. Eikös tämän saman homman saa tehtyä skriptillä suoraan komentoriviltä?

Ongelmia alkaa kuitenkin tulla, kun scope kasvaa ja halutaan tehdä myös kunnolla. Skriptirivi kasvaa pituutta, sitä pitää muokata eri käyttötapauksia varten, tai softan käynnistys alkaa vaatia useamman rivin ja alat pohtia käynnistysloitsujen siirtoa omaan shelliskriptiinsä.

Haluat ehkä että javascriptit kerätään build-tiedostoonsa, ja ne kerätään kuvien kera dist-hakemistoon. Kehityksessä halutaan ehkä käyttää eri rajapintoja kuin julkaistavassa versiossa. Softalle halutaan ajaa linttiä tai minimoida tai obfuskoida javascript-filet.

Tässä työkaluksi apuun tulee buildityökalu. Niitä on monenlaisia ja moneen lähtöön, mutta yhteistä on, että ne huolehtivat riippuvuuksista, käynnistämisestä ja monista pienemimistä tehtävistä. Niitä voi myös yhdistää toisiinsa. Buildityökalut ovat alan standardi ja useimmat ammattilaiset muistavat (tai käyttävät edelleen) esimerkiksi Makefilea, joka on ollut C++-ohjelmien de facto buildityökau. Grunt ja sittemmin Gulp ovat vallanneet sijaa Javascript-maailmassa. Työkaluissa kestää toki hetki oppia, mutta se on sen väärti

4. Pidä koodi siistinä - lintteri

Kaksi vai neljä merkkiä indentaatiota? Koodarien ikuisuustaistelu on välillä turhauttava, mutta silläki on merkityksensä: koodin on syytä näyttää yhtenäiseltä jotta sitä on helppo lukea ja muuttaa. Lintteri voi tarkistaa sisennykset, mutta se tekee paljon muutakin: tarkistaa nimeämiskäytäntöjä, varoittaa mahdollisista sudenkuopista ja auttaa tiimiä noudattamaa kovaa kuria. Äitisi ei siivoa täällä, joudut itse tekemään sen.

5. “Gitti on kova” - Käytä versionhallintaa!

Neljänkin hengen projekti alkaa mennä mahdottomaksi ilman versionhallintaa. Oivallus onkin, miten paljon helpompaa koodia on jakaa isommallakin porukalla kun merget ja diffit hoitaa kone, ei yksi tiimin jäsen silmät ristissä ;)

6. Käytä työkaluja myös projektinhallintaan

Joskus post-it riittää, mutta esim. Trello on hyvä ja yksinkertainen työkalu todo-listan hallintaan ja priorisoitiin. Muista tehdä valmiita, julkaistavia kokonaisuuksia.

Tätä kirjoittaessa ulkona on pimeää ja sisällä valoa tulee paristakymmenestä läppärin ruudusta. MVP on monella lähelle valmista: softa ei näytä vielä kovin hyväoltä mutta ainakin jokin päätoiminnallisuus on jo valmiina. Tekeminen jatkuu myöhään yöhön ja huomenna päästään viimeistelemään.

Kirsi Louhelainen,

Code in the Woods mentori, Barona Technologies

Mitä, kenelle ja miten? - Älä HyPPÄÄ HETI toteutukseen

Code in the Woods Day 2 - Design

Ennen kuin syöksyt koodaamaan tuotettasi, hengähdä ja suunnittele hetki. Tämä yleensä säästää kallisarvoista aikaasi isossa kuvassa.
Kerää tietoa siitä, mitä jo tiedät ja hanki lisää tietoa käyttäjistä. Käy läpi löydöksesi. Jäsennä tietoasi ryhmittelemällä sitä toisiinsa liittyviksi asiakokonaisuuksiksi. Rajaa haasteesi uudelleen ja yritä löytää sieltä ongelman ydin, jota lähdet aluksi ratkaisemaan. Yleensä toteutus kannattaa aloittaa sieltä, missä on suurin riski ja potentiaalinen bisnes. Muiden ihanien asioiden vuoro tulee kyllä ajallaan!

Validoi ideoitasi oikeilla käyttäjillä. Tee luonnoksia valmiiksi viilattujen näkymien sijaan kommunikaation tukesi. On tärkeää saada palautetta mahdollisimman aikaisessa vaiheessa, jotta käytettävissä oleva aika kuluu oikeisiin asioihin. Jos mahdollista, ota oikeita käyttäjiä mukaan suunnittelutyöhösi. Ole valmis myös luopumaan rakkaimmistakin ideoistasi uusien syntyessä. Priorisoi ideasi ja pidä priorisointi ajan tasalla ideoiden lisääntyessä. 

Kun sinulle on selvää, mitä ryhdyt tekemään ja missä järjestyksessä, kääri hihat ja lähde toteuttamaan ensimmäistä versiota! Siis ensimmäistä versiota. Ei kaiken sisältävää valmista tuotetta, vaan ensimmäistä versiota, jossa on vain se kaikkein oleellisin, mitä ilman tuotetta ei voi julkaista.

Hanki palautetta ja priorisoi palautteen perusteella ideasi uudelleen. Tee seuraavaksi tärkein asia, mutta vain, jos sen tekeminen on vaivasi arvoista. Toistakaa kunnes ominaisuuksien lisääminen ei ole enää vaivasi arvoista!

Heidi Holm,

Code in the Woods mentori, Forenom

Today 16 coders entered the Woods

Code in the Woods -viikko lähti tehokkaasti käyntiin kun 16 hakijaseulan läpäissyttä junior ohjelmoijaa ympäri Suomen asettuivat yhteiseen kartanoon keskelle metsää. Kukaan ei tunne ketään, mutta viikon päätteeksi kartanosta astuu ulos tiivis joukko uusia applikaatio-ohjelmoinnin osaajia.

Verkkosovellus valmiiksi viikossa

Kartanon ohjelma rakentaa osallistujien projekteja kohti valmista applikaatiota työpajojen ja asiantuntijamentoreiden kautta. Ohjelma käy läpi applikaatiokehityksen perusteet suunnittelusta, rakennukseen, kevyeen testaukseen sekä Webin tuomiin etuihin ja erikoisuuksiin.

Tiimit työskentelevät läheisessä yhteydessä ohjelman toteuttajan Lauri Svanin sekä mentoreiden tukemana. Henkilökohtaisia oppejaan ja tietämystään viikon aikana metsässä ovat jakamassa mm. Barona Technologiesin teknologinen kehitysjohtaja Kirsi Louhelainen, Lead Developer Matti Saikkonen sekä fullstack developer Niklas Appelroth. Forenomin puolelta tiimien design tukena toimii Forenomin digitaalisten palvelujen suunnittelija Heidi Holm.

Toisiaan täydentävät osaajat

Ohjelman devaajat työskentelevät viikon aikana neljään eri tasoryhmään jaetussa tiimissä, joissa kokeneemmat ohjelmoijat pääsevät yhdessä haastamaan toisiaan haastavimmilla teknologioilla kun taas ohjelmoinnin varhaisemmat alkajat saavat tukea toisiltaan oman applikaationsa rakennuksessa. 

"Tiimi on ihan huikea. Heittelemme ideoita vapaasti ja sitten mietimme yhdessä miten voimme viedä näitä käytäntöön" Marjanah Sadiq, itseoppinut Code in the Woods osallistuja.

Code in the Woods osallistujakaartiksi valikoitui värikäs ja monitieteinen porukka, jossa kenenkään tausta ei ole samanlainen kuin toisella. Koodareita niin itseoppineena, matemaatikkona, humanistina kuin puoliammattilaisena kovan työuran tehneenä fuksina. Kartano on muuttunut osaajien kattilaksi. Matkaa voit seurata blogissa viikon ajan ja ohjelman jälkeen.

Rosa Smolander,

Code in the Woods koordinaattori

Palveluja ilman palvelimia

Menneitä ovat ajat, jolloin yksi rikkoutunut tuuletin, saattoi pysäyttää koko yrityksen toiminnan. 2000-luvun alussa yleistynyt palvelimien virtualisointi vie fyysiset palvelimet pilveen, mutta se ei pelkästään lisännyt vikasietoisuutta, vaan mahdollisti myös laskentaresurssien tehokkaamman käytön. Fyysiset palvelimet jouduttiin monesti mitoittamaan kuormapiikkien mukaan, sillä uuden palvelimen hankkiminen oli päivien, ellei viikkojen työn takana.

Virtualisointi mahdollisti palvelimien hankkimisen minuuteissa, jopa täysin automatisoidusti, jolloin niitä voitiin lisätä ja vähentää kuormituksen mukaan. Tämä ei pelkästään lisännyt palvelimien kuormitusastetta vaan toi myös huomattavia kustannussäästöjä, eikä DevOps-kehittäjänkään enää tarvinnut huolehtia fyysisten palvelimien fyysisistä ongelmista.

Docker iski kultasuoneen vuonna 2013. Helppokäyttöinen työkalu paketoida palvelinohjelmistoja toisistaan eristettyihin kontteihin (container) tuntui ratkaisevan sovelluskehittäjien kaikki ongelmat. Kehittäjät eivät olleet ainoat Dockerista innostuneet vaan myös Amazonin, Microsoftin ja Googlen kaltaiset jätit julkaisivat nopealla tahdilla omat Docker-kontteja tukevat alustansa. Kontainerisaatio jatkoi siitä mihin virtualisointi jäi ja pilkkoi yhden virtuaalipalvelimen ohjelmistot omiksi konteikseen. Hallittavan yksikön koko pieneni palvelimen kokoluokasta prosessitasolle ja yksittäisen kontin resurssien allokointi voitiin tehdä megatavun ja CPU sekunnin tarkkuudella. Tämä yhdistettynä automatisoituihin hallintatyökaluihin, kuten Kubernetes, saatiin fyysisen palvelimen kuormitusasetetta nostettua entisestään. Kehittäjän huolehdittavaksi jää enää konttien toimivuus palveluntarjoajan huolehtiessa lopusta. 

“Nimensä mukaan serverless poistaa palvelimen käsitteen kehittäjältä, toki taustalla on edelleen palvelimia, mutta ne ovat palveluntarjoajan huoli.”

Tässä vaiheessa trendi alkaa jo hahmottua. Hallittavan yksikön koko on pienentynyt moniprosessoripalvelimesta yhden prosessin tasolle ja viime vuosina tuulta purjeisiinsa saanut serverless-arkkitehtuuri haluaa pilkkoa sitä entisestään. Nimensä mukaan serverless poistaa palvelimen käsitteen kehittäjältä, toki taustalla on edelleen palvelimia, mutta ne ovat palveluntarjoajan huoli. Nyt pilkottavaksi joutuu itse ohjelmisto, joka pilkotaan toisistaan irrallisiksi funktioiksi ja näitä funktioita suoritetaan vain pyydettäessä. Suorituksen käynnistää aina jokin triggeri, kuten HTTP-kutsu tai työjonoon ilmaantunut tehtävä. Jos triggereitä ei tule, mitään ei myöskään suoriteta, eikä laskuteta. Itse funktiot suoritetaan palveluntarjoajan suurissa klustereissa, jolloin skaalautuvuuden rajat eivät kovin nopeasti tule vastaan suurillakaan kuormapiikeillä. Erityisesti web-sovellusten purskeiset kuormat soveltuvat serverless-arkkitehtuuriin, jossa maksetaan vain käytetystä suoritusajasta, eikä palvelinkustannuksia tule siltä ajalta, kun käyttäjä miettii seuraavaa liikettään. Palveluntarjoajan saamalla mittakaavaetulla saadaan yhä parempi kuormitusaste, sillä sen sijaan että palvelinklusteria skaalattaisiin yhden asiakkaan kuormitustarpeiden mukaan voidaan, nyt käsitellä satojen asiakkaiden kuormaa yhdellä klusterilla. 

Dockerin menestyksen takana oli yksi yhtenäinen toteutus, joka oli helppo ottaa käyttöön alustalla kuin alustalla. Servelessiä vaivaa vielä yhtenäisyyden puute, jokainen palveluntarjoaja toteuttaa alustan omalla tavallaan, omilla rajoituksillaan. Nähtäväksi jää löytyykö palveluntarjoajilta yhteinen sävel vai korvaako sen joku toinen, vielä hienompi buzzword. 

Jari Ylimäinen

DevOps Specialist, Forenom

Verkkopohjaisuus  liiketoiminnan      ja Tiimin tukena

Ketterän kehityksen toteuttaminen perinteisessä mobiiliympäristössä ei ole mikään triviaali ongelma. Erilaiset hybridiratkaisut kuten phonegap ja Facebookin react native tuovat parannuksia moniin natiivialustojen ongelmiin ja helpottavat uudelleen käytettävän koodin kirjoittamista. Ne eivät kuitenkaan ratkaise sitä, kuinka ketterän kehityksen yksi peruspilareista eli sitä kuinka iteratiivinen kehitys ja pienet muutokset toteutettaisiin tehokkaasti. Niin kauan kuin uuden version julkaisu kulkee kolmannen osapuolen ylläpitämän app storen kautta, on prosessi väistämättä kankea ja hidas.

Natiiviteknologioista puhuttaessa, julkaisurytmiin vaikuttaa myös kehitettävän koodin määrä. Eri alustaversioiden yhtäaikainen kehitys vaatii lisäkoodin kirjoittamisen lisäksi myös erinäisen määrän asioiden koordinointia ja eri softaversioiden yhtäaikaista tukemista. Kaikki tämä maksaa kehitystiimille huomattavia rahamääriä, ja koodarin kannalta ennen kaikkea vaikeuttaa arkipäivästä toimintaa. Mitä suurempi osa panoksesta kuluu uusien toiminnallisuuksien kehittämisen sijasta ohjelmistokehityksen muihin tukitoimiin, sitä vähemmän impactia tiimi saa aikaiseksi.

Progressiiviset verkkopalvelut ohittavat app storen kankean julkaisuprosessin ja yksinkertaistavat kehitystä. Näin uuden version julkaisu tapahtuu samalla tavalla kuin normaalin webbisivunkin ja tuotannossa on kerralla vain yksi versio softasta. Vaikka progressiiviset verkkosovellukset eivät olekaan täydellinen ratkaisu kaikkiin ongelmiin, ovat ne ylivertaisia ketteryydessä. Nopeasyklisessä tuotekehityksessä mahdollisuutta julkaista uudet versiot softista välittömästi samoilla menetelmillä kuin tavallisilla nettisivuilla, ei kannata aliarvioida.

Matti Saikkonen,

Code in the Woods mentori

Web-teknologiat ovat valinta avoimemman tulevaisuuden puolesta

Valinta web- ja natiivisovelluksen välillä on projektin alkuvaiheen päätös, joka tehdään tänään ja myös tulevaisuudessa enemmän uskomusten kuin faktojen pohjalta. Valintatilanteessa kumpikin leiri painottaa niitä asioita, jotka tukevat omaa teknologiaansa; käytännössä kukaan ei projektin alussa tiedä, mitä sovellukselta lopulta vaaditaan. Yksinkertaistettuna valinta tehdään loppujen lopuksi avoimen ja suljetun maailman välillä. Miksi tällä on merkitystä?

Natiivisovellusten kehittäminen muistuttaa hyvin paljon perinteistä Windows-sovelluskehitystä, jossa Microsoft julkaisee vuorovuosittain käyttöjärjestelmästään uuden version, sovelluskirjastot ja niiden mukana joukon muutoksia, jotka johtavat sekä käyttöjärjestelmän että sovellusten päivitykseen. Windows on edelleen maailman suosituin kannettavien- ja työpöytäkoneiden käyttöjärjestelmä, mutta se ei ole saavuttanut vastaavan kaltaista suosiota kännyköissä ja pilvipalveluissa, joiden merkitys markkinoilla on kasvanut. Lisäksi selainpohjaiset sovellukset ovat nakertaneet työpöytäsovellusten markkinoita, koska ne eivät samaan tapaan ole käyttöjärjestelmästä tai tietokoneesta riippuvaisia.

“Onko syytä olettaa, että Applen ylivoimalle ja iOS-käyttöjärjestelmälle käy jonain päivänä kuin Windowsille - se menettää merkityksensä kun käyttötapa muuttuu?”

Ilmiö on tuttu avoimen ja suljetun innovaation teorioista. Suljetun innovaation mallissa yritys tutkii omien ja asiakkaidensa tarpeiden pohjalta eri vaihtoehtoja, joiden pohjalta idea tuotteistetaan, suojataan ja tuodaan markkinoille. Malli on tehokas ja ratkaisut vastaavat hyvin tunnistettuun tarpeeseen. Yritys keksii kaiken, kantaa kaiken riskin  ja myös korjaa kaiken hyödyn itse. Vastaavasti avoin innovaatio poimii ideoita ulkopuolelta ja jalostaa niitä yhdessä muiden kanssa eteenpäin. Kilpailuetu ei perustu ideaan vaan yrityksen muun liiketoiminnan ainutlaatuisuuteen. Vastaavasti syntyneitä innovaatioita voidaan hyödyntää alkuperäisen käyttökohteen ulkopuolella.

Web-teknologiat edustavat avointa innovaatiota. Tunnetuin esimerkki tästä on vanha kunnon WWW ja HTML, josta hypertekstijulkaisujen sijaan tuli 2000-luvun verkkopalveluiden yhteinen kieli. Alkuperäinen HTML 1.0 -standardi ei sopisi verkkopalveluihin tai kännykkäsovelluksiin kovinkaan hyvin, mutta sen HTML5-version ja PWA-sovellusten kautta se kehittyy yhä paremmin uuteen tarkoitukseen sopivaksi. Samoin webbisivujen skriptikielestä, ECMAScriptistä, on tullut myös palvelinympäristöjen kieli Node.js -alustan ja sen maailman laajimman kirjastokokoelman myötä.

Sekä selainstandardeja että ECMAScriptiä kehitetään avoimesti yhteisön voimin ja ne poimivat jatkuvasti ideoita ympäriltään (esim. ECMAScriptin asynkroniset Promise-kutsut). Vaikka Apple, Microsoft ja Google ovat kukin avanneet omia alustojaan (erityisesti ohjelmointikielien osalta), ne pitävät alustan sovellusrajapinnat visusti omissa käsissään.

“On hyvin todennäköistä, että web-teknologiat saavat uusia käyttökohteita, joista emme tiedä vielä mitään. Onko syytä olettaa, että sama tapahtuisi esim. suljetuille iOS- tai Windows-alustoille - ainakaan Applen tai Microsoftin ulkopuolella?”

Natiivisovellukset tarjoavat kullekin alustalle omat sovelluskirjastonsa, kehitysympäristönsä ja sovelluskauppansa. Se on tehokasta ja toimii silloin kun tarpeesi on huomioitu jo ennalta. Esimerkkinä tästä toimii Applen haluttomuus tukea sovelluskauppansa ulkopuolisia maksutapoja. Vastaavasti selainsovellusten kehittäminen on paikoin kaoottista ja turhauttavaa muuttuvien teknologioiden jatkuvassa tulvassa. Maksutapojenkin kohdalla selaimiin juuri julkaistiin oma standardiehdokkaansa ja verkkopalvelut hyödyntävät tusinaa eri maksumekanismia Stripestä Paypaliin. Toisaalta web-sovellusten teko on tänään paljon helpompaa ja ne toimivat paljon paremmin kuin vielä pari vuotta sitten ja tarjoavat uutta opittavaa joka päivä.

Avoimissa teknologioissa yhteisö kukoistaa myös paikallisesti - ei vain verkossa. Esimerkiksi HelsinkiJS lienee Suomen aktiivisin kehittäjäyhteisö, jossa näkyy ja tapahtuu jatkuvasti uutta. Avoimissa yhteisöissä maailmaa voi muuttaa kotoa käsin eikä tarvitse odottaa, että muutos tapahtuu Cupertinosta tai Redmondista käsin.

Kun kehitän avoimilla teknologioilla, koen että osallistun johonkin laajempaan kuin vain seuraavan sovelluksen julkaisuun. Se on minun tapani osallistua jatkumoon, joka oli ennen mobiilisovelluksia, ja jatkuu jonain muuna vielä mobiilisovellusten jälkeenkin.

Lauri Svan,

Code in the Woods mentori