If you didn't know already, I write all my blog posts here in markdown. I've used several markdown editors over the years (wow it's strange to write that), and I thought I'd talk a little bit about the ones I've used, what I liked about them (and the things I didn't), and what my current preference is.

Firstly though, why would you want one? Couldn't you just use a regular text editor like Notepad++? Well, yes - but a dedicated editor has several benefits: Proper spell-checking for one, a live-preview for another, and other nice features that make the experience just that little bit better (I'm even writing one of my reports for University in Markdown, and I have to say that the experience is much more pleasurable than using Microsoft Word :P).

I like Markdown itself rather a lot too. First invented by John Gruber over on daringfireball.net, Markdown is a simple markup language that's inspired by the things that people already do in instant messaging and other text-based mediums. It's designed to be both easy to read and understand on it's own, and easy to write in - such that it doesn't break your flow as a writer by requiring you to look up how to figure out how to apply that particular bit of formatting (I find myself having to do that with LaTeX and others a lot).

(Above: A Screenshot of StackEdit.)

The first contender up is StackEdit. It's an in-browser offering, which saves it's data to your local machine (or the cloud). It comes with a number of nice features - apart from not having to install it of course - such as synchronised scrolling in the live-preview, and a 'publish' button to send your document to a number of different sources automatically.

Since I used it last (which was quite a while ago, actually), it appears to have received a sizeable update, updating the user-interface to be more polished and aesthetically pleasing, and adding a toggleable folder structure to the left-hand-side, amongst other things.

If you can't install anything or run portable programs from a flash drive, StackEdit would be my recommendation.

(Above: A Screenshot of Classeur.)

Next up on my list is Classeur. It's another browser-based offering, with many of the same features, just with a different UI. When I discovered it I was using Stack Edit, and at the time the interface of Classeur was vastly superior.

The main thing I don't like about it is that it's 'freemium' -- meaning that you get to keep about 100 documents on it, and then you either have to delete something or pay. While Markdown is just text documents I can keep on my computer, if I'm going to use a browser-based solution I would prefer to keep them all in the same place (though I never did hit this limit :P).

More recently, now that I've got a travel-laptop that is running Linux (and not Chrome OS, as nice that was I ended up out-growing it), I've been using ghostwriter. It's a desktop application for both Windows and Linux. While it doesn't have synchronised-scrolling for the live-preview as Stack Edit does, it allows you to save your text files to your local disk (or other mounted partition!), and open them as you would a Spreadsheet or other file - in a way that you can't with a browser-based tool.

The interface is also highly customisable - if you don't like the built-in themes, you can write your own. You can also write your own stylesheet for exported documents too. In addition, it automatically detects multiple different markdown renderers that may or may not have installed, allowing you to switch between them (and the inbuilt sundown processor) at will to get the exported document (e.g. HTML, PDF, EPUB, etc.) looking just the way you want it to.

For me, you can't beat the feeling of a native desktop application, so currently ghostwriter is my markdown editor of choice. If I can't use ghostwriter, I'll probably use StackEdit, with Classeur coming at the bottom of the pile.

If you're thinking of doing some writing, I'd highly suggest considering using a proper markdown editor such as the ones I've mentioned here. If you're not familiar with markdown, fear not! It's easy to learn, and all 3 of the editors featured here feature a quick-reference guide sidebar (or floating window) that you can enable to help you along.

Tired of battling endless <script> tags in your html files? Fed up with messing with a dozen libraries cluttering up the place? Can't see the wood from the trees? Try browserify (+ rollupify + wzrd)! It's amazing! It's awesome! It tidies up your code for you, so you don't have to (perhaps not :P)!

Seriously though, I've just been playing around with browserify, and it's awesome. It's that missing thing I've been trying to find for a long time. But what does it actually do, you ask?

Well, perhaps it's best to use an example. Consider these (relatively) harmless javascript files:

// SillySay.js
"use strict";
function sillySay(sentence) {
// Split the sentence up into words
var words = splitWords(sentence);
// Loop over all the words in the above array and display them one by one
for(let i in words) {
alert(words[i]);
}
}

That's looking a bit messy, but imagine what it'd be like if you added another few libraries? Or a new feature in a separate file? See the problem? Browserify solves just this issue. It analyses the dependencies of the entry point to your app, and bundles up all your code into a single file, nice and neat. You can add extra transforms (like plugins), too, to do extra things like automatically insert your app's version, or includeotherdatafiles automatically, or transpileother languages to javascript automagically (full list here).

