Open-source all the things

Appaloosa Store
Appaloosa Store Engineering
3 min readJun 22, 2016

Here at Appaloosa, our backend runs on Ruby on Rails. We are quite fond of it, especially thanks to the ecosystem built around it.

Our main app includes 130 gems, needless to say we heavily rely on the good work of other developers to keep our app working. We recently realized we could, and should, give back to this great community. Indeed, we are regularly writing code that could end up being in gems, provided a little extra work.

And so, Appaloosa went open-source.

Our open-source vision

We already provide several open-source tools. Our clients can use our native stores SDKs, which provide blacklisting and auto-updating capabilities for their apps. We also developed a Jenkins plugin, a Fastlane lane and a Bitrise step to deploy one’s apps directly to Appaloosa. And, very recently, we created the first Appaloosa gem (detailed in our previous post).

Speaking of gems, we intend to create many more. Our sole rule is “whenever you can extract some logic into a gem, do it”. We see three main benefits to it:

  • Encapsulating our code makes it more maintainable and modular. It is independently tested and can be enhanced by everyone through pull requests.
  • We want to help the Ruby on Rails community, our fellow developers. We always enjoy when a gem addresses the particular problem we are working on, what if we could contribute to that?
  • By providing gems, we give Appaloosa the opportunity to get noticed on the open-source scene. This is very important for us: we are always on the lookout for passionate and talented people to join us.

Introducing Tepee

Today’s post is a good occasion to present our latest gem: Tepee, a configuration helper for the braves.

In our backend Rails application, we used to declare our environment variables as follow:

# configuration.rb
$var_one = ENV[‘VAR_ONE’] || ‘the_default_value’

This is not so great because:

  1. in a production app, you are going to have a lot of env variables, and it’s going to get very cluttered.
  2. you use global variables.
  3. you cannot use namespacing to logically group your variables.

Tepee solves these problems. Imagine we have two environment variables:

# configuration.rb
$token = ENV[‘GGL_TOKEN’] || 13
$url = ENV[‘GOOGLE_URL’]

If you happen to work with a long-lived application, you’ll have legacy code and inconsistencies to deal with. Here, GGL_TOKEN and GOOGLE_URL share the same functional domain and could be grouped in a namespace, but their naming does not reflect that correctly.

With Tepee, one would write:

# configuration.rb
require ‘tepee’
class Configuration < Tepee
section :google do
add :token, 13, env_var: ‘GGL_TOKEN’
add :url
end
end

To access our environment variables:

# anywhere in your app
C2DM.token = Configuration.google.token # or ENV[‘GGL_TOKEN’]
C2DM.url = Configuration.google.url # or ENV[‘GOOGLE_URL]

Tepee offers a more structured way to access our environment variables. Furthermore, the grouping in sections offers a namespacing mechanism, increasing readability and maintainability. Note that you can nest sections.

If you want to learn more about it, head to the repo. Don’t hesitate to open an issue or a PR!

References

This article was written by Appaloosa’s dev team:
Benoît Tigeot, Robin Sfez, Alexandre Ignjatovic, Christophe Valentin

Want to be part of Appaloosa? Head to Welcome to the jungle.

--

--