All Posts

If you are writing code in Go and are executing a lot of (remote) commands, you may want to indent all of their output, prefix the loglines with hostnames, or mark anything that was thrown to stderr red, so you can spot errors more easily. For this purpose I wrote Logstreamer.

In loosely typed languages such as JavaScript or PHP, using `==` to compare values is bad practice because it doesn't account for type, hence `false == 0 == '' == null == undefined`, etc. And you may accidentally match more than you bargained for. If you want you can limit unintended effects & bugs this may lead to, it's often wise to use `===`. In the process of converting legacy codebases to use these triple equality operators, I find that as a rule of thumb you can almost **always force triple equality** in case of comparing variables against **non-numerical strings**. There's just never a case where you want the text `'Kevin'` to pass for the boolean `true`, or the number `3`. And if that can still happen in your legacy codebase, you'll want to limit those risks rather sooner than later. Even if that breaks things that now accidentally, work.

Here are some commands to download the most important pages of your site as plain text (determined by `MAX_DEPTH`), and save it into one big `DOMAIN.txt` file. This could come in handy when you want to have everything checked for grammar & spelling errors. After the spellcheck you'd still have to search through your codebase / database to find & fix the culprits, but this should already save you some time in discovery.

Recently we moved the Transloadit status page from an unmanaged EC2 instance to the Nodejitsu platform. We kept status uptime history in redis, and obviously I wanted to preserve that data. For the new setup I did not have access to the filesystem, I only had a redis port to talk to. So instead of rsyncing the .rdb file I used Redis replication to migrate the data between instances.

Unfortunately the Linux DNS resolver has no direct support for detecting and doing failovers for DNS servers. It keeps feeding requests to your primary resolving nameserver, waits for a configured timeout, attempts again, and only then tries the second nameserver. This typically means nearly 30s delay for all request as long as your primary nameserver is unreachable. It doesn't learn to directly target your secondary nameserver so long as there is trouble. Even with the most optimal configuration, the delay will still be measured in seconds per request. For many requests, that's many more seconds. I wanted to solve this.