CSS Sivuraide, pysäkki Nappula

Reading Time: < 1 minute

Sivuraiteella: samalla kun aloin todellakin pääsemään vauhtiin CSS:n kanssa, huomasin kutkuttavan pienen haasteen.

Photo by Chris Ried on Unsplash

Usein projektien kanssa käy niin, että nälkä kasvaa syödessä, ei pelkästään “sinne minne piti mennä”, vaan välissä tarvitsee hieman pompata sivullekin, oppiakseen jotain millä on käytännön hyötyarvoa projektissa.

Samaan aikaan kun blogaan CSS:n oppimisesta, pidän pientä interaktiivista muistiota Codepen -sivulla

Sivu demoaa CSS:n avulla tehtäviä juttuja. Suuri osa sivusta on tekstiä, mutta sitten tuli tarve oikeasti NÄYTTÄÄ miten juttu toimii. Opimme matkimalla, apinoimalla. Ohjelmistojen kaunis puoli on se, että niille on ominaista helppous toistaa ja näyttää asioita.

Eli halusin antaa lukijalle napin, jolla voi helposti nähdä miten CSS vaikuttaa. Kun painat nappia ensimmäisen kerran, se laittaa tyylin PÄÄLLE. Toinen napsautus poistaa tyylin. Nappi toimii kuin valokatkaisin.

Web-selaimen moottori ja CSS

Web-selain parsii HTML-lähdekoodin DOM-puuksi. DOM-puussa on solmuja (‘nodes’). CSS:n määrittelyt tallennetaan omaan rakenteeseensa selaimen muistissa. CSS tulkitaan ja sen määräämät muutokset laitetaan koskemaan noita aiemmin mainittuja DOM-puun solmuja – ja tässä kohtaa nimenomaan tulevat peliin mukaan CSS:n säännöstöt; ne ratkaisevat, miten ja kuinka monen eri tyylin yhteisvaikutus lopulta muuttaa solmun eli web-sivun ulkonäköä.

Hei, aika heavy lätinä. Mennään seuraavassa jaksossa pariin kikkaan mitkä huomasin! Tiedossa on silloin:

  • pätkä JavaScriptaa, napin click handleriin eli tapahtumakäsittelijään
  • muutamia kysymyksiä, miten kannattaa suunnitella piirre, jos mitenkään (vai onko se niin yksinkertainen että “just do it” pätee!)


Software cost estimation: Pokemon Firefall

Reading Time: 2 minutes

I’ll introduce and test in one example how timeboxing works: whether my software complexity estimation holds. The app is relatively simple one. A web based interface that helps you keep track of points in playing Pokemon (the card game).

The non-usual suspects

Pokemon. The ultimate card game you’ll encounter at some point in family life. No, not the app. TGC – the card game. You’ve got these fancy cards shuffled and dealt, with which you start battling the opponent. Epic fun!

Waterfall – auch! The skeleton we all would like to bury. Waterfall is the name of a software project tracking methodology of the autistic idealist; which doesn’t work. In waterfall your team spends 1-6 months thinking and sketching, trying to sort out every possible minute detail of the software, and you’ve lost a major portion of time and/or manpower by the time you actually start implementing the plan. Waterfall is bad. Rael bad.

Time boxing. The “what” for some newbies to corporate software business. But for many professionals, time boxing means day in, day out activity: a software project’s parts (“Tasks” or building blocks), are being estimated, measured — and devs pressed against to reach their goals.

But really?! How to battle? I’m sitting at our living room table, with my 5-yo and thinking feverishly what should I do with the cards. Sure, Hitpoints (HP) seems familiar. I’ve had my share of role playing games along the decades. But what are all the rest of the figures and symbols on the Pokemon playing cards trying to tell me? No idea. Let’s find out.

Pokemon Firefall – tasks to make the app

  • scaffolding (initialize) the app on Codepen
  • 1 view: main view (=intro screen)
  • 1 view: Battle view (BV)
  • feature: Battle View setup (numbers) before going into live battle
  • code: Subtraction (live battle)
  • Next round (routing in BV)
  • Results

Here’s the plan. The app supports one-on-one battle: 2 cards are fighting each other. Each player has:

  • hitpoints
  • name of the card
  • primary attack method
  • secondary attack method
  • weakness
  • resistance

I’m testing coding on a cloud platform. For any experiment to be fruitful, it’s mandatory to have something to really work on.

CodePen is one of the obvious first platforms to try. My setup thus: a laptop and the CodePen. Let’s go!


Jukkasoft blog at around {10/11}

