Talk.save sends the talks attributes to the server

At this point, we're sending data to the server, not just making an
empty HTTP request.

We're choosing to send JSON(Javascript Object Notation). JSON is text which
represents the talks attributes object.

That's all JSON is; another way to store data in a way that both computers and
people can read.

Both Javascript and Ruby make it easy to convert JSON strings into hashes (in
rubies case) or objects (in javascripts case).

The notion of storing the same data in different forms is known as `encoding`.

Data a browser can display as a web page is encoded as HTML.
Data our music player can play as music is `encoded` as an MP3 (or any number
of competing encodings).

We could, if we so desired, even develop our own form of encoding data and
sending it forth to the server. This would be fun, but not terribly
practical.
Talks with ids are saved via a PUT to /talks/:id

Here I'm agressively extracting private methods, signified by the `__` or
'dunderscore'. I'm choosing not to test these private methods because they're
incidental to the behavior of the Talk object.

I'm choosing to expose `isPersisted`, because I can imagine it being useful to
outside collaborators. Some people will wait until another object actually
wants to call the isPersistd method befor publicly exposing it. This is also
valid.

I also refactored my test organization to focus more on the `inputs` (i.e. what
attributes the talk is instantiated with) than the individual methods. This is
somewhat controversial; as standard practice is to describe each method with
the permutations next to it.

Some of you may be thinking "man, it looks like the Talk object does too many
things. It's sending stuff to the server as well as holding the talk
attributes!

To you I say, well done. I concur. However, because there isn't a need to share
this behavior quite yet I will wait to extract an object which is responsible
for sending data to the server.
The deferred object or `promise` pattern is a nice pattern

$.ajax/$.post/$.get each return a jqXHR object, which conforms to the deferred
object pattern.
Convert createTalkView to TalksView

Technically the talkView contains more than one talk. I'm renaming it to
TalksView to be more accurate.

Also, I'm converting it to use a constructor function so it's consistent with
the Talk model.

You'll notice I'm using the instncaeof keyword to test that Thunder's talksView
object is actually a TalksView. This is reasonable only because I've thoroughly
tested TalksView independently.

The Thunder object's one job is to collect the different javascript components.
First test for the AddTalkFormView

I wanted to write a relatively simple test to get started testing the
AddTalkFormView

This view object will be used to:

1. listen for the form submission
2. Aggregate the data from the form
3. Create a new talk from that Data
4. Save the talk
5. Append the response from the server to the DOM
Submitting the add-talk-form creates a new talk object
save is called on the new talk

Our tests are getting pretty crazy-complex. This is because the behavior we're
testing is actually quite complex as well.

We're decomposing the interactions between a computer that could be anywhere on
the Internet and our web application server; and we're accounting for that
being completely asynchronous.

This is also why most people don't test their view logic. It's. Really. Hard.
Append the saved talk to the DOM

Now we're beginning to get the meat. Most of the tests we've been writing so
far are tightly coupled to a specific implementation.

We're leveraging the fact that the Talk.save method returns a deferred object
so we can choose whether the save succeeds or fails in the test itself; and
then assert we're handling that properly.
Append errors when save talk fails

Here we begin to see that `this` sometimes gets changed.

`this` is a keyword which means `the object that the function
was called upon`

The object the function is called on is known as the object's `context`

```
function exploreThis() {
  console.log(this);
}

exploreThis();
// Prints the window, since we're not explicitely calling exploreThis on any
// object
```

We can also put the exploreThis function on an object; which will change what
`this` is when exploreThis is called.

```

coolObject = {
  exploreThisOnAnObject: exploreThis
}

coolObject.exploreThisOnAnObject();
// Prints the `coolObject` object.

```

But wait, there's more!

We can actually call `exploreThis` and tell it what `this` should be.

```
notCoolObject = {
  attributes: "I'm not as cool as the coolObject."
}

exploreThis.call(notCoolObject)
// Prints the notCoolObject
```

`context` and `this` are a huge part of javascript's strength, but also one of
the hardest things to grasp coming from ruby.
Refactor to more clearly express intent

These tests are pretty tough to read because they reveal a lot of the
underpinnings of dodging server interaction.

So I refactored them to:

1. Only test submit stuff in the submission bit
2. Test saveTalk independently
3. Create a FakeTalk object which can be used in place of an actual Talk

This should make the test sligtly clearer. Hopefully.