my not-so-barbaric yawlp

Oh why not, I’ll jump on the bandwagon as well.

[objo-laptop | ~ ] $ history 1000 | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
94 cd
70 svn
49 ll
40 clear
26 irb
24 rake
20 rm
15 ruby
14 cat
12 open
[objo-laptop | ~ ] $ 

I just got back from a whirl-wind tour of conference speaking. It was a real pleasure getting to speak at these events.

If you are considering your conference budget for next year or thinking about where to spend your money, look very hard at the regional events. Having attended and spoken at many of the major and regional events, I have to say the content at the regionals has been exponentially better. Pat Eyler and Mike Moore did an amazing job with Mount West Ruby Conf. Scotland on Rails was organized incredibly well, and had some of the best content I’ve seen in a long time. Alan Francis, Graeme Mathieson, Abdel Saleh and Paul Wilson pulled off their first conference in fine fashion. Between the location, the people, and the pub across the street, the tracks at this conference were a must see.

My slides for two of the three talks can be found here:

• Domain Specific Languages: Molding Ruby
• Be Careful Your Java Is Showing

If you want to see my talk from Mountain West Ruby Conf it was recorded by Confreaks. and posted here

I’ve decided I dislike using Twitter as a replacement for Chat. Chat’s TCP. I liked Twitter for being UDP. – James Duncan Davidson

I spend the majority of my day communicating with people. Whether it’s email, SMS, Twitter, face-to-face, IM, or telephone, I’m constantly communicating with people. I’ve made a career out of getting to know people. Very few of my jobs have ever been away from people (and let me tell you, I’ve had a lot of jobs in my life).

Living in Germany and having moved quite a bit, I began to rely on good ol’ pen-and-paper mail (snail mail) during my school years. When we moved overseas the military let us send mail for free within the military system. We would meet new friends on retreats, and events we attended and begin mailing back and forth. The big lesson I remember learning centered around the idea that what you write cannot be deleted. Say the things you want to say clearly and think about them first because they cannot be erased (and you didn’t want a bunch of scratch-out marks on your letter).

I was introduced to email very early. Thanks to attending a well-funded high school we were able to install a local network and give everyone in school an email address (just about the time the 486 came out … we were cutting edge at the time). Once I learned to type I learned another important lesson. The idea of ‘thinking before you send’ became more important. The better I became at typing, the closer an email was to a stream of consciousness. This got me into more than one argument.

I remember when I got my first job that was phone-based and thinking about how much the dynamics of my conversations had changed, because I now did not have body language and hand signals to rely on in order to help me communicate. I had to rely completely on my voice, playing with pitch, inflection and speed in order to help me make some of my points. Eventually I was able to master it, and excel at it, but not without hitting some rough spots along the way.

Now I have a hundred options in front of me when it comes to communicating. Recently things like twitter, SMS, email on my phone and IM have me thinking. There are so many new dynamics that have been introduced into conversations. So far I have more questions than answers, but in asking the questions at least you can begin working on them. Things like:

• How do you know when an SMS conversation is finished?
• When do you assume there is a technical problem and something wasn’t received
• When is each medium more appropriate than the other?
• What if a conversation was started in one medium, is it rude to switch to another?

Twitter has brought another level of questions to this as we begin to explore what “Duncan” above noted is essentially a UDP broadcast message.

• When is it appropriate to continue a thread that seems like it should be a conversation between a limited number of people.
• Is it rude to take it offline?
• Is it rude to announce something intended for a limited number of people if you know they are listening?

Just some of the many questions I’ve been thinking about lately in the question of communication, the medium, and the rules, idioms, and conventions used in them.

While I should be finishing up some of the dozen half-baked entries, I elected instead to just post my upcoming speaking schedule. I was putting this off in hopes that RailsConf would let me in, but it looks like this will be the first year for me to sit it out (unless of course they are still in fact deciding).

Emerging Technologies for the Enterprise March 26-27

I’ll be in Phillidelphia on March 26-27 giving my talk, “Be Careful Your Java is Showing” a walk through the idiomatic and architectural traps that developers fall into when they first approach Ruby and the Ruby on Rails framework.

Mountain West Ruby Conf March 28-29

I’m off from Philly straight to Salt Lake City for Mountain West Ruby Conf. I’m very excited about this one. The local ruby conferences always have a ton of energy. With friends like Mike and Pat running the show, you know it’s going to be fun.

