RubyGems and RubyGems.org

Welcome to The Changelog Episode 0.5.9. I'm Adam Goyak. And I'm Gwen Nedland. This is the Changelog video.

It's fresh, new and open source. If you found us on itunes. We're also on the web@the changelog.com, we're also up on GitHub. Head to GitHub.com explore.

You'll find some training reposts, some feature reposts from our blog, as well as the audio podcast you're listening to. If you're on Twitter, follow Changelog show and me I'm Stack. And I'm Penguin. P E N G W Y N N and this episode is sponsored by githubjobs.

Head to the changelog.com jobs to get started. Feel like the feature job on initials that advertise on the Changelog. You post your job and we'll take care of the rest. Asana is looking for a software engineer in San Francisco, California.

Great perks on this one in house yoga, executive life coaching, organic home cooked meals twice a day. And the kicker, three 30 inch monitors. Actually they'll let you spend up to 10k on your own rig however you think best. Be sure and check this one out.

Asana It's LG GD AJ Next up is crowdtab. Crowdsab is looking for a rail software engineer there an exciting NYC startup based in the Union Square area looking for Ruby and Ruby on Rails engineers to join their team. If you're using jQuery Rails 3 MongoDB Redis the as Wynn says at the usual suspects rescue RSpec you can close goes on for using those fun tools. They want to talk to you and if you want to work with them check out LG GD AM Secure Endpoints is looking for software engineers in New York or elsewhere full time.

They develop single sign on identity management and security data access solutions including Network Identity Manager, Kerberos, Microsoft Windows platform. So they're also looking for folks on Windows, macOS and Linux, Mobile Client Development, iOS and Android. If you're interested, be sure to check the shortcode LG GD AK this week an excerpt from our live show Reddit recap. Talk to Nick Coranto from Jim Cutters now or Jim Cutter now.

RubyGems and the whole backstory, how that project came about, how it morphed into RubyGems 2.0 and the philosophy behind what goes into a good Ruby gem. Gymspack Intro to creating a Ruby Gem if you are new to the process you got about a zillion gems out there between all the APIs you work with, I got several. You got a couple. Just a couple.

It's not as hard as you think, right? I don't think so. Not something. If you're intimidated, it's your own fault.

You should just try. So easy. And Alan can do it. There you go.

But I'm so tricked. Let's do it. All right. We're joined by Nick Toronto.

Yes. From Boston. Yes. Originally.

No. From Buffalo, New York. Known on the interwebs as Qrush Crush Nutrition. Outside of works.

Cool. It was just limiting the fact we don't have the high end Damageman golden microphone. So we should have it the next year's podcast. So wanted to talk a bit about your gem cutter project that turned out to be, I guess, Ruby Gems Part 2.

Basically, that's how we put it. Talk us through the background of Gem Cutter and how, I guess it progressed much better from your thought tomorrow. Sure. So Jump Cutter started as a little side project of mine at Boston River Group.

I'd just been getting into gems and publishing them. I got in around the GitHub era where we had to go and check a box and you hoped it worked and then it didn't work. And then you checked and someone was on a site that you went to it and you looked at it and you remember this. It was like, no, I haven't seen things.

So it was pretty terrible. So that was pretty bad. And I actually tried to sign up for a report account and signed up for like a fake gem. And then I said no, it's like I basically typed a bunch of garbage and they actually had someone going in and saying, oh yeah, you can publish a gem now.

So I thought that was really not good. So I started talking to Doc Nichols, who wrote the dual agendas in Boston at the time and top of us and Werner about what can we do to make this better? And we just went from there. So basically laid out a few ideas about what the psych would look like, what it would provide and just try to figure it out for a while it was come up with a Nick's crazy idea how to kill Ruby Forge and then realized that wasn't the best marketing term for it.

But I think it worked out pretty well. Did you have that plan going in to sell hrbyforge? I mean, kind of. The way we were looking at it, it was like there was no other way.

So it was either this other weird gemsource kind of hanging out that people will be like, well, do I use Jumper or Ruby Forge or Jennifer, which one do I use? So I think the plan was just to improve what we had because it obviously wasn't ideal. So I think that's besides the prior motivation I just said, which wasn't very nice. We're nice here.

So that was really. The driving force was due. It's going to have to be. And there's no reason for it.

There's no reason for it not to be. Especially with the guy that runs a regional project. I feel like you have to really prove that the Cody write works. So I had to set out going to that first.

Like I was looking at them and say, oh, here's this idea that would have been like, no, that's not going to work. So I had to prove it first and I wanted them in that worked. So how did that conversation go about did you approach those guys who they approach you or it got to. So Extrepoint and Peter Cooper wrote a blog post on Ruby Inside about it.

And this is just after I got it. Got it actually working. And people could actually like download gems from it and be like, oh, here's this new gem posting service taking on these other sites. And like, I wasn't really the point.

