My longest-running project (2016-present): LMS analytics system, Part One

When I was 14, I was a happy homeschooled kid in a devout Catholic family, and I had been taking classes for two years from Homeschool Connections. I was quite ahead, doing 10th grade work and mathematics (Algebra 2, if I’m not mistaken). This was before homeschooling became more popular after the COVID-19 pandemic.

Between being homeschooled, having many siblings, and having a surprising amount of free time, I had been experimenting with BuddyPress and WordPress for almost a year. Before Homeschool Connections, I had taken classes at a now-defunct online school which had a messaging system, but it was shut down due to it having no moderation system. While most students were generally well-behaved, the occasional undetectable incident forced the closure of that system in my old school. With my technical mind, I wondered how I could share my knowledge and learn from other students in my new school.

I set up a simple BuddyPress website, spent a long time perfecting it, and presented it to the president of Homeschool Connections. Though interested, it wasn’t the highest priority for him. Instead, he had a very different thought. His company has a subscription-style business model, similar to Netflix, Coursera, or Pluralsight. You pay your $30 (now $35) a month, and in return you get unlimited access to their catalog of courses. Unfortunately, it was very difficult to know how to pay teachers accurately or fairly long-term. A recurring royalty would have been ideal, but there wasn’t a good way to figure out what royalties were owed, or what courses and teachers got the most attention. He contacted Moodlerooms, his learning system hosting provider, but they wanted “an arm and a leg” for the service.

We sketched out the general idea together: Every time a student clicked on a course, this would be tracked as a view and sent to a database, which had the names of each course, what category the course belonged to, and the name of the teacher instructing the course. With this data, we could then find out the total views the teacher had, by adding up all of the views for the courses that the teacher instructed. Every view would be timestamped, to allow analysis over a specified time period. With this information, you could get a pretty good percentage of how much website traffic was to courses taught by a specified teacher, and this could be used as a factor in figuring out what royalties to pay.

I got to work that very day in the language I knew best: PHP 5.4. Yes, a 14 year old writing PHP 5.4, which has a reputation to this day for being an unusually poorly-designed language, even if it was fairly easy to learn. But, hey, it was a project, and I got to work immediately. In those days, I didn’t even know or care what these things called Version Control Systems were. If I wanted to add a new feature, I copied the folder holding my code and worked on that. If I didn’t have a backup and managed to screw up my code royally, I’d spend up to an hour fixing my code until it ran again. I used Bootstrap 3 as my front-end, because why not? You’ve got to start somewhere.

Eventually, I ended up with a ridiculous amount of files, most of it boilerplate. My code wasn’t very secure, or pretty, or well-documented, and had wildly inconsistent variable names. Despite looking atrocious in the backend, it worked, and the frontend looked pretty good for 2016. If I did anything technically right, at least I used PDO to keep my database somewhat safe.

I don’t have any screenshots surviving that I could find of what it initially looked like, even though I remember taking a few. Maybe they are on a backup hard drive somewhere? I did, however, manage to get the latest and last version of Tracker 1.13 running on my laptop with a little tweaking to the source code. It wasn’t meant for PHP 7 and it will let you know quite clearly.

So, with that, the administrators could easily see what courses were getting viewed the most, and what teachers should get the most (or least) royalties. You might be slightly curious about how I implemented this without using a Moodle plugin.

The company was, at the time, on Moodlerooms, and they didn’t allow community or unapproved Moodle plugins without a very expensive code review. It was part of the deal that there needed to be some way to figure out what courses were getting most viewed without needing an expensive plugin.

I’m not going to share my full technique, but basically, the admins created a “parallel” copy of all courses within my program. Every time a course was added to Moodle, it was added to my program as well. I then used some JavaScript within Moodle’s theme which scanned the URL a user clicked on for a course ID. If it found one, it added a view.

My database wasn’t exactly pretty, but it was functional: There was a table for every course, and in each table was a row for date and views on that date.

Adding up the views for a teacher was simple and slow: Just open up the table for every course the teacher taught, and add up the views for all of those courses, and repeat for every teacher. I didn’t know how to do good caching either, so my initial implementation could take a good ~30-60 seconds to process on a good day.

Even though the code looked atrocious and was difficult to fix, the company was impressed and I sold it to them for what was, in my estimation, a significant amount of money. Even though it was slow and had awful code, it worked and was actually almost bug-free. Other than a bug with timestamps after a year rollover, the company never contacted me about any major bugs: “It just works!” They did have some ideas for improvements though such as Excel exports, which I quickly added using a library. (Those were another thing I hadn’t known about. My initial version didn’t have any composer dependencies! Handy things, libraries!)

My program ran for about 2 years in production without fail. I sold them my program just after my 15th birthday, but I was learning so much about how to do things better that it didn’t age well in my mind. Even though the company didn’t really care, I was learning better ways to do almost everything.

Shortly after my 17th birthday, I discovered Laravel and Laravel Nova, and I was hooked.

Part Two coming soon, and revisions to this article

Published by Gabriel Sieben

Gabriel Sieben is a 21-year-old software developer from St. Paul, MN, who enjoys experimenting with computers and loves to share his various technology-related projects. He owns and runs this blog, and is a traditional Catholic. In his free time (when not messing with computers), he enjoys hiking, fishing, and board games.

Join the Conversation

2 Comments

Leave a comment

Your email address will not be published. Required fields are marked *