Ruby bliki

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.

The main lines of the debate are familiar. Various people, not all women, lay the charge that the images and general tone was offensive. Such material makes women feel degraded and alienated. This kind of presentation would not be tolerated at most professional events.

Defenders of the presenter point out that the slides were humorous and no offense was intended. The Rails community has always had a edginess to it - in part because much of the Rails community is focused on the rejection of enterprise values - both technologically and socially. David Heinemeier Hansson is happy to proclaim himself as an R rated individual and is happy to consign "professional" to the same pit to which he cast "enterprise".

I'll admit to finding much to like in the general edginess of the Rails world. Innovation often involves seeing a generally accepted line and vaulting over it. There's plenty of precious posturing around the software world that I'm glad to see skewered. Many of us have been delighted at how Rails has cheekily whacked over-complex frameworks, vendor bloatware, and other assorted ills. An important target of this skewer has been the rise of corporate blandness, where a fear of offense has transformed into a fear of any authentic communication and the rise of the anodyne press release. I'm right with the rails people on this - software is too much fun to shriveled up in dry talks and writing.

So the view of the rails leadership seems to be this: that the objections to the presentation are yet another attempt to foist empty corporate values on the thriving Rails ecosystem.

Except on this occasion I don't see the suits as the people doing the complaining. Most of those calling foul are women who have had to struggle with very real sexism in their careers, and men who have seen this and side with those women. They have been fighting the suits since before the Rails leadership were born, and for much higher stakes.

This incident has now grown beyond a conference presentation and a slide-deck on the web. The issue is no longer the presentation, but the reaction of the community to this event. The leaders, particularly David Heinemeier Hansson as the most visible figure, now face an important time in influencing what the future of the community will be.

The reaction of the rails leadership thus far is to deny the offense. I'll say now that I don't believe they are sexist. I believe that they didn't think the talk would give this much offense - and even that they don't think the talk should give offense.

At this point there's an important principle. I can't choose whether someone is offended by my actions. I can choose whether I care. The nub is that whatever the presenter may think, people were offended - both in the talk and those who saw the slides later. It doesn't matter whether or not you think the slides were pornographic. The question is does the presenter, and the wider community, care that women feel disturbed, uncomfortable, marginalized and a little scared.

It's my view that the people in a community have the power to set the tone of that community, to decide what is and is not acceptable behavior within it. If something questionable happens and people remain silent, that is an implicit acceptance of that event. That is why I feel compelled to write this page, because I think that this talk, and more importantly the rails leadership response to this talk, is objectionable.

My observation is that most men in the software business think that there isn't much sexism left in the profession - that this curse is a memory from a previous generation. Yet when I talk to women, I hear a different story. Nearly every one can tell me recent stories where they were clearly expected to feel degraded and belittled because of their gender. So some sexually suggestive pictures aren't a joke to them, they are a pointed reminder of disturbing behavior, and a reminder that such events can happen again at any time. One of the great difficulties for white guys like me is that we haven't been in that position; where prejudice can appear out of any corner, reinforced by the fact that every other face looks different.

This becomes more of an issue because the rails world faces a notable lack of women. The software world struggles with Diversity as it is. It's a problem for our profession, in that we lose access to talent, and it's a problem for many women who don't get the chance to develop a satisfying career in programming. The open-source world in general has even bigger issue, and the rails community perhaps more so. I'm sure it's not the only factor but the encouragement of talks like this creates an unwelcoming atmosphere of NetNastiness which deters many women from starting and staying in the community.

There also seems to be a generational factor in this. My colleagues have noticed that younger women, typically those under 30, are much less conscious of sexism than their older colleagues. This is partly because of the successes their elders have had in opening up the workplace to women. It may also because younger women haven't yet met the glass ceiling (and I hope it will be gone before they get there). Younger women also seem much more tolerant of sexual imagery. Yet I don't think this is cause for complacency. An important element in nurturing women in our profession is to have role-models who can show what's possible. Alienating older women makes it harder to do that.

So where does this go? I won't attempt to predict the future, but there is a scenario where this little presentation may be seen as a defining event in the rails story. This doesn't mean that people will suddenly leave in droves, but it does begin with a few departures, such as Mike Gunderloy's. The community continues with more alienating events, encouraged by the fact that those who are more sensitive are no longer around to object. This encourages more departures as people don't want to be associated with such a community. Thus develops a positive feedback loop making the rails world increasingly brash and unwelcoming for many of us.

