Events is the right word for what we are logging
A timestamped index should be the default

Trevor:
  Why? It scales better, but I think not stamping indexes gives
  newbies (like myself from a week ago) less mental overhead. It's
  easy to override if you do need the scalability.
Jordan:
  * Scales better
  * Kibana expects it
  * If you are familiar with ElasticSearch you would expect it
  * It answers the question of how indexes "should be" so you don't
    have to think about it.
test: Explicitly disable datestamp_index in the tests

This makes it much easier to test the JSON, and keeps the output
consistent with what we had before 0477ef7 (A timestamped index should
be the default, 2013-09-26).
Don't blow up if cannot serialize to JSON

Trevor:
  I was planning on setting up something like the errors argument used
  by Python's str.encode, but I'm fine with this until that happens
  ;).
Jordan:
  Sounds good, I just didn't want it randomly blowing up on user
  provided data and killing something in Beehive....
bes: Don't set a global default type

Trevor:
  Why don't you want a default record type?
Jordan:
  After reading more of ElasticSearch's docs, it doesn't make sense to
  not specify a unique type for each kind of record being submitted.

  If an index and mapping do not already exist, the first index
  document command dynamically creates the index and mapping. From
  then on all documents indexed with that type use that
  mapping. Fields can be added, but existing fields are not
  remapped. Sending a document like { 'code': 'BM016', 'organic':
  true} and then sending { 'code': ['BM016'], 'organic': true} the 2nd
  document's code will not be indexed (it isn't lost, but effectively
  is unless the mapping is adjusted by hand and the entire index
  recreated).

The relavant ES docs are under the "Automatic Index Creation" heading
here [1]:

  The index operation automatically creates an index if it has not
  been created before (check out the create index API for manually
  creating an index), and also automatically creates a dynamic type
  mapping for the specific type if one has not yet been created (check
  out the put mapping API for manually creating a type mapping).

  The mapping itself is very flexible and is schema-free. New fields
  and objects will automatically be added to the mapping definition of
  the type specified. Check out the mapping section for more
  information on mapping definitions.

and here [2]:

  Mapping is the process of defining how a document should be mapped
  to the Search Engine, including its searchable characteristics such
  as which fields are searchable and if/how they are tokenized. In
  ElasticSearch, an index may store documents of different "mapping
  types". ElasticSearch allows one to associate multiple mapping
  definitions for each mapping type.

  Explicit mapping is defined on an index/type level. By default,
  there isn’t a need to define an explicit mapping, since one is
  automatically created and registered when a new type or new field is
  introduced (with no performance overhead) and have sensible
  defaults. Only when the defaults need to be overridden must a
  mapping definition be provided.

[1]: http://www.elasticsearch.org/guide/reference/api/index_/
[2]: http://www.elasticsearch.org/guide/reference/mapping/
README: Document the new default-type handling
bes: Remove todo comments

Jordan:
  Type is required, which cleans up the TODO

Having different data accidentally sent to the same index/type mapping
was what Jordan was worried about.  Now that DEFAULT['type'] is
disabled by default, we don't need to worry anymore ;)
bes: Use the more modern ''.format() instead of the old '' % ()

No sense in using both forms in the same package.