I just wanted to fix what we had. So it was around then where I really started realizing, okay, we need to figure this out. We need to figure out what's going to go forward. So I dropped out a little plan and showed to them.

But before that I had not really talked to them at all. But luckily they've been really cool. They've been very nice and open to the ideas we had and they jumped on it. I wouldn't say immediately, but very quickly.

Who here has written and released a gem of under gems front of you folks? The rest of you? Why not? So for the uninitiated, what is a gem?

Okay, so a gem is basically a bunch of Ruby code that you can share. That's like the simplest thing, the way to share Ruby code, the actual internal of it is actually a tarball that has a YAML metadata hunk and then your files. So that's what Ruby Gems handles. Sharing that and tossing around your system and making sure it's in the right place.

And then it also handles actually requiring all that Ruby code that's in the gem at that time. So there's a lot of magic it kind of has and that's to make your life a lot easier. So I hate to use the word manifest, the gems spec is sort of the manifest of the Package. What all goes in that?

Yeah. So the gemspec has everything from the name of the package to the version, to the date, to the files that's in it, to the description to an email. If you depend on other gems, if you depend on other software packages, it's a huge sprawling list of things that not everyone fills out, which is very challenging. Fills out?

Well, you know, an intriguing part about the gemspec is it's actually. You can actually Ruby in it, right? Yes and no. Shouldn't maybe.

So the gemspec, I mean, the second stuff is in Ruby, but it gets saved as YAML. Okay. And that's eventually what it boils down to. And you can't.

I mean, you can put like Ruby code in there, but when you're packaging up a gem, it's when you save the YAML, it's not going to save the Ruby because I mean, we can't just arbitrarily execute Ruby code on servers. So that doesn't work out too well. As I've shown early in my gem publishing days, I would go back and forth some of my sort of project. It's in the patch with Mess with Genesight.

Right. And there's this big hub of the round. Do you put the jspec in Git, do you not? If you want to be able to use bundler from GitHub, it's required.

Right, but what is the etiquette, I guess, around the Jinspec? So many different ways to do it. I wish almost Git had a thing that you could say, don't touch these ever. And Aaron even mentioned it in his talk.

Did not touch build systems. The way that we tend to do it now is we actually put the gemspec in the rake task and the rake file. So there's a rakegem package task. I don't know the exact name of it, but Rake provides a way to package gems and generate the gem file and then I'll actually ignore it from git.

So I won't even start and get it all. And the actual version will be inside the rubygemsmlare and all the information on you will be in the rec file. That's what we're doing it now. I don't know what the best way to do it is.

I think as long as it's in version control, that's good enough. Seems like Bundler has advanced landscape of gem dependencies, I guess library dependencies. Put another way, are we still advancing that cause? Are there problems to be solved or is this the future as in just managing dependencies or managing dependencies and basically versions of those dependencies and things of that sort.

Jim Stats Level 9 yarns I mean I'm not sure about the only one who's been waiting on fetching Source Index. Right? Does anyone else hate that error message? I hate it too.

So there's a lot of problems to be solved there and actually the new bundler release 1.1 is using a new API that we wrote in Jumpcutter to make dependency resolution a lot faster. That's perfect. That's the exact reason why Jump Cutter is there. So we can actually in Ruby writing the APIs that will help out community and get them out there faster.

So hopefully that will be really soon. We had the endpoint done a while ago but Bundler is a big project and it's very complicated. It's not easy to mess around with it, but that's complicated. It does a lot of things.

So the world is definitely not over by any means. Who's driving the roadmap of jumpcresters for the community driven or do you have a vision for it? I guess it's. I wouldn't say that there's a roadmap.

There should be. I should work on that. I would say it's more commuter. We do a lot of features in feature requests.

I try to get them in as soon as I can but I'm not happy with the code quality. I'm not going to bring it in. Luckily there's been a lot of computers and I want to make it as easy as possible to contribute. I think the big things we need and this is kind of something we'll talk about but.

But we need like this bigger overarching things we need that is not really part of the counter but it's part of the region's ecosystem. So things like redundancy and mirroring that every other open source community has like we get laughed at because we don't have mirrors for regens. I get laughed at. So there's these problems we need to fix and it may or may not be within the square junk card.

The nice thing is that we can actually adapt it a lot faster now it's not a huge model with PHP site that we are kind of worried to touch. So I guess the takeaways if you do have mirrors, if you have to host some multiple cloud providers for days like they are, I think I know who to talk to. So when you go to create a new gem to the extent that you do so your own personal Preference of creating a gems back. Are you close to the metal manual or do you like.

Yeah, I mean I started using Jeweler so I tend to default to that. It's gotten a bad rap lately. I don't know. I know a lot of people use HOA and a lot of people handle stuff.

