CHUCK:
Hey everybody and welcome back to the Ruby Rogues podcast. We have a few panelists who couldn’t make it today, either due to car trouble or travel and work. David Brady is going to try and join us here momentarily. But in the meantime, we have Gregory Brown from Ruby Mendicant University. He’s the developer of the Prawn library and several others. He’s the author of Ruby Best Practices and he blogs at magesticseacreature.com. Welcome, Greg.
GREGORY:
Thank you.
CHUCK:
And then we have James Edward Gray from Gray Productions. He wrote the Textmate book and has built some awesome stuff, including the FasterCSV library and we're always happy to have James on the podcast.
JAMES:
[inaudible] would keep me away.
CHUCK:
[Chuckles] And I'm Charles Max Wood from teachmetocode.com and we're going to be talking today about the Ruby Gems discussion that’s going on. We're going to be talking about more than just the opinions involved. We're going to be talking about some of the concepts that surround some of the things that people are discussing and you know, kind of share what our thoughts are on some of these things. So, I just wanna welcome our panel one more time and we'll go ahead and get started.
JAMES:
Great. Greg, you probably know more than anybody what else has been going on with Ruby gems.
Can you give us the tour of the recent kerfuffle.
GREGORY:
Yeah, I mean I'm gradually learning about it, but like two weeks ago, I knew absolutely nothing about it, which I thought that would make me a good person to sort of mediate the situation, get some of these tensions to go down a little bit. It turns out that I wasn’t necessarily right about that. Basically, there were a number of different things that have been going on; one is that Ruby Gems have been sort of rapidly changing since version 1.4, but without a well-established release policy. So the communications with community weren’t really that great and things broke as a result of it. And some of the stuff was things that broke because of patches and other library; some things were things that was happening in Ruby gems. But whatever it was, the communication wasn’t good and things were breaking, affecting end users on a pretty serious way. And then to sort of throw gas on the fire, the Ruby Gems 1.8 release had a tremendous amount of warnings -deprecation warnings – because they are trying to get rid of some of the old cruft. But it turns out that cruft just is still used by a lot of things. With a little bit of prodding and pushing, they actually removed two of the warnings that are causing almost all of the problems for people in Ruby Gems
1.8.4 and 1.8.5, but before they did that, people were going crazy because they would run, like they’d open IRB or they would run just a Ruby script and it would just help print pages of warnings that didn’t respect verbose, so they basically would just make it very hard to see the output of things. That’s pretty much been solved. People are still sort of stressed out about the release policies; I've made some progress with those guys on that stuff, but in the process, this is sort of too little too late because Ruby Gems has been officially forked as of yesterday by Slim Gems, which is at Loren Segal’s and whatever progress have been made for the last week or so has made some improvements, but also this has sort of refan the flames and now were in a big mess again.
CHUCK:
All right.
GREGORY:
So I´ll put in the executive summary, even though it’s not that short.
CHUCK:
Right. That kind of gives us an idea. And I also wanna welcome David Brady to the call. He just jumped in.
DAVID:
Howdy.
JAMES:
Talk about commitment; he came directly from the hospital for this.
DAVID:
I don’t know if this is more commitment or less, I'm actually fine. My wife had surgery this morning on her eye and I am the caretaker and baby sitter, and I was making sure she had enough drugs and enough Netflix easily within reach of her location where she’s convalescing.
JAMES:
And he means totally legal drugs and totally legal Netflix movies.
CHUCK:
[Chuckles]
DAVID:
Actually, I do on both counts. We've got a prescription and a subscription, as the case may be.
CHUCK:
Oh man, I thought I knew you better than that, David.
DAVID:
Yeah, well, you know. So I lie about a lot of things just to keep my street cred up.
JAMES:
All right, so redirecting; Greg was just giving us the tour of what went wrong in Ruby gems.
DAVID:
I came in kind of on the end of that, and I think I heard enough of it to add my own two cents to this which was I love you Greg, I really, really respect what you are doing and I kind of predicted that this would happen because in a very angry society, the big revolution comes after the first concession. And you kind of represented the peace offering and first concession. And that’s when the revolutionaries realize, “Oh, we've got momentum; lets run with it!”
GREGORY:
But you know, the funny thing is that honestly, and I know now that I'm saying this it’s just making things worse, I don’t think that it’s that big of a revolution. I mean the things that I was talking about getting the problems fixed, those would stay on top of Hacker News for like 2 days at a time. And the Slim Gems stuff basically on Reddit just went up there and then disappeared pretty quickly. And on hacker news was up there for half a day, got a lot of commentary and is now gone as well from front page. And I don’t wanna say that it’s like a small amount of people because that would be unfair, but it is a minority people who have been really loud about this stuff. And I just think right now that Slim Gems is causing more confusion than it’s helping with anything. And I don’t know that it’s a revolution. Just from all the people I've talked to, I just haven’t seen people seriously in favor of that.
DAVID:
Yeah, I think you are right. I think revolution is kind of the wrong…. I didn’t mean to put that word. I just went with that pattern seems to be playing out. There's a quote that says that the best way to disenfranchise a man of the political system is to have his candidate get elected. And for all the people that are very, very angry about Ruby Gems, maybe I don’t know but it’s a subset who will then agree or believe that Slim Gems is the right answer. And so, it’s a subset of a subset of a subset.
GREGORY:
Yeah, I mean part of it also is like I've been working with Loren. When I first got involved, the first thing that I did was I spent an hour on a private Skype call with him and make him talk about some of these issues. And I focused on that because there's two things going on here; there's the things that everybody cares about, like those deprecation warnings or things just breaking. And then there's like the philosophical issue of the API backwards compatibility and release standards and all that stuff. Those things were very important but they weren’t urgent at that moment but at the same time like it was really important for me to engage with Loren and I've been doing that more or less. Before I got on this call, we were talking to him about where Evan Phoenix have the idea of introducing a compatibility layer as a gem that would basically guarantee a backwards compatibility across all Ruby Gems version from 1.3.7 and up. Someone tweeted to me yesterday, oh you are not on speaking terms with Loren. The funny thing is that I am and I've been working with him throughout this.
DAVID:
Loren is a really nice guy. I mean, I can see him being really, really angry and really, really wound up but yeah, he's a reasonable person. He's a nice guy.
GREGORY:
Well, I mean, reasonable or not, the point that I'm trying to make is that everybody just calling for blood, when it comes to Ruby Gems is not actually actively working on the problem as far as…
DAVID:
Yeah, they are not helping.
No one who is actively working on the problem has closed out communications or anything like that. So that’s why it’s really surprising to me you get this fork out there and people are so excited because they think they are being released for some sort of tyranny. And then if you'd go and just sit on a Ruby Gems IRC channel or pretty much anywhere else where it is being seriously discussed, you can see that people are still trying to work this out. And so I just find that to be a bit more of a distraction than anything, at this point. I think the main problem right now is that there is not enough reasonable information for someone who doesn’t wanna dedicate a week of their time to this or more, to make an informed decision. I don’t know that there's enough that I can make an informed decision.
JAMES:
Yeah, I kind of agree with that. So when I saw all the Ruby Gems stuff going down this week, I basically just started reading to see what was going on and I went back and read Ryan’s blog post that was the original kick off to Ruby Gems 1.8.x and went through that and it went through several blog post. And then after that, I read the current Ruby Gems source just to get kind of feel of the state of everything and I'm like, “Oh, I´ll just spend a little time and see what I can learn here.” And then like a day later, I'm like, “Oh wow I blew a day just trying to figure out what all this is about.” And I definitely don’t understand all of it because I haven’t read like the old releases of Ruby versions or Ruby Gems which is one of the arguing points. But kind of getting back to it, I mean we definitely talked about the conflicts and stuff which are interesting. But I think they are actually kind of interesting technical problems that I kind of like to discus. So Greg mentioned that what basically drew his attention, Ruby Gems has been going through a very rapid growth period. So he's been making a bunch of releases about like every month or so maybe since January. So they’ve been going through this really big gross period and I think for the most part, people didn’t really notice, and then what brought the attention was in Ruby Gems 1.8, they deprecated a lot of stuff and so it started putting a massive amount of warnings and that’s worked out everybody’s attention. Well, this is kind of interesting, because I was thinking about this and I was like, you know I've definitely seen that kind of behavior in like say, Perl before when you would call deprecated stuff and people don’t seem to mind it that much there and that’s the thinking about it, but rubyists are so used to using IRB and when you fire that IRB, it just scrolls pages and pages of crap, and you can't… [silence]
CHUCK:
Oh, I think the call dropped.
JAMES:
I think that makes it a bunch more obvious.
CHUCK:
Okay, hang on. There was a little glitch there.
DAVID:
Yeah, I lost James’s audio there for a second.
GREGORY:
Yeah, if you would repeat your last sentence James, that would probably…
JAMES:
Okay. Sorry about the break there but what I was saying was that we’re so used to working interactively in IRB, that the deprecations, I think they hurt us more than they hurt people who develop in different ways because they fire up IRB and it scrolls five pages of crap while you are trying to get to a problem just so you can play this in code. I think that maybe that means that we have to think through our deprecations a little bit differently in the Ruby community.
CHUCK:
Yeah. I also wanna jump in here and just kind of wonder aloud, I guess. At what point the deprecations are really problem. I've seen deprecation warnings in Rails and some of these other libraries when I run my server and things, and it doesn’t seem to be as big a deal. And you know, ultimately what it means is upgrade your library, idiot. And so, in this case it was a little bit different I think because the use in Ruby Gems is different. And I'm really curious as to… I think James highlighted one of the differences and that is that people are waiting interactively in the same place that they are getting these deprecation warnings where in my case, when I'm running a web server, it just kind of scrolls up with the rest of the logging and so I'm curious though if there are any other things about Ruby Gems that make it different in this way, such that the deprecation warnings are more of a problem than they would be in some library that you’re just including in your code.
GREGORY:
They are. I mean, it is very much different because for one, the warnings that you are seeing in Ruby Gems there's not a whole lot that you can do about it. If you run gem pristine, it will try to clean up and rebuild your gems. But that doesn’t work safely with extensions, unless you know that those extension don’t have any extra build flags.
DAVID:
What is gem pristine?
GREGORY:
Basically what it does is it will rebuild the Gems based on the new specifications. So I actually, I don’t know the details of that except for that was a recommended solution for getting rid of these warnings, because what it would do is it would remove the deprecated stuff from the gem specs that were being built and then it will leave you alone after that. But the thing is that these warnings, so they deprecated a whole bunch of stuff; a ton of stuff, but the two warnings, the default executable and rdoc were responsible for almost a hundred percent of usual use of Ruby gems. So, whenever those two warnings. At this point, like I've been begging people to tell me if it’s not silent for them anymore, and a lot of people are telling me that it is silent. So I don’t think that we have that problem anymore. It was just those two warnings that was really, really noisy and affected every gem. The reason for that is because things like jeweler and some other like gem building tools, we’re putting those into the gem specs by default, which means that a whole lot of Gems who aren’t necessarily been using that stuff were affected by it.
DAVID:
Well that’s really just a mainstream amplification of the real problem which is that as a developer, I got this third party library that was built with this deprecated stuff and I've upgraded Ruby Gems and now I'm getting this warning, and I don’t actually have control over other piece of code. So I've got warning that I can't make go away.
JAMES:
Right.
DAVID:
Does that make sense?
As long as you are passing it to users and the expectation was that are plenty of Gems out there that are not actively maintained, so if you just put the warnings on the build side, if they don’t build a new gem, then they would never know about it.
JAMES:
Right. Ruby Gems experience is quite a bit of pain due to their depth and that makes total sense when you remember that Ruby Gems was developed at a Ruby conferences, like a hack fest project originally and it is grown from there and changed many, many times, including gaining its most recent maintainer in like January of this year. So it’s definitely been passed on many hands and they have a lot of technical depth from where it came from. So it’s totally understandable how it got crufty in some places.
DAVID:
I also wanna give kudos to the guys that have developed it all along and the guys that have been maintaining it now, because rather than looking what we've got and say, “Oh my gosh, what a huge lack of foresight!” I just wanna go all the way back to that first conference and say what a triumph of YAGNI. Ruby Gems have become what it is because it solved such a huge pain point. Yeah, we did it very agile and very ball of mud and okay, its coming back to bite us and we need to figure that out.
GREGORY:
It is a tremendous amount of technical depth.
DAVID:
Yeah.
GREGORY:
There's no way that you could possibly overestimate what sort of depth you need pay down to get this to do right.
CHUCK:
I have two questions about this and one is did they actually move the deprecation or just the warning?
GREGORY:
As of right now, the deprecations have gone away, so that means that rdoc and default executable just basically stick around as no ops for another year or two.
CHUCK:
Okay. And then my other question is, if we have all these technical depth, I mean don’t we need to be deprecating some of these things or removing them, you know, getting rid of the cruft? I mean, even if it does change the API, and I guess this is another core issue in this discussion, is where is the balance between maintaining the same API that people are used to versus being able to move ahead and move forward, and turn this in to what we have actually really need now?
JAMES:
So I think that’s like an excellent point, Chuck. I don’t know about you guys but I've got an instant reaction that whenever I locate any piece of code I didn’t write, the very first thing that comes out of my mouth is, “Oh, that’s crap!” It’s just my lack of understanding of it. And the great irony of that is I always tell myself oh, I could rewrite that in like ten line. And then I sit down and try to do it; rewrite it in ten lines. And ones I'm in 400 lines in, I realize why it handles all these edge cases that I didn’t think of.
CHUCK:
You know some of the subtleties there.
JAMES:
Right. And I think to some extent, there is that reaction. And this is definitely a point that’s been debated heavily in the whole Ruby Gem SlimGems forum where is it possible that we can maintain old APIs, fix the under the hood stuff but still support the old interfaces. Even if they have to do it in a less optimal way, I think it’s still totally acceptable to document a method to say something like, “Calling this method is extremely slow, due to the blah, blah, blah. Please switch to this better solutions.”
GREGORY:
James, I think the problem is a lot deeper than that because it’s not just the surface level API that they are concerned about, it’s all the layers of Ruby Gems And the idea of using Ruby Gems is developer APIs something that’s relatively new, but it too was developed organically and not actually designed. So what that means is that, there's a lot of libraries that are either monkey patching or trying to use a developer API even though like a public API was never officially laid down for Ruby Gems. So when we say the old API is sort of looking at like, a few years of gradually, organically changing code without any explicit intent of saying, “This is the API that you should be using.”
CHUCK:
So basically, what you’re saying is in this case because there's no explicit public API, the entire library is the API.
JAMES:
That's exactly right. But have been treating it that way. So like, Bundler and things like that have done heavy monkey patching and it remains to be seen how much of that was total necessity and how much of that they could have really done with the APIs having known better how to get in there and get the data they were after. But I think it does point to the cause of that. But if you rip open Ruby Gems and replace some pieces, then you may very well break every single release and that we definitely seen that with Bundler. And I think there's other libraries that use it similarly. Actually, I think it was Loren who made an argument that you'd be surprised about the number of library out there that do use the gems API.
DAVID:
So I have a potentially a very stupid question. And if Greg, you already answered this little bit in the phone call, feel free to tell me to shut up. I'm going to play idiot for just a minute, because it comes naturally to me. Can you give an example of some of these Gems APIs, things that are not actually formal API. See, I'm just a client of gems. All I know about Ruby Gems is that they are some big ass repo hanging out their disk space up in the cloud on the interwebs, that I can get all these magical binaries from that make my computer go. And I assume there's a setup method, or compile method because some of my Gems do set ups and some of them do compile. There's nothing else in the API, as far as I'm concerned. So what are the other APIs that these other people are using. What are they hacking on. What are the things that they are trying to expose through plugins right now. Can you illustrate that?
I can talk to you about the problems that I investigated. I mean, I am very much just a consumer of Ruby gems until today, where I actually started hacking on it.
JAMES:
I can give a very concrete example. So for example, when you just do a require after Ruby Gems has been loaded, then it goes through its process and activates the gem that that requires. In most cases, currently that’s going to activate the most recent copy of that gem for your needs, right? So Bundler for example, when it’s activating things, it does a much more complicated problem to solve because it’s trying to activate everything as a set, and it’s trying to make sure that if this library requires Gem between version one and three, this other library requires that same gem at version two, if you go ahead and activate the most recent one version three, then you screw that other library out of its require, right? So Bundler solves that problem; it figures out, we'll be okay as long as we activate version two, because that will meet both of the requirements.
DAVID:
And Bundler is smart enough to do that?
JAMES:
That’s right. That’s what Bundler does.
DAVID:
Okay, that kicks ass.
GREGORY:
I can give another couple of examples along those lines because, I mean, part of what I've been trying to do is figure out what the breakage was or what the problems were and try and figure out whether it was like Ruby Gems not doing something right or if there's some changes that need to be made so that people can do things without monkey patching or whatever. But I mean, the issue that I feel at least in part set was that Yard was using has rdoc as a sort of indicator of whether or not Yard should be used. And he was basically using that flag which at this point in time is basically just a no op. It is ignored. And when they’re using that, he was thinking of removing it, but then that would make it so that you wouldn’t know whether or not it was okay to run Yard against it. And he was talking about one of three things is like, they either need the a system that allows you to push static documentation of like it’s own gem or they need to be able to run an executable post install to generate the documentation, and there was something else that I forgot, but these are the sort of things where they're making use of certain developer API that was actually there for a different reason. I mean has rdoc is there to tell you basically the option was you could set up the flaw so that you could say, “Oh, I'm lazy and I don’t do documentation.” It’s been repurposed for other things. And so the removal, it has a really effect on things that people use, even though it was being used in a way that it wasn’t intended to be used.
JAMES:
I would like to point out that a lot of these things are very complicated; for example Greg right there you said that you know maybe one option would be to run an executable post install. That's not a good idea.
GREGORY:
[inaudible] security concerns with that and all that stuff. And that’s why something that sounds simple has so much that you need to consider.
CHUCK:
Right. So I wanna jump in here and I'm going to kind of hijack Greg’s example for a second, because I don’t know that there's a clear cut answer to this and I want to get some opinions here, but with that has rdoc flag or setting, is that then yards problem or Ruby Gem’s problem? I know that there's not a clear answer to that. but I kind of wanna see what you guys think.
JAMES:
That’s a good question. I mean, has rdoc is a feature that gem did support at one time, so it doesn’t seem unrealistic that Loren was using that for that purposes. I mean, it seems like a correct usage to me. That said, I don’t think that Gems I mean, I don’t know... some people used it well and some people didn’t. And there is value to rdocing even code that doesn’t have a documentation, right? Rdoc at least runs through all the methods, puts the method on the webpage, gives you a link to the stores, blah, blah, blah. So there is value, I think in rdocing almost everything. Maybe there are some exceptions.
GREGORY:
I think that was the Ruby Gems party line which was that they were just going to enable it by default and remove the option so that it does give you those methods listening and things like that. But Loren’s counter point to that is that he wanted… he said some people really care about how their documentation looks and they don’t want rdoc to run if formatted to yard because they want it to look good and all that sort of stuff.
JAMES:
I guess I can see that point, but those people definitely have the adaption to make documentation look the way they want somewhere else and link to it or whatever. I don’t even know that Ruby Gems needs to be concerned with honoring contracts like that.
DAVID:
I don’t know James, to my mind, the underlying difficulty here is that we are moving from the one model to the end model, which is the has rdoc, what that really means is has doc; has any documentation. And rdoc was the way to document. Well now, there's two ways to document: you can rdoc or you can yardoc. And to cavalierly say, “Yeah, you took this time to document your stuff, but we are just going to fire up how we want to document your stuff,” that doesn’t seem right. Does that make sense?
JAMES:
Yeah, I guess…
GREGORY:
Especially because like there's actually some subtle differences between them. There's yard and there's also Rocco, which is based on docco, and that’s really, really cool. It’s like a literal programing where it shows the documentation, but then it also shows the code like side by side, so you can read the code while you are reading the documentation in line, which is really freaking cool. But that’s very different than what you would with rdoc. But I mean the whole this is that with this whole argument about that, that was actually very similar; they just went back and forth about practical points. That sort of ended in, “Oh you should the build the plugin.” And then Loren said, “Okay, I will.” And then he asked the question, “I need to be able to have my plugin disable other post process if they are present.” So he want to be able to have yard look for our rdoc and disable it if it was enable. Those are the sort of things where are like, that conversation sort of fell apart at that point because we never got answer and so people work around it.
JAMES:
So this is a great point I think. But I do think Ruby Gems thing has made some mistakes; one of them is there has been a long standing discussion about enhancements to Ruby Gems or even just like metadata in the gem spec, which is sort of kind of supported but not really. I think that would help solve one of these problems. I mean, if we had metadata in the Gems spec, then at least to David Brady’s point, you can throw in there and say hey, this is document and then I use yard to do it, you know? And then yard could work for that extra metadata and say, “Hey, these are my guys; I can handle them and things like that. And the Ruby Gems team has been a little reluctant to like officially support things like that or support a healthy plugin API, that these things. And I'm not saying that you know, being able to shut off other people’s stuff is not a good idea. But maybe I think there is a lesson here that if you don’t make an expandable API in the Ruby community, we do take it upon ourselves that we are free to monkey patch away. So not providing that API, you can do so at your peril.
GREGORY:
In my talks with them, I really stressed that point and they seem to really come around on it. It’s like, they have this plugin API but it’s not really something that’s specially well-advertised or specially well supported. Like you don’t get the feeling of oh, this is designed for you to be able to extend Ruby gems. It’s just sort of there, like it almost feels like a way that they were just using to extract things out at Ruby Gems instead of a consumer API. And I suggest they should change that and I more or less agree. But honestly, I think that that’s something that is going to take time because, I mean, I just think about systems that I've built and like one of reason I'm getting involved in this is because I went through the whole PDF writer and then versus prawn and sort of dealing with really complex systems that are hard to get off the ground and internals themselves are hard enough to get right, that thinking about how please get users are really, really hard. And I guess the point that I'm trying to make is that until Ruby Gems has solid internals or at least direction for what those internals are going to look like, it is very hard to decide how you are going to allow people to interact with the system for a developer API.
JAMES:
Right.
DAVID:
That’s wrong.
JAMES:
What do you mean?
DAVID:
That’s inside out development. That’s solving the problem in terms of what you already have to solve, right? Sorry, this is the most recent addcast just went up on Tuesday. Pat and I talked about this for about an hour; about you should start with what people want and then drive in. Ruby Gems is really late in the game and it’s also got a lot of technical depth, and so I'm being cavalier saying, “Oh you should do what the users want.”
GREGORY:
Oh well no I'm talking about seven years technical depth on a np complete problem. So for example, so I was the maintainer of PDF writer for a while and it was this similar situation in which the project was unmaintained for a while, people wanted stuff out of it, but I couldn’t add a single feature or fix a single bug without investing ten times the amount of time that I could possibly want. The point is that we are talking about a version 2.0 of Ruby Gems that was built ground up, then you should start with the problems that people have.
DAVID:
Yeah, that’s fair.
GREGORY:
Think about Ruby Gems more than two three years ago; there was no notion whatsoever that it should be extensible. There was no concept of plug ins or anything like that.
DAVID:
My very first Ruby gem was I had to go to the website and sign up and ask them to let me please have that gem.
GREGORY:
[Chuckles]
DAVID:
Remember that? When you have to go to the website and like asked Dave Thomas, “Can I please have this gem?”
JAMES:
[Chuckles] Right.
GREGORY:
So I guess what I'm trying to make, just to draw an analogy is go take a look at the source for PDF writer and then ask yourself if you wanna build the plugin system on top of that.
DAVID:
[Laughs] Yeah.
JAMES:
I think that's a good point but at the same time, I think David Brady does have the valid kind of angle on it in that, I think one of the issues with current Ruby Gems development is very much that it’s taken place in a bubble, and that it hasn’t been concerned with what people need out of it and stuff like that. So to give you an example, I think one of the problems that’s come out of this is Ruby Gems is not using a standard versioning scheme, like a lot of us now prefer semantic versioning and stuff like that. And there were requests made that could Ruby Gems please adopt a versioning scheme that we understand, and just even if it was published. And some people came back to it actually if you do publish one our websites, so then everybody went and read that one and then they are like, “Yeah, they do and they are not following it.”
GREGORY:
That’s rational versioning or something. They totally don’t follow that. They follow Ruby’s versioning, which basically means they don’t have a versioning policy. But the release policy that I set up with them last week and I'm trying to be realistic because we are talking about months or even years of opinions forming and I'm trying to think like, what can we do right now people to make people happy? So what I ended up getting out of them is the idea that whatever ships was Ruby itself is the API that they need to stay compatible with until the next release of the Ruby came out. So there is this concept of like if Ruby Gems 1.8 ships with 1.9.3, then you can use that API to guarantee you that everything up until when Ruby 1.9.4 comes out, we'll be compatible with Ruby Gems 1.8. The problem with it is the numbering is all weird, right? Because things might not be compatible with one another and you are still looking back at 1.8, to figure out what the API is. But could you seriously think that we would call it Ruby Gems 2.0 right now because that's how you would start semantic versioning.
JAMES:
Right. I understand what you are saying there, but more to the point, so one of the things Greg was talking about here Ruby 1.9.2 ships with Ruby Gems and it ships with version 1.3.7, I believe and the current version is 1.8.5 or 6 or something like that. So anyways, it’s a massive stretch of versions between the two. The point is like, a lot of users just want gems to work and don’t care about other stuff and they just leave it there and that’s fine. And so all the people that do that Ruby 1.9 up, they are using 1.3.7 so it’s still a pretty relevant version, as far as like its seeing a lot of usage and stuff like that. And so when you introduce massive changes and things like that, but that kind of leads to… this is a good question; Ruby gems is not bundled as a standard library. So for better or for worse, it is somewhat tied to Ruby’s release schedule. We can't really say everybody is using Ruby Gems 1.8 until 1.8 is in Ruby and comes out without release. So how do we handle that and develop libraries?
GREGORY:
You probably know this from merging FasterCSV, what is their versioning policy on standard libraries? Are standard libraries allowed to change APIs during point releases?
JAMES:
You know, I don’t think we’re supposed to change APIs during point releases. I think we’re only supposed to do bug fixes. I don’t know 100% that that’s been followed.
GREGORY:
I thought that that was what their patch level was for bug fixes only. I thought that the deal now was actually doing something quite similar to what I just described what Ruby Gems is doing now, which is that they put the standard library in a folder called 1.9.1 to indicate that it’s 1.9.1 compatible. Where if one of the libraries change, there would have to be a 1.9.3 folder or something like that or whatever the compatibility is. It’s extremely confusing because of the arbitrary limitation that there won’t be any Ruby 1.10
JAMES:
You are basically right. And you are right, I did explain well. The patch release is the bug fix. But to your point on Ruby 1.9.1, that’s actually set at Ruby itself and it’s not something the libraries is in control of. So you can't say, “Oh, my library is 1.9.3.”
GREGORY:
Right and so they would have to [inaudible] the entire Ruby to 1.9.3 compatibility, if Ruby gems 1.8 gets more entries it’s not backwards compatible.
JAMES:
Right, and I think I get that. Yeah, you are right about those points.
GREGORY:
But the whole thing is that I'm sure that there is a fair bit of social pressure not to change the APIs, which is what's really I'm concerned because I think that if Ruby Gems 1.8 doesn’t make it into 1.9.3, that we are going to have even further complications and divisions and all of that stuff. But if it does, then it’s going to force everybody to come to terms to the fact that things have changed, and it’s going to force them to make the… it reminds me of us holding really hard on to Ruby 1.8.6, as Ruby 1.9 move forward and 1.8.7 move forward. And I just think that on either side of the fence, whether you pro a fork or not, it’s going to create much, much more issues with compatibility rather than fix it. So unless SlimGems completely wins or you can convince the Ruby Gems team to completely support 1.3.7 API forever, it’s going to be a problem however you wanna look at it.
CHUCK:
All right. I need to wrap this up. We need to get into the picks so that we can end this on time. So I'm going to end it right here, but I do wanna thank you all for your opinion and for sharing, because I think we really kind of get to see not only some of the issues that are surrounding Ruby Gems itself, but just maintaining a project and especially maintaining a project that’s used the way that Ruby Gems and by as many people as it is. And so, I wanna thank you again for sharing and for helping us all understand this. Let’s go ahead and roll into the picks. I'm going to explain them real quick because we have a new panelist with Greg and then we'll jump in and talk about about what we have to pick.
GREGORY:
Chuck, before we get to that, can I just say one more thing?
CHUCK:
Absolutely. Go ahead.
GREGORY:
I really believe that the idea, not necessarily the implementation, but the idea that just came up over the last days that Evan Phoenix has of making a Ruby Gems feature proof gem that builds stubs over the existing API, so that the API can move forward where the compatibility layer can be kept first outside of Ruby Gems and then maybe pulled in if it shows to be promising, I think that’s the way to go. That’s the way that we can meet the needs of that fork, without forking and I think it’s worth people taking a more serious look at. That’s all I would say.
DAVID:
I wanna append to that and second that based on the notion that stagnation… the complaint right now is that we've got to this large body of stuff and the problem with it is that it’s stagnant and if you address that problem by not changing and not progressing and not evolving, the stagnation just gets worse; you just build more inertia; you just build more crap on the old API, and you have more problems. So yeah, there's a way to kind of feature proof API, there’s a way that you can be in Ruby Gems 1.9.5 and say, “Oh crap, I need the 1.3.7 API.” If you can get that and use it, then down the road you go.
CHUCK:
Right. I do wanna ask though real quick then if you leave the old API in, doesn’t that leave you with old code you then still have to maintain?
GREGORY:
[inaudible] leave the old API in and it’s an independent project that right now we are trying to develop as a gem. Like I said, this is just in the idea stage right now, but what it does is it looks up the gem versions and then on a need basis, will load shims that basically have the API level of the old API but used the new API under the hood to do the work. So you can get rid of a code and just keep the API around.
CHUCK:
Okay, that makes sense.
JAMES:
Just to close this out, I just got to say these are complex problems and people really are working hard on solving them and there's definitely been mistakes made on both sides, but they are doing some interesting development and people that are hoping to do that, are definitely heroes of our community.
CHUCK:
Yeah and I really, really hope that people don’t just look at kind of the drama or the arguments that are brewing, but really look at the issues, really see where they can jump in and contribute, and really just make a difference, because ultimately, I don’t know that this is something that we need to become divided over, I think this is something that we need to find a solution to, and so if we can come to understand the issues, I think it will make better developers of all of us and it will really help the community.
DAVID:
Yeah.
JAMES:
Agreed. Okay, on to the picks. We can talk about this for days.
CHUCK:
Yeah, we really could. [Chuckles] That’s part of the problem here. The picks are basically anything that you’ve found that make your life better; they can be code related, but they don’t have to be. So basically, I mean we've had James pick Legos in the past and we've had other people pick. He also picked Tmux, which is a tool that you can use to share a session or create a session on a remote server. I mean, there are a lot of different tools out there that people have suggested as well as toys and other podcasts and things like that. So you know, I think generally people try and pick one technical and one non-technical, and that seems to be a good rule. But anyway, let’s go ahead and jump in to the picks and just share what it is and why. We'll start with Dave this time.
DAVID:
Okay. Wow. I missed last week. Has anybody picked Exceptional Ruby by Avdi Grimm?
JAMES:
Nope. Go for it.
DAVID:
Awesome. Okay. Disclaimer: I am not just going to pick; I'm going to absolutely plug. Avdi sent me a free copy of this book. I asked him if I could buy it because my karma needed that and he wouldn’t let me buy it. He just sent me a free copy of the book. So Exceptional Ruby, you are handling errors wrong in your code right now, and you are idiot and Avdi Grimm can fix you. It’s an entire book about exceptions. Not just about raising exceptions, but like what happens in Ruby when you call an exception. What happens when an exception is triggered, what happens when you set one up. What happens under the hood. And then he gets into like the tradeoffs between like ways of handling exceptions that are don’t require raising exception, like passing data back in the side band, like passing multiple return values or having output parameters. And he gets into just crazy, crazy stuff. And then he kind of gives you like the tradeoffs between each of the different ways between doing it and how to pick. He tells you which exceptions you need to have in your app, which ones you should have right from the get go and why, when you should raise an exception, when you should just bar from throwing an error. It’s just the man just knows more about exceptions than anybody else here. And his book is $15. It’s at exceptionalruby.com. Cannot recommend it highly enough. I'm about halfway through and I absolutely, absolutely love it.
JAMES:
It is a great book. I got to look through it a little. And just to add how important it is, it was developed and published outside of a big publisher and then the --- recently picked it up, so if that tells you how cool it is.
CHUCK:
Wow.
DAVID:
Yeah. As for non-technical…
CHUCK:
You don’t have to if you want…
DAVID:
I don’t have a good one, yeah. not off the top of my head. I got about ten books that I could recommend that all have to do with writing fiction. You know what, if you are into fiction writing. Yeah, you know what, I´ll plug one real easy. How to Write Science Fiction & Fantasy by Orson Scott Card. If you are into writing fiction, you need to read this book because most writers will start one story and then script the story by finishing a different a story. They'll start an idea story and finish a character story. And Card actually lays out the rules. I've actually pitched a talk proposal right now, but I'm hoping to get accepted on how to write code this way. So basically, if you start out with one type of API, you need to make sure you finish that exact same API, so that your readers understand what you are doing.
CHUCK:
Oh, interesting.
DAVID:
Those are my picks.
CHUCK:
Great. Those are awesome. James, go ahead.
JAMES:
Okay. So my code and non-code pick is this time because I'm a crazy guy. But there's a contest coming up; starts on June 16th which is my birthday but it starts on June 16th and called International Conference on Functional Programming Contest. Every year, there's this international conference for functional programing, like the name suggests and they get together and talk about functional programing languages. But one of the cool parts in my opinion, is a few months before they hold the conference, usually around the beginning of the fall, around the beginning of the summer they do a contest. And instead of closing their contacts down and only allowing people to compete with functional languages, the way they prove their “superiority” is they let anybody use anything they want to do the programing contest. So it’s up to the functional guys to get in there and prove theirs is better, basically.
DAVID:
Oh, that’s cool.
JAMES:
Which means, it’s up to us rubyists to get in there and prove that it’s not better. So we have the mission. We have to go do it. But seriously, if you enjoy programing contests and you guys know I do from the Ruby Quiz and such, but if you enjoy those kind of things, this contest is 72 hours. It’s definitely a great, very hard thing. Usually the problem is about 15 pages printed, so you take just a couple of hours at the beginning of the contest, you meet the problem and try to figure out what you are doing again then you develop something working and refine it over time. And I do terrible in this, by the way. I usually come in fairly low, and I'm totally pleased with myself because just completing these problems is all the reward you can need in seeing your name up one the board. So definitely, if you are into programing contests and you like a big challenge, get a bunch of your buddies together, definitely don’t try it alone. They are kind of scary and you need some people that can give you some ideas when you are fried because you´ll definitely get fried. Greg and I
have done it together in the past multiple times and its great time, you learn a lot, it’s big commitment but it’s definitely worth it. So I recommend all rubyists go try the International Conference on Functional Programming Contest.
CHUCK:
Cool.
JAMES:
Starts two weeks from today.
CHUCK:
Sounds like fun.
JAMES:
It is.
DAVID:
That’s exactly the kind of birthday presents that you like James, isn’t it?
JAMES:
[Chuckles] By the way, you are going to do a programming contest on your birthday? It’s like, yeah. It only comes once a year, so…
GREGORY:
[inaudible] four in the morning to do the problem solving contest with me over Skype, so this is a pattern for him.
JAMES:
Greg is like, “You wanna wake up in the middle of the night and do programing contest?” Sure.
DAVID:
I should say the phrasing on that sentence was a little bit wrong. I actually kind of can hear Dana actually saying, “Holy crap! You get to do a programming contest for your birthday?”
JAMES:
[Chuckles] That’s about right.
CHUCK:
Yeah and for the rest of us, programming patterns are things that you get out of a book.
Programing patterns for James is when he wakes up and what he gets to do for the day.
JAMES:
[Chuckles] That’s hilarious.
CHUCK:
All right. We interrupted you, James. Anything else?
JAMES:
Nope. That’s it. those are my picks. Go do the contest.
CHUCK:
All right. I have a couple of things that I have run across lately. One of the first ones, I'm trying to find the book so I can give you the exact title here. I kind of started cleaning off my desk. I couldn’t find it.
DAVID:
Oh, if only you had a moment to prepare!
CHUCK:
Yeah, well [Chuckles] I've been replacing the power steering pump in my van. And I kind of run up here about half an hour before we were supposed to get started and it was like, oh guys, hi! So anyway, it is The Big Nerd Ranch Guide to iOS programing. It’s kind of a step by step tutorial in a book how to build iOS applications. And it has been really, really cool. It kind of gives you what you need and no more. And then the next stage is picking up the next steps. And it has been really, really informative as far as how to program for iOS and I highly recommend it. It’s by Aaron Hillegass and I can't remember the other guy’s name because I don’t have it in front of me. But anyway, super pick. And then the other pick that I wanna let people know about is slimtimer.com and I've been using slim timer for quite a while, and what I use it for is I use it for tracking my time when I'm working for clients since I bill by the hour. So they have a little… it’s a handy little pop up and what you do is you can actually move it up into your bookmarks so it’s a bookmarklet and then when you click on it, it opens up a Slim timer with all of your tasks in it. And my task is just list my clients and when you click on one of the clients, it starts the timer. If you click on it again, it stops the timer. If you click on another client, it stops the timer for one, starts the timer for the other. And then at the end of the week, you can run a report and see how much time you spent for each task or each client.
DAVID:
Is that a free service?
CHUCK:
It is a free service.
DAVID:
Okay that’s cool. I currently use Harvest app, and I absolutely love it. But it’s not free.
CHUCK:
Yeah, Harvest is not free. Harvest does some things that slim timer does I think you can do invoicing and stuff from Harvest.
DAVID:
Yeah, you can.
CHUCK:
But for me it was just really simple and easy way to keep track of my time. And then I've been doing all my invoicing and stuff through QuickBooks online. And that’s kind of handy. I think it’s a little overkill for what I'm doing with it, but it doesn’t cost very much. Anyway, those are my picks.
And we'll go ahead and let Greg jump in and tell us.
GREGORY:
Okay, have you guys talked about pry at all?
JAMES:
Nope. Go for it.
DAVID:
Ooh.
GREGORY:
Pry is awesome. It’s an alternative for IRB. I wouldn’t necessarily call tit hat because I still use irb for most of my standard interactive stuff, but what it is is basically just a badass way to do exploration and auditing and debugging and that sort of stuff in your code, because it allows you to do things like drop the word “pry” in anywhere in your code base and then when you run the code, it will launch irb like thing and directly at that place, within the binding, so that you can have access to all the variables and all that sort of stuff.
DAVID:
How does that compare to Ruby debug?
GREGORY:
It does a lot more of than just that. I mean it has more features that it has, but it also does things like if you run it and then you ask it to show a method for an object, it will pull the source and display the source for you. It will pull the documentation and show you the documentation. It basically shows the syntax highlighter on the terminal….
DAVID:
That's nice.
GREGORY:
It does all sorts of wild stuff like and it’s really good. I would say actually those tools that’s really important for you to have in your tool, but you won't use it every minute of every day but like just today as I'm starting to poke around in Ruby gems, it’s really useful to be able to pull source on method just by interacting with objects.
DAVID:
Is pry available on slimgems? [Laughter]
GREGORY:
Uh…
DAVID:
You know in a few weeks, that’s not going to be a funny question.
JAMES:
Yeah, you are right, it’s not. You know what, I was just thinking when you guys were talking. We need to do an episode on debugging at some point because David Brady goes, “how is that different from Ruby debugging? Unlike what, puts?”
DAVID:
[Chuckles]
CHUCK:
Oh no. [Chuckles]
DAVID:
Yeah, we do need to do an episode on debugging because Greg said that pry will show you the source code. So will the debugger. And the question I have about pry is if you go edit your source code in another window and then reload the source, the debugger gets out of sync; it goes, “This was an on line 17 when I started. I don’t know where it is now.” Does pry do that?
GREGORY:
You know what, I actually don’t know. I'm pretty sure that it uses Ruby 1.9 source location and on Ruby 1.8 I think it back ports that. So if that works, then it should work. If it doesn’t, then it won't
DAVID:
Probably not.
GREGORY:
It’s neat because it’s definitely more focused on the exploration aspect of things than just debugging. But like part of the debugging process is doing a little bit of an exploration, so I found it’s been helpful. I've used them in few different ways. It’s funny because the maintainer of this basically just came in to the --- IRC channels. Told me to look at then I actually did. I don’t know them, but then I've been a major proponent, so I'm glad that did that.
DAVID:
Yeah.
GREGORY:
So no, it’s definitely worth checking out. Like I said, it’s not something that I use every single day, but when I use it, I'm glad it’s there for sure.
DAVID:
Yeah.
GREGORY:
The other thing that I wanted to say and its actually, I don’t know that you can call it a pick; it’s not a thing but it’s a soft skill. Something that's always benefited me but only really in the last few months or so mainly through working with --- but also just other stuff that I've been doing, I've really come to value power of conversations with smart people. And I'm talking both through mailing list and irc and public settings and private conversations. I don’t think that the progress that I've made in the course of the week helping with this Ruby gem situation would have been possible if I didn’t go and talk to people one on one, rather than using just broadcast mediums like twitter and blogs and things like that. I've been using those. They are useful tools to get people who might wanna have a
conversation with interested and also to sort of get your public information out there, but at the same time, like you can get a lot of progress on problems if you just talk to someone and find out what their real problems are, what the real concerns are. That sort of thing. And I think that because we are so used to using broadcast mechanisms that we underemphasize the value of actually talking person to person. And that’s how our view has become successful because that’s how I've learned how to teach intermediate developers. I would say a year ago before I started doing our new stuff, I had a much worst understanding of the sort of problems that they go through until I started with just dealing with people every day, talking to them one on one. So I think I mean that’s sort of wishy-washy but at the same time, if you spend most of your time reading and searching and looking on blogs and broadcasting, spend a little bit of time talking one on one with people and it you´ll find it will really help you to improve your craft.
DAVID:
I can't agree strongly enough. I've been doing a lot of remote pairing and just the amount problems you can solve by stopping typing and starting talking, I just can't agree strongly enough. That’s awesome. That’s great.
JAMES:
Are we actually saying programmers need to develop their social skills? Where’s my bag?
DAVID:
Oh, shut up!
CHUCK:
[Laughs]
GREGORY:
Honestly, I mean everybody knows that he mentored me for years. It didn’t really even sink in that like the reason why I learn so fast, which just happens when I'm available to talk through things because you just get so much more directed help when there are contacts around. In most blog posts, unless they’re extremely well written, tend to lack contexts in a big way and just going on that information alone is just not good enough.
JAMES:
Aww, everybody get in here for a group hug.
CHUCK:
Aww. All right. I'm going to wrap this up. I think we just hit an hour. And I really, really wanna go over it. So there are two more things that I wanna mention and then we are going to be done. The first one is that next Thursday, I'm actually going to be out of town, and I haven’t found anyone else who can record the podcast.
DAVID:
I´ll do it.
CHUCK:
OH, you'll do it?
DAVID: yeah.
CHUCK:
All right, cool.
JAMES:
All right, we’re in then.
CHUCK:
All right, so next week I won't be here, but I guess they'll go on without me and I´ll get with Dave and help him get stuff set up so he can host the episode and things.
DAVID:
That will be great.
CHUCK:
And anyway, the other thing is the topic for next week, we are going to talk about conferences and user groups. And I think we are going to get into both organization of those and just kind of how to run them and also make them happen. So, keep an ear out next week. I guess James and Dave are going to be running the show.
JAMES:
Okay.
CHUCK:
Anyway, finally, go in to iTunes. Leave a review. If you want to talk about this any further, I think we are all willing to talk about it. You can contact any of us or you can go to rubyrogues.com, look at the show notes and leave a comment. That would be terrific. I think that's it. We'll wrap it up because we are out of time and we will catch you all next week.
DAVID:
See you later.
JAMES:
See you next week.