A Logo for TruthVine

I’m delighted to announce that TruthVine now has a logo:

We also have an icon form that we can use in social media handles (our twitter account, for example), and for application icons:

Graphic design work was done by the talented Chris Hesketh, who is now beavering away to make our landing page look presentable.

A crash course on the importance of cross-browser testing

Having trumpeted the successful launch of my startup’s minimal-viable-product on our first customers website yesterday, I went to bed feeling pretty satisfied with the week’s work.

I woke up this morning to find a tweet and a comment on my blog alerting me to an issue with the site. Dave kindly tweeted to say he was getting Http 404 errors when clicking links to view sermons. I checked the site again, and it “worked for me”^TM so I concluded it was just a one off issue, and hoped it would go away. Then Mark commented that he was getting problems when viewing the site in Firefox. Ah!

Rob and I developed the site using Google Chrome. I also tested it on Safari on my iPad. Both worked fine, so I optimistically assumed it worked everywhere.

Prompted by Mark’s comment I downloaded Firefox, and tried the site for myself. Instead of this:

I saw this:

I quickly diagnosed the problem: Firefox wasn't loading the css file that styles the content our script injects into the site. Our script was loading the style sheet dynamically by injecting a <link/> element into the page immediately before our content. This was working fine in Chrome and Safari – both Webkit based browsers. In Firefox, and IE, that technique didn’t work. It seems that IE requires style sheets to be added using the createStyleSheet method, and Firefox is picky, and requires the stylesheets be injected into the <head/> element. Fortunately, a google search turned up a StackOverflow post giving a cross-browser technique for injecting style sheets.

That was the first problem solved. The bigger problem was the links not working. In Firefox, clicking the links showed 404 errors in the page. In IE, they just didn’t work at all.

The cause of this problem lay in the code that takes the html returned by our server and injects it into our customers page. That code has to rewrite all links to make them use hash bangs, so that we can intercept the clicks and post back to our server rather than the customers. In the process of rewriting we were using the document.location.origin property. Turns out, that’s only supported by Webkit browsers. Once again, StackOverflow had the solution.

The problems should all hopefully now be fixed, and welcomehallchurch.org/sermons powered by TruthVine should be working across all three major browsers.

Next time I’ll remember to test on all three browsers first before launching!

Build a Startup in a Week–Mission Accomplished!

This week Rob Ashton and I have been battling against the clock to get a minimum viable product for my startup TruthVine out of the IDE and into the hands of customers in five days.

At 3:42 PM this afternoon, we declared victory:

Mission accomplished! @robashton and I have built our TruthVine MVP in 1 week, and it's now live on welcomehallchurch.org/Sermons

— Samuel Jack (@samuel_d_jack) March 8, 2013

There were some course adjustments along the way, as you would expect in a project like this. By the end of yesterday, I concluded that I wasn’t going to get my streamlined audio recording tool completed, so to make sure we had something to ship by the end of the week, I decided to put that on hold.

Today we focused all our efforts on getting the TruthVine Admin website and the embedding experience ready for use. And I believe we succeeded. Rob wrote a migration tool to take all the existing sermon data from my own church website (which I manage) and put it into the new TruthVine database. Having deployed the final builds of the software to our EC2 server, I then replaced the sermon display code in the website with TruthVine’s magic script. Two minutes later it was live. You can visit welcomehallchurch.org/sermons to see for yourself. Of course, there’s still a lot left to be done, styling being the most obvious thing – but that’s the point of a minimal viable product. It’s now out there in the wild, and I can start gathering feedback to determine where to focus my efforts next.

This week has been great fun, though hard work. I’d like to thank Rob again for all outstanding efforts. He has given me a great head start. But now the real work begins: marketing TruthVine, and building it into a self-sustaining business.

Oh – and by the way - if you know a church who might be interested in trying this out, send them to me, and I’ll hook them up with a free trial.

Why I chose RavenDb for my startup

In my post the other day about my choices of technological underpinnings for my startup, TruthVine, there was one choice I omitted to mention. I didn’t say which database I had decided upon.

In fact it was a decision which took no consideration at all: having worked with RavenDb on the inside and from the outside, it was my immediate choice. Here’s why.

RavenDb stays out of the way

