Archive for February, 2010

Adding Methods on Associations in Rails

Wednesday, February 17th, 2010

Many times, you may find yourself interested in moving some of your logic outside of the view and into a model, so that you can re-use it throughout your app. But sometimes, the method you may want to define needs to be on an association of two models, and not on the models themselves.

As a real world scenario, imagine you are making an online game in which two models exist, Game and Score. The Game model keeps track of when the game was started, who started it, the level of difficulty, etc. The Score model keeps track of the value of the score, the round the score was done in, and the time the score was placed. The Game model has many Score models. Obviously, when the game is over, we are going to want to be able to see the total score. But what model do we define the method on? The Game model, itself, doesn’t have any scores and a Score object only knows about itself and not all the others that belong to the parent Game object.

This is a situation where the method needs to be defined on the association of Game and Score. Anytime the value you are trying to obtain can only be calculated with a parent and a child of an association, then you need to define the method on the association.

How to define it

Turns out that defining the method is a little trivial. The has_many method, used for creating one-to-many relationships, accepts a block in which you can define methods. Inside that block, self is set to the collection of children in the relationship. So now to define your total_score method:

  class Game < ActiveRecord::Base
    has_many :scores do
      def total_score
          total = 0
          self.each { |score| total += score.value }

Then, in the app …

g = Game.create(:user_id => 1)>20)>40)>60)
# 120

Tags: , ,
Posted in Code | 2 Comments »

What’s in a deadline, really?

Thursday, February 4th, 2010

As I sit here in court, waiting patiently to fight a cell phone ticket that I am clearly guilty of, I got the opportunity to read over David Hansson’s recent post on deadlines. To recap, he stated that we should stop holding ourselves accountable to unrealistic deadlines, or better put, to deadlines that force us to sacrifice quality, testing or hours. This isn’t a new thought for any seasoned developer. While we dread the idea of slaving over late hours and patch-and-go design methodologies, we seem to constantly practice the former, and unfortunately the ladder.

While, I agree that we shouldn’t be pigeon-holing ourselves into tight deadlines, the truth is, most of the time, doing so will land you the contract, and refusing it will result in the client giving it to one of countless other developers who will gladly slave to meet that impossible deadline. So, how does one find a homeostasis where both the client and the developer are mutually happy with the quality of work and the amount of time it takes to build it?

For most development companies, three basic questions fuel the work we do, to a certain extent:

  • What do you need done?
  • How much can you can pay to get it done?
  • When do you need it done by?

Armed with these 3 answers, you can derive a general synopsis of the life-cycle of a project. For a certain type of client, the first two questions are givens: the client needs these features and they only have a certain amount budgeted to get it done. Clients generally come to you with specific demands that they typically have good reasons for (and obviously, we will intervene if our experience tells us the demands need tailoring) As for budget, that’s always a touchy subject: we are resolute in what our labor costs will be, but sometimes, clients won’t budge and you still want to help. As a result, time may be your ultimate leverage when you gain the knowledge of the different ways time can factor in to a project.

Why is your deadline?

Steve Walker and myself spend a great deal of time debating certain points of our industry in hopes of carving out a strategy we refer to as “Client-Driven Development.” The idea is to shift the paradigm of many of the assumed truths of developing software for clients. One of the facets that interests me is the concept of a deadline. To explain, here are a couple of examples.

The arbitrary deadline

Scenario: The last web company I worked for believed in the arbitrary deadline as a means to engage their employees. A new idea would be conceived by the CEO and its deadline was always “the last Friday of the month,” regardless of rational, time estimate to develop the feature, or what day of the month it currently is.

Result: The net result was a company divided by people that knew the deadline was bullshit so they lost passion for the project (and eventually the company) and people that worked feverishly to meet this deadlines because “he’s the boss.”

The open-ended deadline

Scenario: Many times, you will work with a client who “doesn’t have a deadline”. The reasons why they do not vary, but many times I feel the client thinks they are being convenient by being very open-ended.

Result: The result of offering an open-ended deadline can have two general consequences. The first is that the developer may afford the client the ability to either negotiate the features or the budget. The second is that the developer will hold you to their estimate, but the project will never get done. You all know about that project that you have right now that started over six months ago but either you haven’t finished it yet because there is no client pressure, or the client has finished providing the content or approvals, also because there is no client pressure.

Note: having an open deadline is like getting in shape without weighing yourself first: sure, you may tell yourself “the amount of weight doesn’t matter, just as long as I look good,” and you still might even loose the weight. However, knowing your starting point and agreeing on the end point is the catalyst for realistic motivation.

Event Inspired Deadline

Scenario: A very common situation is for a client to come to you and say they need a project launched by a certain date because of a certain upcoming event, where ‘event’ is paralleled by a significant date to the client’s demographic. Some examples are trade shows, monthly newsletters, cultural events (ex. launching a red version of a site by Valentine’s day), or in tandem with a new product release, to name a few.

Result: As a whole, I find I am more accepting of these deadlines because they have a black and white reason for their necessity. The issue developers have with these deadlines is that, often times, they are given without much time to develop. “We have a trade show in 2 days and we want the this new section to go live by then,” or even more painful “We have a trade show in 2 months and we want this new section to go live by then,” and then you don’t get the content for it until two days before the deadline.


My suggestion to you is not to try to treat the deadline game in a one-size-fits-all manner, because all clients and projects are different. It’s just not realistic to think that every client will agree to the one way you are going to address deadlines. I have found it much more effective to analyze what type of deadline the client has and see how I can use that as an advantage against the other main aspects of the project. Remember that while the three points of a project – features, budget, and time – may always form a triangle, there are different types of triangles based on how you handle each vertex.

Sidenote: For those curious, I got the ticket thrown out.

Joey Naylor: Dad, why is the American government the best government?
Nick Naylor: Because of our endless appeals system.

Posted in Lecture | 1 Comment »