birthday

"Let's build language-specific libraries to help write logs in a single format, which is human and machine readable."

Spec: Clever/specs#62
@rgarcia - thanks for your thoughts on testing approach. following up on the JSON test spec:

To me, the benefit of the `tests.json` spec is to define expected output for common use cases. Here's an example of where I think the spec would be useful.

Suppose that we want to make single world strings like `bob` no longer have quotes (currently, all strings will be quote delimited, e.g. `"bob"`, due to using straightforward JSON parsing). This would be easy to update (change all affected lines in `tests.json`, then update the `tests.json` file in the various kayvee repos) and immediately run tests to confirm that each repo is changed to support it. 

Without the shared tests, it would mean each `kayvee-{x}` repo with have to restate these common cases, and update them given a change. I'd also want to revisit [kayvee](https://github.com/Clever/kayvee) and write scenarios in words instead of a `tests.json` approach.

So my preference is: 

1. **keep the json test cases** to help clarify behavior for simpler data types in a cross language manner. (Also, because we know exactly what types will be pulled from a json via json marshalling (or equivalently `JSON.parse` (JavaScript), `json.load` (python)) we will know that only these types are covered by the spec.)
2. **add language-specific tests** to be sure each kayvee library handles language specific data-types (things that the JSON test spec won't cover).

Flexible here - if you disagree w this approach I can still easily re-write at this point. Or I can use the spec for now but scrap later if it proves problematic (e.g. difficult/confusing to maintain or we find that bugs are falling through the cracks due to this approach.)