Reading Time: < 1 minute

Jukkasoft turns ten.. I guess! Maybe 11?!

Last year, 2018, I installed Yoast SEO plugin. It made writing much more pleasant, since I could get immediate guidance on both technical and human aspects of the text appeal.

I want to experiment more with the basics:

  • navigation
  • ease of use
  • fixing automated silly linking within the blog

Super! Keep up the love 🙂 The year 2019 looks very interesting. I will definitely keep you updated!



Traveling without moving (your digits)

Reading Time: 3 minutes

Radesign – radical redesign.

This blog post began as a product of two separate coincidences. One that happened earlier was that I while I was commuting from Hyvinkää to Helsinki, in a train, I overheard a discussion; two women were talking about life casually; and at some point the other said: “You know, this is so ridiculous… but my own parents do not take the train anymore. It’s a pity. They simply find buying the ticket too hard nowadays.” And the other replied with sympathy, saying that she totally understands it is not very easy. They were referring to the online sales of the rail tickets.

  • Why are seemingly simple things, as buying a train ticket online, so hard to do?
  • What’s with the (too) long tradition of hassle, anytime a public transport ticket system is being renewed?
  • Why often it seems that despite of high tech solutions, there are arbitrary kludgy barriers – and the price is paid by the customer?
  • Could we do better, given that we’d scrap the physical tickets altogether, and “shift” the technology out of the use case?
  • If we can shift out the visible tech from travel, how exactly would it be done? What were the pros and cons?

The second impetus for writing was that I was rather surprised by a news title, which was along the lines “Helsinki’s HSL zone renewal completed – cost 100 million euros”.

I’m a software developer by trade, and hereby acknowledge my bias towards mobile + software-based solutions being superior to having physical tokens and ticket vending machines. However, that being said, at the moment I do not have a economic stimulus to any direction, except that as a taxpayer and consumer I would like to optimize costs of infrastructure projects in general.


What I did immediately think was couple of things:

  • how much of the 100,000,000 euros is about hardware, ie. ticket gates and reader devices installed on buses, trams, subway cars and local trains?
  • is the mass transit a cost-ingesting or money producing effort for the N counties that take part in it?
  • what were the alternative scenarios, if any, in realizing (implementing) this transit ticketing system?

Honestly, it’s not even radical redesign. I just have at this point a feeling that perhaps a mighty portion of the 100 million eur could have been cut, if the design was a bit different.

The costs of the bad dual systems thinking

The main point is that digital world is often riding in a weird dual-standard world; whereas we acknowledge and seem to be seeking the benefits of virtualizing things, what in fact happens is that we end up doing the same thing (which happened before digitization) but with double the effort.

This kind of extra cost associated with combined migration + “double entry” has also been seen in

  • shift of banking to ultimately purely digital form
  • authentication solutions (identifying a legitimate user to a system); burdened by the apparent need to provide several alternative ways of identification (codes, devices, biometry, passwords, etc)
  • the world of digital documents, where still a major portion of documents are kept in paper form (for example: to make it official, or eligible for archival, a document has to be present in print form)
  • access control (keys; other tokens) whereby there’s both digital and physical keys

I don’t have yet anything to offer, and that’s one of the reasons I wanted to write. Writing is a tool of inquiry for me; it is an essential part of formulating technology and thinking about it.

In nutshell: Helsinki

  • Helsinki
  • Espoo
  • Vantaa
  • Kauniainen
  • Sipoo
  • Kirkkonummi

have a combined mass transit network, where one can travel flexibly – using local trains, trams, bus, ferry and subway – between or within any of the stated municipalities. The zones start from Helsinki (A-zone), and go towards the edges radially as B, C, and D zone.

Tickets – inspected: approaches and tradeoffs

A ticket is one solution to underlying problems, which need to be dealth with somehow. There has been historically 3 main approaches to fares:

  • customer buys a ticket once they are aboard the vehicle
  • ticket is bought in advance
  • the trip is paid once it is completed

Is ticket inspection by personnel required?

Can technology solve the problem of need for ticket inspection, and thus making the system fair so that no one has a possibility to do free riding at the expense of other law-abiding passengers?

Current (2019)

Historically the transit ticket mechanism evolved, throughout decades, but one thing that I still kind of see odd at this time and age is that physical cards and card readers are still present. The cards and their immediate infrastructural requirements, you see, not only count for probably quite a lion’s share of the costs, but also bother people. Cards have to be physically renewed every once and then. Yes. I know. Sounds weird. You are not the only one that has thought about the aspect.

