Practice shows that writing reliable software is extremely difficult. It’s not as if writing code is so difficult. Even monkeys can write code. No, it’s the edge cases that make it difficult, undocumented behavior, maybe even worse is unexpected behavior. Black boxes which do not show what’s going wrong deep within the program, and when an error finally gets the change to bubble up the program crashes, with no trace left behind. I’ll share with you 5 of my habits for writing reliable code;
1. Fail hard, fail fast
Basically it’s the other way around. If anything goes wrong, try to fail fast, and then fail hard. Let your application be vocal about how it feels. Let it throw a tantrum when something goes wrong. A parent will probably be able to handle it.
Throw errors if you cannot handle it properly, rethrow errors whenever applicable, and please, keep the stack trace intact!
In case you are not entirely sure what to do and the application (state) might be corrupted, don’t feel bad to make the app crash. Crashing applications are usually better then running a crippled application which might cause continuous damage while running.
2. Avoid duplication
Code duplication also means bug duplication. Limit the amount of code you have and I promise you’ll still be amazed by the amount of bugs in it. Besides that, it’s just flat out annoying and embarrassing when you fixed a bug only to discover the bug still exists in the same code in a slightly different place.
One part of avoiding code duplication is making sure that you know where to find certain methods for certain tasks. There are too much occurrences where the same code has been written multiple times because the function was hidden in some obscure namespace or class.
Having duplicate code throughout the code base may be an indication that there’s something wrong with your architecture. Go fix these issues!
3. Write automated tests
Small changes in code can have big impact throughout your application. As the application grows you will miss things, forget about pieces of code and lose details about the application. Automated tests will save your ass.
Tests are not the law though. If a test fails you can either change the tested method or the test function. In case of the latter, just be sure you know what you’re doing!
If you’re just starting out, and you’re wondering how you test your code, a good begin is to think about all the small tasks your code has to do. Write tests which describe the desired output for your task, write your task and test it. Writing tests forces you to think about the purpose of a block of code. Doing so will generally result in better code reuse throughout the application.
4. Use logging
Writing stable code is amazing, but there will still be bugs. Part of stable code is minimizing the downtime and damage caused by bugs. In case there is a bug in a production environment (of course you’re not testing in production), it’s extremely beneficial to have a proper stack trace. Even better would be to have a log of events leading up to the bug so you quickly have an idea of what is going wrong.
Please be aware that there’s such a thing as too much logging. Emitting hundreds of log messages a minute might be usable while debugging but it’ll be a total disaster to spit through these in production. In addition this might result to real errors being missed due to the high volume of messages. And let’s be honest, logging code scattered throughout your codebase is just ugly.
5. Prepare for the worst
Believe it or not, even if you apply all of this advice you will still encounter bugs in the worst possible of times. It’s due to Murphy’s law:
“Anything which can go wrong will go wrong”
Calculate your risk, and prepare for the unexpected.
- Make sure your application will restart in case it shuts down.
- Implement retry logic in case some logic does not execute properly.
- Notify sysadmins proactively when unexpected behavior is detected (high load/response times/throughput etc)
- Limit potential damage / downtime caused by potential bugs
- Use continuous integration and continuous deployment (because hey, how many times has it already happened that you copied the wrong version to the wrong environment)
Writing code isn’t hard. Writing stable software is.
The end of a year is a moment for me to look back and reflect on the work done in the past year. I slowly became to realize the whole SkyHop project has been bigger than I could reasonably handle when I all started it back in November 2016. In these two years of on and off development the idea has evolved from a tool to compare flight performances between my brother and me to a state of the art flight analysis platform.
If you would like to participate in the public beta launching approximately Q2 2019, send me a message somewhere and I’ll add you to the list! Leave a comment on this post, send me a message on Twitter, Instagram, or even mail would do fine. I’d be happy to show you around!
Work done in the past year
The most important theme in Q1 2018 has been development of the FlightAnalysis library. This library, which allows automatic detection of flight metadata based on its flightpath, is as good as finished now with almost all bugs ironed out. There are still a few major features I’d wish to implement after other work has been done:
- Detection of launch methods. See whether an aircraft has been winched, towed or started by itself.
- Detection of tow duration. Keep track of tow starts to see when the aircraft unhooks.
During Q2 the biggest focus has been on the improvement of stability. Several bugs throughout the stack have been fixed. This includes the TCP server, APRS server and the FlightAnalysis library. The data model has kind of matured for data storage and that’s about it. All in all not too much groundbreaking work happened before.
In Q3 we’ve been working pretty hard on the front-end interface in conjunction with the API. The API has been written in C#, but according to the GraphQL specification. It’s one of our goals to release the same API we’re building our UI upon to external developers for implementation in their solutions. This work reached well into Q4, and while the API will be completed in Q1 2019, the UI will be a work in progress for a while. The goal is to aim for a beta version in Q1 2019, but work on main features will extend well into Q2 2019. Of course this is all dependent on the amount of free time available to invest into the project as well.
The groundwork for a lot of the topics I’m going to describe next have been already done during the last year. Therefore reinforcing my expectation that a lot of features can be shipped throughout 2019!
We aim for a public beta version at the end of Q1 2019. This version will contain the most important features:
- Automatic flight registration stage 1
- Detailed flight insights
- Logbook functionality
After this first version we’ll release periodical updates which will contain new functionality:
- Fully automatic flight registration (stage 2)
- Flight comparison
- Group management functionality
- Telegram integration
There are two stages in the development of automatic flight registration capabilities. The first one focuses on the registration of aircraft movements, and is dependent on Flarm or ADS-B. Focus in the second stage will be on detection of the pilots and will include fully automatic registration capabilities. A side effect of the technique we will be using is that the flight movement detection capabilities will be enhanced, resulting in a more clear view of your flight.
I think it’s worth mentioning that automatic pilot registration will work with any aircraft, as long as it can be tracked by Flarm, or ADS-B. More details are about to come later, after the first beta has been released.
We will offer one of the best flight visualization tools available, right in your browser. As one of the first experiments I have plotted one of my flights through the Alps in Google Earth. Take this example, and imagine the final result to be the same as this, but with more information about your flight performance.
After the first beta has been released I plan on implementing support for flight comparisons. Selecting two or more flights will show the same screen, but with information from multiple flights shown. Ultimately this boils down to where it all started, and would settle a lot of arguments between me and my brother.
Competition and Privacy
As important as all other items I want to take this change to talk a bit about privacy. My goal has been not to (semi-)publicly disclose detailed flight information. The primary reason is our club culture. While I am all in for an open competitive and safe flying environment I do not think publicly disclosing flight paths will help achieve this in a good way. For dealing with and prevention of airspace infringements are other options, which I’ll write about later on. This also is our biggest potential issue right now. So far my policy is that users can choose to share their flights if they want to, but this information is protected by default. If within an aeroclub, they might choose that only certain persons have access to this information like the safety commissioner.
When talking about competitions and flight performance a fellow pilot made the following comment:
“It would be amazing to see how other pilots do in a competition, and see the differences between our flying styles, and the impact on the result.”
It set me to think a bit. How can we achieve this while ensuring privacy? Sure, all pilots can share their flights, but it would defy the possibilities available with real-time tracking, also for the pick-up team. After the first beta has been released we will invest some time in developing functionality specifically aimed at competition organizers. This will enable organizers to register aircraft flying in the competition with us to enable competition mode, and give organizers the power to disable features like real-time tracking, but also to enable safety features, and flight comparisons between all participants.
The safety features we’ve been talking about before will be primarily aimed at preventing and educating about airspace infringements.
There are multiple known occurrences of pilots making (accidental) airspace infringements going unnoticed by themselves until someone else discovered them.
The goal is to provide tooling for flight planning to show a clear overview of the airspace structure. While usage of mobile devices in the cockpit is frowned upon, I think they can be a valuable source of information, when used responsibly. With this mindset we’re going to offer functionality to notify pilots when they are about to enter controlled or restricted airspace (ofcourse we cannot know whether they have clearance), in order to improve spatial awareness.
In order to be able to provide information to our users in near-real-time we are planning on using Telegram’s bot platform. Telegram has built an incredibly powerful platform which can be used by external developers (like me) to have interactions with users.
Right now there are a few different messages we want to send via Telegram:
- METAR updates tailored to your position
- NOTAMS around you
- Logbook entries after each flight
- Detailed flight information (including a map and charts of your flight)
- Daily, weekly or montly summaries of your flights
Telegram is one of the ways we can make interacting with SkyHop as easy as possible. More is yet to come!
My goal for the beta period of SkyHop is to gain feedback from all users involved. In exchange for feedback I’ll give you free access to all of the platforms features while the beta period lasts.
Given the amount of time and other resources I have personally invested in this project I can impossibly keep offering this service for free, and therefore will be offering a subscription based service after the beta ends. I am not yet sure how long the platform will be in beta, but it can be anywhere from three months to a year. I will keep you updated on that, though.
In exchange for participating in the beta I will also offer a discounted subscription for when the beta period ends.
While SkyHop was originally intended to be a software suite aimed at the soaring community, there is a broad range of features that would suit the whole general aviation community. There is nothing which prevents you from doing so at all! Please let me know if you want to participate as a GA pilot in the beta, and do not have Flarm equipped. I am happy to give priority to implementing an ADS-B feed so your flights can be processed!
Last but not least; feedback. As a pilot myself I know from experience what I features I want to have, and I do have the required skills to build those tools. But other people tend to have better ideas than me. If you want to see specific features implemented, or you are a developer at your aviation club or you do anything related to aviation and you think we could work together on something, let me know! I am really happy to listen to and discuss your feedback!