BenCurtis.com

Googlebot Gotcha

2012-02-28T14:33:00Z

Did you build your site thinking that googlebot can't understand your javascript? I did, and I was a bit surprised when I learned I was wrong...

About a month ago, Starr Horne and I launched a reboot of OfficeSpace.com, which is all about helping people who are looking for office space find it. We've had a lot of fun trying out various techniques and technologies, including trying different approaches to analytics.

I was very interested in tracking on-page events, in addition to the usual page views, etc., so of course I implemented events tracking with Google Analytics. I also wanted to track those events internally, so along with the call to GA, I make a post ajax request to a Rails metal controller that logs the events in Redis. For example, when the map view gets loaded, pins get dropped on the map for buildings that have available office space, and a trigger is set on the markers to pop up a dialog with more info about each building. When the click event fires, json is fetched, the dialog is displayed, and a post is sent to the stats collecting controller to track an event for previewing a building. Since the request was a post and was triggered by javascript, I thought that only humans would trigger it. As I watched the logs, though, and saw googlebot posting to the stats tracker with data from the pages it was loading, I realized how wrong I was.

So now I'm a little wiser and a little more rigorous about keeping bots from creating data they shouldn't be creating. I'm also now more curious about just how much dynamic content googlebot can index. :)

Skipping Asset Compilation with Capistrano

2011-12-13T13:55:56Z

Capistrano has a handy task that runs rake assets:precompile for you when you are deploying your Rails 3.1 application. This gives you an easy way to get the performance boosts of having only one css file and one javascript file to load per request. The price you pay for that benefit is the amount of time it takes to run that rake task when you are deploying. There is a way to get the benefit while reducing that cost, though.

Since capistrano creates a symlink for the assets that is moved across deploys, you really don't need to compile those assets for any deploy where the assets didn't change. Instead, all you need to do is move the symlink. However, the default capistrano for compiling the assets does compile them every time, regardless of whether any assets were changed in the set of commits that you are deploying. The trick, then, is to check the list of files that were changed in the range of commits that are being deployed, and compile the assets only if assets show up in that list. And here is a code snippet that does exactly that:

It only supports git, as that's what I use, so if you use git, just drop that snippet into deploy.rb and enjoy quicker deployments.

Deploying New Relic Server Monitoring with Chef

2011-12-08T14:03:11Z

This morning I deployed New Relic's new Server Monitoring feature for the first time (I've used Scout previously). It's cool to see your server vitals right next to all your app vitals, and their interface looks attractive, to boot.

Since I deploy everything with Chef, I threw together a quick Chef recipe to automate the installation of New Relic's server monitoring agent. It has been tested with Ubuntu 10.04 LTS, and you can configure the license key in your Chef JSON config.

You can grab the recipe from my Chef recipe repository at Github.

Improvements to Bundle Watcher

2011-09-17T15:32:05Z

I just released an update to Bundle Watcher this morning that may make it a little easier to get your Ruby gem updates tracked. Now you can specify a URL where your Gemfile.lock resides, rather than having to upload a file.

You can also now see a list of bundles that your tracking, once you've logged in via Github. This list shows you at a glance which gems have been updated for your bundles.

Faker 1.0 released

2011-09-10T17:43:39Z

Earlier this week I released version 1.0 of the Faker gem. It's been about 4 years since the initial release of the gem, and the API has been fairly stable for the last couple of years, so I figured it was a good time to make the jump to 1.0. :)

This release finishes the conversion to I18n. Just about everything is in the locale files now, including the ability to define custom formats for everything -- company names, street addresses, etc. And, with the magic of method_missing, you can add new items to your locale file and have them show up as methods in the Faker classes.

The 1.0 release also settles some long-standing issues people have had with bad interaction between Faker, Rails 2.3, and locales (especially fallbacks). Though I'm not actively seeking to support Rails 2.3, I at least don't want it to be broken, so this release should cover that. Both Ruby 1.9.2 and 1.8.7 are fully supported.

Finally, I want to send out a big "thank you" to everyone (and there are a lot of them) who contributed code and ideas to this release. I really appreciate the interest shown and the work done by so many people who use and love Faker. According to rubygems.org, it has been installed over 400,000 times — over 1,000 times in the past few days!

Of course, I'm not done yet... next on the feature list is Faker::Image, which will provide an interface to all those cool fake image generator services out there. :)