Rails Conf Friday

So this was the first "real" day of RailsConf. Thursday was a tutorials day. Friday started with Chad Fowler, organizer of RailsConf wanting us to contribute money to charity, which he felt would alleviate some of the bad rep that Rails lovers get for being, in his words, arrogant bastards.

From that point, there were 5 sessions, each about 50 minutes long. The first session was on writing clean code in Ruby by Robert Martin who modified the talk he gives in Java accordingly. He gave a moderately easy example emphasizing test driven development. Simple talks usually fare better than more complex ones. Sure, a few people will find it trivial beyond belief, but more people will get it than not. He was suitable energetic, even if he looked like, oh, I don't know, some cross between Al Franken and Peter Graves.

His simple message was that it's worth spending the time to keep code clean, but you have to write tests to make sure your efforts don't cause the code to break the tests.

The next talk I attended was Going Off Grid: Using Rails as Platform given by a guy, Evan Weaver, who looked awfully young. In many ways, he was as unpolished as Martin (the guy who gave the "Clean Code" talk earlier).

First, let me say something positive. Evan seemed like a pretty sharp guy. He's mucked around in the depths of Active Record, which handles persistence in Rails. He's messed with Django. He's looked at alternatives to databases and SQL which he feels is overkill for most web apps. This guy seems to have pretty serious programming chops.

Evan suffers from problems inexperienced speaker have which is they act the way they normally do. In many ways, speaking well is acting. You have to be more outgoing than you would normally be. And, you're there to sell something--anything, to us, the consumer.

For example, Evan started off discussing his bioinformatics project. First thing he should think about is "who cares?". It's a legitimate question. Most people aren't doing bioinformatics. So, he needs to pull out the key features of bioinformatics that could apply in other situations, or to at least characterize some of the issues surrounding writing code in that domain, and also make a compelling case why we should care.

If Evan had, say, pointed out that there are many domains where we simply have to interact with code written in other languages and that Rails has some shortcomings, then that might be a way to frame the talk.

If I had some advice I'd give to Evan, I'd say "write down what you want the people to get out of your talk--the top three points". That alone would improve his talk tremendously.

The second piece of advice. Speak louder. This is tough. People don't like to yell, and sometimes you practically have to yell to properly give a speech. This has a second advantage. It makes you seem more engaged. Again, speaking is acting, and you have to seem somewhat interested in what you're talking about.

In any case, what he said was over my head, though I'm willing to say it might have been suitably over a lot of people's heads. More focus on the presentation would have helped.

The cats were cute, though it seemed a common theme with several speakers.

The next speaker that I saw was after lunch, which I have to say, was moderately dreadful. I have braces and my teeth aren't great, so eating an oversized sandwich with tough bread was not so good. I have to give props to No Fluff for having decent lunches. These feel like econo-lunches, and were not very good. RailsConf should seriously think about how to upgrade the quality of food given the amount it cost to attend.

I went to a talk by Jeremy Sydik (I think) about Rails in higher education. His was the weakest talk I attended the whole day. I sorta knew this would be the case and still I went, hoping it would try to achieve something more.

First, many education talks end up not being about education. In this case, it ended up being about intellectual property and how universities want to patent software which makes it difficult to distribute education software. He also said he was a one-man shop. He basically said it was pretty easy for him to set things up, and did something basic within a week. His goal was to help others do something similar, i.e., how best to sell Rails to a university (the idea, not literally in terms of money).

There were several problems with the talk. First, like Evan, he talked a bit too softly. Second, other than pointing out that it's easy to develop in Rails, he didn't really have much to say about Rails. He didn't even show the applications he had written, so I don't know whether he wrote something completely trivial or not.

This is the problem with applying technology to education. Often, it's hard to write really good software. It's easy to write online quizzes, but do they really do a good job of teaching? One imagines AI that could adaptively tell you what your weaknesses are and help you coach you to get better at them, but that's an incredibly difficult problem.

Ultimately, the problem with education talks is that they are rarely about education.

And then he completed the talk 20 minutes early, and there was very little takeaway. It just wasn't all that useful. It would have been interesting if he had solved a problem in Rails that is peculiar to higher education but not seen in other apps. Or if he had some advice on what Rails features allows him to do that, say, PHP doesn't, other than its ease of use, or what web apps lack feature wise that prevent him from achieving a dream app that would solve all problems.

He didn't address the issues of what makes effective education apps. There was a ton of stuff he could have covered.

And to think, I could have attended a talk on video transcoding. I should have. That, or testing.

The fourth talk I attended was by Adam Keys. Adam is pretty funny in a deadpan way. He did a riff on this guy named Skip, whose ETech talk on identity zipped through 30 slides in what seemed like 30 seconds. It's funny even if you don't know he's making fun of Skip, but it's pretty nerdy of him to pull that out.

