Page 2 of 49

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.

/Jukka

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?

Facebook Comments

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.

Facebook Comments

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ä.

HTML

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).

Facebook Comments

perl ja irc-botti?

Reading Time: 2 minutes

Irc on edelleen päivittäinen “työkalu” ja vapaa-ajan huvitteeni. Hengailen muutamilla kanavilla; yksi on porukkamme virtuaalinen olohuone jo jostain 1990-luvun puolestavälistä saakka. Pari muuta kanavaa on myös erittäin kiinnostavia; jossa enemmän pelkästään WordPress / muuta tekniikkaläppää.  Oli vain ajan kysymys, milloin into tehdä botti kanavalle iskisi (irccasin vain 22 vuotta ennen tätä..)

On siis aika!

Ai tää on nyt niistä boteista?

Ei. Tää ei oo niistä droideista. Siirry eteenpäin [viittilöintiä 70-luvun kaapupropseissa].Nyt ei rakenneta bottia webbisivulle, vaikka ne ois kuinka in.Boteista on puhuttu tosi paljon viime aikoina myynnin automaation työkaluina. Irc-botti on periaatteiltaan aivan samanlainen: se on vain yksinkertaisempi ja arvattavampi, kuin myynnissä usein käytetyt tekoälyt, joilla pyritään tekemään ihmisenkaltainen keskustelukumppanit web-sivuille chattiin. Botin perusperiaate on:

  • liittyä kanavallekuunnella joko yksityisviesteinä tai kanavalle annettuja tekstikomentojatehdä komennon perusteella esimerkiksi webbiin kohdistuva hakubotti joko “keskustelee” takaisin kanavalle tekstinä, tai tekee IRC-protokollan määrittelemiä komentoja joista on hyötyä botin käyttäjälleusein botin käyttäjä jollain tapaa tunnistetaan, eli tuntemattoman irccaajat eivät voi käyttää bottia väärin omiin tarkoituksiinsa 

Irc-maailma koostuu palvelimista, jotka keskenään vaihtavat tilaa ymmärtämänsä “keskusteluavaruuden” tapahtumista: 

  • minkä nimisiä kanavia on olemassa

  • mitkä ovat kanavien ominaisuudet eli liput

  • kuka henkilö on milläkin kanavalla

  • mitä henkilöt (nick) sanoo

  • millaisia toimenpiteitä henkilö haluaa tehdä komennoilla

Avoin lähdekoodi ja bottien valmisreseptit

Irc-botti on hyödyllinen kapistus. Niitä saa valmiinakin lähdekoodina. Eikä ole yhtään huonompi idea käyttää hyväksi valmista koodia, jos mahdollista. Moni asia toistuu boteista toiseen lähes samanlaisena: harvemmin botin luojaa kiinnostaa esimerkiksi ns. ruohonjuuritason IRC-protokollaan tai muihinkaan protokolliin liittyvät asiat.Teknisesti botin ohjelmointikieltä ei rajoita mikään. Riittää että IRC-protokollan logiikka on suoraan toteutettu, tai se on otettu mukaan ohjelmaan pakettina / kirjastona. IRC:ssä kommunikoidaan tekstipohjaisella suhteellisen yksinkertaisella protokollalla. Teksti on 8-bittistä, eli Unicodea “vanhempi” perusmerkistö.  Sen sijaan botin ominaisuuksien eli hyödyllisten asioiden ohjelmoiminen on paljon jännempää! Se, että voi muuttaa ja mukauttaa bottia juuri itselleen ja porukalleen sopivaksi. Samoin testaus on olennaista: käyttäytyykö tuo ohjelma, niinkuin ajattelit suunnitteluvaiheessa? Joskus yksityiskohtien kanssa tulee paljonkin temppuilua. 

Pärjääkö botti tosimaailmassa?

