Bootstrap a Startup in a Week–Days 2 and 3: A Walking Skeleton

Rob Ashton and I are engaged in a challenge to build a minimal viable product for my start-up TruthVine in a week. We kicked off on Monday. This is how Tuesday and Wednesday panned out.

I’m surfacing briefly from the code-face this morning to announce that our efforts have met in the middle. My desktop sermon-recording client is now encoding and uploading sermons to Rob’s web application.

Having spent Monday working on the Administrator user interface, where churches will upload and manage sermons, Rob turned his attention on Tuesday and Wednesday to the public facing website which will supply the smarts to allow churches to easily embed a rich sermon browsing experience in their existing websites.

Single Page Application without client side templating

The brief I set Rob had three parts:

1. A church must be able to add the sermon display to their website just by pasting a snippet of html/javascript code onto a page of their website
2. Individual areas of the sermon browsing experience should have unique urls to make them easy to share
3. If possible, the whole thing should be SEO friendly

We can now tick off points 1 and 2, and we’re running some experiments with Google to see if we have accomplished 3.

Rob has come up with an elegant solution whereby our small snippet of code loads a small truthvine.js file which brings the whole experience to the page. The javascript inspects the url of the page where it is embedded, and reads the part after the hash bang (ie ‘#!’). It interprets that as a url and requests it from the TruthVine server, which returns a JSONP result containing some html. For example, in the url http://mychurch.com/sermons/#!/sermons/view/33, the part after the hash bang is /sermons/view/33 , and that url is requested from the server. The javascript on the page appends the html fragment from the JSONP request to a <div/> which is part of the snippet.

The best part of this is that there’s no client side templating involved. We can render everything using Razor views on the server side, including all the links between different parts of the experience.

Immutable collections and audio editing

Meanwhile, on my side of the tunnel, work on the desktop recording client has been going forward steadily. It can now play back the audio that it has recorded, and encode it to AAC format. More importantly, it can post sermons to the website.

I spent a large part of yesterday laying the groundwork for being able to trim a recording. This has been very interesting work, not least because I’ve been able to try out the new Immutable collections that the BCL team have created.

The approach I’m taking is to write all the raw audio samples to a memory-mapped file which I’m treating as append-only. I then keep a list of segments – pointers to the start and end of sections in the original recording which will be included in the output. The idea is that it is this list of segments which will change during the editing process rather than manipulating the raw audio. By using immutable data structures it becomes much easier to do work on different threads. It should also make it almost trivial to implement undo-redo, because undoing an operation just requires us to reinstate the previous version of the segments list. Remind me to share the code with you sometime!

Deployment

Yesterday evening we deployed our code to the web for the first time – “the moment of truthvine”, as Rob called it. I was impressed by how painless deployments are using Microsoft’s Web Deploy. Having installed Web Deploy on the server, you can simply create a new website in IIS, then choose the “Deploy –> Configure Web Deploy Publishing…” from the context menu. This creates a publishing profile that you then import into Visual Studio. Then every time you have fresh bits for the server you just select “Build –> Publish Selection” in Visual Studio and – hey presto! – there it is for all the world to see.

There was one point in the deployment where I thought I was going mad. Having successfully deployed the admin website, I tried deploying the public facing website, only to discover IIS wouldn’t serve .js files from the root of the application – it was returning Http 404 errors instead. I checked folder permissions, checked that the Static Content module was installed – nothing doing. I was saved by the old trick: I deleted the site and started again, and everything was fine!

With our skeleton now on his feet, we have two days left on the clock to put some flesh on his bones and make sure he doesn’t wobble over. Stay tuned!