programming, Vulnerabilities_and_Bugs

Kriittinen Intel AMT haavoittuvuus (etähallinta)

Haavoittuvuuden tunniste

Sisäisesti Intel kutsuu bugia “INTEL-SA-00075”. Kansainvälisesti se on tunnettu nimellä CVE-2017-5689

Millainen bugi on kyseessä?

Huonosti toteutettu osa Intel AMT -etähallintajärjestelmässä, joka kohdistuu pääkäyttäjän salasanan tarkistukseen, tekee järjestelmän käytännössä täysin turvattomaksi: salasanaksi riittää pelkkä tyhjä (“ei mitään”). Tämä koskee tietokoneita, joissa on jokin alla olevaista Intelin AMT firmwaren versio:

  • 6.x
  • 7.x
  • 8.x
  • 9.x
  • 10.x
  • 11.0
  • 11.5
  • 11.6

Jos hyökkääjä pääsee samaan sisäverkkoon, missä tietokone sijaitsee, hän voi ottaa yhteyttä pieneen AMT:n sisäiseen web-serveriin, ja avata täydet oikeudet antavan etäyhteyden. Tämän myötä hyökkääjä omistaa koneen käytännössä täysin, loogisella tasolla: hyökkääjä voi asentaa ja poistaa ohjelmia, päättää mitä koodia ajetaan ennen koneen käyttöjärjestelmän käynnistymistä; jne. Hyökkääjä voi myös asentaa esimerkiksi uusia etähallintatyökaluja (takaovia, rootkittejä).

Pieni virhe firmware-koodissa: suuri vaikutus

Ongelman ydin on yhdessä merkkijonon sisältöä vertaavassa
komennossa. Merkkijonoa verrataan C-kielen ‘strncmp’ funktiota vastaavalla rakenteella. Koodi ottaa 3 parametria: kaksi merkkijonoa, ja kokonaisluvun. Ohjelmoija on valinnut väärin kolmannen parametrin, jolloin verrattavien merkkien määrä otetaankin yritteen pituudesta, ei oikean asetetun salasanan pituudesta.

Kyseinen kohta koodissa vertaa sisäänkirjautuvan käyttäjän antamaa salasanaehdotetta oikeaan, tunnettuun salasanaan. Kokonaisluvun tehtävänä on rajoittaa vertailun pituutta: toisinsanoen jos esimerkiksi N=2, verrataan vain 2 ensimmäistä merkkiä, riippumatta olisiko oikea salasana pidempi.

Tällä on kahdenlaisia vaikutuksia:

  • vakavampi vaikutus on, että myös tyhjä salasanayrite päästää sisään
  • sivuvaikutuksena saatta olla, että oikean asetetun salasanan vahvuus heikkenee sanakirjahyökkäys-tyyppisissä skenarioissa

 

Uncategorized

Lyijytäytekynä ja Civilization

Joskus on hauska pysähtyä miettimään teknologian luonnetta.

Oli aivan arkinen aamu. Tein lyijytäytekynällä pientä vedosta, suunnitelmaa paperille. Painoin kynän päästä: halusin lisää lyijyä. Sitä ei tullut. Lyijytäytekynä on suhteellisen luotettava kapistus, mutta siinä on usein nämä omat oikkunsa; nimittäin joskus kynä jumittaa. Jumituksessa käy usein niin, että ilmeisesti syöttöön on mennyt väärän paksuinen lyijy, jolloin se jää kiinni ja alkaa murskautua metalliputkea vasten – “syöden” muutkin lyijyt, mikäli syöttömekanismi niitä yrittää perään työntää.

En ihmettele miksi lyijytäytekyniä lentää roskikseen. Jumituksen poisto nimittäin ei ole ihan triviaali juttu. Ongelmaksi muodostuu kynän ohut läpimitta – se on tietysti tuo 0.5mm tai 0.7mm riippuen kumman paksuista lyijyä kynä nimellisesti ottaa.

Aloin etsiä työkalupakista: kävisikö nasta putsaustyökaluna? Ei, liian paksu. Entä klemmari? Ei käy. Hakaneulan kärki? Liian paksu, ei jaksa työntää loppuun asti. Kuparinen pieni puunaula näytti jo varteenotettavalta! Ei.. Liian paksuja kaikki.