Mikä IRC-verkossa voi koitua sitten botille ongelmalliseksi?

  • jos botti potkitaan kanavalta (kick)
  • joskus servereitä siivotaan, eli niiden prosessit tapetaan, jotta serverin (mahdollisesti ehtyvä) keskusmuisti ei loppuisi kesken. Kun botin prosessi tapetaan, botti luonnollisesti lakkaa olemasta. 

Mitä voit tehdä yllä oleville asioille?

Potkimiseen 

Serverin suhteen en ole varma. Kuvittelisin, että oman VPS:n liisaaminen eli virtuaaliserverin vuokraaminen on keino välttää mielivaltaiset prosessin tappamiset. Hinta on hieman korkeampi kuin satunnaisesti jonkin palvelun kylkiäisenä tulleelle serverikapasiteetille, muttei mitenkään huimasti. 

Muutamia pointtereita tarpeellisiin lähteisiin

Facebook Comments

My Tips for a Professional Developer

Reading Time: 5 minutes

Purely coming from my experiences so far.

I’m a geek. I’m a programmer. I hack away, I’ve always done code. From some point onward, I also started doing code for money into real industrial and business applications.

It was a fantastic moment to really grasp that what had been merely a pastime, could be turned into my trade. I enjoyed software development ever since.

The elements of change can be categorized easily:

  • things that stay the same
  • new stuff
  • skimming, bubbling, trending and waning stuff

Things that stay the same

Computers essentially still are programmed by making them follow instructions, to manipulate bit-based objects. Things that are made from a series of 0 and 1 bits.

Did you know that most of the surface area, cost and complexity of CPUs is due to massive parallelism? The number of gates, total cumulative “vias” (electron conductors) and related power consumption is due to the fact that it isn’t the basics of computation that have changed, but the sheer “volume” or pipeline that the processor crunches nowadays! Essentially a CPU nowadays does serial computation, but in massive scale – and with some snazzy tricks to avoid calculation of futility. Caching is the technology that fetches a result that is already known at the time the computing instruction hits the execution pipeline.

U canst

What I’m trying to say is that even though you might think OMG! I could never understand CPUs of modern computers, I’d say that’s not true. Zooming in, down to the elementary parts you would still find very familiar concepts: registers, simple microcode (pieces of a actual machine code instruction). The computer’s guts, so to speak, are of the type: IF something THEN do something, ELSE do something else. IF-THEN-ELSE. Add to that a capability to jump (branch execution to other place), add two numbers together, and so on – it’s what makes your machine tick. The rest is performance glitter.

What the software industry is aiming is a few things besides technology development per se:

  • managing complexity of a software project, sometimes reaching 100,000s or even millions of lines
  • handling the blame game and risks properly
  • verifying and testing the quality of software
  • keeping software development costs at bay
  • if possible, keeping the margins (profit) by applying blue ocean strategies
  • avoiding cardinal mistakes of doing an app of tech that no one will ever use (or pay for)

Meta: The process side of software engineering

With more experience under the belt, I got great experiences from methodologies to cope with project complexity, team work, splitting development to many members, solving problems together, and continually improve the way the whole team works.

This is a recollection of things that I’ve encountered. Ideas, methodologies, good and bad ones. Things that worked for me, some that din’t.

I’m not particularly an advocate of any specific one toolbox, whether it is a project methodology or a piece of the tech stack.

Enjoy the silence

You might have periods of silence in the project, and especially during daily schedule. Enjoy. These are often the moments where intense development and raw writing work happens. Coding is something that takes different turns depending on the microtask at hand; sometimes you are basically writing quite simple snippet of code, where you don’t have to hold many constraints or guidelines in your head at the same time. At other times, you’re doing a leap forward in some critical portion, where a lot of “things hang in the air”, and making it all spit out as code is a lot more nerve-wracking. People counter often the physical noise with means such as noise-cancelling headphones. These are really ways to do stuff. And a reminder to all fellow coders: even though we might perceive someone is merely listening to good music and having fun, remember that inside what happens might be a intense concentration and trying to get a complex thing to fit.

