Once again, I got sidetracked from Sone development. More or less caused by my moving from Linux (and Windows) to OS X I am currently developing a replacement for the software I used for tagging and organizing my audio files. I used to use JRiver’s Media Center for that but as its OS X port still has a very long way to go to be at least partially usable I decided to write my own software, at least for tagging, converting, and organizing my audio files. So, if I’m currently coding, I’m probably working on AMS.
Author: Bombe
Why Sone Is Stalling Again…
At work we started watching “Clean Code” by Robert C. Martin (“Uncle Bob”) a couple of weeks ago. While some colleagues are of the opinion that these videos are unbearably stupid (and they do have a point: the way all the knowledge is presented is… uhm… questionable, at least) I have grown quite fond of some of the things Uncle Bob has shown us.
Two points that have especially struck home for me: keeping methods short and test-driven development. While the former is (more or less) easy to implement the latter requires more discipline and is also difficult to work with when a sufficiently large codebase already exists.
So lately I have been writing tests. Thousands and thousands of lines of test code have been added to Sone; in the process I was able to eliminate almost the same amount of lines from the production code because it proved to be unnecessary after various refactorings have performed.
However, one of the targets of the current refactoring still has not been achieved: storing everything in a database. I am a lot closer to finishing this task, though: most objects and their relationships are already managed by a non-persisted, in-memory database. Persisting the database will be a second step that follows later.
I will continue writing tests and increasing coverage to make it easier to finish the big refactoring. Unfortunately that will mean that there won’t be a new Sone version in the near future.
Sandboxing
Every now and then somebody pops up and wants to know how sandboxing is done in Java. So, a couple of years ago I sat down and spent two weeks figuring out how it actually works.
Code Deterrent
As mentioned in the last post I am currently busy rewriting the album and image handling stuff. Unfortunately it’s a lot more complex than I had initially estimated. Plus, we currently have the best summer, like, evah, and I don’t actually get to spend much time in front of the computer. :)
Back to the Sone
After a hectic week I seem to be getting back into Sone development. Let’s recap what happened:
On Saturday, the 29th of June I released version 0.8.5 of Sone. This version consisted of a branch I had been running locally for several months now, and a couple of changes I put in next some time ago for, well, the next version of Sone. Two things happened: the changes clashed with each other, and with LCWoT (digger3’s version of WoT). I spent the following week figuring out what’s wrong and managed to get it all fixed by Friday, the 5th of July, when I released 0.8.6.
Coding by Toilet Breaks
I just had a revelation while sitting on the can: the generation of the “I need another source because this one is empty” event happens in the wrong place. The MultiSource will of course detect the end almost immediately after a source file is decoded which can happen in just a few seconds (even if your MP3 file yields seven minutes worth of music) so obviously (obviously!) it should not send the event; instead the final sink of the pipeline should tell somebody that the source of the pipeline needs new data. Now I only need to figure out which sink I should listen to in case I have several sinks in a pipeline (e.g. one for a streaming server, one for local audio output).