Today I released Huey version 2.0.0! Though it contains a number of small bug fixes, the biggest change is switching away from SSDP to using the Hue’s own bridge discovery protocol. This is both faster and more extensible – now when you make the initial request for the Hue bridge IP, it takes a fraction of the time SSDP did. And you can also manually specify the IP yourself, like so:

1
2
3

Huey.configure do |config|
  config.hue_ip = '123.456.789.012'
end

With some clever port forwarding on your router combined with this new option, Huey is now usable on servers outside your local network.

SSDP is still easily enabled if you prefer that over this new method, or find that the Hue bridge discovery API is problematic. Huey just keeps getting better, but let me know if you run into an issues with it at the repository. Happy Hueing!

The title of this post might be somewhat misleading: it’s probably pretty obvious to you why your startup is failing. The same reason any business fails – you’re spending more money than you make. For some tech startups, though, living in the red is (perplexingly) a desirable state of existence. Still, you can’t stay forever in an unprofitable limbo. Eventually investors start asking awkward questions like, “When will I see a return on my investment?” and “How can you possibly be spending so much of my money without making any in return?”

Shortly afterwards they stop giving you money and then you know it isn’t long until the end.

Maybe you’re there right now, or staring down the barrel of that gun. I’ve seen it before; I know what it looks like. You’re not alone. If you haven’t gone off the cliff yet, it’s not too late to save your tech startup. You will have to make some hard decisions, though. Whether or not you can do that will determine if your company is salvageable, or if you’ll be making one of those “What I Learned As An Ex-CEO” Hacker News posts that are all the rage these days. So how do you fix your failing startup? Good question! First, we have to understand why you’re failing at all. Afterwards, we can move on to fixing it.

Overengineering is a special subset of the generalized problem of “making bad choices.” Usually overengineering is the result of one of two specific bad choices: either adding too much unnecessary bloat to something relatively simple, or creating a customized solution when many out-of-the-box alternatives already exist. After running into these problems over and over again, I’m going to quantify and identify them so that you and your friends can avoid the perils of overengineering.

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.

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!

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:

1. 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.
2. 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.
3. 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.)

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.

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.

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.

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.