» Uncategorized of mice and pen

May 26 2011

Uncategorized

Manually generating #yeg trash data

Unfortunately Alertzy is running out of the garbage pickup data that was published by the City of Edmonton on their open data catalogue. I’ve been assured that the data will be up shortly, but our data was set to run out on May 31st and that was starting to get a little too close for my comfort.

I wrote a quick rake task (Alertzy runs on Rails) to generate the data for June 2011 while we wait for the data catalogue to get up and running. I encourage anyone to borrow the code (and point out any mistakes they find!) if they are in a similar position. The code can be found here:

namespace :alertzy do
  desc "Populate June 2011 data"
  task :populate_june =&gt; :environment do
    generate_june_data
  end
end
 
def generate_june_data
  mondays = [6,13,20,27]
  tuesdays = [7,14,21,28]
  wednesdays = [1,8,15,22,29]
  thursdays = [2,9,16,23,30]
  fridays = [3,10,17,24]
 
  mondays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  tuesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  wednesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  thursdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  fridays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
 
  mondays.each do |date|
    [{:zone =&gt; "D", :day =&gt; 5},
     {:zone =&gt; "D", :day =&gt; 6},
     {:zone =&gt; "D", :day =&gt; 7}].each do |zone|
       GarbagePickup.create(:zone =&gt; zone[:zone], :day =&gt; zone[:day], :pickup_date =&gt; date)
    end
  end
  tuesdays.each do |date|
    [{:zone =&gt; "E", :day =&gt; 7},
     {:zone =&gt; "E", :day =&gt; 8}].each do |zone|
       GarbagePickup.create(:zone =&gt; zone[:zone], :day =&gt; zone[:day], :pickup_date =&gt; date)
    end
  end
  wednesdays.each do |date|
    [{:zone =&gt; "A", :day =&gt; 1},
     {:zone =&gt; "A", :day =&gt; 2}].each do |zone|
       GarbagePickup.create(:zone =&gt; zone[:zone], :day =&gt; zone[:day], :pickup_date =&gt; date)
    end
  end
  thursdays.each do |date|
    [{:zone =&gt; "B", :day =&gt; 2},
     {:zone =&gt; "B", :day =&gt; 3},
     {:zone =&gt; "B", :day =&gt; 4}].each do |zone|
       GarbagePickup.create(:zone =&gt; zone[:zone], :day =&gt; zone[:day], :pickup_date =&gt; date)
    end
  end
  fridays.each do |date|
    [{:zone =&gt; "C", :day =&gt; 4},
     {:zone =&gt; "C", :day =&gt; 5}].each do |zone|
       GarbagePickup.create(:zone =&gt; zone[:zone], :day =&gt; zone[:day], :pickup_date =&gt; date)
    end
  end
end

Tagged #yeg, Alertzy, code, gist, Rails, rake

Apr 15 2011

Leave a comment

Uncategorized

Blackberry CEO’s not getting treated “fair”

There seems to be a theme the dynamic co-CEO duo of Jim Balsillie and Mike Lazaridis are going for in the media lately. Techcrunch just ran an article discussing the somewhat unfavorable early reviews for the playbook where they quote Jim Balsillie, and the BBC is airing clips from an interview with Mike Lazaridis where issues of security in India and the middle east are discussed. In both cases each half of the duo seemed to think they are not being treated fairly with Balsillie responding to statements about the playbook with “I don’t think that’s fair", and Lazaridis responding to questions with "that's just not fair". This comes across to me as somewhat comical. Why this pair thinks that the rest of the world has some obligation to treat them in a "fair" manner is beyond me, and further more why they think the appropriate way to respond is by calling the world out is even more confusing.

RIM is clearly facing an increasingly challenging market where they are facing competition from giants where they long enjoyed little or none. The only way they are going to remain competitive in such a market is to take an assertive stance. If reviews for your device aren't what you hoped they should be, then take that as an opportunity to engage in authentic dialogue with your reviewers and customer base. If there are concerns over the security of devices, then use this as an opportunity to advocate for the security of your device relative to your competitors. In both cases by responding with such a weak claim to fairness they are fundamentally failing to control the message.

