TypeScript and new pet project

Around two months ago I started a new pet project. As always, I built it partly to solve a problem, and partly to learn some new language or technology. The problem I wanted to solve was showing images and maps to players when playing table-top role-playing games (and, while at it, manage my music from the same place). The language and technology were TypeScript and to a lesser extent ES2015. As always, I learned some things I didn’t quite expect or plan, like HTML drag-and-drop, Riot, a bit more Flexbox, and some more canvas image processing. The result is the first public version of Lyre, my program to help storytellers integrate music and images into their stories (especially useful for semi-improvised or interactive stories).

But the reason for this post is to talk a little bit about the technology. I admit that I haven’t really studied TypeScript thoroughly (I mostly learned bits and pieces while programming), but I think I like it to the point that it might become my front-end language of choice when I cannot use ClojureScript or similar.

So, what’s so great about it? Essentially, it’s ES2015 with optional types. The bad thing is that it needs special incantations to be able to use regular JavaScript modules, and in most cases you don’t have types defined for non-TS modules so you end up with type any for everything. The good thing is that it’s extremely familiar for people who know ES2015, because it’s almost the same, and that of course you can specify types wherever you want to. I am not the biggest fan of static types, but after trying it I think I really like the idea of optional types. Moreover, types in TypeScript are relatively open and feel like they fit very well in the JavaScript ecosystem. Two examples:

  1. Apart from enums, you can create union types that eg. are as simple as a choice between two strings, like type Mode = "off" | "on".
  2. Interfaces can be used to specify the properties, not just methods, that should be available in an object. Among other things, it’s possible to specify that an object should have certain specified properties plus any number of extra properties as long as their values are of a given type.

They have other interesting features, like union and intersection types, type guards for functions, decorators, generics and others things. I haven’t really used most of those, but I realised that I liked TypeScript when I was writing some JavaScript and found myself missing the optional types.

For actual editing I’m of course using Emacs, in this case with TIDE. Although the refactoring capabilities are very limited, the rest worked quite well and I’m very happy with it.

The other bigger thing I learned was Riot. Which, sadly, I didn’t like as much: I found it very confusing at times (what does this point to in the templates? it seems to depend on the nesting level of the ifs or loops), ended up with lots of rebinding of methods so they could be safely passed around in templates, and generally felt that I spent too much time fighting with it rather than writing my application. Now, some of these problems might have been caused by Riot-TS and not Riot itself, but still the experience wasn’t that great and I don’t expect to use it again in the future. Again, bear in mind that I mostly tried to learn on the go, so maybe I was doing everything wrong :-)

In conclusion, I love these projects because I end up with something useful and because I always learn a bunch of things. In this case in particular, I even learned a language that positively surprised me, even if I’m not a big fan of static typing. Again, if you want to have a look at the result, you can learn about Lyre and download the code from GitHub.

Narrative games and social change

One of the reasons I like role-playing games is that they can be used to train empathy and think about the actions of others, and thus our own. I think imagining what others would do in a given situation is a healthy exercise that can make us understand people, including ourselves, a bit better.

Perhaps my favourite game is Call of Cthulhu, a game normally set in the 1920s. I find that decade fascinating, partly because it so clearly highlights the prejudices normal, well-meaning people had/have. We are tied to our circumstances and all that. One of the things about the 20s that fascinate me so much is the KKK. I read a fair amount of information about them while preparing a scenario about racism and prejudice, and it shocked me how childish they were, and how big they were at some point.

Some time later, thanks to the film Suffragette, I started reading about the suffragettes, the radical, violent branch of the suffragists. The fight for women’s voting rights might sound like a dull topic, but boy was I in for a surprise. I read about the smart stunts they pulled and about how they learned jiu-jitsu to defend themselves from the police, and I was just blown away by how amazing these women were. So much so that I decided to do a little homage, in this case in the shape of a (work in progress) scenario about feminism and oppression set in early 1914. As the one linked above, it’s not completely historical, but it’s close enough that one can learn a thing or two and think a little about how things were then, and how they’re now.

After I’m done with the second one I’m planning to write a third scenario about social change, most likely about mental illnesses, but only time will tell.

