Archive for March, 2007

My new MacBook

Saturday, March 31st, 2007

Today my lovely wife bought me a new macbook.  Partially it is an early birthday present, partially just to get me to shut up about wanting to buy one.  I am very grateful.

It is the white bottom of the line MacBook — 512mb ram, 60gb drive, 1.83 ghz core 2 duo, dvd reader/cd burner.  Having more ram would be nice, but I figure it is probably cheaper for me to upgrade the ram myself than to pay the premium apple charges.

Now I have to figure out all of the mac keyboard shortcuts, and learn how to use quicksilver.  And get my RoR dev environment set up.  And my boss to buy me Textmate and a new laptop bag.  Back to working on those, and not just blogging.

Using form_tag

Friday, March 30th, 2007

DEPRECATION WARNING: start_form_tag is deprecated and will be removed from Rails 2.0 (use form_tag instead) See http://www.rubyonrails.org/deprecation for details.

As useful as that page is, for some reason I had some issues finding the correct usage for form_tag after seeing this message in the logs. Here is my super brief, incomplete, probably incorrect tutorial on using form_tag.

 "signin" do %>
// form code

As easy as that. I always run into problems because I forget that form_tag expects a block.

My work setup

Friday, March 30th, 2007

At work, I have two computers. One is a generic old Dell with a 17″ flat screen that I use for email, MS Office, running IE, using bizarre windows only corporate software. If I could access my exchange server through Linux, I could throw that computer away.

My actual work takes place on my Dell M60 laptop running Ubuntu. It has a 15″ monitor, and is connected to an 18″ flat screen. I use Synergy on the two systems so that my blue tooth keyboard and mouse work flawlessly between the two systems.

Since all of the programming that I do these days is in Ruby on Rails, I fire up an xterm on my laptop. I create 4 tabs in it:

  • Tab 1: my webbrick server. Yeah, I have Apache installed and configured, but I prefer to do my development using ./script/server. That way I don’t have to deal with complicated apache configurations to deal with the ~4 different sites that I have working copies of on my laptop.
  • Tab 2: my rails console. ./script/console is one of my favorite features of working in Rails. Make changes to my code, “reload!” and test away. This is 10,000x better than printf’s.
  • Tab 3: tail -f log/development.log. This one is new, but I find it very helpful. I have taken to using “logger.info” statements places like my authentication and authorization prefilters. Having my development log streaming by is helpful for watching for those messages, and it is also nice to keep my eye on the number of queries and specific queries that ActiveRecord is making. ActiveRecord can generate a huge number of queries in some circumstances and it is better to catch that now than once it is in production and doesn’t scale well.
  • Tab 4: just a shell. Some things are just easier to deal with in a shell. Creating or copying files in a shell is much faster than doing it in my IDE (if we’ll call it that…)

I do all my actual coding in Kdevelop. Basically to me it is just a nice tabbed, syntax highlighting, text editor. I used to use Radrails (based on eclipse) but there were a lot of things that annoyed me about it. Over all I think that Radrails is very usable, and has huge potential. On linux, for me, it was just not stable and fast enough for me. On my Mac I have no such complaints.

Speaking of Macs… I hate my laptop. It is unreliable. It is big and heavy. It takes forever to boot and after suspending my bluetooth stops working until I reboot. I am going to replace it with a MacBook, but my company won’t pay for it. So, until I buy one for myself, I am stuck with my dell.

Passing parameters to before_filter in Rails

Friday, March 2nd, 2007

I am currently working on the authetication/authorization functions in an application.  I would like to have the application require that a user be logged in, and check their permissions before accessing an action.

The authentication portion is pretty easy, but the authorization is turning out to be a bit trickier.  I would like to have the authorization take place in a before_filter on the controller.  However, I need to tell the filter what page to check permissions on — seems like an ideal time to pass a parameter to a before_filter.

My first attempt was not successful:

class SomeClass < ApplicationController

@page_id = 99
before_filter :authorize(@page_id)

end

(Or something like that.)  But of course, that doesn’t work.  A bit of research leads me to post on the rails mailing list.  This lead to the following code:

class SomeClass < ApplicationController

@page_id = 99
before_filter { |c| c.authorize(@page_id) }
end

To be honest, I am not entirely clear why this works.  More research to be done, but I have never claimed to know everything there is to know about Rails.