RASMS v1 to v5: crashes, weak PCs and encrypted backups

Once offline RASMS was installed on teachers' computers in November 2020, real users started finding what I had missed.

One maintainer, many users

Some users reported crashes. Others said the system hung. I was the only person maintaining RASMS, so every report came to me.

I worked overnight to find the causes, fix them and get updates out. By the end of the second term, which ran from November 2020 to April 2021, RASMS had reached version 3.

The computers that couldn't keep up

Then a bigger problem appeared. Some teachers' computers had too little processing power to generate reports. The rest of the system worked, but the step that mattered most at the end of a term didn't.

I couldn't replace the computers. So I changed the question from "how do I make this machine generate reports?" to "how do I get this machine's data to one that can?"

The .rasms file

I built a backup feature that exported the whole database into a single file with its own extension: .rasms.

Because that file held everything, including personal information about around 500 students, I encrypted it with AES and used MD5 and SHA-256 hashing in the process, with the aim that a lost or copied file could not be opened with ordinary tools.

That gave the school a new way of working:

1. A teacher on a low-spec computer entered their data as usual.
2. They created a .rasms backup.
3. They moved the file to a more powerful computer.
4. That computer restored the backup and generated the reports.

Version 5

In the third term of 2021 I released version 5, with processing optimisations on top of the backup workflow, so reports generated faster on every machine.

From then on RASMS worked reliably on Windows and offline. The headteacher received backup files and could open them whenever needed to review the school's data, without depending on any one teacher's computer.

What I took from it

Being the only maintainer is a risk, and users feel it. Overnight fixes kept the school running, but they also showed me why systems need more than one person behind them. It is one of the reasons I later built a company and a team.

When you can't move the computation, move the data. The backup started as a workaround and became the way the whole school worked.

Protect data even when nobody asks you to. Encryption was never in a requirements list. A student database is sensitive, so it was the right decision anyway.

The weakest machine sets the requirements. Performance work isn't optional when your users' hardware is a constraint you can't change.