Blogging Options Paralysis

At least once a year I think about moving this blog off blogspot. When I started this blog back in 2007 I picked blogger over wordpress, as I thought Google’s ownership of blogger would mean that it would soon become the premium choice for bloggers. I was wrong. Blogger has stagnated, and I’m still here six years on with the same (somewhat naff) URL, a very bland theme (which I occasionally attempt to improve, although I am always thwarted by my total lack of CSS skills), and a very clunky administration interface which sends me email notifications about my own comments.

So I should switch to another blog provider right? The trouble is, every time I start to plan a move away, I get stuck in options paralysis. I do have some free Azure credit thanks to my MSDN subscription, so it makes sense to host it there. But there are still too many choices…

Option 1 – Stick with Blogger and Customise Theme

The boring option. Stick with what I have, and just give the CSS a makeover.

Advantages:

• No need to migrate content
• Get to keep all my existing post URLs
• Probably will be best for SEO (although my blog hardly gets a lot of traffic)

Disadvantages:

• Editing blogger themes is awkward
• Limited control over other aspects of the site (such as hosting additional javascript files)
• Can’t change to a custom domain name without breaking all existing links to old posts

Verdict: Probably what I will end up doing since I am lazy!

Option 2 – WordPress

The option I probably should have gone with originally. I host another blog on WordPress, and it has been a pleasure to maintain compared to other blogging options I have tried (previously that blog used serendipity).

Advantages:

• Does everything a blogger could want and a lot more
• Access to lots of nice looking themes
• Has plugins for everything
• Polished admin interface
• Now keeps itself updated to the latest version (very nice indeed!)
• Good spam detection

Disadvantages:

• Needs MySQL, which can be a pain to host. Azure lets you have a free 20Mb instance, but after that you need to pay quite a bit more. I could use an Azure VM with MySQL installed, but then I need to keep that patched.
• Written in PHP, so would need to learn that to do my own extensions.

Verdict: If WordPress worked against sqlite or postgres this would be a no-brainer.

Option 3 – Ghost

The newest and coolest blogging platform, written in node.

Advantages:

• Lots of momentum, likely to become a very nice platform
• Doesn’t require a separate database server
• Azure has a template to make installation easy

Disadvantages:

• Doesn’t currently auto-update itself like wordpress can
• Doesn’t include a commenting system (would need to outsource to disqus)
• I don’t know node, so adding custom features might be tricky
• Runs on an Azure VM rather than an Azure Website, so would need to keep the server patched

Verdict: A good choice if I want a chance to improve my node / Linux understanding, but I’d like to wait and see how it develops

Option 4 – A Static Blog

You can do a surprising amount with a static blog and there are several choices here. Main ones are Jeckyll and Pretzel or Sandra.Snow (.NET based alternatives).

Advantages:

• Simple to deploy
• Cheapest option to host
• (Jeckyll) lots of themes and plugins available
• (Pretzel) written in C# – I can hack it and add features easily. I actually contributed a Blogger importer for Pretzel a while back, so I know it fairly well.
• (Sandra.Snow) written in C# – a demo video shows how to upload to Azure with git publishing

Disadvantages:

• (Jekyll) requires ruby, which I have no experience with and probably a Linux VM to develop on since installing on Windows is a nightmare
• Pretzel not under active development (but getting occasional features added)
• Comments need to be hosted elsewhere (disqus)
• Can lack flexibility with regards to URLs, and historical search capabilities.
• Some of my existing posts don’t convert to Markdown very well.
• Bit more of a pain to do scheduled posts

Verdict: Still one of my favourite options, although static blogs are a bit clunky when it comes to features like archives and tag browsing.

Option 5 – An ASP.NET Blog

There used to be quite a thriving ecosystem of ASP.NET blogs including SubText, BlogEngine.NET and DasBlog. Of those three, blogengine.net seems to be the only one that is still going strong.

Advantages:

• No problem getting it runnning on Azure
• Posts can be stored as XML, so no need to worry about a database
• Supports comments
• Written in .NET so I can create my own widgets / plugins

Disadvantages:

• Not so many themes available as wordpress

Verdict: Certainly a workable long-term solution if I plan to host on Azure

Option 6 - Fork Miniblog

I’ve been playing a bit with Mads Kristensen’s MiniBlog, which is basically a really stripped back ASP.NET blog, with the bare minimal functionality.

Advantages

• Simple C# project – small enough for me to understand
• Posts stored as XML
• Already does 95% of what I want
• Windows Live Writer support

