Monday, May 19, 2014

Qobuz One Week On

After 1 week of use, I have decided not to pay £20 per month for Qobuz HiFi streaming.

The audio quality is superb and long may this type of service continue! But, Qobuz do not offer a DLNA solution which means I can't easily integrate with my existing HiFi; the result of this means I can either stream exclusively from Qobuz or exclusively from my own collection of music. Since Qobuz isn't as complete as it could be, it makes the exclusively Qobuz experience less desirable, even less if I own studio master albums. In many cases I could purchase the music directly from Qobuz and therefore get the rights to stream it, but this would mean repurchasing many albums which would be crazy! It would be good to be able to upload my existing CD rips or flac purchases to Qobuz (Google Play Music style) for me to listen exclusively through their app.

Their desktop app is okay, I covered most in my previous post, the playlist management is very poor I found moving tracks about in the playlist almost impossible and in some cases managed to duplicate the playlist items when removing tracks from it.

Building on the lack of DLNA and incomplete music library, for the price of £20 per month I can get quite a few CDs so another question asked could be how much new music do I discover each month? The answer to this is quite low, 1 album a week a week would be very generous!

Therefore on the basis of cost, lack of integration with my existing music system and incomplete audio collection, I have decided their paid for HiFi streaming service is not for me.


Thursday, May 15, 2014

Using this or that in Javascript, or maybe bind?

When accessing the current context from within an anonymous function in Javascript one usually assigns the current scope to a variable and it gets closed over:

For example:
_ = require('underscore');

