Relief

This week did not start off well. Despite spending the weekend trying to get the application to work on the Pi, it still kept on crashing in most parts of the application. This was getting frustrating as it was working on both my computer and the work computers but failed at the actual deployment environment in which we were going to run the application on. When I showed the application to Dr. Shawn on Monday, he noticed that it was a C++ specific runtime error which was caused by the code attempting to convert null pointers to strings. He then proceeded to emphasize on the importance of testing code in real-world applications as anything can go wrong and that while something may work in one environment (e.g. the work computer), it may not work on others (e.g. the Pi). While it was a good thing to know how real-world engineering works, it does not change the fact that there is a deadline looming in the middle of the week! Later in the day, Dr. Shawn informed that in the worst-case that it does not work on the Pi, he can run it on a real computer and told me to focus on ironing out the bugs for now and not spend too much time on the Pi.

Setting my priorities right, I spent my time fixing most of the major bugs that were reported except for one which I was unable to reproduce after multiple attempts. When that was done, the temptation to get the Pi fixed came again so I decided to try out another attempt at it. I had a hunch that the reason for the application crashing on the Pi could be due to the difference in versions of Witty (Wt 3.3.3 on the Pi vs Wt 3.3.4 on the work computer) where newer versions of Witty could be auto returning a blank string instead of null pointers to avoid such runtime errors. Testing this out, I flashed a new image to the Pi and installed Wt 3.3.4 from an alternative repository. To my amazement, this solved the problem and everything seemed to work fine like the work computers.

Now with most of the bugs fixed and the Pi working, I started doing what should have been done earlier – stress testing the application!. During testing, I tried to break the application with variety of methods like spamming weird html tags to bashing all buttons and keyboard presses. This process was able to uncover a few more bugs. While most of them were able to be fixed, there was one which would require some extensive modification of the code so it was left there for now. A day before the event, I informed Dr. Shawn of this issue as a heads up should anything go wrong.

During the event day, it was absolutely nerve-wracking to not be able to do anything and just being able to hope that everything turns out well. At the start, there were some issues with users constantly being logged out but that seemed to subside after a while. The next 8 hours was then spent keeping track of the status of the application during the event. In the end, fortunately there were no major issues during the event and everything turned out OK (kind of). Nevertheless, this does not mean that our job is done yet. Since the code was not stable enough for production usage, we will be rewriting the code but this time with some major design improvements.

For the next version of the application, there will be a clear separation between the front-end and back-end parts of the application. This will enable a lot of flexibility for front-end as it is no longer tied to the back-end as compared to the current application. For the back-end, we are planning on implementing a REST API to handle the requests from the front-end which will now mainly deal with the GUI. Looking at how it is implemented, it is nice to see how elegant the REST API is structured and used and I hope to see it implemented smoothly into the next version of our application. Now that would be nice!