Previously while talking features of the HTTP Range header I wrote:

Last and likely least , you can read the last N bytes of a file by requesting a negative offset: […] Honestly, I’ve never come up with a use case for that.

A friend pointed out a possible use case, “tailing” a file on a server.

In my previous post about codeless APIs I made use the HTTP Range header to download only a portion of the file from a web server or cache (byte serving).

Because I was working in client side Javascript, I didn’t provide a Ruby example, which would look like:

require 'uri'
require 'net/http'

uri = URI("")
http =, uri.port)
request =
request['Range'] = 'bytes=64-1024'
response = http.request(request)

For bonus points, response.code == 206 tells you that you got your “Partial Content”. A code of 200 would tell you that the Range was ignored and you got the whole file.

There a couple of other features of the Range header that are worth mentioning…

What if I told you that you could create a API backend that didn’t require any code? Crazy right? Wrong!

When I run into a problem I can’t and the Google doesn’t have it, I document it for the next person.

Recently, RVM started using GNU Privacy Guard to sign releases (a good thing!). However, when I tried to upgrade to the a signed release, GPG failed with:

gpg: public key of ultimately trusted key 00000000 not found

The gpg --check-trustdb and gpg --update-trustdb commands report the problem, but do not repair it.

A quickie today, renaming a bunch of files in the shell. Unix gives you million ways to do it, here are a few that will help you understand your tools better.

The word has come down, Uber is the new Awesome and our files must reflect this (management is behind the curve, but they pay the bills).

There’s one Ruby gem that make it into practically every Ruby project I write, my friend Ara’s Map. Really, it’s a coincidence that I know Ara, this gem speeds up development and I would be using it anyway.

To securely access your servers you use SSH keys. Passwords can be guessed, just look in your logs to see all the people trying. But, you know that. You’ve got one key to rule them all added to .ssh/authorized_keys on the servers you manage. You may have even disabled passwords altogether by setting:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

in /etc/ssh/sshd_config

But, how many keys to you have?

So, you’re on a rescue project with some legacy code (and by “legacy” I almost always mean PHP). The old developer probably just FTP’ed changes up to the server. You could do the same, but frankly that fills me with dread. On a good day I don’t like deploys. What if something goes wrong?!?!?! To help me to relax, I use good tools that let me trust my deploy and allow me to rollback if something doesn’t work.

In a Rails project you’d get that security from Capistrano. Turns out that’s the right tool for you legacy project as well. Capistrano 2 had a few, easily addressed, Rails-centric tasks. However, Capistrano 3 is framework agnostic by default. (Am I implying PHP is a framework? No, I am not.)