Jukkasoft

Reading Time: 2 minutes

I haven’t much done games – as in programming them! During 1990s I did one, called ‘Space Shrapnel’ (finnish Avaruusromua), where a spacecraft has to be navigated through a random asteroid field – a side scrolling action game. Although a very simple game, it was quite much fun doing it!

I wrote the game in Commodore 64 BASIC. Designed a sprite, bound the keyboard controls to the spacecraft; added a scrolling background with character-mapped graphics. That was it. Some 200-300 lines of Commodore BASIC language. There was naturally also a “epic” (hmrhmhm….) background tune – but I refuse to talk about the merits there.

Thus this was my thinking one day: let’s grab some Python and do a proper game!

I think part of the reason that I’m really bad at implementing games, is due to the fact that I tend to over-engineer plans, while leaving the rote coding astray in hobby projects. Coding is hard, you know! It’s time to change that.

Python is one of the programming languages I have had a keen interest on learning. I’d done some “mainly read, some writing” of 3D scene importing scripts (for Blender 3D software).

Yet Python remained a bit distant as a casual language for making any standalone project – things that could really stand on their own, and be executed independently.

Battle sim in Python, day 1 (17.8.2019)

I wrote a piece of program to represent “armies”. I want to push armies against each other, one on one. The armies are represented as stats, a bunch of numeric data, and then the battle algorithm – along with a bit of chance – determines outcomes of individual clashes.

At first they only had:

• person count (soldiers)
• offensive strength score 0-100
• defensive strength score 0-100

Naturally that wouldn’t suffice. If actual battles were to be simulated, the armies would have casualties! So maybe it would be proper to record number of soldiers who went KIA, killed-in-action.

At this point my code was around 100 lines of Python. Some structures, initializing routines (“constructors”) for the armies; a bit of boilerplate, and whimsical plans for development, thrown in as inline comments within the code. The typical startup.

I couldn’t yet run the code. In a way the ability to run code would give something to grab: when you can get into that legendary “loop”, things usually look much brighter. Getting to the loop as soon as possible can be considered a modern cornerstone of agile development.

It was time to amend this and make a version that would run, print out at least some signs of life; and then terminate. I’d be quite happy with that as the first day tour of duty.

Language details: Python 3 and data structures

• arrays
• dict
• what’s missing?
• what are the batteries-included in Python 3, without using ‘import’ statements?
• everything is now a properly formatted function
• Python 2 was a bit ‘scriptish’, Python 3 is more formal

I split the initialization of the Battle Sim to constructor functions. They set data in the “army” variables. Python has a dict which suits well representing a record like an army: you have key-value pairs in the dict. By making a contract with yourself, that for example

Reading Time: 1 minute

Reading Time: 5 minutes

What would the essence of a truly futuristic, perfect information society be?

• computers
• AI
• optoelectronics
• the Internet
• digital, intelligent mobile networks
• smartphone software (apps)
• but before anything else, satisfaction and accessibility: technology being useful and understandable to people.

I have been fascinated by application of technology, especially the possibilities of communications together with high-tech (IT), for basically my entire life.

From hands-on experience on a very specific, low level assembly programming on a home computer, I later embarked on studying some (103 ECTS points worth) of computer science curricula – and have done most of my professional work as a software developer.

However, alongside I’ve carried a strong interest towards humanities, especially clinical human cognition, short-term memory, in general: neuroscience; theory of mind, and also layman psychology. Motivation. The kind of kitchen stuff that makes interesting conversations and sometimes even conversions. But which also has an amazing effect on us as information processors. When software and systems designer understand the underlying “fundamentals” of the users in all their variability, the technology can be successful. We humans even tolerate “pain” quite much, but we are not good at that if the prize we’re going to get is relatively too low.

Fascination with the future

The future has always fascinated me. It probably shows quite strongly also in the list of books I’ve read and probably also the scenarios of future present in many articles (A future email system, and its successor “Still room for Future Email system?“)

Sometimes quite seemingly evident changes take decades to happen. Afterwards the time periods seem to compress, and we don’t even remember that some paradigm change was a big deal. That’s human.

Too fast – or too slow?

Yet we often speak as if we would continually be engaged in change that is just like a train moving a bit too fast to be comfortable. There’s been a lot of (hot) and true talk about information

That’s true! …and not. I think the feeling of what is proper speed — “comfortability zone” — also depends on our particular capabilities, mindset and motivation at the time of evaluation. We’re sometimes undulating, and that’s very human indeed – part of our neural wiring.

1969: mobile pioneers and NMT

Cellular connectivity, one of the main building blocks of our connected world, got started as early as 1969 with the formation of NMT: Scandinavian co-operative, Nordic Mobile Telephony. The organization was able to set important practical standards in mobile telephony.

NMT had severe limitations, due to it being rather simple, “analog” technology.

Enter GSM, the next wave of mobile technology.

Without standardizations, both NMT and later GSM, the influx of mobile phone usage would have soon met with a capacity cap of essentially limited bandwidth. NMT