var y = [ 'this', 'that', 'whatever' ];
var test = function () {
  var that = this;
  this.x = 'use ';
  _.each(y, function(item) {
    console.log(that.x + item);

We had a little debate about whether we should use 'self' or 'that' to pass in the context. But maybe we're all wrong, because there's a function called bind in underscore which handles all that for us...
_ = require('underscore');

var y = [ 'this', 'that', 'whatever' ];
var test = function () {
  this.x = 'use ';
  _.each(y, _.bind(function(item) {
    console.log(this.x + item);
  }, this));


Test Driven Development

Recently I watched David Heinemeier Hanson's controversial railsconf keynote and I thought I'd express my views.

His main argument suggests TDD is dead. Oddly I agree with many of his headline views which I try to document below. I just not convinced of his supporting arguments.

DHH appears to have a dim view on TDD practicing developers; whom he generalises write simple unit tests having 100% code coverage, use many mocks, but test nothing real. His example was a bug in Basecamp which lost customer data, their code had 100% code coverage, but still didn't work. I really doubt there are many developers who just stop when they hit 100% unit test coverage?

I'm not going to speak for everyone else; I only started using TDD (not exclusively) about 18 months ago despite 12 years developer experience writing some really cool stuff, some well designed and some not so well...

The well designed stuff has tended to be driven by TDD. I've never used code metrics, I use TDD to help focus my mind on the current thing to write. By factoring a problem down into smaller chunks I can focus very well and avoid 'coders block'. I've never approached factoring from a test perspective, I've tended to think how the architecture should be sculpted and broken down. I can usually find a bite-size component to write a test for and implement, it also ensures you can optimally test many permutations of a system using more than 1 unit. More importantly, the tests I write provide a specification for what I expect that thing to do.

This practice has a danger that you might forget what you originally started to break down - 'the story'. I'm not going to pretend I've never had 100% tests pass and no working system, in fact recently I wrote an email sending service, but forgot to include a real template so the email would be sent to the correct people, but with no body (I'd mocked the template in a test and asserted the correct data was received), this system was never deployed but if I'd concentrated solely from a point of unit tests it could have been. In this and other cases you still need a guiding light to ensure you don't write a suite of insufficient tests or even direct development in the wrong direction. In this example an integration test using the real template was sufficient. This provided me with confidence the the units were being invoked correctly and if the template were to be broken in the future I am confident the test would fail.

Where I work we use integration tests to ensure the services use unit tested modules correctly and ultimately acceptance testing to ensure things do work as the user expected using real databases and real services; only in very rare cases components are faked for acceptance testing if absolutely required (say to avoid sending real emails).

I like decoupled unit tests with an encompassing system level test. Testing only at integration level would lead to far too many permutations of code paths which could lead to poorer test quality.

I am also happy that acceptance tests take a while to run too, with automated tools like Selenium you can perform this within a few minutes before a push. The integration tests run in less than 10 seconds and the unit tests are pretty fast.

A big danger when using mocks during testing is where your assumptions have changed, say a field is removed or renamed in a web service or database response. If this data has been stubbed in your test, your test will always pass despite never being able to work for real. These types of problems I'd never really encountered before using TDD. It makes code reversibility difficult as the production code migrates to a new style of architecture the tests might not be properly aligned meaning problems occur in user testing that really should have been caught during the code redevelopment.

I admit in a few cases I've wondered why some unit tests run slowly and I will investigate the production code to see if it something that can be optimised. Sometimes something I have no control over but has a known and fixed interface can be safely mocked out. However if it the test is slow because of the production code, I'm not going to cut corners just to make the test suite run faster, that reduces the usefulness of the test. Architecture and production code should become the first priority once the associated tests give a certain level of confidence.

DHH further generalises his view of a developer to one that then 'sprinkles some design patterns' on their code once their tests pass.

I only recently started reading about design patterns and I realised I'd already been using them for many years only now I had a name for the shape of the code and could describe an implementation with a common language.

Toward the end of his talk DHH advocates readability which I wholeheartedly agree with, I really like using functions which read like 'reject where x is y' rather than 'filter x is not y' or 'unless x' in favour of 'if not x'. I'd rather the code explains what it does than have a comment which may not age well.

Finally, the way DHH got a clap for mentioning the delete key is the best way to improve code reminded me of Steve Jobs getting applause for announcing an HDMI cable in an Apple keynote...

I watched this Hangout with interest:

And will be watching the second part too:

Monday, May 12, 2014

Moving on from Spotify

So after 5 years of regular listening, I'm moving away from Spotify, the last 3.5 were premium subscription originally so I can listen on my mobile, then for use with Sonos; and later so I can stream high quality music.

I let my subscription lapse because the streaming market is a very different place than when I first joined Spotify. Initially I was going to try Google Play Music All Access, but after reading about Qobuz I was intrigued by their FLAC streaming service.

They offer a 1 month free trial and I started my subscription yesterday, before I forget my first impressions I thought I'd post them here.

I started by using the web player which I found a little clunky, a few albums I searched for had greyed out tracks which played, but appeared to jump. I then noticed the music was streaming as MP3 and realised I had to install the desktop application for lossless. Using the desktop app led me to discover the greyed out tracks were 1 minute samplers with a link to purchase the track from Qobuz. However there is a helpful text message which appears explaining why the music is not streamable.

I very quickly got used to the interface and could overlook the occasional French messages appearing. I liked the idea of favouriting albums, artists and tracks as my Spotify account is awash with playlists containing just an album (although they have now solved this in their latest release). I quickly looked at my recent Spotify additions and added those albums to Qobuz, there were 1 or 2 albums not available but the vast majority are. One major downside for me is the inability to upload my own music purchases to make up the shortfall, although all purchases from Qobuz (often 24bit) are automatically streamable - I'm not sure if studio master purchases will be streamed in 24bit or if you get the 16bit version, I imagine the 16 bit version.

I noticed a cheeky import playlist from Spotify which I tried with a mixtape playlist I created back in 2012 containing 66 tracks of mainly electronic music, unfortunately only 30 tracks made it through. I found on a few occasions there was a slight difference in the album spelling which could have caused some of these failures. For example, Beastie Boys' Ill Communication is available in both services, but in Spotify it is suffixed with 'remastered edition'.

I decided to pick a few tracks to do side by side comparisons. Using Songcast on my laptop to stream to my Linn I played a CD quality track through the desktop app and the same through the webapp at 320kbps MP3 and could tell the difference.

I then played one of my own FLAC rips directly and compared with the FLAC streamed equivalent. My ears could not tell the difference. I tried this for a few tracks with consistent results.

I installed the Qobuz iPad application which seems to be much more responsive than the Spotify iPad app, I can then Airplay the Flac stream. I had to go through the options to make sure the quality was set to lossless. I like the iPad application which also includes a facility to read digital booklets of albums and in some cases browse the original LP sleeve!

The recommendation playlists of Qobuz aren't quite as good as the targeted suggestions made by Spotify, but they are enough to discover new music and there are plenty of links to related artists and albums. I actually discovered a new release by Mr Scruff out next week! I was able to favourite this album which will become available once it is released.

I am so far pleased with the service and in fact have exclusively listened to Qobuz tonight at home ranging from John Williams' Albeniz and Miles Davis Kind of Blue to the Chemical Brothers and even Disney Pixar's Greatest Hits!

I really like the idea of FLAC streaming and want to encourage this type of thing, the ultimate question however; is it worth the £10 premium? Hopefully by the end of the month I'll have an idea!