I’ve been playing minecraft a couple of nights a week for about 40 minutes each time with my son. This seems to be a trend even for very young children. It wasn’t too long before I found myself running a server so that we could play together with our friends (We even setup a trello board for our missions and projects!). It’s much more fun to work together and build something. Discovering new places and building contraptions, houses and other things is very stimulating for a young mind - as well as my old mind. This generation has so much more at their disposal.

Since the 2 teams don’t play very often, it would be nice to get notifications when one goes online so the other can join. The server has a log file that we can inspect. So I came up with this little script that emails the other team when we log in and vice versa. I also made the same for logging off. This is scripting 101, but most people I know are programmers and don’t neccessairly dabble in bash.

tail -F /srv/minecraft-server/server.log | 
  grep --line-buffered 'adymitruk .\* logged in' | 
  while read line
  do 
    echo "Join me if you can." | 
      mail -s "I just logged in to Minecraft" yourfriend@gmail.com 
  done &

The minecraft log makes it easy to take actions according to what happens in the game. A line gets written saying who logged in and who logged out. Tailing this log and then grepping for those lines, we can send an email. Here’s how you can set up your server to send via gmail.

It’s unbelievable the kind of attention something simple can get. I’m still suprised at how many up-votes this answer is getting.

In Git, filtering by author name is easy. Most people simply use the name of the committer that they are interested in. However, it’s a little more powerful due to the fact that the author option on git log is actually interpreted as regex. So for looking for commits by “Adam Dymitruk” it’s easier to just type git log --author="Adam" or use the last name if there more contributors with the same first name.

You can also match on multiple authors by supplying the regex pattern. So to list commits by Jonathan or Adam, you can do this:

git log --author='\(Adam\)\|\(Jon\)'

However it’s tricky to exclude commits by a particular author or set of authors using regular expressions as noted here. Instead, turn to bash and piping you can exclude commits authored by Adam by:

git log --format='%H %an' |  # get a list of all commit hashes followed by the author name
  grep -v Adam |             # match the name but return the lines that *don't* contain the name
  cut -d ' ' -f1 |           # from this extract just the first part of the line which is commit ref
  xargs -n1 git log -1       # call git log from that commit stopped after 1 commit

A limitation of this is that some log options that you would want are not available such as --graph due to the mechanics of calling git log multiple times.

A Few More Details

The cut command is treating spaces as delimiters and is only returning the first field which is the sha1 of the commit.

If you want to exclude commits commited (but not necessarily authored) by Adam, you can replace %an with %cn. This has the same effect as using git log --committer=Adam instead of author in the first example but for exclusions.

Don’t be afraid to split your piped commands onto multiple lines. As long as a line ends with a pipe, bash knows there is more and will prompt for the next line. You can continue to do this until you have written what you want or pasted a multiline snippet from an example online. When you search history, it will be recalled as one line with proper semi-colons inserted if you used while loops or other flow control.

Continuous Tests is Free!

Last week I was lucky enough to present and attend the Norwegian Developer Conference in Oslo. This was a wonderful event with many excellent presentations and post conference get-togethers. The highlight of this conference for me was the announcement that Continuous Tests aka Mighty Moose is now free! If you’ve been keeping up with the conference on twitter, you may have noticed the controversy that the Azure announcement caused. I also didn’t like the use of profanity in the keynote and more mentions of Steve Jobs, but that’s a small part. Aral had me in stitches with all the usability (or there lack of) issues found in our world. My criticism of those 2 things caused Aral to block me on Twitter - I guess some people have thin skin. Don’t let the Azure slip up take away from an excellent conference. Download all the presentations and watch them.

The Dymitruk Model

Following the methodology defined below is the most effective way to leverage the power of Distributed Version Control Systems - specifically Git. This work is the result of an in depth analysis of Continuous Intergration and the notion of responsible Continuous Delivery. The inherent risks that de facto CI and CD introduce are mitigated by what others now refer to as “The Dymitruk Model”.

Features are small

Old-school branch-per-feature meant that branches were large and long living to avoid having to integrate because it was a pain. This was a vicious circle as the feature would diverge further and further from other features or the mainline. Features should be as atomic as possible and your development process should abide by the Open Close Principle. Features should be small.

You can see that the branches have a couple of commits each. We start with the end in mind with failing tests and implement the feature in the following commit. This would be the minimal amount of commits to expect on a typical feature. They won’t typically be that small.

This is the first post using Octopress (I have been editing it though to get some things working). So far it’s awesome. I’ll have more to show soon. Look for:

• Import old posts from adventuresinagile.blogspot.com
• Customize the front page to include my password hasher. My password generator is here.
• Articles and other demo stuff