Entries from June 2008 ↓

I’ve been to a lot of Ruby conferences this past year. Yet the more that I attend, the more that they seem the same. I see the same people giving the same presentations on the same topics. Sure, they add some content here, drop a slide there, or maybe add a different spin on the same subject as before. But, at the end of the conference, I find myself asking “What makes this conference different than any other conference?” There are more people? There are less people? It’s someplace different? That’s often all that I can say.

At RailsConf, Chad Fowler opened and offered one observation that I found particularly profound. He admitted that he doesn’t do particularly well in a classroom setting — and implied that conference talks are like a classroom environment.

That struck me to the core. That’s me.

At Ruby conferences, I see few people voting with their feet. However, I see many people who barely pay attention to the speaker. Instead, they are on IRC discussing how disappointed they are in the speaker, writing a Rails app or Ruby gem, or just surfing the net.

So why even go to the talks at conferences? Why have the talks? Obviously, most Ruby conference attendees would rather be doing something on their computer, social or otherwise.

Beteween games of Werewolf at Ruby East last year (my humble apologies to Charlie Nutter), Giles Bowkett and I were yakking away. Somewhat randomly, he says something like, “Man, you and I… we’re just scenesters.”

That’s exactly what I’d become. I didn’t realize it until that moment. That had never ever been me but it sure is now. And I bet that’s you too.

You go for the scenius.

That’s a Brian Eno-ism. It’s “the emergent genius of a colocated culture”. It’s that spark you get, that inspiration, that makes you feel smarter just because you’re working near and talking with the poeple that you are where you are.

I don’t see much exchange when there is a talking head, even a brilliant one, at the front of the room with an audience full of mostly silent people. Why is a group of such seemingly independently-minded people as the Ruby community willingly enslaving themselves to the words of one person after another for 45 minutes a pop? Just how educational does this really turn out to be?

“This town needs an enema” - The Joker, Batman (1990)

Why should Ruby conferences be traditional conferences? Just because everyone else does it that way? Odd. I don’t see this community (communities?) as followers.

Giles asserts that we’re a weird bunch of people. Hell, I thrive on it — just as much as I gag on the lack of weird when I return to my day job from a conference.

So why not just be weird instead of being like every other conference out there with their clearly delineated speakers, audiences, and Nascar-like corporate branding?

No I don’t mean Ruby Fringe (although I am going).

Let’s invert the process. More discussion. More hacking. Less talking heads.

Let’s make some awesome Stone Soup.

I’ve discussed this with some people around the community. The often conservative and stodgy DC Metropolitan Area may hold the first Ruby BarCamp. Does someone want to beat us to the punch? I triple-dog dare you.

Update 6/29/08: Bryan Liles pointed me at an article by Dave Winer about the “early days” of unconferences. His timing is serendipitous. Come on, people! Let’s make something happen!

This evening, I gave my first presentation of Unit Testing J2EE from JRuby to the Northern Virginia Java User’s Group. It was a very interesting experience. The audience asked some interesting questions — but it was also an insightful reminder of my origins as an engineer. Out of approxiately a 30 member audience, perhaps 4 had done any TDD and only a single one had ever used mock objects. While mocks have their origins largely in Java (at least their initial implementations), it is interesting to see that they have been far more readily adopted in the Ruby community than Java.

Also, Mocha suddenly jumped from v0.5.6 to v0.9?!

So jrsplenda broke when I tried to demo it on my wife’s spiffy new Macbook Air — as I was foolish enough to just ’sudo gem install mocha’.

Who the hell has a public release at 0.5.6 and then another at 0.9? I am so integrating FlexMock into jrsplenda in the next release. I can’t see Jim Weirich doing anything like that.

I’m halfway tempted to redo and give my BDD with RSpec talk to NoVaJUG as a JRuby-Java BDD talk. More people should be doing BDD and not merely those of us working in dynamic languages. Were it so, I imagine that I would encounter far more testable and maintainable code in the Java community.

Slides from the presentation are available here

I’m extremely excited to announce that ERubycon has accepted my proposal to speak on JRuby testing of JEE. ERubycon is unique in that it is expressly focused on Ruby in the Enterprise. While “enterprise” is a squishy term to me (my take on it is “legacy/internal facing/business-to-business/large scale development”), I suspect that the constituency will be somewhat different than the other Ruby conferences that I’ve attended this past year (i.e., RailsConf, RubyConf, Ruby Hoedown, and Ruby East). As the majority of my work falls clearly into the enterprise space, I’m looking forward to ERubycon.

ERubycon is August 15-17 in Columbus, Ohio. I hope to see you there.

Last week, I wrote about the pain of Java unit testing. At the end of it all, I said that I would supply some answers “tomorrow”.

One week and one RailsConf later, I’ll call this “tomorrow”.

In the previous article, I listed a handful of commons Java idioms that reduce testability. Three out of four of the issues may be rolled up into a higher level of abstraction: encapsulation kills. The remaining point may be summarized as Spring XML == code that most developers don’t test. Encapsulation prevents developers from injecting mock objects into their code. Without mocks, the unit under test lacks isolation. Without isolation, your unit test is an integration test at best and a massive FAIL at worse.

If you endured a Computer Science curriculum in college, I’m reasonably sure that the professor of your second or third CS class repeatedly hammered home: encapsulation is a key tenet of good object-oriented design. However, many dynamic languages only provide a brief nod, if any, to the encapsulation gods. For instance, Python does not support private or protected members. While Ruby does, it is trivial to route around those protections. What some may not realize is that, in this respect, Java is little different than Ruby.

Yes, that’s right. Java can be a bit on the promiscuous side of things too.

Continue reading →