Turning fear into curiosity

Frustration can be a powerful force. Sometimes upon initial impact with a project, a so-called handover, there can be friction; you might be looking at a work worth up to several years, when you are entering in midst of a project. There’s a lot of tacit knowledge also present, decisions having been made. A new project being handed over is like a shapeshifting blob of stuff; you’re struggling first to get a overview and familiarize yourself with possible any new tech that comes up.

Don’t be intimidated by initial frustration. It usually turns out fine! Keep asking those dummy questions and keep an eye for possibilities to start chiming away with the code. Usually when you do changes and additions, things start to roll at once.

  • identify your emotions
  • identify the flow and connections between emotions; did you get frustrated at something, a process, someone particular; at a way of things done, or something that you think should definitely be done?

Ivory Tower – Old Systems Plague

Some large organizations have problems in fallout of obsolete technology. Large HR / workflow systems implemented years ago seemed like a great idea; now, they’re outdated, clumsy to use, and have little if any real positive effect on personnel. Yet no-one seems in position to nudge a change. This is a typical situation that you might encounter.

My tips:

  • keep your head cool
  • try to find other kinds of users besides yourself; what do they have in it? Someone surely knows how to motivate using the system, otherwise it would’ve most certainly been dumped
  • when there’s a chance, be part of the changing force that can make things better

Learn to surf on the cutting edge

In our profession, things rarely are “ready”. That means:

  • you will be using software to make software
  • software contains always some bugs
  • => this means that your tools are not perfect!
  • some of those bugs will be visible to you, too
  • you will get irritated by the bugs
  • you can also control how much you let the bugs irritate you, and
  • file a bug report. Or even better: make a patch, and submit that (if the tool is open source and hosted somewhere publicly)

This trend IMHO has stayed essentially the same. The microarchitecture of our tooling has been more finegrained – so on average we’re doing software composed of many more packages, than we used to.

Software stacks – 50000 ft view

Some software stacks might take considerable time to get ready for work. We might be talking about a day or two, typically. There’s some trial and error typically in the process of setup. The more cutting-edge stuff you use, you’ll find that there’s often no single “dogma” of how to do even such a thing as complete setup. It just takes a bit of getting to know the stuff. Explore the options, try to also read first-pass without interruptions and as much as you’d like, it might be better to resist the temptation to go hands-on immediately. So: read. Then start doing, once you got a grasp of the big picture. Otherwise it’s really easy to get stuck midway, and actually wonder how you can undo your half-baked installation.

This is something that is best tackled with patience.

I’ve gone through maybe 20-30ish stacks at some depth. The biggest change that I perceived is that during the last 20 years, rise of open source dogma made a refreshing change in the sense of involvement. Whereas stacks used to be “professional toolboxes” introduced by some big corporation, nowadays stacks are a living project where individual contribution is often appreciated, things move faster, and there’s a better chance of actually reaching a live person to ask about for advice.

Facebook Comments

Still room for Future Email System?

Reading Time: 2 minutes

I wrote a piece of text about personal information management, some 14 years ago. The term PIM, back then, was a hot trend. PIM was referring to the technology that could handle your calendar, email, and any other messaging needs – plus any pieces of information that you simply needed to have always available. Long story short; there were a dozen different brands of PDAs – personal digital assistants. They were typically clamshell smartphones, with a black&white or color display, without native mobile data connection. Internet was available through WiFi in local networks.

What we know now, is that smartphones came, saw and conquered.

However, the question remains:

are our information needs met in an optimal way by this new era of intelligence?

For backgrounders, if you’re curious, take a peek at my original Future Email System -article.