I have a huge amount of respect for RIM and what they have accomplished. They have established a global brand, and created the concept of the smartphone. I want to see them continue to succeed and show that a Canadian company can compete against the US based gorilla's, but this is not the way to accomplish that.

Mar 22 2011

Leave a comment

Uncategorized

Creating a branch of a repo on GitHub

This is a simple thing, but it took me some digging to find some straightforward instructions. For my own future use and hopefully to save some others the same searching here they are:

1. Make sure your local repo is up to date

git pull origin master

2. Create a local branch

git checkout -b [local branch name]

3. Perform your changes to your new local branch.

4. When ready to commit to github:

- If you want the github branch name to match your local name:

git push origin [local branch name]

- If you want the github branch name to be different than the local name:

git push origin [local branch name]:[remote branch name]

Also, as a bonus, to delete a remote branch use:

git push origin :[remote branch name]

Thanks to Joe Savak and his post here which I based my instructions on.

Tagged branch, create, git, github

Mar 16 2011

Leave a comment

Uncategorized

The Social Exodus

There is a recent trend of people ‘quitting’ facebook. Usually this action is accompanied by some form of attention fetching dramatic blog post or video where the remaining of ‘us’, the schmucks still using facebook, are referred to as drones or some similarly derisive term. (Here’s a great example I found through britl) I’ve recently come to the conclusion that this annoys me, and if you feel your attention span is up to the task I’ll spare a few paragraphs to expand on the theme.

Thanks to the marketing campaign for “The Social Network”, we’re all now very familiar with the fact that Facebook has over 500 million users. In Canada there are over 17 million users, meaning over 60% of Canadians currently use Facebook (checkfacebook.com). Not to argue that just because everyone else is doing it you should, this means that there is a good chance you can find almost anyone on Facebook. When you want to get ahold of an old friend you haven’t seen in years, a past coworker, or a friend of a friend you met at that party last weekend Facebook gives you a convenient way to do that. With more and more people discarding their landlines in favour of cellphones, Facebook offers a timely alternative to the whitepages.

Usually when people make their declarations of independence, one of their main complaints is the detritus in their news feed. ”I don’t care if you need help on your farm.”, or “I don’t care what you had for breakfast.”. Aside from the fact that Facebook allows you to easily remove all future posts from a given user from your news feed, there is an even easier solution to this problem; just don’t read your news feed!

Personally the main features I make use of on Facebook are the messages and the events. When I log into Facebook it takes me a total of 10 seconds to check if I have a new message or invites, and then I can get back to the non-social aspects of my life. If you’re planning on throwing a party, being able to send out a mass invite to everyone’s Facebook account is an incredibly convenient way to get the word out. In deleting your account your are in-fact creating an inconvenience for your friends and contacts. It seems the belief that “I’m important enough that you should remember that I’m an exception and go out of your way for me” is one consisent with the psycological make-up of a typical Facebook quitter.

Finally, my greatest annoyance with the Facebook quitter is their patronising attitude to the “attention starved masses”. Their complete confidence that all of those still using the service do so only because they have the neurotic need to share every aspect of their life with the world. While such people certainly exist, generalizing the rest of us is comparably fair to calling anyone who ever drinks alcohol or walks into a casino a destructive addict. The greatest irony of this is the need for the Facebook quitter to constantly share with everyone how superior they are because they don’t need to constantly share with everyone.

I have yet to find a real justification for the deletion of a Facebook account. There is a happy middle-ground between being a drooling, locked in the basement Facebook stalker, and pressing pulling the dramatic delete account switch. However, if you do feel the need to take the action please have the decency to try and not act so smug about it. Yes, there is sometimes merit in moving against the current, but if you insist on staring down your nose at the rest of us at least come to the debate packing some good arguments.

Tagged facebook, leaving facebook, pet peeve, quitting facebook, rant, social networking

Sep 14 2010

4 Comments

Uncategorized

Apps4Edmonton – Open Data App Competition

If you follow my blog than you’re already aware that I entered an application called Alertzy in the City of Edmonton‘s Apps4Edmonton competition. Tomorrow Chris Moore (@chrisj_moore), Edmonton’s CIO will be announcing the winners to the competition. I thought this would be a good time for me to express some of my personal views on the competition, so that it’s clear that my opinions aren’t influenced by any of the outcomes. I’d also like to take this opportunity to express my gratitude to the City of Edmonton for holding the competition, and for all the developers involved in the competition for showing what a creative and vibrant development community Edmonton has.