RavenDb is like a waiter at the best kind of restaurant. It serves your data with the minimum of fuss and gets out of the way. Unlike certain persistence technologies I could mention, there is barely any configuration involved, and not a mapping in sight. You just hand RavenDb an object or any shape or size, and RavenDb stores it. You murmur an object’s id, and RavenDb has it on your plate in an instant, child collections and all.

RavenDb is a document database. That means that you don’t need to declare a schema upfront. Whenever you hand RavenDb an object it simply serializes it to JSON format, and stores it as a blob in its persistence engine. The benefit I see from this is greatly reduced pain when deploying updates to my code, as I won’t need to worry about sql migration scripts. I can add things to my objects with impunity, and for other situations, RavenDb has very nice document patching support.

As as you’d expect, given RavenDb’s provenance, the RavenDb .Net client is awesome. It has full support for the unit-of-work pattern and transactions. Thus any entities you load within a session are tracked, and any that have changed when you save the session are sent to the database in a single transaction. Naturally, the RavenDb client has LINQ support too, with paging in queries being especially trivial to implement.

Here’s a complete snippet showing everything you need to store and retrieve objects from RavenDb.

class RavenDbDemo
{
    public void Demonstrate()
    {
        // DocumentStore is a heavy-weight object usually created once per application
        var documentStore = new DocumentStore() {Url = "http://myravendbserver.com"};
        documentStore.Initialize();

        // session objects are light-weight and are created per transaction
        using (var session = documentStore.OpenSession())
        {
            var person = new Person()
                {
                    Name = "Samuel Jack",
                    FavouriteDatabase = "Sql Server"
                };

            session.Store(person);
            session.SaveChanges();
        }

        using (var session = documentStore.OpenSession())
        {
            var person = session.Query<Person>()
                .First(p => p.Name == "Samuel Jack");

            person.FavouriteDatabase = "RavenDb";

            session.SaveChanges();
        }
    }

    public class Person
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public string FavouriteDatabase { get; set; }
    }
}

Indexing is largely automatic

One thing this snippet highlights is RavenDb’s awesome indexing support. Whenever you make a new kind of query, RavenDb will automatically create an index for you to query against. In the most recent versions of RavenDb, it will automatically tune the indexes over time, depending on the patterns of queries you make against the database. Of course, you can define more sophisticated indexes explicitly, but often you never need to.

One situation where you will need to create indexes is when you want to take advantage of RavenDb’s Map/Reduce support. This is how RavenDb supports queries which involve aggregating multiple documents, since it doesn’t implement grouping clauses in LINQ queries from the client. The nice thing about the way it does this is that Map/Reduce indexes are persisted just like other indexes, which makes aggregate queries very fast.

And There’s More

There is so much more to like about RavenDb, but I’ll just highlight a few other things which I think will be important to me as a startup.

The first is RavenDb’s replication support. This is important if you want to make sure your application has high availability. Configuring replication is as easy as entering the connection string for the database you want RavenDb to replicate too. Replication also helps enormously with scalability, as you can configure your clients to read from any of the replicas, thus spreading the load, but write to the master database, thus ensuring consistency without generating conflicts.

Next is backup support. RavenDb comes with built in support for doing backups to Amazon S3, or Amazon Glacier. You just have to tell it the bucket you want to write to, and your API keys, and off it goes.

The level of support available is always an important consideration when choosing to adopt a product, and RavenDb has great support, both from the RavenDb community who hang out on the RavenDb group, and from Ayende and the rest of the Hibernating Rhinos team. RavenDb is an open source project (using the AGPL license, so you must buy a license if you’re not willing to open-source your own code) and the community are very active in contributing to the project.

I should mention that, if RavenDb has one failing, the documentation is not as good as it might be. The situation has improved a lot recently, and I understand a couple of books are in progress. Most of the time RavenDb just works, but if you stray too far from the beaten path, you might find yourself relying on the community to help you understand what’s going on. Having the code available certainly helps, and, as I said, the community are very responsive.

Finally, I can’t resist a plug for the Management UI (in which, if you press me, I might admit to having played a part!).

I love the fact that you scan scroll through your entire documents collection, or through all the results of a query, with the client paging in the data as necessary.

Full disclosure: Whilst these opinions are entirely my own, and I do not believe them to be prejudiced by any other factors, I have been offered a RavenDb license by Hibernating Rhinos in exchange for setting them out in this blog post. I am also a freelance contributor to the RavenDb project.

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!