Disadvantages

• Rudimentary admin interface
• Would need to write my own migrator for posts and comments (although have been prototyping this and it is nearly done)
• A little awkward to keep my custom changes in sync with those on GitHub
• Need to develop my own theme
• Not entirely sure whether I would end up overwriting post XMLs and losing comments if I deployed with git

Verdict: One of my favourite choices so far, would be a good way to improve my ASP.NET & web development skills

Conclusion

I still can’t decide what to do, so maybe I’m stuck here on blogger for another seven years. Tell me in the comments what you’re using, and whether you recommend it or not.

Essential Developer Principles #5–The Short and Simple Principle

Last time in my essential developer principles series, I gave my own slightly modified version of the Open Closed Principle, and once again I want to give my own take on one of Uncle Bob’s famous “SOLID” principles.

Single Responsibility?

The “Single Responsibility Principle” states that each class should only have a single reason to change. The basic idea is that each class should do one thing only. As soon as you detect your class is doing two things, then it is time to refactor one of those responsibilities out.

All well and good, but the trouble is that the concept of a “single responsibility” or a “single reason to change” turns out to be quite hard to pin down exactly. In my early days as a computer programmer, my applications would contain files such as “database.c”, “graphics.c” or “comms.c”. This is a nice separation of concerns, but the trouble is it doesn’t go far enough. Those files would quickly grow very long and unwieldy despite arguably having a “single responsibility”.

Nowadays you can encounter classes like “MainForm.cs” or “AdminController.cs”, which again conceptually have one responsibility, but they typically grow larger and larger over the lifetime of the project until they are several thousand lines long.

In fact the number of lines of code is I think the single best indicator of violation of the Single Responsibility Principle. Which is why I wonder whether calling it the “short and simple” principle may have saved us a lot of time debating what exactly constitutes a single “responsibility”.

Short and Simple

So I propose the “short and simple principle” which states that methods should not have more than 20 lines of code, and classes should not have more than 20 methods. Of course, the number 20 is plucked out of the air, but I think its roughly the right order of magnitude. If your method has 30 lines, there’s almost certainly some sub-block that could be extracted into a well-named function. And if your class has 30 methods, it is almost certain that a subset of them can be moved out into some kind of helper class.

Classes that adhere to the “short and simple principle” are easy to code review, and should be straightforward to test. They also have the great benefit that they are small enough to be completely thrown away and re-written in an afternoon if necessary.

Of course, the problem your software solves could be very large and complicated. But complex software can and should be constructed out of simple parts.

Postscript: After writing this I recently stumbled across this great article from Marco Cecconi about why he doesn’t love the Single Responsibility Principle, in which he offers further criticisms of SRP and suggests another alternative.

The Challenges of Maintaining Successful Software Projects

Have you ever found yourself wishing that the software project you’re working on would hurry up and die? The trouble with successful software projects is that you have to keep maintaining the same codebase year after year, as it grows larger and larger. Rather than getting a chance to start afresh like you do with greenfield development, you’re forced to live with the architectural mistakes of the past, and work with legacy technologies. And that’s just two of the problems that developers working on successful software projects can run into.

Of course it is possible to evolve your codebase over time to fix the architectural inadequacies, and migrate to newer technologies. But it’s not easy, and it’s easy to become disheartened in the battle against mounting technical debt. My own experiences in this area led to me creating my “Understanding and Eliminating Technical Debt” Pluralsight course, in which I explain some of the strategies and techniques I’ve found most helpful as I’ve worked to keep some very large and successful software products as maintainable as possible.

How to Resample Audio with NAudio

Every now and then you’ll find you need to resample audio with NAudio. For example, to mix files together of different sample rates, you need to get them all to a common sample rate first. Or if you’re playing audio through an API like WASAPI, which doesn’t resample for you, you need to do this yourself (actually WasapiOut in NAudio does include a resampling step on your behalf if needed).

There are also some gotchas you need to be aware of when resampling. In particular there is the danger of “aliasing”. I explain what this is in my Pluralsight “Digital Audio Fundamentals” course. The main takeaway is that if you lower the sample rate, you really ought to use a low pass filter first, to get rid of high frequencies that cannot correctly.

Option 1: Media Foundation Resampler

Probably the most powerful resampler available with NAudio is the MediaFoundationResampler. This is not available for XP users, but desktop versions of Windows from Vista onwards include it. If you are using a Windows Server, you’ll need to make sure the desktop experience is installed. It has a customisable quality level (60 is the highest quality, down to 1 which is linear interpolation). I’ve found it’s fast enough to run on top quality. It also is quite flexible and is often able to change to a different channel count or bit depth at the same time.

