Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets.

miyagawa: ゲストがひとり加わりまして、ここから英語でやりますたぶん、ほとんどね。

matz: Zak 日本語しゃべれるからだいじょうぶだよ。

zzak: アー、ニホンゴデシャベリマセン。

miyagawa: (laughs) しゃべらないの？

(laughs)

matz: Why not? (laughs)

zzak: アー、フツカヨイ デス。。。

miyagawa: ふつかよい (laughs)

matz: そっち何時だっけ？4時…5時とかだよね？夕方の？

miyagawa: 6時。

matz: 6時か。

miyagawa: It's almost six.

miyagawa: So, we have another guest, Zak, can you introduce yourself a little bit?

zzak: Sure. I'm Zak, I'm on Ruby core with Matz, and also a committer to Ruby on Rails, and Sinatra, and I work for a company called Shutterfly, I work on their mobile API.

1:06

miyagawa: And you moved from Vermont to San Francisco, so we hang out a lot lately.

zzak: Yah, when we are both in the same region.

miyagawa: Exactly.

(laughs)

zzak: Whether or not it's in San Francisco, or whereever, it doesn't really matter.

miyagawa: Exactly.

miyagawa: So, in the main segment, I think we talked a little bit about upcoming Ruby, I think Zak, you are a little more involved than I am, so maybe you can discuss some of the things you are excited about, for Ruby 2.2, with Matz maybe.

zzak: Sure. I heard you guys going over some of the garbage collection stuff, but there are some new methods I was kind of interested in talking about..

matz: You mean "super_method"?

zzak: Exactly.

matz: Ah-huh!

(laughs)

zzak: ... and itself.

matz: Ah, itself, yah.

miyagawa: Can you explain a little bit?

zzak: Okay, so, the first one Matz mentioned is, "super_method" is a new method on Method.. class.

miyagawa: Okay.

zzak: ... and, what it does is, it returns the calling method if there is a superclass with a method with the same name. So if you are subclassing and you have a method that is redefined in the subclass, if you call the "super_method" it will return the method from the superclass. So that was recently added, last week.

matz: How do you use it?

zzak: How do I say it?

matz: How do you use it?

zzak: I guess, if you have a class and it inherits so you have a base class, and you want to know where this method comes from, you can use "super_method" and find out. It's kind of like a debugging analysis method, in my eyes. I don't know if you would use it for any other reason.

matz: I accepted that mostly because of the the debugging reason. Maybe we can use it for something very weird. If I see that I would be very excited.

zzak: You like seeing people use Ruby in weird ways?

matz: Yeah, of course, Ruby is there to be abused.

miyagawa: Abused! (laughs)

matz: 私は自分のソフトウェアが思ってもみない使われ方をするのを見るのがすごい好きなので。

miyagawa: Matz is really excited about Ruby being abused in a very creative way.

matz: Of course!

zzak: Such as flip-flops?

(laughs)

matz: No way! I'm going to remove that.

zzak: What do you mean?

matz: Yeah, remove it, I think in the future, like, [in] Ruby 3.0.

zzak: We should just have experimental Ruby implementation, where we let all that stuff go.

miyagawa: What do you mean by flip-flop, is it .. (dot-dot) operation?

matz: Yeah, Ruby has a flip-flop operation with a range operator, just like Perl.

miyagawa: Yeah, that's what I was bout to mention. I think that that's a heritage from Perl..

matz: Yeah, and I regret that.

miyagawa: (laughs) ... what other features do you regret, about inheriting from Perl?

matz: Ah, the most variables are inherited from Perl, like $:, $, or something like that.

miyagawa: Do you have all of them?

matz: Most of them. I don't think we have offset moving variable like $[ or something.

miyagawa: Yeah, it is really weird... global variables in Perl like $, ...

matz: Yah, we do have.

miyagawa: Okay, you have it. (laughs)

zzak: How do you tell the difference between a global variable, and like this Scalar type? I feel like that would get confusing, because you don't see the global variable syntax often, unless it's a language feature in Ruby, but you can implement stuff like that at your disposal... if you want to do really weird stuff, I guess.

matz: You mean, C-wise?

zzak: No, it is in Ruby, just in plain Ruby.

