I’ve known bits and bobs about rails for years, but I’ve never sat down and tried to force myself to be a front-to-back rails developer. It seems weird to say that, because I’ve actively loved the ruby language for years and rails has been something I’ve made a living from supporting before, but my jobs have pulled in non-rails directions (windows, perl, learning vmware, networking, linux systems administration, more perl, more vmware, then lots of security and networking). Combine that with a wonderful relationship, lots of independent interests and it’s been hard to get time together to sit down and focus on rails by itself.
I’m newly single, though, and slimming down my interests a little and I’ve got time to be pursuing some stuff I’ve had on the back burner for a long time. The first of these is forcing myself into learning rails more thoroughly, from soup to nuts.
I’ve had a few ideas for a trouble ticket application to help at work, so I decided to start by making a simple rails app that will track tickets. Each ticket is an idea I’ve had for improving the app itself, so it’s useful from day one and immediate utility tends to keep the interest.
My immediate problem stems from having written a simple test:
test "Only high priority items are returned." do
tickets = high_priority_tickets
tickets.each do |ticket|
assert(ticket.priority =~ /^high$/)
end
end
I’m making the assumption here that I can write some method high_priority_tickets which will return all tickets with a priority of high. I don’t know where to put it, though!
I’m making the bet that it goes in the model for two reasons:
- the model provides data for the controller/view
- unit tests in rails are designed to test the model, integration tests are designed for the controller (c.f. http://guides.rubyonrails.org/testing.html)
Still, it’s these kinds of small decisions I’ve not had to make before. It’s exciting getting to see my own rough edges.
Jam and Bees 