Here;s a code sample that resamples an MP3 file (usually 44.1kHz) down to 16kHz. The MediaFoundationResampler takes an IWaveProvider as input, and a desired output format:

int outRate = 16000;
var inFile = @"test.mp3";
var outFile = @"test resampled MF.wav";
using (var reader = new Mp3FileReader(inFile))
{
    var outFormat = new WaveFormat(outRate,    reader.WaveFormat.Channels);
    using (var resampler = new MediaFoundationResampler(reader, outFormat))
    {
        // resampler.ResamplerQuality = 60;
        WaveFileWriter.CreateWaveFile(outFile, resampler);
    }
}

Option 2: Wdl Resampling Sample Provider

The second option is even newer, and was added as part of NAudio 1.7.1. It’s based on the Cockos WDL resampler for which we were kindly granted permission to use as part of NAudio. It works with floating point samples, so you’ll need an ISampleProvider to pass in. Here we use AudioFileReader to get to floating point and then make a resampled 16 bit WAV file:

int outRate = 16000;
var inFile = @"test.mp3";
var outFile = @"test resampled WDL.wav";
using (var reader = new AudioFileReader(inFile))
{
    var resampler = new WdlResamplingSampleProvider(reader, outRate);
    WaveFileWriter.CreateWaveFile16(outFile, resampler);
}

The big advantage that the WDL resampler brings to the table is that it is fully managed. This means it can be used within Windows Store apps (as I’m still finding it very difficult to work out how to create the MediaFoundationResampler in a way that passes WACK).

Option 3: ACM Resampler

You can also use WaveFormatConversionStream which is an ACM based Resampler, which has been in NAudio since the beginning and works back to Windows XP. It resamples 16 bit only and you can’t change the channel count at the same time. It predates IWaveProvider so you need to pass in a WaveStream based. Here’s it being used to resample an MP3 file:

int outRate = 16000;
var inFile = @"test.mp3";
var outFile = @"test resampled ACM.wav";
using (var reader = new Mp3FileReader(inFile))
{
    var outFormat = new WaveFormat(outRate,    reader.WaveFormat.Channels);
    using (var resampler = new WaveFormatConversionStream(outFormat, reader))
    {
        WaveFileWriter.CreateWaveFile(outFile, resampler);
    }
}

Option 4: Do it yourself

Of course the fact that NAudio lets you have raw access to the samples means you are able to write your own resampling algorithm, which could be Linear Interpolation or something more complex. I’d recommend against doing this unless you really understand audio DSP. If you want to see some spectograms showing what happens when you write your own naive resampling algorithm, have a look at this article I wrote on CodeProject. Basically, you’re likely to end up with significant aliasing if you don’t also write a low pass filter. Given NAudio now has the WDL resampler, that should probably be used for all cases where you need a fully managed resampler.

If you’re a Pluralsight subscriber, you can watch me doing some resampling in Module 4 of my “Audio Programming with NAudio” course

A Few Thoughts on TDD and Why we Don’t Always Use it

I’m sure many of you have been following the recent TDD blogosphere altercation with interest. Just in case you you haven’t, here’s a quick catchup:

• TDD is dead. Long Live Testing (David Heinemeier Hansson)
• Monogamous TDD (Uncle Bob)
• TDD is dead? Let’s Kill the Messenger Instead (Gil Zilberfeld)
• When TDD doesn’t work (Uncle Bob)
• Professionalism and TDD in the Future (Rob Ashton)
• The TDD Divide: Everyone is Right (Cory House)
• Test Induced Design Damage? (Uncle Bob)
• Profesionalism and TDD (Reprise) (Uncle Bob)
• TDD When You Can’t Refactor (Paul Hammant)

Read all that? Good. As you can see there are some strong opinions strongly held on this subject.

My own thoughts on the subject are quite simple. TDD is a fantastic idea that turns out to be quite difficult to implement, especially at first. There are several reasons for this.

Slow Progress

The most obvious is that adopting TDD slows you down initially. This is true of any new way of working. If you decide you’re going to stop using the mouse for a day and only use keyboard shortcuts, it’s going to be a frustrating experience and in all likelihood you’ll be tempted to give up within minutes of starting. But if you can push through that pain barrier and accept the initial slow-down, you’ll reap the benefits later.

