If you are speaking at RubyConf this year, we have a special opportunity for you.

Are You Speaking at RubyConf 2008?

If so, congratuations! And have we got a deal for you …

Wednesday evening, Nov 5, at 6:00 pm, (that’s the night before the conference) we are inviting all speakers to a special training session. I’m going to be sharing some ideas for putting together and delivering a good presentation.

After my talk, Patrick Ewing and Adam Keys are geared up to do some Powerpoint Karaoke with everyone there. I’m not even sure what Powerpoint Karaoke is, but it sounds like fun.

I hope to see everyone there.

Update (4/Nov/08)

I’ve talked to Adam today. He says that Patrick isn’t going to able to make RubyConf this year, but we will be ready to roll with Powerpoint Karaoke anyways.

Update (5/Nov/08)

It looks like the speakers training will be in the Olympic Room tonight. The Olympic Room is on the same floor as the registration desk. Go to the left past the elevators and turn right down that hall (or ask someone who looks like they know what they are doing).

Conference Summary Video

Wow, what a great conference! There was a lot of energy flowing at RailsConf this year. Overall I’d rate this year as head and shoulders above last year. I’m not going cover much here, but will direct you attention to a Rails Envy VideoCase that Greg Pollack put together. The video is a series of very short interviews with a number of presenters giving summaries of their own talks. The only downside with the video is that I wish it was available before the conference. I see there were a number of interesting talks that I missed.

Followup on the “Modelling Dialogue”

Joe O’Brien, Chris Nelson and myself did a dialogue style presentation on the difference between object modelling and data modelling. The most common question I got after the talk was requests for book titles to learn more about object oriented modelling. Here are the books that Joe, Chris and I have recommended:

• Domain Driven Design—Eric Evans
• AgileSoftware Development, Principles, Patterns, and Practices—Bob Martin
• Refactoring: Improving the Design of Existing Code—Martin Fowler

The Musician’s Birds of a Feather gathering at RailsConf was great. We had a room full people, two guitars, a ukulele, a flute, several harmonicas and an improvised drum set. Unfortunately, one of the guitars was an electric travel guitar which had a dead battery, therefore no way to really hear it.

However, the other guitar was a nice Epiphone accoustic which was passed from player to player. It became the quickly became the basis for most of the music performed that night.

I want to thank Artichoke Community Music for supplying the guitar. Travelling with a guitar by plane is a big pain, so I arrived with nothing to bring to the music BOF. I called several local music stores looking for a guitar that I could rent for an evening. Artichoke music said they had a “not-for-profit” guitar that they would let me borrow for a day. Not many stores would do that for an out-of-town stranger.

So, if you’re in Portland looking for a good guitar store, check out the great people at Artichoke Community Music.

Joe O’Brien and I will be leading another Test Driven Studio in Denver, June 9-11.

Testing, Colorado, June … What’s not to like?

About 8 years ago I come upon a technique that radically changed the way I developed code. I was reading Martin Fowler’s “Refactoring” book and came across this paragraph:

“Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The test are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I’m still human and still make mistakes. Thus I need solid tests.” —Martin Fowler

Chapter 4 of “Refactoring” was my first introduction to JUnit and got me interested in “Test First Design” (what we now tend to call “Test Driven Development”). Although I wrote good code before, the confidence I had in my code took a dramatic leap forward after I started adopting TDD practices.

On June 9 through 11, Joe O’Brien and I will have the pleasure of leading the next Pragmatic Programmer’s Test-Driven Development with Rails Studio. in Denver. We will have an opportunity to share with you some of our experiences in using TDD with Ruby and Rails.

There are still seats available, so its not too late to sign up. More information is available here.

Time is running out. Get your talk proposals in.

RubyConf Talk Proposal: Submitted!

I just sent in my RubyConf talk proposal.

Better Hurry!

If you’ve got a good idea for a proposal, you can submit it at http://proposals.rubycentral.org/.

The deadline for the proposals is August 20. However, I have it on good authority that the deadline will be extended to Aug 23, 5:00 pm EST. (Ahh … I see the announcement made it to Ruby-Talk) So you still have some time.

Some Hints

RubyCentral has been having some problems with getting their registration responses delivered (I found my registration confirmation in GMail’s spam box). I would recommend that you go ahead and register a proposal now, even if you don’t have all the details ready. By the time you are ready to submit the final version, you won’t have to worry about any last minite registration hassles.

Good luck with your proposals. I hope to see you at RubyConf!

Joe O’Brien and I will be hosting the Test-Driven Developement in Rails Pragmatic Studio in Columbus.

Test Driven Developement in Rails

Mark your calendars. It is official! Joe O’Brien and I will be teaching a new Pragmatic Studio: Test Driven Development in Rails. The first offering of this studio will be in Columbus on October 17th through the 19th.