matz: Uh... I don't recommend that, but you can declare the global variable by hooks, like setting hooks and getting hooks, so that you can define that kind of special global variables.

miyagawa: I see.

matz: But I would recommend it.

zzak: You do recommend it?

matz: I Don't.

zzak: ... specially in production.

(laughs)

zzak: I heard Cookpad was all global variables!

(laughs)

zzak: They wanted to be a global scope, and take their product internationally, so they use global variables.

miyagawa: OMG!

matz: That's a catch!

miyagawa: That's a great title for this episode.

matz: "Because we are global."

miyagawa: Exactly.

miyagawa: What about the other method? Object#itself?

zzak: Yeah, so I actually I tweeted this out the other day, and I made a mistake. So I thought it was going to be... I thought the feature was approved for 2.2, but I guess it's technically just an experimental feature where any object can use itself, call the instant method itself to return object in question.

I'm not really sure why this is useful, or... like Rails implemented it for whatever reason, and then you got it approved and merged for somewhere upstream but, don't know why. Not really.

miyagawa: I saw the original commit, I think it was by DHH?

zzak: Yeah.

miyagawa: It was like, def self; return self; end, basically.

zzak: Right. Like public #self or something.

8:05

miyagawa: Right.

matz: Yeah.

miyagawa: So basically you get an object and call .itself on it to get itself?

matz: Get itself, yah. Right.

zzak: Just in case you didn't have the object before, which...

miyagawa: What's the point of it?

zzak: Yeah, I have no idea when would that happen.

(laughs)

matz: Mostly, it's used as a block, so &:itself can return itself.

miyagawa: Oh, like Symbol#to_proc?

matz: Uh-huh.

miyagawa: So you don't need to write a block, instead &:itself.

matz: Yeah.

miyagawa: ... okay. (laughs)

matz: I think that's the primary usage.

zzak: ... who does that??

(laughs)

miyagawa: Some Rails people.

(laughs)

zzak: But, it seems to be like, a bunch of... like, if you search github, just like the code search, a bunch of people are using itself already in there objects, and redefining it. So I feel like it's kind of a compatibility issue.

miyagawa: You mean, it's going to break that code if Ruby itself had it?

zzak: Well, I don't think it technically will, because they are just redefining it, right? So, whatever the scope is, in itself, that's what you get. But, if you are not expecting it I feel...

miyagawa: Yeeh, if there is a code that expects itself to return self, and if there is a code that redefines itself it's going to be a problem.

zzak: Yeah.

(09:50)

miyagawa: So, I'm really interested in some of the directions Ruby is going with standard library. I see that some of the standard library is getting unbundled from Ruby, and released as a separate gem. Like, I saw the test-unit, and minitest the other day. Is this going to be the trend? What do you think?

matz: For the first step, we are going to make some standard libraries into gems, so they are going to be a bundled gem. So you can replace them by installing the newer gem from rubygems.org. So that would reduce the burden of maintenance versions.

miyagawa: Yeah, I think it doesn't make much sense to fix the security problem like net/http by upgrading Ruby, so I think it's useful if a standard library is available as a separate gem.

matz: So, the gemifying... some of the standard library is in the plan, but I'm not sure about the timeframe though.

miyagawa: You mean like, not everything for 2.2?

matz: Yeah. The basic idea came in the process of defining 2.0, but it did not happen then. So, I don't know, maybe 2.2 and 2.3?

miyagawa: Zak, what do you think?

zzak: Well, if we are talking about actually removing gems, we need some gems still, in order to run the tests, and build stuff. So in the past what we have done is turn gems into gems, and then just import them when we were ready to release. So, it's kind of a manual process. But the way the bundled gems would work is, at make snapshot time, so when you are ready to make a tarball for release, it will download the gem versions that you specify, in this case so far we have test-unit, and minitest, and it will download them and just package them in the source.

12:45

miyagawa: So you are going to still ship Ruby with those gems, but maintain them as a separate third party library.

zzak: Right. So as far as those two gems are concerned.. test-unit 3.0 is just released, and we are bundling 2.5, but if you wanted to update, all you have to do is gem install. Also with minitest we have 5.3, version that comes with Ruby, if you install. I don't see why we can't move more gems to this format, they already have external locations, like Psych etc. It depends on how much we need them.