I have a different vision - one that sticks it to the suits so hard it will make their eyes water. How about a community where women are valued for their ability to program and not by the thickness of their skin? How about a community that edgily pushes new boundaries without reinforcing long running evils? Perhaps even a community where women reach equal numbers? Such a community would hand the suits the defeat in the long battle women have been fighting for centuries. I'd love to be part of that.

Further Reading

A selection of commentary on this issue on the web. It's not a comprehensive list, just the items I've felt are particularly interesting and relevant to this story.

• The original presentation on slideshare. (Be warned: some people might not be comfortable looking at these slides at work.) This is almost the presentation that was given, although apparently there were some more racy pictures interspersed between the code examples that were removed for the slideshare version.
• Reaction from Sarah Allen, who was there.
• Reaction from Sarah Mei, who was also there. I found her entries in the comments (starting here) most helpful in understanding her feelings.
• Early reflections on this from Audrey Eschright, which try to explain why many women feel offended by this kind of thing.
• Renae Bair offers a different perspective.
• David Heinemeier Hansson indirectly supports this kind of presentation by explaining why he's an R-rated individual and questioning if software is any different to other professions.
• Mike Gunderloy explains why he's resigned from Rails Activists. Notice the shift in focus now from the original presentation to the reaction to it.
• Matt Aimonetti, the presenter, gives his main post reacting to the objections. Note also that he's posted comments on many of the blogs I've referenced earlier.
• Liz Keogh looks at how talks like this lead to cognitive associations that lead to problems.
• Scott Hanselman looks at the region between political correctness and offense.
• Why the Lucky Stiff, posts a mosaic of reactions from women.
• Piers Cawley explains the difference between rails programmers and 80's truck salesmen.
• Josh Susser, who was responsible for the technical program at the conference, apologizes gracefully and explains the background to selecting the talk.
• Tim Bray adds two observations, one link, and some recommendations
• A similar incident strikes the Flash community.

Some thoughts on common statements

These pictures were less revealing and sexual that what you'd find in a mainstream movie

This is where the context matters. Watching a movie is a different social space to being in a software development talk. As result people react differently.

These kinds of sexualized images have long been associated with men's clubs. Condoning a presentation like this can imply that the powerful (the community leadership) wants this atmosphere, to create a context that excludes women. I don't think the rails leadership actually wants to do this, but if someone did want to do create such a group, this would be a good way to go about it.

Women shouldn't get so annoyed, men don't when women make reverse jokes

If you always worry about people being offended, you'll just end up being bland

Yes, that's a real risk. But being aware of causing offense doesn't mean you have to dial all the way down to corporate blandness. It means thinking how what you will cause offense and being comfortable with the result. You may feel that certain people should be deal with being offended, you may think that only a very small amount of people will be offended. That can be a reasonable response, but it has to be a thoughtful response.

As often, I find my black colleague Chad Wathington puts it well:

The presenter made an apology

The people who were offended are being thin-skinned.

That's a comment often made by those who condone NetNastiness, but it doesn't help those who are offended. The crucial point is: do we want to create an environment where "thin-skinned" people aren't welcome? After all the consequence of a society that is tolerant of nastiness and bullying is one where only the thick-skinned need apply. I'd prefer that people are welcomed for their ability in software development, not their ability to withstand offense.

This goes further than just our profession. To be successful as software developers, we need to collaborate with people in other fields. Tolerating this degree of nastiness makes it difficult for people in other walks of life to work with us, which impoverishes us all.

Humor is an important tool to puncture the self-important

I agree, but this only works if the power relationship is in the right direction. Someone of low power poking fun at a powerful person is a different situation to someone with lots of power skewering someone with little power. Women are (still) in a position of low power in our society (particularly in software development) so we have to be more careful with our humor.

Should be organizer be blamed for this?

If an organizer rejected a talk like this, that would be censorship

You're just trying to impose your moral and 'professional' standards on us

This is no worse than what happens in other professions

Can we get off this subject now and on to important technical issues?

Actually I think a social issue like this is worth spending time on. To build software effectively you have to be able to collaborate with other people, both other programmers and people outside of the software community. Discussions like this help us understand how we relate with other people, which makes a huge contribution to both our professional and personal lives.

Acknowledgements

