Monthly Archives: March 2013

Blogging with Markdown

I was introduced to Markdown by GitHub a couple of years ago and instantly found it to be a very friendly method of formatting a document. A veteran of a number of Wiki markup styles I’ve managed to whittle the list down to two: Confluence style which is used at work, and Markdown, which I try and use everywhere else. The exception was blog posts.

Although I have the WordPress app on my iDevices (which are able to connect to the internet via a mobile signal) I find myself writing most of my posts on my laptop on the train – good though the iOS keyboard is, it just cannot compete with a real keyboard. Being a geek I write the posts in plain text and just do the markup by hand. This is a bit of a pain. This morning, while drafting a post I found myself copying text formatted using Markdown and redoing the formatting in HTML. After the second line I stopped, Googled “markdown editors for WordPress” on my iPad and shortly after arriving in the office had Markdown on Save Improved installed. I can now draft posts offline in Markdown using TextMate which, I discovered to my great joy the other day, supports Markdown formatting and rendering.

Incidentally the reference method of creating links really helps when writing offline as you can sprinkle the anchors in your text as you write, jot an empty reference at the bottom of your text and then add the URLs when you have internet access.

Replacing our Git branching strategy

The branching strategy we use at work is one that has evolved from us tentatively learning how Git works, reacting to our mistakes and avoiding the problems that have arisen. I have, on more than one occasion, had to rebuilt the history due to errant merges going into master. Mistakes can also happen resulting in contamination of release branches, or failure to update all required branches, including master. While it works for us, the fact that it can occasionally bite us on the bum, and the fact that I’m having difficulty documenting why we do what we do both point to the conclusion that the strategy is flawed. So I’m binning it, although not until I have a working alternative that we’re happy with.

Key to this new strategy will be how changes are reapplied back to the main and release branches. Rather than simply taking peoples word for why you should or shouldn’t be doing merges or rebases in Git I’ve gone right back to basics and made sure I fully understand what is going on when you merge or rebase and what the implications are – to the point of setting up parallel git repositories and testing the same operations with different strategies on each.

Secondly I need to look at putting branches back on origin. Being distributed can make git a pain in the backside for some things and sometimes you really do just need one place to go look for data. A prime example is Fisheye/Crucible which we use for viewing our git repositories and performing code reviews. Since our JIRA workflow looks to Fisheye/Crucible for information about code changes and code reviews we push all branches to origin. Would a move to Stash remove this need?

Thirdly is our habit of keeping all branches. This leads to a lot of clutter and may or may not be related to the first two points; I’ll need to do more investigation on that front, however, I suspect I’ll be able to greatly reduce the number of branches we have.

What I suspect we’ll end up with is a strategy where most branches are taken from master, with master being rebased back into the branch before the branch is merged into master and then deleted. Release branches will also be taken from master as needed. Fixes to release branches will be branched from the release branch, the release branch rebased back in when work is done, and then the fix merged into the release branch. The release branch will then be merged back into master. At some point the release will be tagged and deleted. Pull requests using Stash will hopefully obviate the need to push feature branches to origin. How well that plan survives contact with reality I don’t know.

Revisiting Git

I first discovered Vincent Driessen’s branching model¬†when I was investigating Git a couple of years ago. At the time I was desperate to get away from the merge issues that we were having with Subversion and was looking into both Git, and different branching models using it. Given the steep learning curve with Git we decided not to complicate things further and to stick with our old branching model; albeit with a slight change in naming convention borrowed from Vincent.

Now I’m a little more comfortable with Git it’s time to revisit our branching strategy, and use of Git overall. I’ve looked at Vincent’s branching model again, and looked at git-flow in great depth and have concluded it’s still not for us, however, the idea of codifying the workflow, and providing git extensions to aid using the workflow appealed to me immensely.

Currently we’re doing little more than branching off master for issues, with each issue (be it a new feature, or bug fix) living in its own branch. Issues are rebased into master when they’re done. Releases are also cut from master and any patches (either to the release version in QA, or to the release version in live) are cut from the release branch, rebased into that and then rebased into master.

In order to simplify our JIRA and Fisheye/Crucible setup we also push issue branches to origin making them visible from a central point, as well as providing a backup. These branches are considered private and not used by others.

Since we have tight control over all the branches a rebase only strategy works fine for our team, although we have had some problems caused by accidental merges. The next step is to improve the workflow and the merge/rebase strategies to survive all situations, codify these steps and then script them – something I’ve already started doing.

I’m also looking at this as a potential opportunity to possibly move away from Fisheye and Crucible to Stash, potentially saving some money whilst keeping the tight JIRA integration.

Interviews

Interviewing effectively is a hard skill to master. Not only do you need to work out if the person being interviewed can do the job, but also if they’ll be the best out of all the candidates and if they’ll fit in to the team dynamic. All this in a very finite space of time. You’re not going to manage that if you just ask a few questions you’ve downloaded from the web.

I’m unashamedly evil when it comes to interviews. Once the niceties are over you’re going to find yourself face to face with my laptop and a copy of Eclipse. What happens over the next 45 minutes or so is entirely down to you.

