map.resources :organizations do |organization|
    organization.resources :members, :member => {:activate => :get}
  end
  
  map.resources :organizations,
    :has_many => :members

There’s a lot of debate going on around these two blocks of code. Why am I opting for the top instead of the bottom? Because there’s no documentation for the bottom! I have no idea how to add a custom, member action to the has_many style of routing.

One thing is starting to annoy me about the latest revisions to Rails. Rails developers are very opinionated and want you as a fellow developer to follow recent conventions, but how can I follow a convention if there’s no documentation to support it?

Of course, I can’t really complain because I haven’t contributed to the documentation. My point is that if DHH and the rest of the core team have strong opinions about recent changes, they should put more of an emphasis on revising documentation to get people using the right conventions.

So I’m a big fan of David Allen’s GTD System. For a long time, I’ve been looking for a personal information system that could help me get the job done.

I’ve been extremely impressed with the early versions of Things. I’m starting to get very excited about their iCal sync feature.

If you’re looking for an electronic version of David Allen’s system, this is the tightest app I’ve seen for it. I especially like the “Areas” feature, as most apps I’ve used lack this feature.

Once I have the ical feature, I will be able to sync this info with my PDA. That’s really the only problem with Things in its current build. Once I’m able to access this information on the go, I’ll feel a lot better about having an offline app for this type of organization.

I might be getting a little geeky on everyone here, but I have to share something very important to programmers. I recently noticed this in a recent Rails project I was working on (method names changed to protect the guilty)

def do_something_really_important
  #lots of complicated implementation

  rescue ApplicationError
end

Why is this some of the worst code I’ve ever seen? If something unintended goes wrong the developers would be none the wiser. Nor the potential user for that matter. If this is a crucial method this really could have disastrous effects.

Defensive design is great when it comes to exception handling, but make sure you are handle for specific exceptions intentionally. Also if you’re catching an exception, actually do something! Email an admin, log the error - create some way for the developers to get insight on what is happening. In other words, if you’re expecting a “File Not Found Error”, do this instead:

def do_something_really_important
  #lots of complicated implementation

  rescue FileNotFoundError
    #actually do something useful
end

It’s not rocket science - it is good design. Good design is what separates architects from hackers.

Kyle del.icio.us’ed me this article and I really dug it. Work has been really crazy lately - we’ve been ramping up development efforts so both coding and project management needs have increased.

Have you ever asked yourself the question: “Am I busy or productive?”. I’ve been asking myself that lately. Sometimes, less is definitely more. In the Agile Software world, there’s this whole idea of sustainable pace.

How productive are you as a developer after 60 hour workweeks and a lack of sleep? Every good developer should know when quitting is actually more productive than staying busy. If you’re burning the midnight oil and making frequent mistakes give these ideas some thought:

• Am I introducing flawed code that is going to haunt me later?
• If I’m observing many mistakes that I’m making, is it possible there’s many more I’m not realizing?
• Am I really contributing to burndown/velocity effectively?

Know when to quit! Your team members and your supervisors will thank you.

Most Rails developers know of PeepCode but I know only a few that have actually purchased a screencast from them. I’m really happy that they’ve reintroduced their year subscription. There’s no excuse now - go and buy this! After watching two or three I can say it’s already paid for itself.

Interestingly, I’m enjoying the pdf’s just as much as the screencasts. Keep it up PeepCode!

If you’re a cheapskate, start out over at RailsCasts - but if you like them, help Ryan out and buy some PeepCode material.