matz: Yeah.

miyagawa: What is the burden right now to process those ideas?

matz: We core team focus on the core, but from outside, the Ruby is Ruby including those standard libraries which we may or may not be maintaining then. They often blame us about the standard library, the quality of standard library. By gemifying, we can delegate these kind of complaints to other guys.

zzak: Yaeh, I think it has been successful for the gems, the gems we have moved to the standard gems, have been successful, as far as what I have seen rubygems was one of the first, and then there were few others, they are on github and they have pull requests and they are managed independently but when it comes time to release, we just import it and make sure all the tests pass, with Ruby.

So that's an important part of, moving forward is, getting that traction and doing it in kind of a case by case basis. Whether we take a gem and whether or not we determine how much we rely on it, and determine the requirements necessary to make this an actual gem, for instance some of the native extensions we have, they need to be compiled at install time. Certain tools need to be installed in order to do that, and that might be another extend of library gem, or something along those lines. We need to determine on a case by case, what is required.

miyagawa: Yep. I think it's interesting that Matz thinks Ruby as Ruby including all these standard library, so Ruby should be available with batteries included. It's kind of quite opposite to Perl, based on my personal experience. Perl development team has been pushing really hard to remove standard library from Perl, to delegate these issues and reduce the maintenance load. All they have is like an ability to install a module from CPAN, so there is like HTTP client in pure Perl, and JSON parser, Tarball unpacker and things like that in Perl, but everything else should be pulled from CPAN, or in the case of Ruby, rubygems, that's the different philosophy.

16:41

zzak: Yeah, I think our philosophy is right.

miyagawa: (laughs) Yah, I think there's benefit - advantages and disadvantages I think.

zzak: Yah, there's pros and cons, but I think having the ability to delegate some of that stuff, having maintainers outside of the core team helps a lot.

miyagawa: Cool.

(17:09)

miyagawa: So, Zak is known to be everywhere... just like you've mentioned earlier, now we live in the same city, but the dates we both were in the same city is really limited because we travel a lot. So Zak, what is the next conference for you?

zzak: Actually, I don't have anything until Kaigi.

miyagawa: RubyKaigi?

zzak: Yah, I'm pretty excited.

miyagawa: Which is September 18-20, I think?

zzak: Yah.

miyagawa: Yah, I'm conflicted, I really want to go but I have to go to Japan later this month and then don't want to stay there three weeks in the summer, it's a little bit too much, and go back and forth as well. But I really want to go.

zzak: You have to!

miyagawa: (laughs) Okay, I have to!

(laughs)

miyagawa: So, how many conferences have you been to this year, Zak?

zzak: I kind of lost count, to be honest, but the last one I did was really fun, and definitely took a lot of energy out of me so...

matz: Which one?

zzak: The end of July I went to Brighton Ruby Conference, in England.

matz: So you played the JEDI in that conference?

zzak: Yah, I played the role of JEDI, a Ruby master... no no no, I'm not a master, I'm only a knight, knight in training... but I did have Padawan.

miyagawa: Is Matz the Ruby master?

zzak: Well, he's the grand master.

matz: I'm a Yoda!

zzak: Yah, Matz is Yoda.

zzak: So, my co-speaker was Terence Lee from Heroku, and we heard about this conference months back, actually it was during Oedo Kaigi, in April. We had this idea that Matz is so much like Yoda that we have to give a topic.

(laughs)

matz: I'm so much like Yoda...!! That sounds so funny!

zzak: So yeah, he knew someone that can make costumes, and she made us a really nicely done JEDI cos-play.

matz: Oooooh.

miyagawa: Yeah, I saw the picture of it and it was really nice.

zzak: Yeah, once I saw that I was like wow, we have to do this! ... And we have to do it right, because I'm not wearing that thing.

miyagawa: Did you wear it outside the conference as well?

zzak: I wore everything but the heavy heavy robe outside in the sun, Terence wore the robe all day. Just crazy. It was really hot... it must have been 25~27 in the sun. Centigrade.

miyagawa: Nice.

