I started pair-programming with Daniel Szmulewicz to increase my proficiency with emacs. Although I have a working knowledge of emacs I need a mentor to show me the ropes.

I took the decision to start out from scratch so I can better understand what decision you are able to make to customize emacs. And what better starting point then building emacs from source.

The emacs wiki has a section on various ports of emacs. You can find instructions how to obtain or build emacs for various platforms.

I am not copying the instructions from the wiki. They worked for my without a lot of problems. If you have problems with it drop me a line.

Uncle Bob’s book Clean Code has a chapter called Meaningfull Names. In this chapter Uncle Bob offers advice, tips, tricks and ideas how to reveal the intention of the code. There is web of pages on the content creation wiki C2 with a similiar focus. The page Intention Revealing Names is a good starting place.

The goal of intention revealing code is to aid in Hermeneutics, a fancy word for

the art and science of text interpretations.

The motivation behind intention revealing code is the insight that the amount of code-reading far outweighs the amount of code-writing. Jeff Atwood wrote a nice blog about the issue: When understanding means Rewriting.

I recently developed a style which communicates the intent of code very clearly. In this blog I would like to share my insights, hoping that others may benefit. Lets start with an example.

1
2
3

var an_array = ['a', 'b', 'c', 'd'];

swap('b').and('d').in(an_array);

I would wager that the intent of the above code is clear. In my opinion the code is very readable, focussing on the What instead of the How. It uses a fluent interface, as introduced by Martin Fowler. A possible implementation is given below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var swap = function(this_element) {
    return {
        and : function(that_element) {
            return {
                in : function(an_array) {
                    var index_of = function(element){ return an_array.indexOf(element); };
                    place(this_element).at(index_of(that_element)).in(an_array);
                    place(that_element).at(index_of(this_element)).in(an_array);
                }
            };
        }
    };
};

var place = function(element) {
    return {
        at : function(index) {
            return {
                in : function(an_array) {
                    an_array[index] = element;
                }
            };
        }
    };
};

JavaScript knows two ways to construct regular expressions. One way is the constructor of the RegExp object. E.g.

1
2
3
4

var r = new RegExp('abra');
if ("abracadabra".match(r)) {
    console.log("positive match");
}

The other way is via a literal regular expression syntax. E.g.

1
2
3
4

var r = /abra/;
if ("abracadabra".match(r)) {
    console.log("positive match");
}

I recently developed a strong preference for new RegExp(). The reason was found in a bug I recently solved with a coworker.

While working on a Grails application we were sending a Model to populate a View. On this View a property of the model was used to create a regular expression with. This was achieved with code simlar to the example below

1
2
3
4
5
6
7
8
9
10
11

(function(){
    var Account = {};

    ...

    Account.validator = createValidatorFrom(/${model.regexp}/);

    ...

    window.Account = Account;
})()

In this case model.regexp is used to create a regular expression that is passed into the createValidatorFrom JavaScript method. So far so good.

But what happens if the model.regexp is null? Then the ${model.regexp} will collapse to the empty string rending the JavaScript snippet invalid. The reason being that the literal regular expression accidently got turned into a single line comment hiding the closing bracket.

1
2
3
4
5
6
7
8
9
10
11

