Building a Ruby Library, the Parts No One Talks About #84
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Building a Ruby Library, the Parts No One Talks About
We all interface with Ruby libraries every day, so we all know what makes up a "good" Ruby API. But there is a lot more to a "good" library than just the API: proper logging, flexible configuration, a sane exception hierarchy, and useful documentation, just to name a few. How do we do these things properly? What pros/cons are there to different approaches? Unfortunately, no one really talks about these things, despite being very important to the overall feel of a library.
In this talk I'll share my knowledge of these things from being the maintainer of popular Ruby applications and libraries. I'll show you the idiomatic Ruby way to do logging, configuration, exception handling, and much much more. But don't worry, I won't just be preaching, I'll show you the reasons why these methods have become the community approved way of doing things.
Mitchell Hashimoto
Mitchell Hashimoto is an operations engineer passionate about all things open source. For four years he was a web developer for a Ruby on Rails studio, and for the past year has been an operations engineer for a start-up company in San Francisco, CA. Mitchell is one of the creators and current maintainer of Vagrant, the tool for creating and distributing virtualized development environments. Vagrant is used by thousands of developers worldwide and many large companies including Tumblr, GitHub, LivingSocial, and more.
Mitchell has spoken at many conferences in the past year, including FOSDEM, RubyConf 2011, DevOpsDays in Sweden, and more.