The Rogues honor fellow Rubyist Jim Weirich in a tribute episode.

 

I tell you what, I’ve spent the last couple of days reading Jim Weirich code and oh my gosh. What a great way to spend time.

Jealous?

It’s awesome, really.

Has Anybody Seen My Code: Nice and small, works for all. Ruby is my all in all. Has anybody seen my code? Clean syntax, runs on Macs. Ruby has what others lack. Has anybody seen my code? Now when I worked in Java, I worked hard every day. EJBs, Entities, Spring DI got in my way. But now I know that for sure, Ruby is my Java cure. Has anybody seen my code? Now I know that for sure, Ruby is my Java cure. Has anybody seen my, anybody seen my, anybody seen my code?]

Hey everybody and welcome to episode 151 of the Ruby Rogues Podcast. This week on our panel, we have Avdi Grimm.

Hello, hello.

James Edward Gray.

Good morning, everyone.

Josh Susser.

Hey, good morning from San Francisco.

I’m Charles Max Wood from DevChat.TV. And this week, we’re going to be talking about our friend and hero, Jim Weirich. And just to start it off, I want to do a quick introduction. Actually, we all wanted to do this, just give you a thumbnail look into who he was. Jim was born November 18th, 1956 and he died February 19th, 2014. And when he died, we discussed it and we all wanted to talk about who he was and what he meant to us. So, Jim was the chief scientist at what started out as EdgeCase. And I know he was there pretty early. I’m not sure if he was a founder or not. And then it got purchased and changed names a couple of times. And it’s now Neo Innovation. He gave us a bunch of tools that we use. He built Rake, which is something that is used widely across the community. He also built Builder, which is a tool for building XML. I know he contributed to RubyGems. He gave us some other things like Rspec-Given, Ruby Koans. And so, overall he just really was the heart of the American Ruby community. And everybody who attended conferences that he was at has stories about him. And as you got to know him or work with him or sit with him, you just really realized what a tremendous person he was and what a difference he made to everybody that came in contact with him. So, we’re just going to talk about his contributions to the community and his contributions to us and things like that. I do want to point out two things. And one is that Neo has put together a scholarship in Jim’s memory to help people learn code. And we’ll put a link to that in the show notes. And also, his family in lieu of flowers, (that’s something that we do in the US, usually people give money for flowers and things at a funeral) his family asked for people to donate to the American Heart Association. And so, we’ll put a link to that as well so that if you want to in his name, make that donation, you can. Did I miss anything, guys?

[Chuckles] You missed a whole lot, but we have an hour to talk about it.

Yeah.

That was a good start. Thanks, Chuck. Jim left us a heck of a lot. He left a big imprint on the Ruby community. He was there from the very start in Ruby, in western world.

I remember him always being there on ruby-talk and the mailing list and having things to say.

Yeah.

Yeah, that was an amazing time. When I first came into Ruby at the height of ruby-talks value where you would regularly ask questions and get answers from people like Dave Thomas, DHH, and of course Jim Weirich who was just tireless in answering questions, helping people. It was amazing.

What are some of your first experiences with Jim?

I think it was at a Werewolf game.

That’s awesome. You’ve got to explain this custom, since it’s fallen out of favor.

Yeah, that was an early… that was before my time in the Ruby community, actually. It’s a fun game, but yeah.

Yeah. I don’t want to do the whole Werewolf story thing, because that’s a big story.

It’s a game that people played at a conference.

Yeah. It’s like a salon party game. And I had run into Jim a little bit at the conference. And then we ended up in a Werewolf game together. And wow, he’s brutal. [Laughter]

That man was good at everything. [Chuckles]

Exactly.

So, that’s how I met him. Who else?

I think I told my story in a previous episode. It was the one that we found out that morning that he had passed away and where I attended MountainWest Ruby Conference and I was very new. And I asked him questions about mocking and stubbing and he just answered my questions. I had no idea who he was at the time, and then found out later that he was the guy that David Brady was talking about when he said that he would pay money to hear Jim Weirich talk about oatmeal. [Laughter]

But there are a ton of experiences that I’ve had since then where I’d just sit down and ask him what he’s working on. And we’d sit there for two hours and skip sessions at a conference while he explained to me what he was doing and why he cared. He was such a terrific mentor to anybody who would listen to him.

Yeah.

And many who didn’t. [Laughter]

Yeah.

My earliest interactions with him were definitely trading emails on ruby-talk. But then, just conferences as I began to go to the conferences, he was such a fixture. The first time I would run into him in the hall of the conference, that’s how I knew I was at a Ruby event. I’m very sad that…

And you heard his laugh first. That’s what everybody says.

Yes. Yeah, you could hear it forever, right?

It was his big Santa Clause laugh.

What was your first interaction, Avdi?

I don’t know. We probably, there were probably some emails on ruby-talk or something like that. One early recollection I have is that kind of out of the blue, because I never really interacted directly with him, I emailed him asking for any thoughts that he had on exceptions when I was getting ready, getting my ‘Exceptional Ruby’ talk together. And everybody talks about how generous he was with his time and it’s so true. He got my email and he sent back this long email with all kinds of really interesting thoughts about exceptions. And he taught me a lot in that email. And there’s stuff that I definitely put in, as a result, put into the ‘Exceptional Ruby’ talk and book because of that. And oh, I was recently reminded too that he was the one to introduce me to Sandi Metz. So, I have him to thank for that as well.

Oh.

