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.


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


properly using the flash

Posted on 06/10/2009

Are those pants made of mirrors, because I can see myself in them...

No, I'm not going to tell you how to seduce the comic book superhero with an evening of dinner, cocktails, and smooth talk while demonstrating impeccable manners and etiquette.

What I am going to tell you is how to correctly use the handy Rails tool for passing objects between actions.  Now, this is no huge secret or stunningly clever trick.  In fact, you probably already know what I'm about to tell you.  It's just one of those things that I never think to do until after it's a problem.

In the typical Rails app, there a snippet/partial/whatever that displays anything from the flash hash with either :notice or :error keys.  If, in your controller action, you set flash[:notice] equal to some message and then redirect to another action, that message will persist through the redirect and get displayed on the subsequent view.

Here's the problem.  If, in your action, you just render a view template instead of redirecting, then the user will see that message like you intended but it will also still remain on the following request which may or may not be confusing.  Fortunately, there's an easy way to avoid this.

If you know you'll be redirecting, then there's nothing to worry about.  Business as usual.  But if you're not redirecting, just rendering a view, then you can use[:key].  The 'now' method only maintains the flash contents through the current request and is cleared before the next action.  Check it out.

def create
      @thing =[:thing])
        flash[:notice] = "Oh snap!  You created a thing!"
        redirect_to @thing
      else[:error] = "Damn dog, you messed up"
        render :action => :new

Notice how when the thing save without errors we use flash[] and redirect, but when there are errors we use[] and there's no redirect.  This will keep your app users from seeing any strance, out of place errors.

So that's it.  Like I said, it's nothing monumental.  As you were...