Monday, 12 November 2012

Game changing technology

Every once in a while a piece of game changing technology comes along.  We experienced this back in 2009 when Akka appeared.  The principles of Akka were fairly well tested, it had been done before, but (disclaimer.... subjectivity follows), the ideas were either wrapped up in Clojure, which was _very_ new at the time or Erlang, which is just not applicable to those wanting to hookup to a rich ecosystem of well used enterprisey frameworks and libraries.

We'd been playing with Akka, and its successor early on in 2009, and when it started to mature a little, at around 0.5 we plugged it into what would go on to become the worlds first commercial Akka based project.

We had grand plans for the project, which almost culminated in domain aware adaptive load-balancing and other funky concepts.  As it happened these grand plans never happened, things were scaled down from a project perspective for whatever reason.  The project was really very simple at launch time, and has remained so to our knowledge.  All of this notwithstanding, the project has enjoyed more than three years of 100% uptime.  Irrespective of whether it is the simplicity of the final proposition that has enabled this, it is impressive by any standard.

The Akka guys did a great job, marrying a slick API to proven techniques for improving fault tolerance and scalability.  We really enjoyed our time working with Akka.  Our (at the time) full time employer has enjoyed great uptime, and a reliable service.

We've left Akka behind, now, having no need for it in our current projects, and have largely moved on to Clojure which inspired many of its ideas.  We do believe however that Akka has set a standard we've not seen beaten yet for a system that can help you build reliable systems, while enjoying the tools you use.

Thursday, 28 June 2012

Injecting a little domain into your tools

We are firm believers in using the right tool to do a job.  We also believe in keeping up with evolution, tools improve over time, and in turn are succeeded by new better tools.

It is important to know your trade though, and sometimes this means understanding what goes on in the depths of the infernal machine.  Clinging to a magic shiny IDE with point and click zealotry in the hope that it can fix your problems is rarely the correct path to take.  If you've only got a hammer in your toolbox, everything looks like a nail.

Moreover, it is really our duty to understand as much as we can across the problem/implementation space of our chosen profession.

We moved away from IDE's to lighter weight alternatives years ago.  On a day to day basis we have constantly come back to the simplest of editors, Vim (or Emacs when playing in Clojure land), Textmate and for the last ~12 months SublimeText 2 for their extensibility.

It is Sublime Text 2 in particular that we would like to talk about here.

Plenty of editors are extensible, one of the reasons Textmate thrives is its extentibility.  Our experience with Sublime Text 2 is that it is quicker and easier to leverage its extensibility.

Very quickly packages can be searched across and installed, for all sorts of different purposes.  While working with Silk, our little fledgeling open source project we write almost exclusively in HTML, CSS and Javascript.  So we took the very obvious step of installing the Tag package.  Tag brings domain knowledge of XML/HTML tags to the editor, now tags are closed for you, and with tab completion we can easily remove repetitive tasks.

Additionally, we get some linting for free, so the editor now tells us when we have failed to close tags.  This is not aligning the domain to Silk itself, but it traps a large number of errors in the XML/HTML domain.  The problem spotting process is brought closer to design/creation time, which means we can fix problems faster.  We like this.  We do the same kind of thing in Silk itself, but we would rather trap as many problems as possible as early as possible.

Next we leverage Sublime Text 2's snippets.  Now we can align the domains even closer to how we would like.  While Silk invents no new elements or attributes, we do use combinations of existing ones.  This enables us to lookup components, and boostrap page generation.  It is trivial in Sublime Text 2 to create snippets so we can tab complete the creation of our template, view and component elements, again saving us time, and ensuring the semantics are correct.

Finally we had intended early on in the project to provide some 'preview' functionality, where saving a file would run the 'spin' or compile process and render the updated view in the browser automatically.  It turned out that the libraries to do this efficiently at the operating system level were a little flaky across the different OS's, so we dropped the feature.  We considered polling, but don't like the brute force approach.  With Sublime Text 2 the build system is extensible, with the creation of plugins being fairly straightforward.  In no time at all we configured the editor to run the 'spin' cycle whenever a template, view or component or associated resource is saved.  Now changes are visible as they are made.

