Recently I compared the major Rails hosting providers – but as opposed to most price breakdowns I’ve read on the Internet, I opted to include provisional hourly devops time to set up and perform maintenance on the servers. For the purposes of this comparison, I only selected four providers: AWS, RackSpace, BlueBox and Heroku, and I’m assuming you use all their services (rather than combining two, say Heroku Postgres with AWS EC2 instances). I found the resulting price breakdown instructive, though interpreting them (and disagreeing with the provided hours) are left as an exercise for the reader.
Why I’m Not Applying to 37Signals (but Why You Should)
In case you haven’t heard…
Yes, it’s true: Willy Wonka is going to grant one lucky golden ticket holder a tour of the chocolate factory. And then you get to stay there until you somehow get tired of working at one of the coolest companies on planet Earth – which, to carry my analogy, would probably be as likely to happen as getting bored of eating chocolate. If you’re into Rails, you’d have to be stupid to not at least consider such an amazing opportunity.
So I did, and because I’m a programmer I carefully enumerated my thoughts. If you’re on the fence at all about taking the plunge, maybe my reasoning will help you. Or horrify you – either way, you’ll have an opinion!
Existing Rails API Solutions Suck
In the past two months, since joining Everest, I’ve spent quite a lot of time and effort researching and reviewing the various Rails API gems and I’ve come to a startling and disheartening conclusion.
They all suck.
In different ways, sure. And many have redeeming characteristics. But overall none of them do what I would consider the three most important parts of supporting a Rails API:
- Be DRY. I need versioning without copy and pasting huge swathes of code. If I want to make a query optimization in an API endpoint I shouldn’t need to browse through every version of the API, applying it to each file.
- Support views (or something like them). Rendering JSON in controllers and models is inappropriate. JSON is a representation of data: a representation of data is a view of a model. You can argue this is a presenter or serializer or whatever, and that’s fine. There are clearly places where this logic should not be, though.
- Integrate with Rails. I have an existing and complicated web application that I want to provide an API for. Probably I want to leverage the power of the Rails stack and everything I’ve installed in it, like logging, error reporting, performance metrics and so on.
Taken in that light, then, here are mini-reviews for every existing Rails API Gem I could find. And believe me, I think I found most of them. (Spoiler alert: they suck.)
Home Automation With Phillips Hue & Huey
I released v1.0.0 of huey today, adding some exciting new features: specifically, light groups and group events. Using them enabled me to quickly and easily set up a light timing schedule from one of my home machines, managed with cron (through the excellent whenever gem). In case you too would like awesome automatic light magic, here’s how to make it work.
Reachability With RubyMotion
A couple days ago I shared with a friend my code to quickly and easily do reachability checks in RubyMotion, and I figured I would post the code on my blog as well. In addition to detecting network reachability, this code suspends the operation queue when the target host is unreachable, allowing you to continue appending requests and ensuring that they will be delivered in the order they were queued.
There might be a more efficient way to do something similar, but this works for me.
Chef Cookbooks for Rails
I spent awhile trying to find other people’s Chef cookbook collections for deploying Rails applications. In the absence of anything other than old GitHub repositories, I decided to write a quick post summarizing the cookbooks I used and a few settings that made them work as I expected. I’ll go by the roles that I created to organize the cookbooks, starting with the most basic: base.
Why I Chose Chef Over Rubber
One of my mandates at Everest has been to sanitize the server build and deploy process. Provisioning every server individually with the same bash script was not exactly the height of extensibility and maintainability, and unfortunately had resulted in an enormous cluster that was very opaque: there was nearly no visibility into what the servers were actually doing. When I evaluated options to create a better process I looked at my go-to configuration management tool, rubber, in addition to Chef and Puppet. As a result of this evaluation – and surprising even myself – I ended up choosing Chef as our solution. Here’s why.
Breaking Up With GirlsGuideTo
It’s never easy to decide to move on, particularly when you’re a cofounder. It definitely feels less like a business shakeup and more like a real breakup.
But I must announce that my time at GirlsGuideTo has officially ended.
I’m proud of the work I’ve done for GirlsGuideTo. I took a decrepit, slow PHP Drupal installation and turned it into a speedy, modernized Rails application. The new GirlsGuideTo uses some incredibly modern technologies to be fast, while still being maintainable and consistent. The pages load near-instantly thanks to head.js and Turbolinks, and the Rails code is well-separated and highly tested thanks to some awesome concerns and really nifty Rack middleware.
It also features a really kickass design from my friend @LukesBeard, so it also looks great in addition to feeling great.
Though I’m moving to greener pastures, I’m sure GirlsGuideTo has a bright future ahead of them. As for me, I’m doing some work for Everest – they’re really awesome people that need their backend scaled right into infinity, and I think I’m the guy to do it for them. In fact, if you download the super cool free app or have downloaded it at launch, you’ve already touched some of my code! The best part about onboarding quickly is having code live in production almost immediately.
So keep on watching this spot for more of the same that you’ve come to expect – adrenaline-filled posts on the exciting world of server scalability and optimization.
Huey Gem Release
I pushed the first version of Huey to RubyGems (calling it 0.1.0).
It’s in a really good state right now, actually – in addition to a rather full and complete set of tests, I added a couple neat new features:
Now you can make as many changes as you like to a bulb, and then commit them all at once with
save
(alias ascommit
for your convenience).Ability to set colors as a RGB hex. So you can do
bulb.rgb = '#8FF1F5'
to get your bulb to be colored aqua. Colors in Hue are a little more pastel than you might expect, though, so exact shade matching might take a bit of experimentation.Copyright and license information.
I’ll be adding more features as I use it more, so watch the repository for changes.
Making Your Web Pages Ridiculously Fast (Without Breaking Them)
I spent a lot of time optimizing page loading speed on GirlsGuideTo. The result is pages that load almost instantly initially and on subsequent loads; and while I’m proud of the work I’ve done in getting these pages zippy, there was no real secret sauce involved. Here I’ll discuss techniques anyone can use to make their web pages load with amazing rapidity, all without breaking Google Analytics and other scripts you might already have installed.