It was with the best of intentions that I made dev diary entries 1, 2, and 3… and here we are, over two months later, with nary a word since.

BLIS Cloud CLI

The BLIS cloud CLI is available to be used on Ubuntu servers. It is a fairly lightweight Python wrapper around apt, docker and docker compose. It is not particularly complex, but I am proud of it because I think it is a better user experience than asking end users to manage containers themselves.

Design considerations

  1. Our stakeholders were identified as using Digital Ocean, and generally used the web terminal interface. This interface is not always consistent so things like TUIs (in my experience) sometimes break. For this reason I wanted the BLIS CLI to be imperative and not overly interactive.
  2. I wanted to limit the number of possible commands. Ideally there should be 1 command for the task you want to perform (blis install, blis start, blis update)
  3. Dependencies should be limited so installation is easier. I still needed some 3rd party Python packages and for this I found Poetry to be really impressive for installing them without having to worry much. End users only need to have Python and Pip installed.

Continuing Windows compatibility

As outlined in the first dev diary, BLIS on Windows uses a portable LAMP stack that uses some old versions of MySQL, Apache2, and PHP. Unfortunately, I was not able to change this at this time, so compatibility with this set of Windows programs had to be maintained.

To better test this in my preferred environment (Ubuntu), I used WINE to test the Windows version.

Excel Export

A frequent feature request has been support for exporting documents to Excel. For a lot of projects, this means adding a CSV export, but I wanted to do better. A real Excel spreadsheet would have multiple sheets and better formatting.

To achieve this, I used PHPExcel to create richer spreadsheets. You can see how that works here.

Future Work

I received feedback that the Excel export feature I added was good, but there were additional report types that they would like to export as Excel sheets. I still need to understand what the requirements are (ie. what are these reports used for? If I know that I can shape them appropriately) but I think this would make a good task for a future crop of C4G students.

I also put some thought into making a replacement for the Server2Go stack that BLIS uses. There would be number of advantages of migrating different parts of the stack, but chief among them would be updating the version of PHP that can be used and providing a better development experience. I having been thinking something like:

  1. Process manager written in Rust: the Rust standard library includes abstractions for managing processes and it seems to be very cross-platform. There are also bindings for Win32 APIs that could be used to create an executeable with wide compatibility.
  2. Caddy for the Webserver: the killer feature of Caddy is the automatic HTTPS certificate management if you set up a domain. BLIS has a small dependency on Apache2, but it would not be hard to replace. Additionally, Caddy would be very easy to set up in a Docker container.
  3. PHP-FPM: This would be straightforward. If we used PHP-FPM we remove our dependency on Apache2.
  4. Possibly SQLite: MySQL works fine and provides us nice features. Additionally, it would potentially “scale” better if someone wanted to use a multi-node BLIS server setup (something I would definitely not recommend). However, using SQLite would remove a dependency on an additional process on Windows, and I don’t believe there is a hard dependency on MySQL features right now.

“Cool” vs. “Useful”

All of the above thoughts are things that personally interest me and not necessarily things that are important for downstream stakeholders. It is important with any project to make sure that the actual problems are being solved, rather than ignored while other, unrelated or imagined problems are “solved” instead.