I’ve worked with other caching frameworks before and while i was loathe to introduce any new complexity, it seemed that the best approach was to unify the two implementations as much as possible. That meant staying away from cache_fu, cache-money, interlock, etc. There’s been a dearth of caching libraries popping up over the past year or so. I suspect that’s because many people are using Rails internal caching. That led me to look at cache_stores, and libmemcached_store from 37 Signals. It was a breeze to implement as a drop-in replacement for MemCacheStore.

The only catch was, we’re using passenger. I wanted to make sure that LibmemcachedStore played nice with passenger’s spawning process. Here’s how to do it:

It’d be nice if all cache stores implemented a reset or disconnect method, in the meantime, we have hacks like this.

I noticed a pattern, this always happened in the morning, typically beginning around 9:15. With that, I scanned crontab to see what jobs might’ve been running around that time. I came to find a call to a rake task in our codebase: cache:fragment:delete:

So, whenever this rake task is run, it deletes the fragments. Right? Wrong.

In this case, we didn’t define a cache store for ActionController, but we did define a cache_store for ActiveSupport. So where were the fragments? In memcached. And that innocuous call to delete the fragments was flushing memcached! It turns out that when you don’t define a separate cache store for ActionController, it uses whatever cache store is configured for ActiveSupport. A quick look at the rails initializer code confirms this:

This is how it should work. Why assume a separate cache store when you’ve configured one elsewhere in your app? This makes total sense, but it was quite the gotcha when I realized what was happening. Why was the cache being cleared, you ask? Well, the key generation scheme changed within rails somewhere along the way so the specific call to delete the fragment was no longer working. All I had to do was figure out what the proper key should be, expire that fragment specifically, and all was right in the world.

There was one tricky aspect that I had to overcome, the whois gem utilizes the ruby Struct object for some of it’s underlying data. Structs are simple and lightweight, but for some reason, the json gem wasn’t handling them properly. What’s more, I didn’t really like how the json gem serialized them anyway. The workaround: Struct#hash. Struct#hash returns a struct’s contents as a hash. It’s exactly what I wanted as I felt it was a cleaner representation for JSON anyway. All that was required then was to extend Struct and implement to_json using the hash:

One other interesting tidbit was that I wanted to actually read the JSON through the browser. I decided it was best to look at the incoming headers and use that to determine the appropriate response type to send back. If you accept application/json, that’s what i give you, otherwise it comes back as test/plain. If there’s a better way to do this, please let me know, this seemed logical though:

The code is up on github if anyone want to look under the covers.

That I completely agree with. To me, it’s all about the second sentence: Tell people about it. And the tools are getting easier, but there are still some big challenges here. And opportunities too. Facebook, Twitter, YouTube, etc. are all amazingly powerful tools. These are huge vehicles for casting the net far and wide. But integrating your content with them can still be a challenge, especially for the layman.

And notifying search engines of the pages on your site is whole other ball of wax. One of the more challenging projects I undertook at Fanzter was generating our sitemap files. As our sites grew, the number of pages in our index just got absolutely insane. A nightly job just couldn’t hack it anymore and needed to be completely rewritten. There are quite a few plugins written to tackle this problem. I haven’t done a side by side comparison or tried any of these out yet, but I’m eager to. Ultimately custom code is often needed for this sort of thing, code that exactly matches your content and your application. And that is far from easy.

The other thing that large textboxes does is eliminate other possibilities for these pages, like using the sign up form as a qualifier. Joshua Porter, the author of that article also recently gave a presentation that has really inspired me lately. Highly recommended.

I’ve found that I pay a lot more attention to Twitter trends this way. Twitter has become my go-to for what’s happening with the things I’m interested in. It’s most fun to check out during Yankees games these days – I hope that doesn’t change for a few more weeks! Go Yankees!

Also, for Twitter on the go, check out Tweetie 2, it’s awesome.

It fits the site’s namesake perfectly and adds an air of whimzy that I’d love to see a bit more of.

But now that August rolls around, it’s time to slow things down a bit. Entourage is finally back on and it won’t be long before football kicks off and playoff baseball (Go Yankees!).

It’s a good time to reflect a bit. It’s also a good time to laugh at these awesome Dos Equis ads!