users and having more people owning a mobile phone, the situation would soon have been unbearable: people would accidentally overhear other people’s conversations, and the discussion streams would have become unintelligible due to mixups.

GSM built philosophically on top of NMT. GSM digitized the cellular network. It made the network better and more secure; more people could join the mobile revolution. GSM enabled digital services in addition to plain voice calls. This was one the key features, again a stepping stone up to the information society.

Many phone vendors built sophisticated mobile phones. The era of smartphones had started.

Data became equally important early on: messaging in all possible formats proliferated quite quickly. It started from 160-character messages between two GSM-phones (the SMS – short messaging service), group SMS, and email; with the availability of smartphone apps, all communication protocols (instant messaging just as one) were available to smartphones.

Just before app store?

With proliferation of smartphones, we craved for software – and soon got a tsunami of apps. Apps were first quite clumsy to install. I remember (2009) the time when getting a neat app for blogging on WordPress, on a Nokia E71, meant about an hour’s worth of geekness: finding the install package (a .sis file), downloading, transfering to the phone; installing it, and even installing some other software packages (or even entire frameworks) needed to run the thing. A big PITA.

Go forward just a few years, and voila! The ‘app store’ – it’s a major accelerator. Also helps people keep their apps updated and secured. Note a very curious twist of the history here: The technical concept of an app store was actually patented by Nokia, and licensed to Apple (among others). [5G phones licensing includes App store royalties]

Now we have lived in the era of app proliferation for 12-13 years.

What about the next 13 years? Say, years 2020-2032! It’s such a long term, but on the other hand I know for sure that many things come out of the labs in about 10, 15 or 20 years.

The path of new innovation, from discovery to actual street availability is quite long. VoIP (voice over IP), Wireless networking, etc all took their time to proliferate.

There’s in fact almost an overload of choice for each possible facet of life imaginable.

But that is exactly also the problem: to live your life, we’re prone to get more and more apps installed on the phone. It’s as if no one ever thought about a whole person – all we, the users, see is the point of view of a single business, a single company, or a single service provider. We’re viewing often their micro-empires and visions.

Corporate-centric UX can be clumsy: to buy coffee, yes, there’s an app. AND IT ONLY SUITS one brand of cafeterias. The same with everything: parking, paying at the groceries, bonus systems of you-name-it; etc. Every single business reinvents the wheel, with varying dressings, but essentially the same beef. The result is a frustrating jungle of apps installed on your smartphone.

Imagine this very likely future scenario:

• you wake up with the aid of a alarm clock app
• your fridge activates another app
• your coffee percolator does something with an app – or you will need to service the percolator (order more filtration papers or coffee beans)
• your electric toothbrush winks a Large Corp app that it’s about time to get some brush heads – but not quite fully automatically
• before you’ve gotten out of your home (the door security system requires a fingerprint), you have interacted with half a dozen apps
• wait till you start commuting…
• each interaction takes anywhere from 5 to 60 seconds, depending on what kind of authorizations and confirmations are configured in the apps

I don’t know about you, but I thought essentially that the future society and intelligent systems were a promise to save our precious free time. The de facto way things are going is that we’re pledging more and more time to miniscule interactions with gadgets, all the time.

Ok. We have a problem. We solve problems. That’s what people do.

The problems in current smartphone era

• finding a suitable app for The Thing You Wanna Do
• installing the app – yes, even still. Even now. But what about in 2030s? Maybe solved.
• authorizing the app for the first time: access to this, that, and some
• dispersed user data and privacy asymmetry, inbalance -> Project SOLID and Inrupt, others.
• updates and all the mental fuss associated with deciding whether or not to choose something
• discontinuations of services / apps
• finding replacement for the discontinued app
• porting your data (in reality, not theoretically) to the replacement solution

Couple of very optimistic scenarios and themes from 2032

• no need to carry wallet around anymore
• natural, high resolution VR enabled all around us
• effortless authentication to computer systems (no passwords anymore)
• perfect information security, while data being available for scientific and generally useful computing
• poverty reduced
• enable remote work for a greater portion of workforce
• more free time gets accumulated for a greater portion of workforce
• human lifespan improvements
• healthier population in general (social and medical improvements)
• targeted, precision medicine
• reducing human error at work with help of technology
• backups of user data is always understandable, safe and automatic
• automatically scheduling complex events optimally for maximum % of all participants
• traffic accidents reduced significantly; robotic cars
• age of getting “driver’s license” significantly lower than today
• smaller crime rate across urban and rural areas
• less congestion in traffic
• lower pollution

Reading Time: 2 minutes

Let’s review why ReactJS became rather popular!

Its philosophy can be summed as:

• write components
• concentrate on one task at hand
• your button is a button is a button
• tight isolation of the internals of a component
• say goodbye to most variable hoisting bugs in your code!
• use raw JavaScript, JSX or TypeScript
• if you can’t see your whole component without scrolling in your editor, refactor your code!

The real benefits of component thinking?

Think of that delicious piece of cake. Doesn’t it look clean, very enticing? There are layers; and the cake has a definite shape. However, the process of making one piece of cake is nothing but clean.