zzak: Between the costumes and everything and even just putting together a talk with more than one speaker, is a lot of work.

miyagawa: I can imagine that. Plus, you tend to write all your slides by hand?

zzak: Yah, so what we did was... I drew all of the middle slides, and like the outro credit section, and we put together a intro video that had some drawing and some animation, and audio engineering by Terence - Beats by Terence.

miyagawa: (laughs) That's a lot of preparation. Are you going to do the same in Kaigi?

zzak: (laughs) I don't know if I'll bring the costume. It's kind of far. We'll see. I am going to talk about, at Kaigi, I'm planning to talk about Ruby ecosystem, gem management, open source, that kind of stuff.

miyagawa: That's going to be fun.

matz: Are you going to talk about Nobu?

zzak: No, not at Kaigi. Everyone knows Nobu at Ruby Kaigi.

miyagawa: Well relatively. Compared to the conference elsewhere.

zzak: My goal is to give that talk at RubyConf this year in November.

miyagawa: In San Diego?

zzak: Yeah, the Nobu talk. So, for anyone not following, I gave a talk at Oedo Kaigi, there is a regional Ruby Conference in Japan, in April, and I gave a talk about Nobuyoshi Nakada, who is like the biggest committer to Ruby, has like over 10,000 commits, well beyond twice as much as the person who is in the second place.

miyagawa: Is Matz the second?

matz: No, I don't know, I'm forty-seventh or something.

zzak: Matz get to one commit a year, and that's to change the version file, when we release.

matz: Yeah, for those years.

miyagawa: Bumping the version number?

matz: Yeah, I'm kind of retired from development of CRuby.

miyagawa: Are you?

matz: Yeah, Nobu is so great, I delegate the work.

miyagawa: Delegation is such an important task for the inventor of the programming language.

matz: I'm still working on mruby though, ...as a programmer I'm kind of retired.

miyagawa: No you're not. (laughs)

zzak: You're not sixty yet, Matz. (laughs) You have a couple of more years to go till you can retire.

miyagawa: After you finish your editor.

matz: Oh yeah. (laughs) ... It's about time to start my own editor.

zzak: You are going to replace Emacs?

miyagawa: Yeah, that's exactly what we have talked.

matz: Yah.

zzak: Did you decide on the name? If not I have a recommendation... Ematz.

(laughs)

miyagawa: That's so cool.

matz: Maybe I'll name it Ginger.

miyagawa: Ginger is... for those who don't know, Ginger is the name of the cat of Zak.

zzak: He's like, sleeping on his back underneath the coffee table right now.

miyagawa: He has a twitter account?

zzak: He does! This is new, so the twitter handle is: @gingypurrs

miyagawa: I'll put the link in the show notes.

(laughs)

zzak: I think Matz retweeted him last week. It's kind of funny.

miyagawa: Cool.

zzak: But I still need to get a follow from Matz. You got to follow @gingypurrs to make it official.

matz: Uh, let me see...

(laughs, Matz trying to find @gingypurrs)

zzak: This is how you get things done in Ruby, because Matz is so nice.

miyagawa: Matz is so nice.

zzak: Uh-huh.

matz: Thank you for saying so!

miyagawa: So, MINSWAN. So we are nice.

zzak: So, are you going to... are you going back to Japan at the end of this month, Miyagawa?

miyagawa: Yeah, I think so, there is a conference, YAPC, Yet another Perl Conference, I want to attend that, and I really want to attend RubyKaigi as well, so I need to think about whether I'm going to stay, or whether I'm coming back and forth.

zzak: There's also that Taiwan conference.

miyagawa: Yeah, RailsPacific. I love Taiwan, so, that's going to be interesting.

zzak: I saw Hiroshi Shibata is going to speak at RailsPacific in Taipei. When we talk about all the gemification stuff, he has been a major part of pushing that forward. Definitely give @hsbt a shot out.

miyagawa: Yes, I will link to that. His talk, as well.

miyagawa: Okay, cool. Zak and Matz, Thanks for your time, it has been a great show. Let's do it soon again.

zzak: Yeah, maybe at RubyKaigi we'll see you.

miyagawa: Yep. Definitely.

---

Transcribed by May Horimoto