Ruby Kaigi ’09: Post-mortem

I consider myself very lucky that I was given an amazing opportunity to go to Japan and speak about Sinatra and Vegas (slides here). I attended all 3 days of the conference, and though I didn’t understand all of the Japanese talks (Leonard Chin did a great job translating the keynotes and some of the other major talks) it gave me a whole new perspective on Ruby and the Ruby community.

The Hierarchy of the Ruby Community

As a Rubyist, I use the Ruby language almost every day. I know most of the stdlib and its methods without thinking. There are certain things I love about it and certain things I hate. Have I ever thought about submitting a patch to the Ruby language? No. There are a couple reasons for this: I don’t really know C; Ruby’s openness lets me change the stdlib without changing the language itself. Something I hadn’t really thought about before, though, is that I’m not a language implementer. In fact, this applies to basically every Rubyist outside of Japan. Rubyists in the US and the rest of the world fit into different parts of the Ruby Hierarchy. Japan, and Ruby Kaigi, however, is the home of language implementers. There’s something completely and utterly different about language vs framework vs plugin vs app. The discussions on a language level are on a much higher level. As Matz revealed in his keynote, there are a bunch of language feature branches that he’s been just toying with, some that have been sitting there for months. Most of them might never be part of Ruby. Thinking about the implications of a new feature, or a change in Ruby’s API, made me realize just how different the thought processes are within the different levels of the community.

When I thought about this more I realized that there a some pretty clear delineations between different groups within the community. It started to look something like this:


The size of the section represents the relative pct of people involved. Each section feeds off each other, but the general flow of information and code is downwards.

I’m sure people have theorized about this before. Yehuda Katz has talked similarly about different groups of Rails users, App Developers, Plugin Developers, and something in between. Personally, I’d consider myself as a plugin and app developer, which is nothing to be ashamed of, its just interesting to actually think about the fact that even above rails core, there’s the interpreter implementers and above them an even smaller group of the ruby core. I’m not really complaining about this at all, its just an interesting way to look at the community that I hadn’t before.

Being a fly on the wall to Yehuda talk to Matz about issues the Rails team is having refactoring, I was witness to an unfortunately rare moment. Knowledge traveling up the chain. This certainly happens to an extent already, but at the language level, for whatever reasons (language barrier, physical distance) the Japanese side of the Ruby community is doing some awesome things that we in the US don’t hear about and vice-versa. I’m hoping more people can make the trip out to the Kaigi and maybe more Japanese Rubyists could come to some of the conferences in the states or abroad.

Ruby for Fun Profit fun

Another theme that I heard again and again is that before Rails, Ruby was a language for hobbyists. Rails changed it, and the community into something else, driven by different needs and goals. I came in with the Rails crew so I cant speak to what Ruby was really like before, but I sensed a sort of dismay about this with some of the Japanese Rubyists. To a lot of them, Ruby may never be their full time jobs. While hacking away at COBOL during the day, Ruby is a wonderful escape. It seems trying to shove Ruby in to the enterprise any way you can, has resulted in a loss of the initial ingenious spark, to do this because its fun. I love that Ruby and Rails are primarily my day job, however, I think in order to stay motivated and continue to like what I do, its important to do some things just for the fun of it. Personally, I forget this a lot: the best way to get re-inspired is often to build something completely useless. Speed, security, unit-tests, and other features we consider important in production code are often the things that bog us down from creating inspired works of code. I think the community as a whole could benefit from a little more fucking around.

Matz told a story in his keynote about how is father gave him a very large sharp knife to bring to school to sharpen his pencils. Sure it was dangerous, but he quickly learned how to use it and it gave him a great advantage over other students. He likened this to not wanting to have to dumb down Ruby so people couldn’t hurt themselves. In the end its better to have a sharp knife and learn how to use it. I would go further and say its important to push the limits of your own comfort with the tool in order to better learn how to use it. As Rubyists of all levels of experience, its important to challenge ourselves and the community for the sake of the challenge and fun, without always worrying about ‘is this secure?’ or ‘hows the test coverage?’.

In general the trip was a great success, I met a lot of people, got to hang out with some good friends and travel around a beautiful country I had never seen before (pictures here). I strongly urge people to make the trip out for Ruby Kaigi ‘10!

One Response to “Ruby Kaigi ’09: Post-mortem”

[…] QuirkeyBlog ยป Blog Archive ยป Ruby Kaigi โ€˜09: Post-mortem […]


QuirkeyBlog is Aaron Quint's perspective on the ongoing adventure of Code, Life, Work and the Web.




QuirkeyBlog is proudly powered by WordPress


  • No categories