Awesome. Well, while we’re doing this, are there any other stories that really illustrate what Jim was about to you that you want to tell?

So yeah, Jim had, that was one of Jim’s things, his shtick, was that he had a story for everything. And it was great. They were great stories. I can remember tons of them. He used to tell this story about how he created Rake all the time and it’s a great story. I know last week on the show, we were talking about a million and one failures, and I used Twitter as an example then because it was what popped into my head. And then afterwards, after we did the show I thought, “Oh that was so dumb. Jim has the best million and one story and I can remember that one too.” He had these stories for everything. It was a part of his thing. It’s neat.

I don’t know if I know the Rake story. Do you want to share it real quick?

Sure. So, they were just fiddling around, him and a colleague. I’m sorry. I don’t remember who it was. But they were fiddling around with make and trying to get the syntax right, as I’m sure anybody who’s spent ten minutes with make has had that problem. And Jim made some comment, or his colleague did, about, “Wouldn’t it be great if this was in Ruby syntax and it wasn’t so complicated?” or whatever. And they were both like, “Yeah, what would that look like?” and whatever. So, they did whatever they needed to do and they went back to their separate work stations. And Jim, just being the fiddly kind of person that he was, sat down and was like, “Well, you’d have this task thing. And it would take a block,” and he fiddled with it for a few seconds and then he went back to the person he was working with. He’s like, “Well, what if it looked like this? This is how you define a task.” “Yeah, that would be so much better. But then you would have the dependencies. It would be a lot of work to recreate make in Ruby and do all these things.” And Jim was like, “Yeah, yeah. That’d be a lot of work. And it would be hard figuring out all the tasks you need to run and stuff.” And so, they did whatever they needed to do, went back to their own work stations, and again Jim being Jim said things like, “Alright. Well, how would you do it?” And he just starts building. And they did that that day and wrote the core of what would eventually become Rake. It’s great. Thinking in code is how I think about it.

Well, that is so Jim. Some of the things that we have from him are his, “Well, what ifs?” like RspecGiven. It was, “Well, I’m just going to experiment with this and see if I can make RSpec have the given-when-then that Cucumber has.” Or Ruby Koans, what if we had a learning system or a set of exercises written with tests? And then we wind up with this cool way of learning Ruby. It seems like a lot of the things that he did were really that way, where it was an experiment that just turned into something really useful.

Yes. That was definitely his style.

Yeah. He was a prolific contributor. He was just always working or playing on something. What’s the list of all the stuff? I would venture to say that anyone who does any Ruby programming is always using Jim’s code every day.

Yeah.

So, there’s Rake, there’s Builder. What else? Avdi and Jim, you really like rattling these things off before.

Rake is the biggest one. Builder definitely gets used in some things.

RubyGems, he contributed to.

He did, definitely he did some of the, a lot of the early work in RubyGems as far as I know. So, that’s a big one. I want to say that even if not as many people use FlexMock anymore, I want to say that the RSpec mocks were actually originally based on FlexMock.

I think a lot of the mocking libraries took their inspiration from FlexMock. And even in recent years, after Jim was playing with Rspec-Given, he realized that traditional mocking didn’t really fit that model well. And he was all, “Well, what we need is spies.” And he went back and added spies to FlexMock so that he could play with them in that environment. And then all the other mocking frameworks again copied FlexMock and introduced spies.

I think he also innovated with any instance in FlexMock.

Oh maybe. I don’t know.

Yeah, being able to… I was just looking through my emails a few minutes ago and found an email from him in 2007 to the Rails Studio email list talking about using FlexMock for any instance. So yeah, he was always innovating on that kind of stuff and always pushing the envelope. And I think you’re right. A lot of it was just his way of thinking through problems and exploring ideas.

Did we mention BlankSlate already?

No, we haven’t. But we should definitely do that. You want to say what it is?

Well, so I think it was in Builder that he ran across the need for a stripped down object base class that had practically no methods on it. And we know that now as BasicObject. But back in the Ruby 1.8 and before days, there was no such thing. You just had object and it already had a whole bunch of methods on it. And so, he figured out the code to strip off all of the unnecessary methods from something and create something called a BlankSlate object. And that later found its way into Ruby in the form of BasicObject.

That code. I just put links in the show notes to it. This is definitely an episode, by the way if you haven’t figured it out yet, you’re going to have to click around on some of the links we’ve showed and look, because this is an amazing legacy. And you should look through some of this stuff. The code’s really expressive and you can learn a lot. But the original BlankSlate is really neat. It’s like Avdi said, he strips out all these methods. But then, Ruby is so dynamic that depending on the load order of the files, he may have stripped out methods but then if you load something like Rails, it’s going to throw a whole boatload of them back in, in the base stuff, and bulk up your BlankSlate again. So, Jim had to define all these hooks and watch as methods were added or modules were included and stuff, and go find those methods and knock them back out of BlankSlate. And it was really neat. He has this code, you do it, it’s pretty readable. You can figure it out. I’ve put a link that takes you right to the class. And then if you look, there’s another file in Builder that in more current versions basically says if BasicObject exists, BlankSlate = BasicObject. And that’s that Jim’s code had such an impact that that feature was adopted into Ruby itself and became like BasicObject.

Nowadays, that’s how we do it.

I think some of the ideas from his talks too, inspire different things. And between the episode that we did on this show where he talked about objects in Rails and then Avdi’s book, I think both of those really influenced the way that people think about Rails. And I’m also reasonably sure that he contributed quite a bit to Rails as well.

