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.

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 as commit 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.

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.

I’ve been working super hard recently, though not blogging about it, and meanwhile a lot of people have been asking me what I want for the holiday season.

Thus I’m taking a massive departure from the normal, professional tone of this blog and publishing a list of the holiday presents that would just bowl me over with joy. If you know and love me, feel free to buy any item from this list – or multiple ones if you know and love me that much.

If you don’t, then don’t worry about it! I’ll be back soon with real content that will hopefully be both pithy and edifying.

I just authored a cool little Gem that allows for automatic discovery of, and control over, the pretty nifty Phillips Hue lightbulbs. I decided to name it Huey, since I love nothing more than cute and silly names. I only spent a few hours tonight hacking it together, so I’m sure there’s a lot of room for improvement, but it works and does everything it’s supposed to and seems fairly fault tolerant; so I thought, why not announce it and fix problems when I wake up tomorrow?

I spent a frustrating hour today searching for a way to do dynamic cache counters in Rails.

The problem is best summed up in a use case. I have a model called votes. A vote can be an upvote or a downvote; I set a column called type indicating what it is. Though I call the column type there’s no need for STI here – there’s really only one model, after all. However, it is polymorphic. You can vote up any kind of content on the site. I want to cache the number of upvotes and downvotes separately for that content. Unfortunately, the out-of-the-box Rails counter mechanism doesn’t let you do this. According to the counter_cache documentation, you must either specify true or the name of the column you’re caching under. You’re out of luck if you want to change it dynamically.

This, then, is the solution I came up with to allow dynamic cache counters.

I use the wonderful elasticsearch for my searching needs. I described in previous posts how I use and test elasticsearch in general; but in my current project, I found myself using elasticsearch in a very similar way across all my models. Call me crazy, but that sounds like a concern to me!

As a result of this concern, I ended up having a really neat abstraction that allowed me to search across all my models using elastcisearch’s multi-index search functionality. The end result of this concern was not only less duplicated code; it was a useful utility function that acted on all the models that implemented it.

In my application, seed data is an unfortunate necessity. I don’t like it but it’s there, and it’s tightly integrated into many parts of the app (dropdowns, navigational links, and so on). Finding that seed data also tends to be rather ugly and long, unfortunately. Who wants to type Tag.find_by_name('Health & Wellness') or one of the finder variations every time you’re looking for something? Not me, that’s for sure. I found myself aliasing these finders constantly as class methods: so, the above would be much more easily referenced as Tag.health_wellness.

Once I started duplicating this functionality across models I knew I had a concern. This is the module I came up with to encapsulate it.

I spent awhile yesterday Googling for a Facebook-style more button with a graceful fallback: something where, if the user didn’t have JavaScript, they’d still see something sensible… but if they did, they’d get a sweet fade-in of more content appended right to the content container. Oh, and I also didn’t want to write separate views for JSON returns, so it had to deal with HTML returns and strip out the unnecessary bits.

I didn’t find anything, so I took a crack at creating it myself. This is the result.

It’s not uncommon to have login-required forms accessible to users who aren’t logged in – for example, maybe you’re trying to encourage someone to start writing some content without having to bother logging in first. Of course, they have to log in before they can post, but what happens when they push that big “post” button? Or take another example: you have a button to thumbs-up some content. Only logged-in users should be able to thumbs-up any content, but you always want to display the button. But then what happens when someone who’s not logged in presses the button? In most Rails applications, they’d be logged in, redirected back to the page they were referred from, and they’d have to click the thumbs-up again.

That sort of sucks. They already clicked it once. Why can’t we remember that?

I ran into this problem myself today in the context of the thumbs-up button. After doing some research and realizing there was no great Rails 3 solution to the problem, I decided I would roll one myself. The result is some complicated but awesome Rack middleware that I think would be pretty handy for most Rails developers.