Totally card-less system?

  • feasibility
  • architecture
  • operations and functions required
  • privacy
  • wireless networking technology needed
  • cases: GPS-only

Why HSL travel cards need to be physically replaced periodically?


Suomi-IT, onko se tärkeää?

Reading Time: 3 minutes

Tarvitsemmeko kansallista – suomalaista versiota – tietoyhteiskunnasta, vai voimmeko rakentaa tarvittavan alustan käyttäen kaupallisia, monikansallisia digitaalisia palveluita joiden olinpaikka, taustateknologia, tarkoitusperä ja historia ei välttämättä ole suoranaisesti käsissämme?

Olen pragmatisti, ja uskon erittäin voimakkaasti teknologian kykyyn ratkaista tiettyjä arkipäivän ongelmia. Näin ja koin omin silmin kotitietokonevallankumouksen Suomessa, eli tavallaan “tietoyhteiskunnan synnyn” hetket. Mutta teknologia ei todennäköisesti kykene ratkaisemaan sitä, että me olemme inhimillisiä – ja politiikka jos mikä on keskeisintä inhimillisyyttä.

Politiikka vaikuttaa tietotekniikan ulottuvuuteen ja saatavuuteen: hinnoittelut, teknologialisensointi, vientikiellot ja muut vastaavat voivat nopeuttaa tai hidastaa teknologian läpilyöntiä. Teknologia on luonteeltaan aika poikkitieteistä, ihan esimerkkinä tietokoneen ja ohjelmistojen valmistamiseen tarvitaan mm.

  • sähköoppia
  • elektronisten laitteiden valmistusmekaniikkaa
  • fysiikkaa
  • matematiikkaa
  • kemiaa

Korkea teknologia on monipuolinen renki. Joskus high-tech luetaan jopa “ammukseksi”, digitaalisen sodankäynnin välineeksi. Arthur C. Clarke totesi, että mikä tahansa riittävän korkealle kehittynyt teknologia vaikuttaa magialta toisen sivilisaation silmissä.

Miten tärkeää siis oikeastaan olisi saada digimaailman peruspalvelut pysyvästi ja suomalaisella alustalla, kauniilla ja puhtaalla kotimaisella kirjoitettuna?

Miten järkevää tuollainen fenno-IT olisi?

Tehdään pieni katsaus muutamaan ydinkäsitteeseen.

Mikä on “digitaalinen minä”?

Digitaalinen minämme on itse asiassa aika kimurantti juttu: meidän identiteettimme määritellään erilaisten (usein englanninkielisten ja ulkomaisessa omistuksessa olevien) palvelujen kautta.

Suomessa kansalaisen digitaalinen identiteetti on rakentunut aika hitaasti. Valtio ei ole ottanut kovin selkeää / muutospainetta luovaa otetta, ainakaan aikaisessa (2000-luvun alun ensimmäinen vuosikymmen) vaiheessa.

Teknologisen adaptaation (uuden tekniikan hyödyntämisen) kuvaajana on usein käytetty ns. S-käyrää. Alkuvaiheessa uuden tekniikan ympärillä tapahtuu ainakin näennäisen paljon kehitystyötä, mutta tämän vaiheen ongelma (loppukäyttäjän, organisaation) kannalta on se, että mikäli ei ole valmis riskeeraamaan, joutuu odottamaan “voittajahevosen” nousemista. Organisaatiot (varsinkaan julkiset) harvoin haluavat ottaa tietoisesti riskiä, heittäytymällä tuntemattomille vesille. Kyseessä on siis muna-kana -ongelma.

Onko digitaalista, tarkkaa “ydinidentiteettiä” olemassa?

Jokaisella Suomen kansalaisella on syntymässä annettu henkilötunnus (HETU). Se on yksilöllinen tunniste. Tietojärjestelmissä henkilötunnus on helppo esittää merkkijonona, eli se muodostuu kirjaimista, numeroista ja muutamista sallituista välimerkeistä kuten ‘-‘.

Henkilötunnusta voidaan käyttää pääavaimena (primary key) sellaisissa tietokokoelmissa, joissa luonnollinen henkilö pitää kyetä yksilöimään yksiselitteisesti.

Identiteetti näyttäytyy epäsymmetrisenä

Jotta tarkastelumme olisi kattava, on myös erotettava tiedon eri käyttäjäosapuolet: digitaali-identiteettimme ei ole täysin symmetrinen tällä hetkellä (2019). Kun ajattelen itseäni esimerkkinä:

minä, Jukka, olen muutamassa eri paikassa olemassa; Gmail-sähköpostiosoitteeni on eräs pysyvimpiä identiteettini osasia. Sähköpostiosoite kun nyt pysyy sellaisenaan ainakin niin kauan kuin Google (yritys) on toiminnassa. Toinen paikka, missä olen olemassa, on tämä Jukkasoft-blogini.

Toisaalta sekä sähköpostiosoitteeni että blogini ovat vain epäsuoria ja heikkoja identiteettini ilmentymiä. Periaatteessa sähköpostiviesti, joka näennäisesti (väitetysti) tulisikin juuri minun Gmail-osoitteestani, ei ole tarkkaan vahva henkilötunniste: sähköpostiviestejä voidaan väärentää, jopa suhteellisen helposti. Eri asia käytännössä on se, miten sähköpostin vastaanottaja (de facto) suhtautuu viestiin.

Minusta on “toisella puolen”, eli kunnilla / valtiolla oma versionsa. Kaikkeen siihen dataan en välttämättä vielä pääse käsiksi kansalaisena. GDPR-uudistus joka on astunut voimaan vuonna 2018, tosin on saattanut muuttaa jonkin verran tätä epäsymmetriaa (YLE: uutinen GDPR:n vaikutuksista Suomessa kansalaiselle).

Internet, reititys, data ja serverit

Nykyisellään “kierrätämme” digitaalisen identiteettimme kun olemme päivittäin tekemisissä tietoverkkojen kautta sekä yksilöiden että yritysten ja viranomaisten kanssa. Tuo datan kierrätys (tiedon reititys) herättää hieman kysymyksiä. Ensinnäkin tuntuu siltä, että meillä suomalaisilla ei varsinaisesti ole oikein pysyvää digitaalista identiteettiä. Asia ei välttämättä sinänsä ole “hyvä” tai “paha”, vaan se on vain eräänlainen näkökulma ja asiainlaita.

Olen itse huolissani ehkäpä kahdesta asiasta, jotka ovat hyvin liki toisiansa:

  • miten angloamerikkalainen IT vaikuttaa palveluiden käytettävyyteen ja ymmärrettävyyteen?
  • toteutuuko tietoyhteiskunta Suomessa, demokraattisella ja ihmiset tasapuolisesti tavoittavalla tavalla?

Entäs sitten? Onko sinivalkoisen digitaalisuuden puutteella merkitystä?

Onko sillä väliä, että itse asiassa iso osa demokratiastamme lepää paljolti maailman suosituimmat sosiaalisen median saitin Facebookin ja amerikkalaisen sähköpostitilin päällä? Yhteiskuntamme on voimakkaasti digitoitu jo, mutta siitä syystä, että sosiaalisen median yritykset hyötyvät tästä.

Kierrätämme arkipäivän kuulumiset ja vähän isommatkin asiat tuolta Atlantin kautta. Muutamat suuret firmat tietävät meistä rutosti enemmän kuin yksikään viranomainen Suomessa. Ja tässä tulenkin liberalistiseen argumenttiin: näinhän on hyvä!

Onko sillä siis väliä, että esimerkiksi hyvin harva blogipalvelu pystyy tukemaan suomen kieltä, kun editorissa on oikolukutarkistus? Olemme aina viimeisimpien listalla, jos tulee priorisointitarpeita kun erilaisia kieliä aletaan tukea tekniikka-alustoilla. Tokihan me sen kestämme. Ei identiteettiimme tai ainakaan psyykemme voi olla niin voimakkaasti kieleen sidoksissa, että kärsisimme rajusti tästä ilmeisestä kotimaisen tuen puutteesta.

Kurkistetaanpa realiteetteihin:

  • Onko tilanne todellisuudessa niin, että väitteille on perusteet?
  • Onko suomalainen IT-infra ja suomalaiset järjestelmät täysin olemattomia maailman mittakaavassa – tai, sanotaanko, meidän suomalaisten mittakaavassa.
  • Mitä Suomessa vielä valmistetaan?
  • Olisiko kotimaisuuden astetta syytä lisätä jostain syystä?

Koska olen itse vain pieni ratas tässä mekanismissa, ammatiltani ohjelmoija, halusin kysyä kokeneemmilta ja nimenomaan näistä asioista paremmin tietäviltä.

Palaan syksyllä 2. osan kanssa, toisen osan kanssa, jossa selvitän toivon mukaan ainakin osaan ylläolevista kysymyksistä vastauksia.