Functional Programming Is Not Weird

Recently I read a blog post titled “Functional Programming Is Not Popular Because It Is Weird“. I strongly disagree with the assessment and Twitter was too short for an answer, hence this blog post :-)

The blog post says that “Writing functional code is often backwards and can feel more like solving puzzles than like explaining a process to the computer”. I don’t agree at all, and I think this is simply a result of seeing functional programming in imperative programming terms. The first thing that comes to mind is that programming should not feel like “explaining a process” to the computer. Why should it? Imperative programming is centred around the process, the how. Functional programming is more focused on the what (which indeed is backwards compared to imperative, but I don’t think it’s backwards for humans).

Second, I think the recipe example is terrible and doesn’t show anything about the two styles of programming. The point of reading a program is not to be able to follow it step by step and produce the correct result (the computer does that), it’s about understanding the intent. Food recipes are about mixing things and obtaining the result. Programming is not about mixing things. In fact, the easier to separate and recombine they are, the better. This is very unlike a recipe.

Third, there is the “Imperative languages have this huge benefit of having implicit state. Both humans and machines are really good at implicit state attached to time”. Hahaha, what? State is the source of many, many problems in programming. Avoiding state, or at least separating the state-juggling bits, generally makes for better programs. Humans are terrible at keeping state in their minds, or understanding how a certain state was reached, or realising what produced changes in the state. To give an more concrete example of this: the post claims that “you know that after finishing the first instruction the oven is preheated, the pans are greased and we have mixed a batter”. No, you don’t. In a real program, you would be reading the source code for the second point, and it wouldn’t be obvious what the current state is at that moment. You would have to read, understand and play in your head the whole first point (and remember that, in real programs, there would be many ways to reach point 2, yikes!). And when anyone changed the first point, suddenly your understanding of the second point would be wrong, and you wouldn’t even know because the second point’s source code hasn’t changed. That is one of the reasons why state is generally best avoided.

The C++ example using templates as a functional language I’ll just skip as I don’t think is relevant at all for real functional programming. But right after, the author claims “I spend too much time trying to figure out how to say things as opposed to figuring out what to say”. I can relate to this while I was learning functional programming, but that’s entirely normal: you are, in a way, re-learning how to program. Many of your instincts and mental tools aren’t valid any more, and in some sense you have to start over. It’s frustrating, but the fact that it’s hard means that you’re being forced to think in a different, and in my view better, way.

Finally, at the end there’s “if functional programming languages want to become popular, they have to be less about puzzle solving”. If it wasn’t hard for imperative programmers to learn it, it wouldn’t be a different style, it would simply be a different syntax. No point in learning it! The reason why it feels like “puzzle solving” is because it’s different, not because it’s hard.

Now, I’m not saying functional programming is the best tool for every single problem, but most gripes imperative programmers have about functional programming are about “it’s different”, whether they realise it or not. Don’t be afraid to learn functional programming when it seems hard: that’s the whole point, you are learning a different way to solve problems!

Music Explorer

Lately I’ve worked on several small projects, mostly to learn new technologies. The newest one is music-related: a piano that shows scales and chords “in context”, to learn and explore music theory. The idea came about because my first instrument was the guitar, and music theory is pretty hard to make sense of when you’re playing the instrument. It’s just too hard to remember all the notes you’re playing, let alone realise when two chords in the same song are repeating notes because those notes might be played in different positions (eg. one chord might use E on the open sixth string, and another might use E on the second fret of the fourth string).

I remembered that when I started playing around with a piano, and I could figure out how to play a couple of chords, it was painfully obvious that they were repeating notes because they are in the same positions. In the same way, it felt much more natural and easier to figure out on a piano which chords fitted a scale, so I decided to write Music Explorer, and ended up even buying music-explorer.org to host it. I don’t have a particularly grand plan for it, but I’ll probably add at least some small improvements here and there.

If you are interested in the technical side of it, Music Explorer is written in JavaScript (EcmaScript 6, to be more exact). I learned to use React with JavaScript, Browserify, Sass/SCSS, Ramda, AVA, the fantastic JavaScript music library teoria and a bit more CSS while writing this so it was definitely a useful learning experience for me. The full source code lives in GitHub and it’s licensed under the MIT license so you can go have a look!

