Unfortunately I did not have much time to update my blog. But I’m not dead and neither audioserve is – actually last half of year or so I focused on building new client. As of now new client is ready for production (version 0.3.3 +) and server has some new functionality too, mainly to support new client.
There is now online demo automatically built from master branch (shared secret is mypass).
Wondering how you project is doing on github and stars and growing over the time? I was (for my favorite project audioserve) so I created ipython notebook for to analyze trend on the time, which some predictions (which are now called AI – even linear regression is now called AI :-).
Recently I released new version of audioserve v0.16.5, which brings some interesting changes. I think I’ve described them in previous article and for sure they are also described in README. This release was focused on two major themes – performance and API. Concerning API – I’ve created small funny page using WebAmp audio player (Web recreation of famous WinAmp). It’s just for demo how audioserve API can be easily used, not everything works reasonably as WinAmp was focused on music. I have been using WinAmp some 20+ years back, at dawn of the past century, so I could not resist to play with it when I saw it.
Not yet. However I did not publish much in last 9 month or so due to several reasons- and covid was not the least significant one. I started couple of interesting things, but was lazy and demotivated to sum them up even in small article. I also changed my job few months back, which kept me quite busy, but positive impact was I’m waking up from lethargy caused by covid and past job.
So I’ll try to quickly summarize past year or so in here, it’ll be nothing special, just to have things accounted:
Not much, but definitely it’s not dead. Actually I’m quite happy with current functionality and do not need more (actually there are couple of things that would be nice to have like shared bookmarks and read/finished audiobook attribute, but these will probably require to go beyond it’s simplistic design) and I’m using it every day. But some coding was done during past year and some small improvements were implemented.
I’m still playing with small exercises, one interesting is “alphametics” (it’s available on exercism). Exercise goal is to evaluate if an expression like “SEND + MORE == MONEY”, when letters are replaced uniquely with numbers, is valid equation (more details in link above). As I have written in previous article, I try to think about performance and this exercise was quite interesting from that perspective.
While I was updating audioserve I hit one part of code, when I was passing a not so big structure (containing data for authentication) to asynchronous task (in tokio multi-threaded executor), as task might run potentially in different thread it has to have static lifetime. Easiest solution was to clone the structure and move it to thread (which was original solution). But during refactoring I realized that reference count – Arc type could be better solution – it can save a small piece of memory (Arc is 8 bytes), but also it could perform better (or could not?). To check my later assumption I’ve run couple of of tests.
I’ve finally found courage to look after migrating audioserve to new hyper and tokio and futures crates. As new futures (0.3) are significantly different from previous version, mainly due to support of async/await keywords, I was expecting significant effort, so I was kind of delaying it. Now when it’s almost done, I’d like to reflect a bit on the effort. Firstly – it was not as bad as expected (although after updating cargo dependencies I’ve got about a hundred of errors). Secondly – there are some patterns to follow in migration, which I’ve like to describe further in the article.