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 unintented 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 rync replication to migrate the data between instances.

This article was featured on the Hacker News frontpage. Feel free to checkout comments there.

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.

Back to basic, let’s brush up on some SQL : )

At my company we have employees creating customer accounts every day. Sometimes we make mistakes, for instance, we forget to check if the company already was a customer (maybe 10y ago they may have had a product).

Duplicate accounts can cause all sorts of problems, so I wanted way to detect them with SQL.

The problem was, the company names may have been entered with different punctuation, whitespace, etc. So I needed similar names to surface from the depths of our database, not just exact matches (that would have been too easy : )

There are many cases where using BASH to code ends up overcomplicating things, but due to it’s portability there are many cases that make it the best tool for the job.

When I do hack on BASH scripts, I often find there are things like logging, configuration, commandline argument parsing that:

• I need everytime
• Take quite some effort to get right, and
• Keep you from your actual work.

Here’s an attempt at bundling those things in a generalized way so that they are reusable as-is in most of my (and hopefully your) programs.

I often share screens with co-workers by Campfire, Github, or mail. Visualizing something can save you a lot of typing. Show people what button shade doesn’t look quite right, instead of explaining in 1000+ characters. Share a load graph without saving & attaching images, or handing out basic auth credentials. The list goes on & on. Once you make it a joy to share, you’ll find use-cases on a daily basis, and it is my believe you’ll lose less time on typing and miscommunication.

At least.. that’s what I’m experiencing, using the following tricks.

I recently had an annoying encounter with the error message: Too many authentication failures for root. I found out this can be caused because you’ve hoarded too many SSH keys : )

So serves me right, but let’s see what happens exactly.

I love my NAS but because I tried to save a little money it does not run SABnzbd very well.

I’ve tried different approaches but find myself ending up downloading on OSX as it writes to a network share on my NAS. Too bad, but I’m archiving this one under the section first world problems.

The challenge I have now though, is when my Mac goes to sleep, my mounts disappear, and SABnzbd writes to the local filesystem instead. Cause as far as my downloading program could tell, it was already writing to a local filesystem, so it will just keep on doing that until my Mac’s disk is at 100%.

I wrote a little script to prevent that.

You may not be running SABnzbd, but there are obviously many other use cases where you want a network mount to persist. Especially if you are automating something outside of the GUI.

With some small adjustments this could work for Linux/NFS/SMB as well.

Quick tip. If you lose your Vagrant mounts after kernel upgrades in your virtualbox, you’ll need to reinstall your VirtualBox Guest Additions. Same is true when you upgrade Vagrant, etc.

It’s just a real pain and people usually avoid it by never upgrading. Or delve in once they accidentally do. But there’s actually a nice & automated way of keeping your VM’s guest additions in sync with virtualbox.