I always find it particularly difficult to write these kinds of pieces. When I do, I find it particularly valuable to bounce thoughts off several of my colleagues and other friends. My thanks to David Heinemeier Hansson, Jez Humble, John Kordyback, Cyndi Mitchell, Mai Skou Nielsen, Rebecca Parsons, Kathy Sierra, Roy Singham, Chris Stevenson, and Chad Wathington for reading and commenting on the drafts. Thanks also to lots of people who have posted their feelings and analysis both on public channels and internal ThoughtWorks mailing lists. I have learned a great deal in the last few days.

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.

Perhaps the first thing to point out is that it's perhaps rather unfair to see this as a race between these particular two horses. Scripting has been available on the JVM for a long time. Jython, a Java implementation of Python, has been around for several years. There's plenty of other, more obscure languages, which I daren't mention for fear of offending all the ones I miss out.

JRuby has got a lot of attention due to the attention of the Ruby language generally - attention particularly ignited by the interest around Rails. We've seen a sharp spike of interest around Ruby and Rails work at ThoughtWorks, and JRuby adds an extra dimension since it allows people to deploy Rails applications using their existing Java infrastructure.

Groovy gets its attention because it, more than any other language, is designed to work seamlessly with the JVM, and got a lot of attention from an early JSR.

Personally I'd dropped Groovy from my radar a couple of years ago when its development seemed to bog down. With its 1.0 release and further interesting positive vibes from some of my colleagues I've started to pay attention again.

Lets begin by talking about similarities. Both JRuby and Groovy (and indeed Jython) are modern OO scripting languages. They combine the well-chosen terseness of scripting languages with good solid structures for building larger programs. As such they are suitable both for classical scripting and for writing larger programs. Both are comfortable with dynamic type checking, although Groovy does offer some static facilities too. Both support Closures which are an important feature for the greater expressiveness that people want from this kind of language.

The biggest difference between them is their broader platform philosophy. Groovy is designed to be a scripting language for Java. As much as possible its syntax tries to match the equivalent in Java. (Including such ugly things as the default fall-through in switch statements.) It also works with Java's class library directly, although it dynamically adds many methods to Java's classes, vital in order to make use of things like closures.

JRuby, however, is a Java implementation of the Ruby platform. Ruby can run directly on mainstream operating systems with a C runtime, and is starting to run on .NET's CLR. When you program in JRuby you primarily use Ruby's libraries which are implemented in Java, and may also use Java's libraries at your discretion. If you stick to Ruby's libraries, or at least wrap any foreign elements, you can run Ruby programs on the C, Java, or (in time) .NET runtimes. So you can use JRuby to both run Ruby programs on the JVM and as a language for scripting the JVM.

One of the big differences between JRuby and Jython is around the libraries. One of the tricky aspects of porting this kind of scripting language to the JVM is that these languages are usually closely intertwined with libraries implemented in C. Porting these libraries to Java involves rewriting the libraries in Java. Jython didn't do much of this, as a result many Python apps can't run in Jython. However the JRuby implementers decided from early on that their goal was to run Rails apps, as a result many libraries including all the Ruby standard libraries needed to be ported.

The fact that JRuby is a Ruby platform on the JVM means that in JRuby you have two kinds of objects - JRuby objects and Java objects. Although there are ways for the two to talk to each other and to convert there is a difference. There are times when you need to know whether you're dealing with a Java string or a JRuby string. With Groovy you don't have that boundary, there are just Java objects.

It's too early, or rather too difficult, to say if one language will win out. Both are pretty young, only just finding their feet on the JVM. On a more personal level, your choice has a lot to do with what you expect to do with it. If you are only interested in running on the JVM, then Groovy could well be the easier choice. You are working directly with Java's library and object model, and the syntax requires less getting used to. A strong reason to prefer Ruby is the fact that it lives in multiple implementations. Ruby is a tool you can use in a lot of other places. As a long time Rubyist, there's not much incentive for me personally to get heavily into Groovy, even though I actually like the language a lot from what I've seen of it.

Rails is an important factor. The Java world is hardly lacking in web frameworks, but Rails is widely liked by those who've used it. I've not got many reports yet about Grails (the Groovy knock-off) so can't give a firm opinion on that. But I can imagine that the ability to deploy web apps with Rails could be a major factor in making JRuby popular. Something else to look at is the growth of RSpec as a new spin on testing environments.

With any platform it's as important to consider the people involved in the community as much as any technical factors. Good people can overcome technical weaknesses quickly and a vibrant community is a potent source for big innovations. RubyPeople have formed a particularly strong community, which has already spawned things like Rails, Rake, and Rspec.