To quote from the web site:

In this Studio, you’ll learn how to do test-driven development by actually doing it. We’ll teach you how to get started with a solid foundation of testing practices, and then quickly build on those with advanced techniques and tools. You’ll experience a powerful synergy between testing and design that helps you write better software, faster!

If you ever wanted to improve your testing skills in Ruby and Rails, then this wil be the place for you. I’m really excited about this opportunity. I hope to see a lot of you there.

Better late than never, here are some thoughts from the erubycon conference in Columbus Ohio.

erubycon Themes

First of all, what a great conference. The talks were great and the hallway interactions were excellent. Glenn Vanderburg’s talk on “Enterprise, Schmenterprise” hit the nail on the head. (paraphrased soundbite: “The Enterprise it not ready for Ruby, it is desperate for it).

Testing, Testing, Testing

But the theme that kept coming back to me over and over again from the conference was testing: unit testing, integration testing, UI testing, all of them. Stu Halloway’s talk on the “Refactoring of the Week” emphasized the importance of tests to enable refactoring. In addition, Stu made a strong pitch for getting 100% code coverage in the projects you are working on. In selecting code to be refactored for his talks, he would just zero in on any code reported not covered by RCov and start looking there for fruitful refactoring possibilities.

So, the moral of the story is that if you have 100% code coverage, then Stu has to work a bit harder to find examples for his refacting talks.

I was inspired by Stu’s talk so I went back and checked all my open source projects to see how well they were covered by tests. I’m happy to say that both flexmock and builder are now at 100% and only needed a little tweeking to get that last percent or two. (Except for the CSS builder … we really need to finish that class or dump it).

The main library file of Rake is now at 100%. It was in the mid 90s when I check and needed some attention to get it the rest of the way. So that is good.

The unfortunate part is that there are some pieces of Rake that are not well covered. First there are a number of deprecated libraries that aren’t at 100%, and since people shouldn’t be using them, I’m more likely to remove them entirely than to write tests for them.

Second, the are some Rakefile tasks that are not adequately covered. I’m not sure how to address this for Rake tasks tend to be very involved in the environment you are working in, making it tedious to mock. I’d love to make the testing of Rake tasks easier, so fee free to make suggestions.

As for RubyGems … I’d rather not talk about the code coverage stats on that one.

So, I’m making RCov a part of my standard Rakefile setup and will start running it more religiously to keep those code coverage numbers up.

Emacs … We’re not dead yet!

I can’t really call it a “theme” of the conference, more like a strong undercurrent. There was certainly a number of programmers attending who use Emacs for their day to day editting, even when programs like TextMate are available. While emacs is a strong editor for a wide number of programming languages, its support for Ruby and Rails is lagging behind some of the more recent editors that are targetting Ruby specifically (e.g. the aforementioned TextMate). A group of us holdouts got together and shared some tips and tricks on bringing Emacs closer to the state of the art in Ruby support. I’ll share some of those tips here in the near future.

Next Time

Going into this conference, I heard the organizers swear they were never doing this again, but the the end everyone was enthusiastic about next year. So, who knows, if you’ve missed this year’s erubycon, you might get a chance to join us next year.

Continuing with the erubycon speaker interviews, next we have Muness Alrubaie.

Muness Alrubaie Answers

Muness has over 10 years of experience in software development and teaching computer science. His development background has included working with various languages including Java, C#, Python, VB.Net, Perl and Javascript. Now, he is thrilled to be coding in Ruby. Muness is currently a software developer at ThoughtWorks.

Here are Muness’s answers:

Q: Tell me a little about your background, where you are working and how did you come to start using Ruby?

I’ve been doing software development since ‘97. I am currently an architect with ThoughtWorks. I first came across Ruby three years ago thanks to all the Rails hype.

Q: What unique opportunities do you see for Ruby in the enterprise?

I love Ruby for system with fast changing requirements. Its succinctness and readability make it especially attractive, for those properties make programs written in Ruby easier to write, maintain, and most importantly for me, evolve.

Q: What obstacles do you see to getting Ruby used more in enterprise software?

Half hearted attempts at Ruby. Let me explain: whenever a company tries something new and it fails, they blame the technology. This is a problem all new tools/languages face, but I think it’s especially relevant for Ruby.

To be harnessed properly, one has to approach Ruby with respect. In my opinion, using Ruby for large systems without the feedback supplied by an agile process, for example, is a recipe for disaster. Another example of the respect due Ruby is that it is drastically different than Java or C#. Writing Ruby without TDD or taking advantage of its features (dynamic typing and extensive metaprogramming support stand out) will ultimately disapoint both managers and developers.