Löysin lopulta pienen palasen ilmeisesti alunperin sähköjohdon johdinta, jonka olin jostain alunperin saanut kuorimapihdeillä. Työntelin varovaisesti (noin ohut metalli myös taipuu helposti, joten tarvitsin käytännössä hohtimet avuksi) jumittavaa lyijyä, ja useamman yrityksen jälkeen koko kynän aukko oli puhdas: valoa vasten näki, että nyt tuli valo läpi.

Aikoinaan loistavassa PC-pelissä (Civilizationissa) rakennettiin omaa heimoa, ja taisteltiin naapuriheimoja vastaan. Peli opetti yhtä paljon yhteiskunnasta kuin myöhemmin opin koulussa. Pelissä oli tavattoman keskeisenä asiana erilaiset keksinnöt, joista oli hyötyä tuotannon ja taisteluvälineiden kehittämisessä. Keksinnöt riippuivat aiemmista löydöksistä. Esimerkiksi pyörän keksiminen mahdollisti käytännössä liudan muita asioita; sotavaunut (engl. ‘chariot) olivat varsin kelpo taistelujoukko, jos vastapuolella oli pelkkiä jalkamiehiä.

Massatuotannossa kulminoituu teknologinen keskinäisriippuvuus: lyijytäytekynä on todennäköisesti tuote, jonka on mahdollistanut vasta useiden eri korkean teknologian yhteiskäyttö. En tiedä, mutta voisin kuvitella, että tuollaisen Ballografin osat tulevat CNC-jyrsimen avulla. CNC-kone on metallurgian ja valmistustekniikan tuote itsessään – lisäksi sitä ohjaa iso kasa elektroniikkaa ja ohjelmistoja. Muoviosat kynään on valmistettu niinikään jonkinlaisessa teollisessa prosessissa. (Mustekynän valmistuksesta video – varmasti aika lähellä lyijytäytekynän prosessia)

Teknologialla on sitten kääntöpuolena, melkein aina, huoltotarve ja kompleksisuus. Enää emme varmasti koskaan mene sille tasolle, missä olimme 5000 vuotta takaperin. Olemme 2017 varsin pitkälle kehittynyt biologinen yhteiskunta – omalla tavallamme. Olemme verkottuneet, digitalisoituneet, ja näköpiirissä on jo keinotekoisia korvaavia elimiä yms. Materiaaliteknologia, tietotekniikka, lääketiede, ja moni muu ala etenee. Silti aina välillä iskee (jopa käytännön) tarve istahtaa alas ja rassata omin käsin tuo lyijytäytekynä auki.

Uncategorized

MongoDB -kaappaukset 2017

Tammikuussa 2017 uutisoitiin muiden tietoturvauutisten joukossa muutamista (sadoista, tuhansista?) ns. ransom-hyökkäyksistä, jotka kohdistuivat MongoDB -tietokantaa käyttäviin saitteihin ja palveluihin. Kevään 2017 edetessä ilmiö eteni kiihtyvällä tahdilla aika epidemiaksi.

Mikä on ransom -hyökkäys?

Ransom on siinä mielessä ikävä hyökkäys, että siinä data kaapataan, kryptataan lukkojen taakse, jonka jälkeen omistajaa kiristetään maksamaan vapautusmaksu. Alkuperäinen data joko poistetaan tai ylikirjoitetaan salakirjoitettuna, jolloin alkuperäisen järjestelmän omistajalle jää korkeintaan kasa satunnaiselta näyttäviä bittejä – tietoa ei voi sellaisenaan enää käyttää.

Hyökkääjä todennäköisesti jättää mieluusti kryptatussa muodossa olevan datan uhrille, jotta tämä vakuuttuisi enemmän mahdollisuudesta vielä nähdä alkuperäinen data maksun jälkeen.

Kuten mikä tahansa panttivankitilanne, takuita tiedon vapautuksesta maksun jälkeen ei ole. Usein maksu pyydetään elektronisessa muodossa, esimerkiksi Bitcoineina. Vapautus tapahtuu salasanan tai koodin / lukituksenpoisto-ohjelman kautta. (Kts. F-secure FSLabs -video aiheesta: Activation Ransom trojan (Youtube) – vaikka videossa on kyse Windowsin kaappaamisesta, periaate on aivan sama).

Nyt huhtikuussa 2017 paljastui enemmän teknisiä yksityiskohtia näistä MongoDB -kiristyksistä. Lukittujen järjestelmien lukumäärä on ilmeisesti yli 30000 tällä hetkellä.