Will either matter to Java? After all Jython's been around for a long time without making a huge impact on the JVM. Tool support is frankly pathetic for any of these languages when you compare it to what you have for Java at the moment.

I think we're actually at an inflection point with Java. Until recently the Java cry was One VM and OneLanguage. (As opposed to the CLR which started with the cry of one VM and many languages - providing they're C# or VB.) This seems to be changing as people realize the limitations of Java and begin to seek out different capabilities. It's likely the future will see multiple languages closely integrated within the JVM.

There are plenty of people who dislike the hype around Rails and Ruby. But even if you dislike Ruby, the hype has led to a resurgence of interest in new languages. I doubt if the interest in Groovy would be anywhere near as great as it is if it wasn't for this hype, nor would Jython be awaking from its slumbers. The ruby/rails hype has also generated interest in other exotic JVM languages. The really nice thing here is that the JRuby people have been encouraging their dynamic rivals - recognizing that the point here is to encourage multi-lingual inter-operability and innovation.

Update: Recently we've seen some very encourging signs coming out of Redmond. In particular, IronRuby will be hosted on RubyForge with what looks like a very permissive licence - Ola approves.

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?

JRuby serves two distinct but complementary purposes. On the one hand it's a powerful scripting language for the JVM, allowing you to weave a dynamic language into a Java application. It's second purpose is an implementation of the Ruby platform in the JVM, which allows a Ruby application, in particular a Ruby on Rails application, to run on the JVM just as well as it runs on the MRI (Matz's Ruby Interpreter, the current C runtime).

The big question for Microsoft's "Iron Ruby" is how compatible will it be? Will it be a full implementation on the CLR? All the signals I hear tell me that John Lam, the main force behind Iron Ruby, is determined to get a fully compatible implementation. However this may be very difficult to do as things stand. Soon-to-be-ThoughtWorker Ola Bini, a JRuby committer, reckons that it's almost impossible to figure out how to implement a Ruby runtime without looking at source code of the MRI - but Microsoft imposes drastic limitations on its employees' ability to download open source software, let alone look at the source. The open-source community does much of its communication through source code - so this makes collaboration with an open-source community very difficult.

Overshadowing this, of course, is Microsoft's historically difficult relationship with the open source world. In the past Microsoft has gone out of its way to vilify and threaten the open source community. In recent years things have improved, but there's a real question about Microsoft's core intentions. The recent patent threats are seen by many as proof that Microsoft is still intent on fighting open source to the death.

Unlike most other technology companies, Microsoft has struggled to find a way to co-exist with the open source world. It is harder for Microsoft - unlike Sun, Apple, or IBM they are overwhelmingly a software company. Open source projects like Linux, GNU, and Open Office are directly competing with Microsoft's crown jewels. However I've never felt that declaring war on open-source, trying to stamp it out, was a viable long-term solution. Open-source is here to stay, the question is how to accommodate it.

With Ruby Microsoft is in a different position to the more visible death match. Ruby doesn't compete with the core revenue generators in Microsoft's line up. What's more there is a real desire in the Ruby community to co-operate with Microsoft. Most people I talked to at RailsConf were very keen to see a full range of support for Ruby on Microsoft - and there were a lot of creative ideas floating around on how we could try to come with an approach that could make it work. The overwhelming sense I heard in the community was not "Ruby will kill evil Microsoft" but "how can we overcome the problems to get Ruby on Microsoft."

As Chris Sells pointed out, we do have to consider the question "what's in this for Microsoft". I see a couple of reasons. First off is the role of .NET and Windows in the data center. If Microsoft doesn't support the Ruby platform, it runs the risk of people moving away from .NET (and Windows) on server farms if Ruby on Rails becomes successful.

Another reason is people. Microsoft doesn't like to acknowledge this in public, but there is a real concern that AlphaGeeks are moving away from the Microsoft platform. There's a growing sense that Microsoft's vision is armies of Morts in command-and-control organizations. There often seems to be outright discouragement of tools to enable talented enterprise developers, or of agile development processes.

A few years ago my (limited) contacts in Redmond told me that they were seeing a real drift of technical leaders away from the Windows platform. More recently these signs seem to be increasing. Reading the 'softie part of my blogroll I got a sense of real disillusionment amongst people who have been long-time Microsoft supporters. Agile-oriented developers have been frustrated with the direction of Microsoft tools. Microsoft conferences barely mentioning agile processes, leaning much more to waterfall approaches. The tools, with their rigid role-separations, actively discourage the blurry boundaries that agilists prefer.

At RailsConf, Tim Bray contended that the key decisions on technology are made by the programming community. I partly agree with this. The reason we have so much bloatware in IT is because IT purchasing decisions are usually made on golf courses by people who have lost meaningful contact with the realities of software development. However golf-course decisions may dominate the short-term, but as time rolls on I think Tim's contention is true. So losing the alpha geeks may not matter this year or next, but will inexorably harm Microsoft over time.

Indeed it's already past next year for Microsoft. We've seen a noticeable drop-off in interest from our clients for Microsoft projects, particularly in the US. In Australia, .NET hasn't got any foothold at all amongst our clients. I'm not sure what to make of this data. We aren't so big to be a statistically valid sample on our own. But it's a useful data point nonetheless particularly since we like to think our clients are the "alpha IT shops".

Perhaps more significant is the story within ThoughtWorks. When .NET appeared there was a lot of interest in the platform. Many people were pleased to see a strong competitor to the Java platform and were keen to get involved on .NET projects. Yet over the last year or so there's been a big turn away from .NET. This is despite the fact that there is some really interesting things coming out of Redmond. Mike Two is very keen on the windows workflow tools, I've been very impressed by Linq and other language developments. But the general view of Microsoft technologies is a loud yawn. This is important because, as Tim O'Reilly believes, the alpha geeks point to what everyone else will be doing in a few years time. And the crucial point is that the attitude to Microsoft isn't hatred (a common attitude amongst many geeks) but boredom. This is what Paul Graham means when he says that Microsoft is dead because it's no longer dangerous.

The attitude to open-source is a large part of this problem. When Java appeared there were yawning gaps in its portfolio, and worse some dreadful standard tools in its API (visions of Entity Beans spring to mind). Those gaps and bad ideas were fixed by the open-source community. Ant gave us a build tool, EJB was displaced by Spring and Hibernate. .NET has also got its gaps, and again the open source community has stepped up to fill them. Yet Microsoft refuses to collaborate with these efforts, even seems to go out of its way to undermine them. I was particularly sickened by Microsoft's reaction to NUnit - an excellent XUnit testing tool, elements of whose design were lauded by Anders Hejlsberg at OOPSLA. Microsoft ended not just bringing out a competitive library, but deliberately making it incompatible. That's not the kind of reaction that encourages people to invest their time in the platform.

To be fair, that debacle was a couple of years ago. Actions like hiring Jim Hugunin and John Lam have helped counter that impression. Technologists like Chris Sells, Don Box, and Jim Newkirk are working to make Microsoft are a more open environment. But like any large organization, Microsoft is full of contradictory forces and we don't know which ones will prevail.

My colleague John Kordyback pointed out that at the heart of all this is realizing that Ruby is not Yet Another .NET Language but a whole community and attitude to software development. Ruby is a community where open source, agile thinking, and lightweight solutions are deeply ingrained values. He says a common problem in Redmond is that "They ask me 'Why is this language important' rather than 'Why is this thinking important?'"

So what I see for Ruby and Microsoft is an opportunity. The Ruby community seems eager to work with Microsoft. This provides an opportunity for Redmond to figure out how to deal with the problems of working with open source and for this effort to serve as an exemplar for future collaboration. A first class implementation of the full Ruby platform on .NET would be a wonderful product of this collaboration. Perhaps an even better result would be for this work to serve as an example of how Microsoft can collaborate with a community that's centered on openness and agility; an example that can be a springboard for further spreading of attitudes that can further help programmers and their customers throughout the Microsoft world.

There's been quite a few reactions to this (see Technorati for a full list). Particularly worth reading are the ones from: Sam Gentile, Cory Foy, Luke Melia, Jeremy Miller, Rockford Lhotka, John Lam, Evan Hoff, Karl Seguin, Ola Bini, Miro Adamy, Charles Nutter, Peter Laudati, Nick Malik

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.

Chad Fowler and Rich Kilmer introduced the conference. Chad shares my name but I don't share his ukulele skills.

With a young technology there's lots of new and important pieces appearing, but for me the most important of these is JRuby. Now in its final cycle of release candidates, JRuby offers a full implementation of the Ruby Platform on the Java JVM, as well as providing a scripting language for the JVM. For what we do at ThoughtWorks, and for many Ruby/Rails developers this matters a great deal even if you never "include java".

One of the biggest issues our Ruby teams run into is deployment. Getting a ruby app into production involves a whole bunch of new technologies, and data centers tend to be conservative on this kind of thing. Our RubyWorks stack tries to simplify this, but JRuby offers the choice of just deploying into a Java container, turning a Rails app into an easily deployed war file. I think this will make Ruby on Rails a much more viable choice in lots of enterprise environments.

JRuby's maturity on the JDK raised the obvious question of what will happen with the other popular managed runtime. Signals from Microsoft were faint and unclear. It was good to see notable Microsoft-oriented geeks Scott Hanselman and Chris Sells at the show, even if when I saw Chris Sells it felt like being in an arena. What I like is that there is a real desire within the ruby community to collaborate with Microsoft rather than the usual competition and Redmond-bashing.

Indeed the overwhelming impression I got at RailsConf was a sense of industry-changing mission. At last year's conference my sense was that of a community delighted and rather stunned by its success. My iconic image was DHH as Neo of the Matrix, breaking the rules of enterprise software and reveling in the success.

This year my sense is that this morphed into something much more important. Success is not just being an outbreak of sanity in the IT world, but actually leading that world. There seems an excellent chance that Ruby and Rails could become a significant platform for IT develop over the next few years. We're already seeing signs of this at ThoughtWorks - 40% of our new business this year in the US is Ruby work.

Unlike previous platforms, this one isn't controlled or even dominated by vendors. Ruby is a community effort. I've been hoping for a long time that one of the LAMP technologies would break through into corporate IT, and it looks like Ruby could well do it.

Corporate IT is dominated by bloatware. Time and time again we have to deal with expensive software purchased on golf-courses that just get in our way while sucking funds and development hours. Technologies that make it harder for programmers to do what they like to do best - make a difference for the businesses they are supporting. (This week's memorable tale was of a large company that spent eight million dollars on an enterprise-wide version control system that couldn't branch properly.)

My hope that with a platform that's controlled by a community we'll see a platform that focuses on simplicity - finding the key things that need to be done and doing them in a way enables programmers to provide their best.

Michael Koziarski and Jamis Buck describing the Rails Way - establishing the good style which lies deep in the Ruby community.

It's helped by the fact that the ruby community has formed around the best ideas of the OO and Extreme Programming communities. Listening to the keynote of Jamis Buck and Michael Koziarski I was delighted to reflect on the thought that they were right there in the values of Ward, Kent, and all the other people who've been advocating clean code, well-factored object-oriented design, and testability. These ideas have made a great impact on many other technological communities, but in Ruby-land they are the orthodoxy.

Throughout the conference there was a sense that we are at an inflection-point in our industry, a key technological shift that promotes a new major platform. Listening and reading about JavaOne I got the sense that a big shift had happened there, people no longer focusing on Java the language but on Java the JVM, replacing one language with multiple languages closely collaborating.

A particularly fascinating thing about the Ruby community is the diversity of ages of people in it. Not just do you have the young paradigm breakers like DHH and the core team, you also have the, ahem, rather more seasoned campaigners like PragDave and the RubyCentral triumvirate. The important thing is that there's a lot of respect and collaboration across this generation gap. There isn't the wall between the old farts and the loud teenagers that you often get, instead a real appreciation for what both groups have to offer.

Not that all is good, however. There is a marked lack of women in the ruby community which, apart from the fact that we're missing out on some serious talent, probably is a sign of other problems within the community. The DevChix group was pretty active in looking for ways to try to correct this and I was pleased to see several conversations sprout up during the conference on finding ways to improve our Diversity problems.

A couple of years ago I wrote about the impressions people had that the RubyPeople were notably more friendly than most software communities. Talking to people at RailsConf I got the message that that had changed for the worse. Both the ruby lists and particularly the rails lists had tended more towards the sad Internet mean. In his opening keynote Chad Fowler said that the rails community had a reputation as "a bunch of arrogant bastards" and I cringed as an, admittedly small, group raised a triumphant cheer.

What pleased me was, that starting with Chad, there was a strong push from the ruby leadership to try and change this. A theme that came from several talks was that our community had an opportunity to try to lead the software profession away from this tar-pit of NetNastiness and lack of diversity, to create a community that really welcomed many types of people into a nurturing and pleasant environment. I've been sick of the tone of geek discussion for many years and if the Ruby community could really show a direction to lift us out of this quagmire, this would delight me even more than all of the other prizes that glitter in front of us.

(Photos courtesy James Duncan Davidson.)

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.

At the recent RailsConf, PragDave's opening keynote highlighted a bunch of unsolved issues with Rails, several of which involved dealing with some of these enterprisey concerns. An example of this was his call for support of more varied database structures, such as having compound primary keys.

DHH's response to this could not have been a more emphatic refusal. With a clever visual manipulation of his recent wired cover, DHH projected himself as the Neo of the software world, forcefully proclaiming himself to be in a better place, and telling the enterprise world that they need to join him, not the other way around. Applying this principle to compound keys, the reaction is "no way". Rails will do what it does, and will not complicate itself to support things it doesn't like.

Here is a solid example of what makes Rails "opinionated software". In the Rails mindset, life is much simpler if you keep your tables isomorphic to your objects, and give your tables surrogate, integer, primary keys. If you play the Rails way - life is easy; if not - use something else.

I confess I like this opinionated attitude. Perhaps it reflects my Unix background, which thrives on many tools that do one thing well, rather than a complex tool that tries to do many different things. I like Rails's focus, its determination to pick a certain class of application and serve that well.

In this sense I see a startling parallel between DHH and Kent Beck. For either of them, if you present them with a constrained world, they'll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don't have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That's why they can create things like Extreme Programming and Rails which really give the industry a jolt.

Lying under PragDave's talk was a deeper concern. Like me he's spent much of this life working with people who can't apply the dynamite. When you need data from a database that's run by a data management group and has run for a decade with compound keys, you can't just don a pair of cool sunglasses and blow the constraint away. One answer to this is to "change your organization or change your organization", but to those who can't should they be utterly abandoned by Ruby?

The last word of the last paragraph is the key to the answer. Rails is right, I think, to ignore the enterprisey world, but that doesn't mean that Ruby should. One of the great strengths of scripting languages, like Ruby, is their post-modern delight in diving into the muck of a chaotic software ecosystem. Ruby is a great place for other frameworks to fill the gaps left behind by Rails's opinions.

My colleague Badri gave a talk, that was sadly not very well attended, about one of these - rBatis. rBatis is a ruby port of the popular Java framework iBatis (led by Clinton Begin, another colleague). The port is being done by yet a third colleague Jon Tirsén. rBatis is still a work in progress but already it shows the same elements that made iBatis popular - fearlessly embracing the strength of SQL rather than just trying to hide it under layer of Query Objects. It also strengthens its appeal by making the most of Ruby - stealing many functions from Active Record (such as validation), and using convenient Ruby syntax rather than XML. (Is XML the hunchback of programming languages?) rBatis could be the answer to complicated database issues, still fitting into a Rails web-app, but introducing a different set of trade-offs. If you're comfortable with SQL, rBatis looks pretty damn simple. (BTW any Rubyists out there Sydney? We may need you to kidnap Jon's surfboard if work slows down on rBatis.)

