Posts from ChadFowler.com...
Not that it should be too surprising to me, but (even as a long time Rubyist) I’m finding the Haskell posts on Slick or Slack to be the most beautiful so far. When I took my first look at Haskell years ago, I thought it was ugly. Every progressive year it strikes me as more and more beautiful.
Why am I not a Haskell programmer, then? More on this in an upcoming post.
In my previous post, I asked for examples of great Ruby code. I got emails, comments, instant messages, and twitter messages with suggestions. I’d still like more.
But one really cool suggestion came from an idea Bil Kleb and Peter Provost had. They proposed a Hot or Not -like site for code.
I thought that would be fun, so Bruce and I whipped something up in a couple of hours over the weekend: Slick or Slack?.
It’s not done yet, but we deployed it anyway. My experience helping Ze Frank with Color Wars 2008 has convinced me that deploying things that aren’t done is more often a good idea than not. If for nothing else that for mental health reasons.
What we want to do now is to start collecting potentially “Slick” code snippets. This could mean beautiful code, clever code, code which does something awesome, or whatever. You can also post code that sucks. We just need code to start the tallies running.
When you visit the site, you’ll be presented with two code samples, probably doing totally different things. They might even be in different languages. Your job is to choose the better of the two. If you can’t make up your mind, just hit refresh.
I doubt this is going to unearth great code in the same way that I doubt Hot or Not unearths great people. But I hope it will be fun to play with. It will probably be broken and we know it’s lacking some necessary features to make it more useful and/or fun. Suggestions are welcome. Just don’t take it too seriously.
Tonight, Rich, Marcel and I spoke at the DC Ruby Users Group. Instead of choosing a topic, preparing a set of slides, and droning on about something for an hour we decided to involve the group to help us answer a question. It’s a question I get a lot when I do training with The Pragmatic Studio: “Which Ruby projects should I look at to see examples of great Ruby code?”
I have my standard answers (I’m sure we all do), but two things occur to me about answering such a question. The first is that when asked a question like this, I have a gut reaction. There are names that spring immediately to mind. If I scrutinize these reflex reactions I realize that I haven’t really examined the code I’m thinking of in enough detail to call it great. So though I have some cursory knowledge that makes me pretty sure when I give my recommendations (I’m holding off on naming specifics so as to not influence your answer to this question), I’m not 100% sure which projects contain great Ruby code.
The second realization about this is that some of the names that spring to mind are based on potentially the wrong criteria. I, like all humans, am more likely to mention something popular than something obscure. There is also a Ruby community folklore. Some names are synonymous with “great”. But it’s just folklore. So the knee-jerk reactions are at risk of being heavily influenced by the Ruby popular culture. Looking at how successful popular culture is at picking great music, visual art, fiction, and other artistic mediums, it’s pretty clear that we shouldn’t trust pop culture when making decisions about which projects are composed of “great” code.
So we asked the DC RUG: “Who are the greatest Ruby programmers in the world?”
Then, all together, we looked at code written by the people they came up with.
Some of it was beautiful. Some of it was ugly.
We talked about what made some of it beautiful and some of it ugly. We talked about the importance of writing beautiful code. It was fun.
Anyway, I still don’t have a satisfactory list of great Ruby code. I’d like to build such a list. So, please leave a comment saying the name of an open source Ruby project you feel represents truly great Ruby code.
I’m always looking for ways to get humans together for meaningful (potentially lasting) interactions at our conferences. So we’re trying something new this year during the tutorial day. It happens on the first (or 0th?) day of the conference on purpose: so the work can continue for the rest of the conference. My hope is to bring project owners/committers together with aspiring contributors and bring more people into the fold of projects which need help. Think of it as a room full of code sprints happening all at once. Here’s the description:
Project Owners: Do you have a project you’d like to work with other people on? Maybe it’s an established Open Source project. Maybe it’s a new idea. Come find like-minded developers and spend the day hacking together.
Developers: Are you looking to get involved in an Open Source project but need a bootstrapping session to get you started? Looking for chances to meet other developers and establish collaborative working relationships? Looking to learn by collaborating with others? Come find a project and spend the day sitting side-by-side with one or more of its developers learning the ropes and contributing code.
RailsConf is the largest physical gathering of Ruby and Rails developers internationally. Let’s take advantage of all being in one place at the same time AND take the chance to give something back to the projects and community which we so greatly benefit from.
In the morning, project leaders and representatives will have a chance to make a short pitch for their projects and the work they hope to get done. For the rest of the day, groups will self-organize and write code! Roll up your sleeves and prepare to learn, teach, and most importantly, contribute.
Go to this page and add your project or idea to the list of projects likely to be active in the Code Drive.
I’m out in not-so-sunny Cupertino, CA with Dave teaching an introduction to Ruby course for a big company this week. Though I’d always rather be back home with Kelly, we’re having a great time out here. In addition to a lovely dinner with Laurent, Jordan, and Luke from Apple last night, I’ve been having a blast introducing a 15-person group to Ruby for the first time.
I do a lot of advanced level courses and Rails courses, but this one is rewarding in a different way: I’m reminded of how absolutely beautiful the Ruby language is. When you use a language every day it’s easy to forget the things about it that originally roped you in. I’m finding this experience to be an excellent way to relive that through the delighted looks on the faces of the students in this class.
Dave and I are doing this course together for the Pragmatic Studio later this month in Denver. If you or someone you know have been meaning to dig into Ruby, I invite you to come share the joy with us
Scanning through the videos this morning, I was reminded of what a great time I had at RailsConf. Planning is well underway for RailsConf 2008 (keep your eyes peeled for registration to open soon). An initial batch of proposals have been selected, and I’m already excited about the program this year.
The Rails community is maturing, and the level of proposed content has matured along with it. Expect more advanced content this year from a more experienced (obviously) group of practitioners.
Seeya there!
This has been a long time coming, and it is admittedly kind of arbitrary, but it feels good to see our little package manager growing up:
Macintosh-2:~ chad$ gem -v
1.0.0Thanks to Eric for gradually taking the lead over the past year and putting the nail in a few of the long-standing TODO items for RubyGems.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/284268
You may remember that I was working on Advanced Rails Recipes earlier this year. I’m not anymore. I’ve been over-committed and I finally decided to face facts and withdraw myself from the authoring process.
That’s OK though. Someone has pressed the “Kick Ass” button on the Mike Clark book-writing machine, and Advanced Rails Recipes has appeared in beta.
The book is a collection of recipes by Mike and top members of the Rails community. There is literally no one I trust more to put together timely, trustworthy advice on how to develop Rails applications right more than Mike. This one is a must-read, and beta is a great time to get in on the action in that it gives you a chance to make an impact on the final product.
The book is not yet complete, but it’s already worth the price.
There were more proposals for RailsConf this year than there were attendees at RubyConf 2006. This means two things:
1. The state of the Rails community has changed significantly in that it has grown and there is a larger subset reaching the expert level.
2. It’s going to take us a while to sort through all of these proposals and make selections. Apologies in advance.
It’s fun to watch the rush to be first to market with a new piece of open source functionality. You probably already know that Amazon released their SimpleDB this week. I was thinking we might whip up a Ruby wrapper but I knew if I just waited a day or so there would already be libraries available. Tonight I checked RubyForge and the three most recent projects are all SimpleDB wrappers:
It will be fun to see which one (or more?) of these gains and keeps mind share. Competition among open source projects is an interesting topic given the abstract nature of the stakes.
Sam Larbi is running a cool little contest over on his weblog. The idea is to try to create a competition on learning new programming language paradigms. This is obviously a topic that’s dear to me (he’s referencing my book), and I think it’s cool that Sam has turned it into a contest.
I also generally like the idea of taking some potentially valuable item that you haven’t used and throwing it onto the internet to promote learning, good will, fun, or whatever. When I get home I may go out into the garage and see what I can find :)
Today I installed Apple’s latest OS release: Leopard. One of the most exciting features for me as a Rubyist is the inclusion of a well-designed Ruby installation, complete with RubyGems and a bundle of pre-installed gems for the software I typically use as well as some of the Mac-specific gems most Rubyists would like to have (dnssd, rubycocoa, etc.)
Some of the gems shipped with Leopard are slightly out of date, as can be expected. But since they shipped the software as gems, updating Rails (for example) was as simple as ‘gem update rails’.
Apple has shipped Ruby as one of its Frameworks and has provided first-class integration with its development tools for the first time. They’ve been working with us in the community for nearly a year to get this right and it shows. Kudos to Apple and especially to Laurent Sansonetti and Jordan Hubbard for a job well done.
I can finally remove that extra non-Apple Ruby install I’ve been carrying around for years now and just use the Apple-supported Framework.
(FYI, Giles has completely jumped the shark on this one. Don’t let his poo-pooing worry you.)
When I was in middle school, my friends and I started a rock band. We picked a name; we had a logo. If we’d had money the next obvious step would have been to print band t-shirts. This all happened, of course, before we ever learned to play any relevant instruments (saxophone and bassoon don’t count).
For well over a year, I’ve been wearing a Scotland on Rails shirt. Scotland on Rails has a name, a logo, and t-shirts.
Now they’ve got a conference.
Organized in part by my good friend and big thinker, Alan C. Francis, Scotland on Rails is sure to be a great time. If you’re in or around the UK, I highly recommend putting it on your calendar (or at the very least considering a mouse pad or pair of boxers).
We’ve just opened RubyConf registration. There are more spots than last year, but it’s probably still going to sell out. I would book soon if I were you.
In the comment thread of a previous post on this site, Chris Taggart made an interesting criticism of my Facebooker Facebook API. It seems that, on a high level review of the code, he found it to be well-craft and well-tested. His criticism was that, unlike in RFacebook, I chose to implement a concrete set of Ruby classes to abstract the underlying workings of the Facebook XML API away from Facebooker’s users. RFacebook, on the other hands, employs a trick using Ruby’s method_missing, to catch undefined method calls and to transform those method calls into HTTP posts which conform to Facebook’s HTTP/XML endpoints. Here’s what an RFacebook call might look like (from the RFacebook Web site):
friendUIDs = fbsession.friends_get.uid_listfriendNames = []
friendsInfo = fbsession.users_getInfo(:uids => friendUIDs, :fields => ["first_name", "last_name"])
friendsInfo.user_list.each do |userInfo|
friendNames << userInfo.first_name + " " + userInfo.last_name
endThis results in two Facebook XML API calls. The two method calls on the fbsession object are undefined, so fbsession converts them to HTTP posts to the Facebook XML API methods called “facebook.friends.get” and “facebook.users.getInfo” respectively. Furthermore, when “uid_list”, “user_list”, “first_name”, and “last_name” are called, RFacebook again employs a method_missing trick to generate an XPath expression searching for the requested data in an HPricot DOM.
Here’s the equivalent Facebooker code:
friend_names = session.user.friends!(:first_name, :last_name).map do |friend|
"#{friend.first_name} #{friend.last_name}"
endIn this code, the same API calls happen as in the RFacebook example, only we don’t explicitly invoke them.
Chris’s (albeit tentative) concern was that, since Facebooker implements objects and their methods as first-class Ruby constructs, the API would somehow be more brittle and less resilient to potential future Facebook XML API changes.
I found it especially interesting that Chris chose this as his only point of criticism, since RFacebook’s method_missing trick and return of an HPricot XML parser object from each API call were two of the key reasons we decided to scrap RFacebook after writing an application with it and implement our own Facebook wrapper library.
As I started to formulate a response, instead of taking my own motivations for granted, I decided to take some time to question my own assumptions. This all led me to question (and to answer for myself) why we write this sort of wrapper library to begin with. What follows are my answers.
Perhaps the primary reason for building a concrete layer on top of a low-level API like Facebook’s is to make the code which uses it less brittle. The scenario Chris was concerned with was that Facebook might change their API, requiring Facebooker to be changed to match it. My point exactly, Chris. If Facebooker didn’t hide the implementation details of the XML API from its end-users, a change in the XML API would require every application which uses Facebooker to change. Magic missing method calls would have to be renamed or changed. If “facebook.users.getInfo” were to be changed to “facebook.user_info”, the calls to “session.users_getInfo()” would need to be changed to “session.user_info()”.
Sure, you could hack the API so that “users_getInfo()” and its parameters were munged into Facebook’s hypothetical new format, but then our API would pretend to be low-level and direct, which would lead to some opaque application code.
When I’m writing a Rails application controller or the controller for a desktop application (both of which I have been doing with Facebooker), I want to think in terms of the domain I’m modeling. In a Rails application, it’s commonly accepted that fat models and skinny controllers lead to well-factored, expressive, and maintainable code.
This is partially because, in the controller layer of an application like this, the code’s job is to (as Marcel Molina said to me recently) codify a dialogue between the domain objects in a system. In other words, when you’re developing an application about users, their friends, their affiliations, and the groups they belong to, the controller should deal with those concepts. It doesn’t make sense to deal with, say, a user, a database connection, the user’s friends, their XML representation, a shared photo album, and HTTP connectivity issues all in the same code.
My brain doesn’t want to jumble all of that together. When I’m trying to look at XML parsing code, domain logic gets in the way. When I’m trying to see how users and their friends interact, XPath is line noise.
Kent Beck refers to this in his Smalltalk Best Practice Patterns as a guiding principle of good API design, specifically having to do with how to decompose your code into methods. His rule of thumb is that one way you know it’s time to create a new method is when the code in one method mixes two or more levels of abstraction.
By abstracting the implementation details of XML and HTTP away from the high level of the API, code becomes more testable. In this case, it’s true for Facebooker itself, but more importantly, the applications that use Facebooker are more testable with a layer of abstraction between them and the XML and HTTP calls which are going on under the covers.
When you’re trying to test a Rails action, it’s much easier to create a User object and set its attributes (first_name, last_name, etc.) than to generate a DOM of sample data. Sure, Ruby being as dynamic as it is, you could create a stub at runtime and forego dealing with the library’s implementation of User altogether. But you shouldn’t have to.
It may seem like a nitpick, but as a Ruby programmer I want to use APIs that look like Ruby code. “fbsession.users_getInfo()” looks like PHP code to my eyes. It’s no surprise. Facebook is written in PHP, and its HTTP/XML API was designed by the same PHP programmers that created Facebook. Wrapping the Facebook API allows me to isolate and hide the PHP idioms, such that the code I use reads like “normal” Ruby code. You could argue that this is not a technical issue, and you’d be right. But I believe in the power of both consonance and dissonance in software development. Dissonant code stands out and alerts the reader that something strange and exceptional is taking place. Sometimes that strange and exceptional thing is just bad code. Sometimes it’s an unusual technique that should be highlighted.
When I see non-idiomatic Ruby code, it tells me one of two things. The first assumption I make is that whoever wrote the code is not a Ruby programmer. That’s usually the case. The second is that the programmer is employing a new or unusual technique to accomplish something which is difficult to do without that technique.
Having implemented a wrapper for the Facebook API, I don’t think there’s a need for dissonance. There’s nothing difficult or unusual going on at any level of Facebooker, so it stands to reason that there should be no dissonant section of the library and that it should all read as idiomatic Ruby code.
I love the tricks you can do with Ruby. method_missing, const_missing, autoloading, and their friends make really powerful things possible.
But they do so at a price. When something goes wrong in a piece of code that relies heavily on one of these tricks, it can be much much harder to track down. So the decision to use such a tool shouldn’t be taken lightly. These are power tools. Used effectively, really cool things can happen. Used incorrectly, you can easily find yourself limb-less and bloody. So when you decide to use one of these power tools, you have to ask yourself: is it worth the risk?
Where possible, especially in a library already dealing with something abstract and out of our control (e.g. someone else’s XML API running on their own HTTP servers of which we have no direct visibility), explicit and concrete are much better attributes than abstract and fuzzy. If you run into a problem or question with part of a library for which you have the source code, explicit method definitions and concrete APIs under the covers are much easier to navigate than parsed method names magically constructing arguments to HTTP posts.
In general, if you’re dealing with code which is out of your control, implicit and hidden from view, it’s helpful if the code which surrounds it balances the abstractness with a nice concrete anchor.
This is a summary of many of the usually-abstract ideas that go through my head when I’m creating APIs that wrap other APIs. I’ve been designing wrapper APIs like this for ages, so it’s been helpful for me to convert intuition into a set of hints. I hope these ideas are helpful to others. If nothing else, if you ever have to use an API I’ve written, you’ll at least know why it’s written the way it is.
As I mentioned previously, Marcel Molina and I are doing a full day testing workshop for charity at RailsConf Europe next month.
Dr. Nic Williams hopes to attend but rather than donate the required minimum $75 directly, he has chosen to auction off his MyConfPlan web site and to then donate the proceeds as part of his registration for the tutorial.
So now’s your chance to kick start your way into Web 2.0 entrepreneurship, help Dr. Nic fulfill his goal of learning more about testing, and develop good karma all in one action.
It’s easy to give money. It’s much harder and more personal to give your time, passion, accomplishments, and creativity. Dr. Nic is a shining example for the rest of us. Thanks, Nic!
RailsConf Europe is right around the corner, and on the first day Marcel Molina and I will be doing a full day tutorial on advanced Ruby and Rails testing techniques. And, in the tradition of Dave and Mike’s Rails Guidebook, we’ll be requesting a minimum $75 tax deductible donation to charity of all those who attend. At RailsConf this year we raised $33,000 for charities, and we hope the spirit of giving continues.
I travel a lot and meet a ton of Ruby and Rails developers in the process, and I’m always surprised at the seemingly unquenchable desire for testing information. So we’re hoping that an entire day with a couple of developers who have been seriously passionate about testing will help at least plant a few seeds and satisfy some of the demand. The fun part is that we’ve both learned new tricks ourselves as we’ve prepared. That’s one of the selfish joys of being a speaker, trainer, and author. No matter how well you know a topic, you always learn things when you go to prepare a tutorial, talk, article, or book on that topic. And, as we all know, testing and test-driven development is a deep topic.
As always, even if you’re not planning to attend, feel free to give to the cause.
RubyConf is going to be held on November 2-4, 2007 in Charlotte, NC, USA. This is the international ruby conference. Matz will be there. And so on.
The proposal deadline is right around the corner. This coming Monday at 5PM EDT. Some of you have started proposals but never submitted them to get them out of draft state. Some of you have forgotten about the deadline. Some of you didn’t know proposals were open at all. Hopefully this will help you to spring into action.
Let us know if you run into any snags with the proposal system. We’ve had some email issues that have prevented registration confirmation emails from getting to their intended recipients.
UPDATE: The deadline has been extended to Wednesday at 5PM. We didn’t want the technical issues with the proposal site to get in the way of good proposals being submitted.
UPDATE UPDATE: I got the deadline wrong here. I meant to say Thursday. I promise I didn’t do that on purpose ;)
Friday and Saturday, I attended the first Ruby Hoedown at RedHat HQ in Raleigh, NC. The Hoedown was one of many regional Ruby conferences popping up all over the place driven in small part by Ruby Central’s conference grant. Nathaniel and Jeremy did an excellent job putting the conference together. It was flawlessly executed with an exciting program and a good dose of southern charm.
Here’s a braindump:
The conference pre-started with me, Bruce Tate, and Marcel Molina giving a two and a half hour testing workshop for charity. Taking a queue from the Dave and Mike’s Rails Guidebook, participants gave a donation ($50 recommended) to attend the workshop. We ultimately raised roughly $3200 for the Food Bank of Central and Eastern North Carolina. A large portion of the workshop consisted of me and Marcel interactively improvising the development of an application in test-first style while drawing the questions, comments, and criticism of the audience. The format worked well (from our perspective), and we covered a lot of great material. We’re really looking forward to our FULL DAY testing workshop for charity at RailsConf Europe in Berlin next month. (Next month’s workshop goes to support Habitat for Humanity. We’re happily accepting donations regardless of whether you attend.)
The main conference kicked off with a talk from Ezra Zygmuntowicz about Merb. Merb started out as a complement to Rails—-something you whip out when you need multi-threaded request processing, such as big file uploads and long-running application logic. Rails isn’t always well suited to this sort of thing, because Rails is single threaded. To scale, you have to add more processes, which adds a potentially unhealthy amount of memory overhead. Merb is a multithreaded, lighter weight Mongrel-bound (for now) framework.
Now, however, Merb is turning into a full-blown Rails clone (Actionpack clone really). I remain fully skeptical. I understand Ezra’s stated reasons for doing it (along with a few implicit ones I think), but I think we already have a Rails, and incremental improvements are, well, incremental. It would be nice to see someone taking a leap as opposed to a step. Even before Rails came out, I think the industry had seen enough MVC. I am hopeful that some of Ezra’s improvements make it back into Rails. His desire to keep things lean and unmagical is commendable.
Next up was Jay Phillips, whose Adhearsion framework for VOIP applications completely blew me away. Adhearsion is a perfect example of someone taking a powerful domain with a historically ridiculous development model and taking a full evolutionary step forward. Jay’s framework takes developers from what literally looks like the dark ages (have you seen an Asterisk dial plan?) to a beautiful and powerful API with modern automation wrapped around it.
We Rubyists have been looking for another killer app following Rails. Adhearsion might be it. Seeing Jay speak made me realize that we have that same combination of disdain with the current state of affairs, courage to slap the (telecom development) industry in the face, intelligence to innovate a solution which brings programmer joy and the people skills and marketing sensibility to push it over the edge. If you care about Ruby, watch Adhearsion closely.
The day closed with Bruce Tate giving a keynote on the direction of Ruby. He drew some interesting parallels to past technologies and also led us through a series of scenarios about where Ruby and its community might be headed. The most convincing one can be summarized as using Ruby to build elegant APIs on top of existing problems which do for those problems what Rails did for web development. See Adhearsion.
Andrea O. K. Wright from Chariot Solutions gave a surprisingly thorough and engaging talk which ended up being a survey of the various game libraries available for Ruby. I’m an avid gamer and got interested in computer programming because I wanted to be a game developer, so I’ve taken this tour myself a few times. But it’s been a while and I was simply amazed at how far things have come. As Andrea spoke, I downloaded literally every library she was discussing and tried them out. I had some problems with the SDL bindings on my Mac, but I had instant success with both Gosu and Shattered Ruby. I’m not sure if we’re ready for Unreal Tournament-style games in Ruby but simple games are finally, well…simple to create. Definitely check out Gosu if you even have a passing interest. Really fun.
There were a series of quick lightning talks. They were good, but there were too many to enumerate. I’m liking this format more and more every time I experience it.
During lunch Jeff Casimir and I organized a “BoF” (I hate that term) on Ruby for Social Change. Jeff booked the smallest spot, thinking we were going to be a tiny crowd, but we ended up cramming a large group into the room. The discussion was lively and loud and the people were passionate. With only 45 minutes to talk, we came out of the meeting with some ideas about organizing volunteers to give their time to produce real applications for non-profits/charities who could use the projects to make impactful change. More on this soon I hope. We have a RubyForge project set up for the group.
If you’re interested in this topic and interested in helping to shape what we do, please do drop in and sign up for the mailing list once it’s activated. The first order of business (in parallel to doing things like setting up a web site) is to find a project with a real customer to rally around. If you have ideas, we’d love to hear them.
I was skeptical because of the title of this talk, but I trusted that Ken Auer was going to deliver something interesting, and my skepticism turned out to be ill-founded. Ken is an old Smalltalker and one of the leaders in both the patterns and agile movements. His talk was a well-thought-out history of Smalltalk and ultimately a comparison to Ruby’s adoption curve. I won’t do this one justice with a summary, but I recommend watching it when the conference videos go live on the Confreaks web site.
Jared Richardson gave a really engaging and fun talk on extending Ruby with C. It was review for me, but the audience was totally into it, and 2 out of 6 people who Nathaniel asked to tell one thing they were excited about learning at the end of the conferenced cited material from Jared’s talk. It’s easy to forget how elegant and human-friendly Ruby’s C API is. If you’re the kind of person who has a natural aversion to that kind of thing and have been avoiding it, you really should take a Saturday morning to crack open the Pick Axe and go through some of the C extension examples. I think you’ll be pleasantly surprised. Lots of potential gain for not much pain.
I’m not going to say much about this, because I hope to take this topic into a separate post, but Marcel’s ideas from this talk have already changed the way I think about my own code as I write it. Those that know Marcel and have worked with him know that he is obsessed with keeping code beautiful. Whether it’s a shell script, a systems programming task, or a high level API, he creates some of the most consistently beautiful code you’ll see in Ruby-land. In this talk, Marcel decided to take this passion for beauty and try to more clearly define the elements that make code beautiful. The result is a small but useful framework for measuring trade-offs when developing software. I’m looking forward to seeing these ideas develop. The keynote itself was short but the Q&A and discussion about it expanded such that Nathaniel ultimately had to cut it off. Obviously a topic that inspired much passion.
This time literally. We took a group to a nearby hotel and played Werewolf until around midnight. If you don’t know Werewolf, you owe it to yourself to try it. We played 5 nights straight at RailsConf this year, and I feel like some lasting bonds were made with people who I might not have even met otherwise. I think our community is too cliquey and fragmented sometimes, and Werewolf is a powerful tool (yes I’m talking about a game and saying “powerful”) for changing that.
We’ll be trying to put together a game again in a couple of weeks at The Rails Edge in Chicago. If you’re coming to the Rails Edge, read up on the rules before-hand and join in. If you’re not yet signed up it’s not too late.
Thanks to last night’s players and my (some-of-them) new friends Lyle Johnson, Tony Devlin, Jim Meyers, Chris Redinger, Evan Light, Devin Mullins, Carl Youngblood, Coby Randquist, Joe Martinez, Rick DeNatale, Ted Behling, Ryan Daigle, and Marcel. I hope to see you guys around soon.
If you’re in the South, I highly recommend watching for an announce of the second Ruby Hoedown. Until then, keep your eyes glued to RubyConf.