Sarjassa tutkitaan, miten tietoyhteiskunta rakentuu; millaisia poliittisia ja teknisiä ulottuvuuksia todellisuudessa kulissien takana on.


CSS oppikoulu osa 3

Reading Time: 2 minutes

CSS on merkkauskieli – ei siis varsinainen ohjelmointikieli. CSS:llä pyydetään web-selainta muuttamaan haluttujen HTML-elementtien muotoiluun (ulkonäköön ja sijoitteluun) vaikuttavia tekijöitä.

CSS:n onnistumiseen tarvitaan kolme asiaa:

  • miten osutaan oikeaan elementtiin (=> selektorit)
  • mitä puolia elementeistä voi muuttaa (=> katsotaan ohjeet ja standardit)
  • pitää olla kokonaisvaltainen visio siitä, mitä haluaa aikaiseksi – sen jälkeen keinot yleensä löytyvät kun näkee vaivaa ja testailee
p {
    background-color: dodgerBlue;

CSS:ssä olennaista on selektori. Yllä esimerkissä on käytetty p -selektoria; se kohdistaa kaarisulkeiden { } sisällä olevan litanian vaikuttamaan yhtä tekstikappaletta (P, engl. paragraph).

Osumatarkkuuden pohdiskeluja – ei liity

Web-selaimella on aina jotkin vakiovarvot kaikille sen tukemille HTML-elementeille: Sinun tekemäsi CSS sitten muuttaa näitä – mikäli CSS on tehty oikein! Alkuun isoin ongelma on usein se, että oma CSS ei tunnu “osuvan” niihin elementteihin, joihin haluaa vaikuttaa. Eli vaikka tekee mielestään jonkin muutoksen, selain näyttää täysin muuttumattoman sivun uudelleenlatauksen jälkeen.

Miten osua haluttuihin kohteisiin? Selektorit!

Selektoreja on muutamia erilaisia:

  • id
  • luokka
  • pseudo

Tarkin on ‘id’-selektori. Tällä on tarkoitus muuttaa yhden ainoan nimeltä tunnetun (minkä tahansa) elementin ulkoasua.

Esimerkki id -selektorin käytöstä

Ajatellaan että meillä on tärkeä valintanappi sovelluksessa.

Valinnan pitää olla pysyvä, kunnes käyttäjä käy toisen kerran painamassa samaa nappia. Eli tyyli pysyy. Toisaalta, valintanapeille on tärkeää, että vain se nappi, jota painetaan, muuttaa tilaa. Kuulostaa sopivalta paikalta käyttää ‘id’:tä.


Selaimen pisteyttää CSS-rivit

On oikeastaan lohduttavaa huomata, että selaimen ja CSS:n suhde on lopulta hyvin matemaattinen. Jokainen rivi CSS:ää saa pistemäärän (kutsutaan nimellä specificity). Selektorien yksityiskohtien määrästä ja tyypeistä ropisee eri määrä pisteitä. Tarkempi määritelmä yliajaa eli jää voimaan.

Lisäksi on olemassa ‘!important’ arvo, jota voidaan käyttää hätätilassa pakottamaan voimassaolo aina rivikohtaisesti.

Mikä on ‘cascading’ ja kuinka se vaikuttaa?

Sana ‘cascade’ tuossa CSS:ssä (Cascading style sheets) tarkoittaa, että tyylimäärittelyt tulevat voimaan sitä mukaa kun niitä kohdataan CSS-tiedostossa. Viimeisin jää voimaan, eli myöhemmin tulevat (jo aiemmin määritellyt) ovat voimakkaampia.

Jos selektori ei osu olemassaolevaan elementtiin, se luo uuden tyylin eli määritelmän. Tätä tyyliä HTML voi käyttää aivan samaan tapaan kuin vakiona selaimessa olevia tyylejä.

  • elementin nimi
  • uuden luokan luominen

Kaikki CSS-rivit ovat samanlaisia muodoltaan:

selektori { määrittely1; määrittely2;}

Selektorilla kohdistetaan vaikutus haluttuihin HTML-elementteihin. Yksinkertaisimillaan selektori on suoraan elementin nimi: esimerkiksi ‘P’ joka muuttaisi kaikkien perus tekstikappaleiden tyylin.

CSS selektorien esimerkkejä

Periaate CSS:n web-sivuun tekemästä vaikutuksesta voitaisiin tiivistää: jollei muuta ole määritelty, käytetään selaimen vakiomuotoilua. Muutoin käytetään CSS:n määritelmää (eli se yliajaa vakiomuotoilut).