What worked!

Lots of submissions

I’m sure I’m not the only one who was both surprised and impressed with the number of applications submitted into the competition. There are a wide variety of applications, on a wide variety of platforms. Some of them showed some great creativity, and I’m sure will continue to grow into successful applications.

Great prizes

This was likely one of the contributing factors to the number of submissions into the competition. I really applaud the City of Edmonton for their progressive IT policy, and the vision to take a risk and invest $50,000 in prizes into the competition. It would be nice to believe that the same quality and quantity of applications would have been possible without the monetary incentive, but there’s nothing like a little cash to motivate!

Good use of social media

For those active on twitter there was an almost constant flow of traffic on the #apps4edmonton hash tag both by administrators, developers, users, etc. It was great to see this temporary community pop-up around this competition.

Where things might be improved

Community Voting System

Having community voting as part of the competition might have seemed like a good idea on paper, but didn’t really seem to pan out in reality. Due to the limited size of the sample size of votes, it really did devolve into a “popularity contest”. For Alertzy I can testify that we beat the pavement to recruit anyone and everyone we knew or used to know in Edmonton to vote for us. I can only assume other competitors went through similar processes. I would suggest that having a separate mini-competition with a small prize for the “community favorite” to be awarded to the App with the most votes would have removed the “popularity contest” from the main competition.

Categories

The current contest used categories consistent with the plans of the City of Edmonton’s new City Vision. This was a cool idea, but unfortunately we only had access to certain data sets, and consequently it was much more difficult to develop applicable apps for many of the categories. I think categories aligned along other lines (for example technology such as Web App, iPhone App, Android App, etc) would allow for a more balanced distribution.

Clarity of Rules

The rules for the competition in regards to dates were often somewhat vague, and adhered to. The community votes are the best example of this issue. The voting was said to end on “FRIDAY, SEPTEMBER 10, 2010″, without clearly specifying when during this day this voting would end. This time also came and went without any indication of a closing of voting on the site. There was also no clear indication that the “likes” on the contest website were the “community votes” referred to in the rules.

Another issue of contention was whether modification of applications during the two weeks of voting and judging was allowed within the rules. For those who looked closely the following could be found in the FAQ:

Feel free to change the app through the course of the competition. Just remembered that you will be judged on the app that exits at the close of the competition (11:59:59 a.m. MDT on Friday, August 27, 2010).

However, the ability of the judges to be able to judge an application based on what was there exactly at a given time is questionable.

Conclusion!

I want to make it cear that I’m not complaining about the competition. I applaud the City for it’s efforts and for providing this platform for Edmonton developers to create and share. I hope that my feedback can help improve the competition if the City chooses to offer a similar event again, or that it may help other city’s or organizations in similar competitions.

Best of luck to all entries. I’ll see everyone at the event tomorrow evening!

Tagged Alertzy, Application Competition, Apps4Edmonton, Chris Moore, City of Edmonton, Edmonton, Open Government, OpenData, OpenGov, Programming

Sep 06 2010

Leave a comment

Uncategorized

Rails Host Review – (the good) SliceHost

As I explained in my earlier post berating HostingRails, I built a project for the City of Edmonton’s Apps4Edmonton contest in Ruby on Rails called Alertzy. In order to make our project live, we needed to find a host for it. Our initial host fell incredibly flat, so in our second iteration we made sure to perform more research into our available options. We were initially looking for what I would call a “Rails Host”, as in a hosting provider who gives you an out of the box solution ready for rails hosting. Under this criteria we found a few potential options, but then we stumbled upon SliceHost.

SliceHost Review

I’ll summarize my impressions of slicehost here:

Pros: Very fast setup, very good performance, very professional

Cons: Start from a blank image on a VPS

Our intention was not to use a VPS provider who didn’t provide an out of the box rails compatible solution. The reviews for SliceHost, however, were just too good to ignore. All the reviews which we were able to find for this hosting provider were positive, so we decided we had to give them a shot.