Well, Builder is Rails’ default mechanism for rendering XML. So, that’s been included in Rails as long as I can remember. I think since the beginning. So, he definitely contributed that, as far as everything else. This is kind of sad, but he did have this quest, sort of. He was never very happy with the structure of how Rails did things, I think, and wanted to bring more objects to it and contributed with that. And there are multiple repos on GitHub where he’s trying to figure out different approaches to structuring Rails apps. And he never really got anything that stuck there. But he kept having ideas on that. He had another repo very late in his life that just says “Coming soon” and it’s another one of those ideas of trying to structure Rails. I think that was the nut he never really cracked.

You know, before we move away from Builder, I think it’s worth noting that I think that Builder really had an influence just in its style, because I think it was one of the first, if not the first library to explore just the idea of a DSL for building things in Ruby, the idea that you could translate the language of the thing that you were building, in this case XML tags, into Ruby methods by using method_missing or something like that. The method would correspond to the tag being generated. So, you could say body do and then inside that block you could say h1 do or p do to put in h1 tags or p tags. And I don’t know if I recall anything before then that had that style to it. And there have been dozens and dozens of libraries since then that used that approach.

I think that that was probably new in the Ruby world. I’d seen things like that before in Smalltalk and other languages.

He actually based it off of, I can’t remember where he saw it in particular, but he did base it off of builders or a concept in another language that he really liked. So, he ported the library to Ruby, basically, to bring that feature to us.

Right. But he was still innovating around that. I remember when Builder was going back and forth between the implicit instance_eval and not.

Yeah, that’s right.

And to explain that for our listeners, in a code block and you’re doing… so, you can either pass in an argument to the block and send all your messages to that, so if you’re in Builder you can pass in an XML and do XML.whatever, or you can do an instance_eval on the block and that evaluates the code in the block in the context of the object that you pass in. So, all the message sends can be implicit. So, instead of doing XML.foo, you just say foo. And Jim went back and forth on that and ran into the issues on both sides of that fence. And I liked that he settled on the explicit messaging rather than the implicit instance_eval.

Right.

Yeah. The thing is that usually when you’re generating XML, you’re pulling the content from somewhere else. And so, you have this object or this context that you’re in and you need to get to those methods because they’re the data. So then, when he would use instance_eval, he would change self out from underneath you and you couldn’t get to your data easily anymore. [Chuckles]

Right.

So, he decided to keep that explicit to keep the separation obvious. There’s another cool trick in Builder that I just don’t see very much. And I noticed it when I was going back through the code recently. He had to handle encodings as Ruby grew up, because in Ruby 1.8 and lower encodings were a very small, simple thing. And then in 1.9, we got full multilingualization. So, he had to handle that when he was escaping content. And there’s this spot in Builder where he just has a conditional while he’s defining the class. So, if encoding exists, if multilingualization is there, then he defines an escape method that’s encoding aware. And if it doesn’t exist, then he falls back on this very simple approach that works with Ruby’s earlier system. And I don’t see that a lot. So, when the class is defined, you only have the one method, but it’s the right one for that execution.

It’s a neat trick. I’ll put a link in the show notes.

One of the things that strike me when I’m reading his code is it’s the code of somebody who has absorbed a whole lot of object-oriented principles in a very organic way. So, you see a lot of great patterns that are used. But they’re used in a really no-fuss way. There’s not a lot of boiler plate around them. There’s not a lot of fanfare. I was just looking at a piece of code in Rake that checks to see, that checks for the modification time of a file. And it’s possible that a non-existent file might be passed into the method. And a lot of code might have returned either the modification time if the file existed or nil if the file didn’t exist. But what Jim has is he has the method, in the case where the file doesn’t exist he has it returning a special case early object. And early is basically a singleton of a little tiny special class that he wrote, which is just designed to basically sort as older than any other possible timestamp. And so, it will always appear to be out of date. And as a result, you can use the return value of that method without worrying about the possibility of it returning a nil.

Yeah. That’s a nice trick. And yeah, I looked at the code when you showed that to me this morning. And I think that’s a great example of how doing that kind of “trick” in your code isn’t very much code at all. And I think a lot of people who don’t have a whole quiver full of those arrows, they have to think a lot about that stuff. Jim just shows us how easy it is. He knew all that stuff and he would just whip it out as he was cranking out code and just made it all look easy. That was the thing about Jim that always impressed me the most, was that no matter what he was doing, he made it look easy.

[Chuckles] Yeah.

There’s another good special case example in Rspec-Given. And it’s one of the really neat ones. It’s one of my favorite programming tricks that I figured out by reading Jim’s code. And the case is such that, so in Rspec-Given you write things like given-then-when, or given-when-then, sorry, blocks, given this, then this, when that, et cetera. And one of the interesting problems he ran into is say you have some code that raises an exception. Well obviously, the exception has to be caught because he doesn’t want it to crash like it does [inaudible] or anything. And it also has to be caught because you need to be able to say something after the fact, like then it should have raised an exception, or it should have failed. So, you can’t let it fail or you’d never get to the “It should have failed” part. But then, if they didn’t do that, say the exception really was a mistake, and they had a normal test, then you want the exception to actually happen and fire. And if you raise the exception then, if you capture the original and then you raise it later, all the line numbers and everything, the context of the exception, will be wrong. And so, there’s this bit of code in Rspec-Given that’s really neat. He has a failure object and it can run code in a context and catch any exception that comes with it. And it returns it wrapped in this failure object, the exception itself. And then you can check for that, the matchers that check for have failed, they say, “Is it an Rspec-Given failure?” basically. But the cool thing is this exception object is wired up like BlankSlate where everything in it just reraises the original exception. So, if you try to do anything with it, if you thought it was a number and then you try to add it to something, that’s going to call the plus method. And that wasn’t counted on, so that it’s going raise the original exception because it saved it. The context is still correct and points back to the right line numbers in your code and stuff. And he’s basically moving exceptions around in the system but then triggering them when it makes sense to do so. And it’s a neat bit of code.