While we are only talking about injecting a little bit of domain into our tools, the results are surprisingly productive.  It feels like the editor is doing much of our work for us.  Essentially it is like a screwdriver adapting its head to suit the screw we are dealing with.  Doctor Who's sonic screwdriver ?

Thursday, 14 June 2012

Making the web Silky

We've been working on something for a while now in our spare time, we'd like to share a little more information about it as we are soon to make a first 0.1.0 alpha release.

What we have done is partially new on the one hand, and borrows heavily from existing ideas on the other.  We want to introduce it without going down the usual path of pointing out how bad everything that came before is, as that's just not true.  We want to illustrate how Silk is useful to us in some small ways, and to other people.  Perhaps most importantly we'd like to share the vision, and where it is going.

Why are we building Silk ?

To set the scene, here are some points to consider:

  •  the web is primarily about HTML
  •  which has changed very little since 1998
    •    you can close your tags properly (XHTML)
    •    you can use some nice new features in addition to the old with HTML 5
  •  which is very secure, it is just served and consumed
  •  which is optimised for the web, its fast, efficient and has a massive audience
  •  which is not tied in to any given framework 'X' strategy or ecosystem, its just files on a disk
  •  when you serve HTML up, (if you do it properly), it can be massively cached, and is not built dynamically millions and millions of times

If the web is all about HTML, why not build for the web with just POSH (Plain Old Semantic HTML) with a little CSS and Javascript thrown in to make things shiny ?  We think semantics are good in the context of the web.

Some people don't want to keep learning new server side languages in order to write their websites and webapps, it takes our focus away from the problems we are really trying to solve, and can just get boring.

Server sides can give you the feeling you are locked in, maybe not even using the right tool for the job. How many web apps could be websites ?  How much of the content changes ?  How often does it change ?

We have witnessed first hand the frustration that some people have with the perceived requirement of dynamic platforms to build sites which are almost entirely static.

What is Silk ?

Silk is the beginnings of our attempt, with the help of our little community, to address some of the points we raise above.

Silk will only build static sites right now.  It is interesting though because it enables you to break your static sites down into re-usable components.  You can build your whole site in nothing but HTML.  Websites become more maintainable, and you can write once and then use multiple times.

Silk works around a blend of components with separation of concerns, and pipelines, drawing from concepts seen in Wicket and Cocoon.  Pipelines can be used to connect various elements geared towards transforming content into the format you need.  We only have one pipeline defined right now, as we are servicing the particular requirement of building static websites from a directory structure of content.

You can define multiple templates to be used across different parts of a website.  These templates wrap views which are the epicentre of Silk (at least as long as we only have one pipeline out of the box).

Templates and views can both use components, which can be defined locally to the project or packaged up into a local component repository.

We have a small community of contributors and committers, and all the usual infrastructure you would expect from an open source project, (oh yes, its open source, Apache License v2.0), all described over at

We even have a couple of clients using Silk to build their static sites, more news to follow.

Where are we going with Silk ?

First with the help of the community we want to make Silk very good at producing static websites... think of it as a compile time HTML development tool.  We want to build more core components, templates, make things a little slicker.

Currently, the codebase is a bit of a prototyping brain dump, and error handling is pretty poor.  Our documentation is just the bare minimum right now, and we would like to create some screencasts.  You should start to see these kind of improvements over the coming months.

Next we want to make dynamic Silk, a runtime which enables CRUD style web apps and web services to be built in a revolutionary way, no server side code.

We have ideas from the community for automation of all sorts of tasks, all sorts of things that could help make building websites more enjoyable and more stable, easier to maintain.

Is Silk for you ?

Are you :

  • bored of or just not interested in the latest server side language ?
  • bored of the all the disruptive change ?
  • keen on semantically pure markup and maintainable structure ?
  • happiest hand crafting your sites with passion ?
  • a fan of components and reuse ?
  • making static websites (for now) ?