[Sorry guys – I have no idea why I brought that cake here. I’m trying a sugarless diet mostly]

In React, each component has a shield against global scope.

Each component also protects the scope at the same time. It’s a two way street, except… well, two-way was bad analogue. Since in React, the whole idea started with ‘props’: passing each component the necessary information, strictly one way. The component doesn’t see the global scope, and it shouldn’t.

Your React components are the hot-blooded trotters with eye patches properly aligned to make your web app a winner!

Reading Time: 3 minutes

Rare developer is the one who thrives on clutter – excess things, when one could suffice with less.

Try Laragon.

Especially if you want to get hands dirty quickly with development on a Windows laptop / PC. This is a real-world story of how I found the new fav toy! But what else? Find out.

Just as with alternatives, you get a Apache, PHP, MySQL stack with a single click. But Laragon is also a bit more:

• looks nice
• automagic virtual hosts: Laragon can update your HOSTS file
• also Rails stack installed
• seems to handle .dll dependencies well (I had trouble with alternatives)

Skip me if you know PHP

PHP is a versatile jack-of-all-trades. And it definitely holds its place with a firm grip. WordPress (blogging engine) and thousands of other well known apps are written in PHP. The power exists in a sturdy set of very central and useful built-in functions, which were chosen and developed by a real web admin for his own needs.

The true web pioneering technology

PHP evolved over the years. It had a very early start in 1994. PHP adopted very good ecosystem tools, such as linters, security checkers, and PHP was supported as a drop-in module in many kinds of web hosting environments. You could thus rely on the investment keeping its value.

I knew all this yet had barely written a few thousand lines of PHP in 2019. I felt that it was time to take mastery of PHP, even if I did it just at a rate of 20 minutes daily.

PHP sits at the server end. It can be written (sprinkled) within HTML, in separate files, or be made the “master of the universe” – with sole responsibility to take in HTTP requests and spit out all the other artefacts; HTML, Javascript code, images.

This is an important distinguishment to make. PHP interprets incoming web requests: GET, POST, HEAD, the usual stuff. This server side PHP code you’ve written takes care of routing these requests. Note here: You can write full web apps with PHP, but if you want to do hifi and have very elegant look-and-feel, it then also takes Javascript and CSS knowledge. So PHP’s role is to take care of classical server side processing; it can be used to do user interfaces, but on quite a rudimentary level. With today’s ‘flat design’ and minimalism, that might be ok. You don’t necessarily need top notch JS/CSS or any other frontend skills.

Peak to the neighbor: Node + Express

Node ecosystem has ‘express’ which is a light-weight development server. I’ll let the figures speak for themselves. Also, look at the setup of minimalist server-side code: couldn’t be easier?! The root ‘/’ is hooked to a anonymous function, that always returns the Hello world string. This is beautiful!

Idea across all of these is that whereas with Apache or nginx you usually handle more complicated real life dilemmas of web hosting; as developer you are interested in passing a single HTTP call, successively, to your code under development. You want button and menu item elements to fire action, and see what happens. As developer we’re more interested in the change of state of the app, as response to user input; rather than more complicated issues, kind of “..yet”. It helps to constrain the problem at hand to an understandable piece.

Reading Time: 2 minutes

It was yesterday that Linus’ tech channel video kindly introduced me the idea of a Pi-hole. It’s a Raspberry Pi -based gadget that makes web surfing less painful, by removing a lot of the ads present in apps and web pages.

• power switch
• UPS backup power from 9V battery or similar, if required for graceful shutdown
• a physical case
• SD card of sufficient size (to hold future blacklist + whitelist data)
• rather minimal software footprint apart from the required
• remote connection daemon (ssh?) running on the device
• web interface for configuration (comes with standard Pi-hole)

What does the Pi-hole do?

Serving you almost ad-free Internet at home or office. Pi-hole is a very small embedded computer, readily available as Raspberry Pi devices. After a software install, there’ll be a dashboard (GUI) and some server software that will do the magic.

The promise is that by configuring your tablets, phones and PCs to use the IP address of Pi-hole instead of the ordinary public DNS server (given to us usually by Wifi connection automatically), you can save yourself the headache of watching countless ads during the day.

Pi-hole runs on Raspberry Pi; it can run on any embedded Linux OS, that supports certain key factors necessary: a network stack for TCP/IP, and a way for the device to be a middleman in Internet traffic.

The device has software: an ordinary DNS server daemon, which has been modified to consult both a whitelist and a blacklist. Whitelist means internet addresses that are accepted by you, the user. Blacklist is typically downloaded from a main repository which curates known aggressive ad distribution servers.

When a computer, tablet or phone’s web browser asks for content via a DNS query, the request goes through Pi-hole device first (Pi-hole has typically a static IP address so technically it is always there, ready to respond, when computers use DNS). Pi-hole checks the request against its whitelist and blacklist. If an address is on whitelist, it gets passed to real DNS server from the other network interface. If the address is on a blacklist, then it means that ads would be served, and Pi-hole simply reports (fakes the answer) that the server is “missing”.

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!