Photo-1 Photo-2 Photo-3 Photo-4 Photo-5 Photo-6



Full-time web developer. Part-time smart ass.

I'm Brent Collier.

After a year and a half as an engineer on Twitter's Trust & Safety team, I'm looking for my next gig. Contact me if you know of something interesting.


IE7's Accept Header And Rails respond_to Bug

Posted on 10/28/2009

Earlier this afternoon, I was debugging an ajax call that consistently resulted in an error, but only in IE.  Checking the log file, I found this:

Processing ApplicationController#index (for at 2009-10-27 14:37:03) [GET]
Session ID: ddde16cf83baca85a81e9fb0772c2844
Parameters: {"format"=>"js", "page"=>"1"}

ActionController::MethodNotAllowed (Only get, head, post, put, and delete requests are allowed.):
/vendor/rails/actionpack/lib/action_controller/routing/recognition_optimisation.rb:65:in `recognize_path'
/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:384:in `recognize'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:154:in `handle_request'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:107:in `dispatch'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:104:in `synchronize'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:104:in `dispatch'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:120:in `dispatch_cgi'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:35:in `dispatch'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/request_handler.rb:50:in `process_request'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:336:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb:183:in `safe_fork'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:163:in `start'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:213:in `start'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'

Rendering /Users/brent/Intridea/project/vendor/rails/actionpack/lib/action_controller/templates/rescues/layout.erb (method_not_allowed)

WTF?  That told me a whole lotta nothing.

First of all, it was blowing up before it even got into the application code, which was was strange because it worked just fine in Firefox, Safari, etc.  Second, I checked the response body and it was returning html.  Html?  The format is clearly specified as "js" in the request parameters.  Double-checking the controller code, there was definitely a respond_to block with format.js, so why was it returning html?

I showed this to one of my coworkers and he asked if I had tried switching the format calls in the respond_to block.  There were two, one for html and one for javascript.  I switched them up, and put the format.js first.  I reloaded the page, and what do you know, it worked!  No error.  Again, wtf?  He told me that this same bug had kicked his ass on a previous project.

Aparently, IE7 isn't specific about what sort of response it expects in the accept header.  This causes Rails to merely return the first format that it comes to.  In my case, the html.

So if you're not seeing the format that you're expecting when testing with IE7, try reordering the format calls in the respond_to block.


Access Your Passenger App From Windows

Posted on 10/27/2009

Eww, Windows?

Yeah, I said it.  As we all know, there's a million and one schmucks out there still rockin' Internet Explorer as their default browser.  That means if you want that spreadsheet-in-the-cloud app you've been working on to hit critical mass, you better test it in IE.

If you're like me, then you've recently started running some or all of your apps locally via Passenger.  This can cause a bit of a problem when it comes time to test in IE.  At least, it did for me anyway.

I use Parallels for my Windows testing, and an old version at that.  From what I hear, VMWare is better, but I'm too cheap to buy it and I just don't really care that much.  Prior to using Passenger locally, I would just point IE at my mac's IP address, port 3000, and everything was kosher.  Well, with Passenger, that no worky.

Now, I'm sure there's probably a way to configure Parallels to allow me to test a Passenger app, but from what I can tell that either requires an updated version of Parallels or more time Googling than I'm willing to spend.

I knew that I could access my local Apach instance from any machine on my home network, so I figured there's got to be a way to hit my Passenger apps since they're running under that same Apach instance.  With a little help from a fellow Intridean, I got it working.

Here's what you do:

1. Set your app up in Passenger, like you normally would.  I use the pref pane.


2. Determine you mac's IP address.  An easy way is to look in the sharing section of the System Preferences.


3. On your Windows machine, add an entry to the hosts file with your mac's IP address and the app's domain (local) domain name.  The host file is in C:\WINDOWS\system32\drivers\etc.


That's it!  Point IE at http://yourapp.local and you should be golden.  This will work for subdomains also, assuming you've added the *.yourapp.local alias to you Passenger conf.


Now in mobile format...

Posted on 08/15/2009


Out of sheer boredom last night, I decided to whip up a mobile view for my blog.

It was extremely easy thanks to the mobile-fu plugin by my friend Brendan.  I also found a few tips and tricks from this post on the Engage Interactive blog such as how to handle orientation changes and how to specify an image for home screen bookmarks.

I did most of my testing via the iPhone Simulator from the SDK and also a Fluid browser which allows you to specify mobile safari as the user agent, giving you the proper look, and you can use Safari's built-in Firebug-like tools.

If you've got an iPhone, give it a look...


iPhone hack day at Viget Labs

Posted on 08/13/2009

photo.jpgI recently spent a day hanging out with a few of the guys at Viget Labs hacking on the iPhone.  Ben Scofield, the Technology Director at Viget Labs, was leading an iPhone development primer for a few of Viget's finest, and they were nice enough to let a handful of "outsiders" join the fun.

My iPhone development experience at that point was very minimal.  I had done a few online tutorials and walk-throughs, but nowhere near enough to really understand what I was doing.  On top of that, my Objective-C knowledge was pretty much non-existant.  Fortunately, none of this was a problem.

We spent the first half of the day going over the basics.  Ben walked us through Xcode and Interface Builder, and we talked about basic project layout, the different types of iPhone apps (list, view, and navigation-based, etc).

We then broke off into small groups, pairs mostly, to do a little hacking.  David Eisinger and myself put our heads together on something amazing.  The Text-EmBIGiner, we called it (or something like that).  Picture this, a text field, a button, and a label.  You enter your text, hit the buttom, and BAM -- the label is updated with your text.  Fucking amazing.  We thought so at least.  Many high-fives were had.

Lunch was provided in the form of Amante Pizza.  Thanks Viget!

In the afternoon we moved on to talk about ways of makin iPhone development less painful.  In other words, removing the Objective-C.  We briefly talked about Rhomobile, an open source framwork for building cross-platform mobile apps.

The remainder of the day was spent talking about and playing with two other frameworks, Appcelerator's Titanium and the open source PhoneGap.  Both frameworks allow you to build your app using primarily HTML and javascript, but they still give you access to the iPhone native controls and features.  They were very cool and I could definitely see myself playing with these more in the future.

Overall it was a really fun day, and I'm looking forward to putting my new knowledge to good use.

Thanks again Viget!