Sounds cool yet? Let me give you a quick tutorial on how I set up Browserify, with Rollupify and Wzrd.

Firstly, we need to set things up. If you don't have Node.js installed, do that now. You'll also get npm - Node's (perfectly awesome!) package manager. Next, let's create a quick project and paste in the code above. I've recorded an asciicast (as you may have seen a few times before here) of me going through the process:

A while ago I posted about how much I like the Atom editor. A few months on, and I'm still in agreement: The Atom editor is an absolutely lovely general purpose editor. It's got a bewildering array of plugins, and I thought that I'd share a few of my favourites with you.

Termrk has to be my number one. It adds a toggleable terminal to the bottom of the screen (and presumably other sides too!). This is particularly useful for sorting out particularly nasty version control system problems, or using a quick one liner to process a few files, or starting a development server in the background. If you know your way around the console / terminal, this package is a must have.

Git Plus is also really useful. As you might suspect, it brings git integration to atom. It has a gui for all the common git commands - committing, branching, pushing, pulling, and more. If you use git, install this package.

If you use multiple computers, sync-settings is worth a look. It synchronises your settings and installed packages by using a Github gist. I use it as a backup for my settings, but it'll be also useful when I finally get around to setting up a portable installation of atom on my flash drive.

There are a ton of other brilliant packages out there that I've found and I could write about them all night, but that would make this post way too long :) If you're interested in which packages I've got installed, I've uploaded a list to pastebin.

Recently a friend of mine (who you can find on GitHub here) reintroduced me to the atom editor, which is built by GitHub. I looked at it a while back, but it was too unstable and lacked too many features for me to consider using it as my main editor. Fast forward a few years, and it's much more stable. It even comes with batteries included - it has an awesome files panel (in which you can open multiple folders), a GUI for the settings (which brackets doesn't have), and a package ecosystem which can be utilised without leaving atom. It shows you the readme for packages too, so you always know how to use packages that you've got installed (or are considering installing).

If you've heard of atom before, give it another go! You might be surprised. If you haven't, you don't know what you're missing out on.

You may have heard already - we have run out of IPv4 addresses. An IPv4 address is 32 bits long and looks like this: 37.187.192.179. If you count up all the possible combinations (considering each section may be between 0 and 255), missing out the addresses reserved for special purposes, you get about 3,706,452,992 addresses.

The new system that the world is currently moving to (very slowly mind you) is called IPv6 and is 128 bits long. They look like this: 2001:41d0:52:a00::68e. This gives us a virtually unlimited supply of addresses so we should never run out.

The problem is that the world is moving far too slowly over to it and you can never be sure if you have IPv6 connectivity or not. I built a quick IP version tester to solve this problem. I know there are others out there, but I wanted to build one myself :)

The online tool I am releasing today is another one of the projects I did a while ago (December 2013 in this case). The difference here is that someone asked me to build it for them. The tool allows you to stich a number of still images into an animated gif.

Having an online version of the tool on a server that I own seems like a good idea (so I can keep it up to date) - so I am releasing it on this site for you to use.

It uses a javascript library called gif.js to render the still images as an animated gif. Please bear in mind that all the rendering is done on your computer! Nothing is uploaded to the server at all. If you refresh the page, everything will be reset.

A description of the options and known issues can be found below. If you just want to skip all that and play around with it for yourself, please follow this link:

Options

The default delay each still image should be given when first dragged into the tool. Remember to set this before you drag all your images in to save time!

Frames per second

An alternative method of setting the default delay. Simply enter the number of frame you want to show per second.

Workers*

The number of threads to use to render the animated gif. For optimum performace enter the number of cpu cores you have. This will speed up the rendering process for large gifs.

Quality*

The quality of the resultant gif. In the code this is referred to as the pixel sample interval. I don't really understand this setting myself - if you do, please leave a comment below and I will update both this post and the tool itself.

A '*' indicates an advanced setting.

Known issues

The 'x' button to remove an image is buggy. - Fixed! A new image removal system has been implemented to fix this bug.

The size of the rendered gif i snot updated when images are removed - Fixed! The maximum image dimensions are now recalculated when an image is removed.