Everything In Particular

I’ve been going to raleigh.rb meetings since about the beginning of this calendar year. The meetings were held at a local Panera Bread and a few of us would gather around a table or two and talk about Ruby and Rails. It was evident, even then, that Rails was about to reach the tipping point. Each meeting it seemed like a couple new faces appeared and we started occupying three or four tables.

But the last meeting was just crazy. We took an entire section of Panera with about 30 people. (I took pictures, but they’re stuck on my phone until I get a data cable.) Thankfully Panera was nice enough not to kick us out.

Matthew Bass led us through a recap of RailsConf. After a few RailsConf stories, the discussion veered into all things Rails. More than a handful of people hung out afterwards and talked until the Panera people were basically sweeping up around us. Then we went outside and hung out some more. :) I’m only sorry Nathaniel, who started and organizes this group, wasn’t there to see it.

It’s evident that Panera is no longer a viable venue for raleigh.rb. Thankfully, Redhat has stepped up to the plate and offered their beautiful Raleigh facility for our use. Redhat also donated facilities for BarCampRDU and hosts other local tech-oriented groups. So, many, many thanks to Redhat for supporting the local tech community.

I also just noticed there are now 98(!) members of raleigh.rb. There were about 87 when the July meeting explosion happened, so I wouldn’t be surprised to see 40 or more at the next meetup, especially since the Relevance guys are going to be demoing their hot new Streamlined Rails admin interface. I’m so there.

UPDATE

After jumping through a few hoops, I was able to get photos from my phone without the need for a data cable. Here are two of the three I took. There’s not 30 people in these shots. I couldn’t fit everyone in the frame, and a few people came after these were taken. And, yeah, they were taken into the light. Oh well. If you want to browse the full-res shots, here’s the raleigh.rb gallery I started on smugmug.

I’m going to step up onto a crowded soapbox here for a minute.

If you’re not testing while you’re coding a Rails app, you’re doing yourself, your users, and your clients a disservice. I’ve been on Rails for the past year or so, but only recently really buckled down and got serious about testing. Oh, I’ve done some testing here and there, but it was “feel good” testing. You know, just to alleviate the guilt of not doing it at all.

Nowadays, I won’t add a feature without adding tests for it. I should’ve taken this approach all along. All it takes is discipline. The “I don’t have time” excuse, which I’ve used myself, just doesn’t make sense. The time you put into testing is made up for down the line. In the app I’m working on now, a couple things have really convinced me of this.

I’m catching bugs I wasn’t even testing for. For example, I’ve caught myself on a couple of occasions writing code that depended on empty strings evaluating to false. This is an ingrained habit from other languages. In Ruby, one checks String.empty? for an empty string. In Ruby, one checks String.empty? for an empty string. In Ruby, one checks String.empty? for an empty string. I’ve typed it three times now, maybe I’ll remember it.

UPDATE: You should actually be calling String.blank? It’s another nifty Rails add-on. More info here.

The only thing that caught these mistakes were tests. And most of the time, when I catch bugs like this, they are an unintended (but welcome!) side-effect of what I was actually testing for.

When I test, I also identify areas of complexity. I question why this or that has to be so complicated. Sometimes it doesn’t have to be. By making a feature simpler to test, I make the feature itself simpler. Simple is good.

I haven’t quite gotten to the point of test-first development with Rails. I’m not even convinced that that’s the Holy Grail. As long as I’m testing things as I go, whether I do it before or after I start to write the real code doesn’t seem terribly relevant. I know, I know, testing is about design. But, I still feel like I’m getting design benefits without always writing the tests first.

The other thing I’ve only dabbled in is integration tests, and only then out of the necessity to test across multiple controllers. So far, I’m really liking them, if only because they remove the single-controller limitation of functional test. I’m looking forward to diving into integration tests a bit more. The way you can write stories, devise a DSL, and wrap that all up into integration tests is definitely intriguing.

I mentioned in my last post that the thing I learned the most from at BarCampRDU was leading a session. The session was simply titled Intro to Ruby on Rails. Here’s the thing, and I think Ryan Daigle summed it up nicely: leading a session is different than giving a presentation. I chose to give a presentation and would have been better off leading a session.