Q: Play oracle for a moment and tell me what you see as the next “Big Thing” in software development.

Language oriented programming, aka, making better use of DSLs.

Q: What erubycon talk are you most interested in hearing?

I am looking forward to all the talks, and especially to Keeping Tests Dry and The Beauty of Ruby.

Thank You

Thanks Muness.

For more information on the conference, see erubycon.com.

Glenn Vanderburg is featured in today’s erubycon interview.

Glenn Vanderburg Answers

Glenn Vanderburg has over 20 years of experience as a software developer, working in diverse environments using a wide variety of languages and tools, including Java, C and C++, Perl, Tcl, and more. His career spans large enterprises, universities, and startups. He caught the Ruby bug in 2000, and has never enjoyed programming so much.

Here are Glenn’s answers:

Q: Tell me a little about your background, where you are working and how did you come to start using Ruby?

I’ve been a programmer for 20 years now, and I’ve worked in a wide variety of enterprises, with many different technologies. I’ve just hung up my independent consultant hat to join Relevance, LLC (where I’m be a semi-independent consultant).

In late 2000 I was a regular at a Dallas-area lunch discussion group focused on “Extreme Programming and related topics” (i.e., what we would now call agile software development). Dave Thomas was also a regular there, and he mentioned to us that he and Andy were working on a book about Ruby. I was able to go to the OOPSLA conference that year, where the first edition of the PickAxe was released, and bought a copy on release day. I was hooked immediately.

Q: What unique opportunities do you see for Ruby in the enterprise?

I blogged recently that I think Ruby and Rails help good programmers to become better—partly through just being well-designed and powerful, partly through providing good examples and assistance in doing the right thing, and partly through having a community and culture that values good design and clean, expressive code. I think good, solid design and code are crucial for enterprise software. Enterprises, however, have historically undervalued those things, largely because it’s been so tempting to believe that tools and technologies will solve all the problems. I think we in the Ruby community have a chance to bring much-needed simplicity back to enterprise systems, and remind enterprises that there’s no substitute for skilled people with good tools.

Q: What obstacles do you see to getting Ruby used more in enterprise software?

Large enterprises have a pretty solid division of labor between those whose job it is to get work done and those who are supposed to prevent mistakes. Those in the first group will be drawn to Ruby as a powerful tool that helps them work faster, but those in the second group always try to resist change. And to some degree they’re right to resist. But because they aren’t accountable for the work getting done, they might hold out much longer than they should, hurting the organization in the process. The best strategy against such resistance is for all of us to go public with our Ruby success stories (and there are a lot of them already).

Q: Play oracle for a moment and tell me what you see as the next “Big Thing” in software development.

There are a lot of people these days wondering whether Apollo or Silverlight will mean the end of web applications, but I don’t think that will happen. My prediction is that new kinds of devices (including smartphones, pads, multitouch screens, and even large- scale displays) will require revising our assumptions about user interfaces, and that will require developers (yes, even enterprise developers) to learn some new techniques. Two-handed input, pervasive animation, and other innovations will cause a lot of upheaval among application developers.

Q: What erubycon talk are you most interested in hearing?

I can’t wait to hear Neal Ford discuss Mingle.

Thank You

Thanks Glenn.

For more information on the conference, see erubycon.com.

Today we are publishing Stuart Halloway’s answers to our erubycon interview questions.

Stuart Halloway Answers

Stuart Dabbs Halloway is a co-founder of Relevance, LLC. Stuart is the author of Component Development for the Java Platform. He regularly speaks at industry events including the No Fluff, Just Stuff Java Symposiums and the Pragmatic Studio.

Here are Stuart’s answers:

Q: Tell me a little about your background, where you are working and how did you come to start using Ruby?

I have been doing enterprise software development since 1989. Four years ago Justin and I founded Relevance with a goal of raising the bar for how software is written. Ruby has been a great tool. In March 2005, we ported a project to Ruby and haven’t looked back.

Q: What unique opportunities do you see for Ruby in the enterprise?

Ruby is compelling for enterprises that embrace agility. Agile teams don’t aim to limit failure, they aim to enable success. Thus, they are willing to embrace open languages that give developers maximum power to get things done.

Q: What obstacles do you see to getting Ruby used more in enterprise software?

We need more knowledge transfer. Ruby embodies a ton of good ideas, and it will take people (and organizations) a while to explore them all.

Q: Play oracle for a moment and tell me what you see as the next “Big Thing” in software development.

We’re already there: Agile development methods and open languages.

Q: What erubycon talk are you most interested in hearing?

I’m looking forward to Muness’s report from the field on large Ruby projects.

Thank You

Thanks Stu.

For more information on the conference, see erubycon.com.