(function(){
    var Account = {};

    ...

    Account.validator = createValidatorFrom(//);

    ...

    window.Account = Account;
})()

If the new RegExp() constructor was used this would not become a problem. The constructor accepts a string. No slash-delimiter could be turned into a single line comment by accident.

Having said that, care should still be taken when working with regular expressions. Character classes like \d or \s tend to be interpreted in JavaScript string, causing problems of their own.

The command line is a powerfull tool. It harnessess the power to slice and dice data from and into the system, transforming it for the better.

The pragmatic programmer even devotes a tip on the use of the command line:

Every woodworker needs a good, solid, reliable workbench, somewhere to
hold work pieces at a convenient height while he or she works
them. The workbench becomes the center of the wood shop, the craftsman
returning to it time and time again as a piece takes shape.

For a programmer manipulating files of text, that workbench is the
command shell. From the shell prompt, you can invoke your full
repertoire of tools, using pipes to combine them in ways never dreamt
of by their original developers. From the shell, you can launch
applications, debuggers, browsers, editors, and utilities. You can
search for files, query the status of the system, and filter
output. And by programming the shell, you can build complex macro
commands for activities you perform often.

I recently learned a new command which I find very usefull. The command is cut and it allows to cut a line of text along a delimeter and select a portion from it.

From the manpage for cut

The cut utility cuts out selected portions of each line (as specified
by list) from each file and writes them to the standard output. If no
file arguments are specified, or a file argument is a single dash
(`-‘), cut reads from the standard input. The items specified by list
can be in terms of column position or in terms of fields delimited by
a special character. Column numbering starts from 1.

For example the following command kills all the running java programs with one command.

1

ps -u dvberkel | grep java | cut -d ' ' -f 4 | kill -9

Software Craftmanship is a hot topic. Like all fancy terms it is subject to inflation. What does Software Craftsmanship mean when different people use it?

Martin Fowler retreaded an article about Semantic Diffusion which addresses this point. In this blog post I try to expose the values of Software Craftsmanship I held dear.

It is a Journey

The metaphor used by the software crafsmanship movement is that of a guild.

A guild (German: Gilde) is an association of craftsmen in a particular trade. The earliest types of guild were formed as confraternities of workers.

Before an apprentice could become a true master she would have to work as a journeyman. Learning the tricks of the trade while travelling from master to master.

For my, This journey symbolises that software craftsman continously improves her skills. Furthermore she should sieze every oppertunity to learn the “secrets” of the craft.

This implies having an open mind, accept critisims and be inquisitive.

Become a Giant

Famous scientist Isaac Newton is purported to have said to ”stand on the shoulders of giants”. I certainly remember that I gained a lot with the aid of others. In this modern day of age one can learn a vast amount of skills, opinions and trivia via books, forums, blogs, podcasts and social media.

I would look to take to oppertunity to give back to the same community that trained my to become the software craftsman I am today. I do this by playing an active rather than a passive role in the commity. I aspire to give talks about various subjects. I answer questions in forums, I patch bugs in software, create open source projects and I maintain a humble blog.

In my opinion a software craftsman should look out for her fellow guildmembers.

A few months ago I came across Travis CI.

Travis CI describes itself as

A hosted continuous integration service for the open source community.

It integrates with GitHub via post-receive hooks. So everytime you push to your GitHub repository Travis gets notified and will start building and testing your code.

You have to provide a .travis.yml to configure your build. Although you could customize your build in enormous detail, the defaults provided by Travis CI allow you to start using continous integration easily.

The bare minimum for a .travis.yml file is the language keyword. For example, the file below will instruct Travis to build a java project using maven, gradle or ant depending on which files are present. I.e. a pom.xml, build.gradle or build.xml file.

1

language: java

Travis CI supports numerous languages, including Java, Ruby, Erlang, Clojure and Haskell. The lanuguage list is growing. To a look on the documentation page for an up-to-date list.

So consider Travis CI for all your open source build.

Today I started using Octopress. The description of Octopress as found on the homepage is

Octopress is a framework designed by Brandon Mathis for Jekyll, the blog aware static site generator powering Github Pages. To start blogging with Jekyll, you have to write your own HTML templates, CSS, Javascripts and set up your configuration. But with Octopress All of that is already taken care of. Simply clone or fork Octopress, install dependencies and the theme, and you’re set.

Right of the bat you have a fully customizable generated blog when you follow the getting started guide. I used the GitHub pages deployment option and it worked like a charm.

But a word of warning is necessary. The Octopress’ subtitle A blogging framework for hackers is in place. You should be comfortable working your way around the commandline before using Octopress.

As uncle Ben has taught us “With great power comes great responsibility”, the enourmous flexibillity of Octopress comes at a price. Although the defaults of Octopress are fine, you should invest the time to finetune your own blog.

So you can expect the blog to changes it’s appearance while I settle on some design choices.