Mikä mahdollisti hyökkäyksen?

MongoDB on siis tietovarasto. Ongelmaksi muodostui löpsö vakiokonfigurointi, joka on ollut olemassa kaikissa MongoDB:n 2.6.0 vanhemmissa versioissa: asennettaessa tietokanta ei vaadi asettamaan salasanaa pääkäyttäjälle. Toisin sanoen tietokanta on sepposen selällään kenelle tahansa joka huomaa tietyssä IP-osoitteessa pyörivän tietokannan.

Versiota 2.6.0 vanhemmissa tietokannoissa MongoDB suostuu ottamaan yhteyksiä vastaan “mistä tahansa” päin maailmaa, ja sen lisäksi, kuten aiemmin mainittu, se ei vaadi salasanaa. Toisin sanoen: jos pahaa tarkoittava hyökkääjä kokeilee hieman tikulla jäätä, ja huomaa että netissä on amatöörin pystyttämä MongoDB (versiota 2.6.0 aiempi), niin hyökkäys on pala kakkua. MongoDB on siis vakioasetuksilla täysin turvaton.

Miksi v. 2017 hyökkäykset yleistyivät?

Ensimmäisen kerran mahdollinen turva-aukko huomattiin jo 2015. Hackernews toitotti maailmalle, että webissä on satoja MongoDB:tä käyttäviä palveluita, joiden tietokanta on siis turvaton. Hackernews kertoi varsin selväsanaisesti myös viestin: tietokanta on vakioasetuksillaan todella turvaton.

Luulisi tällöin tapahtuvan jotain. Kenties turvatonta tietokantaa pyörittävän firman ylläpitäjä tai ohjelmoija muuttaisi pääkäyttäjän siten, että salasana turvaisi tietokannan tästedes?

Miksi tuhansia tietokantoja jäi silti suojaamatta?

On useita (mahdollisia) syitä.

  • tietoturva-aukosta kertova uutinen ei päädy koskaan asianomaisen näköpiiriin
  • uutinen on tiedossa, mutta firmassa on troijalainen – henkilö, joka ei toimi firman parhaiden intressien mukaisesti
  • ne kehittäjät, jotka ovat projektissa, eivät alunperin ole pystyttäneet tietokantaa, eivätkö tiedä haavoittuvuudesta. Arkkitehti on jo toisessa projektissa, tai lähtenyt firmasta.
  • uhkaa on tiedossa, mutta sitä ei pidetä riittävän suurena, jotta siihen “kannattaisi” reagoida
  • asia hautautuu jostain inhimillisestä syystä ja sitä ei käsitellä ajoissa

Enpä itsekään ollut tietoisesti tuota vuoden 2015 Hackernewsin uutista rekisteröinyt. Voi olla, että näin sen, satojen muiden tietoturvauutisointien kanssa. Toisaalta, itse en käytä myöskään MongoDB:tä mihinkään.

Laskelmoiva vs. haparoiva tietoturva organisaatiossa

Yritykset toimivat tietoturvan kanssa usein jommallakummalla tavalla: erittäin laskelmoiden, tai haparoivan satunnaisesti. Laskelmoivassa tavassa tehdään uhka-arviot, ja yksittäiset tunnetut ja tuntemattomat uhka-skenariot pisteytetään suurinpiirtein näin: “Kuinka todennäköinen hyökkäys on; paljonko hyökkäyksellä saavutetaan, ja mitkä ovat seurauksen kustannukset firmalle”. Kaikki tietoturvaan liittyvä toimet toteutetaan ottamalla pistelistalta kivuliammat ongelmat ensiksi käsittelyyn.

Haparoivassa tietoturvassa yksinkertaisesti laitetaan laput silmille ja koodataan menemään, sen kummemmin miettimättä koko asiaa. Firma maksaa myöhemmin ongelmista mainetappiona ja mahdollisesti myös oikeusteitse asiakkaiden karhutessa korvauksia. Jos hyvä tuuri käy, purkkaviritys ei koskaan edes joudu hyökkäyksen kohteeksi.

Laskelmoiva firma siis vähentää riskiä joutua tietoturvahyökkäyksen uhriksi.

Miksi näin laajat hyökkäykset ovat mahdollisia?

