Table or Booth

RailsConf 2008 Saturday Night Key Note: Kent Beck

I got lazy and didn't blog about DHH's key note last night.  So, before I get on with Kent's salient story-style wisdom, I'll quickly catch up with DHH's.

He suggests that developers have a lousy work/life balance and that more 'life' would be make us better programmers.  He's so into this that 37 Signals now only has 4 day work weeks.  Man, I like that.  Wouldn't it be cool if that would actually catch on.

He also love/hated the growing fame of Rails and noted that our Rails skills will be commoditized.  So, therefore, he urged us to continue to invest in one's self.  And, he urges, do it in ways that stretch us beyond our normal boundaries.  Take a business class.  Learn graphic design.  The four day work week allows 37 to better to this.

There you go.  Now, all about Kent Beck's keynote.

"Brittany Spears has musicianship.  Guaranteed, there are singers worse than her who never made it." --Kent Beck.  

Since I was typing about DHH to catch you all up and not paying attention to Kent's intro, I have no idea what the context of that quote was.  Somebody comment here to let me know.

Ideas with Impact.  That's the theme.  Perhaps Brittany's music had impact.

OK.  Listening now...

He's telling stories from the 60s and 70s.  He read the entire patterns book by Alexander standing up, in the book store (was a broke college student).  Alexander showed how design patterns and decisions should be user oriented.  

On developer testing, Kent states: "Testing's not the point.  It's about responsibility; developers taking responsibility for what they write".  Couldn't agree more.  I've seen over and over that agile dev's main win is encouraging accountability and a sense of personal responsibility for the code we write.

"Ideas with impact are the ones that seem ridiculous until you try them. ... When I wrote the test first and there was no class to support, I felt like I was cheating." *laughs*  He continued to write tests then code until he couldn't think of anymore tests that wouldn't work.  "That really transformed me."

JUnit was written, test first, using JUnit.  And, it didn't explode... which was a good thing because he wrote it while on a plane.  Then Fowler liked it.  Eclipse integrated it.  The rest is history.

He didn't go into the XP story very much.  Too bad, I would've liked to hear more.

About the technology adoption curve - ideas with impact follow it like anything.  If you want to continue to make impact, you have to think about how ideas get introduced to successively later adopters on the curve.  Patterns have lost steam as an idea.  The jury is still out on test-first.

Surprise, he's mentioning Zed Shaw's infamous rant, now... The point of any business memo is in the second to the last paragraph.  Zed's second to last paragraph, "Rails really needs to have a transparent services market".  He wonders why the uproar about the rant and seems to forgive Zed's rage; suggests that "Rails really needs to have a transparent services market" isn't such a bad idea.  I agree.  

Come back, Zed (and play nice).

Kent is amazed that Ruby programmers put their Ruby code in an IDE not written in Ruby.  Thinks that writing an IDE in the 'wrong' language would eventually rub off!  CodeGear was in the room.  Their Eclipse IDE is pretty slick - I bet they cringed a bit with that comment.  Well, Kent is Kent; he can say whatever he wants.

Kent's taking questions now...

How do you find success in mass marketing of ideas?  A: Start with what *you* do that works, then amplify it.

How has Agile watered down Extreme Programming and what can we do about it?  A: Accountability.  Thinks that most shops excuse business as usual with thin veneer of meaningless 'agile'.  He repeats accountability, transparency, responsibility.  "What would you do if it was YOUR money paying for what you do?  Wouldn't be thinking: 'documentation'".

Aside, now: Principal of Mutual Benefit.  Try to find a way for everyone to win in any pursued activity.

A good ending, I'd say.

Summary: Dialogue Concerning the Two Chief Modeling Systems

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Object-based data modeling starts with nouns (table names, class names), their sub-properties, and relationships with other nouns.  Behavior-based, asks first what the user's goal is, defines a set of verb-based expressions (methods), and is then followed by the supporting nouns and their relationships derived.  Both have advantages and disadvantages.

Object-based modeling can be brittle when new behaviors are needed.  Behavior-based modeling can lead to object/relational impedance mismatches that are hard to resolve.  

Conclusion

The right answer is... hold on... "think."  Huh??  In other words, there's no right answer.  I hate hearing that, even though I know it's true.  So, I pressed Jim later and got this much from him (paraphrased):

Behavior-based modeling is a good fit for application-level data modeling.  Behaviors and their supporting nouns tend to be consistent within an application, regardless of varying ways the data may be persisted.  For system or cross-application data modeling, a more abstract, noun-first (object-based) approach may be better.  This way, the data structure doesn't have to change from application to application.

Yellow Pages.com Rewrite

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

RailsConf 2008

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Resolving Files with TextMate, Subversion, and FileMerge

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

Ruby Arrays: select(), collect(), and map()

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Ruby Refactoring Pattern: "Forward with Default Params"

Introducing Ruby refactoring pattern called "Forward with Default Params."  This applies to any language that supports parameter defaulting, actually.  And, this pattern may already be documented somewhere for all I know - I haven't looked into it.  If someone can point this out, I'll be happy to defer all credit.  In the meantime...

Problem: You keep creating new methods, each calling the same helper or 'core' method (we'll call it 'method_a'), but with different params.  You can't change the required params of the core method because spagetti-legacy code relies on method_a, without params, such as with Rails controllers.  You should fix the spagetti code but time dictates otherwise.  However, you feel dirty violating DRY in your controller.  What to do?

The Rails Edge, 2006 - Day 1

In this post and the two that follow, I highlight interesting talks at The Rails Edge, 2006.  I do it for Google searching posterity and for my admittedly selfish desire to reinforce key concepts presented. 

Rails Load Path Resolution Tip

Nothing ground breaking in this post.  I write it only because the existing documentation for this behavior is weak or nonexistent. 

Have you ever seen the following message while testing your Rails app?

NameError: uninitialized constant ... blah, blah

Why Ruby?

Several people I know have asked me this recently.  Without just pointing straight to Bruce Tate, here's what I've come up with.

<short_answer>
* Ruby is an order of magnitude more powerful and less bloated than Java
* Ruby has Rails and an explosion of new libraries being built with or for Ruby
* Ruby will make you look good to your customers by developing more efficiently, making you more money
* Ruby is hot
</short_answer>