Add ContextLogger that accepts data as second argument to log method

[bliof]

This PR tries to resolve #77

ContextLogger.info('test')
ContextLogger.info('test', user_id: 123, test_arg: 12)
ContextLogger.info('test') { 'test message' }
ContextLogger.info('test') { ['test message', test_arg: 1235] }

In rails the ContextLogger is returned by Rails.logger. I think that this is not ok and we should return that logger when doing Loga.logger and return a normal logger when doing Rails.logger. Comments :) ?

[bliof]

@timstott @FundingCircle/prod-ops 👀

[timstott]

Is it necessary to raise an exception considering we're logging the error below?

[bliof]

Otherwise it will be NoMethodError on the next line.

https://github.com/FundingCircle/loga/blob/master/spec/unit/loga/configuration_spec.rb#L50

Is there a reason not to default to e.g. device ||= $stdout here?

[timstott]

@bliof it's looking good. I'm going to do some additional review locally 🙇

[bliof]

@timstott 💭 Logging to $stdout by default?

[bliof]

There are some special fields :exception, :timestamp, :type in Loga::Event. At the moment if you write something like Loga.logger.info "this is a test", type: 'my cool test', the type will go under :data. And if you need to modify any of them you'll have to build the Loga::Event manually.

https://github.com/FundingCircle/loga/blob/master/lib/loga/event.rb#L3

[bliof]

@timstott What are we going to do with this PR? :) 👍 / 👎

[timstott]

@bliof while I understand and support the ambition of this PR, I am not keen on introducing backwards incompatible change. Removing Loga from an application should only be the matter of removing the dependency in the Gemfile and the configuration.
I am in favour of closing the PR and going back to the drawing board.

[bliof]

@timstott You have to send me a photo of that board :D

Here are 2 ideas:

1. the gem could provide a more advanced logger which will not be used by default
2. advanced logger which will be used by default for Loga.logger but not like Rails.logger