MongoDB -kaappauksista tuli hieman mieleen vuoden 2014 kohu-uutinen, Heartbleed -haavoittuvuus. Heartbleedissä pienen pieni koodinpätkä (joka oli sinänsä hyödyllinen, mutta ohjelmoitu väärin) teki miljoonista web-servereistä turvattomia: hyökkääjä saattoi lukea serverin keskusmuistia 64 kilotavun paloissa mielivaltaisen paljon. Heartbleedissä oli kyse netin perusputkiston, OpenSSL-kirjaston, bugista. Haavoittuvuutta hyväksikäyttävä hyökkäys ei jättänyt minkäänlaisia jälkiä lokitiedostoihin, koska nimellisesti hyökkäysliikenne näytti harmittomalta, normaalilta web-liikenteeltä: ainoa ero oli, että hyökkäyspaketissa oli yksi numero erilainen kuin normaalissa liikenteessä. Tuon numeron liian orjallisessa noudattamisessa OpenSSL-koodi teki fataalin virheen: se palauttikin hyökkääjälle paljon enemmän paluupaketissa (serverin muistin sisältöä) kuin olisi ollut fiksua.

Yleensä suuren tietoturvamokauksen paljastuttua alkaa analysointi ja sormen heristely. Kuka on alunperin jättänyt tietoturva-aukon järjestelmään? Miksi näin pääsi käymään? Oliko kyseessä vahinko vai tarkoituksellinen teko? Foliohattuteoriat myös usein saavat kannatusta tässä vaiheessa – ehkä osa näistä on oikeassa, todennäköisesti suuri osa ei ole. Aikoinaan 1980- ja 1990-luvulla tietokonevirusten suurin haitta tuli oikeasti ei niinkään tarkoituksella, vaan vahingossa – myös virusten kirjoittajat tekevät bugista koodia.

MongoDB on C++ :lla koodattu. Se ei oikeastaan vielä kerro mitään. Kieli on edelleen voimissaan, ja sitä ymmärtää sadattuhannet koodaajat. MongoDB on myös avointa lähdekoodia. Tämän pitäisi parantaa tietoturvaa, koska kuka tahansa voi käydä katsomassa, miten tietokanta ja sen turvatoimet on toteutettu.

Tekniikassa itsessään ongelma ei varsinaisesti piile. Ongelman ydin on paljon yksinkertaisempi: MongoDB valitsi käyttäjäystävällisen, “kivan” polun, sen sijaan että pakottaisi käyttämään salasanaa tietokannan suojaukseen.

Helppo ja kiva vs. turvallinen (napit vastakkain)

Kun virittelen aina silloin tällöin MySQL-kantaa omalla läppärillä, harmittaa sen vaatima salasana. MySQL:ssä on yksi pääkäyttäjä, jolla on oikeus tehdä mitä tahansa tietokannassa: lukea, muokata, ja poistaa tietoa. MySQL:ssä käyttäjän nimi on ‘root’.

Useimmiten MySQL on alustana, kun kokeilin jotain asiaa WordPress-blogissa – en täällä julkisessa Internetissä (Jukkasoft-blogissa), vaan omalla koneella. Käytän kantaa niin harvoin, että tuo salasana tuntuu sitten olevan “jossain” kun sitä tarvitsisi. Yleensä kirjoitan tuon salasanan vihkoon, jota pidän kaapissa. Tai vastaavaa.. No, kun 3-6 kk kuluu, voi olla että paperi on ajautunut hieman, enkä löydä välittömästi (alle 5 minuutin etsiskelyn) salasanaa.

MongoDB käytti toisenlaista strategiaa: se ei pakottanut pääkäyttäjää asettamaan tietokantaa turvaavaa salasanaa asennusvaiheessa. Eli ohjelmaa oli helpompi käyttää – kenties myös helpdesk sai vähemmän kyselyitä kadonneiden salasanojen palauttamisesta. (MySQL:ssäkin pääkäyttäjäsalasanan voi palauttaa, jos on itse koneen pääkäyttäjä:  ohje MySQL 5.7:lle ja muille versioille) Ilmeisesti ohjelmisto ajautui sitten sellaisenaan, suojaamattomana, myös paikkoihin joihin sen ei olisi pitänyt päästä – tuotantoon.

