I Really Don’t Know

Coghead closes for business

With the announcement that Coghead, a really very smart app development platform, is closing its doors it’s worth thinking about how you can protect yourself from the inevitable disappearance of a service.

Of course, there are all the obvious business type due diligence activities like ensuring that the company has sufficient funds, understanding how
your subscription covers the cost (or doesn’t) of what you’re using and so on, but all these can do is make you feel more comfortable – they can’t provide real protection. To be protected you need 4 key things – if you have these 4 things you can, if necessary, move to hosting it yourself.

1. URLs within your own domain.

Both you and your customers will bookmark parts of the app, email links, embed links in documents, build excel spreadsheets that download the data and so on and so on. You need to control the DNS for the host that is running your tenancy in the SaaS service. Without this you have no way to redirect your customers if you need to run the software somewhere else.

This is, really, the most important thing. You can re-create the data and the content, you can even re-write the application if you have to, but if you lose all the links then you will simple disappear.

2. Regular exports of your data.

You may not get much notice of changes in a SaaS service. When you find they are having outages, going bust or simply disappear is not the time to work out how to get your data back out. Automate a regular export of your data so you know you can’t lose too much. Coghead allowed for that and are giving people time to get their data out.

3. Regular exports of your application.

Having invested a lot in working out the write processes, rules and flows to make best use of your app you want to be able to export that too. This needs to be exportable in a form that can be re-imported somewhere else. Coghead hasn’t allowed for this, meaning that Coghead customers will have to re-write their apps based on a human reading of the Coghead definitions. Which brings me on to my next point…

4. The code.

You want to be able to take the exact same code that was running SaaS and install it on your own servers, install the exported code and data and update your DNS. Without the code you simply can’t do that. Making the code open-source may be a problem as others could establish equivalent services very quickly, but the software industry has had ways to deal with this problem through escrow and licensing for several decades. The code in escrow would be my absolute minimum.

SaaS and PaaS (Platform as a Service) providers promote a business model based on economies of scale, lower cost of ownership, improved availability, support and community. These things are all true even if they meet the four needs above – but the priorities for these needs are with the customer, not with the provider. That’s because meeting these four needs makes the development of a SaaS product harder and it also makes it harder for any individual customer to get setup. We certainly don’t meet all four with our SaaS and PaaS offerings at work yet, but I am confident that we’ll get there – and we’re not closing our doors any time soon ;-)

Ruby Mock Web Server

I spent the afternoon today working with Sarndeep, our very smart automated test guy. He’s been working on extending what we can do with rspec to cover testing of some more interesting things.

Last week he and Elliot put together a great set of tests using MailTrap to confirm that we’re sending the right mails to the right addresses under the right conditions. Nice tests to have for a web app that generates email in a few cases.

This afternoon we were working on a mock web server. We use a lot of RESTful services in what we’re doing and being able to test our app for its handling of error conditions is important. We’ve had a static web server set up for a while, this has particular requests and responses configured in it, but we’ve not really liked it because the responses are all separate from the tests and the server is another apache vhost that has to be setup when you first checkout the app.

So, we’d decided a while ago that we wanted to put in a little Ruby based web server that we could control from within the rspec tests and that’s what we built a first cut of this afternoon.

require File.expand_path(File.dirname(__FILE__) + "/../Helper")
require 'rubygems'
require 'rack'
require 'thin'
class MockServer
  def initialize()
    @expectations = []
  end
  def register(env, response)
    @expectations << [env, response]
  end
  def clear()
    @expectations = []
  end
  def call(env)
    #puts "starting call\n"
    @expectations.each_with_index do |expectation,index|
      expectationEnv = expectation[0]
      response = expectation[1]
      matched = false
      #puts "index #{index} is #{expectationEnv} contains #{response}\n\n"
      expectationEnv.each do |envKey, value|
        puts "trying to match #{envKey}, #{value}\n"
        matched = true
        if value != env[envKey]
          matched = false
          break
        end
      end
      if matched
        @expectations.delete_at(index)
        return response
      end
    end
    #puts "ending call\n"
  end
end
mockServer = MockServer.new()
mockServer.register( { 'REQUEST_METHOD' => 'GET' }, [ 200, { 'Content-Type' => 'text/plain', 'Content-Length' => '11' }, [ 'Hello World' ]])
mockServer.register( { 'REQUEST_METHOD' => 'GET' }, [ 200, { 'Content-Type' => 'text/plain', 'Content-Length' => '11' }, [ 'Hello Again' ]])
Rack::Handler::Thin.run(mockServer, :Port => 4000)

The MockServer implements the Rack interface so it can work within the Thin web server from inside the rspec tests. The expectations are registered with the MockServer and the first parameter is simply a hashtable in the same format as the Rack Environment. You only specify the entries that you care about, any that you don’t specify are not compared with the request. Expectations don’t have to occur in order (expect where the environment you give is ambiguous, in which case they match first in first matched).

As a first venture into writing more in Ruby than an rspec test I have to say I found it pretty sweet – There was only one issue with getting at array indices that tripped me up, but Ross helped me out with that and it was pretty quickly sorted.

Plans for this include putting in a verify() and making it thread safe so that multiple requests can come in parallel. Any other suggestions (including improvements on my non-idiomatic code) very gratefully received.

David Merrill demos Siftables, the smart blocks | Video on TED.com

David Merrill demos Siftables, the smart blocks | Video on TED.com.

Siftables are really interesting, very similar to Reactables which I blogged about while talking about more multi-touch UI last year.

Siftables are generic blocks, each has a wireless connection to a nearby computer, a proximity sensor so it can identify other siftables nearby and a small screen. The manipulation of the blocks at this stage seems a little bit slow, but the work shown with kids gives a really clear indication of the advantages of this kind of tactile interface.

I want some.

Join the Internet Blackout – Protest Against Guilt Upon Accusation Laws in NZ — Creative Freedom Foundation (creativefreedom.org.nz)

Update: The NZ government have suspended the introduction of Section 92a (via MiramarMike)

An interesting campaign to ‘blackout’ your online presence to campaign for change to one of NZ’s clauses started today. Protest Against Guilt Upon Accusation Laws in NZ — Creative Freedom Foundation (creativefreedom.org.nz). I spotted this a few days ago thanks to Mike Brown who tweeted about it.

What’s interesting about the law is that it changes the presumption of guilt quite significantly. Currently in most Copyright jurisdictions if someone is infringing your copyright then the first thing you’d do (after asking them politely to stop) is take out an injunction against them. This involves persuading the court that you have enough of a case that the (alleged) infringer should be told to stop until the case is heard. The bar for getting an injunction is, then, quite high.

What Section 92 of the Copyright Amendment Act does is compels ISPs (and there is a broad definition of that term in the law) to take down sites or revoke internet access when an accusation of infringement is made. The clause looks like this:

Internet service provider liability

92A Internet service provider must have policy for terminating accounts of repeat infringers

• (1) An Internet service provider must adopt and reasonably implement a policy that provides for termination, in appropriate circumstances, of the account with that Internet service provider of a repeat infringer.
• (2) In subsection (1), repeat infringer means a person who repeatedly infringes the copyright in a work by using 1 or more of the Internet services of the Internet service provider to do a restricted act without the consent of the copyright owner.

The potential downsides of a law like this are many, but one of the biggest is the impact it is likely to have on fair-use. Fair use is not explicitly defined and is clarified by case law, though some common examples are often postulated – parody, criticism, illustration are often quoted. There are also tests around the commercial impact of the use.

What this means is that Copyright is not absolute, it’s a negotiation between creators and the state to strike a balance that is most effective for the country’s cultural and economic prosperity. This clause changes that for internet based uses by preventing that negotiation and also by makes people more fearful by increasing the immediate penalty for an accusation of infringement from very little to the loss of internet service. That could be enough to close many small businesses.

The reasoning behind the bill is one of practicality. Those with large catalogs of Copyright works, such as the music labels, are having a really tough time preventing copying on the internet (because teh internet is one big copying machine). The reason is that the current laws make pursuing people difficult and expensive as the RIAA have found out in the states. The solution in Section 92, though, may be a little heavy handed. ISPs are likely to comply with the law, and the cheapest thing for them to do is simply take down anything they’re asked to. ISPs are a commodity, they don’t have big profit margins to use up helping you keep your content up online.

Labour MP Judith Tizard is quoted as saying

It is easier for ISPs, Internet Service Providers, to cut off anyone who might be breaking the law.

Now, this seems to be a more and more common perception. That it would be too much trouble to ask a copyright holder to file suit and that ISPs look perfectly placed to handle issues. What that misses though is that ISPs are not at all equipped to perform any kind of arbitration, so with an individual customer on one side and a large, wealthy corporate lawyer on the other the ISP will always play it safe.

If this were happening in the US then I wouldn’t even have blogged about it, but it seems odd to me that this is happening at almost exactly the same time, and in the same city, as Webstock, one of the best web conferences in the world.

Linked Data on the Web (LDOW2009) – Workshop at WWW2009, Madrid, Spain

I’ve been asked to be on the programme committee for LDOW2009. It looks set to another great workshop and the three papers I’ve been assigned to review all look brilliantly interesting. Unfortunately not allowed to blog about them :-(

dev8D | Lightning talk: Agile Development

This is a great post on agile development coming out from the JISC Dev8d days.

Example from the floor, Matthew: what worked well in a commercial company I was working for where we practiced extreme coding and used agile principles was: no code ownership (bound by strict rules), test-based development, rules about simplicity, never refactoring until you have to, stand up meetings, whiteboard designs, iterations so could find out when you’d messed something up almost immediately, everything had to have unit tests, there has to be a lot of trust in the system (you have to know that someone is not going to break your code)

Graham: building trust is central.

via dev8D | Lightning talk: Agile Development.

The quote above from Matthew and Graham mirrors exactly my experience – when we do those things well, and are disciplined about it and trust each other the things work out well. When we do less of those things then things turn out less well.

Graham is Graham Klyne who I’ve met a few times at various meets like Vocamp 2008 in Oxford. He and his team are doing clever things with pictures of flies and semweb technologies.