We would like your help and feedback, please have a look if it interests you, all help is welcome.

Would you like to know more ?

Contact us on the mailing list or in IRC - details are at

To get started see

Tuesday, 31 January 2012

Development estimation 101


This is just a short post on a topical subject right now.  Having seen several approaches fail, and so far only one succeed, we thought we would share the success story.

The problem

It is difficult to predict how long a software project will take, particularly the implementation phase.  Many posts question whether it needs to be difficult, we question the reasoning behind this view. We are biased of course as developers, but then we have our own experience to draw from, and it has been hard churning through many models over the years where the effort seems doomed.

Some hopefully sensible assumptions on our part

  • You should only ever create something once in the software world and get the most out of re-use.  Therefore you are estimating for doing something you have never done before.
  • You should understand your client will have their own roadmaps and plans to juggle, and will likely require a very vague coarse grained estimate as soon as possible.
  • The human factor can not be overlooked. First it requires you to throw away science, equations, and doctrine (you know what we are talking about oh ye proponents of strict agile, scrum and waterfall).  Second complexity will manifest itself wherever we humans interact.

A model that works for us

First you need to seize the initiative.  You will need to instigate change within your organisation or your client's.  Ultimately on any estimate that is fine grained or signed off you need to ensure that those best suited to making the estimate are in fact those who make it.  We call this a technical meritocracy.  We guard it jealously now we have it... our precious....

In summary our technical meritocracy involves all relevant devs and testers sitting in a room to scope out a project chunk.  This is a process of natural selection where everybody gets their say in terms of how long their sections of work will take.  The wildly different character traits of each of the participants help to derive the best solution you are going to get.

You need several mechanisms in place to help this process along... a BS sniffer, and something to break deadlock for the rare occasions where your devs or testers can not see eye to eye.

Second you need your own magic recipe, and this is in no way scientific or rigorous doctrine, to ensure you follow a similar process each time you estimate.  We have ours, although it will be radically different for you so there would be no benefit in sharing it here - we can say however it was a case of trial and error, and absolutely requires breaking tasks down to the finest possible granularity.

Finally you need to understand that you will publish revised estimates... every time something unscoped rears it's ugly head, every time a game changing rule appears.  Nothing is set in stone.


We are in a happy place in terms of project management on our first contract.  We have incurred 48 hours delay over 9 months, which in our opinion is very acceptable.

This first contract is drawing to its end, and the project model is about to change with the advent of the next contract.  One thing will remain the same, mutual respect between peers, and giving every dev and tester the opportunity to contribute to scoping efforts that affect them in their work.

Monday, 17 October 2011

ISO 9001 and ISO 14001 awards for Bheap

Following an assessment by an independent body, Bheap has been awarded ISO 9001 and ISO 14001 certification.  ISO certification has only been achieved by a small percentage of UK businesses and is a prestigious award supported by the Government and recognised world-wide.

As Bheapers we feel that if we want to preach quality and eco-friendliness we should practice them.  In our favour is the fact that we are a tiny company, and new to boot, so the footprint in terms of processes and documents to manage is small.  Against us is the fact that there are only a few of us to share the extra work and quality control tasks.

We have always been proud of the quality of services and products we offer to our customers, and the way in which we conduct our business.  Now we can add to that satisfaction in the quality of our own internal processes.

Friday, 7 October 2011

Keeping Software Simple

Why keep software simple?

The idea of software is and always has been to automate a task, or to make a particular job easier.  It's a tool we use to improve efficiency, quality and ultimately productivity - if it's more straightforward to accomplish a task we can in theory accomplish it in less time.

It's especially important then that any software we create is as simple to interact with by a User as possible, if we are too far down the other end of the spectrum we end up with software which is so complicated to work with that it's actually a hindrance.  Unfortunately this is all too often the case.

From a pure maintainability standpoint, the more complicated the code is the more time it's going to take to maintain.  This increases operating costs, time to market and is more often than not a soul destroying experience for the development team; the side effects of which can ultimately lead to lack of motivation and job dissatisfaction.