Asiakas, esimerkiksi web-saitin toteuttava ohjelmisto, keskustelee MongoDB:n  kanssa TCP-kutsuilla. Yhteyskäytäntö on siis valittu sellaiseksi, että teknisesti sen toteutus on hyvin samanlainen riippumatta, onko asiakas samassa tietokoneessa (paikallinen), vai toisella puolella maapalloa. Luonnollisesti silloin kun kytkeytyvä asiakasohjelma on fyysisesti eri paikassa, on tärkeää käyttää tietoturvallista kytkeytymistapaa. Internet on “luonnostaan” turvaton, joten tietoturva pitää luoda ohjelmistoissa aina siten että molemmat päät noudattavat samaa protokollaa tiedon käsittelyssä.

Mistään uuden uutukaisesta asiasta ei ole kyse. Krypton käyttö kirjautumisessa juontuu jo 1990-luvulle, jolloin mm. SSH-ohjelmisto keksittiin terminaaliyhteyksien suojaamiseen: Otaniemen Teekkarikylässä opiskelija-asuntolan omasta tietokoneesta oli kätevää mennä yliopiston koneille tekemään kotitehtäviä, mutta harmitti, jos joku toinen teekkari salakuunteli yhteydessä käytetyt salasanan. SSH-ohjelmisto esti tällaisen salakuuntelun. Jostain syystä nämä tunnetut reseptit ajoittain “unohtuvat” tai jostain käytännön syystä jäävät käyttämättä.

Summa summarum

Liian aikaista. Asiasta selvinnee vielä uusia yksityiskohtia. Itseni tämän luokan aukko yllätti, kahdella tapaa. Ensin kuvittelin että ransom-uutiset koskevat jo tutuksi käynyttä asiaa: Windows-koneiden kaappaamista ja kiristystä. Kyse ei ollutkaan siitä.

Toinen asia, joka yllätti, oli että tuotannossa on käytetty täysin suojaamattomia tietokantoja. Se on kuin ajelisi valtamerialuksella laput silmillä, autopilot poissa päältä, ilman tutkaa. Odottaa vaan törmäystä.

 

Uncategorized

Dummysta speksiin: ostoslista (softa)

Teen uusien ohjelmointiasioiden opiskelussa usein jonkinlaista “dummy”-projektia. Eli olen tekevinäni esimerkiksi muistilistaa, tai vaikka – sanotaan – hmm… jotain karttasovellusta. Tällainen lähestymistapa helpottaa hahmottamaan jollain tapaa sitä, mitä tekee. Eli puoliksi huijaa itseään: ei kirjoittele vain koodirivejä ilmaan ja käsittele täysin abstrakteja merkkijonoja tai numeroita, tietueita jne.

Mietin paljon softaprojektin eri osa-alueita. Speksaus on edelleen tärkeä osa, mutta se on myös jotenkin ongelmallinen ja rajoittavakin osa. Speksi tarkoittaa ohjelmiston määritellydokumenttia: niin käytetyn sanaston, tavoitteiden, tavoiteltavien hyötyjen, ohjelmiston sovellusalueen piirteiden, sen käyttötapausten, ja monen muun asian kirjaamista ja pohdiskelua.

Speksi muodostuu keskustelualustaksi, kun ohjelmistoa viedään tiimissä eteenpäin. Se on ohjelmiston eräänlainen aineeton koekappale, joka ei vielä toimi oikeasti. Speksi ei ole siis prototyyppi (prototyyppi on toimiva ohjelma, vaikka se olisi kuinka rajoitettu tai alkeellinen – silti, toimiva).

Ihan oikea tarve: kotiin!

Teen paraikaa oikeaan tarpeeseen softaa: haluan kotikäyttöön ostoslistan. Kyllästyin paperilappuihin, koska niitä varten pitää aina jostain vetää se lappu ja kynä. Kynä lisäksi pitää myös muistaa viedä kauppaan, jos paperilappua haluaa aktiivisesti käyttää: tarvii yliviivata ne asiat jotka on jo ostanut. Paperilappu myös usein unohtuu väärään paikkaan, siis yllättävän usein! Ja koska arvostan esteettisyyttä, paperilappu rypistyy; muste lähtee kosteudessa leviämään, ja lyijykynästä taas lyijyjälki tahraa ja pehmenee joskus sellaiseksi että lapusta ei saa selvää.

