First feature development (7/11/2022) (3h)

[g105b]

3h development @g105b

1200: set up a new project and lay out the skeleton file structure for the first tests.
1215: class planning.

The first thing to do is figure out a general class structure for the most basic functionality. Because the app is going to support anonymous users, we should have the concept of a "User" in the system, but for now that'll just be a randomised ID. The plan for authentication will be to use Authwave, which will also just provide the app with a randomised ID, so the code won't need to be adapted for adding authentication.

The first thing a User of the system can do is upload one or more files, so these files need to be represented by a class. The type of file they upload can be anything, and it's the job of the app to understand the context of what's just been uploaded, so the Upload class needs to be abstract, extended by concrete classes such as PRSStatementUpload or UnknownUpload. This is the first thing that can be tested, so I'll make a start now and cover this functionality within an UploadManager class.

1225: This is the first test, without any implementation. We upload a file with weird data that doesn't have any relevance to Trackshift, and we want to see it as an UnknownUpload rather than crashing.

1230: This is the simplest possible way to satisfy the first test. It just returns an UnknownUpload, no matter what. But the test passes, so next up I've got to flesh out the functionality so it can detect a type of upload.

Oh, and by the way, Github Actions now runs the tests each time there's a commit: https://github.com/SuperHyperInstantFutureTime/Trackshift/actions/runs/3410359570 - Behat tests will come when there's web interactivity to play with.

1235: The second test uses a known PRS CSV header format and require a little bit of real implementation... but I've got to remember to not add any complexity, and only do the bare minimum to satisfy the test.

1245: The PRS statement detection is simple - it checks whether the file is a CSV, and if so, it checks for some known column headers.

Break: 20m

1320: I want to dive straight into adding value to the software, so I'm going to start writing some tests for the PRSStatementUpload, to drive the feature of creating a track amount aggregation.

Something I want to note here for another time is that I'm going to purposefully write some re-usable code directly into the PRS-specific implementation. It's probably accurate to say that all Upload types will have functions like getTotalUsage(), but until I get to the implementation of the other upload types, I don't want to think about it... so it's all going in the PRS class for now.

1330: After a bit of planning, I have some questions that I'm going to run by Biff:

1. Within a single statement, each track can be listed in different currencies. How should this be aggregated?
2. Within a single statement, one track can have different usages with a varied Share amount. Should this be taken into account when calculating? If so, does a usage line with 50% share and 0.01 Amount get calculated to 0.005 Amount, or is the 0.01 already taking into account the share?

I just had a chat with Biff and the answers to the above questions make everything really simple: The currency field is misleading - all values in "amount" are always in GBP. The currency just means which currency was used by PRS to invoice in. The Share field indicates what the Amount field is a share of - so the amount is always the amount made by the artist, after calculating the share, in the artist's local currency.

1340: Test: Getting the usage total of a PRS statement.

Break: 30m

1420: The total is now getting extracted for PRS statements. To get the basics working, I implemented basic Money and Usage classes, which will need to be tested separately when we come to it, but PHPUnit remind me to do it be complaining about the classes not having 100% test coverage.

1425: The last bit of functionality I need to implement now is to aggregate the usages by their song title, so here's the test for that.

1450: The aggregations are now adding up nicely. The last bit of test driven functionality I'd like to do today is to iterate over the aggregations, then I'll drop this into an HTML table and hook up the upload of a real file. Let's see if I can do this before half past.

1515: I've added an Iterator to the Aggregation class that allows an Aggregation to list out all of its usages, collated by a single property (e.g. all usages for one track name). Next up: web interface.

1540: The most basic and hacky web interface possible, quick demo:

The code that represents the logic of the system has been developed from the tests first, which massively helps keep things simple and fast to prototype. The index.php code linked above is really hacky for now, just to visualise something, and contains a bit of its own logic (like sorting by amount, for example), but in time I will refactor it to only call the functions within the classes that are already tested.

That's enough for today. Will catch up with Biff soon.