The difference is in the level of interactivity, and it’s better for the audience to get them more involved. Leading a session takes more preparation and agility than giving a presentation, because when you are letting the audience direct the content somewhat, you never know where the discussion may lead, and thus, where the boundaries of your knowledge might be reached.

For example, the presentation I gave was originally intended for Python developers who had limited or no exposure to Rails. During one of the morning sessions, I changed it around to be a more general Rails introduction. When I was talking about Ruby blocks and the yield keyword, a Python programmer piped up and said, “Python has yield.” I doubted her, but I looked it up later and she was absolutely right. The Python code base I work with on a daily basis is fairly old-school and generators, which use the yield keyword, didn’t hit Python for real until 2.3, but that’s the subject of another post. I was also clued into Python’s enumerate, which is similar to Ruby’s each_with_index. So, ironically, the boundaries of my Python knowledge were exposed. Good for me, bad for the session.

The other lesson my session experience hammered home was that you never give a slide presentation when a demo would be more appropriate. When the subject of a demo was brought up, everyone wanted to see one. I raced through the slides then got about ten minutes into a demo that was really designed to take about an hour. I ended up finishing the demo with two other people during the hour slotted for the next session. This informal demo was easily the best part of my session. So, demos good, slides bad, let the audience in. I will be better prepared next time.

A funny aside

I was taking notes during the day. Here is one of the sections from my notes:

Cool things that happened before the sessions:

• I met Andy Hunt
• A lot of folks proposed talks, more than I expected
• I got the balls up to propose a talk

During the Rails demo, while I was in the terminal, one of the above lines of text ended up getting inexplicably pasted into the terminal session. I’ll give you one guess as to which one.

BarcampRDU was today. I met some cool and interesting folks and just had a great time. The best experience, and the thing that taught me the most, was leading a session on Rails. There’s lots more I want to blog about Barcamp, but man I’m beat. I do want to say kudos to Fred Stutzman and the entire organizing committee, the sponsors, and volunteers. I think we can all safely say that the event was an unqualified success. More details to come…

I’ll be taking notes and blogging about BarCamp more extensively, but thought I’d start with a little note about the pre-event party at Tyler’s Taproom.

The Dead Kennedys were blaring when I walked in. As I stood in line for food the Sex Pistols came on. I can’t decide whether I feel old or hip when 70s and 80s punk comes on in a public place. I mean, I still listen to the stuff sometimes, but I think the retro chic is lost on me. My first Sex Pistols record was a third generation copy of a cassette, so when Anarchy In the UK comes on, that’s what I think of, that old cassette with my handwriting on it. And, yes, I still call them “records.”

I went with Bart and ended up hanging out with Bart and Jared for most of the evening. We’ve all been programmers in the Triangle for a while and it turns out we have similar experiences and mutual friends. So it was basically a night of hanging out, talking with good folks, and discovering a couple new beers. That’s a win in my book.

And, oh yeah, we went outside to escape the loud music, so I guess I am old, and probably not so hip. :)

During and after DHH’s keynote at Rails Conf, me and the person I was sitting with talked about how the keynote wasn’t really about CRUD, but about good OO design. By embracing the contstraints of CRUD/HTTP/REST, you’re forced into modeling not just your obvious objects, but the relationships between them. Scott Raymond has just written a great post detailing his quest to refactor IconBuffet by embracing the RESTful approach to controllers and actions. What he ends up with is a better software design.

Welcome to my new-ish blog. I’ve tried my hand at blogging a couple times, with varying levels of success. Or, should I say, varying levels of failure.

My grand plan is to write a blogging app, from scratch, using Ruby on Rails. While this would be a fun and useful exercise, it just hasn’t happened yet. And I don’t think I should *not* have a blog, so here I am. And don’t tell me you write a Rails-based blog in fifteen minutes just because DHH did it in a screencast. I’m talking about a real blogging app. I’m as big a Rails enthusiast as anyone, but there’s a big diff between a real blog and what you can do in fifteen minutes.

So, here goes. Hopefully someone will read this thing. But, if not, just writing it is good enough.