Page 2 of 49

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!

Facebook Comments

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!

/J

Facebook Comments

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