You know, Rspec-Given as a whole is a pretty neat piece of code. I’ve been using it. I don’t know if anybody else uses it. But I’ve been using it in some of my projects as the main spec tool. And I really like it. And it does some amazingly cool stuff, the way it breaks down failures. It’s hard to describe. You have to see it. But the way it breaks down failures, taking the individual objects apart to see what the actual values were versus the expected values, is pretty neat.

It is a neat framework. I didn’t really appreciate it until I went to Scottish Ruby Conf. We’ve talked a little about how Jim has these talks. I’ll go and throw a link to this one. But he did a whole talk on Rspec-Given and that was where I first saw the exception passing trick. And then I had to look into the code to see how it was done. But he also talks about several other things in that talk, including he has a mini-rant on RSpec’s includes matcher where you can say spec to include.

That’s always bugged me a little bit, too.

Oh, man. That matcher is… he just tore it apart. He showed, I think he showed 11 different ways to make it pass that were something else. He’s like, “I don’t know what this specified. It seems to accept everything.” [Laughter]

Oh, wow.

It was great. It was super great.

Oh, geez. Okay. So, Jim had a lot of style and he had a lot of influence on coding style in the Ruby world. I think that there are one or two things that, we even use his name talking about it, so there’s the Weirich style of block delimiters.

Yes.

The Rails style, the Rails core style of doing block delimiters is if it’s a multiline block, you use do and end. And if it’s a single line, if the whole block fits on one line, you just put it in curly braces.

And if Jim were here, he’d tell you that was wrong.

Yeah, and what would he say?

Well, he would tell you it’s not the style that he uses. [Laughter]

True. He’d say, “That’s not a very interesting style.” [Laughter]

The reason that one’s not interesting is it gives you information you already have. You can see at immediate glance if the block takes up one line or if it takes up many.

Yeah, we talked a lot about code malleability… go ahead.

Let’s get to the punchline of his style, which is that Jim said use do end if you’re using the block…

Side effects.

Without caring about the return value. You’re just doing side effects. If you are using the return value, use curly braces, because then putting a dot and then the next message, chaining that in the end of the curly brace, is much more readable than chaining it off the end, was his signal. And you were saying, Avdi?

Well, I was just saying we’ve talked a little bit about code malleability on the show. And to me, there are a lot of good things about this style. But one of them is the issue of malleability where you don’t want changes to force other noise changes. So, the way I look at it, if you’re changing your curly braces to do end just because the block got bigger…

Right.

If you look at the diff, the part of the diff that’s showing the change from curly braces to do end, that’s just noise. It’s distracting from the important thing, which is that the block got bigger. And it’s very common for blocks to get bigger and smaller, to go from one line to multiline. It is much, much less common for a block to go from a functional block to a side effect block or vice versa.

Right, because the name of the iterator typically implies whether or not you care about the return value.

Right. If it’s an each, you’re going to care only about the side effects. If it’s a map, you’re going to care only about, typically you’re going to care only about the return value.

Yeah. I agree. I think that’s why that style rang so true. Avdi, you did an episode recently on one of Jim’s other style tricks that I really love. You want to tell us about that one?

Sure, yeah. And this is one of the things he sent me in that email years ago, when I asked him about his insight into exceptions. And what he showed me was that convention for how he uses the fail and raise keywords in Ruby. A lot of people now might not even realize that there are two ways to raise an exception in Ruby, that you can use either raise or fail. They’re both methods on kernel. They both do the exact same thing. They’re basically just aliases for the same thing. And I think style these days has gone toward just using raise for everything. But what Jim showed me was that he uses the two different methods for two different things. So, most of the time, he uses fail. If he wants to indicate that there was a failure of any kind, he uses fail to signal the exception. But then in the rarer case where he rescues and exception and then decides to re-raise it, that’s where he uses raise. So, he uses raise strictly to signal an exception that’s being re-raised after being rescued. And I really like that style. Again, it’s a way of using Ruby’s multiple ways of doing things in a way that gives a signal to the reader. It’s a cue to the reader that says, “Hey, pay attention here.”

Yeah, that’s actually I think a really subtle thing that is worth focusing on a little, is that Ruby gives you a lot of different options for how to do things. And you can just settle on one thing. Say okay, I’m always going to use collect instead of map. You could be Josh Susser and just say, “I’m always using collect instead of map.”

[Chuckles] And it’s worth pointing out that back in the old days, some people settled on only using one kind of block, only using curly braces for instance.

Right, right. But Jim’s approach was, okay, the language gives us a couple of different ways of doing the same thing. And that’s more information that I can put in my code. And then when I or someone else is reading my code, they now have extra signals to tell them what’s going on and what the programmer’s intent was.

