I’ve been looking at ClojureScript for a while. The elevator pitch
would go something like this.

ClojureScript is a dialect of clojure (itself a dialect of lisp). You have all the power of lisp, but it uses Google’s libraries, know-how and optimizing compiler to emit efficient javascript that runs standalone in the browser. It can interface with other libraries such as the industry leading jQuery to give you the best of all worlds in power and productivity

In the last few weeks there seems to have been a real uptick in
interest. Some very exciting and cool demos are starting to show up
on GitHub

To give you an idea of what’s possible - There was recently some discussion on the
clojure mailing list about this video by Bret Victor (aka @worrydream, UI
designer extraordinaire). In the video Bret demos a very interesting system
he’s developed to allow developers to connect better with their
creations. His premise is that by connecting better with what you’re
developing you see things that you wouldn’t see in the usual code/test
cycle.

After seeing that video, Chris Granger spent some time prototyping how such a system would look
in clojurescript. The results are
impressive
to say the least. Chris then mentioned on IRC that he’d spent less
than a day on it and actually most of the time had been spent on a
problem not directly related to the prototype. The fact that Chris put
this together in a few hours using a technology that’s not even out of
nappies is a sign of where this is going.

Another fantastic demo by Chris is this control panel for Overtone (a
very cool music synthesis environment developed in clojure)

A good introduction to the ClojureScript world is the ClojureScript One Example Project. This has really detailed documentation, clean design and
annotated code. Well worth a couple of hours of your time.

I’m a fan of automated software testing. If you’re not providing proof
that your code works as part of your deliverable you’re not really
doing software development, you’re just having a bit of fun on the
side. If you hit up google for
Test Driven Development
you’ll find lots of information about what it is, why it’s good and so
forth. The focus is on the process of testing, but there’s not much on
the effects of good testing on your system. The
wikipedia page
only makes passing reference to the effect on design. I like to think
of TDD more in terms of Test Driven Design than development.

For me this brings out one of the primary benefits. By
focusing on designing the system to be testable up front a better
design emerges almost by magic. You get less
coupling,
tighter
cohesion,
lower complexity.
Any code metrics you care to choose will all come out better with good
testable code.

Another benefit that often gets overlooked is the way tests document
the developer’s intent. Good tests read as a description of the functionality.

A new developer starting on a project can find it
difficult to get to grips with the ‘meat’ of the system. I always
point new people at key tests and say, run these tests in the
debugger and see what’s going on. This is much more
interesting and informative than wading through stale, dry design
documents.

Last week I attended a conference about MongoDB - a leading player in the emergent NoSQL space. (The sessions were videoed by the excellent SkillsMatter, you can watch them here).

Other players in the space that look interesting are CouchDB, Neo4j, Cassandra, I’ll likely be investigating all of them in future posts. Now these various projects are not drop in replacements for each other, but at a high level they are all solving a problem in the BIG / DISTRIBUTED / REALTIME / CALCULATING ™ space.

There are a lot of issues that immediately come to mind, before we even start looking at the technology. A few questions that immediately spring to mind:

I’m starting a new blog to talk about the exciting work I’m starting out on. The focus of the blog will be mostly technical, with a slant on solving real problems.

In essence, I’ve decided to ‘go it alone’ after 17 years or so in the software development business, and see how I get on. Most of my working life to date has been spent working as an independent consultant to a variety of different companies. Mostly large financial companies, but there have been some brief forays into telecoms and flight booking systems.

Most people who I’ve spoken to about this plan have the same first question, “Hmmm, so what’s the big idea you’re gonna implement?”. They know that I have family and a mortgage and they assume to risk all that I must have a killer idea. Well, here’s my secret, there is no big idea. (pause for dramatic effect). I don’t think that big ideas are the key.

I have a view on what general areas are going to be important in the next 5-10 years and I intend to spend some time researching those areas. My goal is to identify a growing market and leverage my technical expertise to develop a product that can fix someone’s problem in that market.

I’m a strong advocate of ‘getting on with it’ and finding out what works and what doesn’t. I don’t intend to spend months developing a master plan. Rather they’ll be experiments and evidence to prove what’s worked or otherwise. This is very much in the spirit of the The Lean Startup approach advocated by Eric Ries. Looking forward to the book.