Weekly Project Update 7
It’s probably just as well that this weekly post is mainly a public journal entry, rather than much of anything else. It feels like I didn’t do a lot of goal driven work this week. Everything done was mostly for the sake of doing something, mainly as a distraction to deal with the news. That said, there are some things that could be reported this week.
For Day One Sync, this week included a mix of frontend and backend work. The new Markdown to HTML translation code has been integrated and some work to clean up the code has also been done. Also, work to include the status of the last feed fetch in the UI has begun. Below the feed configuration is a small field displaying whether the last poll from that feed was successful, as well as what the last RSS feed item read actually was. Previously these labels were just placeholders but since that this information is now being recorded when the feed is polled, it can be displayed to the user when they open up that feed configuration in the UI. There are still some issues with the display. The first is that the status is not updated when the feed is being polled while the configuration is in view. To get an update, the user will need to switch to a different feed configuration, and switch back to get the updated view. I think I’ve got a solution to this involving the event bus and I’ve sort of started work on that, but it’s still early days so far. The second issue involves auto-layout. When the title of the last read feed item is long, the calculated width of the label pushes out the size of the window, making it wider. I’m generally not a fan of this sort of behaviour. I would prefer the window size remaining unchanged, and the label value being clipped. I’m still looking into how I can fix this.
I also spent some time on another project this week, just to provide some variety. I alluded to this project last week but I think it’s fair to write a bit more about it since I’ll be talking about it. This project, called Alto Catalogue, is a self-hosted music locker service for private music stored in S3. It consists of a web-app written in Go using the Buffalo framework that has been release as open-source, and an Android mobile client which hasn’t been released at all. I’m generally hesitant to write about this project as it’s in a bit of a frustrating state. It was one of those projects that was built for my own use, meaning that there are a lot of shortcomings that I myself can live with, but are a bit embarrassing if I were to share it with others. It might be that these limitations means that releasing this as open source makes little sense, which is a fair enough argument. But I guess another way to look at it is that the overall effect of open sourcing this now, with no-one looking at it, has the same overall impact as keeping it close. I guess you could call it the “tree-falling-in-the-woods” decision.
Anyway, I did some work on this project this week around adding group headings to tracks. This is especially useful for albums that would traditionally be released on multiple CDs, such as the most recent release of Oxygène, which features three disks, each one a distinct volume. Having a long track listing, all of them with names of the form “Oxygène X” where X is some number, makes it difficult to tell where these volumes actually are.
This was the main motivation for adding group headings, which can be defined on the first track of each album to provide some ease of locating the divisions. How this was implemented in the catalog service is also slightly frustrating, but could end up being useful. I originally considered using metadata for this, but the metadata system has some pretty large limitations related to its design. The first is that it is unstructured: you can define a metadata field with a key or value of your choosing, and no structure over the data, like requiring it to be in JSON, is imposed. This leaves the use of the metadata system largely undefined, which is great for allowing a variety of use-cases, but it does mean more work in the Android app to parse this metadata. That in and of itself wouldn’t be too much of an issue if it wasn’t for the second limitation, which is that fetching metadata is an extra HTTP request. This means that when the track list is refreshed, not only would the track details need to be fetched, but also all the track metadata as well. Given that this grouping would be used in the track list UI of the app, this will slow the process down.
So I wanted this information stored against the track. But I wasn’t too keen of having this stored in a dedicated database column as I’d imagine it would only be used by a few tracks. So I settled on a middle way, which was adding a JSON “attributes” field on the track. The field is meant to store “additional” information about the track, but unlike metadata, is not meant to be too free-form in what it is used for. I’d like to keep the field naming relatively controlled so that it could be used appropriately by clients. This is something that I explicitly decided against for metadata. The attributes field is exposed as a JSON text editor in the UI, but I can envision it being backed by a proper form base UI as well, another thing that would be difficult to do with metadata. Track group names is the only thing this new field is being used for at this stage, but I can see it being used for storing other things about the track, like track descriptions, recording date, artist if they differ from the album artists, country and year if the track is a Eurovision song, etc. We’ll see how it goes. If it proves useful, I may also add it to the album type.