David Heinemeier Hansson, the creator of Ruby on Rails, gave a keynote at RailsConf where he declared that TDD is Dead. This caused a predictably large amount of controversy in both the Rails and wider software development community. It also led to some interesting conversations between David, Kent, and myself. We decided that these conversations were interesting enough that others might like to watch them too, so recorded a series of video hangouts where we discuss the role of TDD in software development.

A couple of videos of a conversation between me and my colleague Badri about hexagonal architecture and its role in a Rails application. In the first video we talk about what Hexagonal Architecture means and how this leads into the choice between the Active Record and Data Mapper patterns for a persistance framework. In the second we move more broadly into the architectural role Rails should play in an application - should you see it as a platform, or a suite of components.

Rake is a build language, similar in purpose to make and ant. Like make and ant it's a Domain Specific Language, unlike those two it's an internal DSL programmed in the Ruby language. In this article I introduce rake and describe some interesting things that came out of my use of rake to build this web site: dependency models, synthesized tasks, custom build routines and debugging the build script.

The Ruby Rogues are a popular podcast where a regular panel discusses topics in the Ruby programming community. They have a regular book club and recently selected P of EAA as their featured book. Consequently they asked me to appear as a guest on their show to discuss the book and the patterns that it describes, in particular the interesting relationship between these patterns and the Rails framework.

The Ruby Rogues is a popular podcast on programming in the Ruby world. They invited me back to discuss the Ruby edition of Refactoring. We talked about the definition of refactoring, why we find we don't use debuggers much, what might be done to modernize the book, the role of refactoring tools, whether comments can be used for good, the trade-off between refactoring and rewriting, modularity and microservices, and how the software industry has changed over the last twenty years.

Thoughtworks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a viable platform that should be seriously considered for many forms of applications - in particular web applications using Ruby on Rails. I also go through some technical lessons, including some thoughts on testing with Active Record.

For a talk at QCon London 2009 I surveyed Thoughtworks use of Ruby from 2006-2008 in which time we did 41 projects. My talk covers our views on Ruby's producitivity, speed, and maintainability. I conclude that Ruby should be taken seriously as a development environment. I also have an article that covers the same material if you prefer reading to watching.

As with most of my keynotes, this is an extemporary talk. Given the conference, this one has a theme of how rails impacts software development.

Collection pipelines are a programming pattern where you organize some computation as a sequence of operations which compose by taking a collection as output of one operation and feeding it into the next. (Common operations are filter, map, and reduce.) This pattern is common in functional programming, and also in object-oriented languages which have lambdas. This article describes the pattern with several examples of how to form pipelines, both to introduce the pattern to those unfamiliar with it, and to help people understand the core concepts so they can more easily take ideas from one language to another.

When you learn about objects, you usually learn that they can capture two kinds of data: instance and class. Instance variables are the most common case, the data varies with each instance of the object. Class variables, often referred to as static variables, are shared across all instances of a class. Every instance points to same value and any changes are seen by all. Class variables are much less common than instance variables, especially mutable class variables.

Perhaps I was being naive but I never expected quite the chatter that my post on HumaneInterface opened up. Sadly most of it ended up being arguments about the relative merits of Ruby's Array and Java's List rather than the underlying points I was trying to make, but despite that I think some nice conversational tributaries appeared.

One of these conversational threads brought out that there are other reasons for the differences between Array and List than the humane/minimal philosophies. One of these reasons has to do with the way similar functionality plays different roles in the two languages.

Recently some of our developers ran into the accusation that with a dynamic language like ruby you use so many dynamic type checks that you end up effectively writing your own type system. So they thought, since we've written a lot of real ruby code - how often do we make dynamic type checks? Michael Schubert gathered up the data.

I've long been loath to write any contributions on the debate between static and dynamic typing in programming languages. This is one of those emotive topics where people seem driven to debate rather than listen. But since I've been asked a few times about it, I will contribute my personal experiences. I'm not trying to convince anyone of anything, but I hope someone finds some food for thought in them.

In the newly formed Rails community, the word 'enterprise' is becoming a dirty word. For many people the Rails framework, with its aggressive simplicity, is the antithesis of over-complex 'enterprisey' frameworks.

If you're reading this I assume you're aware of the fact that there's been a huge amount of fuss about the Ruby programming language, and in particular the Rails framework for developing web applications. Some see it as the future of programming, others as a dangerous diversion.

Currently there's quite a debate raging over the relative merits of Groovy and JRuby as scripting languages running on the Java virtual machine. Curious minds want to know - which of these languages will win this upcoming language war? People want to know which language to pick for a project, or which language to commit to learn.

If I want to teach people object-orientation, which language should I use?

I don't go to as many conferences as I used to, but the advantage of that is that I have time to go to ones that take my fancy. I've long had a particular fondness for the Ruby community, so I turned up as an attendee at this year's RailsConf.

One of Ruby's most popular features is its support for metaprogramming, that is features that act like they change the language itself - introducing things like new keywords.

At RailsConf2007 there was a lot of excitement over JRuby. This small team had taken a moribund project and turned it into what looks like a first class implementation of the Ruby platform on the JVM. They got a lot of cheers and deserved them all.

So with JRuby pretty much here, the spotlight moves onto the other common managed code runtime - .NET. Microsoft's intentions for Ruby are currently much less clear. They have announced Ruby as a language for scripting Silverlight - but that still leaves a lot of open questions. Is this a full implementation of the ruby language, or is some form of Ruby++ - an enhanced subset of Ruby?

As any regular reader of mine should know, I've been a keen rubyist for several years. I like the ruby language for its rich yet uncluttered syntax and the well designed frameworks that come with it. It's become my regular workhorse language for personal projects, including most of this web site.

In my recent post on EvaluatingRuby I mentioned that a colleague had put together a web app with some fancy numerical graphs. Someone emailed to ask how he did that. I added my short answer, ploticus, to the original bliki entry, but that led to the question of how he interfaced ruby with ploticus?

A couple of weeks ago there was a Ruby conference in San Francisco called GoGaRuCo (Golden Gate Ruby Conference). This conference has grabbed attention due to a talk at which the presenter illustrated a discussion of CouchDB by using sexually suggestive pictures of women. Unsurprisingly the result has been a fair bit of heated, and occasionally offensive, debate.