Hei, yllä on melkein ilmaiseksi vedetty se “unelma” -kohta speksiin; tätä minä haluan! Keskustelin asiakkaan, itseni kanssa, ja mietin, miksi haluan sen digitaalisen ostoslistan.

Jalostetaan silti toiseltakin puolelta: mitkä ovat digitaalisen ostoslistan huonot puolet?

Miettimällä ongelmia voidaan saada jonkinlainen parempi muoto ja toteustapa ostoslistalle. No, huomasin tällaiset asiat:

  • mitäs jos kännykkä jää kotiin? Eli huomaa menneensä kauppaan, ja sitten se tieto onkin “ei saatavilla”. Huulipurettaa.
  • onko tiedon syöttö oikeasti niin nopeaa ja helppoa kuin ajattelisi? Känny on usein lukittuna (“screen lock”) tjsp, joten alkuunpääsy voi olla hidasta.
  • eipä kynäkään ole tosiaan aina saatavilla, jollei järjestä kotona aina jonnekin tiettyyn paikkaan esimerkiksi keittiössä tällaista luxusta
  • entäs tietoturva yms?
  • onko ostoslista helppo myös unohtaa / hävittää. Tällaista tietoa ei luulisi tarvitsevan mihinkään tulevaisuudessa… Eli poisto helpoksi, ettei ala kertyä “digiroskaa” kännykkään.

Speksi on perinteisesti tarkoittanut aika paljon tietorakenteita ja ohjelmistossa olevan tiedon hierarkiaa ja linkittymistä toisiinsa. Siis englanniksi: Entity-Relationship model. ER-mallit ovat jo aika raskaita ja puisevia dokumentteja, mutta voivat sinänsä auttaa sekä ongelman hahmottamisessa, pilkkomisessa että koodin kehityksessä. ER -malleilla haetaan ehkä eniten standardimuotoista helpotusta ohjelman keskeisimpien rakenteiden (oikeastaan: algoritmien, datan määrän ja ennakoitujen pullonkaulojen) dokumentoinnissa. ER-malli on toisaalta hyvin staattinen, ja kuvaa vain rakennesuhteet: ei esimerkiksi miten asiat “proseduraalisesti” toimivat, eli miten mekanismit suhtautuvat toisiinsa ajonaikaisessa koodissa.

Tässä kohtaa on aika hyvä pysähtyä hetkeksi. Heitän seuraavat kysymykset mietittäväksi:

  • paljonko käyttäisit aikaa ostoslista-ohjelman tietorakenteiden mallintamiseen?
  • mitä ensimmäiseksi tulee mieleen ostoslistassa käytettävistä rakenteista? Ovatko ne yksinkertaisia, monimutkaisia, selkeitä, epäselviä?
  • ajattelisitko jotain tiettyä laajennusmahdollisuutta, jos ostoslistan saisi tehtyä viikossa jo toimivaksi ohjelmaksi?

 

Uncategorized

React 2/7: Tehdään komponentti

Tänään avataan pienellä esimerkillä ReactJS:ää eteenpäin. Tehdään komponentti, joka on Reactin peruspalikka. Kirjoitussarja seuraa lähes livenä omaa React -kehitykseni kulkua. Tämä on toinen osa. Ympäristö on asennettu osassa 1.

Se ‘opinionated’ eli ideologinen puoli

React sisältää, kuten Angular ja monet muut frameworkit, kohtuullisen paljon valmiita käytäntöjä. Siksi pelkästään päällipuolinen sorsakoodin katsastelu saattaa jättää monia kysymyksiä avoimeksi. Kannattaa aina välillä lukaista jokin kokonaisuus, vaikka React:n virallisilta dokumentaatiosivuilta. Alkuvaiheissa hyvä on esimerkiksi React Component (kaikki omat komponentit perivät tästä).

Kun opiskelen itse Reactia käytännössä “nollasta” eteenpäin, seuraavat asiat tökkivät alkuun:

  • herkkä (ja perus vanilla-Javascriptiin verrattuna uusi) syntaksi; jos syntaksi on väärin, pieni virhe aiheuttaa yleensä tyhjän sivun selaimessa, ei kovin paljoa vihjeitä mistä etsiä bugia… mutta:
  • Sublime Text 3 editori ja sopivat lisäosat auttoivat alkuun, koska monesti hapuillessa oikeaa syntaksia sai askel askeleelta vihjeitä miten päästä oikeaan lopputulokseen
  • ihan ensialkuun tekstieditorin asetusten löytäminen sopivaksi, jotta ESLint -syntaksitarkistaja antaa React-ohjelman kääntyä puhtaasti

