Improve logging and debugging

[mjeffrey18]

Fixes: #19

• There was a lot of spec logic around logging, I guess it seemed like it made sense to remove that?
• Provided developers was an example of how they can change the logging level.
• Refactored a bunch of rescue statements around the code to log the rescued errors.
• Refactored the base connection class type mounting method.
• Added a debug_json method which can be exposed on any rest endpoint to ping and get stats on the current state of the server

Let me know what you guys think?

[jwoertink]

Love it! You can just leave the version update off, and we can get everything merged in and updated all at once. The rest looks great to me! Thanks so much for doing this

[jwoertink]

Sweet!

[mjeffrey18]

Hey @russ / @jwoertink whenever you're ready, we can go ahead and start merging the other branches, except this PR.
Once everything else has been merged I'll need to clean up everything on this PR to finalise the new release.

[jwoertink]

Thanks for the heads up @mjeffrey18. Right now @fernandes is on vacation, but once he gets back, we should be good to start merging stuff in. 👍 Thanks so much for tackling this, it's huge!

[mjeffrey18]

@fernandes this one is ready for final review/merge

Big shout out again to @jgaskins as a lot of the inspiration for the cleanup came from his fork 💪

[jwoertink]

Thanks so much for this!

[fernandes]

@mjeffrey18 what's the rational behind removing these messages? I'm asking because it helped me in the past to catch a few bugs lol

There was a lot of spec logic around logging, I guess it seemed like it made sense to remove that?

maybe my first comment answers this one on description 😉

if this is just because now we are using a bare crystal log class, it supports capturing the logs for testing, like I did here

[mjeffrey18]

Hey @fernandes, your right, logging can absolutely catch bugs. I've always found solid specs are way better at catching bugs and logs are better for debugging/monitoring.

Taking some lessons I've learned from heavy use of Rspec over the years;

• Testing if methods are called can leads to false positives and/or flaky specs.
• Use mutations/results should be tested where possible. This avoids flaky specs and focuses on outcomes over implementation.
• Logging is amazing for debugging, so unless the specs are weak (which they're not, you've done a pretty solid job!) we will catch bugs with specs.

However, I'm open to other alternative approaches (as your suggested) if we feel testing the logs is worth it for this particular case.

[fernandes]

I agree, I tried to test the behavior as much as possible

you've done a pretty solid job!

thank you! 🙇

my final thought is if we should handle log messages as part as the software behavior/functionality, because if so, it's good to have it tested, once users will get the correct messages in the tested scenario

comments? 😄