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.


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!


I decided to "role" my own... get it?

Posted on 07/26/2009

I had some spare time the other day, which doesn't happen often, so I thought I'd take advantage of it by building something useful rather than tenderizing my brain via social media like I usually do.

After hearing numerous complaints recently about shitty role/authorization implementations, I thought I'd take a stab at it, so I whipped up role_fu.  It's a rails plugin that simplifies the process of setting up role access rules for controller actions.

Check out the project page or the readme for more details.

If you've got any feedback, do me a favor and leave a comment on the project page, or just shoot me an email brentmc79(@)gmail(dot)com.


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