Bootstrap a Startup in a Week: Day 1

Hurricane Rob (aka Rob Ashton) is the mildest-mannered whirlwind one could ever hope to meet, and he passed through my office today leaving in his wake a wonderful trail of construction. It was Day 1 of my “Build a Startup in a Week” challenge, and Rob arrived at my house (we’re working from my garden office) bright and early, eager to re-caffinate. Whilst he patched up his scarcely-used Windows laptop with Asp.Net MVC 4 (am I the only Windows developer still actually using a PC and not a Macbook Air?) we talked tactics.

There are three major components for my sermon sharing service that I want to get built this week. One is the administration website, where churches will upload and manage sermons. Second is the public-facing website which will embed sermon listings in churches websites. And third is “The Studio” – a super-easy-to-use desktop application for recording, editing and uploading sermons.

Since Rob’s strength lies in web development and my expertise is centred on desktop applications, a natural division of labour emerged. So whilst Rob got started on the web stuff, I cracked open Visual Studio and created a fresh WPF project.

Some of the ground work for our weeks work, I laid last week.

Ground Work

After much toing and froing I’ve settled on Amazon to host the services, and in particular, Amazon EC2 for the servers. I considered AppHarbour, and Azure Websites, with their promises of painless deployments, but in the end I decided I’d trade off a little extra work on deployment in return for complete control of the stack.

Wherever you turn, Amazon seem to have you covered. The TruthVine landing page is currently hosted as a static website on Amazon S3, and we’ll be using S3 for sermon storage too. The truthvine.com domain is pointed at Amazon’s Route 53 DNS service. We’ll be using SES for sending notification emails. If only Amazon Flexible Payments service worked in the UK, I’d be use that in a shot.

For hosting our source code and managing issues, I’ve settled on BitBucket, with a Git repo. Whilst I prefer Mercurial from an ease-of-use perspective, and would have loved to use Fogcreek’s Kiln, it seems Git has become the lingua franca for DVCS, particularly after Microsoft announced they were adopting it for TFS. Why BitBucket rather than GitHub? Because I think their pricing model makes more sense. GitHub charges per repository, whereas BitBucket charge per user. I can see our repository count growing over time, whereas the number of developers I’m likely to involve in my projects is going to remain small.

The last thing to get sorted before Rob’s arrival was a UI theme for Admin pages. We’re going to be using Twitter Bootstrap to make the UI a little easier to develop. I found a wonderful site called WrapBootstrap which sells themes built on Twitter Bootstrap, all for very reasonable prices. From that, I’ve picked the Optimus Dashboard theme, which not only looks the part, but is responsive, so it resizes to accommodate tablets and smartphones.

Progress Report

So how did we get on today?

Rob made a sterling effort. Starting with some code I’d written for our church website (which he seemed to like) he got a good chunk of the admin website done today – login, sermon management, and series management.

My efforts were a bit more lacklustre. They amounted to this:

I did make a few useful discoveries though. A while back, I found the NAudio library, which does a lot of the grunt work when working with Audio in .Net. Today I discovered that they’ve added code to handle AAC encoding using the encoder built into Windows as of Windows 7. I was thinking I’d need to spend a day or translating C++ samples into C# interop to get that working.

All in all, a profitable day. Hopefully a sign of a good week to come.

Introducing TruthVine

This Monday morning, the metaphorical starting gun will fire, and Rob and I will be off on our one-week startup challenge. We aim to have a minimum viable product up and hosting at least one customer in 5 days. So what is it we’re building?

Allow me to introduce TruthVine – “the easiest way to share sermons online”. The theory I’m testing with the launch of this product is that there are many churches who would love to put their sermons online, but simply don’t know where to start. There are already sites like SermonAudio.com or SermonCloud.com, but my research suggests that there is room in the market for a service which makes the whole process so simple that no IT know-how is required.

With TruthVine I aim to streamline the whole process of recording, publishing, and engaging with sermons. Engagement is a major part of my vision for the future. As a wise man once said, “a sermon is not over until it is lived”, and God-willing, I want to build TruthVine into a tool which helps Christians keep the preached Word of God at the front of their minds so they can live it.

That’s the lofty goal. But every journey begins with a first step, and on Monday we take ours.

Check out the landing page, sign up for the newsletter, and follow along with our hackathon next week.