A fork in the road

So, the university's computer science society issued a programming problem to be solved before next Monday.

Whilst people boast in the society IRC channel about their linear-time solutions measured in hundreds of bytes of source code, I'm left with a cubic-time brute-force algorithm and the distinct inability to think my way into finding a linear solution, despite hours of concentration.

And I start wondering to myself: I've never outshone others in the field of raw problem solving.  My interviews at Oxford went down like a lead balloon, after all.  Will this ever change?

I live in hope.  My dream at the moment would be to never leave university, to continue on as a postgraduate and then a researcher.  I'd love to be able to push the envelope for computer science, to contribute to society without the humdrum of a standard programming job.  That, and I can't bear leaving York and its lovely but unpretentious campus and atmosphere behind.  Not yet, at least.

But to be an innovator, I would need to be able to think outside the boundaries, to be creative and, well, innovative.  If I can't find a foothold in simple programming exercises, then that worries me - I need to find some field I can push the envelope in, and that's one door that already seems to be closing.

I seem to be very much a man of practice at the moment - I found the practical programming strand by far and away my favourite bit of the course last year, as well as the easiest.  I actively enjoy practical programming, especially re-implementing existing ideas in a cleaner or better way, and part of me is convinced that this is my true calling.

We'll see.

Out with MPD, in with SPI

A short while into implementing MPD, I realised that there are a few sticking points that preclude it being a good fit for SLUT's design.

The primary issue is that MPD manages its own database.  This would be fine if it weren't for SLUT's intended position at the bottom of the BAPS2 stack, below the database level (and University Radio York already has its own database, with its own management tools).

Secondly, the use of MPD in SLUT requires SLUT to connect on the TCP level to three separate servers, controlling each via a separate protocol from that used to tell SLUT what to do - this indirection would provide overhead as well as added frustration for the Computing team, who will have to ensure that four server processes are running in tandem.

There has, therefore been a design change:

• SLUT will now use an internal playback engine, based on the Java Sound system using its Service Provider Interface (SPI) to support a variety of file types.  MP3, FLAC and WAV will definitely be supported, and these (alongside WMA, which will likely be unsupportable) are among the most requested formats by users of the original system.
• The SPI playback engine will be inherited from a previous project I started on github while learning Java, JOPS (Java Originated Presenter System), which was itself an early exploration into how BAPS could be replaced by a Java-based system.  This, itself, was IIRC based on sample code. =P
• This will remain abstracted from the controller set, such that it can be replaced with a more efficient playback engine later.

Hopefully this will allow SLUT to be up and running before the end of the summer whilst keeping it manageable and cohesive.

Icelünd, Iceland

So, I've managed to somehow finish the first year of university and plunge into the mire that is the University of York's incredibly over-generous summer holiday (start of July to second week of October!)

I haven't yet thought about getting a job to tide me over.  This is partly because I still have quite a bit of student finance left to live on, and partly because I have a lot of voluntary stuff to do for University Radio York over the year.  I'm almost glad I didn't get into GSoC, thus.

Stuff I'm working on:

• SLUT, the Streaming Library of URY Tracks, which will (along with the URY API) be a replacement for the Broadcasting and Presenting Suite server system.  It is going to be a minimalist but extensible Java controller for external playback systems (initially, MPD) which arranges them into channels which can then be controlled by JSON-RPC.
• The URY website.
• The URY API, (what will become) a PHP-based REST-style API for securely accessing URY's database assets.  This will in turn become part of the new Broadcasting and Presenting Suite.

It returns!

I keep forgetting that this exists.  I should really work on improving my memory.  =P