Decoupling Yourself From Dependencies

I've been working on a project for my EVE Online corporation building a web application with tools to help optimize industry game play. I decided to use Go for this project, for no reason in particular. This post is mainly targeting Go codebases, but the general idea is should be familiar and is interesting to consider, regardless. That is:

For an example, imagine your application needs to send email messages. You could easily use the net/smtp package from the standard library throughout your project. But this would introduce a tight coupling with the un-customizable standard library; you wouldn't have a place to add or extend the functionality.

Instead, create a package in your project that acts as an adapter between the library and your project. This allows you to explicitly section off where and how you use that library's API — you only implement what you need, and you can customize that to fit your application. This package defines the API in which the rest of your application uses the functionality you're wrapping.

In our example above, you might imagine a Sender type in the package mail. A Sender is initialized with parameters for the SMTP connection and then provides an interface suitable for the rest of your application. It additionally provides padding should the library ever have a backwards-compatibility break — you'd only have to fix the break in the mail package.

I'd mention one other reason: in the unlikely event that you need to fully replace the library you're wrapping, then this pattern might be very beneficial.

But consider the drawbacks

Overly granular packages are somewhat frowned upon in Go as they can make a project needlessly complicated. If the component in question is used all over the application, then the benefits for having a wrapper increase. It would be rather pointless, however, if that component were only used in one other place. A digression for another time.

The adapter pattern, so what?

Yep, that's all this is. But it doesn't require classical interfaces or objects or inheritance at all. I just think it's interesting that the same patterns can be useful in many different contexts.

Anyway, so long.

For the past many years I've been dabbling in model rocketry. It started when I was a kid, launching Estes kits with my dad. When I was an adult, I started experimenting with embedding pen cameras in the payload to get a rocket's eye view. Multiple stage rockets also really interested me. However, I always ended up losing rockets due to poor choice of launch area and unstable designs.

Ideal Conditions

Last year, I took a few rockets out to the Bonneville Salt Flats. I launched four different rockets, including two of my own design, and was able to successfully retrieve them all, minus a few nose cones. The conditions out at the salt flats is incredibly ideal, nothing around for miles and thick, flat sand that can be driven on.

One launch was a two-stage E engine rocket, my first of this kind, and I was incredibly surprised to recover the fuselage about a mile away from the launch site. The distance was mainly due to the parachute and nose cone coming apart from the fuselage, but I was impressed with how easy it was to track the rocket over such a distance.

After so many lost rockets prior to this experience, I was feeling more and more confident about building a more complex and interesting rocket.

Sophistication

After my trip to the Salt Flats, about a year ago, I started work on my first non-trivial Arduino application: a payload containing sensors and a transmitter, and a handset that received the telemetry. The handset uses a touchscreen LCD to display and interact with data received from the rocket. The transceivers I'm using use 433MHz, which in basic line-of-sight testing work up to 500 feet.

Over time, the payload became more and more sophisticated. It now contains a GPS sensor, two temperature sensors, two sets of accelerometer/magnetometer/gyroscopes, a non-volatile FRAM storage device, and an on-board battery controller. This information is gathered as often as possible, and transmitted about 20 times per second.

By about winter, I felt the design had stabilized and I was ready for testing. I designed a test rocket using OpenRocket and played with the engine set up until I was reasonably comfortable with launching it. Now to wait for decent launching weather...

Test Launch

Today, I finally launched the test design. The total rocket weight with engines was only about 250 grams. Using a single B6-0 engine would ensure the rocket didn't get much higher than 50 feet, if even that. I was able to launch twice with this setup, though both times had parachute related failures. The first launch had no chute deployment, the second saw two chute lines break. Both flights ended with the payload section hitting the ground pretty hard.

Payload section (and damage)

Payload section exploded

Not too bad. The transceiver continued transmitting throughout both flights, though I still need to work on tooling for retrieving and doing useful stuff with the data.

Until next time, here's a boring video of the second launch.