Book now

Ruby Programming

Are Ruby conferences taking us in the wrong direction?

I just got back from Baruco. I had a wonderful time, made new friends and caught up with some old ones. but I was still left with a concern. That’s what this post is about.

The whole event felt very professional and well-run. Many of the speakers were people who I recognised or knew from the Ruby community, and I was excited to see what they had to say. The talks varied from heavily technical to very non-technical, and each speaker was well-prepared and delivered their talk in an engaging way. We also had a first-rate MC in the guise of Dr. Nic Williams. The promotional video was brilliant, and the space theme ran on into the conference, with a really theatrical beginning to the conference: the sounds of a rocket-launch, dry ice and Dr. Nic coming on-stage in a full space suit.

As a speaker, I was treated incredibly well. The Codegram staff were just lovely, and checked with me several times a day whether I was OK, if I needed anything. We had our own private room where we could go to chill out away from the crowds. I had free drinks all night long at the parties.

So what am I complaining about?

Well, let me get this straight first. I’m not complaining about Baruco itself. I can’t imagine a nicer bunch of people than the Codegram team, doing a better job of a conference in this single-track, speaker-to-audience format. It’s the format that leaves me uncomfortable.

This format, where big names deliver polished talks to a large audience, seems to be incredibly popular in the Ruby community, yet means that most of the people who attend hardly participate at all. Yes, there are Q&A after the talks and yes, there is usually a slot for lightning talks, but it’s often put towards the bottom of the bill, or sidelined into an evening slot. Mostly, you just turn up and consume ideas from the people on the stage.

This, to me, defeats the primary purpose of a conference. If we just turn up and listen, when do we get a chance to think for ourselves? How do we make new friends when we’re spending so much time in a darkened theatre?

I think that a straight speaker-audience format conference promotes a hero or rock-star culture within the Ruby community, and I think that rock-star culture is poisonous.

I’d like to see our Ruby conferences be much more level playing fields, where we really feel like a community coming together.

Some specific things I’d like to see a lot more of from our conference organisers:

Mix up the session format

Instead of just talks, let’s have a mix of talks and hands-on sessions. Hands-on sessions give you a chance to experience a new idea instead of just hearing about it. Plus you get to make friends with the people sitting next to you by doing something you both have in common: playing with Ruby.

Make more space for unplanned sessions

I’ve been to lots of open-spaces (sometimes called unconferences) and even run a couple myself. What I think is so wonderful about this format is that you can come up with conference content during the conference so if you’re inspired to hack on or discuss something, you can find some like minds to join up with.

I think you need planned, scheduled talks to give a conference some structure and to inspire people, but when the only outlet for spontaneity is lightning talks or hallway cliques, it limits the life of the conference. Don’t make open-space an afterthought: give it equal prominence with the planned parts of the schedule.

Design for fun and new friendships

Free booze is one way to help people make new friends, but there are others.

Mealtimes are a good time for conversation, so having sit-down meals planned into the conference is great. Interactive workshops and hands-on sessions, as I’ve mentioned, give people more chance to get to know each other. I’ve also been to conferences where they deliberately matched up new attendees with old timers, so that the newbies had a friend from day one. I notice that GoRuCo does this, so kudos to them.


You’ll notice I haven’t included anything in this list about the selection process. I think enough has been said about that already, particularly by the good people of Ruby Manor, Nordic Ruby and Jez Humble of FlowCon. I’m making a wider point about the format, and the spirit of the conference scene.

Let’s stop promoting heroes within our community and make our conferences be more egalitarian, more exploratory, more fun.

Ruby Programming

Comments (0)

Permalink

Public BDD Training (London, October)

So far all of my BDD training has been done in-house as private courses for companies. That’s about to change.

On October 8th – 11th Chris Parsons and I will be running four one-day training workshops in London focussed on BDD and specification by example. These are the same courses we’ve been successfully running in-house for companies like the BBC, Burberry, and Virgin Atlantic.

There are a range of workshops for everyone involved in software development:

  • experienced testers who want to automate their manual tests
  • product owners and business analysts who want to communicate their requirements more effectively
  • project managers who want less defects and more velocity
  • experienced programmers who want to become better testers
  • experienced Cucumber users who need help with advanced issues like brittle and slow tests

We’re offering a 20% discount to anyone booking before the 1st August. Just use the promotion code super-early-birdy when booking.

So, what are you waiting for?

Agile / Lean Software Development
BDD
Ruby Programming

Comments (1)

Permalink

Matt vs NYC

New York is one of my favourite cities in the world. I’m extremely fortunate to be able to spend a whole week there next week. I’ll be mostly hanging out at QCon:

I’m also going to run a couple of sessions at General Assembly on Thursday evening. If you can’t afford the time or ticket price for QCon, this might be a good option to come along and hear some of my ideas:

  • At 6pm on Thursday I’ll be doing an intro-level talk on BDD. It’s aimed at business people, development managers etc who want to get an idea of the benefits of specification by example and a wider BDD process. Sign up here.
  • at 8pm on Thursday I’ll be doing my ‘BDD as if you meant it’ demonstration, using the example from the middle section of The Cucumber Book. If you’re already using Cucumber, this should give you some fresh perspective and insights about how to use it most effectively. Sign up here.

Finally, I’m honoured to be spending Saturday on the bill with some amazing people at the Gotham Ruby Conference. I’m going to be speaking about hexagonal rails. I’m excited and nervous about this talk, as I feel like I’m still discovering so much about this topic all the time.

As well as all this geekery, I’d love to get some proper culture while I’m in town. Are there any locals who would like to show me around?

Agile / Lean Software Development
BDD
Hexagonal Rails
Ruby Programming

Comments (1)

Permalink

A vision for Cucumber 2.0

At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.

This post is a record of that conversation.

Why do we need a new Cucumber?

The current version of Cucumber has been around since 2008, and as Jonas has previously explained the code isn’t much fun to hack on. It’s quite bloated with features, some of which were added as experiments and maybe aren’t used by most users. Carrying this cruft around is holding us back from adding new features that we do want.

Also, the current mechanism for mapping from steps to Ruby code is pretty basic, and doesn’t really encourage the good practices we’ve learned as a community about organising your test code.

What is your vision?

I asked each of the participants what they’d learned from their fork of Cucumber, and what they’d like to see in a new version of Cucumber.

Aslak made three points:

  • It should be possible to use Cucumber as a library, so that other tools can be built on top of it as well as the command-line interface.
  • The way steps are defined in Cucumber-JVM, by simply annotating existing methods, allows you to focus on keeping your test code well organised. We should steal this idea for Cucumber-Ruby.
  • There should be a collaborative web UI for writing Cucumber scenarios with non-technical stakeholders.

Julien added:

  • Integrating the Cucumber-HTML project, which is essentially a web-based client for Cucumber, would be awesome.
  • It would be nice to use the Cucumber-TCK, which is growing into a standard set of specs for any Cucumber implementation.
  • He hasn’t implemented calling steps from step defs in Cucumber-JS, and he’s not sure he wants to.
  • Parallel execution – can we make this possible?

Oriol echoed Aslak’s thoughts about keeping test code better organised: Spinach uses one class per feature, and is generally more object-oriented unlike Cucumber-Ruby’s flat anonymous blocks for step definitions.

Jonas said his goal for Turnip was mainly simplification:

  • He thinks that the reason some people had started to abandon Cucumber was to do with it being perceived as complex.
  • Jumping from plain english steps to Regexps is jarring, and too big a leap in abstraction. 98% of the time you don’t need regular expressions anyway. Turnip uses the concept of placeholders in strings instead to capture arguments.
  • Using RSpec as the runner for Turnip hasn’t worked out so well.

What features should we remove?

It’s always fun making a ‘not’ list, so we brainstormed the current Cucumber features we’d like to kill in a 2.0 release:

Cucumber: Features to Kill

In case you can’t read my scrawl, here’s that list again:

  • Wire protocol
  • Calling steps from step defs
  • Tables (we’re talking about scenario outlines here)
  • DRB / Spork
  • World having everything mixed in, all the time
  • Cucumber.yml
  • Given / When / Then being regarded as the same by Cucumber

As you can see, we got the audience to come up and vote after the session. It looks like nested steps are living on borrowed time!

My view is that with a well-designed core, many of these features can still exist but as plug-ins, thereby allowing people who need them to continue to use them, but without the maintenance burden on the core team.

So what’s next?

Well, I think I have a pretty clear vision for what Cucumber 2.0 would look like. I’d like to start with a simple core library that has no GUI component at all, but can pass the TCK tests. Then we can start building tools around that core, like a console runner, and a websocket server for running cukes from a javascript browser app. I’m personally really excited about where that last idea could lead.

What I’m short on is time. Would it be crazy to ask if there are any companies who would consider sponsoring this project? I can’t imagine a better way to spend the summer than hacking out a brand new shiny Cucumber!

Update: Thanks for the comments, but I don’t find they make a great medium for discussion so I don’t tend to reply to them. If you’d like to discuss this post, please chip in on these threads on the cukes google group.

Agile / Lean Software Development
BDD
Relish
Ruby Programming

Comments (16)

Permalink

Hexagonal Rails – Introduction