ESLint on osa esimerkkimme build-sykliä. Koska JSX menee Babel-kääntäjälle, on ilmeisesti normaalia tärkeämpää että syntaksi on juuri kohdallaan, eikä melkein sinne päin. JavaScript:hän jättää jonkun verran vapauksia valita syntaksiin liittyviä asioita, mutta JSX ja React ovat sen sijaan varsin tiukkoja. Huomasin alussa nyplääväni editorissa hyvin lyhyttä ohjelmaa ainakin vartin; hain melkeinpä kokeilemalla oikeaa muotoa.

Alkuun asia voi hidastaa kokeilua ja koodaamista, mutta kun tyyliin on päässyt sisälle, homma ei enää nouse ongelmaksi.

Jos editorissa tuntuu olevan syntaksiväritys (syntax highlighting) päin mäntyä, kokeile antaa Babel/JavaScript olla tulkkina sen sijaan että yrität lähdekoodille normaalia JavaScript-asetusta. Erona on siis se, että Babel:in avulla voidaan laajentaa erilaisia kielimurteita, jotka antavat värittimelle oikean rakenteen ja siten värit kohdalleen. Suoraan “Javascriptinä” tulkittuna tuo JSX olisikin virheellistä.

React: komponentit

Koodaaminen perustuu pariin keskeiseen asiaan: komponenttien määrittelyyn ja parametrien välittämiseen komponenteille. Kaikki komponentit perivät perusluokasta React.Component

Paljonko React nojaa ES6 -muotoon JavaScriptistä?

ES6 :sta ei ole pakko tietää kaikkea, riittää alkuun kun katsot miten ‘class’ toimii: se on luokkamäärittely, joka lopulta kääntyy “yksinkertaisemmaksi” JavaScriptiksi. Babel on tuo kääntäjä, joka hoitelee magian ES6 -tyyppisen lähdekoodin ja lopullisen käännöstuotteen välillä.

Class -määrittely (ES6)

Kannattaa katsoa Class -määrittely (ES6)

Perusidea on siis yksinkertaisempi ja lyhyempi syntaksi. Lopulta käännetty JavaScript on aivan samaa koodia, mutta nyt lähdekoodi pysyy puhtaamman näköisenä.

  • yksinkertaista määritellä luokka
  • luokan sisällä olevat funktiot kirjoitetaan “helpommin”, ei tarvitse määritellä turhaa formalismia:
    funkkari (parametrit) { tänne koodi }
  • Perusmuoto ‘class’ avulla tehdystä luokasta:
    Class OmaKomponentti extends React.Component
  • luokka sulkee sisälleen yksityiskohdat, jolloin globaali nimiavaruus pysyy mahdollisimman siistinä.

Tilatonta rakkautta, toistaiseksi

Myöhemmin sarjassa palataan koko sovelluksen tilan hallintaan; Reactissa komponentit eivät voi suoraan muokata tilaa (muuttujia, objekteja), koska on haluttu pitää tiedon liikkuminen yksisuuntaisena. Eli komponentille päin voidaan välittää tietoa kutsujalta, mutta ei takaisin. Ns. two-way binding, joka on mm. AngularJS:ssä keskeinen ominaisuus, on myös sellainen, joka usein saattaa karata käsistä: sekä suorituskyky koodissa laskee, että bugien jahtaaminen monimutkaistuu. React haluaa, että komponentit tekevät selkeästi rajatun asian eli pitävät huolen ruudulla näkyvien (UI) asioiden muuttamisesta; that’s it – ei muuta.

Kädet saveen: komponentti

Lähdetään penkomaan, miten asennettu esimerkki oikein toimii. Jos et ole vielä asentanut runkoa koneellesi, käy vilkaisemassa aiempi osa blogauksesta: React alkuun, kaverina Yeoman

index.js käynnistää sovelluksen elinkaaren. Siellä on oikeastaan vain kutsu näyttää yksi itse määritelty komponentti:

Keskeisin osa lähdekoodista löytyy 2 tiedostosta:

src/index.js

src/components/Main.js

Alempi, “Main.js” määrittelee komponentin – eli päätason komponentin. App kutsuu muita komponentteja, eli se sisältää perus layoutin, komponenttitasolla.

