Using the Game Of Life to code, discuss language, paradigms and approaches

Session Style

Open/Community

Session Length

60 mins

Session Description

I’d like to use the GameOfLife as a background theme to do a dojo with coding in pairs (test drive it through functional tests via stdin/stdout), discussion of different approaches and of the suitability of different languages and programming paradigms.

As I enjoy coding those GoL implementations I’d be happy to share this fun with you.

My session proposal revolves around two things:- It seems quite common for the terms ‘mock’ and ‘stub’ to used incorrectly while talking about testing software, even though both are quite easy to define.- It’s also surprisingly easy to implement a class in Ruby that will act as a simple mocker and stubber, provided you have some idea about meta programming.With these two things in mind, I’ve written a set of koans that will describe what it is to be a mock and what it is to be a stub using Ruby and the Cucumber BDD framework for Software Craftsmanship 2010.

These koans describe the behaviour of each, but the process of completing them will mean that you end up with a class that can perform some basic mocking and stubbing of it’s own.

There are about forty steps involved in the koans and, although most steps are pretty straightforward, thirty minutes is going to be quite a challenging time frame to complete them in. So I’d encourage people to pair up or form small teams in order to get to the end.

On the day, I’ll give a quick intro along with Github clone URL and then just mill around to help out with questions that people have. There will also be a brief summing up at the end.

I’m only going to be able to do the session in ‘Ruby flavour’ I’m afraid, as I’m not familiar with the meta programming features of any other languages.

As programmers it’s easy for us to ignore the more aesthetic elements of the work we do and focus purely on the code. We can often fall into the trap of letting others worry about how well our user interfaces work for the end users, rather than putting the time into thinking about how to design the user experience.

This session will focus on the fact that coding cleanly is actually an exercise in good User Experience, and that the skills we acquire whilst getting better at coding well are directly applicable to thinking about our end users use our systems.

As part of the session we will take a piece of obfuscated code with a very bad user experience. Guided by tests, we will refactor the code so that it’s as good an experience as possible for others to use.

Depending on numbers we will either run the practical elements of the session in a Randori style (everyone takes turns to code with their actions being projected) or as a competition: “who can produce the cleanest most readable code in the time available?” We will then look at lessons learnt from the exercise and how we can apply them to our end customers.

Session requirements (technical)

You will need a basic working knowledge of ruby to participate in the refactoring exercise. If you have it available, please bring a laptop with ruby and rspec installed to run the code.

Project Usus is an open source craftsmanship tool. It can easily be customized. In the session, we will introduce the background needed to perform this task. Also, we will implement an example customization. Participants are encouraged to implement their own customizations together with us.

Session requirements (technical)

Java-Eclipse with the Project Usus plugin installed.
Bonus: Source code of Project Usus checked out in a workspace.Downloads at http://www.projectusus.org

Being able to use an editor fluently is an important part of being mastering creating programs. We spend most of our days using a text editor yet how much time to we spend practicing it?

I’ve noticed from watching people who are very capable with certain editors that the use of the editor becomes second nature and moves away from thinking about what keys need to be pressed and moves toward simply playing the editor like an instrument. Achieving this requires training in muscle memory so that actions can simply happen without having to consciously think about them.

I have taken inspiration from kata in martial arts and will present a few kata for vim. The kata will incorporate some of the basics (movement, changing modes) and some slightly more advanced things (motions, for instance). The participants will perform each kata several times. Afterward I would welcome feedback on the kata and the value of the exercise.

Players write code and tests completely inside a custom web-browser. Players rotate every few minutes and success is when _all_ laptops have a working solution. Players also score points based on laptops being _collectively_ at green. The best way to understand it, as always, is to experience it. Which you can do at http://www.cyber-dojo.com The most important thing to realize is that it is a COLLABORATIVE code-dojo. If there are 10 laptops and 20 players then the game strongly encourages all players to work together, collaboratively, beyond the unit of the individual laptop and the individual code-base.

Session requirements (technical)

Power for the laptops. That’s it. I will setup a wireless network to connect to the CyberDojo server.

The vimeo is an earlier version of CyberDojo. A CyberDojo server is online at http://www.cyber-dojo.com if you wish to see the latest version. There is a chance I won’t actually be able to make the day! If that’s the case you could of course still use the online CyberDojo server if you wish. Good luck.

We’ll start with an application a craftsman would have reasons not to be proud of: there’s no exception handling, expensive database operations are performed from the GUI thread, the view is not synchronized with the model, there’s no undo/redo system… All these things are usally terribly boring to implement. But AOP makes it fun: we’ll see how to encapsulate these infrastructure concerns into classes named “aspects” so that we don’t have to write boiler-plate code again.

Session requirements (technical)

No requirement. Folks wanting to practice at home after the tutorial will need any .NET/Mono environment.

Full disclosure: the demonstration is done using PostSharp, a commercial product and will be given by its main developer, a geek who coded his first program at age of 12 ;). The session is about showing a programming approach and not a specific AOP toolkit, so there will be a lot of takeaways for other languages as well.
License keys will be made available for the audience if someone wants to try at home.

As agile software craftspeople, we aspire to early and continuous delivery of valuable software.This hands-on session will test how well you can meet that goal by challenging you to code a simple robot that will have to compete in a series of battles.

You can continue to refine and upgrade your robot though the tournament. The earlier you release your robot, the sooner you will win some battles and start accruing points.This is a great chance to have some fun showing off your coding skills as well as your project management strategies.The audience should form themselves into pairs or small teams.

The session will take three parts. We’ll start with a warm-up, giving participants a chance to spike the technology and process they’ll need to follow to compete in the tournament itself.

This will include writing a simple command-line program in the supported* language of their choice, and copying it onto the tournament server.

Once we’re confident everyone has reached this point and all the technical issues have been ironed out, then the tournament will begin. We will explain the rules of battle (a simple board-game which everyone will know) and the tournament format.

Then we say ‘go!’ and at every 10-minute interval after that, a battle will take place on the tournament server, between whichever team’s robots are ready.

We’ll provide a couple of seed robots to play in the tournament – modest (or quite useless!) players who will give our teams someone to compete with.

Points will be accrued for any wins in each battle, thus rewarding teams who submit simple solutions early, rather than obsessing over the perfect player before releasing anything.

* we’ll do our best to run anything that can run on Ubuntu linux

Session requirements (technical)

Competence in a programming language that will run on a linux system (e.g. python, perl, ruby, haskell, java, clojure, erlang, C# (under mono)Audience should bring a laptop which can connect to the conference networkAudience will find the session much easier with ‘curl’ and ‘zip’ command-line tools installed.

Similarly to other people here, this was my first ever screencast. Please don’t confuse a crap screencast with a crap session.I’d particularly appreciate feedback on how well the screencast sells the session (particularly if you’ve participated in it before, e.g. at SPA2010), so that I can do another iteration of the screencast.

The idea is to share refactoring tricks with an element of competition.We’ll give people a starting point of some code that needs refactoring, and an endpoint of the code after refactoring (the point is emphatically NOT to criticise our choice of endpoint).

People then have to get from start to finish with as few refactoring moves as possible. There will be penalties for unsafe moves (that don’t preserve the code’s behaviour). The lowest score will then present to the group, then we’ll try another challenge.

We’ll work in Java but hopefully the lessons will translate to other languages.