Recently, I was working on an Electron app and I had to write a module for inter-process communication (IPC), namely between the main process ("backend") and the renderer ("browser window" or "frontend"). This is a pretty common concern for Electron developers - they often need to perform some logic in the main process and report the result to the renderer.

As a huge fan of JetBrains IDEs, I always try to write code that can be easily interpreted by my IDE, giving me access to auto-completion, type-checking, and many other goodies. I also like to write code that is easy to read and easy to maintain. In this article, I'll talk about how I achieved both of these things for Electron IPC.

A couple of notes before we start:

1. I'll explain how one would implement that solution step-by-step. If you want quick answers, you should scroll to the end of the article.
2. I'll drop some obvious constructs in my code examples to make them more concise. It's up to you to adapt said examples to your application.
3. I'll be talking about IPC with a single main process and a single renderer. It's up to you to extend this strategy to multiple renderers.
4. I'll focus on asynchronous logic using promises. It shouldn't be hard to make this strategy work for synchronous requests.

Problem statement

Let's take a look at the naive way of handling IPC in Electron. Consider the two code snippets below.

// In your main process (e.g. main.js)
const {ipcMain} = require('electron');
const backendData  = {foo: 42, bar: 322};

ipcMain.on('get-backend-value', (event, key) => {
    console.log(`Main process receved ${key}.`); // prints "foo"
    const value = backendData[key];
    event.sender.send('response', value);
});

// In your renderer (e.g. <script> tag inside index.html)
const {ipcRenderer} = require('electron');

ipcRenderer.on('response', (event, value) => {
    console.log(`Renderer received ${value}.`); // prints "42"
});
ipcRenderer.send('get-backend-value', 'foo');

As you can see, we had to write quite a lot of code to exchange a couple of simple messages. Additionally, we had to write some IPC logic for both the main process and the renderer, which feels like code duplication (or logic duplication, if you like). If we'd add different types of messages and requests, this code would quickly become a nightmare to maintain. Our goal is to produce a simple solution that solves all of these problems.

Solution overview

Let's start by looking at the brief overview of our solution. This is our desired outcome (compressed for clarity):

// Main process
const IpcModule = require('./IpcModule');
const backendData  = {foo: 42, bar: 322};
const ipc = new IpcModule({mode: 'server', backendData});

// This part is identical for BOTH main process and renderer:
ipc.init();
ipc.getBackendValue({key: 'foo'})
    .then(value => console.log(`Renderer received ${value}.`)); // prints "42"

// Renderer
const IpcModule = require('./IpcModule');
const ipc = new IpcModule({mode: 'client'});

// This part is identical for BOTH main process and renderer:
ipc.init();
ipc.getBackendValue({key: 'foo'})
    .then(value => console.log(`Renderer received ${value}.`)); // prints "42"

// IpcModule.js (our class)
class IpcModule {
    /**
     * @param {object} data
     * @param {string} data.mode
     * @param {object} [data.backendData]
     */
    constructor(data) {
        this.mode = data.mode;
        if (this.mode === 'server') this.backendData = data.backendData;
    }
    
    // Some magic functions, explained later
    init() {/*...*/} 
    _prepareActiveMethod(data) {/*...*/} 
    _preparePassiveMethod(data) {/*...*/} 
    
    /**
     * @alias IpcModule.getBackendValue
     * @param {object} data
     * @param {string} data.key
     */
    server_getBackendValue(data) {
        console.log(`Main process receved ${key}.`); // prints "foo"
        return this.backendData[data.key];
    }
}
module.exports = IpcModule;

That might look like a lot of code, but let's think about which parts we actually need to define for our key-value exchange. It turns out there are only two:

// From main process and renderer:
ipc.getBackendValue({key: 'foo'})
    .then(value => console.log(`Renderer received ${value}.`)); // prints "42"

// From IpcModule.js:
server_getBackendValue(data) {
    console.log(`Main process receved ${key}.`); // prints "foo"
    return this.backendData[data.key];
}

That's right! To define a new inter-process exchange, we just need to add a new method to IpcModule class. Then, we can call this method directly - from both the main process and renderer code, and the result we'll get will be the same! This approach avoids any possible code duplication.

Note that we don't even need to use electron IPC functions to define our new method. This is possible thanks to the "magic" functions init(), _prepareActiveMethod() and _preparePassiveMethod(), which will be described below.

Another useful outcome is that this code can be parsed by IntelliSense, thanks to JSDoc comments. This means that you can type ipc. in your renderer code and getBackendValue method will come up as one of the auto-complete options. Don't be surprised that the method we use, getBackendValue, has a different name to the method we defined, server_getBackendValue. This is intentional and will also be explained later.

Solution implementation

Dependencies

The only package we'll need is electorn-promise-ipc. As the name implies, it gives a nice promise-based abstraction for IPC in Electron. With this package, our naive IPC code becomes this:

// Main process
const promiseIpc = require('electron-promise-ipc');
const backendData  = {foo: 42, bar: 322};
 
promiseIpc.on('get-backend-value', key => {
   console.log(`Main process received ${key}`); // prints "foo"
   return backendData[key];
});

// Renderer
const promiseIpc = require('electron-promise-ipc');

promiseIpc.send('get-backend-value', 'foo')
    .then(arg => console.log(`Renderer received ${value}.`)); // prints "42"

This is definitely a huge improvement over the naive approach, but there is still much left to do.

