Configuration to Go

One of the boilerplate tasks for nearly every (application development) project is the implementation of an application configuration management. In most cases, applications have aspects we want to be configurable, e.g. the port a server listens on, the language an UI starts with or the database connection an application shall use. The twelve-factor app methodology propagates using environment variables for this purpose, but what might be a good idea for cloud-deployed web apps won’t work equally well for desktop applications or in traditional deployment scenarios. For them, more traditional ways like configuration files or command line flags might be a better choice.

Elegant Python Exceptions

Particularly when creating library packages in Python, raising exceptions is a great way to let the downstream developer know about problems occuring while executing code from within the library. Python’s built-in exceptions cover a whole host of cases. However, some problems might be library-specific and deserve a custom exception.

Custom Exceptions

Creating a custom exception in Python isn’t particularly hard when observing a few rules:

• Custom exceptions shall be derived from Python’s Exception class
• By convention, exception names shall end with “Error”

1class MyLibError(Exception):
2    pass

In many library packages, you will find exceptions similar to the one shown in the code example above. There’s nothing wrong with that; if chosen wisely, the exception name by itself will already tell what went wrong. However, the more details an exception provides about the circumstances it was raised in, the easier to diagnose and debug the problem, and the more appropriate the reaction to an exception.

Dataref Caching Revisited

Earlier this year I wrote about caching datarefs. Back then we only looked at caching single datarefs, which quickly leads to bloated code once applied in a wider context. So here we are again, taking a closer look at caching many datarefs efficiently.

What About Trees

“Are we going to leave those poor little Datarefs here in this horrid, dark, dank, tree-infested — I mean… charming, quite charming, forest?”

— unknown dwarf coder

Continue reading

Configuration File with XPPL

In this blog post we’re looking into using XPPL to enhance a plugin with a configuration file. Working with XPPL’s configuration module is follows this five-step sequence:

1. initialize a configuration context
2. register configuration properties
3. load the configuration file
4. access the configuration values
5. clean up

First, we need a configuration context. Since we will need to keep it alive throughout the whole plugin life cycle, we declare it as static, global variable:

Introducing XPPL

Are you tired of (re-)writing the same boilerplace code for every X-Plane plugin project — over and over again? Well, at least that’s how I felt when I started my fourth or fifth plugin. Sure, I reused a lot of my boilerplate code, but with every project, I refined and enhanced it. Backporting those changes to older plugins became a tedious task though; therefore I started the X-Plane Plugin Library (XPPL).

Cache Your Datarefs

Nearly every X-Plane plugin accesses one or several of X-Plane’s datarefs at runtime. It’s not uncommon to find code like this:

1void set_data(float value)
2{
3    XPLMDataRef dref = XPLMFindDataRef("what/ever/data/ref/we/need");
4    XPLMSetDataf(dref, value);
5}

Admittedly this works. However, there are a couple of reasons why the code above is not the best idea, if you’re seeking to write a solid and well-performing plugin:

Talk to the Log

Making an X-Plane plugin “talk” to us is one of the boilerplate tasks when setting up a new plugin project. X-Plane has its own log file, log.txt, which is found in X-Plane’s root folder. The file gets reset every time X-Plane starts, so there’s no need to rotate or trim it from time to time. As a plugin author, we have the choice to either write our own log file, or to jump on X-Plane’s bandwagon and use its logging system for our purposes. While I can see the benefits of having a dedicated logfile for a plugin, personally I prefer to use X-Plane’s built in logging mechanism – there are technical reasons, but mostly it’s a comfort and usability decision: most X-Plane users will immediately think of the central log.txt file when a developer asks them to provide their log file (e.g. when reporting an issue).