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));
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn sum_test() {
assert_eq!(345+5, sum(345, 5));
}
}
Now for the interesting parts in the bottom of the file
#[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:
#[test]
#[should_panic]
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.
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:
open the app called “something”
click on this button
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.
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.
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{}
fmt.Println(vend1.ReturnItem())
}
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
Summary
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.
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.
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.
Content and Legal Advice
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.
Summary
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!
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.
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.
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!
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.
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
EXPOSE 5000
# set app serving to permissive / assigned
ENV NUXT_HOST=0.0.0.0
# set app port
ENV NUXT_PORT=5000
# 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:
node_modules
npm-debug*
.nuxt
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:
and also display the app again when accessing the stated listening URL.
Summary
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 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.
