Cyoa 20141023 rc

First pass at CYOA, specifically the Opposite of Progress exercise.

Features:
-view bills, legislators, good deeds
-bills link to legislators (and vice versa)
-good deeds link to bills, legislators, and related good deeds
-can pull bills and legislators from Sunlight API
-can create good deeds based on bill and legislator information
-good deeds are bills that were voted on or bills that were enacted
-API supports bills, legislators, good deeds; both individual and lists
-TDD tests (rspec)
-BDD tests (cucumber)
-basic user authentication

Missing:
-better testing
-user emails for new good deeds
-user tags on good deeds/other info

I like that even voting on a law counts as a good deed now. ;)

Anyway, there's a lot going on here, and I don't think it's necessary. First things first: this is not a helper, this is probably its own class (I mentioned such a thing above). Next, fix the name, it's not accurate. Next, there's too much going on in one place and it's causing arrowhead code (check out the quadruple-end below this line). One intermediate refactor (that is not a good final refactor but might point to it) would be to encapsulate the creation and update logic:

```
def self.create_deeds_for_votes
  bills_with_votes_and_titles.each do |bill|
    find_vote_deed(bill) || create_vote_deed(bill)
  end
end
```

This exposes the algorithm (find bills, find deeds or create them) and makes your code easier to understand. Another intermediate refactor would be to leverage the `first_or_create` Rails idiom:

```
def self.create_deeds_for_votes
  bills_with_votes_and_titles.each do |bill|
    Deed.where(bill_id: bill.bill_id, ...).first_or_create
  end
end
```

Interestingly enough, since the basis for the `.first_or_create` is a `.where`, we can use a scope!

```
class Deed
  scope :for_bill, ->(bill) { where(bill_id: id, ...) }
end

def self.create_deeds_for_votes
  bills_with_votes_and_titles.each do |bill|
    Deed.for_bill(bill).first_or_create
  end
end
```

Finally, looking at lines 3, 4 and 8, we're doing all the work at the app level. That means that if you have 1,000,000 bills, you're retrieving ~2,000,000 records using 1,000,001 queries. This is not good performance. We can assume that the system will usually be 99% up to date over time, so let's try to select only the records we need:

```
def bills_without_vote_deeds
  Bill.without_vote_deeds
end

class Bill
  def self.without_vote_deeds
    where("not exists (select 1 from deeds d where bills.bill_id = d.bill_id ...")
  end
end
```

This means that Bill still knows too much about Deed's implementation, but it's _much_ cleaner than before and we have an encapsulation we can play with. More importantly, we only ever retrieve records that _need_ a deed created, so we can get rid of `.first_or_create` altogether, and confidently just create records.