Help I'm a Windows developer get me out of here! (Or The Escape from Vim)

Git is a great product. When we thought the problem of source control had been solved, Linus Torvalds came up and looked at the problem and made a superior product to the tools I had began to take for granted. However Linus didn't design Git with windows developers in mind. We are used to rich user interfaces where as Git's command line interface is where its strength lies. In fact Gitk (the GUI client for Git) is an abomination and I suspect a major reason for Git's adoption rate to not be much higher. I use msysgit through the Bash shell and everything is rosey, normally. Sometimes I get myself into a pickle.

Git is fussy, you have to commit with a message. I usually use the message flag (git commit -m "commit message") so I don't have to drop into the frankly alien Vim. On occasion I forget so I thought I'd document how to get out of it.

tl:dr - just get me out of here!

You start of in a screen with lots of garish colours and it seems that none of your keystrokes do anything. Even typing sensible stuff like 'quit' or 'exit' just doesn't work! No doubt you are completely exasperated. What's happened is that Git has started the Vim editor and you are in COMMAND mode. Yes Vim doesn't let you edit straight away. You have to tell it too. What you want is to put Vim into INSERT mode. This will allow you to start editing.

Press i to enter INSERT mode, You can tell you are in INSERT mode by two thing. Firstly you will see -- INSERT -- in the bottom left of the console window and secondly when you depress an alphanumeric key the value will actually appear in the editor! You can now use the keyboard to type the commit message.

When you have finished the message you then will want to either save the message or abandon you changes. To do this you need to re-enter COMMAND mode. Press ESC to do this.


To save changes Unix people have made it simple for us Windows types. On a QUERTY keyboard you simply press the key above S, for save. Its obvious! But before you do that just press the colon key. So that's :w to save. In reality you will just want to save and exit at the same time. Again to exit you use simply use the key that's two to the left, the q key. So you can either chain the Save and Exit :wq or just Exit :q.

Summary

So there you have it. To escape Vim and commit your changes do the following.

1. press i to enter insert mode 
2. write commit message
3. press ESC to return to command mode
4. type :wq to save and quit (think write and quit) OR just quit :!q

Hope this helps someone.

Xp Man XL

I think it was probably 5 years ago that I read Kent Beck's XP explained. The book had a profound effect on me, not because there was anything radical but more the fact that the ideas contained just seemed to resonate with me. 5 years have passed and Extreme Programming kind of went off the radar. When people thought of Agile then generally meant Scrum and many of the practices I associated with XP were deemed superfluous or perhaps too extreme.

However over the last 7 months or so Manchester has started its own XP group and I believe that interest is growing again. As well as monthly meetings at the ever accommodating MadLab, the group organises short guerilla coding dojos and today we had a code retreat, an extra large XP Manchester if you will.

The day was split in to 2 halves. In the morning we had 3 sessions of Conway's Game of Life and in the afternoon we tackled 3 sessions for the CheckOut kata. Time passed surprisingly quickly and both sessions were interesting. The group dynamic was mainly .Net developers, then Python, a Ruby dev and a Java dev.

Conway's Game of Life is a simple simulation of cellular generation. Cell lifetimes are governed by simple rules and so the problem lends itself easily to any language. The group was split into pairs and tasked with finishing the problem. We then swapped pairs and started the problem again, encouraged to approach the problem in a different way. I worked with C# & MsTest, then C#/MSpec, then Python and its unit test framework.

What I took from the retrospectives was the diversity of the approaches to the relatively simple problem. Whereas other groups kept on thinking in terms of grids and cells, my pairs concentrated on the behaviour. Some groups gave cells a tolerance, there were different state models. It just goes to show how we interpret language differently.

The afternoon CheckOut kata sessions were done in a different way. We had one session to finish the kata, one to refuctor and we were supposedly going to have a third to refactor it back. Fortunately we didn't have chance to do the third session and there were some great examples of terrible code that I certainly didn't want to touch with a barge pole.

Refuctoring is the process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anybody except yourself. Comprehensive regression testing guarantees that nobody will be any the wiser.   

Surprisingly it was difficult to deliberately write bad code intentionally. (yes I said intentionally) However once you got going it was a lot of fun. I worked with Mark Kirschstein and we had fun with xml, huge switch statements, dead code and much more. The stand out worst involved an ascii Dr. Spock and some brilliant Linq abuse.

The day was lots of fun and great to see some python written by a python developer. The group is full of people who love their trade and its a pleasure to write code with them. These events just give so much. Unless you are lucky its rare that get to work with developers that are willing to improve and share their skills. If you are interested in attending or contributing a session in the future please join the google group or follow the blog.

Thanks to everyone involved today!

A Codefession

"Forgive me Father for I have sinned, It has been 3 iterations since my last confession."

I was brought up a Catholic and one part of being a Catholic is Confession. It's great! You do a load of bad stuff (sin), tell a priest,  he gives you a penance and then he absolves you.
Now that the slate is clean, you can do loads of bad stuff again until your next confession. (I think that's how it works).

When coding, I'm a good boy. I've read the various gospels. I even try and write my code so I don't give in to temptation. And, oh boy, there is temptation. The devil manifests himself in many ways.

There's the temptation to hack it together because you're going to fix it later. The devil knows this will never happen. The devil can be in the form of a looming deadline. You're under pressure and so your good intentions go straight out the window. The devil can be that you are working in an area or language that you are unfamiliar with.

Well I let the devil into my life the other day, I'm ashamed to tell you Father, I sinned. I wrote a real bit of untested, hacky code the other day. Just thinking about it makes me feel guilty. I fixed a defect but at the same time made that bit of code a little bit less maintainable. I broke the boy scout rule.

Ok...lets drop the metaphor. Programmer writes crap code under duress. Is this acceptable? Well, it depends. In an ideal world all my code would be written like an angry Agile Alliance was stood behind me with baseball bat but we all deviate from time to time, even Saint Corey! I think the most important lesson is to understand the reasons why you have strayed.

Be honest with yourself, why did this happen? What can you do to prevent this happening again? I've done my own retrospective, I guess this blog post is part of it. I know what went wrong and I hope I'll recognise the signs that it will happen again. And when I see those signs I hope I can do what I can to mitigate the circumstances that force me to right it.

I've pulled this into the sprint reviews too. When I've not achieved what I set out too, I want find the root cause. We've not being doing this and I've no idea why. After all, Scrum is not going to solve your problems, it’s just going to make them in-your-face obvious, every day. I've been thinking about XP values recently too. Without courage and communication and to a certain extent feedback we are setting ourselves up for a failure.

In the talk by Software Craftsmanship, Beyond The Hype, Corey Haines talks about when you have to get stuff done quickly you drop back to the skills you find instinctive. It takes time to learn techniques (such as TDD). Its a natural process. That's why practice and honing your technique are important and that's why just coding in work time doesn't give you the time and space to perfect your skills.

Ok metaphor back on.

Father: My child before I absolve you this is your penance. Say 20 Hail Ruby's and do 10 Our Katas.
Me: Thank you Father, see you next week!