In the previous post, I set up a new NPM project to work with, and added in Grunt as a task runner so that we can do complex tasks if we want to. Next is setting it up to build ES6 code into ES5 via Babel, so that we get to use the newer features - Classes, Arrow Functions, Destructuring, Let/Const, and so on - whilst running on a runtime that doesn’t yet support them - because no runtime yet supports ES6 fully.

Babel is a Transpiler that we can use to automatically convert ES6 code into ES5 code for exactly this purpose. It literally takes existing ES6 source code as input, and converts it into ES5 source code as output - in the same way that a compiler would covert source code into machine code.

If we so desired, we could use the exact same setup for working with CoffeeScript, Dart, TypeScript, or any of a growing set of languages that we can convert into Javascript.

Read More

Whenever I start a new project using NodeJS, there are several things that I always do first. I thought that I’d finally get around to writing up what these things are, so that I can reference it myself, and in case anyone else might be interested. This covers part one of this writeup, setting up a base Node project, and adding Grunt in to it so that we can use Grunt as a task runner for more complicated builds. Next post will cover setting up the build so that we can write our code in ES6 instead, and later we will look at setting up some static analysis to keep code quality highter.

Read More

MongoDB has a lot of good things about it, and equally a lot of bad things about it. This is true of most database engines though, and you need to know what you’re looking at to be able to make a good call over which system to use for what you’re doing.

Optimistic locking is traditionally quite difficult to achieve. You need to ensure that the version in the database matches the version in the update request, and fail if that’s not the case. There are a few ways of achieving this, but often with risks and race conditions involved.

Read More

Assuming you’ve got a Maven Build, and you’ve got a correctly configured Site for your build, and then further assuming that you are using the Travis CI system for your Continuous Integration (It’s free, so why not), one potential next step is to automatically deploy your Maven Site somewhere.

Read More

I like the idea behind using Node.js for webapp development. I really do. The idea of using a consistent language between both client and server, which therefore means that you are able to share code between the two without replication. Who wouldn’t like that?

Read More

The latest version of the ECMAScript Language - ES6 - introduces a lot of new features. One of the most interesting of these is the introduction of a module system that is built into the language. The way this works is, unfortunately, very different to how any of the pre-existing ES5 module systems work.

Wait, what? Most of the time when people discuss the new ES6 module system it is talked about as being one of the brand new features of ES6, and not an existing feature that has been fit into the language - such as Promises. However, there are already a number of module systems that are used and very well supported in ES5. The fact that there are different module systems, and that they aren’t trivially compatible, is a big problem. There are ways of making the three major module systems work together, but it’s not great to have to do that just to work around this fact. As such, the fact that there is a language-level module system in ES6 is a good step forwards. It’s just that the new module system isn’t a perfect solution.

Read More

I’ve just recently been working on getting my Hexo blog set up, and importantly on getting it automatically deploy to Github Pages every time I do a commit. Given that this is a generated site, there are intermediate steps involved between the source that is committed and the site that is deployed.

The obvious way to achieve the actual Build part of this is to use the fantastic Travis CI, which can be set up to perform a build every time you do a commit to a Github Repository. The challenge involved in this is getting Travis to be able to push the deployed site back to Github for it to be accessed. However, it turns out that Github have a solution that can work for this as well.

From this point on, I’m going to assume that you’ve already got Hexo configured as you want it, and you know how to configure Travis to build a Github repository correctly.

Read More

Blogs are not a new thing. However, a re-emerging trend is to use Static Site Generators that take source code stored in a source control system, compile this up into static HTML files and deploy the compiled HTML as the site. There are obvious drawbacks to this style of doing things, but at the same time there are a fair few benefits to it as well - more so for certain type of people who are used to thinking in terms of code that gets compiled into the results (i.e. us developers).

Having decided to use a Static Site Generator, there’s then the question of which one to use. There are plenty to choose from, but the three big ones are:

• Jekyll
• Octopress
• Hexo

Octopress is actually just a fork of Jekyll. Both of these are written in Ruby, and have a relatively large number of plugins and themes to select from. Hexo, on the other hand, is written in Node.JS and whilst it has plugins and themes, the selection isn’t quite as much. However, from having played with both Hexo and Jekyll, the architecture of Hexo just feels better. The big problem I had with Jekyll was how the themes were so tightly integrated into the actual configuation. Changing themes in Jekyll is not a trivial thing to do. Because of this, I’ve chosen Hexo as my generator of choice.