Announcing Scriptus, my latest side-project!

I've been working on this small project in my very limited^* spare time since Christmas 2010. I published as open source it a couple of weeks ago, and I've been quietly gathering feedback since then.

Scriptus is a way of programming interactions between people. What's new is that these interactions can be complex and span days, weeks, months or years: elections, chess tournaments and games are all easy to create. The project web-page is here and the blog is here.

Scriptus programs are written in JavaScript, the world's most easily accessible and widely available programming language. Programs communicate via Twitter, since Twitter and their API is open to all and easy to use. Programs can run for months, years or longer, due to the magic of Rhino's serialisable continuations. In addition to that there is a simple UNIX-like process model.

For more information, check out the user guide, API documentation, or the Scriptus project home page.

My motivation is that I am simply driven to create and write programs. It's part of who I am. Fred Brooks said it better than I ever could and I encourage you to read the whole of this, but in short, "Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all..."

Scriptus is meant to let you create programs that interact directly with people without bothering with much of the folderol and yak-shaving that you normally have to do when programming. It's designed to give a new approach to the idea of programming; one that thinks long-term and is focused on people.

I'm interested in your comments and feedback on the project. Many thanks so far to Torrey, Sander, Jean-Michel, Jenya and Nathanael for feedback and advice, and of course to Bethan for her loving support and encouragement :-) Onwards and upwards!

(Footnote *: To illustrate just how limited my time is: I have a full-time job and a baby daughter, and since January, I've spent my 20 minute commutes on the tram programming, when I find a seat. Also, when baby is asleep in my lap, I can balance a netbook on my knees. The rocking motion of my arms when I'm typing seems to to be soothing to her :-)

YAGNI and the boring stuff

YAGNI is an acyonym meaning "You Ain't Gonna Need It", and behind this lies the principle in software that code should not be written before it is needed: the temptation to prematurely generalise and abstract, to write a framework for the problem you're trying to solve, should be resisted.

It also focuses you on the task at hand, which is to directly solve the problem. By focusing on the shortest path between point A and point B, the result should be small, lean, and direct.

However, in several projects I've worked on there comes a point where certain aspects of a codebase not directly related to its functionality begin to demand attention. These issues can be ignored up until the point at which inaction damages the codebase as a whole. I find these things are common across projects, and so they could be classed as "You're Gonna Need It". The examples that immediately come to mind in Java projects are:

• A logging setup, i.e. configuration of log files for errors and debug info.
• Likewise, a sprinkling of informative logging statements, without which it becomes difficult to tell what went wrong outside of a debugger.
• An exception hierarchy. You can throw new RuntimeException for a while, but eventually it becomes unmanageable and you need to distinguish in catch() clauses between errors inside and outside of your own codebase
• Interfaces, for the classic reason of hiding the implementation, but also because it enables Proxy-based AOP which is useful for a bunch of stuff 'YAGN' but may one day be 'YGNI', such as benchmarking and security interceptors.
• A base test case / test harness that lets you pull in different parts of the application and test them individually.

This stuff is all boring but necessary. When living without them starts to affect efficiency and quality, that is the point at which to stop working on functionality, get this stuff right, and then go back to working on the important things.