I gave a talk about clojure and clojurescript @skillsmatter where I did some ‘live-coding’ for the London Clojure User Group on March 6th 2012.

You can watch the video of the talk here

or look at the slides here

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)

Another interesting example is this Gin Rummy game.

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.

Since I’ve been doing lots of learning about clojure. I’ve been picking up / recovering my emacs skills.

To that end I gave a short lightning talk about paredit - the emacs minor mode to handle parentheses et al.

Watch it here:

http://sw1nn.com/talks/paredit

or see the presentation here:

http://sw1nn.com/slides/paredit

I’ve published a review of  Clojure in Action by Amit Rathore  on the LJC Book Club, read it here:

http://ljcbookclub.wordpress.com/2011/11/25/book-review-clojure-in-action/

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.

So…onward and upward.