Michael Brodhead talks to Avdi Grimm of RubyTapas fame about joining Ruby Rogues, creating Exceptional Ruby and why he uses Emacs
- 1:00 All about Avdi
- 9:45 Advice for Python users learning Ruby
- 19:00 Exceptional Ruby
- 20:30 RubyTapas
- 24:00 Working on Ruby Rogues
- 27:00 Challenges with remote working
- 38:00 Why Emacs
- 52:00 What's next
Avdi on Twitter: https://twitter.com/avdi Avdi on GitHub: https://github.com/avdi Avdi's website: http://about.avdi.org/
Links RubyTapas: http://devblog.avdi.org/rubytapas/ Expect-tcl: http://www.tcl.tk/man/expect5.31/expect.1.html Ruby Rogues: http://rubyrogues.com/ Wide Teams: http://www.wideteams.com/ yuuguu: https://www.yuuguu.com/s/home
Michael Brodhead: Hi. Welcome to Cloud Out Loud. I am Michael Brodhead from Engine Yard and, today, I’ve got Avdi Grimm of RubyTapas and lots of other stuff fame. Hey, Avdi. Welcome.
Avdi Grimm: Hey! Hello from Pennsylvania.
Michael Brodhead: How was your Thanksgiving?
Avdi Grimm: It was good. We had a fantastic dinner – really just our family – and looking forward, today, to another tradition that we have where we have sorta a Black Friday friends-giving when we have all of our various friends in the area over. Everybody usually brings a dish, and we have all our leftovers, and we just sorta have an informal gathering. And it’s always been in the past years, so –
Michael Brodhead: Cool, cool, sounds fun – and hopefully, your podcast experience in the morning won’t be too traumatic and you won’t have to complain about that. So, tell us a little bit about yourself.
Avdi Grimm: Let’s see. What do you wanna know? I am, obviously, a programmer. I’ve been programming for a living since I was 18 years old and been messing around with Ruby, in one form or another, since around 2001. And, as you noted, I have – you know, I make videos now. I write. I consult. What else do you wanna know?
Michael Brodhead: What is your day job, in addition to all of the other stuff that we will dig into?
Avdi Grimm: That’s sorta in flux right now. And – oh, by the way, as far as like about me? The other thing that I’d like to say is I have a large and wonderful family. I have five kids so far.
Michael Brodhead: – Wow.
Avdi Grimm: And a wonderful wife, who cooks a mean Thanksgiving dinner.
Michael Brodhead: Cool, how old are your kids?
Avdi Grimm: They run the gambit. We have from a couple months old, all the way up to going on 18. So –
Michael Brodhead: Wow. That’ll keep you busy.
Avdi Grimm: And – yeah, so, anyway, back to your question, day job? Day job is kinda an interesting question right now because I recently crossed the line where more of my monthly income is coming from RubyTapas than is coming from my consulting.
Michael Brodhead: Oh, that’s awesome.
Avdi Grimm: So, I – you know, up till very recently, I considered myself a consulting programmer with some media side projects, and I’m sorta adjusting to the new normal, which, you know, if all goes well, is going to be a producer of – I guess – educational media with consulting on the side. I don’t do any traditional consulting any more. I haven’t since around the middle of the year, so I don’t have contracts that I work on, you know, to build software. What I do is take appointments for remote pair programming sessions and those can be people that – you know, other consultants or other groups that are working on software, and they just wanna work with me on some refactoring, or some question of design, or something like that. Or, “We’d like to get our stuff more tested,” or, “Our tests are really slow. What can we do about it?” And stuff like that. From that, to tutoring people that are relatively new to Ruby and/or Rails, and wanna get a sorta a jumpstart on it.
Michael Brodhead: Cool. Cool, that’s neat. What brought you to programming originally and what, like, other languages did you do?
Avdi Grimm: I think my story is similar to so many other – so many other programmers’ stories I’ve read. I mean, I wanted – I played computer games when I was a kid and I wanted to write them. And, I mean, like the very first program that I wrote myself, I taught myself the Rex programming language, which nobody has ever heard of any more. It was – it’s an obscure IBM scripting language, but it’s what I had because I was running OS2 at the time. I wrote a text adventure, which had three rooms, and – yeah, and an object or something like that. And, yeah – you know, eventually, I crossed that line where I discovered solving problems in the computer was actually a lot more interesting than computer games.
Michael Brodhead: Yeah, yeah, that’s a similar path to my own; although, I’ve only met a couple of people that have programmed in Rex, and I’m guessing most folks won’t have heard of it. That’s – Avdi Grimm: – Hey, I was gonna say, I’m actually impressed that you’ve heard of it, let alone met other people that have programmed in it.
Michael Brodhead: Yeah, not too many. So, as I understand, it’s – the first person who told me about it was comparing it to Pearl and saying it was somewhat text-manipulation-y.
Avdi Grimm: I have on idea because I cannot remember an – one iota of Rex. I literally cannot remember any syntax – anything. I just know that I taught myself to program in it, and I know I wrote some scripts in it, and it has completely fallen out of my brain. You asked about other languages since then. I’ve done C, C++. I’ve done some work in 68,000 Assembler – I mean, Assembly. I did a fair amount of Pearl. I actually did some VBA, which I’m not completely ashamed to admit because it got the job done at the time. Messed around in Python a little bit. I actually learned Python and Ruby concurrently. I did those same examples in both and I wound up sticking with Ruby. I did a fair amount of Tcl at one point. I’ve done a lot of LISP along the way, just as a result of being an Emacs user. Some Haskell just for fun, mainly – for some weird definition of fun. Oh, yeah! Java, C#, done some stuff in those. And, every time I do this list, I realize afterwards that I left like three or four languages off, but that’s some of the ones I’ve used.
Michael Brodhead: Cool. That’s – I’m excited to hear you say you were learning Python and Ruby concurrently because I’ve been trying to find people that can talk about the differences between the two. And – because I feel like my own Python experience, even though I dabbled in Python before I went to Ruby, I feel like I’m too biased or not experienced enough in Python to make very many useful comparisons. So, tell us about that moment when you started to go one way.
Avdi Grimm: Well, okay, and I have to put the proviso in here that this was 2001. So, Python was a younger language back then; obviously, Ruby was a younger language back then, but Ruby, in many ways I think, sprang almost fully-formed from Matz’s head because he’d been mulling it over for like decades before he actually –
Michael Brodhead: – Oh, really?
Avdi Grimm: – created it. Yeah, I mean, I’ve seen a quote that he was writing Ruby in C for many years before he actually created the Ruby programming language, you know? So, he was using a lot of the techniques.
Michael Brodhead: Interesting.
Avdi Grimm: You know? And he – I think – had a pretty cohesive idea for it. So, it has changed, you know, but honestly, it hasn’t changed a heck of a lot, especially in things like its object system, since I started working on it back in the 1.6 or earlier days. Whereas Python, back then, was still in a lot evolution – Python got started as – well, I think, originally it was an in-house scripting, procedural scripting, language, which didn’t even have the OO elements. When I was using it, it had some of the OO elements, but it still had a lot of the history there where there were like these two different worlds that were built-in objects and user objects, and never the twain shall meet. So, like, you couldn’t inherit from built-in – the built-in array or – that’s the wrong term. I think they use list or whatever; it’s been a while. But you couldn’t inherit from any of the built-in objects. There was a lot of funny dichotomies between some things were calling a method on an object and some things were calling a free function on the object. There’s still a little of that left over where you call len on things instead of calling thing.length. And so, as somebody who is really into the OO paradigm, even back then, Ruby felt a lot cleaner. It was a lot more consistent in its OO elements. And the other aspect was that I was coming to Ruby and Python from Pearl. I had been writing a significant amount of Pearl. It had been really, really accelerating my work, you know? I mean, it’s – it really was the Swiss Army chainsaw. The fact that Ruby – that you could basically take a Pearl program, and it would be function – it would be – it would run as Ruby code, or almost run as Ruby code, and then, you could just sorta go through it, and incrementally add nice abstractions to it, that would have been a lot harder in Pearl, was really nice. Whereas Python didn’t really have that kinda Pearl compatibility layer where you had these odd, but very concise syntax sugar elements, which – but then, they also had, you know, OO equivalents, yeah.
Michael Brodhead: That’s interesting. I never thought about that, but yeah; an awful lot of stuff would just go right over. So, I actually – I work with a bunch of people who have been Python programmers and are just now starting to transition to Ruby. Do you have any advice that you would give them on grokking Ruby from the Python mindset?
Avdi Grimm: I think one of the biggest shifts to make is to understand the delineation between message sending and method calling. Python and JavaScript are similar in that you do a lot of – you know, in that methods are just another attribute of an object. You know, you’re basically assigning a function to a slot on the object, and now, you have that method on the object.
Michael Brodhead: Right.
Avdi Grimm: And this is the sorta thing that’s a little hard to describe in a podcast; I’ve done a couple of screen casts on RubyTapas about this. But the sorta small-talkish ideal that Ruby hews to is the idea that you don’t know the implementation of the method that you’re calling and, as a matter of fact, that implementation might change over time. So, you send a message to an object, and the object decides which implementation to use to fulfill that – to answer that message, to respond to that message. And so, like it doesn’t make sense – in Ruby, it’s more difficult to say, “Give me a reference to your method.” You can do it, but it’s a little harder to say, “Give me a reference to your method.” And that’s not – and that’s kinda by design because what if that – because there are actually cases where that method might be changed or that method might become advised by some other code over time. And, if you’re sending the message to the object, then the object worries about those sorta internal things; whereas if you took a reference to that exact method implementation early, then you’re now out-of-date, you know? That idea is much more – it’s much closer to some of the functional ideas in LISP or Scheme where you do a lot of passing around chunks of code. You know, Ruby, it’s much more the small-talk idea of, “This is a black box. It decides how it responds to messages, and it might even change over time how it responds to those messages, and you don’t need to know or care.”
Michael Brodhead: That – you know, now that you put it that way – I dug the Tapas episode about it, but now that you put it that way, I’m kinda surprised I didn’t stumble over that as I was coming to Ruby, but I guess I just got lucky. So, cool, that’s good advice to give them.
Avdi Grimm: So, yeah, message passing. It’s all about message passing; that’s basically a nutshell.
Michael Brodhead: In your Tcl adventures, did you deal with Expect at all?
Avdi Grimm: Yeah, I did, a little bit. Actually, the most that I’ve dealt with Expect – so, I don't know. Do you wanna explain what Expect is?
Michael Brodhead: Oh, God. I should be able to do this because I’ve had to have this conversation a bunch of times recently. Expect was – actually, I didn’t use it hands-on, so I couldn’t tell if it was just a tool or a library, but it was basically a means of automating the driving of command line tools. So, you can, you know, invoke another program, and give it input, and respond to its output, and it gets it name from saying – from a call where you would say, “Expect a particular string,” and you’re basically waiting for that in the out. But then, the part that I thought was really spiff is that you can, at some point, just hand control to the user, and from there on out, the user doesn’t experience anything differently than if they had invoked the command themselves.
Avdi Grimm: That’s a really good point, yeah. It’s been a while since I’ve worked with Expect. I did, actually, write a Ruby – sorta a Ruby equivalent; although, that is one feature that I wish I had gotten around to adding because that would have been really cool – the ability to just sorta hand it over to the user. I wrote a gem called Green Letters, which starts up a PTY, a pseudo-terminal, and – which is, I believe, the same method that Expect uses. And it enables you to basically set expectations on what’s gonna come next, and set responders to different prompts that it might see coming out of that pseudo-terminal. And I – it works for some things that you can’t just use standard IO and standard in, standard out for. I discovered that. However, the classic adventure – the Classic Colossal Cave game is written, it doesn’t use standard IO as far as I can tell because I tried to – I was like trying to automate it, and my program couldn’t talk to it until I put the program in a pseudo-terminal. So, yeah – sorry, tangent, but I have tried to reimplement Expect in Ruby.
Michael Brodhead: You know, I forgot about green letters, and I shouldn’t have because I actually have used it a little bit in testing of command line apps. And I didn’t – it didn’t even click that that was yours. Yeah, because we recently, at Engine Yard, had to do a lot of stuff that Expect would have made much easier – of, you know, invoking a command, and then, passing control to the user – and it was kinda irritating to do. So, it’s made me wonder if we need to cobble something together for Ruby so that the next guy doesn’t have to do deal with that.
Avdi Grimm: – I still – I still miss Tcl from time to time. I mean, you know, all props to Ruby, but frankly, Tcl is a better language root for creating DSLs in.
Michael Brodhead: Hmm, interesting.
Avdi Grimm: You know, it’s – Ruby is pretty good, but as far as the internal DSLs go, Tcl is about as good as it gets.
Michael Brodhead: Interesting, because I read up on Tcl because of Expect, but didn’t actually end up using it, but it just seemed to me like there weren’t enough – there wasn’t enough to make a real language there. Like the much-hyped, “Oh, there are only six rules that define the language,” for me, felt like was not enough.
Avdi Grimm: Well, see that – but that right there is what makes it amazingly good for DSLs because it – because there are so few syntax rules, there is very little to trip over. With Ruby, you have a lot of reserved keywords. You have a lot of, you know, syntactical elements that could just happen to become valid Ruby and break the – you know, valid Ruby, but – or semantically incorrect or something and break the program. Tcl has this wonderful ability to, you know, like a block in Tcl is, literally, just a string. It’s this quoted string that pretty much anything can go in, and then, the method can decide what to do with that string. It can eval it as code, or it can run some sorta parser over it, or – this is something that you see sometimes – it can do a little pre-processing to turn some stuff in there, you know, expand some stuff in there out into code, and then, eval it as code.
Michael Brodhead: Ah –
Avdi Grimm: So, like, Ruby, when you pass a block, you’re always getting the Ruby-parced procified version of that block; you don’t get to intercept the part where Ruby goes in, parses it, and turns it into a proc, or decides that it’s syntactically incorrect and raises an exception. Whereas, when you’ve got a block in Tcl, it starts out as just a string. You completely decide what you wanna do with that. It’s also got some interesting capabilities, well beyond Ruby, in terms of dealing with variable scoping. So, it’s got this concept of – I think it’s like – upcalls and upvars where you can, basically – a function call can mess around with the stack frames above itself, which is incredibly dangerous, but it’s also –
Michael Brodhead: – Yeah, that seems like a lot of rope to give people to hang themselves with.
Avdi Grimm: – Oh, yeah. Oh, yeah, but it’s also – it’s also incredibly powerful for DSLs because it means you can actually – you know, I mean, if you want to create your own variable definition –
Michael Brodhead: – Ah –
Avdi Grimm: – your own version of, you know, how variables are defined or declared, you can do that because you can just define a function called Declare, or MyDeclare, or something like that. You know, maybe you wanna have like types declarations or something, you know? And you can just – you can create a function for that and, since it can mess around with the binding that it was called in, it can totally declare a new variable there.
Michael Brodhead: And you could even define your own control structures, which usually –
Avdi Grimm: – Yes.
Michael Brodhead: Hmm.
Avdi Grimm: Yes, as a matter of fact – yeah. All the control structures in Tcl are just functions, and they just take blocks, and since the blocks are just strings, they can do whatever they want inside those. So, yeah, it’s a very powerful language for DSLs.
Michael Brodhead: Huh, I’m gonna have to go give Tcl another look now. Let’s see. There’s a million different things that you do. I rattled off a list. Let’s see. There was your Wide Teams podcast.
Avdi Grimm: Yes.
Michael Brodhead: You’re on the Ruby Rogues podcast. You wrote Exceptional Ruby, which, unfortunately, I didn’t finish before interview day, but I am digging. Ruby Tapas, which totally rocks, and I’m trying not to use profanity. And then, you do these remote-pairing sessions. What – did I miss anything there?
Avdi Grimm: I think that’s it.
Michael Brodhead: So, I guess we’ll just start in the middle because that makes no sense.
Avdi Grimm: Sure.
Michael Brodhead: Tell us about Exceptional Ruby.
Avdi Grimm: That was an exercise in, “I feel like I suck at this – this area of programming – and, so, I’m going to propose a talk, which, if accepted, will force me to learn more about it.”
Michael Brodhead: Tried-and-true method.
Avdi Grimm: In this case, the area in question was dealing with failure. It seems to get, at most, one chapter in any given programming book and I felt like I didn’t – I never had a sorta cohesive philosophy, you know, to draw on when dealing with failures and exceptions. And like it was always making the same decisions over and over again, and I was never quite sure whether I was making sensible ones or not when designing my failure policies. So, I just – I wanted an excuse to develop that philosophy further.
Michael Brodhead: That – yeah, that’s great, because I was experiencing that same frustration, so I read about Exceptional Ruby, and jumped at it because that’s – yeah – exactly the sorta – where I was at. And so, that’s not a Atoms book, but it is a Bits book, and it’s available through your website, right, and through the Prags as well?
Avdi Grimm: Yeah, it’s available from ExceptionalRuby.com, and it’s also available through the Pragmatic Programmers. I get a bit more money if you buy it direct from me, but if you like Dead Tree books, the Prags actually sell a Dead Tree version. So –
Michael Brodhead: – Ooh, I did not know that. Cool. RubyTapas has been a lot of fun and I was – maybe instead of me blathering about it, I will let you describe what RubyTapas is.
Avdi Grimm: RubyTapas is a screen cast series for, I would say, intermediate to advanced Ruby programmers. So, it assumes that you’re familiar with the Ruby language and gets into stuff that you might now know. So, I cover a few different, broad areas. I cover bits of the language that you might know about, or things about the language – you know, little nitpicky things, and handy idioms, and stuff like that that you might not be aware of. I cover standard libraries a lot that not everyone, you know, knows about or knows fully how to use. And, you know, I go into detail on things like the Struct Library, or OpenStruct, or – I can’t remember what else I’ve done so far, but – and then, I also talk about like program design, and object-oriented principles, and how to sorta program with the grain of an OO language. It’s, I guess, a little unique in that it is very frequent and very short. So, typical episodes are two to five minutes long and I put them out every Monday, Wednesday, and Friday.
Michael Brodhead: Yeah, and the length, I think, is what makes it really work because it means I actually get to them. Because there’s so much great content out there, but there’s a lot of long things, and I had this stack in Instapaper of videos that look really promising. Like, “Okay, when am I gonna be able to hold still for 45 minutes?”
Avdi Grimm: Right.
Michael Brodhead: So, yeah, having them digestible makes it really nice.
Avdi Grimm: Yeah –
Michael Brodhead: – I especially –
Avdi Grimm: – my goal is to have – is to get across one new idea.
Michael Brodhead: Yeah, yeah. Actually, some advice that a colleague once gave me when – because he was – we were working in Java, and he was new to Java at that time, is that – and I would get excited and spew a whole bunch of things at him, and he said, “So, in any given conversation, people can handle two new things.” And so, after that, you know, I tried to make a point of just like count my things, and then, stop. But it’s –
Avdi Grimm: – Good advice, yeah.
Michael Brodhead: – It’s hard, yeah. I especially like the episodes about Fetch because, you know, I don't know how many times I’ve looked at the R-Doc for hash, but I’ve always just breezed right over that. But then, when you talked about it, I realized like, “Oh, I’ve been in a situation where I’ve wished for that a million times.”
Avdi Grimm: Yes.
Michael Brodhead: Like, “Why do I have to write this by hand?’
Avdi Grimm: – I’m always – it’s – I always love the response that I get to that because I introduce people to that in my pairing sessions; I talk about it in talks. I – I kinda – I think I squeeze into just about every talk that I do, and I have this sorta – this goal in the back of my mind that, some day, I’m gonna do a talk and I’m gonna say, “Who here knows what Fetch does?” and every single hand is gonna go up, and then, I know my work will be done.
Michael Brodhead: Mission in life.
Avdi Grimm: Yeah.
Michael Brodhead: You can die a happy man. That’s awesome. So, which Ruby runtime do you use? You an MRI man or –?
Avdi Grimm: Yeah, I mean, I just – pretty much all my stuff is done in MRI 1.9.3 these days. I would use something else if I needed to – if I needed, you know, if had an application where I really needed true multi-threading or something like that. I’d use JRuby or Rubinius . But, also, with more and more of my stuff being educational, I’ve been – I try to keep it to sorta the definitive Ruby and base it on that.
Michael Brodhead: Yeah, yeah, just a lot easier for people to deal with. So, tell us about The Rogues.
Avdi Grimm: So, Ruby Rogues, one of – is often the highpoint of my week – recording those, those episodes – it’s – I am incredibly privileged to get to do that every week. Obviously, I mean, probably most people know it is a podcast, our weekly podcast, with roundtable discussions of topics that are of interest to Ruby programmers, hopefully. And I’m just – I’m so thrilled to be able to chat with James Gray, and Josh Susser, David Brady, Chuck Wood every week. It’s a huge privilege.
Michael Brodhead: How did you guys find one another?
Avdi Grimm: Well, so, the Ruby Rogues existed – were a thing – well before I joined them. I’m the most recent addition to the cast, so I would – I guess I would – I’d ask Chuck and James that question. I’m not sure what the original formative days were like. But I think they had me on – so, back when Aaron was still on the show – Aaron Paterson was still on the show, I think once or twice somebody couldn’t make the show, and they reached out to me to see if I wanted to come on as a guest. I guess, like, from my Exceptional Ruby stuff or something, they knew about me. And then, when Aaron just got too busy to do it every week, I basically filled his – they asked me to fill his seat, and that’s a really, really, really big seat to fill, but I’m doing my best.
Michael Brodhead: I’m comparatively new to Ruby Rogues. I got turned on to you guys with the – I was asking colleagues about pairing, and training for pairing, and somebody suggested your episode with Angela Harms, which was fairly new at the time and sorta gone from there. I haven’t gone back to the back catalog yet, but yeah, it’s a lot of fun. I learn things, but I’m also entertained, and yeah – I’ve been really digging it. So, and then, you’ve got your other podcast, the Wide Teams podcast. Tell us about that a bit.
Avdi Grimm: Yeah, so, I have been working remotely for many years. It’s always been kinda a goal of my life to live where I wanna live with my family and not let work dictate where I’m living. And so, as part of that, you know, I figured it – partly, it behooved me to get better at it, and one way I could think of to do that was to talk to other people who were doing distributed teams in one form or another, and find out, you know, what was working for them and what wasn’t – what kinda techniques they used. And also, I just kinda noticed – as I was doing it, I noticed that there weren’t a lot of resources out there where people were sharing information about their experiences with remote work, and so, I thought I’d create a new – create a place for – to gather some of that knowledge together. I interview people that are working remotely, or, you know, manage dispersed teams, or some variation on that. Occasionally, people that think – you know, to get the other perspective, I interview people that think that dispersed teams are a terrible idea and I do that – we put those out once a week.
Michael Brodhead: Cool, yeah. That’s been a pretty good resource because I’m trying to get better at that myself. It’s so much harder than pairing in person or, at least, you know, because I’m not adept at it yet anyway, it’s harder to me. But are there any highlights you wanna hit of good advice that you’ve learned from doing the podcast?
Avdi Grimm: Well, I think the thing that people hit on the most is trust. You know, the thing that I hear over and over again is, you know, “Build up. Make sure you’re working with people that you trust. Make sure that you work on maintaining the trust, you know, whether that’s meeting up in person regularly or what.” Just, you know, that trust, trust, trust. The downfall of a lot of dispersed teams is trying to manage them, you know? Trying to oversee them, and make sure that everybody is working hard, and basically, like do the digital equivalent of wandering around, looking over people’s shoulders. And it just doesn’t work and it defeats the purpose of it. You know, I think the other sorta broad guidelines that I hear over and over again is, “Make sure that everybody is on an equal footing.” You know, for some teams, this is pretty easy. The teams that are just completely dispersed and have been from Day 1, then they kinda organically figure out how – that everybody is equally at a disadvantage for not being able to walk down the hall and chat, and it’s not a big a deal for them. But for some groups where there’s an office, and then there a few people that are satellites, I’ve heard over and over again that they learned the lesson that they had to find ways of putting everyone on an equal footing, which often means things like the “Everybody calls in” rule where, you know, even if you’re in the – when you have a meeting, even if you have people in the office, they all call in from their own machines, rather than having a bunch of people in a conference room and a speakerphone in the middle.
Michael Brodhead: Yeah, we struggle with that at Engine Yard. There are a couple of individual teams – like our support team is 100 percent remote. And so, internally, they’ve got it down. But then, in other parts of the company, especially in Dev, we’ve got big clusters in a few offices, and so, yeah, it’s definitely something we struggle with. I think we’re at that threshold where we have just enough remote staff for it to be tough without crossing over into like forcing everybody to use the online tools. And I saw a talk by Joe – and I’m spacing on his last name – but he works for Pivotal, or at least worked for Pivotal at the time, and he – I had only tried remote pairing just with screen and a TTY-based editor. And he was pitching using screen-sharing and using a native editor. The little bit that I’ve done that since, it seems to work pretty well, and the latency is not what I feared it would be.
Avdi Grimm: Yeah, I – so, in my work, I primarily use a screen-sharing tool called Yuuguu, and I just – you know, people – I work with people that are using their own tools. I do that for a few reasons. Because I work – I might work with a half a dozen or more people in a given week, I don’t wanna fiddle around with like SSH forwarding settings, and trading keys around, and stuff like that with a bunch of different people in order to establish a T mock session or something like that, you know? And I also – I’m – for the kinda work that I’m doing, I’m more focused on kinda sitting back, being the navigator, and asking questions about what they’re doing, and guiding what they’re doing, rather – and then, having them to be right there in the pilot seat once the session ends, you know, ready to continue forward rather than – so, I’m generally pretty hands-off. I think there’s definitely a place for some of the really low-latency tools like tmux. I mean, if you pair every day with someone, then it could be really – it’d be really nice to be able to hand-control back and forth, and especially if you can have like a – if you can have a server in the cloud somewhere that you both SSH into; I think that could work really well. But just for the stuff that I do, I’ve been pretty happy with screen sharing.
Michael Brodhead: And how is Yuuguu spelled?
Avdi Grimm: Y-U-U-G-U-U.
Michael Brodhead: Ah, I missed a few Us there. All right, I’m writing that down to look at later.
Avdi Grimm: It’s a silly name. It has the advantage of being very cross-platform, so it works on Linux; it works on OSX; it works on Windows. And because it’s hosted, there’s no fiddling around with firewall settings because it –
Michael Brodhead: – Oh, nice.
Avdi Grimm: – You know, it figures out – it sends a stream up to their servers, and then, their servers send it back down.
Michael Brodhead: Cool. Yeah, that makes a lot of sense. My first experience pairing with – well, it was actually screen and not tmux – I haven’t made the jump yet – was a little rough because I hadn’t – my Emacs chops were really rusty. Emacs used to be my primary editor, but it hasn’t been for a long time. So, I was getting my Emacs sea legs back again, but also, the person I was pairing with was using a bunch of fancy modes that I hadn’t used before. So, like, even the key bindings that I did have under my fingers didn’t work, and – yeah.
Avdi Grimm: Yeah. Yeah, this is one of the reasons that I think – I mean, I think for some groups it can be very workable to have people just like trading the keyboard back and forth, but I don't know. When you have different programmers that have their own environments that they’ve configured over the years to work for them, sometimes, it makes sense to just let people use the environment that works for them. And then, if you wanna shift over, you know, maybe push the code to source control, and then, swap who’s hosting.
Michael Brodhead: Yeah, actually, that makes a lot of sense. And, actually, one of the more mundane ways that I’ve done it, which is – it’s not really pairing, but one person is writing test, and the other person is getting the test to pass.
Avdi Grimm: Right.
Michael Brodhead: But that’s not as satisfying, I think, and probably doesn’t result in code that’s quite as good, but it does – at least it works.
Avdi Grimm: Yeah.
Michael Brodhead: So, you’ve mentioned your own remote pairing services a little bit. Can you tell us a little bit more about that?
Avdi Grimm: Yeah, I – so, I mean, basically, what I do – okay, not as much for a living any more now that I’ve got RubyTapas out, but what I do is I accept appointments, they’re typically two hours long, for pair programming. And I think I already mentioned, you know, some of the different topics that people contact me about, but it’s been working out really well. I wasn’t sure what the demand would be, but it keeps me consistently busy. It keeps my schedule full. I don’t do it all week long. I have – typically, I do it Tuesday, Wednesday, Thursday, and, you know, it can be pretty exhausting having several pairing sessions with different people in a day. It can be pretty exhausting.
Michael Brodhead: – Oh, yeah.
Avdi Grimm: So, it’s not something I’d wanna do five days a week, but, you know, people keep coming back, so I guess I’m doing something right. I also try to do one open-source pairing session every week, which I don’t charge for, and where I just work with someone on some open-source project, whether it’s something that they wanna release or something that is already out there and they wanna add something to. And that’s – I love those sessions so much because, you know, a lot of times, it gives somebody who might not have the resources to retain my services for a paid pairing session, you know, it gives them the opportunity to work with me, and so often, it’s somebody that’s new – relatively new – to the Ruby community. You know, I just get to show them some stuff. I mean, last week, I helped somebody push their very first Gem. You know, they – while we were having our session, they registered their account with RubyGems.
Michael Brodhead: Oh, wow.
Avdi Grimm: And pushed – you know, and I helped get them through some of the last hurdles that they had with the Gem that they had already been working on – you know, get it together, build it, and push it out. And that’s – I know that’s exciting, and being able to facilitate that for someone is – it really makes me feel good.
Michael Brodhead: I saw that Tweet go by last week and I was actually a little jealous because that just – yeah, it’s gotta be a cool moment.
Avdi Grimm: – So, this is the thing that – so, this is something that I think about more and more. You know, as far as I can tell, I more or less invented this line of work. I have yet to find somebody else who was like, “Oh, yeah, I’ve been doing that for years,” you know? “I’ve been taking two-hour appointments with lots of different people.” You know, lots of people are doing consulting work, and they’re doing pair programming while they do consulting work, but I’ve yet to find somebody else who is doing this kinda ad-hoc session-based pair programming. And I think it’s an idea that deserves wider consideration, both – you know, for one thing, on the open-source side, you know, if you’ve got some extra time, there are so many people out there that are just so excited about getting into Ruby, and getting to the community for the first time, and – but they’re struggling with their first steps. You know, being able to be there for people like that just – it’s such a wonderful feeling and it makes me feel better about – it makes me feel like I’m paying it forward from all the people that helped me out when I was getting started. And I would advocate more people putting their time out there for that, as well as – you know, I think, at this point, if I were working on a consulting gig and I ran into a piece of technology – you know, I decided I wanted to use a piece of technology that I’d never used before. Rather than go read a book on it – if I was in the middle of a gig, and I had to just get something done, I think I would much rather find somebody who is already an expert on it, and pay them for two hours of their time, saying, “Hey, can you – can you pair with me on this – on my project? Just point me in the right – get me started in the right direction using this –” whether it’s like backbone JS or whatever. “Point me in the right direction. Make sure that I get started on the right foot and don’t make newbie mistakes that are gonna haunt me.” And you can usually do that in a two-hour or maybe two – couple of sessions. You know, I think if there’s – it’s an idea – it’s something that more people could do, and, you know, I would like to see – I’d kinda like to see a marketplace emerge where programmers help each other out like that.
Michael Brodhead: The Zeke author, actually, just posted about that – that he was looking for people to pair with him for an hour on Zeke. So, I’m in the middle of moving and can’t do it now, but I’m planning on taking him up on that. And I actually hadn’t even realized that Zeke was written in Ruby, so that was really exciting, and I pulled it down. I started poking through the source, and – so, yeah.
Avdi Grimm: Yeah, that’s a really cool project. I got to meet him at GoGaRuCo and he showed me around a little bit. It’s a really neat project.
Michael Brodhead: I’m kicking myself for not going to that this year. I mean, I live in the San Francisco Bay Area; I work in San Francisco. It would have been nothing to go over there. I loved it last year, but I – yeah, kicking myself.
Avdi Grimm: Yeah, it was a fantastic program.
Michael Brodhead: You have mentioned that Emacs is your editor of choice.
Avdi Grimm: Um-hum.
Michael Brodhead: Why?
Avdi Grimm: Emacs is only, tangentially, an editor. Emacs is a list machine. It’s a list machine that has been poured into probably more platforms than practically any other list machine. It is a programming environment particularly oriented towards dealing with text files that happens to have a pretty decent editor layered on top. And that suits my workflow well because, you know, it enables me to build – it’s a workbench, you know? It enables me to build the tools at the time that I need them, whether it’s as simple as recording a quick macro, or building on a macro to build an actual function – reusable function – that I can bind to a key, or turning that into a more elaborate library, or something like that. It is a workbench for dealing with the sorta artifacts that I deal with every day, that – those being text files full of code. So, yeah, I mean, I think that’s why I stick to it. The – some of the code that I have, you know, in my Emacs configuration has moved with me through the days that I was using Emacs on Windows, to the days that I was using it at home in Linux, to the days that I was using it at work on Mac OS, to when I migrated back to Linux, you know? I mean, it’s just – it’s enabled me to sorta carry these tools with me without worrying about what platform I was on.
Michael Brodhead: Yeah, it is remarkably transparent now that I think about it; although, I guess I’ve never run it on Windows. Have I? No, I have not – and, although, I’m sure it builds on Cygwin and all that. So – but I guess that’s not even really using Windows, huh, if you’re using Cygwin?
Avdi Grimm: It’s – well, it is. I mean, I’ve spent plenty of time with Cygwin utilities. I think the Emacs builds I was using were not specifically Cygwin. I don't know. They might have used the Cygwin libraries, but I don’t think I installed it under Cygwin. There were some distributions that they had the whole – they worked well with the whole Windows GUI environment, you know? They had native menus, and graphics, and stuff like that.
Michael Brodhead: I think Emacs would have a lot more users if they could smooth that initial learning curve because I know that if I didn’t have an existing Emacs user next to me in my – in those initial steps, I never would have gotten anywhere.
Avdi Grimm: There may be a new resource for that – for people in that – situation emerging soon and that’s all I’ll say about that. Michael Brodhead: Oh, excellent, excellent. Cool. Yeah, because it takes a little while with Emacs to sorta get over the hump where you know enough terms that you know the right questions to ask; that it’s got this great internal documentation –
Avdi Grimm: – Yes.
Michael Brodhead: – but if you don’t know that that’s called a buffer instead of a file, or –
Avdi Grimm: Exactly, yeah, it’s very similar to dealing with the command line the first time. I mean, you know, you can find – you can use Apropos to find the man pages you need if you know what to feed into Apropos first.
Michael Brodhead: Yeah.
Avdi Grimm: Yeah.
Michael Brodhead: Although, the thing that I discovered with man pages though is that you can’t – you can’t read that stuff like we were taught to read in English class. I mean, we’re taught to read for complete comprehension, and if you’re not getting complete comprehension, slow down, and go a bit at a time or whatever. But you can’t read UNIX documentation that way because it’s so intertwined.
Avdi Grimm: Right.
Michael Brodhead: And I guess maybe even a lot of computer documentation – that you have to accept that, “There are portions of this I’m not gonna understand, and I’m gonna glean what I can from it, and let the rest wash over.”
Avdi Grimm: – Yeah, well, that’s another nice thing about Emacs is that it has the whole GNU philosophy of being packaged with info documentation, which usually take the form of actual books, you know, that proceed through more or less step-by-step. So, there really is some fantastic documentation for it and for the packages that come with it. And it’s – I do like the fact that it’s relatively explorable. Like, you know, if you happen to know a key, and you wanna know – if you wanna know related stuff that you could do – if you know a key binding that does something, and you wanna know related stuff about that, you can ask Emacs, “What are you doing when I press this key?” There’s a key binding to ask it, “What is this key bound to?” And –
Michael Brodhead: – I – yeah, Meta X describe key and Meta X where is, I find myself wanting in other editors; even though I’m not really an Emacs user any more, I still – yeah, that –
Avdi Grimm: Yeah, so, it tells you. You know, it tells you what it’s bound to and it gives you the documentation for that function right there. And then, you’ve got all these links to related information, and you can sorta start there, and keep pulling the thread until you find what you want.
Michael Brodhead: Yeah, or the sweater falls on the floor.
Avdi Grimm: Or – yeah.
Michael Brodhead: Are there any particular Emacs packages that Rubyists ought to be looking into?
Avdi Grimm: Rubyists specifically? Well, here; I’ll tell you this. This is the one question that I get most often about RubyTapas – is, “How do you insert the results of evaluations straight into the buffer like that?”
Michael Brodhead: Oh, yeah. I’ve been wondering that –
Avdi Grimm: And the answer is a program called XMP Filter, which is part of the R Code Tools Gem, and R Code Tools comes with an Emacs integration where you can bind a – you know, and I just bound the Ctrl+C, Ctrl+C press to the XMP Filter command, and it runs the buffer through XMP Filter and, you know, replaces it with the output. XMP Filter is as – actually, a really well-developed piece of software that will insert results of evaluation. It’ll insert the standard output. It’ll – as a comment, it’ll insert warnings that Ruby comes up with as comments on the lines that they pertain to. It’s pretty darn cool.
Michael Brodhead: It looks like – is XMPFilter all run together without spaces?
Avdi Grimm: Yeah, it’s – yeah, but the Gem is called R Code Tools.
Michael Brodhead: R Code Tools, oh, there it is. Okay, cool. That looks interesting.
Avdi Grimm: It’s been around for a long time.
Michael Brodhead: So, when there is no Emacs available to you, what is your Plan B?
Avdi Grimm: That question does not compute.
Michael Brodhead: All right, next!
Avdi Grimm: No, I – you know, I try to maintain a very, very – I’ve always tried to maintain a very basic working knowledge of Vim because that’s the thing that’s always – you’ll always find that on the server.
Michael Brodhead: Yeah.
Avdi Grimm: Every programmer should know their way around at least a little bit.
Michael Brodhead: Well, back in the day, I knew just enough VI to get Emacs to build, and then, the GNU auto comp tools got pretty good, and no longer needed that.
Avdi Grimm: I will say that I do have a RubyMine license and I do use it from time to time, particularly larger projects when I’m doing a lot of refactoring. You know, it’s – RubyMine has excellent code navigation. It doesn’t – and it rebuilds automatically, unlike, you know, C-tags, which you might have to rebuild manually. And so, it’s – it makes it easy to sorta navigate around the new code base, and figure out where things are, and it also takes a lot – not all the pain, but a lot – of the pain out of refactorings like renaming things or moving things around.
Michael Brodhead: And it’s basically – even though there are a lot of things about it that I find frustrating, having the navigation – especially the automated refactorings – was amazing. But yeah, I’ve been skeptical of how much of that you could do in a dynamic language without –
Avdi Grimm: – Yeah, there are limits. I mean, it’s as smart as it can be, but, you know, there are pretty big limits on what you can do with static analysis in a dynamic language because the information just isn’t there.
Michael Brodhead: Yeah.
Avdi Grimm: And, yeah, it’d be interesting to see if somebody ever manages to come up with an environment along the lines of the Smalltalk IEE for Ruby where it’s all just manipulating the live VM in memory. But I haven’t seen – nobody has managed to pull that off yet. Oh, I will say the other thing about RubyMine that I do use it for sometimes is debugging. As a rule, I do not trust debuggers and I try to avoid them, but occasionally, they’re useful. And, if I have to do some debugging in Ruby, RubyMine makes it a little bit less painful.
Michael Brodhead: Cool. Yeah, I’ve been meaning to give that a whirl, but haven’t yet. So, one of the criticisms that Emacs gets a lot is that it’s really resource-intensive, and you can get some idea of my age when I say that Emacs was – I was told that it stands for Eight Megs And Constantly Swapping.
Avdi Grimm: Yes! Yes. Thank you. I was trying to remember that one, yeah.
Michael Brodhead: So, I’ve got this shiny new Raspberry Pi, which – I don't know if you’re familiar with it – but it’s a $35.00 computer, really resource-constrained. Is Emacs gonna be acceptable on there? Well, I shouldn’t even admit this, but I’ve been using Pico.
Avdi Grimm: You know, actually, I don’t see why not. Like I’ve watched somebody use a full, graphical desktop environment on a Raspberry Pi, which – you know, the funny thing about Emacs – you know, the rumors of its resource-hogging nature – they’re very true for certain values of resource-hogging. I mean, you know, by 20-year-old standards, it’s a monster, but it’s funny looking at it in my memory – in a HTop display compared to, say, RubyMine. You know? And it’s like this tiny, little 60 mgs of memory, whereas RubyMine is eating like 500 mgs of memory.
You know, I don't know. Like I actually – Chrome is usually using way, way more memory on my machine than Emacs ever is; you know, or any browser. So, it’s – I think it’s one of those that it depends on your definition of lots of resources.
Michael Brodhead: Or that might have been true 20 years ago, but not necessarily so true today.
Avdi Grimm: – Yeah, I mean, it’s way, way, way – it’s gonna use way more memory than Vim, certainly, but it’s probably gonna use way, way less memory than a lot of other programs that you use all the time now.
Michael Brodhead: Well, it’ll use less of my memory than Vim because I don’t have to have that modal thing in my head.
Avdi Grimm: Yeah, I mean, and it depends on how many – a lot of it depends on how many – extensions you have loaded as well. I mean, if you’re not loading up dozens and dozens of extensions, then, you know, it’s not gonna be as big a deal.
Michael Brodhead: So, do you use RMail?
Avdi Grimm: I do not. I regularly – for my entire Emacs-using career, I have regularly – tried to transfer my e-mail workflow over to Emacs and it has never stuck. These days, a lot of the stuff in Gmail is so nice that I’m not sure if I could get it to stick now.
Michael Brodhead: Yeah, I was using MHE, which is an Emacs front-end, to, well, MH. But then, MH wasn’t really being maintained and, eventually, I just –
Avdi Grimm: – Right.
Michael Brodhead: – had to abandon it. So –
Avdi Grimm: There is – I mean, there is one thing that I’ve been looking at lately, which is something called NotMuch, which as Emacs front-end. It has some interesting like super-fast search capabilities and stuff like that.
Michael Brodhead: Hmm.
Avdi Grimm: But, you know, it’s just – it’s one of those things that there are so many conveniences in Gmail, you know, like “Undo Send,” if you – if – what is it? Like 30 seconds – a 30-second buffer between when it sends – when you send and when it actually sends. You know, there’s just so many little things.
Michael Brodhead: – Somebody was talking to me about a drunk mode for e-mail where you have to – you have to jump through some elaborate hurdle to get it to actually –
Avdi Grimm: – Oh, yeah! I think they have that in the labs or something where it like detects – it detects if you’re basically misspelling everything or something. Or, you know, for all I know, Google knows so much about you at this point that it’s probably – it probably detects if you’re sending an e-mail, you know, to your ex-girlfriend.
Michael Brodhead: Yeah. It probably does. I actually was blown away the other day that I typed – I needed to nice some processes down, and I forgot whether you go positive or negative numbers, and I typed man nice into Google, and I didn’t even appreciate, until afterwards, that it was remarkable that it gave me UNIX manual pages and not things about pleasant males.
Avdi Grimm: Nice. I’ll have to try that.
Michael Brodhead: Yeah. So, what’s – what’s in the pipeline? What’s next? What’s next from Avdi Grimm?
Avdi Grimm: Well, I am still working on my next book, Confident Ruby, which also evolved – like Exceptional Ruby, also evolved from a talk; evolving into something along the lines of like a patterns catalogue of stuff to apply at the method level to make your code more expressive and more sure of itself. And that kinda took a backseat to RubyTapas as I was getting RubyTapas off the ground, but now, I’m starting to write new chapters again. And so, at some point – I don’t wanna say when any more because I tried the whole deadline thing with that, and, you know, it whooshing by. But, at some point, I will be completing that. And, at that point, I have several other book ideas; I’ve got a long list of book ideas. I just have to figure out which one I wanna work on next. And I also have some other video projects in the works.
Michael Brodhead: Excellent. Cool. Well, I, for one, am looking forward to them. Oh! Yeah, a question I should ask about Confident Ruby, but to ask this question, I have to admit to not having seen the talk yet. Although it’s on my queue of 45-minute videos, is it aimed at intermediate Rubyists? Beginning Rubyists?
Avdi Grimm: Probably more intermediate I’d say. I mean, I think anybody – if you know the language, then you’ll probably get something from it. But there’s – you know, it’s less about, “Here is how you do things in Ruby,” and it’s more about, “Here is how you might be doing things in Ruby,” and, “Here is the trouble you might be getting into,” and, “Here is an alternative.” So, I think it’s probably a little bit more oriented towards people that have felt the pain from coding for a little while, and, you know, from some of the anti-patterns that I go over.
Michael Brodhead: Cool. Well, this has been great, Avdi. I have enjoyed talking with you and – cool. Yeah, thank you very much for doing this.
Avdi Grimm: Hey, thank you.
Michael Brodhead: All right, have a good one!
Avdi Grimm: You, too.
