LiveReload With Gulp

I’ve started working on a project to learn and use ES6 Modules, Angular and Gulp, and one of the first issues I encountered was getting LiveReload to work, refreshing my browser every time I changed a file. For those not familiar with the concept, LiveReload works in one of three ways (from the LiveReload FAQ):

To communicate with your browsers, LiveReloads needs its JavaScript code to be injected into your web pages. There are 3 ways to arrange that:

  • either add a script tag into your HTML code manually, or
  • install a browser extension (that, when activated, adds the script tag to the visited pages on the fly), or
  • use a plugin for your web framework (that adds the script tag on the fly when serving requests).


Writing and Programming, Crafts Worth Honing

I’ve been doing quite a lot of writing lately, and quite a lot of thinking about writing, and a fair bit of reading too. This of course was one of my goals for 2015, and I’ve been keeping a consistent journal for the first time ever (fourteen days straight and counting). From all of this writing there is one thing I’ve come to realize and it’s that writing begets writing. The more you write, the better you become at clearly expressing your thoughts and ideas through writing and translating them from the jumble in your head to the written word. Your fingers fly across the keyboard with very little barrier between your mind and the keys.

As Joel Spolsky once said,

Writing is a muscle. The more you write, the more you’ll be able to write.

I’ve found that this is a truth in software engineering as well. When you are working with the same language every day you quickly get a lot better at expressing concepts and building elegant implementations through a lot of practice and Rote learning.

However, as is the case with writing, this can only get you so far. To truly hone each craft, and yes I consider programming and writing very similar crafts, you need to start to focus on different things if you are to further improve your craft.

For a software engineer, this might mean learning a new language or framework. There are a whole lot of them out there to choose from, take your pick! Or thinking of an idea for an app or tool, making it, and shipping it! Or even researching different concepts and APIs in your current language of choice, to get a new take on it and learn more about the tools that you have available to you.

For a writer, this can mean writing in different genres or from different points of view. It can mean writing in different formats. Have you ever written poetry, a long form essay, started a blog or written a journalistic piece? As with software engineering, you need to start thinking, really thinking about what you are doing, practice hard and push your own boundaries to really start getting good.

I compare these two crafts because the 10,000 hour rule is applicable to both. Each craft requires careful, deliberate practice for the engineer or writer to improve and become and expert at what they do. And if you really have a passion for something, you will bend every ounce of your will to perfecting that craft because you always get joy out of learning more from it.

Developing a craft is about dreaming big, and thinking deliberately about how you can improve. But you can’t let either of these things stop you from honing your craft. Dreams can stay as just that, dreams, or they can turn into a bestselling novel or highly successful company. Thoughts can stop you from ever accomplishing anything, from ever writing a line of code or setting pen to page. I think Rudyard Kipling had the right idea in his poem If:

If you can dream — and not make dreams your master;
If you can think — and not make thoughts your aim;

Writing is simple. Just write. Coding is simple. Just code. The rest is practice, practice, practice, passion, perseverance and a little bit of luck. Hone your craft, and love what you do.

Lessons Learned From Building Rain

Tackling a new project is the best way to learn about a bunch of new things and solve a lot of new problems. I’ve recently built Rain, a gem to generate beautiful API documentation from a Ruby comment syntax with markdown mixed in (check it out at!). On the Rain project, I’ve learned a couple of things about gem development that I wanted to share because I think it might be helpful to others. (more…)

Render an ERB Template from a Hash

I needed to render an ERB template from a hash for external email templates, and found that this is not as straightforward as you might think. I found a blog post on with a way to accomplish this. Basically, the hash needs to be converted into an OpenStruct before passing it to the ERB template.

The important part of the article and the code snippet demonstrating the functionality are below:

“you have to set the binding for ERB by saying opts.instance_eval {binding}. This runs binding in the context of the opts object, so then calls to methods like first_name made by ERB in this context will evaluate to the values of our hash.”

This will of course result in “Hello Martin Brennan.”.

Goodbye RequireJS, Hello Browserify

For a long time now, I’ve been relying on RequireJS for JavaScript dependency and module management and we have it incorporated into our front-end JavaScript workflow at work as well. There are a few things that have always bothered me about it:

1. Third party libraries, if not properly set up to use AMD, are a pain to include and use. Sure there are shims in RequireJS, but I’ve always found the system flaky and hard to understand.
2. Though not always an issue, we’ve found that sometimes modules simply do not load in the correct order, and it is difficult to diagnose the issue or to force them to load in the required order.
3. Dependency management amongst third party modules is often a nightmare, as the location of the modules that the third party libraries require are often not in the same location as where you want them.
4. The require and define syntax can sometimes be laborious, e.g. for libraries that do not need a variable in the function () {} call.
5. I’ve found that require modules are hard to concatenate in the correct order into one file, as well as uglifying at the same time.

These things have had me waiting for a new module system to come along and finally it’s time to say goodbye RequireJS, hello Browserify! (more…)

What makes a bad software developer?

I came across this question on Quora a while ago (see What are the characteristics of a bad software engineer?, and while the answer with the most upvotes is quote comprehensive, it made me think about the question a bit myself.

I would say the biggest indicator of a bad software developer is someone who is unwilling to learn and unwilling to improve themselves, which manifests itself in a lot of different ways. The first of these that springs to mind is Quality. (more…)

Sensible .NET REST APIs with AttributeRouting.NET

I have a lot of problems with the default .NET Web API that Microsoft pushes for people to use. You can only easily have two GETs, and one PUT, POST and DELETE route per controller. There is no easy way to create more complicated nested routes, i.e. GET /v1/person/:id/contact/:id, or routes that deviate from the norm. The routing syntax (not just specific for the Web API but other .NET services too) is horrible and unwieldy, and all routes must be defined in a separate file. Route constraints, precedence and validation are also tricky.

All of this may turn you off of writing an API in .NET, but there is an easy solution to all of these problems in the form of AttributeRouting.NET. This NuGet package allows you to define routes directly on controller methods, with out of the box support for route constraints, prefixes, precedence etc. It is compatible with the Web API and also .NET MVC. (more…)

DocuSign Connect XML Schema

For those of you that have developed for the DocuSign E-Signature platform, you’ll have probably used their DocuSign Connect service to listen for document and recipient events so you don’t have to long-poll their servers, which they strongly discourage. The example XML in their Connect documentation frustratingly does not have all of the possible values and fields that could come through with each request.

I decided to investigate this and came upon this StackOverflow Q&A that had a handy answer, which linked to the complete DocuSign Connect XML Schema as an XSD. You can find the XSD below:

DocuSign Connect XML Schema (XSD)

Print GitHub Markdown Bookmarklet

I was looking for a way to print GitHub markdown documents without all of the GitHub navigation, UI and other extraneous information showing up on the page. Mainly because I like GitHub’s clean markdown styles, and it’s very useful to be able to print documentation for certain projects.

All you need to do is add the following bookmarklet to your browser:

Here is a demonstration of what it does with the intridea/grape repo’s file (before and after):

Print Github Before

Print Github After