 RubyConf, yeah. Hi, my name is Brad Urani. I'm a staff engineer, a software engineer, a staff engineer at a company called Procore here in Southern California. This is what I look like on social media. It's a funny thing if you do a lot of tweeting and DevRel and things like that, you're afraid to change your profile photo because you don't want people to forget who you are. I really should update it, but I was a lot fitter back then, so I might just keep it. I work at Procore. Procore is located in a beautiful little surf town called Carpentria, California, which is about 200 miles north of here. It's sunny, it's beautiful. We're big supporters of the Ruby community. We're not sponsoring this conference, but we did sponsor the last two RailsConfs in a previous RubyConf. We love these events. If you went to RailsConf, you probably saw our booth and all the engineers we sent down there. We build software for the construction industry, so if you are going to build a skyscraper or a shopping mall or a subway or an opera house, there's a good chance you're probably gonna use our software. It's a full suite of construction management tools for building buildings like this. Here's one of our iPad apps that does drawing management for people working in the field. Here's some men using the iPad app on the side. I say men because construction has a similar problem that tech does, which is, it's overwhelmingly run by males, unfortunately, but we try to close the gap here with, we've got a program called Women in Construction that we're really proud of that we actually modeled after a lot of the Rails programs to increase diversity in the tech workforce, things like Rails Girls and stuff. We actually copied some of those paradigms for a similar program for construction industry. We're a big Ruby shop, a big Rails shop. We have one of the world's largest Ruby on Rails monoliths. I know Shopify's got us beat. They've got like three million lines of Ruby in R's. We've got at least a million, depending on how you count it. It started on Rails 0.95 in like 2005. We've got, I'm not, I don't think I'm supposed to tell you exactly how many, but dozens of backend developers working on it every day. We deploy it four or five times a day. So we do Ruby a huge scale, and along with like sort of massive deployments like this, it comes with a lot of ops work, a lot of tools and things like that. We've got a lot of this kind of stuff. So these are various like infrastructure tools and system management tools and configuration tools. And I'll be perfectly honest, like I'm not very good at this kind of stuff. I'm mostly a web developer. I spend a lot of time writing Ruby and JavaScript and Java and doing database infrastructure, SQL and things like that. But we've got an ops team and they do a lot of this kind of thing, these kind of things. And these tools all have something in common, which is they're all very command line centric. Using these tools effectively requires good competency in your shell, Unix-like environments. Being comfortable with SSH and servers are doing things like that. And when I sort of got into this world, I was a little bit of a disadvantage. Here's me in 2013. I did .NET on Windows long before I came to the Linux environment and Ruby and things like that. And so command line was like a little bit foreign to me. It wasn't something I was immediately comfortable with. Here's me in 2018, right? And now I completely live in my shell. I vim all day. I almost never leave it. There's really no difference to me between Windows, Mac OS or Linux because I never leave my shell anyway. So obviously something changed in those five years. Something caused me to completely issue window environments and work entirely into command line environment. And that thing was .files. .files is our hero today. Yay, .files, woo! Yeah, .files, right? So .files, this is how you customize your shell environment. And that's what this talk is about. This talk is about how to hack your shell environment, how to customize your shell, how to install tools in your shell, how to upgrade your shell and just make it genuinely kickass and awesome by modifying your .files. And I'll tell you what, if you start to do this, well, this talk is mostly fun. This talk is mostly about tips and tricks and cool things to improve productivity and make you a more productive and happy developer. It does carry sort of like a serious kind of message, which is that if you get competent in this environment and shell environment, it does allow you to be more comfortable using tools like this. I like to say that .files are sort of a gateway drug to ops. That if you really master your shell environment, you won't be so shy about SSH-ing to servers and changing configurations and building Docker images and doing stuff like that. So it's a really good segue from a web development career into being more comfortable in systems management and things like that. So what are .files, right? Simply put, they are files in your home directory that start with a .. So if you see Detilda and you have your home directory, mine looks like this, and all these little files that start with a .. They customize your system. They change the way programs interact. They change the way your shell works. They change the colors on your screen, things like that. And it can be really, really fun. You can go deep down a rabbit hole of changing these things and modifying your environment and learn a lot on the way, it turns out. One thing you might notice is that a lot of these are SimLinks. More on that later. Now, this comes with a bit of a warning. If you start hacking your .files, you will break everything at some point and render your computer almost completely inoperable. At work. And it will be embarrassing. You will be pair programming with someone and find you cannot bundle install because you broke something in your Zsrc. But you will fix it. And that's the key. If you're like me, you learn about technologies in a lot of different ways. Books, online classes, conference talks. But in my experience, breaking things and then fixing them again teaches you the most out of all. And that's one of the things this talk is about, is about breaking your shell and then fixing it again. And this gets addictive. This is an actual photo of me on Christmas Eve in 2015. That's when I got hooked on .files. I was supposed to be visiting home, in St. Louis. I was visiting home. I was supposed to be spending time with my loved ones and my family. And I got totally hooked trying to modify my shell environment and miss most of Christmas. Santa came down the chimney. So I was hacking on my VMRC. We drank a bottle of red wine together and both passed out. So you will miss time with your friends and family if you get hooked on this stuff. It gets addictive fast. But anyway, let's start with shells, right? Shells, we probably all use a shell at some point. Ruby tools are very shell-centric. Rails tools are very shell-centric. This is a boring shell. I call him Larry. I don't know why he just looks like a Larry. But shells, first of all, it's not confused shells and terminals. If you're in macOS, for instance, you load a terminal, something like terminal or iterm, which emulates sort of a Linux terminal and emulates old Linux hardware from back in the days. But inside that, you have a shell. A shell is where you run these commands. And believe it or not, you do have a choice of shells. So by default, macOS and most Linux distributions use a shell called bash. Bash is reliable, it's well-maintained, it works. It's a little bit boring. And it turns out you're not stuck using bash. You can actually change your shell. I use a shell called Zshell, which is a little more exciting and offers a little bit more. You can see by this shell on the beach, by this beautiful California sunset that it's a little more interesting. Hopefully the sky is orange like that because the sun is actually setting, not because it's the sun is shining through some thick plume of wildfire smoke. Pray for us in Southern California, good God. But anyway, Zshell I find a little bit more exciting than bash and I'll show you why. For one thing, it is very similar to bash, but it has just, it's got some things that just make it a little bit nicer, a little bit more ergonomic. I like, for instance, the tab completion comes with colors and sort of better layout. You get nice autocomplete, there's like a little trick. Say you want to CD into a user local bin, right? You can do this little trick, dash U slash L dash B and it automatically expands these kinds of things. So it gives you some slight nice little things to have over bash, but I like it because it's not so different where if you have to use a bash shell, you don't feel uncomfortable, you don't feel out of place. You SSH into your server. It's so much like bash you don't notice, just a little bit better. There are these shells too. These are shells from the 90s where things got crazy fancy and they have like sort of visual menus on the screen and they're like sort of half gooey, half shell. I don't really use them. Some people swear by them. They seem a little bit out, little bit crazy for me, but your mileage may vary, you may like it. But you have a choice. Like I said, I use these shell. I think it's a nice balance between being similar to bash that we're familiar with and being a little bit better. And it comes with a programming language called SSH. And it turns out to change your shell, you run one simple command. You type this into your terminal, next time you open a shell, it will be SSH instead of bash. It's that easy. And it comes with a scripting language, right? And SSH is very similar to bash, so similar that it's almost the same that most of the time if you write a program in one or the other, they are interchangeable. I gotta be honest though, these scripting languages, bash, SSH, they're showing their age, they're quite frankly not very good. They're weird, they have weird scoping rules, they're a lot of foot guns, easy way to mess them up. For any serious scripting, of course, I'm gonna reach for Ruby as hopefully you are, but I tell you what, it is nice to know just a little bit to be able to do some conditionals, some if statements. And if you go hacking your .files, one of the things you learn is just enough bash or SSH to be dangerous, just enough to be useful where someday you're doing Docker files and things like that and you need to reach for that skill, you're kinda comfortable with it and have it in your arsenal. So it's one of the things that I learned, doing .files is just a little bit of bash, right? You can put these in a file, of course, but what's kinda cool is you can modify your shell by editing a .file called Zushar C. This goes in your home directory and in this you can put all kinds of magic that makes your shell even cooler. For instances, you can add aliases. So I have an alias here, BE, which runs bundle exec. Well, let's see, I've gone from like 12 characters to two. Congratulations, I just six text your productivity, right? You all deserve a raise. And that's pretty nice because you can just do BE Rails console, for instance, like that and have less to type. A simple but effective trick for making your shell experience just a little better. I don't know what happened there, you didn't see that. Right, here's another one, BERS, bundle exec Rails server. How many of you type this all day long, pretty much every day? I definitely do. Makes it just a little bit shorter to type. But in your shell, you can also do some other pretty clever things, like you can add functions. So here I made a little one, it's just called MCD. All this does is makes a new directory with the dash p flag, meaning create all those like subdirectories in the path along the way if they don't exist and CD into it. So if you just do something like this, it makes the directory and CDs right into it. So there it is, one nice little shell hack that just makes your life a little bit more ergonomic. And we can do a little better than that. For instance, here's one I love. It just makes a function called g. And all this little snippet does is say, if you type g without an argument run, get status. If you give it an argument, make it get and then whatever the argument is. And so all day long, I can, for instance, let's see here, just type g and get my get status. Ah, a piece of cake, isn't that nice? Or I can g log and get log. And I'm just a little bit more productive if I really like that one. I think that's a great little shortcut. It makes my life a little better. Here's some other ones, right? So this one's kind of funky. I'm defining a function called man. Well, you all might know what happens if you type man in your terminal, right? It pulls up the man page. It throws a manual of certain programs you use. Well, I'm overriding that. I'm creating a function that overrides that. But look at the last line of it. Notice it's calling man at the bottom. And then there's all this term cap stuff. I don't actually know what that is. I took this from someone else's. Dot files are kind of cool in that you can kind of trade snippets with people. More on that later. But whatever this little magic snippet does is it simply gives you colored man pages. Ah, cool. Nice little improvement here. All right. You may have noticed my shell has kind of a cool prompt. This is a default just like boring prompt, tilde, percentage sign. Not very fun, not very useful, not very informative. We can do much better, for instance. The default is kind of boring. What's really cool is we put a get branch in our prompt, right, even better. Unstaged, staged and committed files, right? Even diffs between the origin and things like that. And you might have noticed it, but this is what my prompt looks like. So we have current directory, the current get branch that we're on. The number of commits behind origin master from compared with the server, right? The number of commits ahead, in case you have committed something that's not on GitHub yet. The number of local stage changes and the number of unstage changes. That's awfully useful and awful cool. It took me weeks and weeks and weeks to write the script. It's a labor of love, just kidding. All I did was get clone it. It's a project out there. I installed it and it's pretty awesome and it works. And it does smart things, like I think it background fetches that and there's a timeout so it doesn't freeze your shell if it can't connect to the internet, right? There's also a bash get prompt if you stick with bash, right? Very cool, fun stuff makes me a little more productive. Here's another tool that I really like, moving on. This is a tool called FCF, which is one of my favorite shell tools which is simply a fuzzy find tool. It is first and foremost a Linux tool that I can pipe to and perform sort of a fuzzy search. Cool, all right? So kind of like grep but for fuzzy searching but it also can do some neat things like help me quickly find files in this folder. Oh, very, very neat, right? It's also, I really like it because it improves my shell. You can search, like your command history really easily. And when you dig into it and you dig into the docs there are a lot of cool things. It is sort of closely linked to VIM. So if you are a VIM user, you can use Fuzzy Finder to find things. Let me get into the right directory here. The .files repo, more on that later. But it helps you search your files if you are a VIM user. Now this is not a VIM talk. I could give a whole VIM talk. I would love to give a whole VIM talk but I wanted to do a talk that everyone, because I know there's some not VIM users here. I want to give a talk for everyone but I do want to mention VIM sort of briefly because this does kind of come into play with this whole .files strategy. To VIM or not to VIM? Well, for those of you who don't know, by the way, VIM is this text editor. It's from the 90s. It's purely shell based. It requires you to learn all these like really arcane and weird text commands. It's a text editor that's totally different from anything you've ever used before and it's a very steep learning curve. And there are three phases to learning VIM. Suffering, right? You will hate it. You will not be able to do anything. You will swear that it is the worst thing ever. Stockholm syndrome. This is when you are held captive by kidnappers and after long periods of confinement, you sort of identify them and sympathize with your captors for getting that they are terrible people who are ruining your life. And then number three is the sunk cost fallacy. This is when you have invested massive amounts of time in it and you swear and even though it was a terrible idea and not worth the effort, you've already gone through the effort so you swear it was a great idea, right? It's sort of like having kids. When someone, when a, the only reason anyone has more than one child is that they forgot how much trouble it was with the first one. That's like what's happening when your friend recommends you learn VIM, right? You're forgetting how much you went through having that child. But I will tell you what, even if you do not use VIM as your editor like I do, it is useful in knowing because VIM on your laptop leads to VIM on the server. And it is a great tool to have in your tool belt is to learn just a little bit of it because if you ever have to SSH to that server, modify that config file, a little VIMFU will really go a long way and it pops up in sort of weird kind of interesting places. Like for instance, did you know that if you are in P-SQL, how many Postgres users do we have out here? Yeah! Someone asked me the other day like what is your favorite webpage on the internet? I said it's the Postgres manual page that shows the locking semantics. I'm only nerd. But anyway, you can be here in P-SQL and you can slash E and pop up a VIM terminal, right? Select, whoops, no, quit, which is always the hard part of VIM and it runs just like that, which is like a handy little trick. Did you know that if you were in less, right, man opens less, you can use VIM shortcuts to search. So, control U, control D, page up, page down, those are VIM key command shortcuts. So, VIM key commands, shortcuts, various things, pop up in all kinds of interesting places in your shell and become kind of useful. So, good tool to have, whether you use as an editor is up to you. Anyway, P-SQL, speaking of P-SQL, because I already mentioned that, you may have noticed that my P-SQL prompt looked different than yours. Yes, whoops. You notice I have my name in there. I've got local, which is the name of the local server. You can edit that with the .file turns out. If you put a file called .p-SQL in your home directory, you can change things. For instance, this little bit makes it so nulls show up looking like that rather than just a blank space. This little bit changes the prompt, right? So you know what database or what server you're on, so you don't confuse your local prompt with the production database prompt, which is very dangerous, right? This little bit shows the timing at the end of every query. Kind of cool, so you know how long it took to execute. Nice. But let's move on to a probably more commonly used tool, which is get. There's a file called get-rc. If you put it in your .files, you can change your, you can do everything in completely hacker-get environment. I like this little shortcut. Defom, diff-origin-master-dash-color, right? That just gives us g. Remember my g shortcut? Yeah, it's tying together, right? And there we go. Psh. I like this one too, get-lg, which just makes you a nice little, whoops. Oh, cool. You can kind of see it on the left, but it's actually just sort of like a visual representation. This isn't a very deep repo here, but it gives you a visual representation of your sort of get directed acyclic graph, right? And in here, you can do things like hooks. You can add hooks. I have this little script, so hooks are, right? You can put little bash files in .get slash hooks in any of your repos, and they will run, like for instance, there's a after commit hook, so it will run after you do a get commit. There's a pre-commit hook, so it will run after you do a pre-commit. This is a pre-push script that I wrote. Don't try to decipher it. Before I tell you what it is, has anyone accidentally ever pushed a master? Yeah, right? All right, this is what it looks like if I try to push to master. Aha! Nice, this is saving me a lot of embarrassment, right? And all it takes is a little bash magic in a get hook. Okay, let's talk about Ruby. Ruby has a few .files that you can change to change your Ruby experience. For instance, most of you probably don't use, if you like me, you Google your Ruby docs, right? No sense installing all that stuff when you gem install, so put this in your .file, and it won't waste time when you bundle install, downloading the documents for all your gems. Cool, RSpec automatically had color, automatically run your specs in random order, just by having this in your .files, nice. It was Rails, right? Every time you make a new project, you can have it automatically use certain options, so you don't have to remember how you like to do your Rails new every time, right? Kind of handy, but my favorite, when we're talking about RubyLand is pry, turns out, does anyone use the pry shell? Yeah, turns out you can modify your pry experience in quite profound ways by using .files. So there's a file that's called .priRC, it goes in your home directory, and in it, you can set up shortcuts. So for instance, here, if anyone uses pry by bug, you're probably typing continue next, exit all day for me at CCNN, FF, right? Ah, that's a killer feature, that is a really nice one. You can even install gems in your pry, right? So I use one called awesome print, which improves the sort of the output if you print an array or something in pry or a hash. They look a lot better, they're colorized, they're split across multiple lines, and just by putting this in your pry RC, you can make it use awesome print by default to print everything, which is a huge experience, in my opinion, in the pry experience. As anyone use factory girl to set up fake data in your Rails app, you can use your factory methods, like what does it create and build in your pry if you do this, and that way you can sort of pull up demo objects and things that you can hack around on really with no effort at all. Kind of a cool trick, and I like this one too, this allows me to just run a command called SQL and type in raw SQL, so from a Rails console, right, I can type SQL select star from whatever and just run a SQL command and get the output right there. If I don't bother, want to bother with active record, and I prefer to write SQL. So lots of little hacks, lots of little tricks in ways you can improve your life by putting any type of crazy thing in your pry RC, any Ruby you can run, any gem you can install, any functions you can create, and you can just call the functions from within pry, and in that way completely modify your pry experience. It's really nice. Then there's T-Mux. So T-Mux is a terminal multiplexer, and this is one of my favorite tools. You notice the little green bar down here at the bottom. This is how I run multiple windows in my terminal. There's a window, there's a window, and you can do splits, like that, or like that, and have multiple shells on the same screen. T-Mux, notably, is a shell-based terminal multiplexer. So probably if you're using a terminal, your terminal can also do cool things like this, like splitting panes and stuff like that. You don't need to do this in the shell. You might even argue that terminals do a better job at doing splits and windows and tabs than something like T-Mux, but T-Mux has a huge advantage, in my opinion, and that T-Mux can be run on a server. So, for instance, here I am on a remote server, on an EC2, pretend this is production, right? I can run T-Mux on a remote server, and let's say I am hacking around on a server, I need to run a backfill in production using Rails console and ActiveRecord to try to fill in database objects. Maybe I'm editing config files or I've got like a P-SQL terminal open or something like that. You could have any number of things. I must say, let's up the ante. Let's say you're on an airplane with spotty Wi-Fi. Has anyone ever lost an SSH session and cursed themselves, right? Pop quiz for you. If you SSH in your server and you open a Rails console and you kick off that giant ActiveRecord backfill and your SSH connection drops, does the backfill continue? No, but it does if you're in a T-Mux session, and the kind of cool thing is that you can lose your connection like this, then you can SSH back in, whoop, I'm gonna make that bigger, shh. You can do a little thing called T-Mux LS, see your open sessions, and then you can T-Mux Attached to session zero, whoops, T-Mux, sorry, and get it all back and save your session, and in the meantime, whatever you've been doing has been running. So that's kind of a magic superpower that helps you a lot in OpsLand, and for that reason, I use T-Mux locally, so I use Vim as my editor, and as I'm actually developing Ruby on my local laptop, I use T-Mux because I like the skill that it gives me and the extra tool in my tool belt so that when I do need to run it in the server, I'm already comfortable with it and know how to use it, and in that way, modifying your .files, of course, can help you learn valuable server skills. I should mention that all the colors and everything are totally customizable of the .file. That's where the .file comes in, is you can totally trick out T-Mux in the kind of coolest ways with all kinds of colors and themes and neat stuff. So let's talk about GitHub, right? So what have we done so far? We've created all these configuration files, we have customized our environment, we've added shortcuts, aliases and everything. We need to save these now, right? We don't wanna just sort of start hacking away at our laptop and if we get a new laptop or have to reformat it, it's gone, lost. What we want is we wanna put this stuff in a repo, don't we? So here is how we do that. First of all, create a GitHub repo and call it .files. Everyone calls it .files. Every single person I know names it exactly that. D-O-T-F-I-L-E-S, it's just called .files. Here are mine, so if any of you want my T-Mux setup or my P-SQL shortcuts or my Zsrc or all my aliases, you are welcome, this is a public repo, you are welcome to go find them and borrow them and trade them. That's the kind of cool thing is you trade them like they're Pokemon cards or yo-yos or whatever. What do people trade these, I don't even know what people trade these, is it jewels, is that what people trade? Like you're trading jewels, is that what teenagers do now? I'm not even sure. But it's like trading, right? Sorry. So once you have your .files in a public repo, you can trade them and this is how you back them up. So what you need to do then is a way to install them. And install them is, okay, so you've got your .files in a repo, it's wherever you put your source directory. Wherever on your local machine that you put your source code, put it in there, create your .files, name them without the little . at the beginning so it's just like .zrc, .zrc. And then what you need to do is sim link them into your home directory. So that's the trick then, right? We need like a little program or a script that sim links them from the source directory into your home directory where they take effect the next time you pop open a shell. And there are a few ways to do that, right? I use a little program called RCM. It's from the find folks at Thoughtbot. You just kind of brew install RCM or apt-get install RCM. And then there's a little command RC up, build a slash .files and it sim links them all in and then you close your shell, open it again and then you've got your whole editor or everything is already there set up for you and that's great, right? Because now if you have multiple dev machines you have an easy way to get clone your .files repo, run the little script, sim link the files and now you have your entire dev setup on whatever machine you want. You can do that in a server, right? You can get clone your .files, run a little script, sim link them and now your production server has exactly all the same get shortcuts and things that your dev machine has. It makes them completely portable, which is a really nice thing. This is RCM, right? It's just a very small, minimalist program that sim links your .files for you. You could also use a gem, right? I was picking around my friend, Megan2's .files not long ago. That's what the other fun thing is that like a lot of your friends and notable Rubyists and people you follow on Twitter also often have their .files and one of the fun things is checking out other peoples. She uses a gem called Homesick which I didn't know about. Oh cool. It's just a Ruby gem that does exactly that. It sim links your .files into your home directory. Pretty clever. You can also write your own script, right? And that's sort of the fun in all this is doing some of these things on your own. So for instance, I found this one in Jess Brazil's .files. She's a dev evangelist from Microsoft. Does a lot of Kubernetes and things like that. She wrote her own little bash script and I found it in her .files. So all this does is loop through your .files directory and sim link it once again. So however you wanna do it, do it that way but that's kind of the fun. Part of the fun is learning to do this stuff on your own. And with .files there are kind of two ways to go, right? You can fork them or you can create your own. So here's Sam Fippins. Sam is the maintainer of RSpec. I gave this, first gave this talk at RubyConf Philippines and he's the audience so I was trolling him a little bit. But he forked someone else's .files. So Homesick, Homes.files, right? And in that way there are whole sets of .files out there and you can just fork them, make them your own, start to update them and install them or you can choose not to, right? Sam has great messages, fuck it, restart it, right? I thought that was kind of funny. But then you find cool stuff in other people. So here's one I found which is like, this was in Sam's prior see, right? There's a method here called rye, right? And what you can do with this I thought this was kind of neat. Let me get back to where I was. Boo JavaScript, sorry. Yeah, I found this method called rye. Oh my gosh, let me just do this. I think I can do this through pry. Okay, so and it gives you this little magic ability. You just do this and you type rye and you get the documentation for that class. This is what it looks like up at the top. Oh, sorry. So anyway, what I did is I typed object.ry and it spit out the whole documentation for that. You can also do something like this and you get the documentation for two string. So I don't know. Personally, I don't actually use this one because I Google my dots. But these are the kind of interesting and fun things you find when you start poking around in other people's dot files. Cool pry tricks and Ruby tricks. So the question then becomes to fork or not to fork. On the one hand, if you fork someone's dot files, you get a full suite of really kick ass working awesome dot files and you're off to the races and you're ready to go. On the other hand, if you build your own you really are in for a learning experience, right? You get to learn bits of shell scripting, right? Which comes in useful later. You get to make as many mistakes as possible and then fix them. So it's kind of up to you. There are whole repos out there with just links to awesome dot files and cool resources that you could find. I personally forked mine. So I forked the thought bot dot files which is a massively complex and really powerful suite of dot files from thought bot folks. This is sort of like graduate level dot files I feel like. If you're looking to learn this might be a little too much, right? But if you just want like a really powerful set and really just make your shell really awesome it's beginning without a lot of effort then this is a great place up to you what you wanna do. One quick warning, don't check in secrets, right? A lot of us have various things, SSH keys and things like that, right? In our dot files, don't check those in. What I do is I put this little snippet in my zsrc. This says look for a file called dot local rc and if it exists, source it which is to say load it. And then what you do is you get ignore local rc so you cannot accidentally check that in and push it to your public repo. That would be a bad idea. So in the end of all this, go experiment. The fun here is not only getting a better environment, it's hacking your system, it's breaking your system, it's fixing it again, it's staying up late trying to make the ultimate tmux config or the ultimate psqlrc even though it's a complete waste of time, it's not really because you come out on the other end being competent in your shell, having better tools, having a new hobby, being able to trade this and hopefully possibly in the end feeling more confident in ops, more confident in servers, building a little more courage, courage to experiment with other cool things that the command line leads you to, things like Docker and Kubernetes and feeling comfortable in most environments. So thank you, I've got a few resources here. I've linked to some articles, I will tweet these slides, follow me on Twitter. I'm Brad Irani, I work at Procore in beautiful sunny Southern California. If you like the weather here, come talk to us. We're hiring all roles, Ruby, Android, machine learning, security, DevOps, you name it. I'd love to chat with you about that if you are interested. We've got a beautiful beach view from the office. If you're somewhere cold, move to Southern California where the weather's warm and the forests are on fire. That'll go out though, the forest fires will go out, I promise, they don't last forever. Cool, thank you.