It also tells you another very important thing about the way Jim programmed, is that he cared about how the code came out, how it looked and how easy it was to understand and share, and stuff like that. That was always in his mind.

And you know, I’m pretty sure that that was because Jim actually cared about the people who would be reading his code.

For sure.

He had a lot of compassion. Any other style stuff? We got blocks. We got fail versus raise.

I’m kind of curious. These are all things that he actually talked about that he liked to do. But I’m wondering, I haven’t read a lot of his code. I know you guys have read more of it than I have. But are there things in his code that you’ve noticed that are more stylistic than, say the patterns that you mentioned before?

Oh hey, yeah a lot of his code looks much more like Perl than what most Rubyists are used to.

That’s interesting. Why do you say that? Because he uses…

Well, so Avdi you were pointing out an example in FlexMock I think where using the ‘or’ form of or…

Yeah, actually I was just going to bring that up.

Yeah.

It’s basically a cascade of try this, then try this, then try this. And a lot of people might use an ifelse with a bunch of clauses. But it actually looks quite nice the way he made it. I can practically read it to you. It’s lookup task name and scope, or enhance with matching rule given task name, or synthesize file task given task name, or fail don’t know how to build task. And so, there’s an example of fail as well. And it reads really nicely at the end of this cascade of try this, then try this, then try this. This is in the Rake source code, by the way.

It’s so natural. It literally reads like it is. Do this, or if you couldn’t do that, do this, or if you couldn’t

do that, do this.

And it’s very much a Perlism as well.

Yeah.

Right.

If you rewrite it, it’s a fun exercise, rewrite it with ifs, it’s a lot uglier. [Chuckles]

Right. Yeah, so Jim wasn’t afraid to experiment in his code styles and trying to find something that was more expressive. I don’t always agree with his choices, but I love that… Well, I agree with most of his choices, I will say. I don’t agree with all of it. But I do love that he’s always, it always looks like he’s trying to push things in that direction of readability and understandability. He took the time for that.

For sure.

One thing that’s related to that, and this is something that I saw a lot in his talks, (I’m changing the subject, sorry) but one thing I noticed in his talks was the things that people tended to want to throw out or avoid for whatever reason, sometimes cultural, and I’ll give an example here in a second, are the things that he liked to come back to challenge you on. So, the last talk I heard him give was at RubyConf last year. And he talked about UML.

Which is a very enterprise, waterfall thing in a lot of people’s minds. And so, he came back in and he said, “Look, this is a very powerful way of representing the entities and interactions in your code.” And he gave a full-on, I don’t remember if it was an hour-long talk, but he made a lot of terrific points and reset the way people thought about something that to their mind is very enterprise-y. And so, I just love that. I love the way that he pushed things that way as well in his talks and the ways that he would interact with you while explaining the way that he approaches his code.

Yeah. Jim really, I think in his attitude, taught me a lot about not being a reactionary, I guess, being very pragmatic and open-minded.

Yeah.

I could see that. Jim struck me as the kind of person who always looked for the best qualities in people. And it’s great, because when you look for those qualities, you usually find them. And Jim was great at that. [Chuckles] I always walked away from a conversation with Jim feeling like I was a better person. He could bring that out. And he was really thoughtful, too.

Yeah. And that really makes me think. It makes me want to be that kind of person.

Yeah.

Well, we all can.

[Chuckles] So, one other thing that comes to mind talking about this challenged the way some people think about things, I remember (and this was a few years ago) he spoke at one of the conferences I was at. And he gave a talk on being a polite programmer. And basically, it was here’s the way that you should be patching things that don’t belong to you.

Oh, this was the etiquette talk.

Yeah.

Okay, yeah. This is great.

And there were so many people out there that were writing gems and things. And some of them were doing the things that he talked about and some of them were literally opening a class and monkey-patching it because Ruby allows you to open the class and do that. And so, he walked through all of the etiquette of doing that and why you want to do things in a particular way so that people can go back through and figure out where things came from and why they’re doing the things that they are. And again, it was just… he never came across as, “I’m challenging the status quo,” but it really was a, “You really ought to think about it before you do these kinds of things,” and I see a lot of these things out there.

Yeah.

Yeah, I guess I’m bringing up some of my favorite talks. But it was really the way it was, and so it was a mentorship. And at the same time, it was, you need to change the way you think about some of this stuff.

Okay, so we’ve mentioned this many times. Jim is really well-known for all of the ridiculously great conference talks that he did, and teaching. He did a lot of… he worked with Rails Studio for a while, I think, with the Pragmatic Studio stuff, educating there. And he just was always an educator. He loved teaching people stuff because he loved learning new stuff. So he left… his Confreaks page is ridiculous, how many talks he gave.

Yeah, I just counted. I think it’s 34. There are some on there that are tributes. But yeah, it’s a big list of talks, 30 talks. And that’s not all of them, because the one I linked to earlier about the RspecGiven is not on Confreaks. So yeah, there’s a ton of talks.

And they are all just staggeringly good talks. I haven’t seen them all yet. All of the ones I’ve seen are amazing.

He was a great speaker. And he was really smart, he was a great educator, he had a good rapport with the audience. He was always having fun on stage and wanted to make sure that you were having fun too. I always looked up to him as a great role model for a presenter and wish what I can someday be as good as he is at the lectern.

Yeah.