But there are two other reasons we have for not using TDD that I want to highlight in this post. They are:

• “This code is too simple to bother using TDD”
• “This code is too complicated to use TDD”

Too Simple for TDD

Often early on in the lifetime of a piece of software, you already have in your head a large portion of the design and architecture. And if you’re an experienced developer, you probably have a very good instinct for what that design looks like. You just want to turn it into code as quickly as possible. TDD seems redundant during this rapid prototyping phase, so you skip it.

The trouble is, now when you start evolving that initial design further, a unit test suite would be really useful. But you haven’t got one, and retrofitting unit tests to existing code is slow and painful. So this is the reason why I think a lot of developers who have embraced TDD in theory, end up not actually using it in practice. We lack the self-discipline to start the way we mean to go on.

Too Complicated for TDD

But let’s look at the other side of the equation. Sometimes we really want to use TDD, but are thwarted because it just seems too difficult to do.

I’m glad Uncle Bob admitted in one of his many posts on TDD that it doesn’t fit all types of development. There are many types of coding where TDD isn’t a natural fit, and I have several examples from a series I wrote a while back:

• Test Resistant Code #1 – External Dependencies
• Test Resistant Code #2 – Markup is Code Too
• Test Resistant Code #3 – Algorithms
• Test Resistant Code #4 – Third Party Frameworks
• Test Resistant Code #5 – Threading

What do we do about code like this? Uncle Bob freely admits that much of this type of code requires “fiddling” and is outside the domain of unit tests. And I agree with him. All we need to do is ensure that the business logic isn’t intertwined with this untestable code, in order that it can be written test driven.

Now I don’t know if I’m a special case, but many applications I write are almost exclusively made up of test-resistant code. For example, I write a lot of audio applications, which play or record sounds and display custom waveform visualisations. The amount of code that I can meaningfully unit test is sometimes less than 5% of the total code in the application.

This means that for me to write these applications “professionally”, as a responsible software craftsman, TDD is at best only a small part of the answer. So while I’m happy to keep enthusiastically promoting TDD (and trying to be better disciplined to use it more consistently), I don’t think it’s the final word on writing quality code. I think there’s still plenty of scope for new practices to be discovered and frameworks to be created that help us test those parts of our code which ordinary unit tests just can’t reach.

I have some thoughts on what those might look like, but that’s for another blog post.

Understanding and Eliminating Technical Debt

I'm pleased to announce that my fourth Pluralsight course has just been released, on the subject of "Understanding and Eliminating Technical Debt". If you've been following this blog for any length of time you'll know that Technical Debt is a topic I care deeply about. In fact, in many ways, it has become one of the main focuses of my career as I am technical lead for the ongoing development of a very large and successful software project that has over one million lines of code. In fact, it is typically successful software projects that have the biggest issues with technical debt, because as a general rule, technical debt is proportional to the amount of code you have.

In the course I attempt to give a big picture overview of what problems technical debt can cause, how you can identify it, and how you can go about repaying some of it. I take quite a broad definition of technical debt, encompassing any decisions we make (whether intentionally or not) about the way we write our code that slow down future development. I know this isn't how Ward Cunningham originally used the term, but it seems that the industry has taken his metaphor and applied it more broadly. (For example, see Martin Fowler's "Technical Debt Quadrant").

In the course I ended making up some of my own terms to help me express the breadth of issues that could fall under the category of "technical debt". These were:

• "code debt" - issues with the way we write our code (such as failure to write clean code) are slowing us down
• "architectural debt" - shortcomings in the architecture of our software that make it hard to extend in the direction we need to
• "test debt" - slows us down because we can't quickly verify everything is working correctly
• "knowledge debt" - where developers don't fully understand the system they are working on
• "technological debt" - where we've got stuck on a legacy technology and the cost of migrating away is too great

In the course I don't assume you're using agile process, or TDD, or indeed up to date technologies or best architectural patterns. And that's because the simple fact is that there are lots of software projects out there that are being actively maintained, but that have not been built using what are now considered to be "best practices" for process, architecture or coding techniques.

One of the biggest challenges creating this course for me is that every company is different. When I talk about technical debt where I work it's easy for me to make it very relevant because I know what the specific issues we are facing as a team. But on Pluralsight, I'm speaking to a worldwide audience of developers working on all kinds of systems. I've done my best to keep the content as broadly applicable as possible. But please do give me feedback, and tell me about the technical debt issues you're facing, and what you've done to deal with them.