Walter Higgins

Tinkering with Software & the Web

Platform Game

2014/09/13 10:08

Minecraft as a Platform

In all of the coverage I've read about Microsoft's rumored bid to acquire Mojang, I haven't yet seen any talk of Minecraft as a Platform. Minecraft: the Platform, is far more interesting than Minecraft: the Game. It's interesting to Microsoft, it should also be interesting to other big players in this space.

When I say Minecraft is a platform I mean it in the same way we say the Web is a platform. If you don't believe Minecraft is a platform then go ask any of the thousands of plugin developers and server administrators who are in freefall since the recent DMCA Takedown.

Minecraft has become Important - too important to be controlled by a boutique game development company in Sweden. The thousands of developers and administrators who build on top of Minecraft now see this. Microsoft see this. Learning the Minecraft protocol and how Minecraft servers work, will be important to software developers in the same way learning HTTP and how web servers work is today. There, I said it.

I'm ambivalent about Microsoft acquiring Mojang. Will they Embrace and Extend Minecraft as they've done with other categories? Let's hope not. On the other hand, some adult supervision and a Plugin API would be welcome. Mojang have the financial resources but lack the will and focus needed to publish and support a Plugin API. Perhaps Mojang themselves don't realise just how important their little game has become.

An interesting thread on reddit spells out the alternatives for developers who want to build on an open Minecraft platform. Me? In my down-time I'm going to stop reading the book I was reading and go read some source code instead. It may come in useful some day.


Minecraft, Microsoft, Platforms, The Future

George Orwell: Why I Write

2014/06/17 09:08

Writing a book is a horrible, exhausting struggle, like a long bout of some painful illness. One would never undertake such a thing if one were not driven on by some demon whom one can neither resist nor understand. For all one knows that demon is simply the same instinct that makes a baby squall for attention. And yet it is also true that one can write nothing readable unless one constantly struggles to efface one’s own personality.
-- Collected Essays, by George Orwell : part47



Nashorn Vagaries

2014/06/08 09:52

JavaScript sometimes causes me to doubt my sanity. I spent a good few hours debugging weird behavior in Nashorn's JS engine yesterday. JSON.stringify() wasn't doing what it was supposed to.

In scriptcraft I expose the JS engine as a javascript variable called __engine . That is - you can access the JS engine from javascript itself and do something like this:

var x = __engine.eval('( { "names": ["tom", "dick", "harry"] } )');

I noticed something odd - An object read this way was not being output correctly by JSON.stringify():

console.log( JSON.stringify ( x ) )

outputs "undefined". Yet if I construct the same object using JSON.parse:

var y = JSON.parse( ' { "names": ["tom", "dick", "harry"] } ');

and output it using JSON.stringify() the output is fine. So basically, what I think is happening is that in Nashorn:

var x = __engine.eval('( { "names": ["tom", "dick", "harry"] } )');

returns an object whose "names" property is a Java array, not a JavaScript native array so it can't be stringified by JSON. The subtle differences between Nashorn and JRE7's JS engine are driving me nuts right now.


JavaScript, Nashorn, ScriptCraft


2014/05/14 14:05

I've seen this happen...

Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.
-- Typical Programmer - Why don’t software development methodologies work?


Programming, Agile


2014/03/25 12:15

Mark Jason Dominus on Java...

When you learn Perl, Python, Ruby, or Javascript, one of the things you learn is a body of technique for solving problems using hashes, which are an integral part of the language. When you learn Haskell, you similarly learn a body of technique for solving problems with lazy lists and monads. These kinds of powerful general-purpose tools are at the forefront of the language.

But when you learn Java, there aren't any powerful language features you can use to solve many problems. Instead, you spend your time learning a body of technique for solving problems in the language. Java has hashes, but if you are aware of them at all, they are just another piece of the immense Collections library, lost among the many other sorts of collections, and you have no particular reason to know about them or think about them.
-- The Universe of Discourse : Why I like Java



Mid-Career Perl

2014/03/11 11:12

Chromatic on being a Perl programmer in the middle...

Look, I'm a programmer. I solve problems. I've managed teams and I've been managed. I've written documentation and I've written tests. Some days I've deleted more code than I've written and I've been glad of it. Some days I've solved customer problems by not writing code. Some days I've been elbow deep in profiles or Valgrind reports and other days the best thing I've done was add an index to a column in a database and it was totally worth all of the research to reach the point where that was the solution.
-- The Mid-Career Crisis of the Perl Programmer - Modern Perl Programming


