However, many of the most active developers behind the Ruby 2.0 release are Japanese, largely unknown to the Ruby world outside of Japan because of the language barrier. Recently I asked the Ruby 2.0 release manager, Yusuke Endoh, to send a few questions to the Ruby 2.0 committers located in Japan. I was curious who they were, what each of them worked on and what they’re like as people. Fourteen other developers replied to his survey; read on to take a look behind the language barrier and meet some of the people in Japan behind this year’s Ruby 2.0 release.

Update: We just received answers from one more Ruby committer. Now there are sixteen of them :)

Yusuke Endoh

Nobuyoshi Nakada

Akira Tanaka

Yui Naruse

Usaku Nakamura

Hirofumi Watanabe

Koichi Sasada

Akinori Musha

Motohiro Kosaki

Shugo Maeda

Kazuhiro Nishiyama

Kouhei Sutou

Tomoyuki Chikanaga

Photo taken by Kakutani-san

Kenta Murata

Masaya Tarui

Hiroshi Shibata

Every week a group of Ruby Enthusiasts get together in a Virtual Roundtable and explore/discuss/argue some aspect of the Ruby language or the Ruby community. They allow the rest of us to listen in on their discussion by way of The Ruby Rogues podcast. The podcast can be accessed on iTunes or on the website and offers a ‘fly on the wall’ view of a great bunch of technology savvy people sharing their ideas and opinions.

In this series of articles I will share the results of my interviews with each member of this special group.

Thom: The first thing I’d like to ask, James, is tell us a little bit about yourself.

James: I’m a programmer. That is my day job. I use primarily Rails to build web applications. I’ve been in the community a long time now. I came in kind of at the end of the first era of Ruby, you might say. The first era where we had a handful of people just playing with the language before Rails even landed. Suddenly Rails got popular and one of my hobby skills turned out to be valuable.

Thom: About how long ago was that?

James: Ruby, actually as a language, has been around since 1995. But there weren’t a lot of people playing with it outside of Japan back then. Dave Thomas found it. I can’t remember when the original Pickaxe Book was published, but I would suspect it’s in the early 2000s. I came into the community, I think, in the summer of 2004.

Thom: Unlike many of us who discovered Ruby through Rails, you actually came the other way around. You discovered Ruby first before Rails existed, is that correct?

James: Yes. I was playing with Ruby back when Rails was under development.

Thom: So what kind of things did you do with Ruby? Desktop development and scripting?

James: I used it largely as a scripting environment. At a big job I worked back then, we used Perl everywhere to do a bunch of data manipulation. It was for a company that had a very large product-base. They would transform the products into reports, static websites, and such. We just used Perl for all of that. Then I got into using Ruby in those similar applications. Eventually, after Rails became popular, I began playing with that and figuring it out. I moved up the ladder that way. So you’re right, I came the other way.

Thom: That’s very interesting and I think that’s probably (as I said) not the norm. Many of us discovered Rails which brought us to Ruby.

The other question that I’ve asked Charles Max Wood, and even though I’ve gotten the story from him, I’d like to get your perspective on it; how did the Ruby Rogues begin?

James: It’s an interesting story. I listened to another podcast that is a panel discussion on a totally unrelated topic. I just always liked that format, where there are several people talking to each other and hashing out ideas instead of just individual interviews. I can’t remember if it was me or Chuck that originally tweeted, “I’d like to see a panel discussion of Ruby.” But both he and I had been thinking basically the same thing at the same time. So one of us tweeted it and then the other one was like, “I’ve been thinking about that, too.”

That was what put Chuck and me in touch. We became the first two. We started fleshing it out and then the original members of the podcast were all friends of ours; Aaron Patterson, Peter Cooper, and David Brady were just people we knew and we asked if they would do it. They did and that was how we originally put it together.

Then, over time, people came and went and we settled on the group that we currently have today.

Thom: So you and Chuck were following each other on Twitter, had you met maybe at a conference or something or how did that happen?

James: Yes, I believe we had met at that time. I think we did meet at a conference. I had gone down to a MountainWest Ruby Conference, the one in Salt Lake City, Utah. I went there maybe in 2009. I spoke there. I think my wife also gave a small presentation.

Thom: Is your wife a techie? Is she a programmer also?

James: Yeah, she worked for me for a couple of years doing Rails development, but now we have a small baby and she spends more time chasing her around.

Thom: I understand that. But I am envious!

James: She still helps with the non-coding side of the business, but the coding side is a bit much with a young one.

As I said, I think I met Chuck when I was at the MountainWest Ruby Conference. I had met all of the original Rogues by that time, with the exception of Peter. Then Josh and Avdi came on and I had not met either of them.

Thom: You mentioned some names that are now, I want to say ‘household names’ within the Ruby on Rails community, but I’m guessing at that time maybe they were not. They were just the guys that came to a few conferences and were giving talks?

James: It’s a good question. I’m not sure how much Aaron Patterson was doing with Rails at that time, probably some. But he was already known for things like Nokogiri. He had built many tools before that time. People knew him that way. Peter Cooper had his Ruby Weekly mailing list by then, but not the massive empire that he has today.

Thom: Yeah, you can kind of claim, “I knew him when…”

James: Right. That’s what I think led both of them actually to eventually move on as their time commitments are much, much bigger now.

I think it was Aaron, when he was off one week, who said, “Hey, we ought to have Josh on the show,” and we tried him. Somebody else mentioned Avdi or I knew of Avdi and we had them on a couple of times. It was a great fit and we all loved that. So, as the others moved on, we brought them on full-time and it’s just been a great group ever since.

Thom: I think Chuck put it well when he told the story about Katrina, that her guest appearance had been so well received and you guys got along so well with her, that it got to the point in the discussion that there simply was not enough room for another person, everybody raised their hand and said, “Well, I’ll give up my spot!”

James: Yes, that’s pretty much how it happened.

Katrina is very modest, I’ve actually read your interview of her where she calls herself a beginner and stuff like that. If you believe that, you’re not a regular listener of the show.

She has those rare qualities of being good with code—able to think about code and stuff—and then also being able to explain code. That is one of my favorite things about her. That she can take something and she just describes it in a way that’s very simple. I think that’s really unusual to have in programmers. I think we’re notoriously not great at communicating our ideas.

Thom: Boy, you’re absolutely right about that!

I know as a listener, I am very impressed with her. Katrina doesn’t seem to speak as often, but when she has something to say, it’s usually very insightful.

James: Yes, both her and Avdi are the quiet ones. They don’t jump in there and butt in a lot. I’m the loud one. I’m the one they can never get to shut up, right? They don’t talk as much but whenever they do pipe up and ask a question, it’s very insightful and usually leads to a great discussion.

You also don’t see how much people do behind the scenes, Katrina especially. She used to be a transcriptionist and so, as we’re sitting there talking, we tend to use a lot of horrible things like acronyms or strange words like “The Threequel Operator” or something that would drive a transcriptionist mad. Katrina is sitting there in the back channel typing all those out as we say them, typically.

She supports us a lot in that way and recently she’s been booking shows and stuff, too. She set up the show on Regular Expressions, with Nell Shamrell, which was a really great episode. So she helps out a lot even when she’s not asking questions. But I tend to enjoy the ones where I take a week off. Without me butting in all the time, I think the others get to talk more and I always enjoy those episodes.

Thom: So the Ruby Rogues has crossed 100 Episodes, which is a pretty big deal.

James: Yeah, we were surprised.

Thom: Does it feel like it’s been 100 or maybe, in some ways, it feels like it’s been more?

James: You know, I think we were all surprised when we hit the 100-episode milestone, that we’d been going so long. Just the other day we realized that our mailing list was one year old, and that’s shocking.

Thom: Oh, what a great confluence.

James: I think we’re all surprised by it. I’m sure that there’ll come a point when burn-out sets in or we feel like we’ve talked about all the things we want to talk about. But I can tell you from our current list that we have a lot of things we would like to talk about and we haven’t gotten to. I mean, like you said, we’re 100 episodes in and Regular Expressions is one of my favorite things in all of Ruby and we just did the episode on that.

Thom: That’s exciting.

James: I was excited about doing that one, too, although I think it has even more of the problem, as usual, of me talking too much because it’s my favorite subject.

Thom: You’ve been a pretty regular contributor to Rails, and since you mentioned you’ve been involved in Ruby even before Rails, how does that feel to have such a strong influence on something that has become quite an important and well-recognized framework?

James: Actually, I’ve only contributed to Rails a couple of times in minor ways. I have done a lot as far as the teaching Rails and stuff, but as far as the source code itself, I’ve only had a few small commits.
Josh, actually has done quite a bit more than I have as far as contributions.

Thom: Okay, I misunderstood that then, but you’ve written a lot of Gems.

James: I have written a lot of Gems, I don’t know how many of them actually end up being useful…

Thom: We all feel that way.

James: Right, right. The FasterCSV Gem is probably the one I’ve had that’s been the most successful, that eventually became the CSV Standard Library in Ruby 1.9 and on.

Thom: That’s something to be proud of, certainly.

James: Yes, I was glad to see that. The HighLine Gem that I wrote with Greg Brown’s help, it also is still pretty widely used, I believe. Those are probably the two I’ve written that have had the most impact.

Thom: You mentioned earlier, and I realize it was kind of in the vein of self-deprecating humor, but you mentioned that you’re the one that’s always talking and butting in. But honestly, what do you see as your role in this panel of an obviously very diverse group of people with different perspectives? Do you see yourself as providing some specific role or guidance there?

James: At one time Josh put up the various roles of TV Tropes—the TV Tropes website has a TV Trope called a “Five-Man Band” and for like a week afterward we were all trying to figure out which position is us.

But seriously, I think one of the things that I bring to the table in the Rogues is not so much technique and things like that, I think the others are better at that than me. Josh especially has a really strong Rails background and Avdi being so good with patterns and things like that. Katrina, the great communicator, like I said before. David is funnier than I am and Chuck is the glue that makes the whole thing possible.

But I have an almost encyclopedic knowledge of the various corners of Ruby and that comes mostly from running The Ruby Quiz for three years. Every week people would email all these programs to me and I had to read through them and understand them enough that I could talk about them in the write-up I did that week. People solving programming problems use every dirty and metaprogramming trick in the book. So, in my time overseeing that contest, I’ve learned so many dark corners of Ruby and the API. I don’t know what percentage of it is actually in my head, but it’s a very high percentage.

Thom: That’s wonderful.

James: Just because I’ve played with it a lot and had to figure that stuff out. When we did the regex discussion, at one point we got into the horrors of why the replacement strings of sub and gsub. Why do I have to start doubling my backslashes and I end up with four or eight or whatever? I’m like, “Oh, that’s because,” you know, and I start explaining why that is.

I think that’s maybe the thing I bring to the table. I have the knowledge of Ruby and how it works.

Thom: A final question. Is there anything that you’re working on presently that you would like to promote or to tell the world about?

James: That’s a good question. I’m one of those people that never hurts for ideas. I wake up every day with more ideas and I keep this file on my computer where I squirrel them all away for some day. I’m always working on 3-500 of them at any given time.

Thom: Is that 3 to 500 and not 300 to 500?

James: Yeah, it’s something like that. “Too many” is how my wife would describe it, I’m sure. I never hurt for ideas, but, some become other things or some I end up using on work projects or some I give up on for various reasons of time or realize it was a bad idea or whatever. I don’t know which ones actually end up being things that get there. I think we all have that problem. There’s several things I’m working on that I hope turn out to be as cool as I think they’ll be, but I don’t think I’m ready to share those yet.

I will say the one thing, of interest to Rogues listeners, that we’re working on. We’ve mentioned it a bunch in the past and there was kind of a long period of us not talking about it for various reasons, mostly just getting it all working, but we are in the process of working on the Ruby Rogues first book, which will be “Ruby Best Practice Patterns”, a Ruby port [basically] of SmallTalk Best Practice Patterns from Kent Beck.

Thom: Oh, that’s an excellent idea for a book.

James: I want to say that as one of the Ruby Rogues, I feel very lucky to spend time every week with the likes of Josh Susser, Avdi Grimm, David Brady, Charles Max Wood and Katrina Owen.

Thom: Thank you, James, for your time and the insight you provided us.

James Edward Gray II can be found, in addition to the weekly broadcast of the Ruby Rogues,

• Twitter
• Github

However, making your first contribution to an open source library can be very daunting. If you’re like me, I was/am nagged by self-doubt and a fear that I would/will “do it wrong.” I worry about the mocking of other developers, all solidified by years of open source contributions. They will shred my code and use my avatar as a meme to terrible coding.

I did, eventually, get past this fear. I have contributed to a few open source projects (AngularJS, neography, jquery-ui, just to name a few) and I can tell you it’s not so bad. If you are stuck in the self-doubt phase, but want to jump in, you may be asking “What’s the first step?” or “How do I contribute?” Well, I aim to answer those kinds of questions by walking you through my attempt at contributing to the wonderful guard-jruby-rspec gem.

The Steps are:
1. Search
2. Fork
3. Prepare Your Local Environment
4. Write a Test
5. Fix It
6. Commit and Push It
7. Test It
8. Issue the Pull Request

The Gem

I am currently working on a JRuby project that uses RSpec. Running the tests continuously, automatically, and (most importantly) quickly is paramount. I pulled in the guard-jruby-rspec gem to do just that, and it runs my tests faster than any other solution I’ve seen on any Ruby project. Joe Kutner , author of Deploying with JRuby has done a brilliant job with the gem. (Joe also reviewed this article, so thanks for that too!)

Briefly, let me explain what guard-jruby-rspec does. The gem is a plugin to Guard which, according to its Github page, is “a command line tool to easily handle events on file system modifications.” It is most often used to monitor files in a Ruby or Rails project and fire off the affected tests as files change. If a controller file is changed, the corresponding test file is automatically run. This is invaluable, as you get constant feedback as you code. Automate all the things.

Guard has a thriving plugin framework, and guard-jruby-rspec is one of the many plugins. guard-jruby-rspec, as you may have guessed, runs RSpec on files based on “watchers” in you Guardfile. It leverages JRuby to minimize the loading time for each test.

In a Rails app, for example, if the Guardfile looks like:

interactor :simple
guard 'jruby-rspec' do
  watch(%r{^spec/.+\_spec.rb$})
  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
  watch('spec/spec_helper.rb')  { "spec" }
  # Rails example
  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/#{m[1]}_spec.rb" }
  watch(%r{^app/(.*)(\.erb|\.haml)$})                 { |m| "spec/#{m[1]}#{m[2]}_spec.rb" }
  # HEY THIS LINE IS IMPORTANT
  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb", "spec/acceptance/#{m[1]}_spec.rb"] }
  watch(%r{^spec/support/(.+)\.rb$})                  { "spec" }
  watch('app/controllers/application_controller.rb')  { "spec/controllers" }
  # Capybara features specs
  watch(%r{^app/views/(.+)/.*\.(erb|haml)$})          { |m| "spec/features/#{m[1]}_spec.rb" }
end

Anytime a file changes that matchers a watcher, the specs run. If you pass in a block to the watcher, you can narrow down the specs that will run. In other words, when I change a model file it will run just the model spec.

The Problem

As I was working, I noticed that Guard would fail anytime I changed and saved a controller file. Here is the error:

16:29:43 - ERROR - Guard::JRubyRSpec failed to achieve its <run_on_changes>, exception was:
[# NoMethodError: undefined method `match' for #<Array:0x4816505b>
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:50:in `spec_folder?'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:38:in `should_run_spec_file?'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:30:in `clean'
[#] org/jruby/RubyArray.java:2395:in `select'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:30:in `clean'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:62:in `clear_spec_files_list_after'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec/inspector.rb:29:in `clean'
[#] /home/vagrant/ws/rental_express/ROOT/rails/.bundle/jruby/1.8/gems/guard-rspec-2.5.4/lib/guard/rspec.rb:85:in `run_on_changes'
[#] /vagrant/git/guard-jruby-rspec/lib/guard/jruby-rspec.rb:74:in `run_on_changes'
[#] org/jruby/RubyKernel.java:2080:in `send'
...

I started looking around to see if I could figure out how to fix this error, and this is how I did it.

Step 1: Search

In many cases, you are not the first one to find an issue. Especially if the issue is with a well-used gem or framework, like Rails. Before you start frolicking through the code, it’s smart to ask Google to see if someone else has the issue.

Also, you should find the code base on Github (the vast majority of open source gems/code can be found on Github) and search its issues for your problem. Chances are someone else is also having the issue and/or working on a fix.

What do you search for? I find that using the meat of the error message (if you have one) has a high incidence of success. Take out the line numbers and your local computer/directory names and search for the error. In this example, I searched for the following:

• NoMethodError: undefined method `match’ for Array
• JRuby Guard NoMethodError: undefined method `match’ for Array

No dice.

If you don’t have an error or your error isn’t helping, try searching for the major gems involved. In this case, I might search for “Guard JRuby Rspec Rails Array match” and see what pops up. Most times, you’ll get a few StackOverflow hits and you’ll be on the road to recovery. This, however, was not the case for me. Sad panda.

I found the code on Github and searched the repository for “undefined method match for Array” and BINGO! Sure enough, someone else had the same issue. It was only a day old, as well, so there was still blood in the water.

I added a “I am getting this too” comment and let them know what version of the gem I am using. In this case, I also added “I plan to investigate further” to let them know that I was taking a crack at fixing it. On to Step 2…

Step 2: Fork

Since the code for the gem I am investigating is on Github, I can easily make my own copy of it. This is called “forking” and is a step in the process made possible by the fantastic-ness of Github. Some people think forking is a git thing, but it is not. All forking does is copy/clone the repository to a location under your user on Github. In my case, I now have ruprict/guard-jruby-rspec repository that I can hack on to my heart’s content.

Once I have a fork, I like to add it to my Gemfile and make sure the issue is still happening. In order to add a gem to your Gemfile that is sourced from a github repository, you do this:

gem 'guard-jruby-rspec', github: 'ruprict/guard-jruby-rspec'

After a quick bundle, I run guard and make sure the issue is still there. It is.

Now, I need to get this code locally on my laptop so I can start working on it. This is a simple git clone git@github.com:ruprict/guard-jruby-rspec.git from my local terminal, and we’re cooking with gas. Step 3, you’re up.

Step 3: Prepare Your Local Environment

OK, I’ve cloned the repo and switched into my local directory. I like to wall off my work when I am working on something like this, so I use RVM because it is fabulous.

Since this is a JRuby gem, I need to make sure I have JRuby installed (I am using 1.7.4, so rvm install jruby) and then create a gemset. I named my gemset “guard-jruby-rspec” and added a .ruby-version and .ruby-gemset to the directory so that it switches to the right environment when I am in this directory. You can use .rvmrc file (link) for this too, but everything seems to be going the way of .ruby-version.

Once you’re in your new gemset (or other walled-off environment) run bundle install to install all the dependencies of the gem. Most gemspecs will have a Gemfile that points to the dependencies listed in the gemspec file. You’ll see all your dependencies go by, like so:

We are now to the most important step in preparing our development environment: Running the tests/specs. This is Ruby, so all gems should have some tests. You should NOT start development until the existing tests run successfully in your environment. Most often it is simply a case of running rake test or rake spec or, in this case, rspec.

OK, tests are passing. Excelllent. Now we can hack.

I like to make a git branch for my work so the “pristine” environment is just a git checkout away.

git checkout -b array_error_in_custom_watcher
git push -u origin array_error_in_custom_watcher

The second command forces my local branch to track a branch on my github repository with the same name. I dig it.

Many gems/repositories will have a section in their README on how to contribute, so make sure you have read that and are following the requested process. guard-jruby-rspec does not have one that I can find (but Angular has a monster), so I am following the “most common” process as I know it.

Step 4: Write a Test

Test Driven Development tells us that you should write a test to reproduce any bug that you are fixing. Sometimes, this is very easy. Other times, not so much. In this case, it’s somewhere in the middle. I don’t know how Guard works, so I am going to have to do some investigating into how Guard is put together in order to figure out how to make a test that reproduces the error.

It’s a bit more difficult in this case, since the error actually happens in the guard-rspec code. It’s unlikely that guard-rspec has the issue, though, as no one seems to complain about this error on that repository.

What makes this a bit more frustrating is that I think I know what the fix is. In this case, when an array of test targets is passed from a watcher block, we’re getting a NoMethodError on Array. It has to be more than a coincidence that Array is issuing the error and we are returning an Array in our watcher. Go back and look at the Guardfile to see the line I am talking about.

Looking at the stacktrace, the last time the test is on the guard-jruby-rspec code is on line 74 in the run_on_changes method, which looks like:

def run_on_changes(raw_paths)
  unload_previous_examples
  @reloaders.reload(raw_paths)
  unless @custom_watchers.nil? or @custom_watchers.empty?
    paths = []
    raw_paths.each do |p|
      @custom_watchers.each do |w|
        if (m = w.match(p))
          paths << (w.action.nil? ? p : w.call_action(m))
        end
      end
    end
    super(paths) # THIS IS LINE 74
  end
end

That paths variable is an array of files to run based on the changes passed in to the function in the raw_paths argument. By putting in various puts statements, I know that paths is an array of arrays when it fails. The question is, how do I write a test that reproduces the issue?

First, I look at the existing tests. I want to try and use the same style and I certainly want to leverage the same tricks (mocking, etc) so I look through the test files to find a spot where I think the test fits best. My first few attempts either break “wrongly” or pass when they should fail. Some of the existing tests mock two objects runner and inspector. By tracing the code through the guard-rspec gem (the super call calls the run_on_changes method for Guard::RSpec), I realize that the mocked call to inspector.clean is the key to what I want.

That call takes an array of paths and, when things are right, it should NOT have an array as an element in the outer array. With that knowledge, I can write an expectation test that ensures the mocked call to inspector has the appropriate arguments.

# guard-jruby-rspec/spec/guard/jruby-guard_spec.rb:226
it "works with watchers that have an array of test targets" do
  subject = described_class.new([Guard::Watcher.new(%r{^spec/(.+)$}, lambda { |m| ["spec/#{m[1]}_match", "spec/#{m[1]}_another.rb"]})])
  test_targets = ["spec/quack_spec_match", "spec/quack_spec_another.rb"]
  inspector.should_receive(:clean).with(test_targets).and_return(test_targets) # THIS IS THE TEST
  runner.should_receive(:run).with(test_targets) { true }
  subject.run_on_change(['spec/quack_spec'])
end

The test creates a watcher that returns an array of test locations. The test_targets variable is what the inspector SHOULD recieve when things are working. When I run this test, I get a failure on the expectation, because the call to inspector.clean gets an array with an array as the first element.

If this seems daunting, it isn’t. The actual process took me around an hour, and I had a lot of failures, wild goose chasing, etc. Each time I failed, I learned a little bit more about the code until I figured out how I needed to structure my test. There are tools that make the investigation of an issue much easier.

For example, I recently discovered vim-bundler by Tim “I should be given a medal” Pope. This glorious plugin allows me to open gems in my bundle with a simple Btabedit <gem name>, where I can edit the gem in place and never leave my editor. I screamed like a rabid, Beatles fan when I found vim-bundler. Really. Much of my investigation was placing puts statements, etc. into other gems (like Guard::RSpec), which allowed me to see what was happening as I messed about in the code.

Ahhh, with a test showing the issue. Step 5 will be a breeze.

Step 5: Fix It

As I mentioned, writing a test to catch the issue is almost always harder than fixing the code. That is true here, as the fix is simply adding .flatten to the paths array we are passing up our inheritance chain.

def run_on_changes(raw_paths)
  unload_previous_examples
  @reloaders.reload(raw_paths)
  unless @custom_watchers.nil? or @custom_watchers.empty?
    paths = []
    raw_paths.each do |p|
      @custom_watchers.each do |w|
        if (m = w.match(p))
          paths << (w.action.nil? ? p : w.call_action(m))
        end
      end
    end
    super(paths.flatten) # Here be the change, mon.
  end
end
 

The tests run again and they pass. I sit back and soak in the good feeling.

It’s worth noting that this may or may not be the best solution. In this case, it’s not much code and I have a test. I am happy enough with the code to move on to Step 6.

Step 6: Commit and Push It (Get Up on This!)

I can now commit the code. A word of caution here: Make sure that your changes only include what the fix NEEDS. In one of my earliest contributions, I had a bunch of whitespace changes left over from adding puts statements or other debug statements. This made my commit touch more files than necessary, and that is not cool.

In this case, here is my git diff:

As you can see, my changes are just the test and the change. Nice and clean.

Also, make sure you don’t commit any new files accidentally. If you’re in the habit of doing a git add ., then you are in danger of committing temporary editor files or anything else that may have snuck into your path while you were working.

Finally, make your commit message informative. A good (if not maybe a little overdone) example is the AngularJS commit message conventions. That example is probably at the far end of the SuperDuper Commit Message Spectrum, but it’s unlikely that anyone will complain if you put too much info into the commit message.

Here is my commit message:

Step 7: Test It

I like to go back to the my project where I originally found the bug and add my github repository into the Gemfile, bundle, then make sure the issue is no more. In this case, I add
gem "guard-jruby-rspec, github: "ruprict/guard-jruby-rspec, branch: "array_error_in_custom_watcher"
to the Gemfile and run bundle update guard-jruby-rspec.

Now, recreate or go back to the environment that exercises the bug. For me, I simple added the custom watcher that returns an array of test targets back to the Guardfile in my project, started guard (guard), and changed a controller file. I put in an obvious failure, then removed it.

Since Guard didn’t blow up all over the place, I am good. The error, she is vanquished!

Step 8: Issue the Pull Request

The moment has finally arrived. You are about to embark on a journey of open source contributions that will take you to faraway lands and introduce you to alien folk. Or something.
Go to the branch on your GH repo and click the Pull Request button.

In your message, mention any issues that you may have read that are fixed or affected by the PR. In my case, I mentioned the issue I found that had the same error. You can mention an issue simply by linking to it in your comment. If your commit message is OK, you shouldn’t have to type much more than the issue reference.
Your self-doubt may rise to the surface here, but just go for it. I have yet to meet a OSS author that isn’t appreciative of someone trying to help. Even if you mess it up, learn, fix, and resubmit it. It’s the only way you’ll become an OSS contributing machine.

Congratulations! An optional Step 9 is to have a celebratory adult beverage!

Wrap Up

I hope this post helps someone get over their fear and apprehesion of contributing to open source. Trust me, if I can do it, ANYONE can do it.  If you are having a hard time finding a bug to work on, I would suggest signing up for Code Triage which exists to facilitate finding places to help in popular open source libraries.

Good luck!

What exactly is network architecture and what does it represent in web app development? Why discuss Network Architecture these days?

Those might be some of your questions after reading the title of this article, and this just supports the point that I’ll explain in this post.

Network Architecture

What is It?

There are a lot of different interpretations, but one that fits the bill is one I found on Wikipedia:

Network architecture is the design of a communications network. It is a framework for the specification of a network’s physical components and their functional organization and configuration, its operational principles and procedures, as well as data formats used in its operation.

There is a lot of information in this little sentence, but one detail that surprised me was the word design. It reminds me of planning, beauty, and functionality. It’s not just about socket connections, it’s also about dealing with those connections in smart ways.

Why Talk About It?

I will try to illustrate this by using a common example. Here’s a question for you: Which line is longer?

We all know that, despite any observations to the contrary, the right answer is that both have the same length. However, this time I have changed the rules and, actually, there is a longer line. We are so used to giving the same answer that we just ignore our instincts, and this is exactly what is happening in the world of Network Architecture these days.

It’s simple: Something has changed in the way the world works. Somebody changed the way we relate with devices and apps in the past 5 years. However, nobody mentioned how we – as developers – should adapt ourselves to the new paradigms, so we just keep “giving the same answer”.

What Has Changed?

Has the network changed? No. It’s faster, but it hasn’t changed really. We may have to deal with it in different ways if we want to build better and faster applications. I believe that this can and will produce a huge change in the technology market in the next few years.

If it isn’t the network, what has possibly changed so fast that we are not able to keep up? The societal values.

Society, more often than not, is changing its values. If there is something that is becoming really precious, it is time. Time has become the most important resource to everyone and now time is actually money and nobody wants to waste it anymore.

Developers should be able to respond to the new demands of all users around the world. We should be focusing on building real time applications, or at least applications that don’t make our users waste their time. Our mission should be reduce the load time to zero!

Bottlenecks

Unfortunately, it’s not so simple. There is always a bottleneck and this time it’s the network. How are we supposed to build faster and real time applications if we don’t even know how our apps will behave on Edge, 3G, 4G or even a regular wired connection?

Where is Gaming on This?

If there is a market that has always been concerned about real time and responsive applications, in spite of network constraints, it is the games market. We’ve been building online games since the days of slow dial-up connections in the 90′s. How did they do it? By asking themselves a simple question: If speed is important, why do we keep depending solely on the raw speed of the network?

The result of this mindset is quite easy to visualize. Below you can see the difference between a regular Web Application flow and a Massive Multiplayer Online Role Playing Game (MMORPG) flow:

In the usual flow, there are actions that result in wait times while the application and server deal with our request and the interface is updated.
But when we are talking about network multiplayer games, we can’t have wait times. The action can’t stop to load the next one as everyone must seem to be sharing the same reality from different points of view. As a result, the flow will be something more like this:

This flow is only possible because we are not talking about speed at all, we are talking about perceived speed. It’s about cheating, because the users don’t care what is really happening in the background.

There are lots of techniques used in gaming that follow this concept. We could and should apply them to our web development process. We will go through four simple techniques that can change a lot about how you are used to build applications.

The Fantastic Four Techniques

Render in Client

This technique is quite well-known for those who enjoy cutting edge technologies. There are many javascript frameworks and libraries that claim to be “the-best-template-solution-ever” and with all these options on the market there is no excuse to not find something that fits your needs. It will certainly make a huge difference in your application performance and user experience. Everything will be loaded at the beginning and the interface will be able to update itself.

Even if this technique is quite common, there are still plenty of people that avoid this technique. Most of them argue that those libraries don’t have support for all the devices and browsers that are on the market, so they don’t use it. It doesn’t make any sense.

For a second, let’s compare browsers with televisions. Imagine that we have different types of televisions, some high quality with all this awesome technology alongside your grandmother’s television from 90′s, each representing a browser, I can’t tell which coughs:

There is one single signal that is sent to all of the televisions, regardless of what it supports, and each one will render the best image possible. This is called graceful degradation, and the result would be something like this:

When a developer decide not to use render-in-client technique because of lack of browser support, this would be the expected result:

Don’t be afraid to deliver the best quality possible for those that can use it. Graceful degradation is a simple concept that can change things a lot.

Store Data in Client

Making less requests can make your application faster, but sometimes we don’t realize how simple it is to just store some data in the client instead of sending it to the server. It will not only save you some infrastructure resources, but also help you avoid useless data in the database.

Some years ago, it was hard to think about storing data in the client, all we had were cookies and sessions, and it wasn’t safe and spacious enough to be useful. With HTML5, we have LocalStorage, a lot of space, and an amazing API to make everything easier. Why not start to think twice before making remote requests?

Intelligent Preload

The word that better describes intelligent preload is Prediction. Usually, when we talk about prediction, developers get scared. They start to think about machine learning and huge formulas, but prediction can be quite easy.The actions that your users will take next are the ones that you should offer.

Let me illustrate this by showing an example. This would be the basic flow of an Instagram application:

People think that their image is uploaded when the “send” button is pushed, but actually, your image starts to be uploaded at the transition represented by the red dotted line.

The application assumes that once you selected the shot and scaled and applied filters on the picture, the most expected next action will be to share it. It isn’t hard to predict, right? No magic formulas. The application will start to upload your image, and once you push the “send” button, it feels faster. Not because it is fast, but because it seems fast.

If you start to build intelligent applications using logic and preloading assets by predicting the user actions, it will make a huge difference on user perception.

Asynchronicity

This is a term that everyone uses, but only a few are concerned about the real proposal behind it.
The goal is to detach the view from the server. The server will only respond when requested by the interface, and the interface will update itself and not make the user wait for the response.

A basic example would be the Gmail interface on iOS. All you have to do to delete an email is to select it and push “delete”. The email will automatically and magically go away, disappearing from the interface. However, it hasn’t been deleted yet, nor was the request wasn’t sent over the wire. This will happen in the background.
The point is that the email is not visible and the user is not staring at a spinner or a progress bar. He can keep using your application, being confident that that email was deleted.

But, What If the Server Fails?

It isn’t a problem, machines are expected to fail.
Just let the user know that it happened and ask him to try again later, I guarantee you that your user will not get mad of being informed about an inconvenienc. He will, however, if you make him stare at a load bar for many minutes while your interface is locked waiting for a server response.

Let’s do it!

Yeah! Let’s do it, let’s build awesome-freaking-zero-load-time-applications, but remember, there isn’t a silver bullet. These techniques are not a solution to all problems, just a collection of good techniques that are used on games.

They represent a new range of possibilities to our web app development process, helping us follow the users’ requirements. Don’t forget, our mission is reduce the load time to zero!.

This article is based on one of my recent talks that I had the opportunity to present at the TakeOff Conference in Lille, France in January. It was pretty funny, if you wanna laugh a little bit, you can watch it on YouTube.

“Ruby is designed to make programmers happy.” – Yukihiro “Matz” Matsumoto

Not everyone might agree, but as a Rubyist I think Matz achieved his design goal. There’s something intangible about Ruby’s syntax that makes it fun, rewarding and easy to use – something that makes me happy. I thought it would be fun to compare Ruby with a few other languages by looking at how different open source developers implemented the same method or function in each language. How do the languages differ? Do they make you equally happy?

And what better example to look at than inside of Ruby itself! Today I’m going to look at how Ruby’s Hash#fetch method is implemented in Ruby (by Rubinius), Python (by Topaz), Java (by JRuby) and finally in C (by standard Ruby 2.0). Of course, there are many other programming languages out there, even other versions of Ruby, but looking at a small slice of Ruby internals gives us an interesting example and allows us to compare apples with apples.

Hash#fetch

For those of you not familiar with Ruby, or with the the Hash#fetch method, let’s first review what the Hash#fetch does. Fetch allows you to lookup a value from a hash using a key, just like the [] method does. In addition, fetch also allows you to specify a default value Ruby should return if it can’t find the requested key. Here’s the example from the Ruby documentation:

Also, if you provide a block Ruby will call it to get a return value if it can’t find the requested key:

Hash#fetch in Rubinius

Let’s start our survey by looking at how Rubinius implements Hash#fetch. Since Rubinius uses Ruby to implement its kernel, reading the Rubinius source code is a great way to understand exactly what a given Ruby method does.

Here’s the Rubinius implementation of Hash#fetch from kernel/common/hash19.rb:

As you can see here, there’s a lot to criticize in Ruby’s syntax. And certainly this isn’t the most elegant example of Ruby code in the world.

But I like it. It makes me happy. Why? Because it’s simple to understand what this code does. The Ruby language doesn’t get in the way of the meaning of the code, of what the code is trying to achieve.

Reading Ruby is almost like reading pseudocode – you know, the sort of code you write on a whiteboard while trying to explain some idea or algorithm. Why do you use pseudocode? Because you don’t have time to fuss with language syntax. You just want to get your point across. For me, writing Ruby is just like writing pseudocode.

Hash#fetch in Topaz

One of the more exciting events this year in the Ruby community was the news that Alex Gaynor had implemented Ruby using Python and the PyPy toolkit. PyPy allows Python developers to implement a compiler and virtual machine for their own language using a subset of Python called “RPython.” PyPy converts the developer’s custom VM into C using a sophisticated series of optimizations, and later compiles the C into fast, native machine language.

Let’s see how the same code looks in Python:

To me Python really seems like a sister language to Ruby. Aside from some minor differences around whitespace, colons and end keywords, the two languages are quite similar.

One important difference between the two is that Python doesn’t support closures in the same elegant way that Ruby does with blocks. The block parameter and invoke_block call here are part of the implementation of Ruby blocks for Topaz.

It’s almost as easy to read this code as it was to read the Rubinius implementation. Any additional code or verbosity here is just due to the details of the way Topaz works internally. I think I could become happy using Python if I spent some time learning to use the language – at least if my editor handled whitespace properly!

Hash#fetch in JRuby

The similarity between Ruby and Python become more obvious when you compare either of them with Java. To see what I mean, take a look at the JRuby implementation of Hash#fetch:

The same code is just a bit more verbose in Java than it was in Python or Ruby. Trying to read and understand this code takes a bit more effort than it did before. First you have to train your eyes not to see semicolons, parentheses or braces.

More importantly, the way Java works begins to get in the way of the algorithm. The clearest example of this is the use of an interface IRubyObject to handle the method’s arguments and return value. Since Java is a statically typed language, you have to worry about exactly what type of value each object is.

Depending on how you look at them, Java interfaces are either an awkward workaround for this problem, or an elegant way to insure each object provides the API you require, allowing the Java compiler to give you helpful error messages. But for me, they are unnecessary typing and thinking. I’m starting to forget what I was trying to achieve and worrying more about how the Java compiler works. The Java compiler should be making me happy, not the other way around!

Hash#fetch in C

Now let’s take a look at the official version of Hash#fetch. This is the C code that your Ruby program actually uses if you’re running Ruby 2.0:

Now the level of verbosity jumps even more. In C, not only do we have the same static types we saw in Java, but now I have to worrying about pointers, memory management, and hardware optimizations using keywords such as “volatile.”

If you’re familiar with the idiomatic style of Ruby’s source code, with constructs like “RHASH,” “st_lookup” and “rb_scan_args,” then it’s not that hard to follow this. But there are still very confusing details here, such as the use of rb_protect to handle exceptions that might occur while generating the “key not found” error message.

Writing C code like this, I have to be completely aware of how each piece of data is represented by my computer’s hardware. How many bytes does it use? Does this API expect a value or a pointer? Do I need to free the memory this pointer references?

Unfair Comparisons

Of course, all of these languages are very different, intended for different purposes. C is really shorthand for writing assembly language, and, if used well, gives you tremendous control, flexibility and speed. Java allows you to write elegant, clean, and object oriented code without worry about hardware details or portability issues. And it still runs quite fast on the JVM. JRuby, in fact, is one of the fastest versions of Ruby around, faster than MRI Ruby in some cases.

My reason for comparing these languages to each other is to remind you of how happy you are writing Ruby. Don’t take it for granted! Matz and the Ruby core team have done a tremendous amount of work for the past 20 years to bring you programmer happiness.

And why have other talented open source developers worked so hard to reimplement Ruby using different languages, such as Java, Python or Ruby itself? Because they love Ruby also. They want to bring that happiness to their own platform or technology.

  a href="/pages/#{@page.id}/edit" Edit this page,
  a href="/pages/delete/#{@page.id}" Delete this page

Editing Pages

We need to create a route handler for when the user clicks on the edit page URL. Add the following to main.rb (but make sure that it goes before the ‘/pages/:id’ route):

  get '/pages/:id/edit' do
    @page = Page.find(params[:id])
    slim :edit
  end

This finds the page that is to be edited in the database using the id provided in the URL and stores it in an instance variable called @page. This will be accessible in the view, which is called edit.slim. We need to create that, so let’s do that now. Save the following as edit.slim in the views directory:

  h1 Edit Page
  form action="/pages/#{@page.id}" method="POST"
    input type="hidden" name="_method" value="PUT"
    fieldset
      legend Edit page
      == slim :form
    input type="submit" value="Update"

Notice that this reuses the form partial that we used for the new page in the last tutorial. This keeps things consistent and keeps our code DRY. The form refers to values in the @page object, so some of the fields should be filled in with their current values. The form also has a hidden field that is used to tell Sinatra that the request is a PUT request. This is because most browsers don’t natively support any HTTP verbs other than GET and POST. The solution is to use Sinatra’s method override so that the request will be routed as if it was a PUT request. We are using a PUT request in this case because we are updating the resource.

Next, we need to deal with what happens when the form is submitted. We need another route handler to deal with that, so add the following to main.rb:

  put '/pages/:id' do
    page = Page.find(params[:id])
    page.update_attributes(params[:page])
    redirect to("/pages/#{page.id}")
  end

This finds the page that needs to be updated and updates it using Mongoid’s update_attributes method. It then redirects the user to the newly udpated page.

Deleting Pages

To delete a page, we are going to create a two-step process. First, we display a confirmation page to check that the user wishes to delete the page. Here is the route handler for that page:

  get '/pages/delete/:id' do
    @page = Page.find(params[:id])
    slim :delete
  end

This route handler simply finds the page that is to be deleted and then shows a confirmation page. We need to create a view for this page, saved as delete.slim in the views directory:

  h1 Delete Page
  p Are you sure you want to delete the page called #{@page.title}?
  form action="/pages/#{@page.id}" method="POST"
    input type="hidden" name="_method" value="DELETE"
    input type="submit" value="Delete"
  a href="/pages" cancel

We have to use a form to do this, as we will be using the DELETE HTTP method in our route handler that will delete the page. If we use a link then we can only use GET methods. We also need to use a hidden input field once again to use Sinatra’s method override, this time telling it to route the request as a DELETE method.

All that is left to do is add a route handler at the bottom of main.rb to deal with that request:

    delete '/pages/:id' do
      Page.find(params[:id]).destroy
      redirect to('/pages')
    end

This simply finds the page and uses the destroy method to remove it from the database. It then redirects to the page index.

Permalinks

So far we have been using the id of the Page object as a URL. MongoDB uses very big ids, so this means we have URLS such as /pages/5173f443a39401776a000001. These are very long, and not very descriptive, so it would be nice if we could create a ‘pretty URL’ based on the title of the page.

To do this we have to add a new field to our Page model called permalink. This can be done with the following line of code:

  field :permalink, type: String, default: -> { make_permalink }

This is not going to be a field that is filled in by the user in a form. It will be automatically created based on the title. We do this by using adding a default value that is set with a lambda that refers to a method called make_permalink. This method takes the title of the page and removes any spaces or punctuation with a hyphen (‘-’) using various string methods. Here is the method, it just needs to go inside the Page class:

  def make_permalink
    title.downcase.gsub(/\W/,'-').squeeze('-').chomp('-') if title
  end

We can test this functionality in IRB using the following lines of code:

  $> irb
  2.0.0-p0 :001 > require './main'
   => true

Now, search for the first document in our collection and you’ll find, amazingly, it already has a permalink field with an appropriate value:

  2.0.0-p0 :002 > Page.first
  => #This is our first page
", permalink: "hello-world">

Welcome to the world of schemaless databases! Unfortunately, things are not as good as we first thought because if we try to query based on this field, we get an error:

  2.0.0p0 :003 > Page.find_by(permalink: "hello-world")
  Mongoid::Errors::DocumentNotFound:

This is because the Page object with its new permalink field needs to be saved. This is easily done using the following code:

  2.0.0p0 :004 > Page.first.save
   => true

Now we should be able to find the page using it’s permalink:

  2.0.0p0 :005 > Page.find_by(permalink: "hello-world")
   => #This is our first page
", permalink: "hello-world">

Great! This means that every page created so far just needs to be saved to get it’s own permalink. If you have lots of pages, you can do this in one hit with the following line of code:

  2.0.0p0 :007 > Page.all.each{|page| page.save }

Everything seems to be working as it should. Now we just need to create the route handler for pretty URLS. These will simply be the permalink and won’t start with /pages. For example, going to http://localhost:4567/hello-world will show the page with the title of “Hello World!”. This route handler will actually match every route, so to allow other routes to get through we will use Sinatra’s pass method in a resuce block which will be invoked if the page cannot be found in the database.

Add the following code to main.rb:

  get '/:permalink' do
    begin
      @page = Page.find_by(permalink: params[:permalink])
    rescue
      pass
    end
    slim :show
  end

This route handler will try to find the page based on the permalink given in the URL and store it in the @page instance variable before displaying the page using the show view that we have already created. If it can’t find the page in the database, then an error is thrown. The rescue method catches the error and calls the pass method, so Sinatra will simply move along to the next route to see if it matches.

Adding Some Style

Everything is working just as we want, but it all looks a bit nasty. Sinatra makes it really easy to use Sass to put together some nice stylesheets. All you need to do is add the following route handler to main.rb:

  get('/styles/main.css'){ scss :styles }

Then place the following line in your layout file:

  link rel="stylesheet" href="/styles/main.css"

Then create a file called styles.scss and save it in the views directory. This is where you put all of your styles.

Here is one I knocked together. It adds a bit of color, makes the form a bit nicer and makes some of the links and submit input fields look like buttons:

  $blue: #0166FF;
  body{
    margin: 0;
    padding: 0;
    font: 13px/1.2 helvetica, arial, sans-serif;
  }
  h1,h2,h3,h4,h5,h6{
    color: $blue;
  }
  .logo {
    background: #444;
    margin: 0;
    padding: 20px 10px;
    font-size: 44px;
    a,a:visited{ color: $blue; text-decoration: none;}
  }
  .button{
    border: none;
    border-radius: 8px;
    padding: 8px 12px;
    margin: 4px;
    color: #fff;
    background: $blue;
    text-decoration: none;
    font-weight: bold;
    display: inline-block;
    width: auto;
    &:hover{
      background: darken($blue,20%);
    }
  }
  label{
    display: block;
    font-weight: bold;
    font-size: 16px;
  }
  form, input, textarea{
    width: 100%;
  }
  input, textarea {
    border: #ccc 1px solid;
    padding: 10px 5px;
    font-size: 16px;
  }

Note for some of these styles to work, you will need to add a class of button to the relevant elements in your views. For example, show.slim now looks like this:

  h1= @page.title
  - if @page.content
    == markdown @page.content
  a.button href="/pages/#{@page.id}/edit" Edit
  a.button href="/pages/delete/#{@page.id}" Delete

… and it looks a lot better for it!

That’s All Folks!

Now we have a fully functioning, albeit very simple, content management system. You can create, update, view and delete pages and they also have some pretty URLs based on their title. In the next part we’re going to create an admin section, flash messages, cache pages, versioning and timestamps. Please post in the comments any other features you’d like to see in the future.

Every week a group of Ruby Enthusiasts get together in a Virtual Roundtable and explore/discuss/argue some aspect of the Ruby language or the Ruby community. They allow the rest of us to listen in on their discussion by way of The Ruby Rogues podcast. The podcast can be accessed on iTunes or on the website and offers a ‘fly on the wall’ view of a great bunch of technology savvy people sharing their ideas and opinions.

In this series of articles I will share the results of my interviews with each member of this special group.

Avdi Grimm is a Hacker, an Author, a Podcaster, a Screencaster, an AirShip Entrepreneur.

Thom: But as with anything like this, the very first question that comes to mind is, tell us a little bit about yourself.

Avdi: First and foremost I’m a dad and a husband. As some folks know, we have five children. My first programming job was when, I was 18. I got a job with a defense contractor working mostly on Air Traffic Control systems. Although some of my early work I did some industrial automation and such.

Thom: That’s pretty cool stuff, and that was with Java?

Avdi: Actually, most of that early work was C++ and C, there was some assembly in there. Very little of the higher-level languages at that point, although later on in that job I did work with both Java and C#. That was mostly doing things like building testing tools; tools that didn’t actually run on the hardware. A lot of the work that I did was middleware, so I did stuff like implementing networking protocols.

Thom: That sounds cool.

Avdi: And when you’re trying to pass packets around really fast and you need to talk to the operating system, networking APIs, C++ or C is often a good choice, especially back then. Java and stuff like that were really kind of immature for that type of work.

A lot of the work that I did on middleware used the ACE libraries and these are the libraries that Doug Schmidt created and he probably still has them up – you know he’s one of the patterns pioneers, particularly one of the concurrency patterns pioneers – and ACE is the framework where things like the Reactor Pattern first appeared. So some of the earliest work in what we now call Evented Programming, where you take the operating system primitives, like Select or other kind of asynchronous primitives, and you wrap that in nice, higher-level OO abstractions like a Reactor or a Proactor, or a Future.

Thom: Right. Tell me about the transition then, from something like that to Ruby. Was it like the story most of us tell; Rails and the Web drew you to Ruby? Or because you were doing testing and other control systems, perhaps you went straight to the Ruby language?

Avdi: It’s always been about a combination of pragmatism and curiosity for me. Very early on in that job, partly just as a matter of interest and curiosity, I did a lot of reading up on the existing scripting languages that were out there. Obviously, Python was already moderately well established. Perl was quite well established. And that’s actually one of the first scripting languages I learned – Perl – because the task at hand, where I decided it was time to learn Perl was. We had these huge mini-Gigabyte dumps of a particular low-level serial protocol and we needed to analyze them. There was documentation for the protocol, but we knew that the documentation was at least partially wrong. So we needed to analyze these huge dumps of actual network traffic to find out what the packets really looked like as opposed to what the documentation claimed they looked like.

I decided everybody used stuff like C and C++ for everything there, but being the young punk that I was, I decided that I could probably be a lot more productive if I wrote analysis tools with a higher level language like Perl.

Thom: Right, that’s what Perl’s designed to do.

Avdi: Right. It’s the Swiss Army Chainsaw for ripping through data.

Thom: Exactly.

Avdi: I had known about it and I decided at that point, “Okay, I’m going to learn this.” I got the Camel book and I just poured over it for days on end, and I wrote some pretty useful software in Perl. I was just really interested in all the scripting languages and kept learning about them.

At one point in 2001, I kicked off a little personal project where I learned Ruby and Python concurrently and did some of the same examples in each one. At the end of that I was just really, really impressed with Ruby.

So I started writing little things that would help me get my job done a bit faster in Ruby. Since a lot of the workstations there were Windows workstations, I messed around with automating Excel using Ruby instead of using VBA. Even back then, the Ruby Windows distributions came with the Win32 OLE library. I also did some stuff involving preprocessing and munging binary images which were going to be burnt onto PROMs – which is what you had before embedded systems had flash memory.

Thom: That sounds like fun stuff.

Avdi: Yes, so I was basically writing these programs to preprocess binary images and I was doing that in Ruby.

Thom: It’s the true spirit of hacking. Personally, I appreciate your little sign-off on your Ruby Tapas because I’ve always been an old-schooler that argues the huge difference between Hacking and Cracking. Having gone through a career in telecommunications, the whole idea of cracking is very familiar to me. The general public tends to have the concept that Hackers are bad. I make the distinction that a hacker is just someone who’s infinitely curious and continually disassembling and deconstructing things in an effort to better understand them.

Avdi: True.

Thom: In contrast, a Cracker is a person nefariously trying to steal from others. What you describe there sounds like the true spirit of hacking.

Avdi: As long as I’ve known about it, I’ve identified very strongly with the Hacker ethos. In that classical sense. Once I discovered the kind of UNIX hacker history, I just dug into it and started using Linux for my primary operating system.

Obviously I didn’t come up with the sign off “Happy Hacking,” that’s something that Free Software Foundation people have been saying for years and I’m sure others as well. I like that it’s about hacking, because I think that’s not a dirty word, like you said, but I also like that it’s about joy, because I think one of the things I most want to project in a lot of the stuff that I put out – particularly Ruby Tapas – is the joy of coding. One of the things that drew me to Ruby in the first place is the fact that it is a language that was deliberately created to be optimized for programmer happiness as opposed to various other more academic optimizations.

Thom: That’s a fine way to put it. I agree.

Avdi: Well, and that’s what Matz has said about it and that was his intent and it really shows through in the language. I think it has already shown through in the community and still does to this day.

Thom: So you took us there; How did Ruby Tapas emerge? I am certain there’s an interesting story behind that.

Avdi: I’ve been trying to figure that out lately. *chuckle*
It was an idea that came to me, I think over a year before I actually managed to launch it. But thinking back now, I can’t actually remember what was that crystallizing moment when I realized, “What if I did really short videos about Ruby?” I had been thinking about screencasting for a long time and I’ve been dabbling in releasing little, incredibly poor quality screencasts on my blog from time to time when there was something that felt it would be hard to demonstrate using just text.

But part of the idea of doing a service was just sheer economic business pragmatism. I am a sole earner for our whole family and I’d been consulting for a while and I’d been augmenting our income with some of the books that I’d released and that was a nice source of secondary income. But it was also kind of tough sometimes when I would have a couple of consulting clients and also be trying to keep up with book writing and then sometimes with consulting. The difficulty in managing all that; sometimes it pours and then sometimes it’s dry.

I had been looking for a way to come up with more of a smooth, even source of income while still doing the stuff that I love. I love coding, but I also love writing about code and the screencasts are really just an extension of writing about code. They’re kind of an excuse to write all the blog posts that I never got around to writing.

At some point it occurred to me that a lot of screencasts seemed like it’s hard to find time for them. So I thought that I’d try my hand at really short ones and see if I could cram just one piece of knowledge into a single short screencast at a time.

Thom: I think that is your “Secret Sauce”, the magic formula. I feel the same way. Five minutes is not only easily digestible, more importantly, I’m less likely to procrastinate watching it. I will devote the time if I know that it’s finite and I know what it is, I will spend the time to go through it.

Avdi: I’m in a very lucky situation. It’s kind of a positive reinforcement system now where I get to see a lot of feedback from the community, both as a Ruby Rogue and speaker and screencaster, et cetera. I get to see a lot of people talking about different techniques and different features of the language. People send stuff my way, I get emails with suggestions for topics or people tweet at me asking about a particular thing.

I benefit a lot from the community and I try to share the things that people send my way.

Thom: Terrific. I need to guide the conversation now to the Ruby Rogues. We’ve read from other Rogues on this, but from you, how did you discover them or how did they discover you? How did you become a Ruby Rogue?

Avdi: Ruby Rogue is the podcast I always wanted to create but I never did. Instead, Chuck and James got to it before me.

I love the panel format on podcasts, I’d listened to CNET’s Buzz Out Loud for years. There’s a Java podcast which – what am I doing listening to a Java podcast?! – but it’s actually a bunch of really smart people, in a panel format, and it is a lot of fun. So I always thought it would be cool to have a podcast like that for Ruby and then I got really excited when I saw that Chuck and James and some others had started to put one together. I listened to it and then I guess they knew about me through my blogging and books and stuff. One day they were missing a panelist and kind of at the last minute said, “Hey, do you want to join us?” and I was like, “Heck, yes!”

Basically the same thing happened again a couple of weeks later; missing a panelist, they didn’t have one of the regulars and they invited me on again. After that, I was incredibly lucky to be invited to stay.

Thom: You’re very busy, obviously with Ruby Tapas, I’m sure. I know from experience that developing something like that takes four or five times the amount of time of the final product, and that’s not counting any of the missteps or re-do or anything you have to do in post-production.

Avdi: A single five-minute video I would say takes somewhere between four and eight hours to put together. When you consider coming up with the idea, honing the code for it, then writing out the script, then recording the screen for the different parts of the screencast, doing the voiceover, and then editing. When you put all that together.

Thom: Yes, you’re building a curriculum for each one and it’s a complete module in itself.

Avdi: Right.

Thom: Do you have any idea of perhaps packaging them into little groups and selling them in a different way as bundles of some sort?

Avdi: I think about stuff like that, but it’s not something I’m going to be doing any time soon. But yeah, I think probably eventually I’ll do something along those lines.

Thom: For clarification, Ruby Tapas is a subscription service where you get access to all of them, historically, right?

Avdi: That is correct.

Thom: It includes the source code and I notice there’s been some active discussions in the comments also, which I think is a great adjunct. When somebody smarter than me makes a comment about something that you brought up and then there’s a little interchange there, I always learn something. It’s a brilliant formula.

Avdi: Thanks, it’s been working out really well.

Thom: Do you have ideas of extending it to maybe other things? Other than just Ruby?

Avdi: Well, I’ll say this much. I reserved CodeTapas.com on the same day that I reserved RubyTapas.com.

Thom: Ah, very interesting.

Thom: The last thing I wanted to ask you about is recently I saw that you generated a kind of…

Avdi: A meme, almost.

Thom: Yes, a meme. Which was a result of your talk at the Ancient City Ruby here in Florida. But tell that story for me, please.

Avdi: I spent the latter half of 2012 as a consulting pair-programmer. I came to the end of my current consulting jobs and rather than looking for a new regular consulting jobs, I started taking appointments for pair-programming. People would sign up with me and pair-program with me for two hours at a time on whatever they wanted. A lot of these were paid, because this was my job, but I also tried to make time for a free one every week, those were always on Open Source software.

It was a tremendous experience. I’d been a fan of pair-programming for a long time anyway, but it really just kind of cemented in my mind the value of pairing. Not just pairing, but pairing diversely. I learned a tremendous amount, I like to think that all the people I paired with learned something and certainly I got a lot of very nice comments from them.

One of my favorites was always when people would end the session with, “Wow, I actually understand my own code a lot better now.” It cemented in my mind how valuable it is, first of all, to practice programming socially. A lot of the people I worked with didn’t have opportunities to pair program or to program with others in any form, or didn’t have a lot of opportunities for that, maybe they were just isolated somehow, they were not in some tech hub and they didn’t have a lot of programmers around or they were the only programmer on their team or something like that.

I could see the value that they were getting from it. Thinking about it, I realized that I really wanted to encourage more programmers to not just pair-program within their own companies, but to pair up diversely; to go out and seek other programmers to pair with on different projects, on their own projects, on other projects, or on Open Source projects, and learn.

For me it’s all about diversity. We know that Biological communities are strengthened by genetic diversity, and I feel like in a very similar way, our community is strengthened by mimetic diversity; a diversity of ideas. There are so many good parts to having somebody else’s perspective. You find new ways to solve problems, you find new ways to think about problems, and there’s this whole psychological aspect to it where working with a lot of other programmers, it just gives you a more three-dimensional and a more positive feeling for the other people working in your field. You realize they’re all human, they are neither gods nor devils, and sometimes I see kind of little explosion of cynicism. Maybe I spend too much time on Twitter, but I see little outbreaks of cynicism in the community and I feel like if people spent less time sort of tweeting at each other grumpily and more time pairing up – working together, hearing each other’s voices, maybe seeing each other on video, or if they are able to, in person — they would be happier programmers. And they would have better feelings for the rest of the community and just generally have a better time. It’s all about happy hacking.

That was basically the idea and I decided to kind of kick off a personal campaign to get programmers to pair up with each other more and I launched that at Ancient City Ruby with my talk there. I launched a tiny website in conjunction with that, PairProgramWith.me, which had, at the time of launch, nothing other than a badge that you could download that said, “Pair with Me” to stick on your website.

The idea is that I’m not really trying to solve a technical problem here. The main thing I’m trying to solve is a social problem where I think that people feel like they can’t ask. I think most programmers, if they thought about it for a little while, they could think of someone they’d love to pair-program with. But it’s just like asking, “Hey, can I pair program with you,” out of the blue is not a thing in our community and I want to make it a thing.

Thom: Well, thanks. Avdi, can we pair-program sometime in the near future?

Avdi: Sure. That would be great.

Avdi Grimm is quite a prominent figure in the Ruby (and Rails) community. You can find him:

• Github
• Blog
• Twitter
• Books
• WideTeams Podcast and Ruby Rogues podcast

Setup

First of all, your app needs to be running on Ruby 1.9+, JRuby 1.6+ or Rubinius 2.0 (with Ruby 1.9 mode on the last 2). Then, install the gem by running

gem install sucker_punch

or add it to you Gemfile via

  gem 'sucker_punch'

And that’s it! Now lets see how to use it.

Creating a Worker

Creating a worker is pretty simple. It’s just a plain ruby class that includes the SuckerPunch::Worker module, and defines one or more instance methods. Sucker Punch suggests just one perform method, but any name and number of methods can be defined and used.

  class SomeWorker
    include SuckerPunch::Worker
    def perform(some_data)
      # Method code. Do some work.
    end
  end

Calling the Worker

Before calling the worker, we need to configure our queues:

  SuckerPunch.config do
    queue name: :some_queue, worker: SomeWorker, workers: 5
    queue name: :welcome_queue, worker: WelcomeEmailWorker, workers: 2
  end

We can define as many queues as we want with as many workers as we want (preferable 2+ per queue), but each can have only one worker class per queue.
More workers equals more parallel jobs that can be performed, but be aware of running out of connections if you’re using a connecting to an external service like a database or memcached.
Then you can access the workers on the queues via

  SuckerPunch::Queue[:some_queue] # or
  SuckerPunch::Queue.new(:some_queue)

This will give us a Celluloid::ActorProxy object wrapping our worker object.
We can call the perform method (or any other method we defined) on that object directly, or use async to return control instantly and make it run in background.

  SuckerPunch::Queue[:welcome_queue].perform(1)
  SuckerPunch::Queue[:welcome_queue].async.perform(1)

Just be aware that running the job async will not raise any exception if it fails. It will just fail silently.

Testing

Everything needs testing, of course!

Fortunately, testing the worker is pretty easy. You can test it as any Ruby class.

With some rspec flavor:

describe WelcomeEmailWorker
  let(:user){ FactoryGirl.create :user }
  let(:worker){ EmailWorker.new }
  describe "#perform" do
    it "delivers an email" do
      expect{ worker.perform(user.id) }.to change{ UserMailer.deliveries.size }.by(1)
    end
  end
end

To test how it integrates with other methods, there are 2 options:

1) Test that it calls and enqueues the job. To do this you need to require 'sucker_punch/testing':

require 'sucker_punch/testing'
describe User do
  describe "#send_welcome_email" do
    it "delivers an email" do
      let(:user){ FactoryGirl.create :user }
      expect{
        user.send_welcome_email
      }.to change{ SuckerPunch::Queue.new(:email).jobs.size }.by(1)
    end
  end
end

2) Running jobs inline. This can be done by requiring 'sucker_punch/testing/inline', and jobs will always be run synchronously.

require 'sucker_punch/testing'
describe User do
  let(:user){ FactoryGirl.create :user }
  describe "#send_welcome_email" do
    it "delivers an email" do
      expect{
        user.send_welcome_email
      }.to change{ UserMailer.deliveries.size }.by(1)
    end
  end
end

Considerations

Tests Running Inside DB Transactions

There’s one thing to have in mind with tests. If you’re running each test inside a transaction, you’ll need to change that to a truncation strategy for Sucker Punch tests. Here’s an example of how to do it with DatabaseCleaner: https://gist.github.com/kitop/5248674. This happens because Sucker Punch workers always run the method in a separate thread, no matter if it is synchronous or asynchronous.

Persistence

Keep in mind that Sucker Punch runs your jobs on a separate thread, and not polling from an outside queue. That means that, if your app goes down while processing a job, it will not notify nor store that error anywhere by default, and it won’t retry it either. If you need more control over this, you can write your own wrapper. Maybe you could get some inspiration from girl_friday, or use some other solution like resque, sidekiq, or delayed_job.

Rails

If you’re working with Rails, workers usually go in the app/workers directory. You should be careful with ActiveRecord objects and connections. Workers should receive a record id and not the full object. Preferably, workers should wrap database access related code in a ActiveRecord::Base.connection_pool.with_connection block so it does not exhaust connections in the pool.

class WelcomeEmailWorker
  include SuckerPunch::Worker
  def perform(user_id)
    ActiveRecord::Base.connection_pool.with_connection do
      user = User.find(user_id)
      UserMailer.welcome(user).deliver
    end
  end
end

Connections

You have to be careful not just with ActiveRecord connections, but also with any redis, memcache, or any other service that may limit connections. It’s important to also limit the number of workers based on those limits. You don’t want to have 20 workers, when there are 10 connections max!

Unicorn/Passenger

If you’re using Unicorn or Passenger as your web server, there’s one more step to ensure everything is set up well. That is to define the queues on blocks that run after the server. For unicorn (only needed if preload_app true is set):

# config/unicorn.rb
after_fork do |server, worker|
  SuckerPunch.config do
    queue name: :log_queue, worker: LogWorker, workers: 10
  end
end

For Passenger:

# config/initializers/sucker_punch.rb
if defined?(PhusionPassenger)
  PhusionPassenger.on_event(:starting_worker_process) do |forked|
    SuckerPunch.config do
      queue name: :log_queue, worker: LogWorker, workers: 10
    end
  end
end

Further Reading:

• Concurrency and Database Connections, Heroku Dev Center
• Celluloid’s Frequently Asked Questions
• Celluluid’s Thread safety notes

Today, I want to discuss a few of the techniques that I use to make swapping branches easier, specifically the git-stash command.

git-stash is a wonderful way to temporarily hide changes in a dirty working directory. This allows us to work on a feature branch and quickly swap to other branches without the bother of staging / commiting our changes first.

[Typical Stash Workflow]

If you are like most developers, then the extent of your experience with git-stash extends no further than the following two commands:

git stash

and

git stash pop

Often, this is enough for what we need, but git-stash has so much more to offer. Let’s explore some of its myriad abilities.

Saving With a Description

The simplistic approach to stashing is git stash and is analogous (mostly) to git stash save. The latter takes several arguments, most important of which is a description. If you are going to use stash as part of your normal workflow you must use these descriptions to keep better control of each stash. Let’s see how that’d work:

touch gum_drop_mountains.rb   # New feature
git add .                     # git-stash only works on tracked files
                              # unless you pass the --include-untracked flag
                              # to stash save
git stash save "Initial pass on Gum Drop Mountains."
git stash list
stash@{0}: On master: Initial pass on Gum Drop Mountains.

Now when we view the current stash list we see meaningful messages instead of the default description WIP on <branch> <last commit message>.

Stashing In Patches

Sometimes you want to stash a specific subset of changes, for this we can use the --patch (-p) flag. This allows us to interactively specify which changes will be included in this stash.

# edit gum_drop_mountain.rb
git stash save -p "Added GDM tests"

Which will drop you into a prompt like below:

Once you’ve begun the interactive process, you can press ? to see a list of available commands. Upon completion you’ll be able to see your new stash with git stash list. The changes that are left uncommitted (to the stash) will still be in your current directory.

Listing Stashes

The most common way to view your current stashed changes is to type git stash list as we touched on earlier. This will print:

# Unless you are cool and passed a description
stash@{0}: WIP on submit: 6ebd0e2... Initial Commit.
stash@{1}: On master: 9cc0589... Add git-stash

Here, the stashes are specified as stash@{<revision>}. Many of the git-stash commands allow this stash identifier to be explicitly set, making it an important piece of information. git stash list takes any of the options accessible to git log which allows for some customization.

git stash list --pretty=format:'%Cblue%h %Cred* %C(yellow)%s'

Which will output something like:

You can alias git-log with the above formatting, which is common. Doing so with the git stash list is a prime candidate for this style of optimization, as being able to quickly decipher these descriptions can save you time.

Showing Individual Stashes

Showing stashes can be done with the git stash show command. It accepts an argument for the stash identifier and defaults to stash@{0} (most recent). It will display the diffstat by default.

Applying Stashes

Let’s assume we’ve been working for few hours. During this time we’ve been pulled off several times to work on other branches in the project. As we were pulled away, we’ve stashed our dirty working directories and given them all nice messages so we can cobble it all together later. Now that the bugs are fixed, we get to go back to our features. Our stash list looks like this:

git stash list
stash@{0}: On gum_drop_mountain: Touching up gum drop mountain peaks.
stash@{1}: On candy_cane_lane: Adding some tinsel to candy cane lane
stash@{2}: On master: First pass on gum drop mountains.

We want to go back to the candy_cane_lane feature branch and apply our stashed changes there. To do so, we are going to use the git stash apply command.

git checkout candy_cane_lane
git stash apply stash@{1}    # Specified stash or most recent (stash@{0})

Once we’ve done that, our changes are back in their proper place and we can resume work.

Git is smart here, in that you can apply these changes to branches other than the branch from which they were stashed. Furthermore, the branch you apply the changes to doesn’t have to be a clean directory! Git will throw a merge conflict to be manually resolved if the stash no longer applies cleanly[1].

Removing Stashes

Just for funzies, let’s check the stash list before moving on.

git stash list
stash@{0}: On gum_drop_mountain: Touching up gum drop mountain peaks.
stash@{1}: On candy_cane_lane: Adding some tinsel to candy cane lane
stash@{2}: On master: First pass on gum drop mountains.

What? Our stash is still present in our list even after applying it. That’s because apply doesn’t automatically clean up after itself, we have to use the following command to remove the stash

git stash drop stash@{1}

Which will drop just the stash we applied. Had we not given it a stash identfier it would have assumed we meant to drop stash@{0} (most recent). If we want to be rid of all stashed changes we can run git stash clear. Beware of clearing stashes (with either drop or clear) as they are impossible to recover.

The Oh-So Convenient Pop

After applying a stash of changes to a branch, it is quite frequently a good idea to remove that stash from the list (like above). Luckily, Git provides us with a convenient method that wraps this workflow. Assume we want to apply stash@{1} and remove it from the stash list. We can run the following command:

git stash pop stash@{1}

If we provide no stash identifier, it would assume most recent (like most git-stash commands). The git-stash man page provides a good way of thinking about this command. That it does the inverse of git stash save.

Branching a Stash

Sometimes you’ll find yourself in a situation where you’ve begun changes on the wrong branch (master for example) and want to take your current dirty directory to its own branch. Well you are in luck! Normally you’d have to do something like this:

git stash
git checkout -b new_feature
git stash pop

But git-stash has a convenience method to do just this. Simply:

git stash
git stash branch new_feature

This will create and checkout a new branch new_feature and apply stash@{0} to it.

To Stash or Not To Stash

Determining when to stash versus when to commit and squash later is a matter of taste. As long as you write descriptive messages about the stash and be sure to keep your stash list clean, then stashing is a great way to quickly get to a clean directory. If, on the other hand, you don’t take care, you’ll find yourself painfully wasting time figuring out which stash is which.

Warnings aside, stashing is a powerful ability that Git provides and with a little practice it can help you navigate your code more quickly and safely. Happy hacking!

Resources

1. Pro Git (stashing)
2. git ready
3. git-stash man page

David Brady – Learning and Laughing

Every week a group of Ruby Enthusiasts get together in a Virtual Roundtable and explore/discuss/argue some a
spect of the Ruby language or the Ruby community. They allow the rest of us to listen in on their discussion by way of The Ruby Rogues podcast. The podcast can be accessed on iTunes or on the website and offers a ‘fly on the wall’ view of a great bunch of technology savvy people sharing their ideas and opinions.

In this series of articles I will share the results of my interviews with each member of this special group.

Beginning with “The Basics”

Thom: Like any interview, in a podcast or in writing, the first question of course is; “David, please tell us about yourself.”"

David: No, next question.

Thom: Okay. That was a short interview!!

David: No, I’m kidding…

I am kind of an old-school programmer, kind of self-taught. I grew up in rural Utah. When I was in middle school they had some old Apple II computers — well, at the time they were rather new — and they say when you first fall in love with computers, your emotional growth is stunted at that point. So I was 11 and that’s my emotional age to this day because I just absolutely fell in love with computers. I’ve been tinkering and hacking the entire time since.

I took kind of a weird route through programming. I started in Apple Basic and then I moved to IBM and DOS and so I went into BasicA and GW-Basic and I moved up through the ‘Basics’, moved to Quick Basic – well QBasic – Visual Basic, then I sort of went down the rabbit hole. I went into C++ and then into C and then into Assembler.

At that point I was writing graphics drivers and writing video games and just really, really enjoying it and then somebody said, “You know, does it really have to hurt this much to be efficient? And do you really need to be that efficient?” So I said, “I don’t know, tell me more about what you mean.” He said, “Well, there’s this language called Perl and it’s this very high-level language, much higher than even Basic.” I absolutely fell in love with how much you could get done — yeah, you gave up a ton of efficiency, but for 90% of the things you do, you don’t need super efficiency.

Also, Perl is write only [as a language], it’s very terse and everything is implicit, they value implicitness, don’t waste time telling me things that I already know.

A few years later Python came along and I’m like, “Oh my gosh, it’s like Perl, only clear.”
Python has one right way to do it and every other way is wrong and that started to stick in my craw a little bit. Then I came across Ruby. Ruby’s attitude, of course, is there’s probably one right way to do this, but this general class of problem has nine different types of solutions. Unlike Perl where you should try to use all of them for every situation, Ruby says you should use the best one for each given situation. I think a lot of Python people would say that, too, so I don’t want to kick Python’s tires too much, it’s not a bad language.

But I finally found my way into Ruby and I’ve just absolutely loved it. It’s a language that lets me do what I want the way I want and communicate to others in the way that I like.

So that’s more of a programming language history of me. Does that answer the question?

Thom: That’s perfect, because my next question was how did you discover Ruby? You just answered it for me.

David: Perfect.

Thom: This interview is remote control.

David: Perfect.

Neighbors – Friends – Fellow Rogues

Thom: So how did you discover the Ruby Rogues? Did I get an impression that you and Charles Max Wood were friends and had worked together?

David: Honestly, “Location, Location, Location”, just like in real estate. I lived a mile and a half away from Chuck and I was actually at URUG, the Utah Ruby Users Group, back when there was only one Utah Ruby group [now there’s like five]. I was at URUG the first time Chuck came out to a Ruby meet. We made friends, we found out that we were living — did I say a mile away? More like 500 yards! I mean, literally, he was down my street, hang a left and go down a half a block.

Thom: So like if you have a loud party, he’ll know it.

David: Yes, exactly. Well, he moved, but it’s a small town, so now he’s two miles away and so we still know where to find each other.

Yeah, he got talking with James Edward Gray about starting up a panel-based podcast and just kind of out of the blue he’s like, “I think it would be funny to have you on the show,” and I said, “Okay, I will do my best to come and be funny.” I thought I had an opportunity as well to help people, not just be funny, but also to see things in a different way and that’s what I like doing, is getting into a conversation with people and then finding some angle that they haven’t viewed something from, and saying, “Well, have you looked at it this way?” Then there’s that moment when everybody around suddenly goes, “Oh, Wow!” and they make these mental connections that weren’t there before. That’s my favorite thing in the world to do ever.

I’d like to think that’s why Chuck invited me to be on the show, but the reality is, it’s probably just because I was in the room when he was thinking about it.

Thom: I think you don’t give yourself enough credit, but that is funny, the self-deprecating humor seems to be common in the tech world.

David: Yeah.

Thom: Is there something that you’re working on or some project, is there a soapbox you want to get on?

David: No, and I regret that. What I will say is that I have something in the works. I’m not ready to announce yet. I am getting into more of a training and mentoring aspect and so if anybody would like to do that, that’s the direction I’m going with what I’ve got in the works. But that’s not the main business model, so it’s not even a “You can pay me to train you” thing, it’s just a “Hey, if you want to pair just get a hold of me.”

Thom: Terrific. You know you’re going to get a lot of response from that. I may be at the top of that list.

David: Absolutely! I think we could, maybe, break something together.

David: One of the very first programming books I ever opened up said, “Don’t be afraid of the computer, you can’t hurt the computer by typing on it, unless you type with a hammer.” Yeah, I’ve burned up a disk drive by writing a program that was very disrespectful of the hardware timing. I don’t know how many things I’ve burned up or fried. They lied to me. They absolutely lied to me!

What is interesting; I actually never programmed in Fortran. I came in right behind it, but everybody that I looked up to and everybody that I mentored under had come out of Fortran. So for, oh gosh, 15 years, I was (in 1999) writing C++ code professionally as my career and I was rigidly formatting my code to 72 columns. I did not know why, and I got with an old-timer who saw that I was still doing that and he just died laughing. He’s said, “Do you know why you’re doing that?” I said, “No.” He said, “Because in Fortran you need to leave 8 characters for the address line on the punch card and you’ve only got 80 columns on the punch card, that’s why you’re doing that. You’ve got a 21-inch monitor,” (those were the biggest ones at the time) “stop formatting your code at 72 characters.” It’s like the old story of cutting off the pot roast because Grandma did it, but Grandma did it because it wouldn’t fit in her oven.

Thom: Yes, it wouldn’t fit in the pan she had, right.

David: Yes.

Thom: So you probably also then – the habit I can’t break – put the constant first in a comparison?

David: Actually, no, that came after my time. I came from Basic and then into C++, you can do

if X = 42

Right? And oops, you just assigned X the value 42.

Thom: Exactly. Instead of comparing, you just assigned it.

David: But I had gone through the phase where I was writing loops like while *p++ = *d++ which is a de-reference copy and re-reference and then increment both pointers inside the If test.

Thom: Right.

David: And if you look at the source code for strcpy in the old C-reference, that kind of monkey business was not only allowed but almost praised.

So when Microsoft introduced the coding style of swapping the constant and the variable, it was just wrong. Constant == variable, it just never caught on and I still don’t do it to this day. I tried, I don’t like to throw away an idea without tasting it first and I spent a year where I rigidly did — I think they call LHC style, Left Hand Constant style — and no. It just read wrong to me.

David: Ruby does the same thing because you can do

if fp = file.open(...)

Then you’ve got an fp variable in the next line.

Thom: When I work in VBScript, it just (shudder)…

David: Just between you and me and — You know, I was going to say this is not for print, but you can go ahead and print this. I fed my family for a year writing VBA and VB script and so I don’t tell people that I do it, because if you want to hire me for that skill, I don’t want to work for you.

Thom: I agree. In job interviews, when asked if I do VB or VB scripting, I always say, “Yes, but I wash my hands afterwards.”

David: Yes. Yes, exactly. So anyway, I just wanted to mention that as a yes, it’s a mark of shame, but I stand with you in solidarity, brother.

Revealing a new Perspective

Thom: What do you see your role in the Ruby Rogues?

David: Obviously I have a pretty good sense of humor and I like to inject that where appropriate and then a little bit more, as much as I can get away with without annoying people too much.

Like I mentioned earlier, trying to make people think and see things from different ways is a very big goal. But the open secret that I have when I’m on the show is I love it when I’m on a show with two people that have wildly differing approaches to something. That one is like, “Don’t ever test,” and the other one is, “Over test everything.” When I can look at two people and say, “You know, you guys are in disagreement on 98% here, let me throw one-third thought in here that you guys haven’t mentioned,” and then both of them go, “Oh, my gosh, you’re right.” I absolutely love that.

I love the MINASWAN — that stands for Matz Is Nice And So We Are Nice. I really like honoring that in the community and when we have somebody on the show that has a really strong opinion about something, I love being able to temper that in such a way that we can have people with strong opinions that suddenly find themselves working together with their strong opinions, rather than opposing each other.

I think that’s kind of why my favorite episodes I’ve ever been on are the ones that have been on like diversity and drama in the Ruby community and interpersonal relationships. Those are my favorite episodes to be on because they’re such juicy topics for people to be wound up about and yet care deeply. When you can get two people and tap into their caring deeply, you can suddenly make them going from disagreeing violently to agreeing; maybe still violently.

But that’s really what my favorite thing to do on the show is. I just use the humor to distract from that.

Thom: Thanks David

David: My pleasure.

You can find David Brady in the usual places:

• Github
• Ruby Rogues