I tend to go to Jeweler by default just because it generates all the junk and you usually need like a spec directory and features and it starts complaining at you if you don't write tests. So hopefully you're doing that. But I mean I can handle stuff as well. The practice of problem handling is I don't even remember what's going on.

So the next thing that jeweller kind of sets it up and then complains at you until you fix it. And it's not like ho where HO will always complain at you if you don't do certain things and follow their way. So I don't know, I think just use the best that you can and whatever you're familiar with as long as it's not like. As long as it's somehow automated, that's the important thing.

Who's leading the charge, I guess in this area because it seems like it's had a lot of falling forward when you just listen to the other alpha geeks when they. That probably they figured out a long time ago, case in point around the gen spec in the in the GitHub or in the git repository and things like that. But also like Ryan's post I guess several years ago now around not requiring rubygems it seems like there's no canonical place to go and say okay, this is how you do. No, no, the rubygems backslide is not good.

And one of the things that was brought up recently, there's no real community places they're like, well here's how we do things. And like that may not probably apply, but at least a general set of rules to say like okay, don't do like don't require rubygens, don't mess up the load path if you don't need to. Don't like wrote constants in weird places like at the top here at the top of files. Like I remember at one point when I was doing the GEM fighter gem, which is a gem plugin and the gem plugins get loaded every time you bring in RubyGems and I would put a URL constant in there, this little URL.

So anyone that ever installed that gem had a URL constant defined in their app always. It's like I had no Idea that's like, okay, I just put it there. I had no clue. So I think it's a huge community problem.

I don't know who no one's looking at. So I think there should be more information on where that is and that could be a whole separate site and I'd love to help out with that. What was the transitional gem cutter command you had to do for the command line before Ruby gem switch over migrate. That was fun.

So that was. So that kind of existed. Let me think back a little bit. So that kind of existed when roof order still around because we had to somehow figure out that you owned a gem.

And the use case I was always thinking of was that, okay, I need to make sure someone like DHH is going to come to my house and kill me for pushing a new Rails gem or pushing rails 2.0 by accident. So because there's a few things in the gems like we can't trust, like the email. So that command actually would like upload a file to your gems FTP space on rupeeforge, which I had no idea existed, and then look for it on the jumpcare side. It was a mess.

That's gone now, thank goodness. But it was a weird transition for a little bit. So the out of the gem building business. Right.

Is there any, I guess, valid reason to have a namespace gem upon. No. Oh well, yes and no. So I.

So the namespace gems. So like your GitHub username and then the name of the gem, those are there because GitHub couldn't do it any other way. And there's been a lot of discussion about how to do forked gems. That's basically what it is.

If you're forking a gem and you want to publish it. I think now that bundler is around, which it wasn't when we did the cutover, and that you can specify. You can do a dependency on a git repository. I think that's perfect.

You should just use that. You shouldn't waste time pushing a gem. You just hook it up right there and you can even specify a rep. So if you're going.

If you really want to get nutty with it, you can set a tag in your own repo that isn't going to be the main repo and that means it will never pull it in and then make sure that you're always locked to that one. So I think that's a lot better than pushing it up, having to wait for it. And then you have to maintain that gem instead of just the repo I would imagine just the sheer virtue of creating GemCard you see a lot more in DOM gems than the average person. What's the funniest host install commit message that you've seen in a gem?

For instance HTTP Party Party hard. I'm surprised when people don't abuse that because I think the only thing you can do after gems install is you can actually print the whole message. So I'm surprised people don't like it's only a string, but I don't know how long that string can get right? So Eric crammed quite a bit into the I'm not sure if this is a new one for the Twitter gems now actually gives you the mailing list and some resources to follow to commit back to the gem which I thought that was unique way to use it seems like the humor aspect of this seems to be more I didn't seem too crazy.

There's definitely been a lot more like silly gems posted because you don't have to wait a few days like the meme generator General a few gems that do terrible things that I want to talk about but there's a few funny funny gems. Not so much funny post installs, but may that be a whole new era of comedy in theory. For the second question you have for it, Wes, you know gems and the Fog Library means to an end. What's your end?

What are you building with Jump Cutter? With anything. It's Sunday afternoon. If you're just coding.

If you're playing like me and that's what you do in South Africa, I'm that lame as well. I'm no different. So I've been working a lot with Redis lately and I've been doing a few talks on it and I'm in the process of writing a service that uses it. So I've just been knee deep this week.

I've been doing a lot with machine. I've never used vent machine before seriously for anything. Apparently they do timers really well, which is really hard to write and they do it really well. So I'm gonna let a vent machine do that.

So I've been messing around with let us invent machine trying to wrap my head around it. So besides that, not too much outside of the Junko world. There's definitely always a lot of pull requests and bugs that suck up a lot of time. Thanks for joining us.

We need to clear off the stage for Dr. Vulcanot. Appreciate it. Thanks.

Thanks everyone.