Since 2005 a lot has happened:

  • technically our devices have become much more capable: in terms of device memory, speed, etc
  • we have even more messaging channels (media)
  • in business, various collaboration platforms reign currently
  • the volume of messaging has probably increased
  • digitalization has enabled us to take care of many real-world services online (think: dentist reservations, car maintenance, groceries, etc.)
  • number of passwords we need daily has increased somewhat (my estimate being around 20-40 per person)

In the near future, some trends to anticipate:

  • strong authentication may obsolete the user of passwords in near future: less hassle, easier & better security in accessing services
  • 5G mobile networks (2020-> onwards), as continuation to 4G, might bring a nice performance + usability boost to digital services, especially those that we access while on the road: faster and more ubiquitous
  • basically as IT advances as a profession, services should cost less (not clear whether it is the whole truth)
  • as people get online and use more smart services, some “network effects” (synergy) should make also a positive change
Facebook Comments

Spagile laptop

Reading Time: 1 minute

“Getting new laptop and installing Linux” (2016, a note in my Lastpass secure notes)

2019 – Bought a Lenovo, refurbed, with Windows 10.

Facebook Comments

The Discoball analysis of WordPress

Reading Time: 2 minutes

Getting SEO wrong is probably quite easy.

That’s not a bold statement. This is – in addition to the rather fancy project name, Discoball:

I had blogged for 10 years, until I had a glimpse into the reality that my content wasn’t exactly “selling”.

Here. Raw diary of how I:

  • discovered the status quo in terms of search engine optimization, and my content quality on Jukkasoft blog
  • learned how Google search and ranking works
  • what methods I used to gauge my blog’s post ranking on Google
  • how much it all cost
  • what was the effect of doing remedies on the blog

Google uses a variety of spice in what is called PageRank, an algorithm that determines the weights – and the order of search results display. PageRank scores web pages, and gives the result in which order (descending importance) the Google search results page shows sites. Rank high, and you will get hits. Rank worse than the first 10 results (default size of search results), and you will get a few % of the hits that would have been available at higher ranks.

The original structure, algorithm and plan for making Google’s spider software is very openly documented. The Anatomy of a Large-Scale Hypertextual Web Search Engine is a base document that you can view to get a glimpse into Google’s inner workings, at a time when the Web consisted of about 20-30 million documents.

During years, and as Google has had fundamentally an open approach to developing its methodology, there were also many attempts by various parties to tweak their search results, ranking higher in Google searches. Google responded with adjustments to the search algorithm. They used to be rather infrequent, but have since become much more prevalent.

Intuitively I was baffled by the fact that sometimes searching even with explicit keywords that I knew to be contained in some of Jukkasoft’s (my blog) posts, I couldn’t get a hit on Google. This led me to believe that my site was not exactly built by the book, in terms of search engine discoverability.

With a manual next to me, I set forth to first investigate how indeed am I ranked generally on Google, then make a plan to make Jukkasoft articles fully discoverable by search engines.

My aim is not to become a master of web as advertising media, but to better utilize the hours already spent on writing the content.

As I started planning it seemed obvious that I would be facing two kinds of things: technical and quantitative. The technical part has to do with things such as..

  • how does the Google search spider work
  • what search spider expects from a well-behaving blog
  • what are some of the obvious findings I need to fix in my blog’s articles?

Whereas the quantitative is raw data, numbers, which is indicative of probably both the writing quality and how interesting the article’s topic in general is to my audience:

  • what’s the expected background traffic (hits per month) that I sustain regardless of efforts to improve content searchability?
  • is the blog being used as a kind of reference, popping into individual articles, or more like a book with interesting content devoured article after article?

The Plan

  • make a inventory of status quo: # of articles on Jukkasoft; followers (readers), and viewer statistics (hits per week, month, year)
  • what’s the trend on yearly view statistics
  • understand Google’s PageRank basics (the search engine)
  • refresh and ingest the main points of the modern (2019) PageRank algorithm
  • understand which portion of the articles makes top 80% of traffic quantified by page requests (hits)
  • determine which of the articles are discoverable and which are not

Facebook Comments