Success!

One of the two products I'm working on had its first deployment to people who we hadn't met and nurtured last weekend. We've spent a bit of time looking at logs and the conclusion is: It worked! OK, there's a couple of bugs to fix, a couple of performance tweaks we could make, someone wants a new feature and we still have a big enough backlog to keep us occupied. But, as a proof of concept, it gives us a lot more confidence; as the start of something that grows through user network effects we can be relieved; and we're starting to get publicity: nice pieces at Stuff and CNet.

Drawing Skills for Computing

Drawing pictures is a vital skill for computing. Pictures of our designs in particular.

Towards defining the minimum viable product

I finished work today on a happy note: the "current" milestone task list became empty!
This obviously leaves the task of looking at the backlog and choosing the next step.

Testing for Value

Companies need a way to validate their ideas - and reduce the cost of adapting them when validation says that their value isn't so good in their current state. Accepting that most products and business strategies evolve, this validation needs to be efficient, effective and ongoing. Ideas are business value for companies who rely on innovation. For a start-up with a new product this process is make or break.

I recently read Eric Ries' "The Lean Startup" closely followed by Marty Cagan's "Inspired: How to Create Products Customers Love". Both interesting books, and both talking about minimum viable products and measuring response to products in order to guide innovation and direction.

PMD: Part technical note, part confession

I've been meaning to do some code style / complexity checks for a while. JavaNCSS seems to be broken with Java 1.7 syntax so I'm just using PMD. First, a quick how-to for the Jenkins install to help recreate the effect. First, create a slave instance which will stop rather than terminate, using the slave AMI. Then...

Jenkins Slave on EC2

Our Jenkins master running on an AWS t1.micro has run out of memory for running the more complex integration tests e.g. play server, mongodb, headless X and firefox. Rather than have the cost of a larger instance all the time when pushes to version control are occasional (cough) we will run a slave for these tests that only costs when there's a test to run. A simple JUnit run through can still work on the master. The Jenkins Amazon EC2 plugin makes this easy, and handles temporary instances.
This install a lot like the earlier post on creating the master, so I'll skip most of the screenshots, but fix a few things too:

CI with Jenkins, ant, git and Assembla

I've got a little continuous integration (CI) box at home. For what is, at the moment, a one person project CI might be seen as overkill. My excuses are:

Finding bugs I wasn't testing for

I had an interesting bug the other day ... interesting in that it took a day to chase down and a bit more to fix, refactor and tidy up. Interesting also in that there were two solutions, one of which would have hidden the real problem but both of which needed to be implemented - and an extra test written to uncover the now hidden one.

A fourth dimension of scalability

The AKF parners' book Art of Scalability places a justified emphasis on their concept of enabling scalability in three dimensions, as an alternative to "failing up". So, rather than buying a shinier server one designs systems to do one or more of:

1. Split traffic between multiple servers. Probably with a load balancer in front, each server having the same code and same data and sharing the work round-robin or according to load.
2. Split between functionality, with different servers for different classes of request. So, for example, logins go to one pool, search to another and so on. The idea being that with specialization servers can be more efficient, if only by what code or data they need to cache and the number of relationships with other servers they must maintain. Also, when managing upgrades on portions of the code base the effect can more easily be split away from impacting other services.
3. Split by customer. This comes out as a class of specialisation of data; but in this case to do with user data rather than function or functional data. 

ReWork

I've been reading REWORK over the last couple of days, an ideal book for odd moments which don't allow a train of thought to build up. I've had the pleasure of using 37signals' BaseCamp in other projects, so I'm predisposed to liking what they do. The book is a good articulation of "do one thing, do it well, do it to please some people, and just get on and do it".

IT as a Utility

This is an old post from another blog, which seems to fit here as well. These are my reflections after the Digital Economy IT as a Utility network+ meeting in January 2012. At the end of the meeting reflections on outcomes and ways forward were invited – below is my contribution.

Introduction

A bit over a year ago I went to a workshop, heard some interesting talks and got talking to colleagues, as you do. One conversation tied in with other work I'd been doing and set me thinking about building something. Over time that idea has been developed and worked on, and I've rediscovered the pleasure of creating a product. It ties in with the day job to some extent, but isn't out yet or making me a living. This will be a place for sharing the bits of the process that I hope may be useful to someone else - as I've read plenty of inspiring advice on others' blogs. I'll even try and share what the idea is, and why, along the way!