He likes to build things. Usually out of code. Sometimes sound.
Here's some of his stuff.
Dramaforum's educational social media platform, targeted for primary schools. Allows children to learn 21st century skills in a safe, modern environment.
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.
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.
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.
Sole designer, implementor and maintainer of the project.
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.
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.
Because they have some very interesting properties.
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.
Signal(a) + Signal(b) is of the type
Signal(a, b). When either
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.
Since a signal is a function of its input, there's no place for hidden 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