Cooper Systems Delving into systems, security and society. Thu, 04 Apr 2013 06:37:38 +0000 en-US hourly 1 Scala Play 2.0 web services on Heroku Thu, 04 Apr 2013 06:32:28 +0000 Read more »

I noticed two issues with Scala Play web services on Heroku.

Firstly, for some reason my initial implementation worked when running Play locally, but did not work in production on the Heroku server. The approach was using as an input stream and blocking while the content was downloaded. So, don’t do that (the approach that worked is detailed below).

Secondly Heroku uses a reverse proxy between the user and the web server, so getting the user IP isn’t going to work as it will be the IP of the proxy instead. So what you need to do is look for the “X-Forwarded-For” attribute that the proxy adds to the header information for you.

Here’s what worked for me:

def index = Action { implicit request =>

   val ipAddress = request.headers.get("X-Forwarded-For") match {
      case Some(ip: String) => ip
      case None => request.remoteAddress
   val ip = if( ipAddress.equals(""))
      "" // insert your IP here for development mode testing
      else ipAddress

   val promise: Future[] = WS.url(""+ip).get()
   Async {
      promise map { res =>
         val locationJSON:JsValue = Json.parse(res.ahcResponse.getResponseBody())
         val lat = ( locationJSON \ "latitude" ).asOpt[Double].getOrElse(0)
         val long = ( locationJSON \ "longitude" ).asOpt[Double].getOrElse(0)
         val city = ( locationJSON \ "city" ).asOpt[String].getOrElse("")
         println("City: "+city)

What is Systems Engineering – A simple explanation Wed, 16 Jan 2013 15:46:41 +0000 Read more »

If you look in the regular places, you’ll see that Systems Engineering is described, but the words are all Gartneresque. That’s all well and good for a wiki or report, but what does Systems Engineering actually mean?

Basically, it’s a process to reduce complexity.

First of all we define everything as a System. A computer can be a system, a factory can be a system, even people following processes can act as a system. In fact the details of what’s inside the system can even be largely ignored at the start of the process. A system has inputs and outputs, but at a high level, so long as the outputs are correct relative to the inputs, the insides of your black box system could be microchips, cogs, bacteria, or something else entirely. It really doesn’t matter.

To solve the problem, the first thing you do is describe the problem as a series of inputs and outputs, which form your requirements. Whether you’re transporting cargo, processing information, or trying to achieve some effect, your system will have requirements, which define the boundaries of that system. For example a space shuttle may need to deliver one ton of cargo to low earth orbit within 24 hours of launch. As you can see, the requirements don’t detail the solution, only the boundaries of the problem.

With your requirements in hand, you now have the boundaries of the system. You have a black box, and ‘something’ will go inside that box to solve all of your problems.

So how does this reduce complexity? The black box, ie the system can be reduced into smaller and smaller sub systems. At each reduction you are architecting the system and defining the boundaries between which the engineers of each sub system will work. For example, you might break a space shuttle down into a fuel subsystem, life support subsystem, navigation subsystem, etc. This makes a lot of sense, because the chemical and mechanical engineers designing the fuel subsystem, likely don’t care about and don’t know how to engineer the software navigation subsystem, or the medical life support subsystem, so they interface through the tightly defined boundaries created when breaking the system down into its subsystems. These boundaries make the problem workable and ensure the best person for the job is designing the exact details of each subsystem. This is a good thing because too much detail in an architecture can miss the mark through naivety, you really just want to design the boundaries and the effects achieved by the super system.

Systems Engineering then focusses on Verification and Validation, where each sub system is tested against the requirements, and the overall System is approved to undertake the mission.

Without the clearly defined boundaries, a complex System can quickly become something unwieldy. Using the space shuttle again as an example, what if the fuel line requirements were not clearly defined? It’s easy to imagine a scenario where engineers (who are often not in the same building or even country) get their wires crossed and the fuel is not delivered fast enough, or at the right temperature, or even the right fuel type for the engine. Would the shuttle take off? And if it did, will it achieve the mission, or or will it fall back to Earth? Even if the fault was discovered before the shuttle is launched, the costs of re-engineering can be astronomical (no pun intended). Particularly delays, where you may have to pay a bunch of staff to do nothing for weeks, re-engineering costs can quickly add up.

Another example is anything relating to Services Oriented Architecture or SOA. In SOA, every service can be regarded as a subsystem. It can be quite flexible, as software services can be reused with no additional work, and depending on how well the system is designed it can degrade gracefully if services become unavailable or have not yet been developed.

Having well defined boundaries and a series of tests to be performed on each subsystem, depending on which requirements the subsystem had allocated to it, allows the engineers on each subsystem to ignore the other side of the boundaries, which reduces the complexity of the problem to something manageable.


As you move through the process, the complexity of the links between every line of every artifact increases, as if absorbing the complexity of the system. It can be difficult to manage these traces, but worth it to maintain the context of the system. Without context the purpose of a sub task is often lost (“Why are we testing this nut against ISO1404 again? Why does this wire need to transfer 10Mbits? Can I get away with using a cheaper cable?”). But with the context of traceability you can not only see exactly why each task is important and which stakeholder is asking for it, you can be sure that every subsystem is tested and every requirement is met. Being able to trace back to stakeholders is also great, as anyone can identify the stakeholders originally responsible for every component of the system being built and tested, and ask them for feedback and clarification if necessary rather than simply being lost in some enormous process.


A common criticism of this process is that it all sounds very ‘waterfall’, something that has been replaced by the ‘agile’ software development life cycle. But three points should be made:

1. A lot of what people these days call agile is simply staged waterfall. You can still stage the requirements under this method. You can also stage the order the subsystems will be implemented, and even defer finalising or even deciding on whole parts of the design, because they’ve been neatly compartmentalised for you through Systems Engineering. You can use Systems Engineering to define the goals of the subsystems, then use the Agile method to develop any or all of them.

2. An Agile organisation is one that is not burdened by classical engineering like this. But really their flexibility does not come down to their technical people, these extremely agile startups are actually in search of a business model. And it goes without saying that you can’t architect a system to meet the user needs if you don’t know what the user needs are in the first place. Under these conditions you don’t use Systems Engineering, but the fact that the system under development needs to be constantly re-engineered is quite wasteful, a price you just have to pay for continually going back to the drawing board. For established businesses however, the project needs can usually be quite easily determined and documented, making the entire process much more efficient, which saves both time and money. Systems Engineering can be the difference between a project being feasible or not going ahead at all.

3. Sometimes the Systems Engineering process itself can be quite costly, depending a great deal on the tools being used and the level of mandatory processes and regulations in place at the organisation. The size of the system will determine whether the costs of using a rigid systems engineering process is proportional or not. For vehicles, infrastructure, any enterprise software, weapon systems, etc, it would be crazy not to, but for a very small component individually (maybe a resistor or a motor), the complexity of that job might not warrant the overhead of the full systems engineering process. Once again though it’s up to the tools and the organisation, Agile Systems Engineering is definitely possible

And at the end of the day if done right, eliminating all of that waste and having your systems delivered on time and to specification will ultimately save you a great deal of time, money and heart ache.


Implementing a tree hierarchy in GWT Tue, 28 Aug 2012 18:31:23 +0000 Read more »


A simple example of the Node hierarchy described in this post.

If you’re like me, you’re using GWT to push the boundaries of what is possible in an interactive web UI.

One of the data structures I’ve been working with recently that I didn’t see much documentation on is the tree hierarchy, as shown on the right.

Nodes within nodes, within nodes, within nodes, etc.

This method uses the GWT composite to give you full control of the widgets, provides data persistence and provides a simple way to integrate the gwt-dnd library.

We have two classes, one of which is abstract:

public abstract class Node extends Composite {
int nodeID = 0;
Node aboveNode = null;
Node belowNode = null;
Node parentNode = null;
NodeContainer parentContainer = null;
NodeContainer childContainer = new NodeContainer(this);
NodeData data = null;
int level = 0;
Widget widget = null;

public class NodeContainer extends VerticalPanel {
ArrayList<Node> nodes = new ArrayList<Node>();
Node parent = null;

Each node is stored within a NodeContainer, is also holds a NodeContainer to hold other nodes inside of it.

The NodeContainer needs some logic to handle the nodes, including:
– Add(Node node, Node aboveNode)
Pseudo code: Find the aboveNode and insert this node below it. Update the above, below and parent references of the three nodes so they have an up to date picture of their neighbours.

– Remove(Node)
Pseudo code: Find the node and remove it from the node container, update the above and below for the above and below nodes to point to each other, closing the hole where this node was.

With these functions in place, we can now write a movement function in the node itself.

public void move( Node moveTo, Node aboveNode )
this.getParent().remove(this);  // Remove me from my parent
moveTo.add(this, aboveNode); // Persist node after saving

Great, we can move the node around. For example you might hit a button or press tab to move the node to the right in the hierarchy, or shift+tab to move it backwards. To move it to the right essentially what you’re doing is making the node a child of the node above it. The code is simple:
node.moveTo( this.getAboveNode(), null );

There’s no aboveNode requirement once we’re into the destination node, so that’s null.

Persisting the data
You might have noticed in the move code, we implement a save() function. Each node has a reference to it’s ‘NodeData’. This is your data and all it needs to do is implement a simple interface.

public interface NodeData {
Long getParentID();
void setParentID( Long parentID );
Long getAboveID();
void setAboveID( Long aboveID );
Long getID();
void save();

So using the methods that you have written in your data object in order to fulfill the NodeData interface contract, a node is able to set the attributes corresponding to the data ii contains then hit the save() method. Obviously your save method will vary, but in general all it needs to do is send these attributes to the server and save them to the DB. My recommended option would be a simple data store put, using objectify (if you’re using AppEngine) because it’s so damn easy.

The way you style the Nodes to look the way you need them to be is by extending the Node class. It’s simply a composite so you can treat it like one. In the initialising function for your own node extending Widget, you’ll need to call initWidget() in the node class, and then add the nodeContainer to the widget you’ve initialised in the node class. From here you can decorate that initialising widget however you’d like with buttons, text boxes, etc.

I haven’t been able to fit everything into this post (for example loading the widgets, including the algorithm for sorting sibling nodes by aboveID and the recursion function needed to draw the tree), but hopefully this has given you the basis to form a solution. If you’d like the code I’m using for my own hierarchy then just leave a comment and I’ll upload it to GitHub.

Nick Cooper

]]> 3
What is agile? Fri, 24 Feb 2012 23:29:47 +0000 Read more »

There’s a lot of confusion around the concept of agile, and particularly when it should be used. Basically, agility is a property of a class of business methodologies. Being agile is great, given the choice between agile and cumbersome who wouldn’t choose agility? But the thing to realise is that you might be accepting other trade offs.

A good analogy is a military air craft. Agility is a great thing to have depending on the role. As it turns out, for a fighter jet agility is one of the most important properties you can have. Dog fighting involves a tight decision loop and the faster you can react and out manoeuvre the opponent the better your odds of winning. Fighter jets need to be agile.

But what about a bomber? In a one to one fight a bomber is never going to be as agile as a fighter jet. The role of a bomber is not to provide combat power in the air but to provide a strike capability on the ground. For a bomber characteristics like range, payload and stealth are more important, agility almost doesn’t enter the picture. Would you waste time building an agile bomber?

When it comes to engineering a software system traditionally a very large process (known as the waterfall methodology) is followed. For government it goes like this:

  • Get the project mandate,
  • derive operational operational needs,
  • work down to functional requirements,
  • put it out to an open tender,
  • a bunch of people respond,
  • analyse tenders by set of predefined criteria,
  • functional requirements form basis of contract (deliver all these functions and we pay you),
  • contractor writes up a big design,
  • validate design,
  • deliver system,
  • test system,
  • authorities approve system,
  • transition into service,
  • sustain it

What a pain, we have to go through all those steps just to get a system?

Well there are really two main steps:
– Build something
– See if it works

If it works, bingo! If it doesn’t, go back to step 1. Except the thing is, evey time you go back you compromise the system. All or part of what you built in step 1 is now waste. Not only that, but the architectural decisions made while building step 1 now have to be revisited, and the design won’t be as good as if it had been rearchitected from the start. The design will have bandaids all over it.

So what we want to do to keep cost down and improve the design is to get it right the first time. Waterfall methodology does all the thinking up front. Work out exactly what the user wants, design the system, build it to the plan, test that it met the original design and introduce it. Waterfall is like a sniper. He chooses his time and place, identifies the target, gets permission to take the shot, tests the wind, makes adjustments, fires….. and confirms the kill. He gets it right the first time.

Or does he?

What if our sniper can only fire once, but now he’s trying to hit a man with a rocket pack at 200 meters from a moving train. He shoots, he misses! All that planning, all that setup for nothing, the solution was the most efficient one possible for a static target, but once things get crazy he needs a new plan.

And that new plan is agile.

Agile is the heat seeking missile. From atop that train he quickly locks in and fires the missile. The target is flying around, dodging and weaving and all the while the missile keeps adjusting trajectory to move toward where he is, but eventually hits the target. Wasting fuel and wasting distance but it eventually hits and we all say mission accomplished.

So which method is the best? It completely depends on the scenario. It scenario one the sniper rifle was obviously more efficient, the heat seeking missile was overkill. But in scenario 2 the sniper missed, all that effort wasted. Even though it used more fuel and cost a hell of a lot more overall, at least with the agile missile we hit the target.

So there we have the two methodologies, the sniper and the missile.

It turns out that in the commercial sector agile is the most effective strategy. Yes it’s more expensive, but only if the waterfall method hits the target spot on the first time, which considering how fast the market moves and how fickle customers can be is pretty damn hard. Agile works on iterations, continually testing and adjusting the solution.

Agile works quite well for commercial and small projects, so where does waterfall come in? Waterfall is great for large projects, where we can’t afford to be agile and the solution can be very well conceptualised ahead of time. You wouldn’t agile design a space shuttle. Imagine designing something that you think looks pretty good, sending it off into space only to have it blow up. Oops! Let’s do another one and tweak that failure point. It gets a little higher then blows up again. Great job. It’s also possible in government that even though agile would be better, due to the number of approvals required and public money handling requirements waterfall becomes your only option, which is frustrating but sometimes necessary.

Waterfall is often occasionally useful in very large software systems. Sometimes these systems are just so huge, particularly with considerations like change management, transition plans and engineering hours spent in development that you just can’t afford to be building the wrong thing. You only get one shot and the problem isn’t going anywhere, so it makes sense to do the analysis up front and get it right the first time.

So there you have the two methodologies. Next time you’re presented with the choice: agile vs waterfall just stop and have a think. Is the target nice and still or will it move slightly before I’m finished aiming? I want the rocket launcher, but can I afford it?

Whichever you choose it will come down to waste. Do I can make the shot without wasting it, or would it be better plan on wasting some time and fuel for readjusting.

Did you like this article? Check out the free task management tool I’m developing at You’ll love the simplicity, and your colleagues will love how much more orgnised you are.

Documenting a Startup Episode 3 Sun, 12 Feb 2012 11:54:15 +0000 Read more »

After uploading the version 1 How Do You Feel app, and feeling pretty good about it (no pun intended) I decided to do some work (just an hour or two here and there after work) to pretty it up a bit. I can’t have something horrible floating around on the web with my name on it surely? It looks like this personal experiment (continuous integration) is actually working, as even the smallest changes are pretty rewarding to see on the live URL, making me more motivated to keep making them instead of just reading Hacker News or learning some wanky programming language I’ll probably never use until bed time.


Version 1 – The debut

The concept here is that there’s a simple question, how are you feeling today?

There are two axis you can vote along and no words, just pictures. Right to left is happiness, up and down is exitement. So you can be happy and exited (overbearingly happy), happy and unexited (content), or unhappy but neutrally exited (simple depression), or some combination (there’s 9 total).

Clicking on an element takes you to the next screen which says which one you chose, and then goes and gets the aggregate happiness for the entire site, so it immediately gives a sense that you’re connected to something bigger.

The whole idea is that it’s about the user. How do you feel? And it’s such a subjective question that you’re compelled to answer it, knowing that there is no wrong answer. The phrase how do you feel was determined by using the Google Keyword Tool, which scored high on traffic and low on competition.

The foundation for the app is GWT and it’s written in Java. Some people say Java is too verbose but I’m a fast typist (again, no pun intended!) and I absolutely love the way Eclipse can check and auto complete code as you type. Sure Python might be faster and it interrupts your mental flow a bit less by not getting in the way as much, but it’s pretty damn cool to be able to code the same language throughout the entire application stack.

On the backend I’ve used the appengine datastore and Objectify. The datastore is treated pretty much like a giant hashmap. You just take an object, pass it from client to server (all transport is abstracted away once the interfaces are defined), then objectify.push(object) it straight into the datastore, love it. I do quite like relational databases (more than NoSQL) for the record, but the idea of mass scalability and the novelty of not having to write queries to get or store data (speeding up development) seemed intriguing enough to at least try the datastore out for this app.

Version 2

The site gets a little more complicated with the addition of geolocation code. It checks your IP and uses a free API to get the city the user is from (url: Some testing though proved it to be not quite accurate enough. It worked well on my computer, but using my phone it said I was in Sydney instead of Melbourne. The description of the API said it accepts user submissions of location based on blocks of IPs, so I’m guessing the company my phone is with (Optus) is assigned to Sydney, even though they use some of their available IPs in Melbourne. Either that or I’ve heard that mobile networks sometimes NAT the entire network, so maybe all phone’s appear as the same or at least a very small set of IPs to any external website, making the per city functionality useless for mobile devices.

The other option was to use HTML5 geolocation, but the problem with that is it asks the user to confirm they want to share their location. We don’t want the users exact position down to the metre and asking for permissions disrupts the flow of the user experience. Instead I kept the API but changed the app to get location by country. Broad enough that no personal information is requested but precise enough to be useful and accurate.

Version 3

The most immediate change is that we’ve simplified. Rather than having two axis of happiness, a concept that itself needs to be explained, there are just three faces to choose from. Your country is automatically selected for you, and a map of how the world is going is displayed right away.

Between version’s 2 and 3 I also read the book The Lean Startup by Eric Ries, which was a real eye opener into the management principles you’ll need to survive in the modern world. His basic premise is that scientific management, pioneered by Frederick Taylor in 1910 has been taken too far, and used as an excuse to make the workplace too rigid and unable to change. This is probably because the companies at the top of the food chain want to maintain the status quo and just stay profitable forever (and who wouldn’t want that), but the world is changing. Disruption is the new buzzword and the rate of change is never going to decrease. The lean manufacturing movement was pioneered by Toyota decades ago to somewhat counter the trend towards inflexibility and waste, and Eric Ries takes the ideas into the world of software where they thrive as useful tools to turn today’s behemoths into tomorrows agile (but still large) organisations.

I’ve started applying it to this experimental startup by thinking of every change not as a feature to be implemented, but as a hypothesis to be tested. In thinking lean we want to minimise waste, and there’s no greater waste than working diligently to a plan that was wrong to begin with. Every plan makes assumptions and leaps of faith, so the idea is to make changes as small as possible and to test them with real data as quickly as possible to tighten the feedback loop. Although it’s slightly more effort, Ries argues that it is far, far less wasteful than wasting valuable engineering hours on a perfectly flawed, unverified plan.

I’ve added a link to my pivotal tracker to the website, which is where I’ll store the hypothesis to be validated. There’s also a feedback link to capture any input from existing users.

Version 4

After watching a user struggle to use the website I made a few basic changes, and it’s clear that there will be many more required in the future. What’s the deal with the colours, how do they relate to the faces? So I’ve added a colour gradient beneath the faces and given them words, so a user knows exactly what they’re getting when they click it. The colours also relate to the map, yellow is happy, blue is sad, and green is somewhere in the middle according to the gradient.

And how are we going with validating hypothesis? Well, the overall hypothesis of ‘I think people will want to see how the world is feeling’ is not yet proven positive, because there’s been almost no visitors. To be fair, no one knows about the site except the facebook visitors, and they got version 1, so you wouldn’t exactly expect them to return.

To be even fairer, the site does need more to it. For a start, you can click a face as many times as you like and they all count as valid votes. Who can trust the data when that’s the case? So if I was being true to the method, I’d have to say that we’re not actually to the ‘testing’ part, we’re still in implementation.

I’m currently reading a book on design called The Non-Designers Design Book which is proving to be full of the most immediately useful design ideas around (the low hanging fruit), perfect. Maybe it’s time I had a look at the site from the design point of view before coming back to implementing a single vote mechanism.

The best way to validate one vote per user per day would be through a login method, but I think that forcing users to login at this stage would interfere with any testing activities. I’ve only had a couple of visitors do this, but even coming to the site and spamming votes shows there’s some interest. Ideally it would support Google, Facebook and Twitter login, and I could easily do Google login, but what’s the point of doing any login system if the idea itself is fundamentally flawed? I’m quite prepared to pivot, and until the idea as a whole is validated as useful I don’t think it’s worth doing any long term engineering work, especially with such scarce hours (maybe 1 per day on a good week) to contribute to it and this blog series. So unless it becomes critical for testing, login will have to wait, hopefully I’ll have a better idea to validate the idea behind the site in the mean time.

Scale Fail
I also ran into my first engineering constraint with app engine. Every ‘vote’ is stored in the database as an individual record, and when getting the overall score for a country (done once per vote, and once per country every time the map is loaded) you have to extract every relevant record from the database.

If you vote ‘happy’ on Australia and it returns that there are currently 300 votes with an average score of ‘happy’, that’s 300 read operations it’s had to do to get that result. And every time you click vote, it does 301 more, 302 more, 303 more. The world map is even worse because it does every vote in the world for the last 24 hours. I had a user or two spam votes until the map just stopped showing up.

Logging into the AppEngine backend it showed that I had exhausted the daily quota for reads which is 50,000. This wouldn’t be a problem on a relational database as you could use an aggregate function to average it for you on the server and simply return the result. However, that’s the point of AppEngine, that would take up processing time on the database and that means as the app grows you’re going to need more database servers, which is pretty wasteful. So with AppEngine, you can’t do that.

What the answer needs to be is that for every vote it looks up the current score and updates the average, so the server only needs to pull the current average out for every hit. For the world score it can contain the average of each country as separate properties in one record, so getting all that data out is still only one ‘read’. I’ll setup a cron job to recalculate the averages from scratch every 15 minutes or so.

Looking forward to polishing off this iteration to see if it’s a winner or a dud that can be pivoted. Either way it’s just great to keep learning about GWT, AppEngine and lean startups.

Documenting a Startup Episode 2 Sat, 11 Feb 2012 10:08:50 +0000 Read more »

In one little action I’d completely humiliated my fiance.

After fiddling with GWT for a few hours my amazing app was ready to share, complete with a horrible color scheme and some very ‘special’ to say the least faces.

I post it on my facebook feed for laughs and my ever supportive fiance, without even realizing what she was linking to put it on her feed as ‘probably the best thing ever’.

The next day I’m chuckling over how crap version 1 was but how liberating to have it out in the wild free and from my own fears of not meeting the expectations of others, having thoroughly lowered them. While checking the visitor analytics, I idly comment  that there are actually quite a few users from Canada and Sri Lanka. She freezes.

Canada and Sri Lanka? Those are her home countries, and therefore her friends who clicked her link! She rushes to the website hoping that it’s the inspired genius she’d expect from her can-do-no-wrong fiance.

Sorry babe, it’s version one, the minimum viable product, as crap as it gets ; )

“I hate you”

The occupational hazards of a startup!

Can I make money online? Sat, 14 Jan 2012 04:46:31 +0000 Read more »

Talking about making money on the internet has a bit of a stigma about it these days. This is probably because of all the hyped up ‘get rich quick’ schemes that are advertised so heavily on so many less than desirable sites, however, the fact of the matter is – Yes, you can make money on the internet. It’s a multi-billion dollar industry.

Now before I continue: Don’t worry I’m not going to try and sell you anything. There’s no affiliate links, no CPA products, no ebooks, nothing. The only way we will profit off this blog is if we one day decide to advertise.

So now with that little disclaimer done, lets get to the reality of the situation. As much as would-be internet millionaires who try program after program trying to make their millions so they can live on a beach and never have to work again don’t like to believe, for all intents and purposes making money on the internet is just like running any other business except, you guessed it, on the net.

There are several ways people can do this, whether gaming Google with blackhat SEO techniques (not recommended!), eBooks (which can range from extremely informative to just plain rubbish), selling products on eBay, or mastering the art of getting cheap google AdWords traffic through split testing and optimisation; at some point along the line you’re going to realise “Hey, this is hard work!”.

You’re going to be making spreadsheets and entering all sorts of data to calculate which of your numerous split tests is performing the best and deserves your full budget. You’re going to be sending and receiving emails every day to customers, product suppliers, or content writers. You’re going to be carefully managing your finances because every time you run that $10,000 campaign you stand to lose thousands of dollars.

But the news isn’t all bad, you’ll get to work your own hours, be your own boss, and be able to tell people that you are that guy who actually did it. Also, being that you are by definition an entrepreneur you’re not constrained by the chains of a ‘salary’ and can stand to add a couple of zero’s to that bank balance and pay off the mortgage.

There are of course two distinct reasons why you’d take a normal business and put it on the internet.
1. The increased connectedness brings together people with niche interests in a way that they never before could. If there’s a cat collar enthusiast community, suddenly it might become profitable to create luxury cat collars and sell them to the community. The product has nothing to do with the internet, but it’s being on the internet that makes the entire business viable.
2. Internet ads are much more efficient than the old print and television ads. You can target very specific demographics including individual users who have visited your site before but not purchased. And once targetted you can measure the exact performance of your ads with statistics as useful as dollars spent vs dollars made (if you give the formula the value of a sale). The power of online advertising is killing traditional media and bringing normal non-internet industries online.

Your limit rests only on that one factor, how hard are you willing to work for it? This scares off 99% of the people who are typically attracted to internet riches. The ones who are attracted to it for the wrong reasons. The question is: which type of person are you?

Your turn
If you’re just starting out leave us a comment with a question about anything at all, we have heaps of experience and want to see new players succeed. Also feel free to sign up to our rss

Good luck

Did you like this article? Check out the free task management tool I’m developing at You’ll love the simplicity, and your colleagues will love how much more orgnised you are.

]]> 7
How to open a business in eight easy steps Fri, 06 Jan 2012 23:08:20 +0000 Read more »

So you want to open a business. Great! Maybe you’re even most of the way there. But like it or not, there are eight steps you’ll need to follow. Skip any and you’ll probably find that no one will want to buy what you’re selling. Luckily, they’re pretty easy.

Remember when you open a business, if you’re not returning value for the money you receive then you’re either receiving charity from someone (which is ok for a little while) or stealing from them. The more people you help, the more value you’re creating, and the more money you deserve. The skill is turning a problem into an income.

So to get money, let’s create some value. The eight steps are:

  1. Find a problem or opportunity
  2. Find out how how big the problem is (is it worth solving?)
  3. Think up the solution
  4. Position your solution in the market
  5. Implement the solution and create the product
  6. Test and adjust your solution
  7. Test and adjust the price
  8. Spread the word
The point of writing a business plan is basically to cover these steps in your own head (it can also be presented to potential financiers to prove you’ve thought these through). However you don’t always need to write a business plan, skimming through these steps first should be the first thing you do when evaluating any opportunity.

1. Find a problem or opportunity

This must always be the first step. Even if you find the solution first, you should always backtrack and think to yourself what is the problem this product is solving? If there is no problem or opportunity for improvement, then there is no market to purchase what you’re selling. This is the most important one, every business must be solving a problem.

This is the most fundamental mistake. You only have to turn on an episode of Dragons Den to see just how many solutions looking for problems there are out there. Once again, you have to start with a problem to solve! What’s the problem that’s being solved for your current product? (or conversely what opportunity is being created?) If it’s a problem that you yourself have had then you may have done this step somewhat intuitively, which isn’t necessarily a bad thing, but can you think of one other person who also has the same problem?

Also note that it need not be a fundamental, huge problem, it can be an incremental one. Google didn’t invent the search engine, they just made it incrementally better and in doing that took the entire search market. They realised that search engine’s just weren’t useful enough (a problem), and they had a solution. The problem could be that business analytics are too confusing, and your solution will simplify them, or that no coffee store in your area uses ethically sourced coffee beans. You don’t need to invent something fundamentally new like a jetpack or flying car (in fact what problem would 60 second flight jetpack solve anyway?), incremental problems are just as good.

2. Find out how how big the problem is
This step isn’t nearly as hard as the first one as you have direction now, but it’s also often missed. This is basically a large deal of what is called ‘marketing’. You need to know how big your target market is, or how many people would potentially be interested in your product. For example if you’re selling basketball shoes, you’d want to find out how many basketballers there are in the areas you’re planning on selling the product to, and how often they buy shoes.

If you’re selling basketball shoe insoles, you might consider what percentage of the population require insoles, and take that percentage of the number of basketball shoes sold per year. That’s how big the problem is. Say 20,000 basketballers, x 2 pairs per year, 20% of which need insoles = 8,000 potential customers per year. These can be pretty rough, off the top of your head if necessary, but each time you do that you lose accuracy. Once you have these figures, you simply need to ask yourself whether the problem is big enough to be solved.

This will depend on the price of your product, but if you identify a target market size of only a thousand people and the maximum you could possibly charge for your product is $20, then it follows that the most money you could possibly make is $20,000. Is that enough to justify starting an entire company, marketing the product, paying the production cost on every item and converting every single potential customer into an actual customer?  (hint: often you’d be extremely lucky to get just 5% of the target market). Often the answers to this question will send you back to step 1 to redefine the problem.

3. Think up a solution
This step comes most naturally. You’ve identified a problem, now what’s the solution? It could be a physical item, it could be a website, an app, an ebook, a service, insurance, etc. A solution solves a need or problem.

Most people will immediately be able to give an answer, but you can iterate solutions also. Is that solution really the best one? Just for argument’s sake, why not force yourself to think up five more solutions to the problem (even though you’ve already found the one you like best). Then look through each of them and ask yourself which one really does best solve the problem. Often you’ll find your first answer wasn’t actually the best solution at all. It’s this kind of thinking that brings some out of the box answers that can really take the market by storm.

4. Position yourself in the market
So you’ve got yourself a technical solution. People who don’t like chopping veggies will get their snap chop. Confused people who can’t handle their money will get financial consulting services. The elderly will get their lawns mowed, you’ve got products. It’s time to fine tune both the market selection and the solution by positioning yourself in that market.

The problem is that there may be other people who provide the exact same solution as you, and the answer is to differentiate yourself within the market. Are you going to be the fastest solution? Are you going to offer the best customer service? Will you have the cheapest product? Will it be the most customisable? Will it be have the highest quality? Ideally you’d pick just one or two characteristics and focus on them, they’ll form the culture of your company and be part of the message you send to your customers when dealing with them.

Let’s say Freddy wants to start an accounting firm. He’s got 15 years training as an accountant and he knows that there will always be people out there who don’t want to do their taxes, a classic problem for him to step in and provide a solution to, with a large market to sell to. But there are already accountants out there. He sees a huge firm that guarantees to be the cheapest, in fact they guarantee a (modest) return for every customer. Another firm has the fastest turn around, they’ll do your accounting in 2 days flat or it’s free.

Freddy picks customer service. He’ll have the best customer service of any company in the area. He’ll really think about his customer’s problems and be proactive in offering solutions, give quick replies to email and will always go above and beyond to make every customer delighted. He won’t be the cheapest, or the quickest, or maybe even the most thorough, but his company will give service with a smile, quick replies by email and keep the client base small to really get to know them. And everyone will know that if you want the best customer service you go to Freddy.

5. Implement the solution and create the product
This step can involve anything. It can mean flying to China to start widget manufacturing, getting your hands dirty writing HTML code, or turning on your camera and creating the film you’ve been dreaming of, or running dress rehearsals of the services you will provide. Whatever your solution is, you need only the skills to make it a reality. Of course, you can also outsource this step, just make sure you have a rough but conservative estimate of the final price you will charge first to make sure you can afford to pay the supplier in the future. It’s also pretty standard to break even on the first batch for physical items, as you can bring the price down later if the first small batch sell simply by ordering more products in greater volume. The minimal profit lost on the first batch will more than make up the risk of having to order too many items before making sure any of them will actually sell.

Put simply: You can run at a loss initially and plan to scale up production to bring your costs down once you you’ve confirmed the product sells.

6. Test and adjust your solution
In a perfect world you’d do your analysis, find the market, design the solution to meet the need and the dollars come pouring in. It can take a lot of judgement however to get this perfect, so in the real world it will most likely need some testing and adjusting. For physical products, it’s important to physically test them to make sure they to supplier has delivered. If it’s a rifle scope for example take it for a spin and ask some basic questions like, is this actually doing the job I want of it? Is it holding the aim after firing from bigger weapons too? Are there any tragic design oversights? Can I think of one other person who would pay for this product?

Software products are a little different in that they can be ‘finished’, sold, and then later updated, so who’s to say when they’re really done?

Two counter examples are Minecraft and Blizzard. Minecraft opened their business by putting a very, very early version of their game into the market and immediately had millions of paying customers while they finished the product, whereas Blizzard famously refuse to release a game until it’s absolutely perfect. The feedback from launching an unfinished product can be extremely valuable in knowing which features are great and which don’t need to be created at all, but it’s at the cost of the goodwill of the customers who will need to be understanding that it isn’t quite finished yet.

Aiming too far into the future could bankrupt your business. So as a rule, the bare minimums for when to release should be:

  • Your product is good enough, ie it really solves the problem, and;
  • It’s better than the competition (if any)

7. Test and adjust the price
Cost vs Price
The most important thing to remember is that the price has no relationship to cost. The price is what the customer is willing to pay. This could be more than it cost you (hopefully) or less. Obviously if it’s less then you need to go back to step 1 and find more value.

Sell Value
The other thing to remember is that it’s value you’re selling, you’re solving the problem. Don’t concentrate on how good the product is or the amazing features it has, look at how many problems and how useful it is to the customer, that’s how you’ll work out the right price. Sell the product on value instead of features, which customers only care about in terms of how well it solves their problems.

Optimal Price
You no doubt already know this point but it’s worth mentioning just in case.  The price lives in the world of supply and demand, where charging too much or too little for your product gives you less profit. Yes, you can go broke charging too much, because no one buys what you’re selling. Reducing the price too much can give you many, many more customers, but the margin between your price and cost reduces very quickly as you lower the price. Sometimes reducing the price by even a dollar can halve your margin.

Segment the Market
Sometimes you’ll be able to segment your market and it’s a good thing for the seller. For example a car garage has identified two different customers for the exact same product. In the city, some people come into the garage wanting all day, every day parking, it’s part of their daily routine. Whereas others only want parking for a few hours. If you look at value, the person who only needs it for a few hours is getting a lot more value in the form of convenience, so they’re willing to pay more, whereas the daily commuter has time to make alternate arrangements. By segmenting the market a garage will charge the customer up to $16 an hour in Melbourne Australia, for a total cost of around $40 for a three hour stay, whereas the daily commuter who spends 9 hours in the garage pays a total of $10-15, even though they used more than twice the time on the exact same product. They’ve managed to segment the market by saying you only get the $15 daily rate if you enter before 10 and leave after 5, which is the daily commuters, while the other market segment has to pay the higher rate.

Testing the price
Large companies will often do huge campaigns with test groups, sounds expensive to me. There are many more creative methods you can use online. Once you have a landing page and Google Analytics (or similar) setup you can drive a small number of potential customers to your site with ads and play with the price as they arrive. Start high enough to get no sales and slowly move the price down at intervals (lower it say every 3 days), and measure the response down until you’re selling nearly at cost. It’s best to do this in the startup stage when there’s not yet any public awareness of your product, established customers can be sensitive to price changes.

8. Let the word spread, use advertising only to accelerate it
If you’ve done your marketing and testing right, then there are people who want exactly what you’re selling. If it’s amazing they’ll tell their friends about it and you won’t need to advertise at all, but for every degree less than amazing your product is you’ll need to use advertising to make people aware of what it is you’re doing. Products that are only marginal or downright scammy will need go as far as using outbound telemarketing to gain new customers, so you can see it’s far cheaper to put the effort and cost into having an amazing product rather than resorting to that! Make the user experience great and you might not even need to advertise at all, plus it’ll feel better than running a scam.

Another way to spread the word more easily is to target a smaller market. Even an amazing product might get lost in the sea of shouting voices when the market is particularly large. If you pick a niche, for example invoicing software made perfectly for bird vets (maybe they have a problem keeping track of all the different bird medicines), you can more quickly establish yourself as the number one choice in that niche, and there are a lot of benefits to being number one. People in niches talk to each other and it’s far more likely they’ll mention your product if it’s number one, rather than targeting a market like ‘cheap airfares’, which no doubt has a ton of competition.

Your turn
There now, wasn’t that easy? Now it’s time to open your business. To be fair the title was a little misleading because while it’s easy to talk about, pulling these steps off is an art and it’s all in the implementation, it’s all about you. But knowing this process will save you wasting all of your time and effort on something that would never have reached the end point anyway. Like it or not, whether you do it consciously or not, whether you do the paper version of this (the simple business plan) or not, any successful product you ever launch will satisfy each of the above eight steps.

Did you like this article? Check out the free task management tool I’m developing at You’ll love the simplicity, and your colleagues will love how much more orgnised you are.

]]> 6
Filesharing now an official religion Thu, 05 Jan 2012 00:39:44 +0000 Read more »


Here’s the official press release:

“The Church of Kopimism is recognized by the state of Sweden 

Just before Christmas, the Swedish governmental agency Kammarkollegiet registered the Church of Kopimism as a religious organisation. This means that Sweden is the first country to recognize kopimism as a religion. 

The Church of Kopimism have tried to become registered as a religious organisation by Kammarkollegiet for more than a year.

– Since Kammarkollegiet has been strict with formalities, we had to apply three times, a happy Gustav Nipe – board chairman for the organisation – says. He continues, I think it might have something to do with the governmental organisations abiding by a very copyright friendly attitude, with a twisted view on copying.

For the Church of Kopimism, information is holy and copying is a sacrament. Information holds a value, in itself and in what it contains, and the value multiplies through copying. Therefore, copying is central for the organisation and its members.

Being recognized by the state of Sweden is a large step for all of kopimi. Hopefully, this is one step towards the day when we can live out our faith without fear of persecution, says Isak Gerson, spiritual leader of the Church of Kopimism.

The Church of Kopimism is a religious organisation with roots from 2010. The organisation formalizes a community that’s been well spread for a long time already. The community of kopimi requires no formal membership. You just have to feel a calling to worship what is the holiest of the holiest, information and copy. To do this, we organize kopyactings – religious services – where the kopimists share information with eachother through copying and remix.

Copy and seed.” – Church of Kopimism


Do you still agree with Intellectual Property laws?
The Pirate Party are certainly gaining momentum, with seats now in Berlin and the EU, and most likely Germany soon. Conventional political parties are being forced to change their views on copyright or risk losing the entire under 30 block of voters.

I personally think intellectual property has gone too far. Yes, it probably does promote some people to create works that they otherwise wouldn’t have, and to have absolutely no protection could result in a tragedy of the commons type scenario, but the disruptive forces of the internet have brought us to a place where copying bits has almost zero cost, destroying old business models and creating new ones, are we really going to make laws that freeze time in the 80’s just to protect a few of today’s business’?

Did you like this article? Check out the free task management tool I’m developing at You’ll love the simplicity, and your colleagues will love how much more orgnised you are.

Why we could be alone in the universe Tue, 03 Jan 2012 23:16:21 +0000 Read more »

A bit of a philosophical post today.

First I’ll start with a belief of mine, it’s highly probable we’re living in a simulation.

This is because:
1. We’re reaching the stage where  we can create more and more complex simulation worlds. Our artificial intelligence agents, while still very primitive, are getting a lot better. Once we can simulate a human brain and also scan a living brain we will very likely be able to digitize people. In addition, quantum computing will allow us to simulate every atom of the universe. These simulations tend to be simplifications of our current universe, but as computing power increases the effort required to create a simulate tends towards being trivial.

2. If creating a simulation is trivial, then so long as the civilisation creating them survives, it makes sense to assume an infinite number of simulations would spring up. If infinite simulations exist, then the probability of us being in the one true (non-simulated) world would tend toward the trivial also. That is, there’s almost no possibility that we are currently in a non-simulated universe.

I was doing some thinking on evolutionary computing and how it could be used to create an ecosystem of agents that compete to complete tasks on the Amazon Mechanical Turk. Sure they’d only make a few cents, but it might be enough to cover their hosting/computing costs, which could essentially make those agents completely independent.

Then I got to thinking, once evolutionary agents start being created (by us and by other agents), most agents will exist to solve a problem, they’ll have a purpose. The probability of being an agent created purely for academic no-purpose observation would be next to nothing. The academic agents will be created and observed, then shut down, while the agents with a purpose (even if it’s just ‘making enough money to live another day’) will carry on indefinitely.

If you take these two concepts together; it’s highly likely we live in a simulation, and it’s highly likely this simulation exists for a purpose!

This creates another answer to the Fermi-paradox, the question of where are they? If we’re not alone in the universe, why haven’t we made contact with extra terrestrials?

If you assume that it’s highly likely that this universe exists inside a simulation, and that just as in nature, all agents or simulations are created to fill an evolutionary niche, ie they’re created for a purpose, it makes sense that we would be alone.

If something has created this universe to gain an information output, assuming that human calculations are the output, it makes sense that they wouldn’t want to contaminate it with other life forms. And so it would seem probable that no matter how far we spread through this universe, we will never find others like us, because this universe was created for a purpose and that would only mess things up.

As an analogy, imagine a computer program designed to classify clothing. You give it an item of clothing and it has to classify whether it’s a shirt, pants, socks or a hat. It has to work out whether it’s for a man or a woman, what colour the item is, and what size person it will fit. The point of the program is obviously to classify the clothing so it’s more convenient for shoppers to find the items they want based on their needs. This is a task commonly sent to the ‘Mechanical Turk’ for humans to do, because computers are currently very bad at it.

So imagine a program designed to complete this task instead of humans, earn a few cents in the process and pay for it’s own hosting. Firstly, it would likely have some form of evolutionary computing. Instead of just trying to ‘exist’, it would spawn many instances of the same code with a few variables tweaked. Then it would let each program try to work out the correct answer, and assess each program against the actual answer (‘it’s a blue, male shirt’). These agent-candidates would all be insulated from each other to avoid contamination of their answers, much like how in an exam you can’t talk to the person next to you.

From the perspective of each agent, the world is made up of four dimensions (colour, gender, size and clothing type). It has a model of the world consisting of objects that track the dimensions, and the successful agents have worked out that they need to correctly classify the clothing to be ‘fed’ (or continue existing). The agent lives and breathes these concepts and doesn’t understand anything outside of them, because the clothing and the reward are the only input it has. Just like we live in a world with four dimensions, we live on rocks and breathe air, we compete against each other for ‘energy’, what if the entire universe we live in, our entire model of the world, was simply the input for a program? And the actions we perform are the output, from which we are ‘fed’ (survive).

In such a scenario, assuming our current actions are the intended final output of the program, I can’t imagine ever coming into contact with extra terrestrials, it’s possible the universe isn’t even simulated to that level of complexity outside of the solar system until we get there. This would satisfy the Fermi-paradox question of, if they’re out there, why haven’t we heard from them? It’s not that all civilisations destroy themselves after achieving the ability to communicate and spread through the universe, it’s just that those civilisations are insulated from each other and will never be able to communicate.

What do you think?

Did you like this article? Check out the free task management tool I’m developing at You’ll love the simplicity, and your colleagues will love how much more orgnised you are.