This method of trial by fire is something I’ve endured a number of times, and every time I’ve hated it. You’re in the spotlight, you’re under pressure and you’ve got someone questioning everything you do. I recognised very quickly that this is a very powerful interview tool because it leaves you wide open and quickly cuts through any front.

What I ask you to write (which, incidentally, will be decided based on the preamble, the telephone interview if there was one, and your CV) is pretty much irrelevant, as is whether you finish it. The discussion and discovery that happens in the time is what counts. I’ll probe as many subjects as I can, dropping them as soon as I’ve determined if you’re strong or weak in that area. All of this on a platform you may not be familiar with because I use OSX.

You can use the internet because it’s not about what you can remember, it’s about how you apply knowledge; you can ask questions – in fact failure to ask any questions will probably have you flunking the interview; you can say you don’t know, we’ll move on – it is actually OK not to know every tiny thing I question you on.

It’s brutal, I know. I’ve been there. You’re constantly off guard, the goal posts keep moving, the questions keep coming and during all that someone is expecting you to code at the same time. Do well in that and the job itself will be a cakewalk. But hey, if you’ve made it to the interview then I obviously think your CV matches what I’m looking for, so you shouldn’t have a problem ūüėČ

Job Specs and CVs

Job specs annoy me. There seems to be a standard formula which contains a number of canned phrases that are absolutely pointless to certain job types; especially those I’d be applying for, or, as I am currently, advertising for. These are some snippets I’ve pulled from a similar job advert on the internet:

“Strong Analytical capabilities”

It’s a java development role. Strong analytical capabilities should be a given. I could understand it if you were advertising for a role that paid below ¬£20K, but there are certain things that you can start assuming one you get into the realms of higher paying jobs.

“A thorough attention to detail”

I’m actually hard pressed to think of an employer who wouldn’t want that.

“Presentable and organized” [sic]

Coming, as that did, after “A thorough attention to detail” you have to love the irony in the use of the American spelling in a British job advertisement.

This isn’t just a one off either. Most job adverts are like this, and when they’ve dispensed with the banal and pointless buzzwords there comes the smorgasbord of required skills. This is usually just a list of all the technology in use without proper consideration to if it’s actually required. It also tends to bear no relation to the salary on offer and, worse still, adverts these days have the wonderfully vague ¬£competitive or ¬£negotiable. In effect, most job specs say the following:

“Wanted, one development guru willing to work on junior wages. Social skills desirable.”

Norwich is not a hotbed of Java shops, so it’s understandably light on Java developers. Restricting myself with a “standard” job spec would just further limit my options. Instead, lets focus on what I really want, in the order I want it: a developer who in an A player, who has a voracious appetite for learning about new things, and who has good working knowledge of Java. That’s it, everything else is a bonus because with that base they can learn everything they need quickly, and lets face it, it’s rare that you can just walk into a new job without having to learn something.

WebLogic? We use it, but I’ve got step by step instructions on how to use that so even a non technical person should be able to cope with the amount of WebLogic knowledge that’s required. Oracle? Provided you can string together some SQL for at least one database you’ll probably be fine. JSPs, Servlets, Hibernate, Spring, JUnit, TDD, BDD, Ant, Maven, Eclipse? Yes, all lovely to have, and the more experience the better, but I don’t want to prevent an otherwise excellent developer from applying just because I’ve done the shotgun approach to skills. I’ll list them, but just so you can make the bits of your CV that include the relevant skills shine.

You’ll also note I’ve not listed how many years experience with Java I want. I’ve never thought was productive. I’ve known people with just a few months of experience in a language produce far superior code to people with several years experience. The last person I hired was technically an ActionScript developer with some Java knowledge. They were an excellent find. I’d rather take an enthusiastic, bright and eager junior developer who will grow over the years than an experienced developer who is now resting on their laurels. This is software development; evolve or die.

Degree? I don’t have one. They’re useful when getting into the job market, but once you’ve got a few years experience under your belt they become less of an issue. Mandating one is just another way of artificially limiting the¬†available¬†pool of candidates for no good reason.

This doesn’t mean I’ll take anyone though. Your CV has to convince me you’re an A player. It has to tell me you’ve got the appetite for learning that I want. It needs to show me that you’ll grow in your role. Sadly in todays world of keyword matching not many CVs do that.

BDD inline questions

I’ve started using BDD scenarios for most things now as I find the Given/When/Then syntax great for focusing on the problem and generating questions. What I have found though is that often the questions need to be written down somewhere to ask the relevant person. Correlating the questions and the scenarios can be a pain so I’ve started putting them inline into my scenario text using a ?? notation. The format is simple:

  • ?? on it’s own: denotes an outstanding question about the preceding text.
  • word??: denotes a question about the preceding¬†word.
  • ?option/option?: denotes uncertainty about which option should be used.
  • ?question?: denotes a question being asked.

This syntax can actually be used to write the original scenario:

Given ??
When ??
Then ?? should ??

An example of this usage might be:

Given a user on a web?? form
When the user ?enters/selects? ?should we be thinking about how the provides the data? their D.O.B.
Then the form should ??

