Since I’ve been a little hasty about jumping in and cleaning out the server-side API, I figured it would be a good idea to step back and re-evaluate my goals for the server API. For installation we had a somewhat simple task of simply removing anything that wasn’t needed to compile, and we were able to take our time and focus on one element at a time. With the server-side API, we don’t exactly have the same luxury as we don’t know how interdependent the various modules are to each other.

The first goal for the server-side API is simplicity. Simplicity also implies brevity. But if we start removing everything, we won’t know what’s broken and what isn’t. So the highest priority is probably going to be to establish a test suite before we start anything. Aptana included a test suite in their original build, and while we’ve changed the client-API, the main change is that we’ve changed the default from synchronous calls, to asynchronous calls wrapped in promises. That means that we might be able to make use of most of the original code as-is if we are able to add in the “await” keyword for testing. So looking into that should be a good priority. Then we can at least have a baseline for generally what we’re dealing with.

In terms of practical action, I haven’t had a chance to set up a Pi and do a lot of testing. I’m really tempted to look into setting up a virtual machine to act as a Pi. And that was I can set up a new environments to be able to test and reset installation and then run tests. And then come back and run final tests on actual hardware. We also need to get the original analytics set up and running after each install and that way we have a metric to track what works and what’s broken.

In a previous attempt to set up a new environment I came across a issue where a rule was missing for the libmysql.a file. Which is somewhat surprising as the precompiled ARM library should already be included in the repository, and we managed to suppress the error by copying the libmysql.a file to where the resulting file was expected to be. Though it’s somewhat concerning as more than source code errors, Makefile errors can often be more difficult to locate and track down.

So the priority now is to try and establish some form of testing to be able to set up virtualization to be able to test installing, compiling and running the diagnostic tool to be able to access the status of the builds. And then from there we should be looking into tracking down what aspects of the server-side API we can address and work on. Which means that the next blog post should probably be about setting up a virtual environment for Pi Testing.