Wrappers, libraries, SDKs, gems — there are probably more benefits to making a simple abstraction than you realize. Ridding your application of non-business related functionality can help you focus on what matters, give back to your community, and provide an excellent way to introduce you or your company to a new audience.

A few months back MadGlory began a project that requires internet connected devices to be in real-time communication with a web application. While MG was responsible for the web application, another team was responsible for the device’s hardware, firmware, and software. Since early development on any application can involve countless changes due to domain discovery and other factors, it was decided that both the web application and the devices would use Device Cloud by Etherios as an intermediary of sorts.

There is a very large feature set, but from our point of view Device Cloud was a service that provided a common, stable, and robust API to manage our internet connected devices and get access to their data. It stored our devices’ files (logs, images, event data, etc.), provided an interface to real-time status of a device, exposed the devices’ internal API, and even allowed us to provision and update the devices remotely.

One useful feature was the Device Cloud’s virtual filesystem. The devices we were working with pushed files (JSON data) to the Device Cloud, which were in turn sent our web application as push notifications (HTTP PUT), containing the file data and some other meta information, whenever a new file event occurred. There are a TON of different events for which you can set up monitors to receive push notifications using Device Cloud’s Monitor feature, so we figured out what needed to be monitored and got to work.

Eventually, we ended up with a working example of sending and receiving data from our devices. While our code worked, it was very tightly coupled to the inner workings of the Device Cloud API. We had an entire model namespace dedicated to interacting with the Device Cloud. There were separate classes for requests, responses, modeling API objects (like Monitor or PushNotification) mixed in with our business logic of how our devices use those things. It was evident that our application was splitting its domain logic between both business needs of working with our device data and a Ruby wrapper for the Device Cloud API. Something smelled funny.

We needed to model how our application uses the Device Cloud, not how everyone else interacts with it using Ruby. In an effort to decouple that Device Cloud wrapper from our business logic, we started extracting the API models to a separate gem, and the device_cloud repository was born.

This technique is not new. Many third-party services provide SDKs, gems, libraries, or simple example code to show how to interact with their API from within a certain language. I think this is a good practice not only to provide a sort of hands-on documentation of interacting with a third-party, but also to keep your application’s code organized and relevant.

This simple change drastically helped form how I think about interacting with third-party services and what is really important to an application. First and foremost, it made our application’s code more concise. By abstracting the code that defined how the Device Cloud worked, we were left with exactly what we needed — our data. It also had a couple of interesting side-effects.

Creating the device_cloud gem allowed us to contribute some reusable code to the open-source community. This does two very powerful things.

First, it gives the contributors an avenue to publicly demonstrate their abilities. MadGlory is a consultancy and we are hired to be expert engineers. That said, it can sometimes be tough to give detailed examples of the work you or your company is capable of due to non-disclosure agreements (NDAs). Releasing your abstracted wrappers or gems can provide concrete examples. Its no secret that more and more companies are using GitHub as a resume of sorts when searching for talented employees (don’t get me started on cold-call recruiting emails). Why not leverage your company’s GitHub organization as a sort of digital portfolio?

Lastly, and maybe most importantly, you are helping your community grow. Producing simple, well-documented tools is crucial to cultivating a thriving tech community. Programming novices are encouraged with quick wins and easy-to-grok code, as DHH (video) and Farrah Bostik (video) alluded to this year at RailsConf 2014 in their keynotes. In addition, the more knowledge we can share with one another, the easier it is for everyone to build on top of those common tools and push the community forward, which is what Yehuda Katz (video) was talking about in his RailsConf keynote.

Putting aside the intangible benefits of community building and showcasing work, abstracting small bits of non-business related code has the real benefit of helping you focus your energy on the task at hand, and that is enough for me.