He wanted to talk about reading code. One problem with this is that any interesting code is likely to be tough to read. He wanted to illustrate the point by digging into code that inspired him, but it ain't easy to follow. He could have taken another tack, and decided to say what lessons he learned. Ideally, such talks would illustrate how he might have written the code once upon a time, and how he would now write the code based on what he learned.

Adam had a pretty high level of difficulty with this talk, but unlike, say Evan's talk, where Evan's talk lack real focus, Adam's centered on how to read code. He might have pointed out "wished for" tools that might make learning to read code better. Although he advocates reading other people's code because each of us has to do it, as gross as this skill sounds. Can we, however, write languages that make it inherently easier to read.

Indeed, code is often written to be read. It begs the question "Why is code hard to read?". Can we leverage what he and others have done to provide better running commentary of existing code, or is it simply something we, as programmers, ought to do (i.e., read lots of code) even as we find it distasteful.

Adam started off funny, but ended off a little too deep for me to follow. I'm not sure what I could have done. The idea of the talk seemed more interesting then the actual steps of watching him go through code. I doubt I could learn at the speed he was covering it. This seems like one of those talks that it's better to have a "coach" guide you one-on-one to follow the code, if you're unwilling or unable to do it yourself.

I skipped the next talk because I came to the following realization. Hotels that say they have high-speed Internet often have no clue if they do or not. They should advertise their download speeds, but they're probably too clueless to do that. I wanted to upgrade Ruby on my Mac to do Rails. But I need XCode, which is the developer tools that comes in a disk with the Mac but is not installed on it by default (too ostensibly save space, but now I think that's totally silly).

Unfortunately, XCode is a beast at 1 G in size. The convention center caps download rates to about 60K a second which turns out to be loads more than my hotel which dribbles in data at maybe a tenth of that. It's awful, and they probably don't even know it. I was thinking of going to Starbuck's and fishing out ten bucks to hopefully get higher bandwidth.

But I thought of another idea.

Maybe there's an Apple Store in Portland and they have the developer's disks which I can install.

And indeed, there was one, and better still, it was within a few blocks of Powell's, so right in the route traveled by the MAX. I was heading downtown for the second time today. The first was to search for a breakfast place recommended by someone attending Railsconf who lives in Portland.

Unfortunately, the location falls under the heading of "Stupidest City Idea Ever". Apparently, cities like streets to go on and on, and yet, when they do, they run out of numbers. No problem, we'll have the street have two names, one called SW for Southwest, and one called SE for Southeast. Thus, SW Morrison and SE Morrison. And although they may share a number, like 1300, they will be man blocks apart.

So I looked for this breakfast place and eventually found a different one, and used the city wireless (amazing they had some) to discover I was nowhere near this breakfast place. So I headed back up to the convention center.

Anyway, later that afternoon, after trying to locate the Apple Store, the guy said I had to download. But the wireless at the Apple Store wasn't really any better. Occasionally, it would get to 120 KB per second, which is great, but I needed something like 200 MB or more to download within an hour.

Fortunately, the genius bar guy (yes, genius is bandied too easily here) went to the back where they probably had a wired connection that was much faster than the wireless. He said it could be done in an hour. So I ate at the food court, then headed to Powell's, and eventually returned about an hour later. He had burned the disk, and I was able to install.

Then, I had to rush back, where I listened a bit to some guy talk about whether ROR was Enterprise or not, then another Smalltalk guy named Avi who said Smalltalk and Ruby were basically the same and so Ruby should leverage the Smalltalk VM to do its VM, and finally Ze Frank, Internet comedian, for lack of a better word, who was pretty funny, though possibly not all that relevant to the conference. And his name is pronounced "Zay". That finished around 9:30.

I then went to a BOF (Birds of a Feather) on documenting Rails. I though this might be about how people write books and how you keep stuff interesting for the reader. Instead, it was about how to document the API on a moving target and how the documenters want to document, but the Rails committers are making their lives difficult. Apparently, they used to value great documentation, but now they seem to value being able to make changes quickly, documentation be damned.

Compare this with a committee approach where a feature would have to be voted on and agreed to, which would eventually get documented, and possibly the documentation would also have to be approved. This would lead to better documentation, which would be at odds with developers trying to write new code.

I suspect that frameworks like Rails may need to really keep documentation in mind, to the extent that they may have to seek permission before making changes to the semantics, and it should make sense. This is always the dilemma between coders and documenters. Unless coders value documentation highly (and many don't), the documentation is always likely to suffer, especially because many coders don't want to be burdened by documenters.

And many of these documenters code. There are plenty of tech writers who don't seriously code, and then they try to document. That can be really tough. One thing you realize is that documenters code often as code is being updated. It's not as if they wait until the code is settled down, then document, because some things, like Rails, keep moving and moving, and if they waited, there would never be any documentation.

I had originally envisioned this to be a talk on how to write books for users, but it ended up being how difficult it is to write up-to-date and accurate documentation if the guys writing the code aren't a willing bunch.

I thought that was quite fascinating, if a little sad too.