What are the benefits?

On top of the obvious productivity benefits creating simple software can have other secondary advantages.  Users who find a system intuitive to use, a system which actually makes their lives easier, will suddenly be more engaged with their role.  The software will blend into the background and the work becomes their main focus; which is exactly how it should be.

Similarly for the developers maintaining the code, if the code and architecture is easier to understand it becomes much simpler to innovate - not to mention a pleasure to work with.  Training new developers is no longer an issue either, saving a company both cost and time.

Simple software almost always has less bugs.  This results in less down time, increased stability and less time and money spent on support.

The downside

OK, so what's the downside? Simply put, time.  It actually takes more effort upfront to create a simple, stable piece of software.  It requires a lot of thought, planning and compromising.  However, the time spent upfront in order to write something to be proud of more than pays for itself later on when you have happy users and even happier developers.

How to keep it simple

Taking the time to understand the domain is probably the single most important and overlooked aspect of developing any software product.  This can take a bit of time to iron out, but it's critical that the developers know who their target audience is, exactly what problems they are trying to solve - and for which reasons.

Another important facet to keep in mind is to consider restricting the feature set.  Within the software industry feature creep is a big problem; the emphasis appears to be upon adding as many features in as short a time as possible.  By concentrating on just those features that add genuine value to accomplishing a particular task, the task which the software was originally intended to solve, more time can be spent creating an elegant architecture and intuitive interface to wrap around them.  For example adding a feature which allows a 'Library borrowing system' to use different skinned windows is far less important than getting the feature which allows users to check out books right.

Using the right tool for the job when building an architecture is vital, if the wrong technologies or frameworks are implemented it can very quickly lead to a bloated and confusing codebase.  It's worth taking the time to invest in researching what's available, there is no reason in the current busy ecosystem of frameworks and tools available to tie yourself into any one vendor or platform.  It's cheap to find out at the start of a software project what your options are, it's not the same story once you're already tied to a particular set of technologies.


In essence simpler software is more reliable, promotes engagement, can save on operating costs and is a pleasure to work with and maintain.  With a lot of thought, a bit of research and planning and the courage to say no to unimportant features there's no reason any software product can't be a pleasure to use, and a breeze to support.

About the Author

Barrie McGuire is an open source developer, enthusiast and co-founder of Bheap Ltd.  A software company which specialises in simple, elegant software solutions written in Scala.  Barrie has over 7 years experience in developing commercial software using cutting edge web and mobile technologies.
email:  |  twitter: barrmc  |  website:

Tuesday, 23 August 2011

Spark, your light in the dark

We are excited to announce the beta launch of our first product Spark.  This is our first step into the world of mobile apps, currently available only on iPhone and 3G enabled iPad.

Spark helps you let the people who matter know where you are when your battery is about to die if you are on the move.  Running in the background in a low power consumption mode, the app tracks your battery level, and if it falls below a threshold you configure, sends notifications to your contacts via email.  We think that this will give loved ones or colleagues the reassurance that you are safe if you forget to charge your battery before setting off, or if you forget your battery charger when you go on business trips or holidays.

For home users Spark is designed to give peace of mind to your loved ones when they can't get hold of you.  You will feel reassured that even if your phone 'goes dark' those who care about you will know where you are.

For business users Spark can help let your colleagues or boss know that you made it to an important meeting, even if you were forgetful and forgot to charge your phone before leaving.  If you head off on a business trip aboard, but forget your charger, colleagues will know why you have gone 'black ops' :-)

Spark is currently in beta, and there are of course a few little bugs to iron out.  If you find any, please head over to the website where you will find the forum.  We think it is stable 'enough' and useful enough to have pushed it on to the App Store, hopefully it will be useful to you.

In a matter of weeks we will be pushing the second update live, and will then start to market the app.

The evolution of Spark does not stop there, while we want to ensure it is always simple, and useful, we have plans for developing the product, including SMS notifcations.  An Android version is planned also.

Let us know what you think of it!