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.