Sunday, January 16, 2011

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.

Saturday, January 15, 2011

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!