I’m giving my “Domain Specific Languages: Molding Ruby” talk. This is one of the two talks I’m the most passionate about and should be a a lot of fun. This is also the talk I was supposed to give in Ann Arbor last night, but I had to cancel on account of snow.

Scotland on Rails April 4-5

In April I’ll be traveling to the land where they make scotch. Oh man is this going to be fun. While I’m there, I think I’m supposed to give a talk or something :-)

Seriously, this is going to be another fun one. Jim and I are working on something lively for that conferences that should be a lot of fun. I can’t wait.

erubycon August

Yes, we will be putting on erubycon again. We will be giving the conference to show ruby’s readiness for the enterprise. Look for another announcement within the next couple weeks.

I’ll add more talks as they come up. God knows I’ve papered enough places with proposals.

I was able to attend RubyConf and truely enjoyed it. One of the best moments was a discussion that took place during Stuart Halloway’s Refactorum discussion. On the screen he displayed a piece of Rake that he wanted to refactor. With the blessing of Jim, who was sitting in the front row, Stu began the journey. He then showed the unit test that he used to test the private method he wanted to refactor. Unfortunately this is where the discussion got carried. I’ve seen posts by both Jay Fields and Jason Rudolph that talk about the how in testing private methods, and a lot of discussion around the blogsphere about how wrong this is.

Whether you agree with testing private methods or not, people are missing the subtlety of what Stu really did. Taken out of context I feel that the real message was missed.

Tightening the Feedback Loop

The first thing he did was identify a piece of code he wanted to refactor. The piece he found happend to be a private method. This method was fully tested (100% coverage), but it was tested through it’s public interface. If something in the private method was changed, it would have been picked up, but the unit tests were testing a level higher than the method that was being refactored. What Stu did (before performing any of the refactoring) was to tighten the feedback loop. He gave himself a safety net that was closer to the problem being tackled instead of relying on the one that was there. That way, if he broke something in the method he was refactoring, he would know right away instead of identifiying what was broken through a side effect.

Are Integration Tests Enough?

I also saw a suprising post from a highly regarded individual who said they don’t really unit test much. They rely on the integration and functional level tests to make sure that things are working. Yes this made the hair on the back of my neck standup. It goes against everything I believe in as a religious TDD’er. But after thinking it over for some time I realized that it’s all about the feedback level you are comfortable with. If something breaks I want to know about it at the most granular level possible. If you choose to only create functional level tests, and you are using a tool to check your covereage levels (such as rcov) you are still building that safety net, just further away from the actual code.

I know here at EdgeCase we rely on extremely tight feedback loops. We typically deliver projects in terms of weeks, not months, we work in weekly iterations and we test at the most granular of levels. We still rely on integration testing to ensure things work together, but when it comes to the code, the closer to the source, the better.

A key ingredient in the success of EdgeCase is collaboration. We decided early on that the most effective way to develop with each other was by pair-programming. It has been fantastic.

An irritation I had before founding EdgeCase was that more companies did not try and work hard enough to figure out how to overcome the barriers of having people offsite. With the plethora of technology available, I was convinced that we could be a very effective organization without either requiring our developers to commute using a 747, or to pass up on great team members just because they didn’t live in Columbus.

The first real test came when we hired Jim Weirich. Jim lives in Cincinnati, two hours south. We had already become accustomed to working with each other in a 100% pairing environment. We made it clear that we had no intention of making him drive up to Columbus every day, nor did we expect him to move. We also had no intention of leaving him alone in his basement and throw work his way. So we decided to figure out exactly how we were going to pair with him in Cincinnati.

Our requirements were pretty straight forward. We needed:

• ability for us to work with multiple files (When in Rails, you are never in a file for very long, especially when bouncing back and forth between tests and regular files)
• a way to communicate effectively
• little or no perceived latency

Secret Sauce

After a lot of trail and error (mainly researched by Jim and Chad) here is what we came up with:

• ssh to a server that both parties can access
• screen so that both parties can share a session
• Emacs (or any headless editor that does not require a GUI environment)
• Video Skype

ssh and screen

ssh and screen allowed us to create an environment that uses up very little bandwidth. This was awesome for two reasons. One, there is very little latency (especially if you ssh in with the -C option). Two, it gives us extra bandwidth for skype.

If you have not tried it yet, you really should check out screen. It’s a really cool command line tool that most *nix environments come with now days. It allows us to look at the same shell session. So we both ssh into the box, and then join the screen session (in our case one called pairing). Then we can see what the other person is looking at. When the cursor moves, we both see it.

Some of the gotcha’s that we have encountered:

• Try and ssh in as the same person. This will keep down the amount of headaches you encounter with file permissions, etc…
• create a separate subversion user for the ‘pairing’ server (again, it helps with file permissions)
• Tweak your timeout settings. There will be lots of times where you are watching your pair type, and not actually interacting with the keyboard. ssh likes to think that you have timed out and kick you out. This is something that can be configured (I believe in /etc/sshd_config)

Video Skype

While this sounds like a luxury, it’s actually become a fantastic tool for pairing. Nothing beats seeing the facial expressions of your pair. You can pick up some great cues and it feels as if he/she is sitting right next to you. We both are using macs and have a two monitor system. Inevitably you will find yourself looking at the video image of your pair. Therefore we have elected to drag the skype window right below our camera on our laptop lids. This way, when you look at the picture, you are in essence looking into the camera, further helping the feeling of ‘being there’.

Emacs

Unfortunately some people in the company are not advanced enough to use use Emacs, and have chosen to use a remedial editor. Either way, spending time learning one of the main editors is not wasted effort. While it seems like at first you are trying to run through mud, you will be amazed at how, after a month or two, you are working faster than you ever thought possible. Years of effort have been poured into tweaking these editors and making them unbelievably extensible.

All in all, the important thing is that we do not have to launch an entire X instance simply to run our editor. TextMate is a good editor, but it’s not worth moving to something like VNC simply so we can use it (although, a subject for another post, we have actually found that TextMate is fun, and shiny, but just does not give us the support we need anyway).

Another benefit to using one of these editors is the excellent buffer support. Being able to seamlessly move from one buffer to the next, moving text around, and executing files leads to some excellent increases in productivity.

Extra Communication

Not being there does have other challenges. When you are pairing together in person, who gets the keyboard is usually pretty easy to figure out. When you are remote, you simply need to ensure you communicate more. We use phrases like tag when we are about to take over the keyboard, or yield to say you giving control to the other person.

We also do not have the luxury of a white board. So communicating ideas is a bit more difficult. This is the only place where I would say “I wish we were in person.” During our time pairing, we have become better at communicating our ideas. More times than not, we end up thinking in code. Again, it’s not great, but it does help.

Is This For Me?

This is by no means our way of saying, this is the only thing that works. What I am tyring to do is give you some more insight into how we operate, and what things we have found to be successful. While we are encouraged by tools such as Coda and SubEthaEdit they are still a little ways off. Stay tuned, as we continue to bring on more talented developers and put our recipe through it’s paces.

What has worked for you?

One of the great things about starting a company is the ability to team up with some of the best talent you can find. It’s a nice feeling to be extremely excited when you hire someone. Every time we have brought someone on, I’ve wanted to tell the world. It’s a fantastic feeling.

We are extremely excited to welcome Scott Barron to EdgeCase.

Scott is a member of the Ruby on Rails Core Team, avid twitter monkey (although we will have to work on his nic), and incredible developer. We are looking forward to not only working with him, but helping him with his incredible contributions to the open source community.

Scott lives (and will remain) in Cincinnati. We have worked hard on creating an environment that allows us to pair-program even if the person is remote. It works really well for Jim and I. With video skype, we are able to feel as if the person is right there, combine it with ssh + screen + emacs and it’s no different than sitting in the same room.

Welcome Scott!

I realized that I completely forgot to post this up to my blog.

Jim Weirich and I will be teaching a Pragmatic Studio on Testing Rails in Columbus Ohio, October 17-19.

We are preparing some fantastic content to help show attendees what TDD is all about, as well as how to get the most out of your testing. This is as much how to test correctly as it is about how to test Rails specifically. We are taking our years of testing experience in and out of Ruby and showing you how we apply it to Ruby and Rails. We will show you how to test as individuals and in your teams.

We have learned a lot at EdgeCase over the past year about specifics of testing Rails applications, and especially about the fantastic RSpec framework. You get the benefit of having all of the things we have learned the hard way wrapped up in a nice, neat package.

Nicole and Mike have put together a fantastic program with the “Pragmatic Studio” brand and we are honored to be a part of it.

What are you waiting for, register now!

I delivered an application today. I was very proud of this app. It took a bit longer than I wanted to deploy, but that had more to do with an unexpected server and me forgetting RHEL. What struck me though was how confident I was in it.

We have delivered a bunch of applications at EdgeCase, but this was the first one where I was back in a cubicle navigating the enterprise hallways and firewalls. Back in the land of overhearing conversations on what people are doing for lunch, and how early they hope to leave on Friday (although in all fairness, it’s the only IT organization in a 100M company I’ve seen who really ‘get it’ – more on that later).

Anyway, so it got me thinking about all the other deployments I’ve done before in large IT enterprises. I’ve never been more confident in an application. Once deployed, I had a plethora of tests that hit the application from every different angle possible. Unit spec suite, integration spec suite, and an entire harness to beat on the app from a performance standpoint. This was a fixed priced gig. Most of the things in here were not required ‘by contract’. They were done because the developers care about their craft.

I also knew that the code I was turning over was top notch. Understanding it’s the first Rails application for this company, it was nice that this is going to be a reference application for future Rails projects. The guys at EdgeCase turn over code that’s the best they can do. Not so in the IT departments of most companies.

On my way home I was catching up on some podcasts and the idea of caring for your craft struck me again. Take Geoffrey Grosenbach and the Ruby on Rails podcasts. Most of us in the Rails community take for granted the time and effort he puts into making sure the sound on them is nearly perfect. He spends countless hours and lots of money making sure our listening experience is the best it can be. And he is ONE person.

I then flip over to a podcast I was trying out from Business Week on selling – something I spend way more time doing than I care to admit. Here is a large company (I have not idea what the circulation is, but I know it’s huge). It sounded like it was recorded in a train station on a cell phone. WTF?

Big media keeps complaining about all the blogs, podcasts, and vlogs saying that there is no quality filter. When I see things like that from big media, and then listen to the Geoffrey I can’t help but think, that I hope by lowering the financial barrier of entry into media delivery, we end up with more craftsmen and less mediocrity.

Cheers Geoff, and thank you for caring.

One of the two books I’ve ordered this year that I really just could not wait to get O’Reilly’s Beautiful Code. It’s just as good as I thought it would be. Very interesting article on Subversion’s delta editor, Tim Bray has a great look at search and a very pragmatic approach (as well as a realistic discussion on using Ruby).

But of course, the part I loved the most, Matz’s look at how code should be written.

Humans are more valuable than any tools or languages. Computers should serve programmers to maximize their productivity and happiness, but in reality, they often increase the burden instead of lightening it.

I’m lucky enough to be pairing with Jim Weirich and I’m learning a ton. Of course I’m learning things like how to get the most out of the one true editor and the really hard to understand ins and outs of Ruby.

What I’m enjoying the most is the different perspective on developing in Ruby. We’ve had quite a few discussions about style. The most recent I thought I would put up here.

One or more lines

When you come to Ruby people inevitably ask the question of when to use do … end and when to use the {} syntax for blocks. The normal answer, and the one I’ve subscribed to, is that you use {} if you are on one line, and do … end if you span more than one line.

  Items.find(:all).each { |item| puts item.description }

  Items.find(:all).each do |item|
    # do something
    # do something else
    item.save
  end

Problems with this approach

First, when you decide to add more functionality into your block, you have to change the surrounding syntax. If you are following Red, Green Refactor, this could happen quite frequently.

The most interesting issue we discussed was that this style tells you nothing of value when you are reading the code. We can tell visually that it’s one or two lines.

Use {} when returning a value, do … end when performing actions

The alternative is to use these two syntaxes to communicate what you are doing. Jim’s style of development, which I’m quickly growing more fond of, is to use {} when you are returning a value from a block.

  [1,3,4,5,6].find { |i| i == 4 }

  [1,3,4,5,6].collect { |i| i.to_s }

On the flip side use the do … end syntax when performing actions, but not returning any values.

  %w{ one two three four five }.each do |i| i.capitalize! end

  %w{ one two three four five }.each do |i| 
    i.capitalize!
    i.reverse!
  end

So now when you are glancing through some code and you see a block that looks like this:

  array.method_accepting_block { |item| 
    some_action
    more_actions
  }

you will know that they are returning a value at a glance.

Interesting idea. Thoughts?

Dave Thomas put out the challenge and we responded.

Last year Dave and Mike in conjunction with the Pragmatic Studios came up with a stellar idea, hold a one day guide book training session. The only caveat was that in order to attend you had to donate money to a charity. They raise over $12,000. This year, they did the same thing. When they combined it with the conference at large, they were able to bring the total up to $33,000.