All this tilts our perspective. Enterprise Rails may well be an oxymoron, but Enterprise Ruby is anything but. Indeed as I look at the way the enterprise world is going - a greater use of messaging, autonomous services featuring ApplicationDatabases, a post-modern acceptance of variety - the glue that doesn't set seems to be the ideal tool.

Although some people felt these talks implied that there was a rift appearing between the Davids, further conversation suggests to me any rift is founded on misunderstanding (now there's a mangled metaphor). PragDave's call wasn't for Rails to support these things but for the wider community to find a way. Similarly DHH's response was about the Rails core team; which hardly limits other peoples' efforts - as rBatis demonstrates. Furthermore DHH felt that most of PragDave's calls were consistent with the Core. The notion of a narrow core rails and a wider ruby world (including rails) supports both concerns - this is the strength of composing small tools.

However this wide-ruby / narrow-rails view of the world has a catch. I joked during my keynote that RailsConf was a sign of a failure of Rails - since if it was truly successful Rails would be too simple to need a conference. The underlying truth, however, is that Rails has become the keyword for Web apps (even Enterprise apps) in Ruby. I suspect we'll see more enterprisey people at RailsConf than at RubyConf, because Rails has got the attention. The consequence of this is that there's a danger that people will hear the opinionated nature of Rails as a statement about Ruby, and thus give the impression that Ruby isn't a suitable enterprise glue. That would be a shame.

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?

I actually ran into a similar problem myself recently as I wanted to use ploticus to graph some data for a personal project. The solution I came up with was actually very similar, if rather less refined, than the one my colleague used. As a result I thought I'd share it.

First a caveat - this is literally something I knocked up one evening. It isn't intended to be robust, performant or otherwise enterprisey. It's just for some data I use for me, myself, and I.

A sophisticated way to drive a C library like ploticus is to bind directly to the C API. Ruby makes this easy, so I'm told, but it's too much work for me (particularly if I want to be done before cocktail-hour). So my approach is to build a ploticus script and pipe it into ploticus. Ploticus can run by taking a script from standard input that controls what it does, so all I have to do is run ploticus within ruby and pipe commands into it. Roughly like this:

  def generate script, outfile
    IO.popen("ploticus -png -o #{outfile} -stdin", 'w'){|p| p << script}
  end

To build up the script, I like to get objects that can work in my terms, and produce the necessary ploticus stuff. If you have anything that uses the prefabs, then putting together something is easy. I wanted to do clustered bar graphs, like this, which requires a ploticus script.

I built what I needed in three levels. At the lowest level is PloticusScripter, a class that builds up ploticus script commands. Here it is:

class PloticusScripter
  def initialize
    @procs = []
  end
  def proc name
    result =  PloticusProc.new name
    yield result
    @procs << result
    return result
  end
  def script
    result = ""
    @procs.each do |p|
      result << p.script_output << "\n\n"
    end
    return result    
  end
end
class PloticusProc
  def initialize name
    @name = name
    @lines = []
  end
  def script_output
    return (["#proc " + @name] + @lines).join("\n")
  end
  def method_missing name, *args, &proc
    line = name.to_s + ": "
    line.tr!('_', '.')
    args.each {|a| line << a.to_s << " "}
    @lines << line
  end
end

As you see the scripter is just a list of proc commands (well they could be anything that responds to script_output - but I didn't need anything else yet). I can instantiate the scripter, call proc repeatedly to define my ploticus procs, then when I'm done call script to get the entire script for piping into ploticus.

The next level is something to build clustered bar graphs:

class PloticusClusterBar 
  attr_accessor :rows, :column_names
  def initialize
    @rows = []
  end
  def add_row label, data
    @rows << [label] + data
  end
  def getdata scripter
    scripter.proc("getdata") do |p|
      p.data generate_data
    end
  end
  def colors
    %w[red yellow blue green  orange]
  end
  def clusters scripter
    column_names.size.times do |i|
      scripter.proc("bars") do |p|
        p.lenfield i + 2
        p.cluster i+1 , "/", column_names.size
        p.color colors[i]
        p.hidezerobars 'yes'
        p.horizontalbars 'yes'
        p.legendlabel column_names[i]
      end    
    end
  end

  def generate_data
    result = []
    rows.each {|r| result << r.join(" ")}
    result << "\n"
    return result.join("\n")    
  end  
end

This allows me to build a graph with simple calls to add_row to add data rows. This makes it much more easy for me to build up the data for the graph.

To make a particular graph, I'll write a third class on top of that:

#produces similar to  ploticus example in ploticus/gallery/students.htm

class StudentGrapher
  def initialize
    @ps = PloticusScripter.new
    @pcb = PloticusClusterBar.new
  end
  def run
    load_data
    @pcb.getdata @ps
    areadef
    @pcb.clusters @ps    
  end
  def load_data
    @pcb.column_names = ['Exam A', 'Exam B', 'Exam C', 'Exam D']
    @pcb.add_row '01001', [44, 45, 71, 89]
    @pcb.add_row '01002', [56, 44, 54, 36]
    @pcb.add_row '01003', [46, 63, 28, 87]
    @pcb.add_row '01004', [42, 28, 39, 49]
    @pcb.add_row '01005', [52, 74, 84, 66]    
  end
  def areadef
    @ps.proc("areadef") do |p|
      p.title "Example Student Data"
      p.yrange 0, 6
      p.xrange 0, 100
      p.xaxis_stubs "inc 10"
      p.yaxis_stubs "datafield=1"
      p.rectangle 1, 1, 6, 6
    end
  end
  def generate outfile
    IO.popen("ploticus -png -o #{outfile} -stdin", 'w'){|p| p << script}
  end
  def script
    return @ps.script
  end

end


def run
  output = 'fooStudents.png'
  File.delete output if File.exists? output
  s = StudentGrapher.new
  s.run
  s.generate output
end

It's a very simple example, but it's a good illustration of what I call the Gateway pattern. The PloticusClusterBar class is the gateway with the perfect interface for what I want to do. I make it transform between that convenient interface and what the real output needs to be. The PloticusScripter class is another level of gateway. Even for a simple thing like this I find a design of composed objects like this a good way to go. Which may only say how my brain's got twisted over the years.