One of my favorite stories there with Jim and speaking is actually the story that the Phusion guys told on their blog in their Jim Weirich tribute where they came and they were getting ready to give a talk. And they showed him their slides. And he actually helped them rewrite the talk and made it into a success. I’ll put a link in the show notes. But that’s just another example. He was very good at speaking, and again, very willing to help people out to make their talks and their things a success too. But he understood it very well and did such a terrific job.

So, he gave a talk a while back with the modest title ‘The Grand Unified Theory of Software Development’. [Laughter]

And if anybody else had given a talk with that name, I don’t think it would have lived up to the title. But this one, honest to gosh, lives up to the title. It’s where he introduced me to the concept of connascence, which is the generalized concept of things being connected to each other, and goes over all the different types of connascence. And basically, it lives up to the title, because it’s a great framework for just understanding all the different choices that we make in software and all the different patterns that we use. They all pretty much all boil down to controlling the amounts of connascence and the type of connascence that are in our programs, and just mind-blowing talk.

I saw that talk and it is very good. He had another talk on the SOLID principles. That was similar. And it seemed like connascence was, he was trying to take it a step back and figure out what were the building blocks that these things came from, is what I felt like.

Oh.

It was really good. They’re both great talks. And I will definitely put some links in there. It’s funny what you say about the Grand Unified Theory. When I ran Red Dirt, he came and we made him the opening keynote speaker. And we started early. I think he went at, it was 8:30 maybe in the morning. And he just launches right into physics at 8:30am.

It’s totally Jim Weirich. It was great.

[Chuckles] Very nice. I love that his talks, he always included a lot science. Well, not always, but very often he included a lot of science in them. And it was clear that he was very well-read on a wide range of topics. So, a lot of good talks, a lot of good conferences, he was on Ruby Rogues twice. He was one of our few repeat guests, episodes 20 and 60. And I love how the first one was object-oriented programming in Rails and the next was SOLID, the SOLID principles. So, he was a real master of object design.

Jim had a talk that I love and it fits in with Chuck talking about how he always challenged your ideas. I’m a super big debug with puts and p. I pretty much never launch debugger. And I’ve just always been that way. And Jim wrote a talk for people just like me one time. He was like, if you always debug with puts, you don’t know what a debugger is basically, and he took this example which is the Gilded Rose Kata. And so, Jim also introduced me to the Gilded Rose Kata through this talk, which is a really neat programming exercise. If you’ve never tried, you need to. It’s very mind-expanding and shows you what you can do with properly structured code. And he has examples of that, repos of that, and I do as well, that you could look at after you try your own solution. But in this example, he takes the original Gilded Rose code translated into Ruby. He translated it to Ruby. And he shows you how hard it is to use puts to figure out what’s going on in there. It’s very hard. And then he fires up a debugger and you can very easily tell what’s going on there in the debugger. So, if you have that same bias I do, you should really go watch this talk, because it’s very eye-opening.

Okay. So, we’ve talked about a lot of his talks and videos. That stuff’s all fun. What about the really fun stuff? What about the games?

Oh, I thought you were going to bring up quadcopters.

[Chuckles] Well, that too.

He is into quadcopters.

I sat and talked to him for two hours about quadcopters at RubyConf. And he’s showing me videos and the whole nine… it was really fun, just fun stuff, the quadcopters

What about the Katas and the Koans?

Oh, yeah.

Yeah. Yeah, I believe, I’m not sure, I’d have to look. I think he might have originally taken the idea for Ruby Koans from Metakoans, which was a Ruby quiz early on that Ara T. Howard ran, I believe. But anyways, Jim made Ruby Koans. And when you pull it down, it’s a way to learn Ruby. And it’s basically a Ruby program that you pull down and try to run. And just right of the bat it dies. But it gives you a really good message and tells you why it died and what you should go fix. And you go in there and fix that. And then you run it again. And what you realize is it’s basically a test suite. And all of these tests are failing for various reasons. And he’s hacked around it to give you these good error messages and stuff. And then you go through and you fix these tests. And as you go, you’re learning to understand what Ruby does. You’re correcting these things and making them answer correctly. And it’s teaching you bit of Ruby. And it has different modules so you can learn different things. I contributed to that as well. I put in some regular expression stuff because it skipped over those and I thought that would be fun. But it’s a neat way to learn Ruby, an interactive, teach-yourself-a-little-bit-of-Ruby bit. And they just, I think it was EdgeCase, just released that for free. And it’s really great.

Yeah, I love that approach. It really made me think when I ran across that, because it occurred to me that a lot of us have some of our first programing experiences not in a proper first principles way, but just in encountering a program that’s broken and we decide to try and fix it. And it’s a neat way of thinking about learning, is from the perspective of just fixing something little by little rather than from the perspective of let’s build up from first principles.

Some of his talks just have incredibly fun bits in them, too. I don’t remember which talk this particular bit is, but I mentioned earlier his one in a million failure story and I’ll give you just the basics. But Jim worked in, boy, I think about every industry over the course of his career. And at one point, he wrote code that ran on jet engines, rocket engines. And they had to do something with parallel shared state, typical scenario. And the synchronizing in order to do this was killing them with the speed that it would take to require the lock and stuff. So, Jim sat down and he worked out a way that he could do it with a lockless data structure. And he said, “You know, the downside is it’s going to fail,” and I can’t remember what the exact number of times is, but it was something like one in a million. It will be right this often, but there’s this horrible edge case. It will kick in every so often. It would be wrong. And they decided that was within the error bars. That was good enough. And it reduced tons of overhead. And so, they implemented this. And then they would leave these engines testing in these, I guess tunnels, where they would test things. And it turned out that after they switched over to this new code, every two and a half days or something, the engine would randomly die. [Chuckles] And typical Jim, here they have this horrible showstopping bug. And typical Jim, he sits down and does the math. So, okay, It’s doing this many revolutions. It’s going to be going through this code every so often. If we take so often and multiply it by two and a half days and figure it all out, and he’s all, “I was right!” The failure rate is exactly what I said it would be. [Chuckles] And that was his lockless structure when it would fail.

