What I'm working on this year
A number of people in and out of work commented that I usually seem to be working on something, but that I’m not very good at making it visible. Although I don’t do it for publicity, a personal goal is to be better about articulating what I’m working on - so here’s a post documenting what I’m working on right now, and where I’d like to get to by the end of 2016.
I discovered Kotlin, a JVM language which is much like Swift is to Objective-C, in the latter half of 2015, and found that it only improved up to the recent 1.0 release. Having successfully used it for several projects (including the ones below), this year I made the decision that unless there was a really good reason for doing something in Java, I’m going to do it in Kotlin instead. Shading it in to a distributable Jar incurs a ~1.5mb cost right now which seems entirely worth it for all of Kotlin’s benefits.
At the beginning of this year I made the CarrotCodes organisation on GitHub to collect projects that were either widely used, or that I considered good enough to make public. It also makes it easier for people to follow stuff, and my personal account is mostly for messing around - there’s a nice line between experimenting, and software I’ve committed to maintaining for a while.
Warren is both an umbrella for chat related projects, and an IRC framework itself, which reminds me that I need to make a big list of rabbit related names (sensing a theme?) and choose a good one. The main consumer of the framework at the moment is Thump, which I’ll discuss later.
I’ve been interested in IRC for a very long time (relative to my age, anyway) - since the early days of MSN Messenger when I used to contribute to MSNP, a reverse engineering effort. Earlier versions of of MSNP were very similar to IRC, from a client perspective, which made getting interested in both fairly natural. Eventually Microsoft SOAPed the MSNP protocol up, which naturally it killed any interest I had in continuing. I’ve met very few people enthused by XML in my lifetime.
Much of my out-of-work communication happens over IRC, across several networks, and I use a private channel on ImaginaryNet to provide things like CI and GitHub notifications for the organisation.
Warren was originally baked in to Thump, but it became obvious pretty early on in the project that splitting them out made sense. Development on it is slow and steady - consumers can stay connected to IRC for months at a time, so rushing things and risking disconnecting regularly is bad.
In terms of goals, I’d really like to get Warren up to ‘full’ RFC 1459 compliance, along with IRC v3.1 compliance, by the end of the year. Version 0.1 was written entirely in Java, and I’m working on 0.2 which is a Kotlin rewrite, to apply learnings from the first version.
Thump is a Minecraft IRC bridge, that uses Warren to provide the IRC related bits. People use it so they can play in game (usually on a server) and continue to chat with people outside of the game.
At university we had several Minecraft servers going, on and off, both CompSoc related and not. IRC bridges existed already, and worked OK, but were largely poorly constructed and didn’t support many IRCv3 things. Near the end of my degree I needed something to work on that wasn’t my dissertation, so I decided to go ahead and write my own, and release it for other people to use.
Currently, ForgeCraft (a large, fairly popular private server for testing Minecraft mods), and a few members of it, are the largest Thump users - and people seem happy with it. One rare bug plagued the project (in certain circumstances a netsplit would make the bridge quit), but thankfully it was infrequent enough, and easy enough to fix, that it wasn’t too annoying.
It’s currently written in Kotlin, and the Kotlin runtime is shaded right in to the Jar. Being able to use Kotlin in Minecraft is testament to how much effort JetBrains have put in to making it interoperable with Java.
Although Thump and Warren aren’t as popular as some of my other projects, they’re definitely what I enjoy working on the most.
Bunnies as a Service 🐰
‘Bunnies As A Service’ is a fun little project I worked on to share all the bunny videos people had sent me. There are 115 videos on bunnies.io right now. You can click the video below to get a new one.
I split it roughly in half - an API to get resource locations (including random IDs, and specifying assorted metadata like an aspect ratio), and somewhere that served the resources. That way, if it did suddenly get a lot of traffic, I could serve the resources from somewhere cheaper.
It’s served 52GB of bunnies this month, and as of today there have been 652,319 tracked API requests, plus ~400K before I added tracking to the API layer (guesstimated from nginx access logs). My work’s Hubot (a chat bot) is integrated with the API, and it turns out people really like getting a whole bunch of random bunny videos at once. As long as they don’t bill me for lost productivity, it’s probably fine.
It uses Dropwizard for the API layer - a speedy Java framework that makes everything really easy, as well as Redis for persisting access counts. Last time I stress tested the service it could serve between 5K and 10K a second from the cheapest Linode I could put it on. I’d like to investigate Kotlin web frameworks, but this is lower down my priority list.
This site uses Jekyll, a static site generator. I write posts in Markdown, run the generator, and it makes a bunch of static HTML files that I can chuck up basically anywhere.
The design itself is all custom (plus a few things from popular Jekyll themes, like the footer area below). I deliberately did the HTML and CSS myself to try and capture some personality (which is just an excuse to include emoji and bunnies). It might eventually be open sourced, but I’m paranoid about my terrible CSS skills.
The goal for this project is to get some technical blog posts going, on some of the other projects I’ve talked about. The main thing blocking it at the moment is syntax highlighting - the highlighter built in to Jekyll doesn’t support Kotlin at all yet. If I don’t get something working within the next month or two, I’ll probably just put the code on GitHub and embed it using Gists.
What I’m probably not working on
EnderTech is a Minecraft mod for the 1.7.10 version of the game. More specifically it started as an addon for another Minecraft mod, Thermal Expansion, which added all sorts of fun technological machines and mechanics, but didn’t offer much for the endgame.
As of today, it has 1,529,942 tracked downloads on Curse!
Newer versions of Minecraft have meant huge changes to the way mods are written, and I don’t have any enthusiasm for rewriting it. Although I had fun doing it, unless there’s huge demand, I’m probably not going to port it.
As I conclude this post I realise just how much stuff I have going on, and how bad I’ve been at advertising it. Several years ago I had a goal of going ‘open source by default’, and I’d say I’ve achieved that. Having a personal account as a testing ground for things to work on, with the goal of making it good enough to push to the organisation, helps a lot.
At the beginning of university I was extremely ‘code shy’ - I never felt anything was good enough to release. Having high standards for your work is a good thing, but keeping it secret doesn’t really help anybody. Although you’ll probably meet unpleasant, entitled people in your open source work, they’re definitely a minority, and feeling like you’ve helped people makes it worth it.
Make goals, have fun, and ship it.