It is important to understand that SliceHost is not so much a Rails hosting provider, as a generic VPS hosting provider. They simply provide you with a “slice” which has certain performance metrics and a blank OS install on it, and then it is up to you to configure the server to do what you would like it to do. This has the advantage of complete freedom (SliceHost would prove as effective a PHP host as they are a Rails host), but comes at the cost of configuration.

With our decision to give SliceHost a try, we proceeded to go through SliceHost’s registration and payment process. Their cheapest slice starts at $20, but we opted to go for their $25 plan which got us 384 MB of RAM, 15GB of storage, and 225GB of bandwidth. For some reason we flagged something in their system and had to go through an additional verification step. This process was completed promptly by SliceHost, and our account was online and operational within 45 minutes of the start of the process.

With our account in place we now had access to their control panel, where you are able to configure your DNS as well as choose an operating system for your Slice and launch it. The speed with which a new slice comes online impressed me greatly. From the time of choosing the operating system and launching it, it takes only ~20 seconds before you are ready to start connect to and start configuring your slice.

Unfortunately the next step of this process involving configuring our Slice to run Rails proved to be very difficult. This was in no way SliceHost’s fault as this process is exactly the same as configuring Rails to run on any system, but the convenience of having a ready made image to use would be an advantage of using another Rails specific host. The tutorials that I was able to find for configuring Rails to run on a SliceHost VPS were out of date and didn’t work with the more recent versions of Ruby and Rails. (I will try and put a tutorial outlining my own experiences online in the near future). I opted to use Capistrano and Deprec to deploy Rails on the new server, and due to the same shifts in versions this proved to be quite a headache to deploy on the Ubuntu 10.04 server we had opted to run. It took me approximately 10 hours to resolve all the bugs in the deprec scripts to where the deployment could fully run.

Once I had Capistrano and Deprec functioning I was able to deploy our site to SliceHost. Finally being able to access our site on a good host with great performance was more than sufficient reward for the past day of struggle deploying Rails! The difference between HostingRails and SliceHost was truly night and day, and we’ve received very good feedback on the responsiveness of our site.

In conclusion, I had a hard time deploying Rails, but in no way was this the fault of SliceHost. In everything that is their responsibility, SliceHost has so far delivered either up to, or more often exceeding my expectations. I intend to use them as my default host for similar projects going forward. If you would like to check the responsiveness of our site, go check out www.alertzy.com which is running off our slice.

Tagged Alertzy, Capistrano, Deprec, Hosting, HostingRails, Review, RoR, Ruby, Ruby on Rails, Slice, SliceHost, Ubuntu, Virtual Private Server, VPS

Aug 25 2010

6 Comments

Uncategorized

Rails Host Review – (the bad) HostingRails

I am currently working on a project for the City of Edmonton’s Apps4Edmonton contest. When we initially started looking for hosts we made the decision that we would use a cheap host for our initial deployment, and then migrate over to something faster when it was justified. Our site Alertzy is mostly a web portal for people to configure settings for text messages, so we didn’t expect the load to be high.

After looking through the available options, we initially decided to go with www.hostingrails.com.

HostingRails Review

At the risk that some might not read this entire review, I’ll summarize our experience here:

Pros: Friendly, fast support. Very Cheap.

Cons: Painfully poor server performance. False advertising on website. Bad upgrading support. Outdated support articles. Blacklisted IP’s for e-mail.

We initially went with Hosting Rails’ Shared hosting option. For $8 we got 10 GB of space, 100 GB, and migraines. The initial sign-up process was unexceptional, but things went downhill from there. We naturally went to Google and searched for articles on deploying a Rails application onto hostingrails.com, and quickly found an article on hosting rails wiki “How to deploy a Rails application on HostingRails.com”. Unfortunately this article which was the first hit on google is archaically out of date, and we wasted hours trying to get its procedure to work. We created a support ticket for help with a step of this procedure, and this was our first experience with the knowledgable, fast, and friendly support. We were quickly straightened out, and started working through the much easier and up to date process in the more hidden article on their wiki “How to deploy a Rails app with Passenger”.

With this updated procedure in hand and the occasional promptly answered support ticket we soon had our application online (I should point out that this great support response was happening at 4 in the morning on a Saturday night!). Unfortunately this accomplishment only led us to experience more issues. It was quickly apparent that the performance of the server just wasn’t going to cut it. At times the site was snappy, but at other times a page load could take upwards of 20 seconds. As this is shared hosting some performance variance is to be expected, but this was well beyond acceptable.

