brentmc79.com - RSS Feed

Snow Leopard Rails Dev Setup Guides

Fri, 05 Mar 2010 02:36:39 +0000

You can never have too many.

Much like every new version of OSX, there have been a plethora of "How to install BLANK on Snow Leopard" blog posts and walk-throughs detailing all the little tips and tricks around how to install some tool or piece of software. Having a lot of options is awesome, but in the words of the great Biggie Smalls, "mo' blog posts, mo' problems".

That IS how it went, right?

Anyway, with all of these walk-throughs, how do you know which ones are good, and which one just suck. Well, you don't really...

So here's a list of a few [confirmed] valid and useful dev setup walk-throughs:

First, this is actually a series of posts, as opposed to one single write-up. Actually, its not even a series of posts. Its just the search results for 'Snow Leopard' on the Hive Logic site. So really, its only the first 3-5 posts that matter.

http://hivelogic.com/search/results/a7a831b978f2667fa301ea095d3d8fa7

This is the route that I personally followed after a fresh install of Snow Leopard, and I had everything up and running in no time.

Next, Robby On Rails did a thorough and entertaining post on Snow Leopard Rails dev env setup, or SLRDESU for short. Acronyms make everything better (AMEB). I don't know about you, but Robby's older post about getting setup with Passenger came in handy for me on more than one occasion.

http://www.robbyonrails.com/articles/2010/02/08/installing-ruby-on-rails-passenger-postgresql-mysql-oh-my-zsh-on-snow-leopard-fourth-edition

His latest post covers everything from start to finish, and he even included a few video to pass the time while waiting for binaries to build and whatnot. I haven't personally used this walk-through, but based on my previous experience with Robby's posts, and the recommendation from coworkers, I'm sure it'll get you where you need to be.

Another noteworthy mention comes from the guys over at Thoughtbot, the makers of such wonderful tools as Shoulda, Paperclip, and Factory Girl. Their robot-laden guide goes beyond just Rails/dev-related stuff, and covers the likes of several generally useful OSX tools. Things like Quicksilver, Fluid, and Firefox/Firebug.

http://robots.thoughtbot.com/post/159805668/2009-rubyists-guide-to-a-mac-os-x-development

This is another one that I haven't personally used, but I think we can trust the guys over at Thoughtbot. After all, their company reputation depends on it!

So there you have it. Three different hand-holding recipes for getting you set up on Snow Leopard. If you haven't upgraded yet, what're you waiting for? Get to it!

Geoip_city gem install on Snow Leopard

Mon, 28 Dec 2009 19:15:07 +0000

I had recently upgraded my MacBook Pro to OS X 10.6 Snow Leopard, and I was in the process of reinstalling most of the ruby gems. The geoip_city gem was the only one that gave me a bit of trouble, so I figured I'd post how I got it working.

Go here and download the latest source for the GeoIP C api
Untar the source, cd into the directory
Run ./configure
Then run make && sudo make install
Finally, run sudo env ARCHFLAGS="-arch x86_64" gem install geoip_city -- --with-geoip-dir=/opt/GeoIP

The key is the ARCHFLAGS parameter in the last step. This indicates the native extensions are to be built for a 64 bit architecture.

Also, if you need the free GeoIP City Lite database, you can find it here. I hope this helps.

IE7's Accept Header And Rails respond_to Bug

Wed, 28 Oct 2009 01:26:30 +0000

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 192.168.1.108 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'
    /Library/Ruby/Gems/1.8/gems/passenger-2.2.5/bin/passenger-spawn-server:61

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

Tue, 27 Oct 2009 21:03:24 +0000

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

Sat, 15 Aug 2009 20:01:38 +0000

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

Thu, 13 Aug 2009 21:30:40 +0000

I 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?

Sun, 26 Jul 2009 20:19:36 +0000

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

Wed, 10 Jun 2009 02:13:41 +0000

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 flash.now[: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.new(params[:thing])
  if @thing.save
    flash[:notice] = "Oh snap!  You created a thing!"
    redirect_to @thing
  else
    flash.now[:error] = "Damn dog, you messed up"
    render :action => :new
  end
end

Notice how when the thing save without errors we use flash[] and redirect, but when there are errors we use flash.now[] 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...

hookers, nuts, and ActiveRecord callbacks

Thu, 07 May 2009 20:44:36 +0000

Remember my post from a few weeks back about temporarily disabling ActiveRecord callbacks? Well, I decided to extend the functionality a bit and wrap it all up in a plugin.

You can now specify one or more callbacks to disable, or specify nothing and disable all callbacks by default.

You can check out the project page or jump over to the Github repo.

Git checkout woes [updated]

Wed, 06 May 2009 14:49:42 +0000

I ran into a strange issue while attempting to checkout a remote tracking branch of an Intridea project earlier today, so I thought I'd post up my work around.

I ran my normal checkout command, like so...

brent:~/Intridea/earthaid[master]$ git checkout -b prod origin/prod

which resulted in this error message

fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/prod' which can not be resolved as commit

After a bit of googling, I'm still not sure of the cause as most of the search results were related to issues around deploying tags, and I was merely attempting a checkout. What I did find out was that I could specify the start point of my new branch by the revision/commit sha instead of the remote branch name, like so...

brent:~/Intridea/earthaid[master]$ git branch prod 02314583a99abdc276cde968c20babbadd23
brent:~/Intridea/earthaid[master]$ gc prod
Switched to branch "prod"
brent:~/Intridea/earthaid[prod]$

Once I had applied my changes, I just had to make sure to push them to the proper branch.

[update]

Ok, I'm a retard. About a minute or two after I typed up this post, it occurred to me that Git couldn't resolve the remote branch name because I hadn't pulled first. Yeah, that's right. All I need to do was pull and then everything worked properly.