A few months ago, development of http://relishapp.com reached what is a familiar but rather unpleasant plateau for me. Up until that point, it had been developed using conventional Ruby on Rails idioms, with controllers that talk directly to ActiveRecord class methods to make queries, then set instance variables to pass the results of those queries to view templates for rendering. It’s all very procedural, and very tightly coupled.

This post is an introduction to a forthcoming series which will explain how I’ve been tackling this.

Let me start by saying that the coupling in my Rails application is not necessarily a bad thing. In fact, to get the product off the ground and give RSpec’s amazing living documentation a place to call home, we needed to be able to put Relish together very quickly. This is where Rails absolutely dazzles: the early stages of a project are so easy that adding features is a delight.

Unfortunately, the very forces that make adding features to a new Rails application so easy are the same ones that start to hold you back as the number of features grows. That conventional Rails style is what Kent Beck has called a connected design style, Quoting from that article:

In a connected system, elements are highly available to each other (via global state, for example). Adding the first feature to a connected system is cheap. All the resources you need are available. However, the cost of all those connections is that subsequent features are very likely to interact with previous features, driving up the cost of development over time.
The alternative to a connected design style is what Kent calls a modular design style. He contrasts these using this chart:

Cost of Features in Connected and Modular Designs (from http://www.threeriversinstitute.org/)

For the first few features, a connected design style is cheaper than a modular design style. In fact, using what might be referred to by software design snobs as ‘poor design’ could give you a competitive advantage in the early stages of your product’s development. The trick is to recognise when it’s time to switch styles.

So, while I love Rails for what it is, I also recognise its weaknesses. To make the Relish codebase habitable in the long term, I need to move beyond its connected design style and establish a more modular design. But how? It’s a question that many different people are asking at the moment, and I’ve been diving deep into what they are saying. Here’s a sample:

For my part, I re-read the outstanding Growing Object-Oriented Software Guided by Tests (GOOS) by Steve Freeman and Nat Price. In that book, Steve and Nat advocate a ports-and-adapters or hexagonal architecture, which keeps your core application logic separate from any technical details needed to connect the application to the real world; technical details like databases, or web user interfaces.

I think it’s easier to use an architecture like this in Java or C#, where packages and interfaces make it easy to see and enforce separation between chunks of the application, than in Ruby where it’s harder to make clear boundaries around areas of the system. But that doesn’t mean it isn’t possible. For the past couple of months I have been experimenting with refactorings in the Relish codebase to move it towards a more hexagonal architectural style. The overall goal is to make the Relish codebase habitable, which for me breaks down into:

1. Fast tests

I never add features without tests, and I want those tests to run fast. The goal of the hexagonal architecture is to have the most interesting (and frequently changing) logic implemented in plain old Ruby objects that have no dependency on any other libraries so they are easy to understand, and can be quickly spun up in a test.

2. Modularity and encapsulation

Ruby is an object-oriented language with great support for functional programming, and I want to make the most of that to keep Relish’s code easy to change.

3. Clean and well-organised

I want a structure that communicates what each part of the system is doing, and makes it easy for new team members to jump in and start hacking on the code.

I’ll start the series by explaining a couple of key concepts from Steve and Nat’s GOOS book, and about hexagonal architectures in general. Then we’ll get down to some practical work refactoring a typical Rails controller. Stay tuned!

Agile / Lean Software Development
Hexagonal Rails
Relish
Ruby Programming

Comments (6)

Permalink

Free BDD Coaching

In this blog post, I will reveal a secret to you. A secret that can get you access to free, hands-on BDD coaching from some of the world’s leading experts like Aslak Hellsøy, Mike Sassak, Greg Hnatiuk, Joseph Wilk and even me, Matt Wynne. Yes, that’s right: absolutely FREE.

Would you like to know how?

I’ll give you step-by-step instructions.

  1. Point your web browser to the Cucumber issues list.

  2. Have a look around. Take your time. Look for issues that don’t already have Code Attached, because we’re looking for an issue that nobody has tried to solve yet. Found an interesting one? Good.

  3. Fork the Cucumber repository to your Github account.

  4. Now comes the hard part. You need to write a failing test for the issue you found. Start by writing a scenario that describes the way the code should behave once the issue has been fixed. Try to not to just create a file called ‘features/fixissue234.feature‘ but instead try to slot your scenario into the existing features as extra detail about that particular aspect of the system. You might need to create a new feature file, but try to name it according to the behaviour it describes, rather than the bug it tests. Look at the other features for examples of how to write your scenario. Try to use a declarative style where possible.

  5. With your scenario written, it’s time to submit a pull request.

  6. This is where your FREE BDD coaching will begin. One of the Cucumber team will see your pull request, and will be delighted to offer you feedback on your scenario. You don’t have to wait for the feedback though, you can go ahead and start to get your scenario running.

  7. Keep pushing. Every time you make progress, getting the steps of your scenario to actually run against Cucumber, push to your fork and the pull request will be updated automatically by Github’s legions of octocats. Your FREE BDD coach will keep encouraging you with comments and feedback. Now comes the hard part.

  8. Once you have the scenario running, you’ve got the bug trapped: it’s time to fix it! Again, your FREE BDD coach will be in your corner. Ask questions about the design of the existing cucumber code, about your code, write specs to isolate behaviour further, and let your FREE BDD coach guide you. Before you know it you’ll have fixed the issue, and your name will be emblazoned in the codebase forever more.

This is a great way to get access to some very experienced and friendly software developers and feel good about giving something back to the community. Many wise software craftspeople have already discovered this secret. Isn’t it time you joined them?

And did I mention that it’s FREE?

Agile / Lean Software Development
BDD
Ruby Programming

Comments (0)

Permalink

Commands vs Queries

There are some fascinating discussions going on over on the mailing list for Avdi Grimm’s excellent e-book, Objects on Rails.

Recently, in a discussion about command-query separation and Dan Kubb posted this little piece of beauty:

One convention I use is that query methods are idempotent and return a value, while command methods change state, but they can only return self. This provides a nice fluent interface when working with the objects, and feels quite natural (to me at least).

Feels natural to me too.

Ruby Programming

Comments (2)

Permalink

Announcing The Cucumber Book (Beta)

I love using Cucumber to help me write software. I almost find it hard to imagine doing it any other way.

I want more people to discover this for themselves, so for the last year or so Aslak and I have been writing a book all about using Cucumber for Behaviour-Driven Development:

The Cucumber Book cover

We hope we’ve captured some of the passion and sheer enjoyment we get from working with this amazing tool. Whether you’re a complete novice or an experienced Cucumber user, I think you’ll get a lot from the book.

What are you waiting for? Go and get yourself a copy!

Agile / Lean Software Development
Ruby Programming

Comments (4)

Permalink

Fixing my testing workflow

Okay I’m bored of this. I need to talk about it.

I love to use Ruby, RSpec, Cucumber and Rails to do test-driven development, but my tools for running tests are just infuriatingly dumb. Here’s what I want:

  • When a test fails, it should be kept on a list until it has been seen to pass
  • When more than one test fails:
    • Show me the list, let me choose one
    • Focus on that one until it passes, or I ask to go ‘back up’ to the list
    • When it passes, go back up to the list and let me choose again
    • When the list is empty, I get a free biscuit
  • When a test case is run, a mapping should be stored to the source files that were covered as it ran so that:
    • When a file changes, I can use that mapping to guess which test cases to run. Fuck all this naming convention stuff, it’s full of holes.
    • At any time, I can pipe the git diff though the tool to figure out which test cases to run to cover the entire commit I’m about to make.

When I say test case, I personally mean:

  • An RSpec example
  • A Cucumber scenario

…but it should work for any other testing framework too.

I feel like having a tool like this that I trusted would make a huge difference to me. There are all these various scrappy little pieces of the puzzle around: guard plugins, autotest, cucover, cucumber’s rerun formatter. None of them seem to quite do it, for me. Am I missing something?

Or shall we make one?

Agile / Lean Software Development
Ruby Programming

Comments (8)

Permalink

Targeting Multiple Platforms (JRuby etc) with a RubyGems .gemspec

Recently we had a user who runs the relish gem on JRuby, and needed jruby-openssl to be loaded. He kindly submitted this patch, which I merged in without really thinking about it too much. Then the problems started.

That’s not the right way to express dependencies for different platforms using RubyGems and Bundler. I’ve done some research and I think I understand the current good practice for this, so I’m going to document it here.

The .gemspec is read at the time you build and release your gem, so any conditional logic in that file will be evaluated once when the gem is built and released on your machine. So a line like this:

s.add_runtime_dependency('jruby-openssl') if RUBY_PLATFORM == 'java'

Will bake-in the dependency based on whatever platform you run gem build on.

What you need instead is to evaluate the platform at runtime. Bundler offers you a way to do this, in your Gemfile:

platforms :jruby do
  gem "jruby-openssl"
end

What a jruby user will now experience is that when your gem is loaded, they’ll see a warning:

→ relish help
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
...

It’s now up to the user to manually install the gem themselves. It seems a shame that there isn’t any way to specify this information in the gem’s manifest, so that it can be installed on a platform-specific basis when you gem is installed, but as far as I can tell there’s no way to do that right now.

Agile / Lean Software Development
Ruby Programming

Comments (3)

Permalink