Continuing our deployment (with our fingers crossed that performance would improve once passenger got up to speed), we then worked on deploying e-mail. I configured SPF and domain keys to try and ensure our outgoing e-mails wouldn’t end up in junk bins, but unfortunately despite both of these passing, our e-mail was still getting junked on gmail. Having a bad feeling about this I performed a blacklist search on our IP address, and sure enough it was blacklisted. We created a support ticket, but unfortunately received a very apathetic response:

We can request a removal from the blacklist, but due to compromised accounts and other customers sending spam, the blacklist is almost always reinstated shortly after having it removed.

Being the resourceful chaps we are, we moved our e-mail over to Google Apps, and kept on moving along. Finally we had our application fully deployed, but had to come to the conclusion that the performance on the shared server wasn’t going to cut it, and that we’d need to move to a VPS to avoid being embarrassed at our site’s speed. At this point we could have looked at other hosting options, but we had been very impressed with the support thus far and were convinced that VPS would solve our performance problems and we could move on.

We were very optimistic about the migration to VPS, as hostingrails.com states on their site they are “experts in scaling Rails applications from shared to VPS and multi-server dedicated environments”. They also state they provide a “Ruby on Rails Image Ready to Roll”, which had all the software we would need pre-installed. Unfortunately both of these statements turned out to be false.

After a painful account upgrade process with broken e-mail confirmation links and confusing billing we finally got a server online, only to find that it was a completely blank CentOS install with none of the functionality we had been told would be present. At this point our shared hosting was already down, so we were understandably anxious to get our site back online. We sent in another support ticket (about our 5th of the migration process) asking where the stated functionality was. We patiently waited about an hour with no response, and found that our support request had been escalated to a level 2 request. Deciding that no response would likely be forthcoming until morning we decided to call it a night.

In the morning we did in fact get a response, but it was not what we were hoping for.

I apologize for the inconvenience, but the VPS Rails image that was used previously has become very out of date and is no longer offered the image that is currently on your VPS is the standard image all VPS accounts receive

At this point we had had enough. We picked up our bags and decided to move elsewhere. This time we did better research before choosing a host, and ended up at Slicehost. I will do a follow-up post with a review of our experiences on Slicehost once we have been there longer, but so far the experience has been a dream relative to our nightmare with HostingRails.

[update] HostingRails.com has since removed the Ready to Roll image from their list of features; likely do to our experience.

Tagged Blacklist, HostingRails, HostingRails.com, Rails Hosting, Review, RoR, Ruby on Rails, Shared Hosting, SliceHost, Support, Virtual Private Server, VPS

Aug 20 2010

2 Comments

Uncategorized

Ruby on Rails – Disabling a select tag using the select helper

There is a bit of a subtlety to this, and it took me a while to figure this out. If I used the select_tag helper I was able to disable the select menu, but using comparable code with the select helper it wouldn’t be disabled.

<% options= ['one', 'two', 'three', 'four'] %>
 
<%= select_tag :content, options_for_select(options), :disabled => true %><br />
<%= f.select :content, options, :disabled => true %>

Here my select_tag would be disabled like I wanted, but the f.select would not be. This made me quite perplexed, and with more research I discovered it’s because the “disabled” option for the select helper has been mapped to allow the developer to disable specific elements. For example, this code similarly yields differing behavior:

<% options= ['one', 'two', 'three', 'four'] %>
<% disabled_options= ['two', 'four'] %>
 
<%= select_tag :content, options_for_select(options), :disabled => disabled_options %><br />
<%= f.select :content, options, :disabled => disabled_options %>

In the case of the select_tag helper, the menu is still disabled as the disabled_options array will evaluate to true. For the select helper, however, the disabled_options array will tell the helper to set the options that match elements of the array to disabled. This is where I remained stuck for a while, not being able to figure out a way to use the select helper to disable the menu. Then looking more closely at the API documentation, I noticed a difference between the two helpers.

select_tag(name, option_tags = nil, options = {})

select(object, method, choices, options = {}, html_options = {})