A discussion, which could be via email or some other means than face to face, can than be had to resolve the questions using just the scenario files and the annotations to the scenarios. You could even go one step further and use something like Gollum to track the changes to the scenarios.

Always read the small print

I spent a fair few hours this weekend perusing Shutterstock for images for an idea that a friend and I are looking into. Since we were setting up an LLP I figured I could go grab something suitable to use as a logo for a few quid and use it to set up the website, among other things. The search was going well until it came to purchasing the image I’d settled on. Unsure as to which license I’d need I delved into the small print. What I discovered was rather upsetting: you can’t use Shutterstock images for logos or trademarks. In fact there are a number of restrictions on how the images can be used, some of which had me checking I wasn’t breaching the terms of the license on other images I’d previously purchased. In the end I resorted to spending a little more than I had initially hoped and got a professional to do a logo for me. I’m working on the premiss that they’ll do a much better job and we’re not leaving ourselves open for legal issues later down the line. On the plus side I did at least have a collection of images to use as a “mood board” for the new logo. Just goes to show that its always worth reading any licenses you’re signing up to.

Tumbler and low level stories

I’ve run into a bit of a brick wall with Tumbler in so far as I think I’m using it at far too low a level. I’ve got a fairly simple object at the moment, little more than a bean, which I’m using as a working example to try these new techniques out. While my first story and group of scenarios were easy to write I started running into issues with the second group. The issues are twofold. Firstly I’m having to learn to rethink how I group my tests to fit into stories and scenarios. While working this through I started butting into problems with long class and method names which I can’t really shorten as there will, eventually, be literally hundreds of tests and I need to be able to distinguish between them.

After fiddling about with different ways of framing the stories and scenarios I discovered that its annotations aren’t picked up by the JUnit plugin for Eclipse so I can’t rely on them to make readable tests, I have to use readable class and method names.

Then, I discovered that Tumbler isn’t hierarchical. Stories are listed on the index page, then you can drill down into a story and see it’s scenarios. That’s it. If I had 100 stories I’d have to wade through all of them on the front page. What I need is epics.

This all rather makes sense for a tool that’s going to be used at a higher level, detailing 20 or 30 user stories that constitute an application, but I want the ability to test at different levels. After all, as I understand it, BDD can be considered fractal in its nature and is as easily applied to a users interaction with a save dialog box as it is to the save method call on some object somewhere. Yes, the players change, and yes the granularity and precision of the inputs and outputs change, but it’s the same fundamental thought process when developing the tests.

In order to shed some light on the issue I tool a look at the Tumbler source, specifically the test cases, but they were all at the user level. Tumbler itself isn’t that complicated a program so it may be that these user stories suffice for testing the majority of the code, but I want to know at an object level that they do what they say on the tin.

Sadly, the majority of this discovery has been performed on the train with its connectivity issues so performing research into alternative tools is proving hard. That said, given Tumbler isn’t massively complex I may just put my current project to one side, fork that and get it to work at both the low and high levels. In the mean time it seems like I need to do more research.

Rise Of The Machines

Last night I attended An Evening Of Game A.I., a talk given by Alastair Aitchison, for the Norfolk Independent Game Developers group. My aim was to learn some new stuff (A.I. has always been a subject that I wish I knew more about) and possibly come away with a few techniques I could use in my own code. I’m glad to say that both goals were achieved.

The night started with a brief introduction from everyone (“Hi, I’m Dom Davis and I’m a WoWoholic, I’ve been clean now for 5 years”) and then launched straight into movement algorithms. A little bit of physics and some fun demos brought each of the strategies to life and, while not useful for any applications I was thinking of, it was very interesting. Similarly the section on pathfinding, while brilliant from a personal interest point of view, lacks much practical application in what I have in mind.

There was discussion on and demos of decision trees and state machines. These are both topics I know something about, although I never got the chance to ask if people used off the shelf FSM’s or not. Despite their simplicity and the profusion of if blocks it did remind me that decision trees have their place.

Utility curves is where it started getting really interesting. It’s a technique I’d never really explored before and its simplicity appealed to me. As I tweeted at the time, I’m sure I’ll get lots of utility out of utility curves.

From there it got fascinating with a quick discussion of neural nets, something I think I can make use of. I’m not sure I’ve ever been involved in the training of a neural net before, but now I can safely say that I have. I can see me and Google spending a lot of time on this subject.

Sadly I had to leave half way through the discussion on genetic algorithms. This is something I’ve done some reading about before and I’m absolutely amazed by them in a “I have absolutely no idea how to create, code or apply them” type way. I have a few ideas which may or may not be practical, but could produce some very interesting or amusing results. The group were left seeing if a little lander would evolve to land on a landing pad. As I was leaving they were getting close, so who knows.

The demos and videos of bloopers from big budget games made for a great talk and Alastair had a way of presenting some quite complex material in a fun and accessible way. I just wish I could have stayed later to pin him down and go into excruciating detail on some of the topics. Not doubt I’ll be revisiting some of these subjects in more depth in later posts as I explore them further.