Extracto de la transcripción automática del vídeo realizada por YouTube.
- My name is Jack Danger It's a silly, silly name, but it is mine. And I work at a company called Square. We're in San Francisco and a few other places. We have a New York office, Atlanta, St. Louis, Waterloo, Canada, and Tokyo. It's a pretty great place to work.
Because Square sent me here I feel like I should, it's obligatory that I tell you a little bit about how we do engineering. I'll just sum it up by saying that we do billions of dollars in financial work with our own manufactured hardware that we create, code the firmware for, manufacture and then send out to all of our people.
And we'd love for you to join us cause we do it all in a really secure, superbly secure and really, really pretty way. Very well designed way. And it's a lot of difficulty. (laughs) It's really hard. So, please come join us. We'd love to show you how we do it and have you help us do it better.
All right. This talk is about the Ruby Environment Variable API, which, in my description of the talk, I actually said, "I'm not going to call it that" and then Abdi was like, "No, that's great. You should totally call it that. " So, I'm calling it that and I actually kind of like it too, because what we're gonna talk about is the things that you can do with environment variables, which I'll explain in a second if you're new to them, to tell Ruby how to behave.
And, this is the core, actually, of how all of the tools that we use, that are not Ruby itself, operate. How Bundler and RVM and rbenv, chruby, and, um I'm missing some of them, how they all actually work, they work through environment variables. And we're gonna talk about how to debug your machine when they go wrong.
Another name for this talk could be, "require, cannot load such file" because, when you get this error, something in the chain of stuff I'm about to show you has been misconfigured. To begin with, let's talk about the ideal world. So, the perfect world is this.
There's one version of Ruby. It's at, let's say, bin/ruby and you run it as, let's say, root because you don't have to worry about users and permissions and stuff and if there's one argument and one argument only and it's one file that contains all of the code that there is.
You've just copied out of your favorite gems, just copy out of the rail source, just paste into the top of this file, at the top. And then, as you go down, you paste in other dependencies until the very bottom, there's your app. And you run this, then it runs and it never has to call a require.
And that's perfect. And, that's what we're gonna do. That's not what we're gonna do. That's ridiculous. That's also just not the real world. The real world has a lot of rubies. Like, like a lot of rubies and your application requires a lot of files. This is the reality of it and your application, you don't say require slash full path to file because that would be extraordinarily tedious, error prone, too tied to specific versions and it would be impossible to manage.
Instead, you just say, I want this thing, give me this thing. In fact, give me the right version of this thing and the right version of this thing considering these other things that I also want. And it should just work. Except when it doesn't. You know, you can just require nokogiri, "cannot load such file nokogiri", Oh, also, please forgive me, the syntax highlighting, it's hard to do it on slides.
So, sometimes I get it wrong. Also, I'm color blind, so you're gonna see like seven shades of yellow that I can't distinguish. I tried to make them all the same, I really did. Now, can we make this make more sense? Leslie Knope thinks so and so do I. And we've done that, mostly through these projects.
We have a bunch of tools that wrap up the complexity of working with different versions of Ruby and different Ruby dependencies and make it really easy, intuitive to just run your code and not have to think about things. Also, I would like it very much if you would just pretend there are logos on the slide.
Because, some of these projects don't have logos and I didn't want them to look bad next to the projects that did. Now, in spite of the heroes who've built these projects, and the incredible amount of work that has gone into making them work across many different kinds of systems and with many different dependencies.
This is how most people solve problems with their environment. And, this is like, kind of written up as a joke, but then, I've been asking people, during the conference, so, if you can't find the right file or if Bundler doesn't seem to be working the way you want, what do you do? (laughs) And it's almost exactly this list.
Like, no body actually said farmer, right, but if you can't read it or if you like to hear my voice say it, it goes, rake, or whatever command, then, oh, whoops, oh bundle exec rake, oh right. Oh, wait no rvm use the right thing and then bundle exec rake or actually, you know what, close terminal, start over or ask a coworker and then, you know, if Danielle can't figure it out she'll tell you, close your terminal, start over.
And then, after that, you're like, well, whatever, rvm implode (explosion sound) just start over completely, reinstall rvm and then, like, installed some rubies, you're compiling them from scratch. Sure, that'll fix it. Or, rerun the bespoke setup script that you and your team, or your company, or your client use.
In fact, reboot your machine, Actually, that probably should've been up there higher. Or, just buy a new computer, but then definitely become a farmer. This is blindly trying things to stem the bleeding from the wound that was caused because our tools were so sharp, they cut us.
And what we need, is not, um like, there are people who blame their tools, right and we all blame our tools sometimes. But, the people who built the tools that I mentioned in the previous slide, they've done incredible work. They continue to do amazing work and all those tools are getting better.
What we need are not for those people to stop doing it. What we need are just more heroes, like them, to do it. And that's what this talk is about. This is indoctrination. You are all about to be equipped with all the tools necessary to join the folks on projects like RubyGems and Bundler and RVM and Chruby.
By the end of this, if you don't want to do it, it'll be because you choose not to do it, not because you're not capable. Now, how to become a superhero, Parts number one through infinity. There's one step. You just learn the tools. If you want to be somebody who everybody else calls a wizard.
If you've ever talked to someone who's not a programmer after you started programming, you'll realize that they think there's something about your brain that just works differently, and that's not true. You just sat down and got really frustrated for a long time until you got a little bit less frustrated.
And we call that understanding. And now you know how a thing kind of works. And that's all there is. And then they're like, "Wow, how'd you do that?" And you're like, I mean, Stack Overflow mostly, right. So, you learn the tools. We're gonna talk about a couple tools here.
And the main thing, because it's in the title of my talk, I'm gonna start with, is environment variables. Now, environment variables, I've seen trip up even really, really brilliant people. The people who seem to work with them really easily, are just people who've worked with them a lot.
But, what they are is, it's a global hash of strings that, or HashMap or dictionary, however you want to call it, that your program inherits from its parent program. So, if you are in a shell session, you've inherited it from something earlier on in a boot cycle that created your shell session.
[ ... ]
Nota: se han omitido las otras 4.007 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.