Separate class for IPC (attempt #1)

Now we're going to create a new ES6 class that's going to hold all of our IPC logic. As you've seen in the overview, we want to include this file in both the main process and the renderer code to avoid code duplication.

We'll try to mimic what we had in the solution overview section, but you will notice that it looks much closer to the code from the previous section:

// IpcModule.js (attempt #1)
const promiseIpc = require('electron-promise-ipc');

class IpcModule {
    constructor(data) {
        this.mode = data.mode;
        if (this.mode === 'server') this.backendData = data.backendData;
    }
    
    init() {
        if (this.mode === 'server') {
            promiseIpc.on('get-backend-value', data => {
               console.log(`Main process received ${data.key}`); // prints "foo"
               return this.backendData[key];
            });
        }
    }

    getBackendValue(data) {
        if (this.mode === 'server') {
            return Promise.resolve(this.backendData[data.key]);
        } else {
            // this.mode === 'client'
            return promiseIpc.send('get-backend-value', data);
        }
    }
}
module.exports = IpcModule;

// After we initialize 'ipc = new IpcModule(...)', we can use
// this method in BOTH the main process and renderer code:
ipc.getBackendValue({key: 'foo'})
    .then(value => console.log(`Renderer received ${value}.`)); // prints "42"

Sure, this class can do what we need, but the code looks very dirty - there are a lot of if statements and our business logic is spread between init() and getBackendValue().

A better class for IPC (attempt #2)

We will rewrite the class from attempt #1 to remove some of the code duplication. First of all, we'll add a prefix to our method name. The prefix is either server_ or client_.

If the prefix is server_, we know that the body of the method should be executed in the main process. For example, let's call our method server_getCpuUsage(). If you call ipc.server_getCpuUsage() from the main process, we just run the method as-is. If you call ipc.server_getCpuUsage() from the renderer, we make a request to the main process to send us the result. This logic is reversed if the prefix is client_.

To make our method call look the same in both main process and renderer, we'll introduce a method wrapper. That is, if the original function was called client_getCpuUsage() or server_getCpuUsage, we create a wrapper method called just getCpuUsage(). This wrapper method will also incorporate the logic described in the paragraph above.

Putting all of this together:

// IpcModule.js (attempt #2)
class IpcModule {
    constructor(data) {/*...*/} // same as before
    
    init() {
        const method = 'server_getBackendValue';
        
        // Extract prefix and prepare alias name
        let methodMode;
        if (method.startsWith('server_') methodMode = 'server';
        if (method.startsWith('client_') methodMode = 'client';
        let alias = method.replace(`${methodMode}_`, '');
        
        if (methodMode === this.mode) { // Can execute logic locally
        
            // Create a simple alias method
            this[alias] = this[method];
            // Create a listener for remote requests
            promiseIpc.on(alias, this[method].bind(this));
            
        } else { // Need to make a remote request
        
            // Create a wrapper method that makes a request
            this[alias] = function() {
                return promiseIpc.send(alias, ...arguments);
            };
            
        }
    }

    server_getBackendValue(data) {
        console.log(`Main process receved ${key}.`); // prints "foo"
        return this.backendData[data.key];
    }
}
module.exports = IpcModule;

Okay, we got rid of code duplicaiton and the solution is already looking quite good. The final thing we need to address is how we get the method names inside init(): Right now we have a hardcoded constant called method - we can definitely better than this.

Best class for IPC (final attempt)

To get the list of method names automatically, we'll use the Object.getOwnPropertyNames() function (check this MDN link for more info). We'll also add a way to check that we're not accidentally redefining the same alias twice, and we'll extract alias-creation into separate functions.

Finally, we'll add a lot of JSDoc comments to make sure our IDE can understand what's going on. To make sure our IDE picks up the new alias method, we'll add @alias IpcModule.getBackendValue to our server_getBackendValue() definition.

The final code for the IpcModule class can be seen below. It should be fully functional.

// IpcModule.js (final)
const promiseIpc = require('electron-promise-ipc');

class IpcModule {
    /**
     * @param {object} data
     * @param {string} data.mode
     * @param {object} [data.backendData]
     */
    constructor(data) {
        this.mode = data.mode;
        this.otherMode = data.mode === 'server' ? 'client' : 'server';
        if (this.mode === 'server') this.backendData = data.backendData;
    }

    init() {
        const takenNames = {};
        const methodNames = Object.getOwnPropertyNames(IpcModule.prototype);
        for (const methodName of methodNames) {
            let methodMode;

            // Determine whether we even need to prepare this method
            if (methodName.startsWith(`${this.mode}_`)) methodMode = this.mode;
            else if (methodName.startsWith(`${this.otherMode}_`)) methodMode = this.otherMode;
            else continue;

            // Check that we're not redefining a method multiple times
            const alias = methodName.replace(`${methodMode}_`, '');
            if (takenNames[alias])
                throw new Error(`Tried to redefine method ${alias} in IpcModule!`);
            takenNames[alias] = true;

            // Define method as passive or active depending on the mode
            const data = {methodName, alias};
            if (methodMode === this.mode) this._prepareActiveMethod(data);
            else this._preparePassiveMethod(data);
        }
    }

    /**
     * @param {object} data
     * @param {string} data.methodName
     * @param {string} data.alias
     */
    _prepareActiveMethod(data) {
        this[data.alias] = this[data.methodName];
        promiseIpc.on(data.alias, this[data.methodName].bind(this));
    }

    /**
     * @param {object} data
     * @param {string} data.alias
     */
    _preparePassiveMethod(data) {
        this[data.alias] = function () {
            return promiseIpc.send(data.alias, ...arguments);
        };
    }

    /**
     * @alias IpcModule.getBackendValue
     * @param {object} data
     * @param {string} data.key
     */
    server_getBackendValue(data) {
        console.log(`Main process receved ${key}.`); // prints "foo"
        return this.backendData[data.key];
    }
}

module.exports = IpcModule;

This class can now be used the same way it was used in the Solution Overview section. It's worth noting that you could replace prefixes with decorators if you wanted. In my case, prefixes worked just fine since they didn't require any additional compilation.

In the summer of 2017 I had the pleasure of spending several months as a research intern at UCL's Surgical Robot Vision (SRV) lab. I was primarily working with HoloLens, developing a system for tracking different surgical tools and displaying relevant information as holograms.

Almost a year has passed since I joined SRV for a two month internship. It's true that I've since forgotten some minor things, but there are several important lessons I have learned back then that are still with me now. Truth be told, I was planning to publish this article shortly after my internship has ended (pic below) but, for some reason, I felt like it would be incomplete - now I have finally understood why.

What I've been waiting for...

As I said above, something just didn't feel right before. A couple of days ago I finished a project involving autonomous drone exploration using ROS, and it dawned on me - if only I'd use ROS more during my time at SRV, my development speed would be much higher.

A year ago, back when I joined SRV, I had very little robotics experience. During my first year in UCL I've taken a class called COMP105P Robotics Programming. This class didn't even mention ROS, which was definitely a huge oversight since ROS is a crucial part of robotics these days. In UCL's defense, the timeline for that class had to be rushed because of the exam period, but I still wish they would include ROS in some shape or form.

Caltech, on the other hand, has a very strong robotics track with amazing classes like ME/CS 133 Robotics. This year they offered an new class called CS/EE/ME 134 Autonomy. As the name implies, it focused on autonomous systems, mainly autonomous exploration and SLAM using different robots. The practical part of the class relied heavily on ROS, with a fair bit of handholding from the TAs during labs.

This soft introduction to ROS helped me understand just how powerful (and, in a sense, simple) ROS is. Thinking about the final product of my SRV project, I can see exactly where ROS would make my life easier - most of the time it's about standardadising communication between, say, HoloLens, and the ultrasound machine.

Considering SRV literally has the word "Robot" in its name, it should be obvious that people there use ROS all the time. Back when I was just starting my project, my colleagues suggested I use ROS. I quickly brushed off the idea because the learning curve was a bit too steep. Additionally, I had to use Windows for HoloLens development and ROS doesn't play well with Windows.

This wasn't a bad decision overall: I still ended up building a decent proof-of-concept system even without ROS. That said, if I were to redo the whole project, I would definitely use a different approach. I only needed Windows on my development machine to compile my HoloLens application, so it wasn't a runtime dependency. This meant that, potentially, I could do HoloLens development on Windows but then switch to Linux to get access to all ROS features. This is the main change I would make if back then I had the experience I have now.

Mistakes made and lessons learned

Note: Don't get the wrong idea - although I start the article by reflecting on my mistakes, my experience with SRV was dominantly positive. In fact, I had a blast working with them! Check out the end of the article for my thoughts on this.

First of all, I must say that the proof-of-concept system I built ended up working as expected. This video shows one of the final prototypes in action. You can notice that the hologram for the ultrasound probe (green mesh) doesn't perfectly align with the actual probe - I initially used a wrong transform in the absolute orentation algorithm. I fixed it later, but I didn't shoot any videos after the fix was made, which leads us to my first mistake.

Mistake #1: Not enough videos

As the saying goes, a picture is worth a thousand words. Extrapolating to videos, your average PAL stream shows you 25 thousand words per second. In my case, shooting more videos of the final setup would not only make it easier to publicize the project, but also help my colleagues reproduce my experimental setup.

This might sound silly but making video instructions actually makes a huge difference. In my case, the setup was using a Python server, OptiTrack Motive software, infrared cameras, ultrasound machine and appropriate software, Unity3d, HoloLens-specific Visual Studio plugins and some other minor tools. During development, I've become familiar enough with these tools to setup the whole system with ease - but it is unreasonable to expect other people to learn the whole pipeline just to test a small component of my system (say, IR tracking).

Producing more videos showing the whole setup in action and explaining how to setup each separate component (using some voiceover) would definitely make things clearer. Unfortunately, I didn't have the time to do that, which leads us up to my second mistake.

Mistake #2: Hard to reproduce

While it's true that I was learning some new things on my way, I wouldn't say I wrote bad code. The code I wrote was reasonably easy to follow and I tried to clarify any ambigious points in the README. The issue was that there was a lot of code - not only that, but it was also split between a Python (backend) codebase and a C# (HoloLens) codebase.

Near the end of my internship, I decided to use my last week primarily to fix bugs and increase the quality of codebase in general. While this wasn't a bad idea, I had my priorities wrong - I should've spent more time writing documentation instead. I learnt the hard way that mediocre code with good, detailed documentation can be better than perfect, poorly-documented code.

Despite the little time I dedicated to documentation, I still ended up writing a very long README file describing everything in detail. Sadly, quantity doesn't imply quality and there were still things in the README that were ambigious (mostly related to experimental setup). I believe that, if I would spend more time bouncing documentation off my colleagues, I'd be able to make things more clear.

I still don't have a universal solution to writing detailed documentation for complex systems. That said, in my particular case I could avoid some of the complexity by not reinventing the wheel and using ROS, as I mentioned in the beginning of this article.

Mistake #3: Not enough expiremental data

With the help of my supervisor I ended up producing a short paper for the SPIE 2018 Medical Imaging conference. That paper wasn't particularly good because it didn't display much experimental data - because I didn't record much data in the first place.

I was too focused on improving the prototype that I completely forgot to measure quantitative things like hologram drift, lag in ultrasound imagery, error in hologram placement and so on. I didn't really have any research-related experience before SRV so I didn't realise how important data is before I actually begun writing the paper.

Another important lesson was that just recording data isn't enough - you must also make sure to store it in a safe place. I used a MacBook provided by SRV for my work and stored all of the data on it. After I left, the laptop was repurposed for other projects, and the need for my data didn't come up until several months later. At that point, tracking down the data proved to be a bit of a challenge, which could easily be avoided if I'd just store the data online.

Conclusion on my mistakes

Some of these mistakes might seem silly - they certainly do to me when I re-read the draft of this article. Nevertheless, those are issues that I have actually experienced and I think it's important to reflect on them. After all, this is exactly what internships are for.

Working at SRV

The list of mistakes above is the result of me reflecting on my SRV experience for a year or so. During the actual internship I had an amazing time - not only did I get to play with cool, expensive hardware (see pic below) but I was also surrounded with friendly, smart and helpful people.

As I said earlier, when I joined SRV I hardly had any research experience. I was also not too familiar with robotics and computer vision. Much to my surprise, that wasn't an issue most of the time - I got so much support from SRV members that I was never stuck on some particular problem. Apart from helping me out with my project, they were happy to answer my questions about their PhD and postdoc experience, as well as give me academic advice.

Now I'd like to take some time to thank Dan Stoyanov, my supervisor and the head of SRV, for inviting me to work with them and guiding me in my work. I'd also like to thank Mirek for introducing me to Dan and answering numerous questions I had during my internship. Thanks to Francisco for explaining computer vision and ultrasound concepts to me, to Francois for helping out with hardware and video conversion, to Evangelos for giving me a Quaternions 101 lecture and to George for giving me a hand with 3D printing. Huge thanks to Neil for helping out with the paper, it would be impossible without him!

I'll wrap up this article with a picture of a $2 million da Vinci robot that I had a chance to play with. I had a very good time interning at SRV and I hope I'll get a chance to work with them again in the future.

Recently, I finished developing a simple framework for autonomous exploration of 3D environments using drones in ROS. It was my final project for Caltech's ME 134 Autonomy class. I was using the move_base navigation stack and I ran into a weird issue where my local costmap would correctly display obstacles as they appear, but will not get cleared once the obstacles move out of drone's field of view. In this article I'll talk about how I fixed this issue - hopefully this will help someone out there facing the same issue.

Problem statement

This problem is a bit hard to explain so I'm going to include some animations to illustrate the issue. It's important that you understand exactly what my issue was - there are many different reasons why certain parts of the move_base stack can fail and I don't want you to waste time reading about my solution if it isn't relevant to you.

The drone and local costmap

The type of sensors you use for your navigation stack matters a lot - in my project, I used a simulated drone with a Kinect attached to it (from hector_quadrotor package). Kinect published depth information as point cloud, i.e. message of type sensor_msgs/PointCloud2. Below you can see how the drone and Kinect depth data looked in rviz. Even if you're using LaserScan instead of a point cloud, this article might still be relevant to you.

Desired result

The animation below shows the result we want to get. The white square around the drone represents the local costmap, which is populated using the data from the depth cloud. Note that the costmap gets cleared when the obstacle is no longer in the way.

Incorrect costmap behaviour

Now the actual issue I encountered: note how on the animation below the costmap does not get cleared once the drone flies away from the wall. This is a big problem because it gets in the way of the local cost planner, which can fail because it has an incorrect costmap.

The solution

There are several reasons why your costmap might not be updated. I'm going to suggest several steps you can take to get it working.

Step 1: Getting the obstacle height right

When running your navigation stack (i.e. move_base) you might see the following warning in the console output:

[WARN] [1529117350.880168708, 781.744000000]: The origin for the
sensor at (0.05, -0.02, 2.42) is out of map bounds. So, the costmap
cannot raytrace for it.

One possible (trivial) reason could be that you're using an incorrect transform for your sensor - I will assume you're using the correct transform. Now, the actual issue could be that there is some displacement between your sensor and the costmap in the Z-axis. Since I had a drone, I had to make it hover at the altitude of 1 metre above ground. This meant that the costmap has to be generated at approximately the same level. I had to make the following changes to my costmap_common_params.yaml (GitHub link if you want to see the full config):

max_obstacle_height: 1.2
# ...
map_type: voxel
obstacle_layer:
  enabled: true
  # ...
  origin_z: 0.8
  z_resolution: 0.4
  z_voxels: 1
  publish_voxel_map: false
  observation_sources: depth
  depth:
    data_type: PointCloud2
    topic: /camera/depth/points
    marking: true
    clearing: true
    min_obstacle_height: 0.8
    max_obstacle_height: 1.2
# ...

Note that now the Z-origin of the obstacle layer is at 0.8 metres, it has a height of 1 unit cell and the size of a cell is 0.4 metres. Putting everything together, I essentially have a 2D costmap that considers obstacles of height between 0.8 and 1.2 metres. The Kinect sensor on my drone was always at around 1m altitude so the costmap was always able to raytrace it.

Aside: Make sure your obstacle layer is a part of the local costmap. For example, in my local_costmap_params.yaml (GitHub link) I have the following specified:

local_costmap:
  # ...
  static_map: false
  rolling_window: true
  # ...
  plugins:
    - {name: obstacle_layer,      type: "costmap_2d::VoxelLayer"}
    - {name: inflation_layer,     type: "costmap_2d::InflationLayer"}

Step 2: Clearing the costmap using LaserScan

Following instructions above might've made the warning disappear, but chances are your costmap still doesn't get cleared correctly.

In the previous step we have specified marking: true and clearing: true for our depth point cloud data source. Marking essentially means using the point cloud to add obstacles to the costmap. Clearing means using point cloud data to remove obstacles from the costmap. It's apparent that clearing functionality isn't working.

A possible reason could be that the costmap_2d doesn't know that it should interpret "no points" as "free space". There is actually a way to enable this logic, but it only works for LaserScan data, so we'll need to convert our PointCloud2 into LaserScan. We can use pointcloud_to_laserscan package to carry out this conversion: install it using sudo apt install ros-kinetic-pointcloud-to-laserscan (or your ROS version equivalent) and run the conversion node as follows:

<launch>
  <node pkg="pointcloud_to_laserscan" type="pointcloud_to_laserscan_node" name="pointcloud_to_laserscan">
    <!-- See all params at http://wiki.ros.org/pointcloud_to_laserscan -->
      
    <!-- Min and max height to sample from depth data - these values worked for my drone -->
    <param name="min_height" value="0.3"/>
    <param name="max_height" value="1.7"/>
      
    <!-- Min and max range range of generated laser scan - set this to match your depth sensor -->
    <param name="range_min" value="0.2"/>
    <param name="range_max" value="4.0"/>
    
    <!-- Frame of your depth sensor -->
    <param name="target_frame" value="camera_link"/>

    <!-- Topic from which to read PointCloud2 -->
    <remap from="cloud_in" to="/camea/depth/points"/>
    
    <!-- Topic to which LaserScan will be published -->
    <remap from="scan" to="/scan"/>
  </node>
</launch>

Once you've specified the correct settings, you can visualise your PointCloud2 and LaserScan in rviz. You should get something that looks like the animation below. Note the red LaserScan points generated from the depth data.

Finally, you need to tweak your obstacle layer observation_sources to use the new laser scan data, the example is shown below. The most important part is the inf_is_valid: true. This tells costmap_2d to treat "no reading" from laser scan data as free space, which is exactly what we want. This is possible because pointcloud_to_laserscan_node we enabled before by default publishes +inf values when it doesn't see any depth cloud data for a particular angle.

# ...
obstacle_layer:
  # ...
  observation_sources: scan
  scan:
    data_type: LaserScan
    topic: scan # Your LaserScan topic
    marking: true
    clearing: true
    inf_is_valid: true # This parameter does the trick!
    min_obstacle_height: 0.8
    max_obstacle_height: 1.2
# ...

Step 3: Recovery behaviours

If you've done step 1 and 2 correctly, your problems should be fixed by now. Nevertheless it's worth specifying some recovery behaviours for your navigation planners. This is also useful if (for some weird reason) you can't do step 2 and must rely on PointCloud2 data only.

Recovery behaviours are triggered as a last resort when your local planner fails to generate a local plan. Since we're concerned with clearing the local costmap, we'll add this logic to our recovery behaviours. In my case, I added the following to my move_base_params.yaml (GitHub link):

# ...
recovery_behaviors:
  - name: 'conservative_reset'
    type: 'clear_costmap_recovery/ClearCostmapRecovery'
  - name: 'aggressive_reset'
    type: 'clear_costmap_recovery/ClearCostmapRecovery'
conservative_reset:
  reset_distance: 0.1
  layer_names: ['obstacle_layer']
aggressive_reset:
  reset_distance: 0.0
  layer_names: ['obstacle_layer']

It is very important to specify the obstacle_layer as one of the layer_names or the costmap won't get reset correctly. You might wanna increase reset_distance for conservative_reset if you don't wanna clear the full costmap.

Around a month ago I switched to using Vim full-time. I've already been using Vim for all of my command-line editing, but now I've enabled Vim emulation in all of the other editors I use (namely those coming from JetBrains).

To keep my Vim skills versatile, my Vim configuration uses vanilla key mappings. That said, I've still made a lot of quality-of-life adjustments to the config, including colour scheme tweaks. One of such tweaks is changing the style of the active pane to make it more obvious - which is also the focus of this article.

Getting it to work

There are several steps needed to get the whole thing working. Jump to the end of this article if you want to see the final code.

Initial setup

For the sake of this article, I will use red for my colour column (from here on I will call it just "column"). To make screenshots more compact I will use values 20 and 40. Let's assume I start off with this .vimrc:

" Make cc red
highlight ColorColumn ctermbg=Red

" Set global cc default to 20
set colorcolumn=20

" Set cc in Markdown files to 40
autocmd FileType markdown setlocal colorcolumn=40

Now, if I open files config.ini (left pane) and text.md (right pane) I will get this:

Note that the column in the left pane is draw at position 20, and in the right column and position 40.

Problem statement

We want the column to only appear in the active window. Here's the result we want to get:

Naive solution (that doesn't work)

A naive solution, that uses only autocmd, could look like this:

augroup BgHighlight
    autocmd!
    autocmd WinEnter * set colorcolumn=40
    autocmd WinLeave * set colorcolumn=0
augroup END

This will indeed only show the colour column in the active window, but there is one drawback - the position at which it is drawn is always 40. This defeats the purpose of using different colour column settings for different file types. We can do better!

Better solution

Instead of using one-liners with autocmd Win<Enter/Leave>, let's define some functions:

function! OnWinEnter()
    " We will put some code here soon
endfunction
function! OnWinLeave()
    " We will put some code here soon
endfunction
augroup BgHighlight
    autocmd!
    autocmd WinEnter * call OnWinEnter()
    autocmd WinLeave * call OnWinLeave()
augroup END

By now, you have probably guessed what we will do: We will hide the colour column in OnWinLeave() and reveal it in OnWinEnter(). Doing this is pretty straight-forward, but there are some things we have to consider.

We will "remember" the initial colorcolumn setting of a window using a window-scoped variable. Window-scoped variables are created by prefixing their names with w: (check out Vim variable scoping for more info). To remember the value, we'll need to execute the let w:initial_cc=&colorcolumn command at some point.

The question is, where do we put it? There's a catch: If we put it inside OnWinEnter(), we'll actually remember the colorcolumn of the window that we're leaving. This makes the logic somewhat complicated, so, instead, we're gonna put it inside OnWinLeave(). We're also gonna add some code to hide the colour column (since the window we're leaving will become inactive):

function! OnWinLeave()
    " Define w:initial_cc if it isn't already defined
    if !exists('w:initial_cc')
        let w:initial_cc=&colorcolumn
    endif

    " Hide colour column
    let &colorcolumn = 0
endfunction

Now, variable w:initial_cc holds the colorcolumn value of the window to whose scope it belongs. All we have left to do is use this value in OnWinEnter():

function! OnWinEnter()
    " Use w:initial_cc if it's defined
    " (default value will be used otherwise)
    if exists('w:initial_cc')
        let &colorcolumn = w:initial_cc
    endif
endfunction

And we're done! Putting everything into our Vim config we'll get the desired behaviour. I know that some of my explanations lack detail - there are just too many small things to explain here. If you want to understand why (and how) this works, try implementing it yourself.

Final code

Below you can see the full Vimscript snippet that you can put into your .vimrc.json. Note that this technique can be applied to other Vim parameters too - go make something cool with it!

" Global default
set colorcolumn=80

" Specific length for different filetypes
autocmd FileType javascript setlocal colorcolumn=120

" Logic for entering/leaving a pane
function! OnWinEnter()
    if exists('w:initial_cc')
        let &colorcolumn = w:initial_cc
    endif
endfunction
function! OnWinLeave()
    if !exists('w:initial_cc')
        let w:initial_cc=&colorcolumn
    endif
    let &colorcolumn = 0
endfunction
augroup BgHighlight
    autocmd!
    autocmd WinEnter * call OnWinEnter()
    autocmd WinLeave * call OnWinLeave()
augroup END

I was hoping to write at least one article every month, but as you can see this is my first post since January. I sometimes find it hard to decide which ideas or projects I want to write about, which could explain this 4-month gap.

Although I didn't post anything in that time period, I've been working on some things, including several open source projects. In this post, I'm going to tell you about a few of them: Von, Rammy and Trek* (click to jump to relevant section).

Von

Around a year ago I wrote Blitz, an opinionated static site generator. That project was doomed from the start for several significant reasons. One of them was that I contradicted the motto of the project, "dead simple static site generation", by trying to support too many features and making the logic too complicated. Needless to say, I quickly abandoned that project.

This time I was much less ambitious - I tried to make a command line tool that generates a single page gallery based on the images you provide. I also decided that this tool should require minimum-to-none configuration and only generate a single .html file. This is how Von was born.

You can always read more about how Von works on its GitHub page, but I think this diagram sums it up pretty well:

You pick a folder on your computer that has some images in it, open that folder in terminal and simply type von... And, voila, you can see your new gallery in the index.html file. The default (and only template at the moment) is responsive and supports lazy-loading by default, but you can always define a custom Pug template.

It is true that this tool is pretty niche. At the same time, Von is so easy to use that you might as well download it and try running it in your Pictures folder. You might get some pretty interesting results, having spent less than 20 seconds on the whole process. Personally, I use Von for a self-hosted Tumblr-like gallery.

Rammy

I have recently switched to Vim as my main editor - for small projects, I use NeoVim; for larger projects, I use JetBrains IDEs with Vim emulation. Thanks to this, I've significantly increased the speed at which I can manipulate text and, as a side effect, I've become incredibly efficient at typing up my notes in $\LaTeX$.

This might sound crazy, but I now do all of my note-taking and document production in $\LaTeX$ - problem sets, lecture notes, reports, you name it. As such, I found myself often reusing the same templates and code snippets over and over again in my .tex files. After looking around for a while, I decided that none of the existing tools do a well enough job at .tex template management, so I made Rammy.

You can read more about Rammy on its GitHub page. In essence, it lets you define collections of $\LaTeX$ templates and snippets and groups them into Rammy modules. These modules can then be imported into any project or Git repository using the rammy add <module> command. Check out the Quick Example section in the docs to see an example workflow with Rammy.

Rammy is not an incredibly sophisticated tool, but it fulfills its purpose pretty well - it makes setting up new $\LaTeX$ projects a painless process, so you don't need to remember what snippets you need to include to make you documents look nice. Additionally, since Rammy modules can be added to your current project as Git submodules, managing versions and dependencies becomes very straightforward. Check out Rammy modules documentation for more info.

Personally, I'm using Rammy in some shape or form almost every day and I think this tool has some potential.

Trek*

Trek*, or TrekStar (formerly known as Ariadne's Thread), is a project I'm working on with a group of students from Caltech. We're trying to take a brand new approach to automatic route planning. Instead of going for the shortest or quickest path like most route planners today, we're trying to make the route more enjoyable. Our users can specify a bunch of non-trivial preferences, such as the amount of greenery they want to see on their way, and we will generate them a route that best matches these constraints.

This project is still in active development so there isn't much to present at this point. All of the code is publicly available under the Ariadne's Thread GitHub organization.

Wrap up

I know that the descriptions I provided in this post are a bit too brief - you're welcome to check the documentation for each project separately. I feel like the docs already describe everything in detail, and I don't want to repeat myself.

I had to move from London, UK, to Pasadena, CA, USA for a year as a part of a study abroad program. Unfortunately, I couldn't take my battlestation with me so I had to bring one of my old laptops instead. While looking through my old coding projects, I found a couple of nice images and blog posts I wrote. This sparked some memories of how I first got into coding, so here's a short article about it.

Early days

At some point in the past, my dad used to be a programmer and an IT specialist. Although he left the industry before I realised how cool it was, this meant that I had my own PC pretty early in my life. At first, I used to game, a lot (don't judge). Then I slowly picked up some photo manipulation and video editing skills, and eventually some music production. Considering I'm pretty much tone-deaf, the music I made sounded horrible.

Photo manipulation and video editing was a completely different story - I became quite good at it and volunteered to fix "issues" on all of the family photos accumulated over the years. While spending day and night playing with Photoshop, I was also producing tons of video compilations and other slideshows for the whole family.

According to Say's law, "supply creates its own demand". This might not be true in economics but this certainly worked with my family - to this day, I'm still getting requests for videos for different celebrations, weddings, and less festive occasions. When I find myself editing a family video at 3 o'clock in the morning, with several deadlines coming up later same day, I ask myself: "would I have changed anything in the past given a chance?". I still don't know the answer, but it always feels nice when your skills are recognised, no matter how humble they may be.

Surprisingly enough I still remember the exact Photoshop tutorial that made me shift from the "consumer" mindset to the "original content creator" mindset, as silly as it sounds. Unfortunately I couldn't find the actual link (it was a Russian website which no longer exists, I believe) but the tutorial focused on the "Wind" effect, which can you see in step 4 on this page. Learning how to do this got me interested in the things I could do with my PC besides gaming, so I spent some time experimenting. Here are some "works" from 2008:

This might not sound like much - but this is all it took. Here I am, 10 years later, studying Computer Science as an exchange student in California Institute of Technology. One could argue that there many other things that contributed towards my interest in computer science. That is certainly true, but learning how to use Photoshop was the first time I sat down and thought:

Damn. Computers are powerful.

This marked the start of my career as a 3d artist, graphic designer, music producer, video editor, photographer, author of numerous mods for numerous games and so on. Thinking back, I never produced anything particularly good but it was all useful experience - it helped me realise just how many things there are that you can do with a computer.

You would expect that I would stumble upon the concept of "programming" by this time, but somehow I managed to remain oblivious to the fact that you can actually produce your own programs. This is especially surprising if you consider the fact that I successfully made several game mods that involved using scripts written by others, but I never wrote anything myself. If I remember correctly, the first thing I wrote that at least remotely resembled "code" were ActionScript snippets for Macromedia Flash. Back then, I couldn't understand how a Flash scene interacts with ActionScript so this experience didn't leave any particular impression on me.

Before we dive into the next section, I'd like to share a picture of my cat. The timestamp suggests that it was taken in 2012, which means she's 7 years old already. Time flies.

Web design

The first "real" coding experience came in middle school. I can't recall exactly if it was grade 6 or 7. As a part of our IT education curriculum, we had to make simple portfolio websites. This was the first exposure I had to HTML and CSS. Before that, I never really thought about how the two worked together. The moment I created my first page and styled it with CSS, I clicked - the next couple of months, I'll spend several days a week making websites, and after that I'll code for several hours almost every day.

My IT teacher at the time was Svetlana Borisovna. She also taught my older brother (who went to the same school), covering calculus lessons and homeroom. The reason I'm bringing this up is because she actually let me teach an IT class once - after she saw my progress, she decided it would be a good idea to let me share what I've learnt with my classmates. If memory serves me right, they weren't as excited about it as I was, but it definitely was a great experience. Years later, during my first year as a computer scientist at UCL, I'll get a chance to talk about my project as a part of software engineering lecture (thanks to a good acquaintance of mine, Yun Fu).

The first website I made was a simple showcase of some of the things I made in Photoshop. It wasn't anything particularly impressive, but I still think it was kinda cool - I spent a lot of time experimenting with <frame> tags, trying to avoid code duplication as much as possible. Of course, I had to use Comic Sans as the font of my choice. You can see screencaps of selected pages below.

Considering I'm 20 now, this must've been 9 years ago so the whole thing begun in 2009. Since then my blog went through several iterations of complete redesigns until I finally ended up with what you see now. Here's an overview I made several years ago, which covers the 2009-2012 (approx.) period:

Wrapping up

This pretty much sums up how I got into coding. Some time later, I got into PHP which vastly increased the amount of things I could do. I stuck with PHP+HTML+CSS stack for a year or so, and then I discovered jQuery which helped me get into JavaScript. Funnily enough, for quite a long time I was using the good ol' MS Notepad for all of the coding I did. That's right - no syntax highlighting, no auto-indentation, no auto-completion, just bare text. You can't imagine how excited I was to use Eclipse for the first time (eventually switching to JetBrains' IDEs, which I still use today).

I'd like to wrap up with a passage I wrote for my blog in 2012. I preserved the original grammar and syntax, enjoy!

Web Design

The idea of creating websites came to my mind long time ago, when I saw cool websites made by non-professionals. I found out, that they were using uCoz system. I got an account, then registered my first website... That's how I became involved in web-design.

My first website was very basic and non-customized - I just used typical uCoz preset. It looked exactly as millions of other websites, because preset I used was popular. Then I explored the possibility of editing HTML and CSS with WYSIWYG. It was a big step forward for me. As uCoz's editor had had not enough functionality for me, I begun learning HTML by myself.

My first tutorial taught me how to make a simple websites using standard MS Notepad. Believe me or not, but this website and it's previous version are/were written in Notepad! So I would like you to make a conclusion - the result doesn't depend on facilities. My first website was written in MS Notepad and had 3 strings of code, and this page, also written in Notepad, has 300 HTML strings, 25 PHP strings and 297 CSS strings written by me.

I was adding bits and pieces to a small project of mine (I wrote about it here) when I came across an interesting problem. I had a bunch of images that were aligned in one row and resized using display: flex;, so that all of them would have the same height. This setup can be seen below.

These images were loaded lazily, which meant that the height of the page and the layout in general changed as more pictures were loaded. In this article I'll talk about creating responsive placeholder for images when you know the dimensions of the image beforehand.

Problem statement

As seen in the embed above, we have a row of responsive pictures. We want to replace these images with placeholders until loading is completed, and we want these placeholders to look and behave exactly like the original images. We want this because

We don't have any thumbnails available. We also want our solution to work correctly even when perfect alignment wasn't possible (seen below). This happens when the total width of all images is smaller than the width of the container, since we don't stretch our images.

Solution

The placeholder that satisfies our requirements can be built using two divs and some CSS. The basic concept is as follows:

<div class="placeholder-wrapper" style="max-width: {IMAGE_WIDTH}px;">
    <div class="placeholder" style="padding-top: {RELATIVE_IMAGE_HEIGHT}%;">
        <img src="./image.png" />
    </div>
</div>

.placeholder-wrapper {
    margin: 0 auto;
    padding: 0;
}
.placeholder img {
    max-width: 100%;
}

Where {IMAGE_WIDTH} is the original width of the image, and {RELATIVE_IMAGE_HEIGHT} is defined as IMAGE_HEIGHT / IMAGE_WIDTH * 100. Obviously, this requires you to know the dimensions of the image beforehand.

The reason we need two divs instead of one is that padding-top ignores any margin induced by margin: 0 auto;, which means that in cases when the total width of all images is less than the width of the container, our placeholder can behave incorrectly.

Demo

Applying this idea to our initial example:

I often have to read through piles of logs for different programs. Levels of sophistication and approaches to logging differ from program to program, but I think everyone would agree that there is a certain bare minimum of data your logs should contain to be useful. Not only that, I'd go further and say that it's your obligation as a developer of an open-source/public project to make your logs look nice.

Better native Node.js logs

There are a lot of amazing logging libraries out there (pino, bunyan, winston, etc.). The only issue is that these libraries tend to require some time to setup and understand, and it's totally alright if you're not willing to put in the effort.

That said, there are still ways you can improve your console output without using external libraries. Here's a nice 13 line function that makes your logs look much nicer:

let log = () => {
    let now = new Date();
    let options = {
        hour12: false,
        year: 'numeric',
        month: 'short',
        day: 'numeric',
        hour: '2-digit',
        minute: '2-digit'
    };
    let timeString = now.toLocaleString('en-us', options);
    let args = [].slice.call(arguments);
    console.log.apply(null, [`[${timeString}]`].concat(args));
}

This function is simply a wrapper for console.log(...). It prepends a (configurable) timestamp to your console output and makes it easier to follow the timeline of your logs. Some usage examples:

log('Logging is cool!');
// [Nov 21, 2017, 00:46] Logging is cool!

log('Hello', {a: 1, b: 2, c: 3});
// [Nov 21, 2017, 00:47] Hello { a: 1, b: 2, c: 3 }

log(new Error('I am an error.'));
// [Nov 21, 2017, 00:48] Error: I am an error.
//     at Glitter.connect (...)
//     at Object.<anonymous> (...)
//     at Module._compile (...)
//     ...

log();
// [Nov 21, 2017, 00:49]

That's not much, but it's already a step in the right direction. Replace your plain logging with my function and I'll love you forever.

For bonus points, export this function as a part of your Util module to make it easier to use. For even more bonus extra points, use a proper logging library.

Now that I'm enjoying my time as an exchange student at Caltech, I decided to look back at some of the great things that happened to me in UCL. This particular time I'll tell you about an effective way to shield your website from various exploits: by introducing more vulnerabilities.

Scenario weeks

Being a 2nd year computer scientist at UCL means that several times a year you'll have so-called scenario weeks. During a scenario week, all lectures are cancelled (woooo) and you have a week long computer science and/or software engineering challenge (wooooooo).

To help you get started, the first couple of scenario weeks are reasonably tame. One of them involves learning about web app security and popular exploits by implementing two versions of the same website - the first version is vulnerable to popular exploits (namely OWASP Top Ten) and the second version is as bullet-proof as you can get.

Once you're done with the implementation, you produce videos and reports of all of the exploits you managed to use on your first web app, and then produce a similar report to show how every single one was prevented in your second web app. I had a bunch of web design experience prior to that scenario week so I personally didn't learn anything mind-blowing, but it was certainly a fun challenge to tackle.

Aside: I mentioned having some web design experience - I've actually been making websites since I was 11. The designs for some of them were hilarious (I didn't immediately discover CSS) so I will most likely make a separate post about them too. (4th Feb 2018 edit: Here's the post!)

"Implicit" cross-site scripting protection

We finished making the "bad" version of the web app reasonably quickly (doesn't take long to break things), you can find the final "masterpiece" in Chris Ul's GitHub repo. We moved on to producing reports and videos shortly after, and everything was going smoothly until we got to cross-site scripting (XSS).

It was weird and funny, of course, that every single exploit we tried before that worked successfully: cookie hijacking, SQL injections, cross-site request forgery, you name it. Every exploit worked like clockwork because we purposefully made our website vulnerable. But that did not apply to XSS - did we mis-engineer our web app and unknowingly made it more secure than it should have been?

As funny as it sounds, it wasn't completely out of the question. A quick reminder on how XSS works: On most websites, when you register you specify your name and other details in your profile. These details are then shown to other users when you, for example, post comments. Remember that everything you see is just HTML source code that your browser has parsed, and your browser normally can't tell the difference between proper, readable text and HTML tags that should be parsed. If I were to set my name to <script>alert('Hello!');</script> and the website wouldn't have proper XSS protection in place, every user who opens a page with my comment would get an annoying Hello! popup. Now this example is relatively harmless, but people can execute all sorts of nasty scripts using XSS.

With this knowledge in mind, we went through the source code for our app to see if we're performing sanitisation or any other "unnecessary" checks. Looking at our SnippetAPI.php:

// ...
$q = "INSERT INTO snippets (owner_id, content) VALUES ('".$_GET['user_id']."', '".$_GET['content']."')";
$res = mysqli_query($conn, $q);
// ...

Looks pretty insecure to me - so the issue wasn't in sanitisation. We brainstormed for a second and then it dawned on us.

Eureka!

All the scripts we used for our XSS injections had a structure similar to <script>alert('Hello!');</script> - you might notice that it contains some single quotes ('). These single quotes broke the SQL query you saw above, so nothing was inserted into the database and our uses were safe. In essence, the fact that our system was vulnerable to SQL injections saved our users from specific XSS attacks.

Now that's not some obscure bug that requires decades of computer science experience to pinpoint. In fact, this is probably the simplest yet silliest "bug" I've ever encountered in my life, which is why we spent good 10 minutes laughing at the very idea.

' vs "

Of course, if we were to use double quotes instead (i.e. <script>alert("Hello!");</script>) our XSS attack would succeed and someone could steal our users' data. This is where the second punchline comes in - it's safe to say to that any meaningful JS script would contain at least one string. Same goes for scripts used in XSS attacks. Unless you're doing something weird, this means the script would have to contain at least one quote symbol.

I personally always use single quotes in my JS code (and sometimes backticks for template literals, but that's unavoidable). Naturally, I would want to convince you to switch to the dark side single quotes too. There are many ways to achieve that, and thanks to this bug here's a brand new take on the problem:

Imagine you begin religiously using single quotes in your JavaScript, converting all of your friends. They convert their friends, and soon enough we have everyone using single-quotes.

Now, a friend of yours, who's not very good with webapp security, makes a site everyone begins to use. By convention, they'll use single quotes in their SQL queries.

Eventually someone would try to perform an XSS attack to spy on you. Remember that in our perfect world everyone uses single-quotes, meaning that the attacker will fail since their code won't even get inserted into the database thanks to the bug we've just covered. Thus the world is safe.

If this doesn't make you want to only ever use single quotes in your JS code, nothing ever will. Either way, thanks for your attention.

A small disclaimer: I was planning to write this article for a long time now, and somewhere between now and the time I released Blitz I've realised that this project was doomed from the start. Initially, this post was going to be about me telling you how cool Blitz is, but that didn't work. So now I'm just gonna tell you that Blitz happened, and it was great while it lasted.

There are times when I suffer from the NIH syndrome. Back in my high school days I used to write everything from scratch - I once even attempted to reinvent Photoshop using PHP (don't ask me how that went).

Throughout the years, my programming experience was growing and the amount of free time I had was shrinking, so I had to (forcefully) contain any NIH tendencies that I had. Luckily, that didn't always work! When I was working on the PEACH Reality project one of the requirements was to make a simple static website. That website would contain an overview of what we've done, user manual, and some other things, practically a bunch simple HTML pages with basic styling.

If you know me personally, you'd know that I'd never be satisfied with completing such a simple task without adding a bunch of all-nighter-worthy extra features. After trying a bunch of existing static site generators, I decided that none of them were worthy of being used by me. And this, ladies and gentlemen, is precisely how Blitz was born.

Blitz

The first version of Blitz was published on its GitHub on November 12, 2016. Since then Blitz got its own website - https://getblitz.io/ (which is now dead, obviously) and a bunch of updates. All 0.1.* releases had some nice basic functionality to them, but I never got to publishing 0.1.6+ which had all the cool features like advanced menus, IDs and so on. Instead, I was just keeping 0.1.6+ to myself and reaping all of its perks, har har har. You might also enjoy some trivia:

• Blitz was my first published NPM package (I now have 3, wooo).
• Blitz was developed in a series of all-nighters amidst university deadlines and upcoming presentation to corporate VP of Microsoft.
• A bit of background on how Blitz generated pages:
  • You create some .pug files to define the "skeleton" of your website. Pug is just a very nice HTML templating engine which makes your HTML pages smart.
  • You write up some content in .md files because Markdown is awesome. You can also augment your .md files with front matter (concept shamelessly stolen from Jekyll). Front matter can define all sorts of useful things for your templates, like page ID, page title, menu title, etc.
  • You create blitz.yml that tells Blitz how to map your content to your Pug templates. Here you would specify menus, page URLs, etc. What I personally find cool is that you could choose a single template, and then pipe all .md files from some folder into it, without having to create a setting for each page separately. For example, you could create a blog-post.pug, then make it use all .md files from posts/ effectively generating a page for every blog post you had.
• Blitz had an amazing feature of generating "offline" websites. As you might know, if you open a website locally (i.e. by simply clicking on .html files, without a server) most of the links tend to break because they rely on absolute URLs with respect to the website (e.g. https://foxypanda.me/some/path/). Blitz could generate websites where all images, stylesheets, JavaScript files and (!!!) menus would use relative paths (e.g. ../../image.png) so your website would work anywhere. "Menus" is emphasized because damn is it hard to work with multiple menus while generating HTML files in different folders.
• ...because Blitz is absolutely awesome, it didn't stop on offline websites. As you might also know, server software (like Apache) usually serve the path/index.html file automatically if you make a request to path/. Blitz made use of that (and generated tons of directories) so you could get pretty, user-friendly URLs even if your website is static: http://<name>/about/, http://<name>/blog/post-1/, http://<name>/blog/post-2/, etc.
• A small but nice feature - Blitz actually told you what element in the menu was the "active" element, so you could add some nice styling to it.
• Now a killer feature: "Killer" not necessarily because it's cool, but because it was damn near impossible to implement. In fact, one of the main reasons v2.0 came to be was to solve this issue. Anyway - Blitz allows you to reference pages by IDs on any other page. This means if on your /blog/category-1/post-3/sidenote-1/comments page you'd want to have a link to the "About" page, you could simple use one of the Handlebars helpers Blitz provides. Now remember, as a developer, I had to deal with the case of you using relative URLs.
• Blitz strived to differ from other static site generators, but for some reason it chose to use YAML for its config although there was really no reason to use it, Tim. Because YAML isn't very smart (unless you mod it) configs got very repetitive for big websites:

# Snippet from `blitz.yml` of a big website
pages:
  - uri: '/'
    content: 'overview.md'
    template: 'overview.pug'
    menus:
      - name: 'main'
        title: 'Overview'
      - name: 'overview'
        title: 'Overview'
    child_directories:
      - uri: '/'
        name: 'overview_pages'
        template: 'overview.pug'
        directory: 'overview'
        menus:
          - name: 'overview'
  - content: 'research.md'
    template: 'research.pug'
    menus:
      - name: 'main'
        title: 'Research'
      - name: 'research'
        title: 'Research Overview'
    child_directories:
      - uri: '/'
        name: 'research_topics'
        template: 'research.pug'
        directory: 'research'
        menus:
          - name: 'research'
# ... and it kept going for 100 more lines.

• Blitz had a super cool 2.0 version in the works, development of which begun in December of 2016. It had tons of bug fixes and tons of improvements, including real-time updates, preview server, config validation...

• ...but version 2.0 was never released. In fact, the pull request is still open.

Conclusion

I absolutely loved writing Blitz. BUT I really, really, really had to limit the scope. My software engineering lecturer, Graham Roberts, would be disappointed by the amount of scope creep I have allowed. I would also definitely not use YAML again - if anything, I'd stick to JS-based config files so my users would get all of the perks of an actual programming language.

These 2 things aside, my main mistake was to allow the architecture to get super complex. I should've developed a nice, simple abstraction first and then develop the project around it, instead of doing it the other way around. All in all, Blitz was a great programming exercise.

Lesson learned, project abandoned.

This article has been sitting in my drafts for a while now, I decided to add some minor details and publish it. Apologies if it might seem incomplete.

One day I was looking through the MyAnimeList (MAL) account of mine and I've noticed that I've specified the start and finish for every single title I've watched. Now that isn't really impressive, but noone else using MAL actually does that.

I immediately thought that it would be neat to map all of the titles I've watched on a timeline to see how long it took me to complete each one (I'm known to take up to a year to complete certain series). Once I got the basic demo running, I decided to add a couple more features to the prototype and make it public. This is how MyAnimeTimeline was born and, as a side product, I made a small API tool called Kuristina. Find out more about both of them below.

MyAnimeTimeline

You can try the MyAnimeTimeline webapp to see the tool in action. You will need a MyAnimeList account of course, or you could just try my username: Timbo_KZ. The source code can be found on its GitHub. Below you can see a screencap of what it looks like when you use my account.

Since most people don't actually specify their start and finish dates, the app has to fallback to some less accurate timestamps, such as the date of last update. This makes the timeline look a bit wonky if the user has made a lot of updates on a single day, or, a more likely scenario, if they added a bunch of titles when they've created their account.

Fetching anime and manga lists using Kuristina

While developing MyAnimeTimeline, I realised that MAL website doesn't support CORS. To help aid my own projects and help out other developers, I hosted a simple API on Heroku that takes raw data from MAL and makes it a bit more structured. The API is called Kuristina and you can find more information, including usage instructions, on its GitHub page. Kuristina also has a Node wrapper.

It's a life-long dream of mine to invent a robust yet accessible music visualisation framework. I've tried a bunch of times in the past using Java (ActiveVisualiser, Envision) but the solutions were very obviously imperfect: first of all, I had no idea what I was doing, and secondly, they were written in Java.

As we all know, browsers are becoming more and more powerful every day with Web Audio API and WebGL being some of the cool additions. Seeing how perfectly these 2 technologies could work together I decided to combine them to produce yet another music visualisation framework, while eliminating 2 major flaws of previous implementations:

• The framework no longer uses Java but the beautiful language of JavaScript.
• Users can run visualisers in their browsers, so developing/sharing visualisers doesn't require much setup. (Or any setup if you just wanna check out someone else's visualiser, just click on a link.)

With this mind, I made Akko (GitHub repository, online demos).

Introducing Akko

Akko is a JavaScript music visualisation framework that runs in your browser. It uses Web Audio API and WebGL to provide play music and render 2D or 3D graphics in to the browser window.

Akko exposes a set of APIs that allow you to implement a visualiser, ranging from simple 2D graphics to complex 3D compositions with shadows and shaders. Below you can see a screenshot from a simple visualiser implemented in 45 lines of JS (with proper whitespace). The picture is clickable, in case you want to see the visualiser in action.

As usual, you can find more information on Akko's GitHub page. Check out some online demos, but keep in mind that Akko provides the framework for visualisation - how cool the visualisation looks is up to the author.

If you've ever visited this website before October 2017, you might've seen some cool animations and a dynamic grid, just like the one on the gif.

It looked nice and was certainly fun to implement, but god was it not readable at all. I decided to fix that.

Home page update

As you've probably seen by now, the home page now has a nice list of posts. You can still filter them by Projects or Blog categories, but they're much more readable now in a sense that all titles and excerpts are now nicely aligned in a vertical line.

I've also added some thumbnails (well, they were already there, I just revealed them) so the home page also looks prettier now. Just in case I will update it in the future, here's a snapshot of what the home page looks like at the time of writing:

Hope you like it! Tim out.

As you might've found out from a previous post of mine, in Summer of 2016 I spent a couple of weeks travelling around Japan. The previous post focused on the pictures I've taken with my camera, while this one has a bunch of panoramas I've taken during the trip using my phone.

Panoramas

All of these were taken on iPhone, so apologies for the quality. I wanted to post them because I think they give quite a good idea of what the atmosphere there felt like.

View from the balcony of the apartment I stayed in, Osaka:

View from a ferry to Miyajima island, Hiroshima:

Miyajima island shore, Hiroshima:

A hidden room in an anime cafe, Hiroshima:

The famous rock garden in Ryoanji temple, Kyoto:

World's largest wooden building, Daibutsuden in Todaiji temple, Nara:

Iconic bridge from the Fate series, Kobe:

Room in a ryokan, Atami:

Bath on the roof of a ryokan, Atami:

A street in Akihabara, Tokyo: