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.
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:
or see the presentation here:
I’ve published a review of Clojure in Action by Amit Rathore on the LJC Book Club, read it 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.