Rivi riviltä tärkeimmät osat komponentista (Main.js)

Komponentin perusasiat ovat:

  1. ympäristön asetus sopivaksi
  2. luokan määrittely
  3. render() funktio on komponentin tärkein pihvi
  4. export – eli kerrotaan mikä osa komponentista avataan kutsujalle (koodin käyttäjälle)

Komponetti piilottaa siis kutsujaltaan turhat yksityiskohdat. Tässä on eräs Reactin kulmakivi: monessa muussa frameworkissa ohjelmoija voi pian olla scope-sotkun kanssa tekemisissä. Reactissa on tavallaan nihilistinen, yksinkertainen malli, jossa yritetään noudattaa klassisen olio-ohjelmoinnin kapsulointia – ideaa siitä, että jokainen olio (komponentti) pitäköön yksityiskohtansa omana tietonaan. Kutsuja on vain kiinnostunut rajapinnasta komponenttiin: mitä se ottaa vastaan, ja mitä se lupaa tehdä.

Tärkeät muistisäännöt

Katsotaan mitä koodista löytyy

  • komponentitkin joutuvat itsenäisesti käyttämään require() :eja
  • komponentin koodissa alussa myös tärkeä import
  • render() on se funktio, mitä komponentilta odotetaan aina löytyvän
  • pidä render() mahdollisimman lyhyenä ja siistinä, monimutkaisempaa käsittelykoodia voi laittaa komponentti-luokkaan render() :n rinnalle
  • render() :ssä muista palauttaa aina ensin yksi div -elementti
    jonka sisälle on kääritty muu haluamasi sisältö

Toisin sanoen Reactissa komponentti on niin itsenäinen palikka, että se ei automaattisesti saa ympäristöstä muiden osien käyttämiä require ja import -määrityksiä. Jokainen komponentti huolehtii itse sopivien määritysten tekemisestä. Jos tarvitset komponentissa jotain resurssia, muista kirjoittaa tarvittavat sisällytykset.

Uncategorized

Open source, closed doors? Peace of code.

Throughout my involvement with code, I’ve been curious as to both the volume and quality of code. As well as, how it feels in particular moments to be programming.

Not so long time ago the suitability of open-plan offices to R&D (generally, “anything needing precise concentration for rather long periods of time”) was revisited and, according to many articles or persons, programmers hate open-plan offices. This in turn translates to diminished productivity.

Part of the negative side of a open-plan office is due to interrupting the flow, or optimal mental state of a developer. Good managers know how to shield developers from completely unnecessary and fruitless disruptions. Apart from one-man shops (where you, the CEO, are also developers, sales-guy, coffee grinder and the janitor), developers rarely should directly handle individual service cases (ie. being helpdesk), nor should they have much direct daily output to sales activity. Developers often participate as technical aides in product design; write both payload code and tests (the ‘core’ of their trade), handle open bugs, and learn new things. Developers should not (in my opinion) be involved much in the back-office activities of a project, such as maintaining capacity and reliable availability of servers, configuring complex build systems; and they definitely should not be involved in mindless ramifications from organizational architecture change such as moving a lot of stuff from a folder to another, or having fencing with any office productivity / email / calendar suites. Well, the latter goes to every role (not just devs) in the company, and I know that it’s part idealistic to state that change shouldn’t incur painful and numbing experiences.

My stance on the open-floor plan issue is quite similar as the news. If I’m mostly in developer role, I prefer somewhat closed rooms. It doesn’t mean that each developer would sit in their own closet, but rather that a team is shielded from extraneous noise and distractions. A very good idea is to have easily available, temp quiet spaces for individual work. Booking them shouldn’t be necessary.

Joel Spolsky said very well:

The more things you (ie. developer) can keep in your brain at once, the faster you can code, by orders of magnitude.

There might be purely neurological reason behind this. Our sound perception works as a background thread, automatically. We kind of – computationally speaking – keep making sense of the word-stream that enters our ears. Thus the more there is sound signal in the enclosing space, the more we probably have to deviate from perfect concentration on the most important task.

The idea behind open-floor plans probably were to alleviate siloing (individual developers going solo, making things that become incomprehensible to others, and pose a business risk). By putting people together, the architects maybe thought of leveling and making the team advance in more even and predictable steps. Reality perhaps got in the way.