Sunday, 15 December 2013

Global Day of Code Retreat 2013

Have you heard of Coderetreats? I hadn’t until a couple of weeks ago, when a friend of mine prompted me to try one. From the About page:

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of ‘getting things done’, the coderetreat format has proven itself to be a highly effective means of skill improvement. Practising the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.

I signed up for the Global Day of Coderetreat session and then promptly forgot about it until yesterday, when I realised that I was going to regret my 0600-1200 sleeping pattern today. (Other than making it difficult to interact with normal people, however, it’s awesome.)

Despite my lack of sleep I dragged myself to the depths of Shoreditch where Unruly Media, our hosts for the day, make their home.

To summarise the format, the day is broken up into multiple 45 minute sessions. All sessions revolve around pair programming a solution to Conway’s Game of Life. There is a preference for using test driven development, and a hard rule that all code must be deleted at the end of each 45 minute session.

We rotated pairing partners throughout the day, and there were no language restrictions other than the basic sanity check of “at least one of the pair should be comfortable with the language you’re using”. I only wrote in Python and Go, since my recent programming experience is limited to those languages, but people worked in Java, Javascript, Haskell and (I think) a couple of other languages as well.

In addition to the basic rules, some of the iterations had constraints placed on them, in order to stimulate thought about the problem domain or just for the entertainment of the facilitators. (Mute immutability springs to mind. :P)

Was it worth it? I certainly think so. A day of practice with no pressure to deliver useful code to a customer was very refreshing; I felt it enabled me to think about the actual problem being solved as well as the various approaches that could be taken. The enforced deletion of code as well as changing pairing partners during the day lead me down several different tracks of how to solve this problem.

The day was concluded with a wrap up, where everyone was asked three questions:

  1. What, if anything, surprised you today?
  2. What, if anything, did you learn today?
  3. What, if anything, will you do differently in the future?

Speaking for myself:

I was surprised at how effective pair programming is. This was my first experience with it, and I was expecting it to be stifling (having to wait for other people, not using my own development environment). It transpired that these worries were largely unfounded (Alex’s shocking vim skills not withstanding; he has been directed to the appropriate learning resources). Having someone to bounce ideas off meant that at no point did I ever get stuck; if I got to a point where I wasn’t sure what to code next, my partner generally had a concrete suggestion. If neither of us were quite sure how to progress, 30 to 60 seconds of chat usually resolved this and we were back to making forward progress.

In terms of learning: I think for me, the biggest lessons were simply in collaborative coding. As a network engineer, most of my coding since leaving university has been knocking together code that just about works to solve specific problems, with a couple of exceptions where I’ve worked with full time developers on specific projects.

Things I’ll do differently: I will try and pair program more, when given the opportunity; today has definitely given me an appreciation for its benefits. It also brought home the real benefits of test driven development; one of the exercises had the stipulation that one partner wrote the test code, and the other partner the implementation. This turned out to be a good way of forcing clarity of requirements, and having the tests in place gave me much greater confidence when making changes, which was particularly important given the time pressure.

Overall a very enjoyable and productive day; for those looking to practice the art of programming, you could certainly do worse than attending a code retreat. Many thanks to Rachel Davies for organising the event and keeping us fed and watered, and to Steve Tooke for facilitating. I look forward to next year.

Written with StackEdit.

Tuesday, 3 December 2013

tmux and vim for Scheme development

I’m currently working my way through Structure and Interpretation of Computer Programs, as a lot of people I know speak very highly of it as a text on the craft of programming.

It uses the Scheme programming language, a dialect of Lisp. Most tools for developing in Lisp and Scheme (e.g. SLIME) are based around the emacs text editor. Without going down the rabbit hole, suffice it to say that I’m a vim user, and wanted an alternative.

My first thought was to use slimv.vim, which apparently provides vim users with similar functionality to SLIME. Unfortunately, my attempts to get slimv.vim to play nice with mit-scheme on OSX lead to frustration; I may revisit that at a later date, but in the mean time, I needed to get something working.

Enter tmux. tmux is a terminal multiplexer in the vein of GNU screen. One of its main benefits over screen is that almost every action in tmux is scriptable via the command line, which lends itself nicely to automation and integration with other programs.

For example, we can load the contents of a file into a tmux paste buffer…

$ tmux loadb <filename>

… and then paste the contents of a paste buffer into a specific pane in tmux.

$ tmux pasteb [-t [<session>:]window[.<pane>]]

If a target isn’t specified, the currently active pane is used. Windows can be specified by name or by number.

To create a new pane:

$ tmux splitw [-h] [cmd args...]

(The -h creates a side-by-side split; by default, tmux splits are stacked vertically.)

Finally, we can create a mapping in vim, which saves the current file and then shells out to tmux, reads in the contents of the current file, and pastes it into a target pane.

:map ,t :w \| !tmux loadb % && tmux pasteb -t 0.1

I can now have a scheme REPL side-by-side with my editor, and whenever I hit ,t my code will be saved and run through the REPL.

A quick screencast to demonstrate:

Written with StackEdit.

Network notes

As mentioned previously, my good intentions to blog as I learned interesting stuff didn't survive contact with my new employer.

Now that I'm unemployed, I'm going to be writing more frequently here; the main intention is for this to be a memory aid, but if other people find this stuff interesting, so be it.

First up: in preparation for my Google interviews, I put together some revision notes on some fundamentals of networking, which may be of more general use. You can find them on my Github page: