Showing posts with label events. Show all posts
Showing posts with label events. Show all posts

Sunday, December 06, 2009

A Year Of London Developer Events

Today marks a year since I moved to London from Chicago. So far, my favourite thing about being here is the trains run like clockwork the vibrant software developer community.

Here is a list of events I've attended, all of which I highly recommend:

Monday, August 03, 2009

Open Space Coding Day: TDD As If You Meant It and Cucumber With IronRuby

Saturday I was at the Open Space Coding Day that was part of the Alt.Net UK Conference 2009.

In the morning, I was in the session on TDD As If You Meant It. Gojko Adzic already did a pretty good write up, so I'll point you there to learn more about it: TDD as if you meant it – revisited.

In the afternoon, I was in the session about using Cucumber and RSpec with IronRuby. Mostly, I was interested in this because I keep hearing really good things about Cucumber, but as a non-ruby person, I have never quite discovered what those good things actually look like.

I was also a bit psyched, because I was pretty sure I'd heard that IronRuby was going 1.0 on my birthday. But alas, it seems that article subtly changed since I last looked at it, from saying "IronRuby is 1.0!" to now saying "IronRuby is almost at 1.0!" A slight let-down, but that's okay. We still had a good session, and I'm the first person to understand that software doesn't always magically appear on a certain date just because we want it to.

To install IronRuby, Cucumber, and RSpec, I mostly used these instructions:

The process for me went something like this:
  1. Install Ruby.

  2. Install IronRuby. (The day I was doing this, 0.6 was being billed as the current release. It looks like things have moved on.)

  3. From IronRuby and .NET, do:
    1. Installing required gems
    2. Creating a Cucumber wrapper script for IronRuby
    3. Running the examples

  4. Now the examples ran, but there was some weird escape-character output. I didn't find the answer to how to fix this, but another person in the session, Lorenzo Stoakes , did. Here's how that looked on Twitter.

    For convenience, though, I guess I'll compile that into the single sentence: In your file that corresponds to C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.3.92/lib/cucumber/formatter/ansicolor.rb, replace Term::AnsiColor.coloring = false if... with Term::AnsiColor.coloring = false.

At that point, the examples seemed to sort-of run okay for me. I think Lorenzo and Garry Shutler got past some warnings that were getting output, but I didn't. I'm also pretty sure Garry also got RSpec to work.

What was the whole point? Well, since I didn't get past the examples, I'll sum it up with one of them.

Say you're developing a calculator. Your business person can specify the addition behaviour in text, like this:

Feature: Addition
  In order to avoid silly mistakes
  As a math idiot 
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered  into the calculator
    And I have entered  into the calculator
    When I press add
    Then the result should be  on the screen

  Examples:
    | input_1 | input_2 | output |
    | 20      | 30      | 50     |
    | 2       | 5       | 7      |
    | 0       | 40      | 40     |

And you can make that executable by adding some code in a related code file like this, where you're testing a .NET assembly Calculator.dll that contains a Calculator class in the namespace Demo, and the Calculator class has push and Add methods:

require 'spec/expectations'
$:.unshift(File.dirname(__FILE__) + '/../../lib') # This line is not needed in your own project
require 'Calculator' # Calculator.dll

Before do
  @calc = Demo::Calculator.new # A .NET class in Calculator.dll
end

Given "I have entered $n into the calculator" do |n|
  @calc.push n.to_i
end

When /I press add/ do
  @result = @calc.Add
end

Then /the result should be (.*) on the screen/ do |result|
  @result.should == result.to_i
end

That does look pretty sweet.

Monday, May 04, 2009

Notes from Gojko Adzic's "What is FitNesse and Should I Use It?"

Last week, I went to What is FitNesse and Should I Use It? by Gojko Adzic.

I was struck by the difference between two of his slides:

And a slide from a different talk about FitNesse that I'd attended a week earlier:

To be fair, Gojko said that it's very easy to hook lots of different kinds of testing into FitNesse, and he had been as guilty of it as anyone else.

Here are a couple other good things I picked up from Gojko's presentation that I hope to put to use:

  • Focus on "what" and not "how". Don't try to translate test scripts into FitNesse—that's "how" and can lead to having a lot of similar or duplicated setup code. In fact, if you find yourself writing many similar tests, you're probably focusing too much on "how".

  • To keep your tests as living documentation, separate them into to main categories: tests for the current release and tests for previous releases organized by feature. At the end of each release, move the tests from that release into the other category.

Friday, April 24, 2009

Notes from ThoughtWorks London Geek Night: Startups That Innovate

Last night I went to the ThoughtWorks London Geek Night "Startups That Innovate". I know there are some people who wanted to go who couldn't because there wasn't enough space, so I'm going to share what I remember. And I aplogise for everything I remember wrong.

The first two speakers were Giles Thomas and Jonathan Hartley from Resolver Systems, who talked about founding Resolver and the technologies they use. Here's what I remember:

  • To get your startup going, you need people who can fill three essential roles: (1) Technologist/Developer (2) Rainmaker (3) User Advocate.
  • They use IronPython and it works well for them. At first, they picked it because it looked like a good language for rapid prototyping. When it came time to switch over to a "real" programming language, they decided that they liked IronPython so much that they wanted to keep using it.
  • They use PyUnit for unit testing. Some people in the audience thought PyUnit might not be mature enough, but Giles and Jonathan said they were able to make it work.
  • They use an internal Python-based DSL to automate acceptance tests.
  • They are an XP shop.
  • Developers really do pair program pretty much all the time, except for spikes.
  • With pair programming, it's true that you don't get as much of a flow experience as you would programming alone, but it still seems to work pretty well.
  • As an XP shop, they try to keep their working hours sustainable. That might be different from what you see in other startups.
  • One lesson they learned was: Don't go into stealth mode—it would have been useful to get user and community feedback earlier.
  • Another lesson they learned: Release earlier. It took them around 2 years to release v1.0, and again, it would have been useful to get user and community feedback earlier
  • Interns are a great resource for startups.
  • (Jonathan used vi instead of PowerPoint to present his talk, which was cool.)

The last speaker was Martin Dittus from Last.fm. Here's what I remember:

  • Last.fm started to having trouble scaling all of the updating of data that results from scrobbling. They realized that they didn't need to do it in real time and switched to batch mode.
  • They are using Hadoop to do this.
  • One of their interns, Klaas Bosteels, wrote Dumbo to help make working with Hadoop easier.
  • As a startup, they had trouble affording Business Intelligence tools, so they built them themselves.

I'm not very good at tweeting events, but some other people did better: London Geek Night tweets.

Also, I saw a list of upcoming ThoughtWorks Geek Nights while I was there. I think there were three in May and one in June. Here are links to the ones I could find links to:

Tuesday, March 31, 2009

Looking Forward to Alt.Net London Beers Tonight

I'm looking forward to attending Alt.Net London Beers tonight to see what social gaffe I can commit next. My favorite from last time was when someone asked me if I "was you-switch" and I looked at them blankly, wondering what they could possibly mean. In retrospect, I knew that there were several developers there from uSwitch, and I was just being asked if I was one of them. But at the time, I completely forgot, and the best my mind could turn the question into was something like... "Do you use switch statements? Because you know, in the OO-world, that's not cool." My secret is that I probably have used switch statements in the past year. But I didn't like it. Really.

Seriously, though. It's a good event. I made it to the last two, where we discussed Robert C. "Uncle Bob" Martin's SOLID Principles and "avoiding the big rewrite," including ideas from Michael Feathers' book Working Effectively With Legacy Code.