During the second year of university, I created a kernel for the ARMv7 instruction set. I went above and beyond what was required on this project, achieving a clean design and features such as a blocked process queue, piping, kill, and a simple filesystem. This was my favourite coursework so far. I found it very interesting to learn about and implement the things that we take for granted as programmers.

For the last two years, I have been working on a very ambitious game. The game is a top down sandbox with multiplayer support. I’m aiming towards a city-based game, where players can wander around a procedurally generated city. One of the main reasons I started creating this game is to learn about multiplayer networking at a low level - client-side prediction, server-side reconcilliation, cheat preventation, and reducing the visual effect of latency.

It’s very hard to debug a crash when no stack traces are printed. It becomes a case of manually trying to find the error.

GET /foo/bar/
Doing something useful
Error: Expected } near ;

ES6 promises doesn’t seem to offer the functionality to change this, and bluebird has on[Possibly]UnhandledRejection, which can only be used if you don’t add a .catch() case to the promise. There is no global callback for a rejection unless it’s unhandled. To workaround this, we’re going to need to override the method which runs the callbacks. This is a little hacky, and relies on the library not changing - but it’s better than swallowing errors.

First, if you haven’t already, install Bluebird.

npm install --save bluebird

Next, make a file somewhere (perhaps called bluebird.js) with this as its contents:

const Promise = require('bluebird')

// Throw errors in promises rather than calling reject()
// Makes debugging A LOT easier
Promise.prototype._rejectCallback_old = Promise.prototype._rejectCallback
Promise.prototype._rejectCallback =
    function(reason, synchronous, ignoreNonErrorWarnings) {
        if (reason.stack) {
            throw reasong
        } else {
            this._rejectCallback_old(reason, synchronous, ignoreNonErrorWarnings)

module.exports = Promise

Alternatively you could just print reason.stack if it exists, however I prefer a full crash whilst debugging. You could also make it possible for promises to declare whether they should throw errors - similar to the throw keyword in Java - and print out the stack rather than crashing in that case.

I created a very short C++ snippet to accumulate a series of Mats into a single Mat strip. It works like acc = acc + m - a new mat is added to the accumulator each time, then stored in the accumulator again.

Example output
Example output
#pragma once
#include <opencv2/opencv.hpp>
#include <opencv2/core/core.hpp>
#include <opencv2/imgcodecs.hpp>
#include <assert.h>

using namespace cv;

class MatStrip
    Mat current;
    float scale;

    MatStrip(Mat start, float scale=0.3f):
        resize(start, current, Size(start.cols * scale, start.rows * scale), 1.0, 1.0, INTER_CUBIC);

    void add(const Mat &in_o)
        Mat in;
        resize(in_o, in, Size(in_o.cols * scale, in_o.rows * scale), 1.0, 1.0, INTER_CUBIC);

        assert(in.type() == current.type());
        Size sz1 = current.size();
        Size sz2 = in.size();
        Mat im3(sz1.height, sz1.width+sz2.width, current.type());
        Mat left(im3, Rect(0, 0, sz1.width, sz1.height));
        Mat right(im3, Rect(sz1.width, 0, sz2.width, sz2.height));
        current = im3;

Usecase: shells dropping in sync with firing, fake bullets, etc

You must use a particle emitter to create particles, however this doesn’t mean it’s impossible to create single particles on command. You can create a particle emitter which simply adds particles from a queue to the system

#pragma once
#include <SFML/Graphics.hpp>
#include <Thor/Math.hpp>
#include <Thor/Graphics.hpp>
#include <Thor/Particles.hpp>

namespace sfext {

class SingleParticleEmitter
    std::vector<thor::Particle> *particles;
    SingleParticleEmitter(const SingleParticleEmitter& that);
    void operator() (thor::EmissionInterface& system, sf::Time dt);

    void push(thor::Particle particle);
    void push(sf::Vector2f position, sf::Vector2f velocity, float lifetime, float rot=0, float rotsp=0);

}; // end namesapce sfext

The above allows you to use the push functions to emit particles. Here is an example of it in use:

SingleParticleEmitter single_emitter;
thor::ParticleSystem particle_system;

// When you need to emit a shell:

single_emitter.push(origin, velocity, 1.0f);
// lifetime of the particle in seconds --^

Here is the cpp file:

#include "singleparticleemitter.hpp"

using namespace sfext;

    particles = new std::vector<thor::Particle>();

SingleParticleEmitter::SingleParticleEmitter(const SingleParticleEmitter& that)
    particles = that.particles;

void SingleParticleEmitter::operator() (thor::EmissionInterface& system, sf::Time dt)
    for (auto particle : *particles) {

void SingleParticleEmitter::push(thor::Particle particle)

void SingleParticleEmitter::push(sf::Vector2f position, sf::Vector2f velocity, float lifetime, float rot, float rotsp)
    thor::Particle particle(sf::seconds(lifetime));
    particle.position = position;
    particle.velocity = velocity;
    particle.rotation = rot;
    particle.rotationSpeed = rotsp;
    particle.scale = sf::Vector2f(1.f, 1.f);
    particle.color = sf::Color::White;
    particle.textureIndex = 0u;

Now that Github supports unlimited private repos in all plans, you might as well keep things all together (although definitely have backups elsewhere incase Github is DDOS’d again, dies or goes evil). Simply change “rubenwardy” to your username and “XXXX” to a personal access token with “repo” checked. Also make sure you have an SSH key for Github.

# Clone from bitbucket
git clone git@github.com:samkuehn/bitbucket-backup.git
mkdir bk
cd bitbucket-backup
./bitbucket-backup -u rubenwardy --mirror -l ../bk

# Upload to GitHub
cd ../bk
for D in *;
    echo $D
    cd $D
    data="{\"name\": \"$D\", \"auto_init\": false, \"private\": true }"
    curl -i -H 'Authorization: token XXXX' -d "$data" https://api.github.com/user/repos
    git push --mirror git@github.com:rubenwardy/$D.git
    cd ../
cd ../

I use a dual monitor setup. For each monitor I have a panel, and each panel has a whisker menu. I found that the favourites section of each of these panels is not synchronised. To fix this, I wrote a simple script.

First, you have to decide which whisker config to keep.

$ cd ~/.config/xfce4/panel/
$ ls
whiskermenu-1.rc  whiskermenu-9.rc

The favourites menu is stored at the top of each file, like this:

$ head -n1 whiskermenu-1.rc

Find the one you want to keep. From this point on, replace whiskermenu-1.rc with the config you want to keep and whiskermenu-9.rc with the one you want to ditch.

The script is as simple as this:

#! /bin/bash

rm -f ~/.config/xfce4/panel/whiskermenu-9.rc
cp ~/.config/xfce4/panel/whiskermenu-1.rc ~/.config/xfce4/panel/whiskermenu-9.rc
xfce4-panel -r

If you save that to /usr/local/bin/syncwhisker, then you can use “syncwhisker” in the terminal to keep your menus the same.