Perl, Programming

Debugging Jasmine

2014/03/04 10:36

If you want to debug your Jasmine tests then run Node like this (assuming you've kicked off an instance of node-inspector already)...

node --debug-brk node_modules/jasmine-node/lib/jasmine-node/cli.js --verbose {PATH-TO-TEST-FOLDER}

The above statement assumes that Jasmine has been installed in the current working directory ( npm install jasmine ). Once running, open Chrome and visit http://localhost:8080/debug?port=5858


nodejs, debugging, javascript, unit-testing


2014/02/18 18:51

This is how much javascript code it takes to copy a directory tree ignoring temporary files ...

var target = 'dist',
  copyIgnore = [ /~$/, /#$/ ];

function ignoreEmacsTempFiles( content, srcPath ) { 
  var i;
  for (i = 0; i < copyIgnore.length; i++ ) {
    if ( srcPath.match( copyIgnore[i] ) ) {
      return false;
  return content;    
module.exports = function( grunt ) {
    copy: {
      all: {
        options: {
          process: ignoreEmacsTempFiles,
          noProcess: ['**/*.{png,gif,jpg,ico,psd}']
        files: [ { 
          expand: true, 
          dot: true, 
          cwd: '.', 
          dest: 'dist', 
          src: [ 'src/**' ]
        } ] 
  grunt.registerTask('default', ['copy']);

... There's a lot of buzz and activity around Node.js and its ecosystem, some of the innovations in node and the ecosystem are very very good. Others, not so much. Grunt feels like a throwback to the dark days of Maven and POM.XML files. Grunt has no built-in tasks so even a copy task requires you to install an additional npm module. That feels like plugin fetishism to me. When I first encountered Rake, it was a light-bulb moment. Rake is a brilliant example of an embedded DSL. The syntax is simple, you have a target, one or more sources and a block which when executed will build the target using the sources as input. This is the essence of any good build system. Grunt configs in contrast don't even look like a build file. Grunt feels more like Maven, it's self-regarding software. I've spent all day debugging Grunt just so I could figure out how to get it to ignore certain files when copying. That to me feels like Grunt-work.


grunt, node, make, javascript

Goodbye Python

2014/02/13 16:08

Ian Bicking on giving up Python...

It’s oddly common to see people talk about how a programmer can pick up something new in the matter of a few days or months. To find programmers that consider all that knowledge transferable (for instance). I don’t know what to make of it — my less forgiving self thinks these people have never known what real mastery is. I don’t think it takes another 10,000 hours to get mastery in a new language and environment… but it definitely takes some thousands of hours, some years of hard work. I only now feel like I’m getting close.

Maybe it’s my perspective on what mastery is. Deciding to do something and then doing it is good. It is not mastery. You have to pick the right problem to solve. You have to pick the right way to solve it. You need to know when to revise that plan, and understand the constraints that inform that revision. You need both large scale and small scale intuitions. And you need to be good enough at all the details of programming in that environment that you don’t get overwhelmed with the “easy” stuff, so you have mental energy to spare on the big stuff. The jump from Python to Javascript isn’t that big, the languages have a very similar shape. And the browser was already the environment focused on. And yet redeveloping my intuition for this new environment has taken time.
-- Saying Goodbye To Python



Releasing ScriptCraft

2014/02/11 21:38

This is the procedure I use for releasing ScriptCraft - an open source side-project which is not in any way mission-critical to anyone but still has enough users who care about its reliability...

After I've done some testing and verified there are no major bugs and the documentation is up to date, I create a new release on GitHub. GitHub is great, they don't get pissy about your project existing in other locations. This is a perfectly grown-up attitude and one which all websites should adopt. GitHub don't mind or care if my source-code and binaries are also available in their own dedicated website (they are ). This is totally commendable and one of the reasons I love github.

Next I upload the binaries and release notes to - ScriptCraft's own dedicated website. It's important that ScriptCraft has its own home after all.

Finally I upload the binaries and release notes to Bukkit's site. Bukkit are a bit funny about posting links to anywhere but bukkit. They want to be the canonical source for all bukkit plugins and don't like if you link to the project's own site or github. Which makes my last port of call when I release a new version of the plugin.

Having 3 different locations from which ScriptCraft can be downloaded means I can hit a wider audience. Not everyone uses so providing the binaries and release notes elsewhere is important. Plus, if the Bukkit team do get cranky about cross-linking (hey it's the web!) to non-bukkit properties and decide to remove ScriptCraft altogether, well it's no big deal. I can't understand the thinking behind forbidding such links, it reeks of silo thinking.



Fork Me

2014/02/04 11:29

I think I maybe love too much.

Of all the online services I use, the one which has become truly indispensible is GitHub. Over the past 2 years, I've grown from an occasional to a rabid user of the service. GitHub gets everything right. Its use of Markdown for documentation? - Perfect. Perhaps what I like best about GitHub is that it has so far been resilient to the usual influx of social media types that infect most social networks. It has also (for now) stayed under the radar of Recruitment consultants, though I suspect recruitment firms are aware of github but just haven't figured out how to mine it the way they've mined LinkedIn.

What github have done is nothing short of miraculous. They've taken version-control - the bane of most developers existence (though absolutely necessary of course) - and made it social. GitHub has in a short space of time become the canonical source for most open-source projects. It succeeds brilliantly where others (e.g. SourceForge) failed.

Every time I see the Fork me on Github badge on a website I see a veiled plea for some kind of immortality. I think it's only a matter of time before 'Fork me on github' is engraved on a headstone. The phrase 'Fork me on Github' is developer parlance for 'I will not go gently into that good night'. It offers the promise of immortality, that our work at least will outlive us. It pampers to the polite fiction that what we do has lasting value. The reality of course is that - especially in the world of software development - most of what we do today will be obsolete in 5 years time. Frameworks, tools and languages go in and out of fashion on a weekly basis. Fork Me on Github offers a tantalising promise of permanence, a foot-hold into the future, the chance for memetic immortality.

Or perhaps it's just another stupid website badge.



Arduino and Minecraft sitting in a Tree

2014/01/21 23:34

So I bought an Arduino last Sunday afternoon and spent a pleasant few hours with my eldest setting up simple circuits and even running our first Arduino program. We got much further along than I had hoped. I'm new to electronics and circuitry - I know I know (hangs head in shame), so it was as much a learning experience for me as it was for my daughter. I hoped to get the Starter Kit but Maplin didn't have them in stock so I bought a basic Uno board, some push-buttons, LEDs, resistors, photo-resistors (LDRS or light-dependent resistors), wires and a breadboard and a USB cable. The total cost ran to about 90 Euro but it was money well spent.

Getting started

If you want to get started on messing with Arduino, go watch the man himself Massimo Banzi on Youtube.

Arduino and Minecraft

What prompted this sudden interest in Arduino was a thread on the ScriptCraft Group about using Arduino to send and receive messages/events from Minecraft. My first sighting of Arduino was at local CoderDojos. My kids seemed to know more about them than I did (I never - until recently at least - had much of an interest in Electronics). Anyway it seemed that wiring an Arduino with some real-world sensors up to Minecraft might be an interesting project. This is my first foray into this area. Consider this the Hello World of Arduino/Minecraft interaction.

... it's a somewhat contrived example of real-world / virtual-world interaction (a real-world 'button' is no different to a keyboard button after all) but it demonstrates how sensors attached to an arduino (which can be remotely connected over wifi with a wifi shield) can trigger events in the Minecraft game. This all being based on ScriptCraft and using Arduino hardware, the source code and instructions for setting this up are on github of course. Under the hood, it's using MQTT - Message Queue Telemetry Transport - a lightweight protocol machines use to natter amongst themselves. It's a pub/sub mechanism aimed at resource-starved machines and it's part of The Internet of Things. Needless to say, I like it.

There's plenty of potential for some interesting two-way interaction between Minecraft and Arduino-based contraptions. I can't wait to see what others do with this.


Arduino, Minecraft, ScriptCraft

Tone Deaf

2014/01/20 10:14

A good piece by Om Malik on Google's misdirected energies...

And yet, I cannot get over what seems to me a tone-deaf approach by Google’s scientists. It also highlights Google’s fundamental challenge: it fails to think about people as people, instead it treats them as an academic or an engineering problem. Instead of trying to understand the needs of actual people, they emerge with an elegant technological solution.

It is not just this one time. Google+, their social network, is a fail because it fundamentally isn’t social or about people — it is an effort to solve Google’s need for social data for better advertising using machines. Similarly, Google Glasses are a cringe-worthy assault to the social interactions of normals, but because a certain subset of Googlers — including co-founders Sergey Brin and Larry Page — have a cyborg fetish, it is okay to make that design. It is frustrating for me to keep repeating this, because Google is a company with huge resources and those resources could be deployed more effectively and have a much more positive impact, more quickly. And to do that, the company needs to learn to be human and develop compassion for human condition.
-- One diabetic’s take on Google’s Smart Contact Lenses — Tech News and Analysis




2014/01/13 17:24

I've long believed that the distinction between software architecture and software development is misleading. Good software development is software architecture. You can't do one without the other.

Uber-Architects don’t create a bunch of rules and enforce them across large organizations for consistency’s sake, like a foreman with a clipboard overseeing hundreds of fungible laborers. They pick up the hammers and nails and work along side those workers, showing them how it’s done, building the thing together, and making those around them better until it is no longer a fungible collection of workers, but a humming, autonomous machine that’s more than the sum of its parts.
-- Uber-Architects: The Building Metaphor Is Dead | DaedTech


Software, Programming

An Open Letter to the Mojang Team

2014/01/12 14:25

TLDNR; Please make Javascript a first-class language for developing Minecraft plugins

A proposal for supporting Scripting in the forthcoming Minecraft Plugin API.

I'm really excited about the forthcoming Minecraft API. Not least because the people working on it are the same people who created Bukkit so they clearly know a thing or two about creating good APIs. What would make me even more excited is if Javascript was also officially supported as a first-class language for writing plugins. Minecraft has transcended its original medium. It's no longer just a game. It's a cultural phenomenon and for its huge community of server admins and modders - a platform. A platform desperately in need of an official API. The modding community is a ghetto. If you want to get started modifying Minecraft there is no clear path to doing so. Even for a seasoned Java developer like myself, it's bewildering and intimidating getting started. I can still remember those first overwhelming days last year when I began working on my own Mod (ScriptCraft). This hurts because if it's tough for a seasoned dev, imagine how tough it must be for younger people who want to try their hand at creating their own mods. I'm talking about children and young adults.

Minecraft has a huge mindshare among children and young adults. It is the first game that many children play where concepts like 'client-server', 'plugins' and other tech ideas are learned along the way. Minecraft is being successfully used in Education to teach all kinds of things. What interests me is using Minecraft to teach children programming.

Minecraft is written in Java and chances are the forthcoming API will be a Java-based API. Java is a fine language but some of the language concepts (Object Orientated Programming, Inheritance), overly verbose syntax, and tool-chain (IDEs - eclipse, etc) and the need to compile mean that Java is not an ideal language for those who want to 'dabble' or test the waters to see if Programming is interesting. The overhead and learning curve is too steep for younger potential-programmers. This is where Javascript comes in.

I've taken my kids to a couple of CoderDojo sessions over the past 2 years. CoderDojos are free and open volunteer-led environments which provide training in programming for young kids. Kids learn to program using Scratch and are also taught how to create their own websites using HTML, CSS and Javascript. The excitement about programming at CoderDojo sessions is palpable. Javascript is a comparatively easy language to learn, especially for younger programmers. Anecdotaly I can say there's a lot of interest in Modding minecraft at the coderdojo sessions I've been to. Kids are learning to program in Javascript. I imagine a lot of these same kids would like to use that knowledge to create cool Minecraft plugins.

The good news is that Javascript is bundled with Java since version 6, so any Java-based Application (like Minecraft) can - with a little effort - expose its API to Javascript. This is how my own Bukkit Plugin (ScriptCraft) works, it provides a Javascript-to-Java bridge to Bukkit's excellent Server API. ScriptCraft is a Meta-Plugin, a Bukkit Plugin that lets plugin authors write their own plugins in Javascript. This for example is how you add a new Bukkit event listener in JavaScript...

events.playerJoin( function( event ) {
  var player = event.player;
  player.sendMessage('Welcome to ' +;

... It's more succinct than the equivalent Java code and it doesn't need to be compiled. You just put the code in a .js file and drop the file in a folder and the code is executed whenever a player joins the server. Java bean setters and getters are optional in Javascript which is why player = event.player and works. The only thing provided by ScriptCraft in the sample code above is the convenience object events which provides a simple way to add Bukkit Event listeners in Javascript. Javascript has come a long way and systems like NodeJS with its adoption of the superb CommonJS Module System mean that large-scale modular systems can now be written in Javascript with little additional effort. Again, ScriptCraft has recently adopted the CommonJS module system so a ScriptCraft plugin (a bukkit plugin which depends on ScriptCraft) might look like this...


var bkEntityType = org.bukkit.entity.EntityType;
exports.spawn = function( location, entityType ){
   var world =;
   world.spawnEntity(location, bkEntityType[entityType]);

... and might be used like this...


var spawn = require('spawn');
var animals = ['COW','PIG','HORSE','SHEEP'];
exports.spawnAnimals = function( location, count ) {
   var i = 0;
   for (; i < count; i++){
      spawn( location, animals[ i % animals.length ] );

... and at the in-game command prompt (or from another module) you can use the farmspawn module ...

/js var farm = require('farm'); farm.spawnAnimals( self.location, 25 );

... This by the way is another great advantage Javascript has over Java - programmers can 'explore' the game API more easily by executing javascript (it's interpreted so no need to compile code) at the in-game prompt. I realise you're a small team and you're already under a lot of pressure to deliver an official plugin API. All I'm asking is that you consider Scriptability as an important feature of the API. Since Javascript is the only Scripting Engine embedded with Java 6 and 7 anyway, it should be possible to add official support. Further down the road, these are items on my wish-list for official Javascript support from Mojang...

Most of the above are already present in ScriptCraft today so please feel free to co-opt the features/source-code - it's all open source. To sum up. I wrote the Bukkit ScriptCraft plugin and from day one I saw it as just a stop-gap solution until Mojang officially publish a Plugin API and hopefully add supporting Javascript functions. I would like nothing more than for ScriptCraft to become redundant and for Mojang to officially support Javascript as a language to develop Minecraft plugins. This would make a lot of young budding developers very happy. A Javascript API for Minecraft Plugins would be rocket fuel for young minds. The Mojang Team have an opportunity to do something great here. I hope you do.


Javascript, Minecraft

BeerJS Cork

2014/01/10 22:20

Prompted by a tweet from local BackboneJS expert James Sugrue, I suggested a meetup of a few local Javascript people in Cork.

One thing I'd really like for 2014 is to get Cork tech events buzzing. You can help by listing your events with @SDigestCork

— James Sugrue (@sugrue) January 1, 2014

... so BeerJS Cork is happening next Thursday 16th January in the Vicarstown Bar on North Main Street, Cork. It's basically a meetup of Javascript/Tech/Software people. You can get all the details including a map of the venue at This is going to be pretty informal, no presentations, no whiteboards etc. A few people have been asking what to expect so I'll point to

Pub Standards is open to everyone. It's loosely aimed at web design & development geeks, but that doesn't mean chitchat need necessarily be work-related. Don't expect structure, don't expect presentations, just relax with like-minded people and a few beers.

This is the post-conference drink-up, without the conference

... which pretty much sums up what I had in mind when I proposed the meetup. If that sounds like it might interest you, then please pop in. Vicarstown Bar is a nice recently refurbished pub in the city center. They do craft beers and have a beer garden out back.


Javascript, Cork


2014/01/10 16:58

I've been playing around with SweetJS just for fun. Macros in Javascript seem like a good idea. They're clever, they reduce boilerplate and allow you to write javascript using a cleaner syntax (much like CoffeeScript) but I'm not convinced the trade-offs are worth it.

One area where sweetjs and coffeescript can make life easier is in callback syntax. ScriptCraft uses callbacks for event-handling so you might write code something like this in javascript to handle a particular event-type...

events.on('player.PlayerInteractEvent', function( listener, event){ 
   if ( == 'walterh'){

... I'm not a big fan of the syntax overhead - the function expression and closing }) has always looked ugly to my eye. SweetJS can make this look cleaner by defining a macro like this...

macro on {
  rule { 
    $eventType $listener $event $body 
    events.on ( $eventType ,function( $listener, $event) $body )   

... which would let me write the Javascript event-handling code like this ...

on 'player.PlayerInteractEvent' listener event {  
   if ( == 'walterh'){

... which neatly gets rid of the need for that function expression, parameter boilerplate and trailing }). It's cleaner for sure but I'm not sure it's really that much cleaner. There's a couple of problems with using SweetJS or CoffeeScript in ScriptCraft - the big one being that ScriptCraft is meant to be a tool for younger programmers to learn to program (with the opportunity to build cool stuff or even create full-blown mods in Minecraft being the carrot). I can't really stand over that claim if I bring CoffeeScript into the mix or - worse still - introduce my own custom macros.

Is that really much cleaner than this...?

events.on('player.PlayerInteractEvent', function( listener, event){ 
   if ( == 'walterh'){

I'm going to leave aside the need to compile sweetjs macros into javascript and the attendant headaches of writing code in one language but debugging it in another. SweetJS might call them 'macros' and 'hygenic variables' but it still smells like code generation and obfuscation to me.

Update: 2014/05/08

I've since simplified the events API so you can add (and remove) a handler like this...

events.playerInteractEvent( function( event ){ 
  if ( == 'walterh'){
  this.unregister(); // unregisters this function if needed.

... which saves a few characters and simplifies unregistering (which was a pain previously - I didn't even include unregistering code in previous examples). All without resorting to macros or coffeescript. The listener parameter and event parameters swapped places because the listener parameter was rarely used and only for unregistering. It just added noise. It seemed cleaner to just bind the listener function to a behind-the-scenes object with a single unregister() method.


Javascript, SweetJS, CoffeeScript


2014/01/10 09:47

I'm working on a project that uses Angular right now and have for the past two years been using Dojo, so I can feel the allure of frameworkless javascript. This is what have to say about Angular...

...And despite it's been marketed as being simple, the API is huge. Currently there are 147 different sections on the sidebar of their documentation area. That's a big cognitive load. I need an empty table for building stuff.

And I really don't like to put so much logic in views or wrap my precious code to proprietary "directives" or "filters". The fairly complex logic of Moot is better expressed with plain old JavaScript.

Frameworkless Javascript

... Angular is useful but it is a framework written by framework guys for framework guys. That is - it assumes you are already something of a Javascript adept. It's not a framework for beginners. Directives, Controllers, Interceptors, Dependency Injection - don't try to tell me any of this is 'easy'. My biggest problem with Angular isn't that it does a whole lot of magic, it's that you have to understand the magic. Dependency Injection is magic that looks great on paper but I've never come across DI that 'just works' without having to dive into the innards of the framework to debug some case where it doesn't 'just work'. Spring and Angular are both guilty. DI - particularly in Angular - feels like bad magic. I've been reading O'Reilly's AngularJS book and it irks me how often the word 'Awesome' appears in that book. Remember when Computer books just provided references, tutorials and sample code and didn't try to tell you how 'awesome' everything is?

Anyway, the problem with arguing the case for using POJOs ( plain-old-javascript-ojbects) instead of locking in logic to proprietary Dojo Widgets, or Angular Directives or some other framework-provided container, is that POJOs in javascript are still a misnomer (at least in browser-based js) and defining objects in javascript doesn't come naturally if your team are Java people. When it comes to objects-oriented programming, javascript seems to suffer the same problem as Perl - There's More Than One Way To Do It (TMTOWTDI).



Bonsai Programming

2014/01/07 10:39

Most friendship is feigning, most loving mere folly.

Also known as Personal Programming, or Programming in the small, or Software Carpentry or Pet-Project Programming. I've been doing a lot of Bonsai Programming over the Christmas break. You would think that my programming day-job would be enough and that the last thing I'd want to do for relaxation would be more programming, but the opposite is true.

Programming in the Small offers a refreshing break from Programming in the Large. Bonsai Programming is a chance to focus on refining and perfecting a small system of your own design. A system where you are the end-user, the architect, the key stake-holder, the product manager, project manager and software developer all rolled into one. Bonsai Programming offers a chance to start with a clean slate, to 'do things right', to hone and tweak, to refactor with impunity, to play code golf. For me personally, Bonsai Programming is what I do to unwind. Some people play computer games, I prefer to write computer programs. It's been like that since the early days when I first realised that programming my first computer (a ZX Spectrum) was infinitely more fun than playing games on it.

My current Bonsai ( ScriptCraft ) has been as much about tweaking and honing the documentation as it has been about coding. I've been fortunate in that ScriptCraft has attracted interest from other developers and contributors, and has a small user-base. These past few days I've had to constantly fight the urge to write new code and instead I've been documenting code which was long overdue documentation. If ScriptCraft is to grow, it needs better documentation, better example code, a compelling killer mini-game ... the list goes on.

Where was I? Oh yes, Bonsai Programming is something I do to unwind. Returning to work and programming in the large after a sustained period of Bonsai Programming throws into sharp relief the differences between the two. There's a tension between the two types of programming. I'm seasoned enough to understand the need for all of the artifice and ceremony that comes with programming in the large, and still naive enough to hope that Bonsai programming is more than mere folly.



Create Minecraft Server Mods using Node.js style modules

2014/01/03 14:52

During the past year I've been tapping away at ScriptCraft in my spare time. In my day job I started using Node.js a couple of months back. One of the things I love about Node.js is its module system which is based on the CommonJS module spec. The module system used by Node.js is just so simple and elegant and really lends itself to thinking about programming in a more modular way. While ScriptCraft is aimed at younger programmers (or programmers who just prefer to mod Minecraft using Javascript rather than Java), I think modules and thinking about code in a modular way should be part of any novice programming curriculum. Modules shoudn't be an afterthought and Node.js's module system is succint and expressive enough to be understandable by beginning programmers. At the end of the day the difference between these two source files is minimal...

hello-basic.js (traditional javascript)

var salutation = 'Hi ';
function greet( player ){
    player.sendMessage(salutation +;

hello-module.js (modular javascript)

var salutation = 'Hi ';
exports.greet = function( player ){
    player.sendMessage(salutation +;

... In the first example, the greet function is a global named function and the salutation variable becomes a global variable too. In the second example, exports.greet is assigned to a function expression and the salutation variable is private. In a node.js module, everything (functions, variables) is private by default. If you want to make something public you add it to the exports variable which 'exports' all its properties for use by others. I've been programming for 26 years and have programmed in a lot of languages in that time. The node.js module system is the most elegant module system I've yet encountered. It's so good that I decided I had to have it in ScriptCraft. I did some digging and there are a couple of implementations of the commonjs module system , at least one or two available for Rhino, but projects like Narwhal seemed to be too heavyweight for ScriptCraft's needs. All I wanted was the bare bones module loader - not the standard module libraries ('http', 'fs', 'system' etc). Really all I needed was a good working require() function that adhered to the CommonJS module contract and to be able to export stuff using exports and module.exports. After some hacking, I got a bare-bones module loader part working recently. It works in Java's javax.scripting JS Engine and conforms to the CommonJS module contract. ScriptCraft modules that reside in the scriptcraft/plugins directory will be loaded automatically at Server start-up and any exports will become global variables - this is obviously different from how Node.js modules work but it's a convenience for novice programmers who just want to write functions and be able to execute them at the in-game or server console prompt. Modules in the scriptcraft/plugins directory are also auto-loaded and auto-globals to be backward compatible with how ScriptCraft used to work (all .js files autoloaded at startup - dependencies between modules was a bit problematic). ScriptCraft modules that reside in the scriptcraft/modules directory behave pretty much identically to Node.js modules. For example to use the utils module (which resides in scriptcraft/modules/utils/

var utils = require('utils');
var player = utils.player('walterh');
player.sendMessage('Hello ');

... this style of javascript coding should be familiar to Node.js programmers and I think it's a good idea to expose younger programmers to modules early in the course of learning programming. Thinking about how to decompose a big problem (how do I create a complex minecraft mod) into smaller problems and solving each problem in turn using distinct modules, is a good skill to have and the CommonJS module system is a superb tool for thinking about problems in a modular way. Variables, Functions, Looping, Conditionals, Modules and the distinction between private and public data and functions are all important basic concepts in teaching programming. Most of us who learned Javascript had to overlook the lack of a module system and the syntactic ju-jitsu required to get privacy, but now at least (on the server-side) there's a great module system in CommonJS. I'm going to stick my neck out here and predict that in the long run, any Javascript framework that doesn't use the CommonJS module system will eventually lose out to JS frameworks which do use CommonJS modules.

Things will be better for the Javascript programmers of tomorrow.


ScriptCraft, Nodejs, Javascript