I was reading this article it raises quite an unexpected question - "Can we consider logging as a code smell"?
Clearly - the answer is more nuanced than that and whilst I do enjoy the event bus
approach from the article - that seems like overkill for most applications.
It's interesting that Aspect Oriented Programming is mentioned but not in a positive light and I resonate with that to a certain extent - especially in Java but in Ruby world this is quite easy to implement - actually no one even calls AOP (most likely because is not in the pure definition of it) it's just neat little feature of ActiveSupport
: more precisely ActiveSupport::Notifications
.
To me that's quite similar to the implementation in the original article - it just comes as under the "instrumentation API for Ruby" moniker.
A simple example would look like:
ActiveSupport::Notifications.instrument('some_action_that_requires_instrumentation') do run_the_action end
In some other part of our logic - preferably in config file we can subscribe to those events:
ActiveSupport::Notifications.monotonic_subscribe('render') do |name, start, finish, id, payload| # According to the docs we get a handy set of meta information: # # name => String, name of the event (such as 'render' from above) # start => Monotonic time, when the instrumented block started execution # finish => Monotonic time, when the instrumented block ended execution # id => String, unique ID for the instrumenter that fired the event # payload => Hash, the payload # here we could implement our logging and instrumentation (Librato & friends) end