Pet projects

I’ve been writing several pet projects in the last months. I wrote them mostly to learn new languages, techniques or libraries, and I’m unsure as to how much I’ll use them at all. Not that it matters. All three are related to role-playing games. In case you’re interested:

  • Character suite: a program to help create characters for RPGs. It’s designed to make it easy to add new rule systems for new games. It’s written in Clojure and ClojureScript, and with it I learned devcards, macros, Clojure’s core.async, figwheel and PDF generation with PDFBox. The code is messy in parts, but I learned a lot and I have a usable result, which is the important thing.
  • Nim-DR: a tiny command-line program to roll dice, including adding aliases for rolls (eg. alias “pc” for “1d100”). It doesn’t even support mixing kinds of dice, or adding numbers to the result. I mostly wrote it to get a taste of Nim. While I’m not a big fan of statically typed languages, the type inference really helped, and I liked what I saw. I may try more experiments in Nim in the future.
  • Map discoverer: a program to uncover a map bit by bit. You can use it online. I wrote it to learn ES6, the new JavaScript standard, and a bit about the HTML5 canvas element. I used Babel to translate ES6 to regular JavaScript (I could have used Node 4, but Babel supports much more ES6) and es6-features.org as a reference to learn the new bits. I really liked ES6: it still feels like JavaScript, but it improves things here and there. I just wished let didn’t allow re-assignment of variables.

While writing the last one I even learned about the pointer-events CSS property, which allows you to mark an element as not receiving events like mouseclick, mousemove, etc. Very useful!

My first Arcon

Arcon is a gaming event in Oslo with board games, card games, miniature games, role-playing games, and other activities, and I attended this festival for the first time this year. I was curious about attending such a festival, and I wanted to play some more RPGs and see how it was to play with people you just met. Also, as there was a competition for the best scenario, I decided to submit one I had written but not played yet. It was short and simple, and thus fairly appropriate for playing in a festival.

The scenario was set in the world of Elric and Stormbringer by Michael Moorcock, a (dark) fantasy world much closer to Game of Thrones than to the stereotypical fantasy role-playing games (sadly) most people expect. I don’t want to spoil anything here in case you want to play it but if you want to read it you can download the full version of my scenario “The Merchant“.

Unfortunately I was there only one day so I didn’t see much, but I won the scenario competition (see here, in Norwegian though!) and got, among other things, a gift card with which I bought myself Fiasco, a game you could say is about collaboratively making up and telling your own Coen Brothers-style film; and Rory’s Story Cubes, a set of dice with pictures that can be used as an improvisational story-telling game, as a tool for story brainstorming, etc. As a funny note, the shop inside the festival gave the attendees a discount: they could choose between 20% or roll 4D8 and get the result as a % discount. Although I only got to play my own scenario and one game of the Small World board game I can say that all in all it was a pretty fun experience for me. Will probably go back next year.

Role-playing games and creative writing

Note: if you think RPGs = Dungeons and Dragons (or otherwise nerdy fantasy), go read “Role-Playing Games as a medium” first!

I started being an RPG narrator as an adult not too long ago, and a whole world opened for me. Although I was convinced I wouldn’t have time to write my own scenarios (stories) and planned to only ever play scenarios written by others, at some point I couldn’t resist writing my own. It wasn’t even important whether I ended up playing any of them, and in fact I haven’t yet, but I find it just so satisfying to write them. It is an interesting, new, creative hobby that fascinates me.

Writing RPG scenarios is a bit like writing a short story, but instead of writing exactly what is going to happen, you develop the mood, the main events, the characters, the locations, and the hints (if applicable), and only as you narrate them can you fill in the specifics. The reason is that in RPGs, you, as a narrator, are not in control of what the protagonists do. For example, instead of deciding that a secondary character says this or that, you can only decide what that character knows, her personality, and her goals. Then, as you play the scenario, you will have to improvise what that character actually says, depending on what the protagonists ask or how they behave.