The select helper has an additional set of parameters called “html_options” after the options. The select_tag helper conversely simply uses any parameters in its options array that don’t match expected options as html attributes. Based on this I wondered if I passed a hash array for the options parameter, if I could explicitly pass disabled as an html option, as follows:

<% options= ['one', 'two', 'three', 'four'] %>
 
<%= select_tag :content, options_for_select(options), :disabled =>true %><br />
<%= f.select :content, options, {}, :disabled => true %>

Sure enough this worked, and gave me the same behavior for both helpers! I was quite surprised to find such inconsistent behavior for these two helpers. It was reminiscent of my experiences with PHP and I’m disappointed to see it here in the Rails API. I would be curious to hear an explanation for why these two helpers are so different.

Happy Coding!

Tagged disabled, disabling, form, Form Helper, RoR, Ruby, Ruby on Rails, select element, Select Helper, select_tag

Aug 20 2010

Leave a comment

Uncategorized

Ruby on Rails – Nested Object Forms using a :belongs_to association

In a project I am currently working on, I have a one-way relationship using a belongs_to association. I wanted to use the newer Nested Object Forms functionality added in Rails 2.3 to allow me to modify the properties of the related object in one form.

For the purposes of this post I’m going to use the following simplified code:

#address.rb
class Address < ActiveRecord::Base
  attr_accesible :address_string
end

#user.rb
class User < ActiveRecord::Base
  attr_accessible :name

  belongs_to :address
  accepts_nested_attributes_for :address
end

I ran into an issue when I was testing out this functionality in script/console and trying to assign attributes to the address through the user. I would encounter the error “WARNING: Can’t mass-assign these protected attributes: address_attributes” in my development.log. I proceeded to try and google a solution to this problem, and found many posts from users which encountered this issue, but none of them provided a solution. It appeared many people simply abandoned attempting to use nested attributes with a :belongs_to association. The solution to this problem is actually quite simple (once you know it!). Here’s the console log and the database log from my initial attempt:

#script/console
>> user = User.first=> #<User id: 1, name: "Bill", address_id: 1, created_at: "2010-08-20 21:49:52", updated_at: "2010-08-20 22:06:37">
>> params = {:address_attributes => {:address_string => "Up the tree", :id => 1}}
=> {:address_attributes=>{:address_string=>"Up the tree", :id=>1}}
>> user.update_attributes(params)=> true
>> user.address=> #<Address id: 1, address_string: "down the street", created_at: "2010-08-20 21:49:53", updated_at: "2010-08-20 21:49:53">

#development.log     
WARNING: Can't mass-assign these protected attributes: address_attributes

Note that the console even returns true from the operation, but the update address attributes aren’t assigned and the string is still “down the street” instead of “Up the tree” that we were trying to assign. The solution to this problem is to make sure that address attributes are added to the attr_accesible in the user model:

#user.rb
class User < ActiveRecord::Base
  attr_accessible :name, :address_attributes
  belongs_to :address
  accepts_nested_attributes_for :address
end

Now the error will no longer occur, and the address will be succesfully updated, as in the following console log.

#script/console
>> user = User.first=> #<User id: 1, name: "Bill", address_id: 1, created_at: "2010-08-20 21:49:52", updated_at: "2010-08-20 22:06:37">
>> params = {:address_attributes => {:address_string => "Up the tree", :id => 1}}
=> {:address_attributes=>{:address_string=>"Up the tree", :id=>1}}
>> user.update_attributes(params)                                               => true
>> user.address=> #<Address id: 1, address_string: "Up the tree", created_at: "2010-08-20 21:49:53", updated_at: "2010-08-20 22:41:46">

I hope this post can help save some time for others who run across this same issue.

Happy Coding!

Tagged accepts_nested_attributes_for, ActiveRecord, attr_accesible, belongs_to, Nested Object Forms, Rails, RoR, Ruby

of mice and pen

brain dumps and more

Filed under Uncategorized …

Manually generating #yeg trash data

Blackberry CEO’s not getting treated “fair”

Creating a branch of a repo on GitHub

Apps4Edmonton – Open Data App Competition

Rails Host Review – (the good) SliceHost

Rails Host Review – (the bad) HostingRails

Ruby on Rails – Disabling a select tag using the select helper

Ruby on Rails – Nested Object Forms using a :belongs_to association