eVitabu dev week October 2021

Some of my colleagues at work laugh about the fact that I take annual leave from "the day job" to go to work on eVitabu, but that was my plan for four days in early October.  Getting to concentrate on eVitabu for longer periods (days rather than the odd hour here and there) really helps me to move along the development road map, so here's a summary of what's been achieved this time 😀️.

If you're not familiar with eVitabu I suggest reading this post first.

Not alone

Most of the time I develop eVitabu on my own but occasionally my good friend and long time coding partner, Adam, has joined me.  I was pleased he was able to join me for this week and we were able to divide and conquer.  Importantly for me there was someone I could bounce ideas off or get help with troubleshooting.

Blame the cache

Originally I introduced caching to eVitabu and its partner web application to help save our African users some data.  Each time the app connects to the web server's API an XML file is downloaded that tells the eVitabu Android app what resources are available.  I've had to tweak that caching over the years to allow for different use cases, but it's still enabled for announcements.

To better plan development work, and prioritise features, we needed to know what version of the Android OS was being used by the end user.  This information is now being captured, but at one point I was stuck in a situation where the system would record the Android version one minute but fail to do so the next - all with no code changes.  Good spot points to Adam who noticed two things: one was caching and the other was that recording the Android OS version was only part of the announcement download.  With announcements being cached, the Android OS version would only be recorded once every five minutes.  Moving the recording routine solved that problem.

Having sorted a few issues (Adam must have slain several bugs) I elected to deploy a new release of EVM, the management web application for eVitabu.  I deployed version 1.10.0 and sat there confused that all sorts of functionality had died.  Caching at the database layer was responsible this time and clearing that sorted the problem.

Moved to PHP 8.0

EVM is written in PHP and the system had been running using PHP version 7.4 for quite some time.  As the PHP supported versions page makes clear, version 7.4 exits active support on 28 November this year and ceases to receive security updates in 2022.  I regularly complain at work about suppliers not moving to new versions, be that PHP, Java or .Net, so it was time to "eat my own dogfood".

After changing the development system to PHP 8.0 and running the full test suite (all passed), I swapped the staging environment to PHP 8.0 too and checked the Android app against it.  All good.  Finally I changed the production environment over and, aside for forgetting to increase the max file upload size (sorry Geoff!) all went smoothly.

As I work on various EVM features I'll be adding function return type hints and exploring other new PHP 8.0 features.

Tests and code coverage

I really should finish my blog post about automated tests, but the summary is that it's possible to write tests that can be run to confirm the functionality of your code.  These tests can save you hours compared to running them all by hand and can find problems early.  I tend to run the full suite of automated tests before deploying a new release of EVM, for example.  In a previous dev week it was automated testing that allowed me to determine I'd not correctly secured some areas of the web application resulting in anonymous access to some features.

Adam originally introduced me to tests and I've been using them ever since, so a benefit of working with him is that he also writes tests as he's developing.  With both of us writing tests it means the test code coverage for EVM is quite high - over 70% according to the PCOV code coverage driver.  As you can see from the image below, some areas of code coverage are better than others

As I write this post there's been further development merged into the main branch and overall test coverage is now 76.56%, which is awesome.

Keep field names consistent

This should be obvious, but keeping variable / field names consistent can save a lot of confusion.  While working on app based registration, a feature that's been in development on and off for a while, I noticed the Android app called the email address field email whilst EVM referred to it as username.  This caused some confusion between the two and meant registration was failing.  Initially I refactored the Android app to match EVM, but ultimately the username will be coming from the Google Oauth process so I was able to remove that from the data sent by the app altogether.

As nomenclature has changed there's some other fields that have retained their old names, affiliation vs denomination for example.  The user sees one term on the front end while the database column is called something different and this always throws me!  At some point I'll rename the database column to fix that issue (which will also involve refactoring a lot of code including updating the tests).

App based registration

A big part of my work this week was working on app based registration, in a bid to make the whole registration process smoother.  At present, and since the eVitabu launch in 2018, in order to get access to eVitabu's library of resources the user has to complete a registration form via our website.  Then they sign in to the Android app.  While this doesn't cause me any hardship, swapping between the app and a browser is not the smoothest of experiences and has caused some confusion amongst our target audience.

Our aim is to present a form in the eVitabu Android app itself, allowing the user to simply register from there.  There's still a number of challenges to overcome, such as how to display multiselect boxes for user language preferences or linking countries, districts and regions, but EVM is now able to handle a registration request from the app.  I need to handle some of the data that's currently being ignored, and sort of the location and language data, but then it'll be good to go 😊️.

New releases

Each dev week I try to make sure there's a new release of at least one component - either EVM or eVitabu.  I was able to release one for each, taking eVitabu to version 1.9.0 and EVM to 1.10.0.

EVM's release fixed a bunch of bugs such as preserving contributor logo transparency (earlier EVM versions used JPG images, which don't support transparency) and corrected download counts.  It also captured Android OS versions so we can determine what Android versions are being used and drop support accordingly later on.

eVitabu's release was very minor, only being changed to send the Android OS version number.  I can see not everyone has updated to the new version yet and that, so far, there's reports of Android 7 - 11 in use (Android 11 almost certainly me and the APF project co-ordinator, Geoff).

On version numbers

I use semantic versioning which means each version number, for example 1.10.0, has three numbers representing the major version, followed by minor version, followed by patch version.  The major version (1) will increase only when there's incompatible Application Programming Interface (API) changes between EVM and eVitabu - that'll be at one for a long time.  Most of my work causes the minor version (10) to increase and, if there's a bug fix following a release that doesn't add anything new, the patch version (0) would also increase.  Because of semantic versioning you can see that the Android app with version 1.9.0 will be compatible with EVM 1.10.0.

It's important to consider the version number is just three integers separated by dots.  Version 1.19.0 is version 19 in the API version 1 branch and is a later release than version 1.2.0.

Summing up

I think it was a productive week (four days) and I'm pleased with what we were able to accomplish.  Imposter syndrome stayed away for the most part, which was nice.  Now I just need to keep the momentum going so I can complete the app based registration part.

Banner image: Screenshot of the changelog for EVM 1.10.0 released on 6th October 2021.