This is Tuomas

me

He likes to build things. Usually out of code. Sometimes sound.

Here's some of his stuff.

SKILLS

web
front-end
back-end
mobile
desktop

TECHNOLOGIES

node
react
angular
ruby on rails
python

RECENT PROJECTS


PETRA'S PLANET SHARE

Dramaforum's educational social media platform, targeted for primary schools. Allows children to learn 21st century skills in a safe, modern environment.

More »


REACT + SERVICES

Developed for Petra's Planet Share, React + Services is a FRP library for React. It's fully open source and available on my Github.

More »


RUNESTONE: ARENA 2

Sequel to Runestone: Arena, a turn-based RPG inspired by the classic Finnish Areena series. Built on top of the Flex framework. Game engine, UI, sound and music all created by me.


CLIMBING MOON

Winner of the Kongregate Game In Ten Days Game Jam. Simple mouse + keyboard game implemented in Haxe. Game, engine, sound and graphics, all created by me.

Play »

ABOUT: PETRA'S PLANET SHARE

Petra's Planet Share is a modern learning environment for primary schools, social media and 21st century skills in a safe, secure environment. Children can chat, blog and share content.

MY ROLE

I was primarily responsible for designing and implementing the product's client and server side architecture.

BACK-END

Share is implemented as a cluster of microservices talking to each other over AMQP. I designed the architecture to maximize code reuse between multiple products. At the time of writing this, the product's back-end consists of 8 services covering various requirements from handling user requests to availability monitoring and media processing.

Docker is used for continuous integration of development environments and production deployments.

ruby clojure node amqp docker mysql mongodb

FRONT-END

At the time of writing this three clients have been developed for Share, with one of them facing the end users. The clients were developed as responsive single page applications to target desktops and mobile devices.

React was chosen as an alternative to bulkier MVC framework for its compatibility with functional programming concepts. The choice really paid off, resulting in a far higher level of code reuse than in a typical web project. Functional reactive programming library React + Services was developed to solve problems caused by imperative style programming early in the project's lifecycle and proved to be a pleasure to work with.

react services coffeescript gulp less browserify

ABOUT: REACT + SERVICES

React + Services is a functional reactive programming library that solves the problem of wiring data to components in React. It lifts some concepts from the Flux architecture such as unidirectional data flow and combines it with functional programming concepts to create a simpler alternative for event based architectures.

MY ROLE

Sole designer, implementor and maintainer of the project.

MOTIVATION

Early while developing Share, we were having serious issues with data integrity. We used imperative style of programming to store mutable data locally and manually invalidated it when the data was changed. Since this usually resulted in immediate re-rendering of some components, which in turn could trigger further changes in the system, it was easy to accidentally introduce infinite loops and lifecycle issues into the system.

I took a look at some Flux based solutions to the problem, but couldn't help but feel that they felt needlessly heavy-handed. Often the syntax seemed to be full of redundant definitions and imperative concepts. The number of layers seemed unnecessarily high.

SOLUTION

In software engineering, mutable state is the root of all evil. Unfortunately, programs often need to do useful things based on user input, so the best thing we can do is to try handle that complexity. RS does this with signals.

In mathematics, a signal is defined as a function of time. Applications are often required to react to things like clicks and keypresses, so writing functions with only time as an input wouldn't be that useful. Therefore we have to replace time with a unit that the HTML DOM understands: events.

So, if we're just gonna react to events, why bother with signals at all?

Because they have some very interesting properties.

  1. Signals are continuous

    That is to say that they always have a value. In React we are always interested in only rendering the current state of the application. If we have a promise for example that will be fulfilled after a HTTP request completes, we can't render it because it doesn't have a value yet. Instead, we need to hook it to a component method and modify local component state after it completes.

    Since a signal is essentially a state machine, it can be rendered at any point. We can declare in a component that it requires some data, and if that data is not available yet render a loading indicator. When the signal state changes, we can render the component with the newly acquired data.

  2. Signals compose

    Signal(a) + Signal(b) is of the type Signal(a, b). When either Signal(a) or Signal(b) change, we know that the value of Signal(a, b) will change. Not in any other case. Therefore we can descibe the state of the entire application as a signal composed of every signal in the system.

  3. Signals are explicit

    Since a signal is a function of its input, there's no place for hidden state.

CURRENT STATE

Right now React + Services is in production use in Petra's Planet Share. You can read the source code at Github. Unfortunately the documentation is outdated. If you're interested in experimenting with RS, you can contact me via these channels and I'll help you to get up and running.

react coffeescript gulp browserify