Jason Garber

Tracking innovations in code and culture

I Quit Backblaze

Three reasons I quit Backblaze, the cloud backup service that lets you back up an unlimited amount of data from a single computer:

  1. Poor Backup Bouncer test results. When I restore files to my Mac, I want all the metadata too. I’m a programmer so ownership, permissions, timestamps, and symlinks are important to me on my development machine.
  2. They say they won’t store my private key anywhere, but I have to enter it on their site in order to restore files. They may keep the files decrypted for up to 7 days. I don’t want decrypted files anywhere but my computer.
  3. I’ve switched to SSDs and needed to move some infrequently-used photo libraries to an external hard drive. I can’t be sure I’ll plug it in every 30 days. The idea that my backup of those precious photos would be deleted if I forgot to plug it in scares me.

I tried out Arq and generally liked it. It has the benefits of Backblaze plus performs well in the above three areas. Amazon’s S3 reduced-redundancy pricing is a little more expensive for the amount of data that I have (85GB), but the improved peace-of-mind is worth it to me.

If Backblaze ever fixed those things, I’d probably come back because it was otherwise a good service.

Ruby Recruitment Solution: Hire an Expert to Train Developers You Already Have and Like

Like most well-qualified Ruby developers, recruiters and hiring managers contact me frequently about their open web developer positions. The secret is out that you’ll get more bang for your buck with Ruby on Rails than the Java and .NET web frameworks, so small and large companies alike are clamoring for experienced Ruby developers. I read a year or more ago that there’s a shortage of at least 1,500 Ruby developers in the United States alone. That number has probably doubled or tripled by now. Everyone faces the same frustration: top Ruby talent is hard to come by.

Benchmarking Ruby String Conversion

I have a class (Parslet::Slice, to be precise) that inherits from String but needs to be converted back to a string. Which is faster, String#to_s or String()? My hunch is the latter, but I can find out for sure in about a minute:

Deploying Octopress to Heroku With a Custom Buildpack

I’ve had apps on Heroku since 2009, but over the last year or so I’ve been deploying apps there more and more. With the advent of the Cedar stack, there’s less and less you can’t do. Compared to provisioning a virtual server, even with the help of moonshine, you can’t beat heroku create --stack cedar: boom, you have a live site with backups, logging, release management and the running of migrations and asset compilation on deploy. In just another few minutes, you can have SSL, rotating database backups, NewRelic, HopToad, cron, DNS, monitoring, and myriad other addons.

When I switched my blog from Radiant CMS to Octopress, I wanted to keep the site on Heroku. It’s free under normal scenarios and if I ever get on HackerNews or Reddit, I just have to scale up my web processes and pay a bit to keep the site responsive. If I were to be so fortunate, I wouldn’t have to scramble to set up load balancing on Linode or even wait while my slice resized. Yay cloud!

The standard method for deploying Octopress to Heroku involves generating your site, checking in the generated contents (within the public/ folder), and deploying to Heroku. As Matthew Manning noted, neither having to check in generated content nor having it generated on-the-fly is ideal. We really need to hook into Heroku’s build phase.

The Cedar stack lets you provide a buildpack for generating the app. It’s how the stack can support Node.js, Python, PHP, etc. I forked Manning’s buildpack and customized it for Octopress. Here’s what you need to do to deploy your Octopress site to Heroku: