Unit Tests with Rust Tutorial 101

Writing unit tests is heavily integrated into rust without additional dependencies or external test runners. You can write unit tests inside the file that has the testable code or use a separate tests directory, let’s see how we do that.

You don’t need to have any prior rust knowledge, but you will have to have rust installed, which most easily is done by using rustup.

Writing Your First Test

When creating a rust project with cargo new and we’ll need a function that takes arguments and returns something, so let’s go for a simple sum function in main.rs:

fn sum(a: i32, b: i32) -> i32 {
    return a + b;

fn main(){
    println!("12 + 1 is {}", sum(12,1));

mod tests {
    use super::*;

    fn sum_test() {
        assert_eq!(345+5, sum(345, 5));

Now for the interesting parts in the bottom of the file

  • #[cfg(test)] <- the test section attribute (see conditional compilation)
  • #[test] <- the test attribute for the individual test
  • assert_eq! macro to compare the two values

This is the simplest way to implement a unit test in rust, the next step is to look at how to move your functions and tests into another separate file.

Running cargo test should output something like:

    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running target/debug/deps/rust_test_101-e2cf395340fbef91

running 1 test
test tests::sum_test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Adding the following has the correct types, but it would cause the return value to be larger than i32 allows:

fn greater_than_i32() {
    sum(2147483647,1); // this would be bigger than i32 allows

By using #[should_panic] we tell the test run to expect the following function to fail. This catches errors that usually crop up with:

thread 'main' panicked at 'attempt to add with overflow', src/main.rs:2:12

Now this is the easiest possible way to get started with writing tests in Rust, let me know if you want to know more in future posts! Don’t forget to check out the Rust Book Chapter on Testing as well.

What is a QR code?

QR codes are little pixelated images that can convey information beyond the pattern that you see with your eye. Usually that information is a little bit if text, like a web address, phone number or similar. They are commonly used where you don’t want to present anyone with instructions like:

  1. open the app called “something”
  2. click on this button
  3. type in “42lkj,nm3ikj25j900jkjlkjaeii”

Instead, you present them with a picture, that’s going to do that for them. For example to lead them to your website, follow you on social media or pay with a cryptocurrency.

Continue reading “What is a QR code?”

Bonding: Season 1

Bonding on Netflix is a show about a Dominatrix that hires her reluctant best (and only) friend to be her assistant.

The show looks amazing, I mean still frames of the main characters could basically be paintings, but it’s not the deepest of shows and loaded with stereotypes. Fortunately, for me, the show doesn’t take itself too seriously in my opinion.

Among sex workers and the BDSM scene the show has gotten some critique, which The Rolling Stone sums up nicely, all justified from my point of view, if you want to know what’s wrong with it.

For Denmark it might be silly and harmless show, but lots of places in the world I bet the show can still lift a bit of stigma and cause conversations, which is why I’m mentioning it (HELLO AMERICAN READERS!).

Check out Bonding, if you’re looking for a mostly funny show about sex and two young adults struggle in the gig culture.

What is an Interface?

An interface is something I first stumbled upon when I started learning compiled languages. I had read the term a couple of times before, but really only with C, Java and lately Go an interface actually means something to me that I can remember.

I’ve used the abbreviation API about one thousand times in my life, which stands for Application programming interface, usually I mean web APIs, where I get some JSON to feed it to my frontend or something, but that’s already a very specific use case.

As with many words in computer science, interface can mean many things, but depending on context it means a very specific thing. To quote wikipedia:

In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information.

and more specifically regarding programming:

the term interface is used to define an abstract type that contains no data but defines behaviours as method signatures.

So an interface is a bit like a puzzle piece. You can’t just attach your code or your function anywhere, but you need to find the right part that’s sticking out.

Implementing / Satisfying Intefaces

To implement or to satisfy an interface means to comply with the rules set by the blueprint. In object oriented languages such as C# or Java, interfaces are abstract classes, that just set some requirements for which functions must be included and which types they can receive or return.

Since Golang is not an object oriented language, there are no classes to implement, but we can still satisfy an interface with our type and it will be checked automatically by the compiler. Let’s pretend we are programming a series of vending machines and instead of a <Product> type, they’re supposed to return a string:

package main

import "fmt"

type VendingMachine interface {
    ReturnItem() string

type Cola struct {

func (d Cola) ReturnItem() string {
    return "you get a cooled cola"

func main() {
    var vend1 VendingMachine
    vend1 = Cola{}

You can see that type VendingMachine interface creates the first blueprint interface and the Cola struct now will need to satisfy the interface by also having a ReturnItem function.

We test this by creating a variable vend1 of type VendingMachine and assign a Cola{} struct to it.

The expected output is: you get a cooled cola

If we remove the following code:

func (d Cola) ReturnItem() string {
    return "you get a cooled cola"

We get the error:

# command-line-arguments
./main.go:21:8: cannot use Cola literal (type Cola) as type VendingMachine in assignment:
        Cola does not implement VendingMachine (missing ReturnItem method)

Thanks Go! Helpful! This way we can’t forget the essential ReturnItem function in our VendingMachine and make our customers really angry at us, because no products come out after they payed.

Similarly, if we change the return type of the Cola ReturnItem to int:

./main.go:13:9: cannot use "you get a cooled cola" (type string) as type int in return argument
./main.go:25:8: cannot use Cola literal (type Cola) as type VendingMachine in assignment:
        Cola does not implement VendingMachine (wrong type for ReturnItem method)
                have ReturnItem() int
                want ReturnItem() string

This makes sure that we return the correct type as well, because the humans or possibly robots interfacing with our vending machine will expect strings, not integers to come out.

Lastly, when coming from other languages you might try to implement a go interface by using the interface to create a type instance, maybe like this:

vend1 := VendingMachine{Cola{}

However, since the implements checking is done by the compiler and abstracted away, you’ll only get an error about a composite literal:

./main.go:17:25: invalid type for composite literal: VendingMachine


Interfaces are handy tools to ensure that your application can have consistently grouped functionalities with different values, even in a non OOP language like Go.

Real world examples of interfaces are the Readers and Writers in Go are IO parts like the Writer or Reader which you can try out and extend for some simple file system operations if you’re interested.

Fuck You, Pay Me. [Video]

I came across this wonderful video a few weeks ago and it’s more true than ever. It has a couple of valuable lessons for anyone who’s freelancing or trying to run a business without bankrupting themselves.

Mike Monteiro runs a design company and takes you on a bit of a journey on when they hang up the phone because the other party brought their lawyer, but they didn’t.

The key lessons for me are: Lawyers will save you money. The higher you climb the “big client” or “big game” ladder, the more people will test you and try to stretch you, especially if you’re inexperienced.

I’ve started to love contracts, obviously short and straight forward and most of all honest, simply because it’s a written reminder what everybody has to do and who gets what as a delivery. I’m a fan of saying hard things early in the process, so writing up a contract is a good exercise for that. It’s, at least it’s supposed to be, a simple and honest description of the business relationship.

Do yourself and everybody a favour and write contracts, don’t start working without the startup fee. If you can’t afford to walk away from something, that’s where your job will wear you down and it’s the most painful. Trust me, I know.

Building law.photography

We built a website that lists photography related laws by country and also in multiple languages. We started it as an independent project to enable the community to contribute to the site and to keep the content open source on a public repository, in this case on github.

Building law.photography is something that happened over the last 4 months when ever we had time and energy for the undertaking, to learn the new skills and to mill through foreign legal texts and some (actually really great) Wikipedia summaries.

Since we’re both photographers interested in street photography, it wasn’t hard to find a starting point. We often witness similar discussions unfold in photography communities about what is legal, what is not, where different laws protect either the subject or the right of the photographer. Especially on facebook a lot of the posted content reflects only an opinion or only takes one of multiple laws that may be relevant into account.

We wanted to create easy to understand summaries and quote the relevant law texts so photographers could inform themselves relatively quickly. None of us studied law, but we’re hoping a lawyer or two (per country and language) will join our efforts in the future.

The content for the laws is publicly available on the content repository on github and the change history since the initial release can be traced and a “who wrote this line when” is always just a few clicks away. This transparency is probably a benefit in the long run, also considering that new privacy laws like the GDPR and other local implementations (and court cases) will further clarify some of the legal situations over the years.

User Journey

Search engine traffic will probably be the biggest driver to this site in the future, while somebody researches their rights or compares local laws to a travel destination’s laws. Possibly the individual articles will be used as a reference on forums or social media discussions.

Editing a page currently is a bit of a techie experience, but we hope it is possible while using the web interface, even for anyone who is not a developer. When the first contributions come in, we’ll try to reach out to the editors and ask how difficult it was to apply. In general, editing a text / markdown file is a low barrier of entry, but the versioning through git adds a bit of complexity.

Technology: Gatsby.js

The first version was actually done with hugo, but we decided to with a an approach that has similar speeds, but is component based and allows for more flexible template and asynchronous data handling. For that our considered options were next.js, nuxt.js and Gatsby.

Having little to no experience with all of them, the odds were pretty even in the beginning, but Gatsby won the race, because of the outstanding existing ecosystem including image loading, familiar react syntax and the frontmatter enhanced markdown support.

The GraphQL querying is still new to us, but has great ease of use for different content types and not having to think too much about what content could possibly come in the future, but just focusing on getting an early version out. We’re confident to be able to add example contracts for photographers like for weddings, events or general model release forms without doing too much restructuring.

Gatsby is great for speed, because the initial hit is server side rendered, further navigation just loads the difference between the current and the destination page.

This fits our primary expected use case of a large portion of search engine traffic well, as the initial load times are low and assets can be prioritised. Especially when looking up something on the go, we don’t want to keep users waiting for too many network requests or images in an unfit resolution.

Very helpful while optimising for speed, was the Google Lighthouse test through the respective browser plugin, even though Gatsby makes it very difficult to make anything slow.

Currently there isn’t too much content for every release and the site builds swiftly, if this stays as snappy for the future volume and the localisations remains to be seen.

For deployment we chose docker, since we already had a dokku server at our disposal that runs some other side projects and deploying containers to other services is becoming easier and more widely supported by the minute. Since Gatsby only requires the static files to be served, the Dockerfile basically installs node and Gatsby, clones the content repository and serves the build directory through nginx.


We built a static site with Gatsby trying to be an easy to understand and at times illustrated resource for everything that has to do with photography and the law. We’re not done and we hope the community will help us out on github. Maybe it’s a silly idea, but we’ll know that in a year or two.

Check it out at law.photography and give us a shout what you think about it!

Best Cheap Linux VPS Hosting 2019

Where are VPS the cheapest, how many CPU cores, how much RAM and disk space do you get for the dollar? I’ve taken a bit of time and looked at those questions.

Currently I’m comparing the following providers:

If you know of a hosting servers I should absolutely include, please let me know! The data for the below charts are benchmarked with at least 10 samples and aggregated with a bit of node code. I’ve written more about the process in the end of this post.

Note: The labels don’t show up right on all mobile devices, work on an improvement is pending.

Best 5$ VPS?

Let’s first have a look at the 5 dollar tier for smaller projects or just learning your way around the Linux command line and basic deployment.

^ Sha 256 time, shorter is better

^ Bzip2 compression time, shorter is better

^ IO operations, more is better

^ file system write, shorter is better

We can see that Vultr and Digital Ocean lag behind on the 5$ plan compared to Linode. Especially on the io speed Vultr seems to have some trouble. Keep that in mind if you’re going to run a very file system heavy project, for example video upload or streaming.

Best 10$ VPS?

Comparing the plans shows that you mostly get the same specs in the 10$ tier, 2GB RAM, one virtual CPU core and ~50GB of SSD space.

^ Sha 256 time, shorter is better

^ Bzip2 compression time, shorter is better

^ IO operations, more is better

^ file system write, shorter is better

The Vultr server shows overall higher CPU speeds (at times 3x the speed), which is surprising compared to the previous server. We might need to take into consideration that deploy hardware for the virtual servers and other instance loads on the host system may vary.

Best 20$ or 40$ Dollar VPS?

The 20 and 40 dollar plans are again very similar and show little variance even in available disk space or transmission bandwidth. If you get above this tier, dedicated servers might be more suitable for you, if you don’t need exactly replication of hardware of similar magic

^ Sha 256 time, shorter is better

^ Bzip2 compression time, shorter is better

^ IO operations, more is better

^ file system write, shorter is better

In this segment, we can see Vultr leading the CPU bound tests and Linode following on second place. DO outperforms its own bigger spec VPS with the smaller instance.

General Notes on VPS Providers

I’m not paid by any of the providers to mention them or to say anything nice about them. While I do get “store credit” with them if you sign up with them, I couldn’t care less which ones you try. For my sake: try all of them!

All so far tested virtual private server hosting companies have very user friendly UIs and make it incredibly easy and fast to spin up a server, which is exactly what you want when managing web infrastructure or just wanting to try them out.

Digital Ocean

Digital Ocean has a referral program.

DO also has Kubernetes hosting in a limited availability / beta stage.

There’s a 15$ flexible VPS tier that let’s you decide between 1-3GB of RAM and 1-3 CPU cores:


  • America: New York, San Francisco, Toronto
  • Europe: Amsterdam, Frankfurt, London
  • Asia: Singapore, Bangalore



  • America: Dallas, Fremont, Atlanta, Newark
  • Europe: Frankfurt, London
  • Asia: Singapore, Japan (Tokyo)

If you should try to mine XMR/Monero or other crypto currencies, their support will reach out to you and you will be expected to not do that. Their terms of service state:

Misuse of System Resources: Intentional misuse of system resources, including but not limited to employing programs that consume excessive network capacity, CPU cycles, or disk IO.

I know that the support will do that because a friend told me. No other reason. Really!

Linode has a referral program.



  • America: Atlanta, Chicago, Dallas, Los Angeles, Miami, Newark, New York, Seattle, Silicon Valley ?, Toronto
  • Europe: Amsterdam, Frankfurt, London, Paris
  • Asia: Singapore, Japan (Tokyo)
  • Australia: Sydney

Their mascot is a cute little vulture.

Vultr has a referral program.

As one of the few providers, they offer servers in Australia.

How this vps benchmark was made

I’ll quickly go over my toolchain for creating this post:

  • The amazing nench was used to actually run the benchmarks and test the performance of the different machines.
  • There’s a small bash script that wraps around nench, captures the output and runs it 10 times
  • The data samples are parsed and aggregated with node and converted to JSON
  • The charts are using Taucharts, which supports custom colours by data point (for the different providers) and is generally very nice to use.

Love Death Robots: Season 1

is an amazing show. It’s weird, gory, funny and some of the mockery of humanity hits you like a bitter brick in the genitals.
If you’ve felt forgotten and waited for more than 9 episodes of The Animatrix or if you don’t mind a fast paced mash up like Into The Spiderverse, or an explicit master piece like Ghost in the Shell this is for you.
The show is available on Netflix and every episode so far has been a firework of effects, dystopian fantasies and science fiction amazeballsness.
Stop reading this blog and go watch it if any of what I just mentioned appeals to you in any way.

Deploying a Nuxt.js App with Docker

Let’s check out how you can deploy your Nuxt.js app, including server side rendering, with Docker. You can also view this post as a video:

The versions at the time of writing are:

  • nuxt: 2.6
  • Docker 18.09.3

Nuxt.js installation

For this tutorial I’ll create a new nuxt app

npx create-nuxt-app my_app

Hitting ENTER will work for us, but you can customise your app as you wish.

? Project name my_app
? Project description My shining Nuxt.js project
? Use a custom server framework none
? Choose features to install Prettier, Axios
? Use a custom UI framework none
? Use a custom test framework none
? Choose rendering mode Universal
? Author name Jonathan M. Hethey
? Choose a package manager npm

  To get started:

    cd my_app
    npm run dev

  To build & start for production:

    cd my_app
    npm run build
    npm start

Now let’s verify that our app works with:

    cd my_app
    npm run dev

If we access http://localhost:3000 now we should see:

Which is exactly like it should be.

Nuxt.js Dockerfile

Next, we’re going to write the Dockerfile for your Nuxt.js app.

FROM node:11.13.0-alpine

# create destination directory
RUN mkdir -p /usr/src/nuxt-app
WORKDIR /usr/src/nuxt-app

# update and install dependency
RUN apk update && apk upgrade
RUN apk add git

# copy the app, note .dockerignore
COPY . /usr/src/nuxt-app/
RUN npm install

# build necessary, even if no static files are needed,
# since it builds the server as well
RUN npm run build

# expose 5000 on container

# set app serving to permissive / assigned
# set app port

# start the app
CMD [ "npm", "start" ]

This Dockerfile is based on the node alpine Linux image and then moves on to install git, the npm dependencies and finally builds and starts the Nuxt project.

Note that the NUXT_HOST and NUXT_PORT are set to Bind to any IP at port 5000, this might change depending on how you deploy your docker container.

My .dockerignore file contains the following to prevent using my local dependencies and builds:


Building your docker container can be done with, while in the repository with the Dockerfile present:

docker build -t my_app .

The output should be something along the lines of:

Removing intermediate container 7e9f607fb06e
 ---> c5b57739f412
Step 9/12 : EXPOSE 5000
 ---> Running in a326b4f25052
Removing intermediate container a326b4f25052
 ---> 796e335481fb
Step 10/12 : ENV NUXT_HOST=
 ---> Running in 9aa3b799df0b
Removing intermediate container 9aa3b799df0b
 ---> 12f905ccb574
Step 11/12 : ENV NUXT_PORT=5000
 ---> Running in d9e9e111a32c
Removing intermediate container d9e9e111a32c
 ---> 0eab950732ab
Step 12/12 : CMD [ "npm", "start" ]
 ---> Running in 211496606e04
Removing intermediate container 211496606e04
 ---> 54779de7e817
Successfully built 54779de7e817
Successfully tagged my_app:latest

Next, to run the container:

docker run -it -p 5000:5000 my_app

Which should show this or similar:

   │                                            │
   │   Nuxt.js v2.6.1                           │
   │   Running in production mode (universal)   │
   │   Memory usage: 20.8 MB (RSS: 54.9 MB)     │
   │                                            │
   │   Listening on:     │
   │                                            │

and also display the app again when accessing the stated listening URL.


Setting Nuxt.js up with a Dockerfile couldn’t be much easier than it is already, so you know you have a reliable way of distributing your app after writing it.

I’m still new to Nuxt.js, but I suggest you give it a shot, since it’s amazing.

Elite Dangerous: You are small, the ‘Verse is big.

Elite Dangerous or simply Elite is somewhere between a space flight simulator and an immersive open world role play game. You get dropped into the universe after optional and basic training.

The space simulation part of the game is incredibly well executed, the sheer distances that need to be overcome can take up quite a portion of game time. However, depending on your preferred play style, you can play Elite in a number of different ways.

Continue reading “Elite Dangerous: You are small, the ‘Verse is big.”