He was way more excited about that than they had some engine that would just die. [Laughter]

Yeah, how many thousands of dollars’ worth of engines did they destroy? [Laughter]

That’s awesome. Jim was literally a rocket scientist.

Nice.

Yeah. He’s done it all. He told me once how many industries he worked in. I don’t even remember, but it was a lot. It was impressive.

He showed me some stuff that he was working on, this was a couple of years ago, for Neo or EdgeCase or whatever they were at the time. And basically what it was, was it was an Androidbased thermostat. And you could control it. They were working on a web interface for it. Just stuff out there that you don’t really think about, rocket OS’s and thermostats in your house. It was just anything that he could play with, [chuckles] the guy was into.

He loved to fiddle, for sure. But Chuck talked about the quadcopters. I threw a link to a recent talk he gave that was actually about Friendly Flying Robots with Ruby. And I think he actually, it may have been when we were in England, I mentioned that I saw him at Scottish Ruby Conf. And like me, he toured around through England a bit while he was there. And I think he ended up going to a Node.js group and they were playing with quadcopters there. And he played with that and had fun. And then typical Jim, he wanted to figure out how to do it in Ruby, his favorite toy. So, he did a lot in there. I haven’t seen this talk, but I assume it’s about that.

Okay. So, there’s one little bit of Jim’s legacy that I think is one of my less favorite parts of the Ruby world. And that’s the way that people name their configuration files.

[Laughs] Yeah, [inaudible].

[Chuckles] So, Rake was the Ruby make. And make was created, it used the makefile was what they called it. And this is back in the day when filenames on systems were really short. You got eight characters and then a three-character extension. For all you children out there, yes we couldn’t have thousand-character long filenames. [Laughter]

And we had to walk to school uphill both ways.

In the snow.

Yeah.

What’s funny is even after operating started to get beyond that, you still ran into problems with it, because in Windows even when it got past that, if you went down to the DOS layer or something, it just truncated everything to eight.three.

Yeah, you got all the twiddles in your filenames.

Right, yeah.

Yeah, that was terrible. So Jim, not criticizing the decision at all, I think it was a good decision, he said, “Oh, we’re going the call the file, the configuration file for Rake, rakefile.” And there was a lot of history coming from makefile for that, so that was fine. But then, every other project that’s come along since then that’s looking for a configuration filename just slaps file on the end of the word. So, you have procfiles and gemfiles and…

Vagrantfile.

Yeah.

If you use Librarian-Chef, it’s the cheffile.

Yeah, capfiles and filefiles and dirtfiles and whatever.

Jugfiles.

Yeah. So, I think Jim gets a special exception.

He’s exempt from criticism on this because he was following in the footsteps of make. But everybody else, you’re wrong. [Laughter]

Josh, why don’t you tell us why?

Everybody else, you have no excuse.

Why don’t you tell us why we’re wrong?

Because, well one, it makes it harder for your tools to know that the file that you’re working with is written in Ruby. So, your syntax highlighting doesn’t work. Your searches and things like that can’t be smart. So, that’s a problem. And that’s actually my biggest problem with it.

So, the fact that it doesn’t have a ‘.rb’ in the end is what you’re saying?

Yeah. There’s no ‘.rb’ on the end.

See, my biggest problem with it isn’t that. It’s that it’s all in the root directory of the project. [Laughter]

That too.

And so, all of my other configs for my database and whatever, say in Rails, it all goes in config. Or in Sinatra, I still put all my config stuff in config. And then I’ve got blahfile, blahfile, blahfile, blahfile, and blahfile because I’m using Guard and Foreman and…

Yeah, Guard is [inaudible]

Oh yeah, guardfile.

Rake. And so, I’ve got six of them in there and it’s all cluttered, because I don’t need to know about them I’m specifically dealing with those tools. And so, I’d rather hide them in config.

Right. But it shows up on the first page of GitHub. That’s what you need.

Yeah. [Laughter]

Right, that’s important.

See Josh, I always thought your main objection was that the naming was redundant.

Oh, well that too.

The filefile?

Well, it is.

But the extra redundant information isn’t as big a problem for me as the missing information that the file is written in Ruby.

Gotcha.

That’s like when you have a name object and you put a name method on it. So, you’re like, name.name.

It’s like, “Ah!” I hate that. [Chuckles]

The worst is content.

Content, yeah. [Chuckles]

What’s the content of my content?

Yeah, exactly.

Well, then if it’s bad, you make it malcontent.

[Chuckles] That’s right.

Nice. [Chuckles] Okay.

One thing that Jim always did for me too, is he always introduced me to new people. And that was something that I really appreciated. I just wanted to bring that up. I know Avdi talked about him introducing he and Sandi Metz. And he did that with a whole bunch of people for me. And I’m not going to go down the list, but they’re people whose opinion I still appreciate today. So, it was, man, the guy was just awesome.

Yeah.

That is such a great people pattern.

Yes, yes.