Writing the second scenario in particular was an enjoyable, immersive experience. I ended up researching a lot to prepare it: the 1920s generally (even learned about make-up!); the Ku Klux Klan; Charleston, West Virginia in the 1920s… I also tried to create a decent-looking document for it, and even tried to make some basic drawings of some of the characters. There was something irresistible about developing this story and using different skills to bring it all together in the most realistic and vivid way I could manage (which is not a lot, but that’s not the point!).

One of the drawings for the scenario

One of the drawings for the scenario

The 1920s fascinate me because they make me think of how prejudices pass unnoticed and/or as positive traits when they are commonplace, something I tried to highlight a bit in my scenario. I will probably improve it a bit in the next weeks but if you’re curious you can download and read the initial version of “Gone Girls“.

Role-playing games as a medium


Imagine if someone who had never watched films thought all films were like Fast & Furious. Or if someone who had never listened to music thought all music was like One Direction. Or the same with videogames and Call of Duty. This is similar to what happens to Role-Playing Games (from now on, “RPGs”).

You see, RPGs don’t have to be a dorky, silly power fantasy (disclaimer: I’m a Dungeons & Dragons hater). They are story-based games that can be used in different ways, a bit like videogames: telling a story, light social fun, cooperative problem-solving, etc. They have many different genres (horror, fantasy, detectives, thriller, science-fiction, …) and as many ways to interpret those genres as films do.

Tiny bit of history

Modern RPGs started in 1974 with Dungeons & Dragons, in the context of wargames and other boardgames. Its author greatly downplayed the “play-acting” and story telling elements, and indeed most old-school RPGs are not very story-centric, but more rule- or goal-centric. However, some later games, like Vampire or Trail of Cthulhu, gave much more importance to the stories. In fact, there are more and more story-driven games, including many recent RPGs that explore different mechanics, like not using dice or not having a central narrator, or themes and genres not usually associated with RPGs, like love or sex.

How they work

Now, how do you actually play? It’s sort of what an improvised radio drama could be: you have one narrator and several “actors” (the players) playing the protagonists. Some important differences are that (a) the “actors” (players) don’t have written parts, and instead decide, as the story develops, what their characters do; and (b) all non-protagonist characters are played by the narrator. When there are conflicts (eg. a character searches a room for clues and for whatever reason it’s not clear they will find it), dice are usually used to decide the outcome.

In detail, an RPG session starts with the players getting familiar with their characters (assuming they’re playing with new characters; it’s a bit like actors preparing a role, but only for a minute or two), and the narrator describing the initial setup or conflict. Once the initial scene is described, the players talk and decide what their characters do. The narrator then describes the outcome and the players can decide what to do next. And so on.

This has some interesting properties: first, the narrator does not have a full, linear story ready to tell, but instead has to work with events, characters, locations and scenes, adapting all this to what the players decide to do; second, no one knows how the story will develop or end, including the narrator itself! This opens the possibility of telling the same story to different groups of players, because it will be different every time.


RPGs can be used as a storytelling medium. A bit like videogames, they can be used both for interactive storytelling, or simply for the fun or the challenge. As examples of different genres and possibilities, I’ll close with a short list of “alternative” RPGs:

  • Dread – Horror game about centred on tension and, well, dread. It’s played without dice, using a Jenga game instead. If a player knocks over the tower, his/her character is removed from the story (dies, becomes insane, …).
  • Universalis – Storytelling game in which all players are narrators. There’s no story to tell beforehand, the story is created collaboratively.
  • Breaking the Ice – “A game about love, for two”. It tells the story of the three first dates of a couple, and at the end of the game it’s decided whether or not the couple stayed together. Again, like in Universalis, both players are narrators and build the story while playing. This book is part of an RPG trilogy about love.
  • Fiasco – Another RPG without narrator in which you tell Coen-brothers-style stories that end up pretty bad for the characters.

Bye Flickr, hi trovebox!

For some time now I’ve become more and more interested in running my own services and using less and less external services. The latest has been Flickr, which I had been a Pro member of for over 8 years now (yikes!). I used it less and less, and was more wary of uploading pictures to it, so I thought it made sense to just paying for it. However, there was one thing I was still using Flickr for, a program I wrote called clj-flickr-memories (now clj-photo-memories): every week, that program searches for pictures taken this-week-several-years-ago and sends you an e-mail with the results, if any.

