Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hello. Awesome. Mic's working. Hi, hello everyone, I'm here to talk about. . . Woo! I'm here to talk about building CLI apps for everyone, so if you were looking at the board and you saw something about managing a community for Ruby association, this is not that talk.
Unfortunately, he couldn't make it. So, yeah, I'm Terence Lee. I go buy hone02 on Twitter, I come from Austin, Texas, which is only an hour and a half north of here. We have some awesome tacos. If you're ever in town, I'm more than happy to take you out for some tacos.
I know some people have collected on that. There's also a Torchy's Tacos, I think, in San Antonio, halfway between here and the airport. Is what I've heard. They have awesome tacos. With a few fellows here, and Davy, who is not here at RubyConf, we run this weird conference called Keep Ruby Weird, which is in Austin, Texas.
Just happened last month. Stay tuned for year three next year. You can probably hassle Ernie about how great or terrible the conference was. He was there. I'm also a big proponent of Ruby karaoke. If you did not go to Ruby karaoke at RubyConf, you missed out on a really awesome, magical experience.
This was us singing Bohemian Rhapsody, which is a classic, of course. And it really started, I was inspired by Charlie Nutter, back in last year, during RubyConf Taiwan, he karaoke'd for a marathon seven hours. I only managed to do, like, five, but it was a really great experience, and this is him singing a duet with Plexus, which is always a good time.
I have to give a shout-out to P. J. Haggerty, who could not make it here, but he has been a huge proponent of Ruby karaoke, and has helped organize a ton of them. So much that I've actually organized none of them this year, but there's been one at every single Ruby Conference I've been to, which has been pretty great.
So I work at Heroku, I do Ruby things there with Richard Schneeman, who's sitting over there. He had that picture on the first slide, drinking that medium sized margarita. Everything's larger in Texas, apparently. So onto the actual talk. I'm here to talk to you about packaging in Ruby, and why we should be building things in Ruby.
In order to get a sense of how this works, I'm gonna talk about the Heroku toolbelt, and the story behind it, and where we started, and where it's going today. And so when we first started, we were just a Ruby gem, so in order to get started, you just ran gem install heroku.
I think even some people today are still using the Heroku gem, even though you're not supposed to. It's been deprecated. And at the time, it was a great decision because Heroku was just targeting Ruby customers. That was the only thing we supported on the platform, and so plugging into the Ruby gem's ecosystem made it really easy and convenient to get up and running.
We didn't have to deal with package management, we didn't have to figure out how to deal with all this stuff, because Ruby gems already had a specification, and if you're a Ruby developer, you already had the Ruby gems installed to ready build your rails and other applications.
So that was great win for us, because it allowed us to move quickly and not have to deal with many other things. But the downside, over time, that we learned was that it required people to actually have Ruby installed on their system, which, as we moved to being a more polyglot platform, that became an issue.
I've talked to some other people who have. . . Like there's the Sass Project, which requires you, when it first got started, to have Ruby installed to do, like, Sass stuff, which was a huge barrier to entry for front end developers who may not be familiar with getting Ruby up and running.
If you've ever helped out at a Rails Girls or Rails Bridge, I'm sure you're very familiar with how painful this process can be. And the other thing, even if you were a Ruby developer, we couldn't guarantee the version of Ruby you're running was the same one, so we had to essentially support many versions of Ruby.
On OSX, it was famous that they Ruby 1. 8. 7 as the default version of Ruby for a long time, and even after Ruby 1. 8. 7 was deprecated, and no security updates or anything were being added to it, we still had to make sure our gem was backwards compatible, so we couldn't take advantage of any of the new features and syntaxes, just because we had to make sure it would work.
Which made debugging and maintaining it a pain in the butt. So then we moved on to a, essentially, a packaged up installer, where we would package up the Ruby runtime into this thing called the toolbelt, and we would take the gem and basically have the gem and the runtime with it.
And so we would have to build that for every single platform that we wanted to run. I don't know if any of you have tried to package up Ruby for Windows, but it is not very fun. We had a special box that would do that, and even for OSX, we had a Mac mini, when we first started this, under someone's desk at the office that was just there for packaged up OSX Rubies.
And we've automated a lot of that stuff since then, but it is still a lot more work than just pushing up a new gem, right? If you're just updating a gem, you can just run rake release or some other task, and it's very simple to get versions and stuff out.
Now it's a much more involved process, and with the new OSX signing stuff, we have to have certificates and other things in place. So then there was this HK project that was started internally by an employee, and it was basically rewriting the entire CLI inside of Go.
And one of the big motivating factors for doing this was that speed is a feature. Like, fast is a feature. And so at the time, when this was benchmarked, running Heroku version on the Ruby gem or the toolbelt took almost two seconds, and the Go equivalent was 16 milliseconds, and so you're talking about orders of magnitude of difference here.
Admittedly, the Go version did a lot less than the toolbelt version, but I think it does show some baseline on performance difference there. I think a lot of this can be attributed to the fact that having to load a bunch of these things inside of Ruby at runtime can be a slow process.
If you hadn't heard of this before, require is pretty slow. There is a performance impact for doing that. So especially for a command line application, you want to split up your application as it gets bigger, because you don't want to have the monolithic Perl 23,000 lines of Perl code that you're trying to parse through for a single command.
So you end up splitting it, but then you have to do all these hacks which we've done in the toolbelt to only load the files that we need to at the time that they're needed all throughout the code base, as the default version of Ruby for a modular and actually maintainable.
The second thing that was really appealing about Go for us when we were doing this was that you could statically link each binary, which meant that we could build a single file that we could distribute to every single operating system that we cared to support.
Which meant for Windows and OSX and Linux, it was one file, we could just package that up and then give it to someone, and they could install it on their system and it wasn't this folder of files and things plus some runtime, and path environment variables to make sure that all that stuff is set up.
And if you had an existing Ruby install, we had to make sure we weren't monging and overriding stuff while you're running the toolbelt, that it would pick up other things that you already had set. So I don't think the Heroku toolbelt story is unique. I know Hashicorp has had a similar story.
[ ... ]
Nota: se han omitido las otras 3.684 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.