When you’re at a conference or something and you realize that person A has something in common with person B and you introduce the two, it’s a great feeling for you and it’s usually great for them. It’s a great habit to be in.

Jim was, Gladwell has this term, Malcolm Gladwell, about the different kinds of people. And one of the people is a connector. And they’re the people that know everybody. [Chuckles] Their job is literally to put people in touch with other people and help people find other people. And I would say Jim definitely fills that role. I think it was because he was so just a kind personality and that everybody eventually got to know him. And then it’s like you said, he would find this other person, and they would be like, “Well, I’m working on this.” And he’d be like, “Oh, I know somebody you got to talk to.” And he would take you to them. It was great.

Yeah. You know, this isn’t much of an anecdote, but I want to share it just because it’s part of my memory of him. Just very briefly, my wife and I sat with him on the pirate boat at Ancient City Ruby. And so, she doesn’t code and she doesn’t really know many of my Ruby friends. But she remembered Jim because he was so nice to her. He completely put her at ease and talked about all kinds interesting stuff outside the world of coding for a while on that boat. And I don’t know. He was just such a nice guy to everyone. And he put everyone at ease.

Yeah.

My wife also knew Jim. She did through coding. When she was working in Ruby, she took one of his workshops at a LoneStar Ruby Conference. One year after Red Dirt, we played board games with Jim in the hallway of the lobby after the conference was over. And my wife was there for that and played games with Jim. And then we went out to eat with him a couple of times when we ran into him at conferences and stuff. And when she heard he had passed, she was just heartbroken because she really liked him too.

Yeah. He was the epitome of style and grace.

Absolutely. Well said.

My one little Jim anecdote, I’ll finish up my part here with, was when RubyConf was close to San Francisco in 2009. It wasn’t exactly in San Francisco. It was down by the airport. But there was a little event that we did during the lunch break of ‘Pairing with the Stars’ where we had… I kind of disliked the whole star, hero worship focus of the event. But it was fun to do anyway. A couple of us big name Rubyists paired up with “ordinary” Rubyists and we did a little ‘Dancing with the Stars’ type competition. And Jim kicked my ass. [Laughter]

I thought we had it. We went through the first two rounds, my pair and I. We were ahead on points. Everything was great. And then the final number, we did okay, my pair and I. This was something that happened over a couple of lunch times throughout the conference, for a couple of days. And the last day, Jim and his pair got up there and they just crushed us. And Jim took our code, which I thought ended up being really beautiful, and in the midst of his, he only had so many minutes, three minutes to do his entire thing, he took a few seconds out to correct my code. [Laughter]

Here’s what I did right. Here’s what Josh did wrong.

Yeah, yes. He’s like, “Very good. You almost got it right, but you left out the bit where you always want to pass the block to the method.” [Laughter]

Thanks, Jim.

That was awesome.

So, he completely crushed us. But he made me feel so good watching him do it that I couldn’t feel bad about it at all. [Laughter]

So, even though we were ahead on points, his pair won by acclaim. And I didn’t feel bad about them at all.

That’s awesome.

Yeah.

He is such an inspiration to me when it comes to how to deal with criticism and with opinions. He clearly had lots of opinions. A lot of his talks are about his opinions. But he always addressed them in such a very constructive way. And I reflect on that every time I think about him.

Yeah. I agree.

Well, sounds like we’re at a point to wrap up.

Yeah, I think maybe something good to say in closing is, we’ve touched on this in this episode, but Jim left this amazing legacy of code and talks and stories and things. And it’s really inspiring and there’s amazing stuff. The code is very readable. I’ve just spent the last few days reading bits of Jim code here and there. And I can’t believe how many cool things I found. I have even more that we didn’t have time to talk about. And I think you could spend a little time just spelunking in Jim land. Go pick a talk that sounds interesting you off of that list of 34 and listen. Go look through a couple of these libraries and glance at the code we’ve been mentioning and talking about. I’m pretty sure you’ll consider that time well spent. It’s hard not to get into this and not gain things from it. It’s truly an amazing legacy and what a great way to honor the guy by learning from it. That’s exactly why he did all this. So, it’s worth it.

Very much agree.

Yeah. I got nothing to add to that. That’s great.

Quick reminder, we are reading ‘Object Design’ for our book club book. It is by Rebecca WirfsBrock and Alan McKean. And we’re going to have Rebecca on the show. So, go pick it up. We’ll put a link in the show notes. And thanks for listening.

Ruby Coding High] It was born in the mountains of a far and distant land, Bringing hope to a world lost in drear. Created as a promise to coders far and wide, Who felt that joy was never here. It came to the new world in a most pragmatic way, Revealed in the pages of a tome. It came to us in secret, but it didn't stay that way, Growing fast, it came to every home. Ruby is righteous coding high. I've seen it make a Java guru cry. You can make an object, and change it on the fly. Ruby Coding High, Rake and Builder. Ruby Coding High, Nokogiri. Ruby Coding High, Devise and Yaml. Ruby Coding High, Mocha and JSon. It started as a simple way of gluing custom code. But it wasn't its final destiny. Rails came to show convention was a better way to code For people, for sites for all to see. Ruby is a righteous coding high. I've seen it make a PHPer sigh. You can make a web request and wait for its reply. Ruby Coding High, Rails and RSpec. Ruby Coding High, Capistrano. Ruby Coding High, ActiveRecord. Rocky Mountain Ruby, Colorado.]