The beauty of this idea was two fold. First, was the obvious idea of raising money for a good cause. In our case, we are supporting an individual charity that is responsible for helping fight hunger in children. Each $50 donation supplies enough to feed on child for a month in one of their theraputic food centers.

The other reason I love this idea is because it has identified a need that every conference has, to get people on the same level. Especially with new technologies, we have a problem of brining on new developers. The ‘guide book’ name was coined by Dave and Mike to represent a day of training that acted as a travel guide. When you visit Moscow, you take a guide book, not to give you the entire history of Moscow, but one that will give you enough to make your trip more enjoyable.

We have followed suit. We have added another ticket to erubycon called charity training. This gives you full access to the conference, in addition to a one day training course offered the day before the conference begins. erubycon will donate $50 from your ticket to the Action Against Hunger. We have are running a charity drive through ChangingThePresent.org

So take the opportunity to help us raise money, and make sure you get the most out of erubycon. Register today, seating is limited to the first 50 people.

The training session is an introduction to Ruby and Rails. It will give you enough of a background to allow you to get the most out of the conference and see for yourself what all the fuss is about. After the training, you can join us for three days of packed content showing you what you can do tomorrow to have an impact in your organization.

If you cannot make the dates, please consider donating to the cause anyway. RailsConf raised over $33,000, let’s see how close we can come.

We have finally posted the session list for erubycon.

We will be having two tracks and have some incredible talks to choose from. Stay tuned for the exact schedule. Some of the topics we are covering:

• Data Warehousing
• Large Teams and Rails
• JRuby, the DLR and other alternative platforms
• Security
• Domain Specific Languages

What are you waiting for? Register soon while we still have space.

Come be a part of the first Enterprise Ruby Conference. It’s being held n Columbus Ohio July 16, 17 & 18. Come get all the ammunition you need to convince your boss to take a good, hard look at Ruby. Maybe you too could be coding in Ruby this year!

As you know we have a contest going on to win free admission to erubycon. All you need to do is tell us some really cool thing you are doing with Ruby.

The latest post is from Josh Schairbaum, a leader in in the community who is working hard to get organizations to take notice. He writes about his experience getting Ruby adopted inside some major corporations. First JPMorgan Chase and now CardinalHealth, number 11 and 19 on the Fortune 500 list respectively.

From his post:

So, what am I doing? In short, I’m helping technology leaderships make the best investment decisions, while becoming an industry leader, not an industry follower. I’m proving to them that you don’t needs teams of consultants or a pricey support contract to business value out of the data that your organization holds. I’m proving that Ruby belongs.

His work at JPMC has grown quite well:

At JPMC, I led the team that created the 1st fully-supported and fully-funded Rails application inside the bank. ... The part that I’m most proud of is that 1 year ago, there were no full-time Ruby/Rails jobs at JPMC, today there are 3, and that’s a great thing for the community.

He’s now moved on to CardialHealth, but has not left his innovative ideas behind:

I’m doing something that I think is even more edge-leading and innovative. I’m in the process of deploying several small Camping apps, which work together to create a dashboard of information for IT leadership to make investment decisions

Read the full text here. You can also listen to the Ruby on Rails podcast with Josh and Dan Manges about their work at JPMC.

It’s exciting to see some of the inroads that Ruby is making, and the developers that are happier because of it.

So I thought it a bit odd to run into Roy, the founder of ThoughtWorks, upon my arrival to RailsConf today. I then get to the speakers lounge, register and find a two page spread announcing not only mingle but also the most interesting announcement of all:

Today ThoughtWorks Studios introduces the convenience, power and flexibility of Ruby / Ruby on Rails to Fortune 1000 companies.

RubyWorks is, what appears to be, ThoughtWorks supporting Ruby for the Enterprise. To say this is huge would be a drastic understatement. ThoughtWorks is releasing a production LAMP stack for Ruby on Rails that’s designed for both Red Hat Enterprise and CentOS (think free version of RedHat). According to their website, beginning in July they will begin offering 24×7 paid support. This is putting your money where your mouth is.

RubyWorks – a new products and support service for Ruby. Designed to help enterprises implement and use Ruby more effectively …

EdgeCase is pushing the meme of Enterprise Ruby with erubycon, and now ThoughtWorks is getting behind it with full support.

This is going to be a stellar year.

update: Edited to fix stupid grammar mistakes. Will stop blogging when jet-lagged.