The first possible alternative I found was MediaGoblin, but the API is too basic and it doesn’t even save the picture details (such as the date the photo was taken) in the database so I couldn’t even improve the API to support that. I was close to giving up when I found Trovebox: it’s a hosted service you can pay for, like Flickr, but it’s also open source so you can host it yourself if you want. And although its API documentation leaves a bit to be desired, it could do what I wanted, so I got cracking and modified my clj-flickr-memories to support both Flickr and Trovebox.

If you want to switch from Flickr to a self-hosted Trovebox and want to import your photos, there are two things you should know:

  1. If you self-host and use HTTPS (and you should!) you need to include the “https://” both in the “host” key in the command-line tool configuration file and in the Android app.
  2. You can easily import all your Flickr photos in two steps: first you use export-flickr to fetch information about your Flickr photos (only works with Flickr Pro accounts, though!) and second you use import to import those photos into Trovebox. Note that the first step will leave a directory “fetched/” with one file per photo, so you can choose which photos to import to Trovebox, eg. based on the date.

Trovebox also has mobile apps, but at least the Android one requires internet access to it’s not great for me (you can’t browse photos offline).

Book summary: The Information Diet (III)

This is the third and last part of my summary of “The Information Diet” by Clay Johnson (you can also read the first and second parts). This part covers part III: Social Obesity.

Social Obesity

The only way we can solve the problem of information obesity is to change the economics of information (the information that is the worst for us is the easiest/cheapest to obtain), because they have changed in a way that not only stupid people are getting duped anymore. We need to demand an end to factory-farmed content, and demonstrate a willingness to pay for content like investigative journalism and a strong, independent public press.

Ideas: share this book; organize in infogroups; focus and be civil, keeping focus on the goal of improving digital literacy; meet face to face; learn, eg. from the reports by Knight Comission; act, producing useful outcomes in your local communities, including children.

Participation gap

The participation gap is the gap between people and the mechanics of power in their governments. Its cause is our desire to focus on large, emotionally resonant issues over practical problems that can be solved. Related to this is the “sportsification” of politics, which makes us treat elections like athletic rivalries, vilifying the other team at the expense of doing what’s right.

The first cause is scale: the underlying structures of government aren’t designed to handle our present population. Transparency is overrated as solution to this, plus it has disadvantages like allowing dishonest people to appear honest. Two big lessons about this: (1) there’s a gigantic gap between the skills to win an election and the skills to govern a country, and (2) many of the nonprofits and advocacy groups are more interested in staying relevant than solving problems (as a result, these advocacy groups tend to focus on larger problems that can go unsolved for years; also, after working for one such group, the author assures that online petitions are not meant, primarily, to cause change, but to get your email address so that you can later be bombarded by emails asking for money).

Start sweating the small stuff at the expense of some of the big stuff. If you’re interested in making government more accountable, work on making it so that the government’s listening tools and policies are modernized. Every issue has hundreds of small, nonpolitical, operational problems. Fixing these can have a huge impact compared to combating a vague foreverwar.

Special note: Dear Programmer

Programmers: take your role in society seriously.  Dedicate some portion of your time to issues you care about. You needn’t ask for permission to do this, or wait for a nonprofit or advocacy group to ask you donate your time (and while it’s useful to partner with organizations, it’s likely that they’re more interested in your skills to help them fundraise than they are to solve problems). This isn’t a call for you to build apps for your favourite nonprofit, because unless you’re willing to support and maintain each application, and help constantly ensure its usage and adoption, you’re wasting your time.

And this is it. As for my review of the book, I got to say I was a bit disappointed by it. It was much more focused on American politics than I expected, which sometimes made it hard to relate to. There are definitely many interesting parts in this book, and a fair amount of food for thought, but some of the advice feels pretty demanding: it feels like it’s enough to keep certain things in mind and make certain changes without really measuring everything objectively (I have the impression that the author has a much bigger faith than me in numbers, measurement and “objectivity”). In summary, good book, but not as universal or life-changing for me as I had hoped.