 How many people were just here for the previous talk that Brad gave? Okay, a significant amount, okay, that's interesting. That's good, Brad and I, this is our mini-track on developer tools in Promptu. And I have a somewhat different perspective than Brad, so hopefully you will find both of our perspectives to be interesting. Okay, so this is a talk about workflow and tools. So I wanna start by talking about workflow. This is something that I do all the time every day, several times a week, if not several times a day. It is my like wrap up a piece of code workflow. I finish some code, I run RuboCop or ESLint or whatever else is going on. I commit it to Git, I push it to GitHub, I open a pull request. I assume most of you do this a lot of the day. Now, if you just use the tools as you would hand them to a new developer on a fresh machine who has not had the time to optimize this environment, this is a multi-step process. This is a 10-step process, accounted. I run bundle exec RuboCop or whatever other things or possibly more steps there. I run a git status to see what files have been changed. I run git add to stage them in git. I run git commit, I edit the message in my editor. I git push origin branch name, I open GitHub. I create, GitHub has a button for me to create a pull request. I do that, I edit the pull request, I hit another button to create it. This is a lot of steps. I'm deliberately kind of making this sound like the beginning of the infomercial where it's really, really hard to boil an egg or something like that. But still, this is a lot of steps. This is a lot of complexity. In order to do this, I have to have at top of mind five different commands, four git commands plus my RuboCop. And maybe more to the point, what's the most important piece of this workflow? To me, the most important piece of this workflow is making sure that the changes that I think are going into the repository are actually going into the repository. And that important step is buried. It's technically the git add step. But there's a lot of stuff around it. And if you start cutting corners, if you start getting frustrated because you're doing the same 10 steps over and over again, it becomes easy to jump over the most important part of the process. But at the same time, that's not what I do day to day when I do this, and it is probably not what you do day to day when you do this. Every single one of us creates our own workflow for doing this with our own set of tools and our own likes and dislikes. And he was talking yesterday about tribal knowledge. This is a kind of tribal knowledge that we pass from person to person about the best way to commit something to git. And there's a very, very strong difference here between novices and experts. I saw this working with some apprentices over the summer that even maybe more salient than the differences in our knowledge of how to use Ruby, the knowledge of how to use editors, how to use git, how to use a terminal window, in some ways, an even bigger gulf. So this talk is called the Developer's Toolkit. My name is Noel Rappin. You can follow me on Twitter at Noel Rapp. There's a very strong possibility. We will not have time for Q&A at the end of this. So please do hit me up on Twitter for questions. That would be great. I also will be around during the rest of the conference. I work for a company called TableXI, which is a consultant company in Chicago. We're currently running a Kickstarter for meetings that we'll talk about at the end if I have a moment. I also do a podcast called Tech Done Right. Guests on this podcast have included two of the conference, one of the conference organizers, two of the keynote speakers, multiple other speakers and attendees of this conference. If you are enjoying the conference, you will probably enjoy the podcast. It's not just a Ruby podcast, it has a lot of Rubyists on it. That's it. Also, links to everything that I'm going to discuss in this talk and some other notes and some things I didn't fit in are at that bottom link, Bitly Dev Toolkit sheet, which I'll show again at the end. So you don't need to take pictures. You don't need to write down all the URLs. They're all online. And the slides will go up afterwards. OK, so there's two parts to this talk. The second part, which is probably what you're all here for, is a list of cool stuff that I use that will probably make your life easier. And you'll get there, I promise, we will get there. But I also want to back up a second and talk about why this stuff is important and what makes a tool useful to developers and what to think about when you look at this array of complicated tools and things that we used on a day-to-day basis. How do you think about which ones to add, where to spend time improving things, and what is not a great use of your time? So what makes something useful? Well, one of the things about programming is that we have to attend to detail, a lot of different details, and details at a wide range of orders of magnitude, ranging from individual bits and bytes to ProCore's million lines of code, or gigabytes of data. This is just a tremendous range of detail that we need to deal with. And brains are not great at that. It's not really the high point of the human brain is like managing detail. Particularly managing detail at different levels of scale is something that brains are not very good at. So to me, the important part of the tools that I use and the workflows that I deploy them in is that they allow me to focus on the important piece of the information. We talk a lot about, we use this thing because it saves us some keystrokes, and that's great. Saving keystrokes is good, but it is an end to the final goal. The final goal is not about saving keystrokes. The goal is about saving your memory and saving your focus. And minimizing potentially places where you might make mistakes on a regular basis. Things you might mistype or something like that. So simplifying your workflow is about, some of it is about minimizing the amount of steps, but minimizing the amount of steps or minimizing the amount of things you type is only a means for that final end of making sure that you are keeping your attention on the things that are important and not bringing in a lot of incidental complexity from the tools that is going to prevent you from focusing. Like one of the keys to, and I'm convinced after doing this for a while that one of the keys to success and development is your ability to minimize the amount of load in your brain, the amount of cognitive load that you have, that you need, the amount of things that you need to worry about in any particular time. And your tools can help you with that or they can get in the way. Our tools are very complicated and they are very, very flexible. Brad gave a great talk right before that was largely about all of the different ways that these tools are flexible and all the ways that you can customize them to do what you need or want them to do. And we as a developer community I think have an interesting relationship with complexity in our environment and in our tools. We expect it. We don't even notice it sometimes. Like if you, we become a sort of immune to it. That, you know, I mentioned that this was a, that committing something to GitHub is a complicated multi-step process and some of you probably went, no it's not, I do it all the time. But, you know, if you ever sit down and try to explain it to somebody who's never done it, it is a complex process. But we, we come to sort of get used to that kind of thing and in a certain way we kind of valorize it. Like we use complicated tools, I can master a complicated shell tool or I can master a complicated editor, this must mean that I am good. I am a smart good programmer because I can handle these complex tools and, and then it becomes, which like is fine as far as it goes but when it goes to the next step of the only way that you can be a smart good programmer is to master these complex tools then that becomes a problem because it is not really the only way that you can be a, a, a good programmer. Like command line tools are great and I don't want anybody to come out of this thinking, oh Noel says don't use command line tools ever. Like command line tools are wonderful and a tremendous amount of effort has gone in over the, you know, the last decades of work into making these tools really powerful and really flexible. They're also like opaque and memory intensive not of the computer but of our memory. Like one of the, one of the things about having a bunch of aliases or lowering all of these command line tools is you have to remember that they're there in order to use them. You have to remember the options in order to use the options and, and it is a, a burden that you place on yourself and so these tools as wonderful as they are they have costs. You know, when the Unix command line was originally being created computers kind of looked like this, this is a 1976 deck thing, computer thing. I think it's running deck, I can't quite tell from the file layout. But it's basically like an 80 character by like 40 character layout, right? My current workspace, this is my desk, it looks like this, you can see a picture of the older computer in the middle of it, right? I have a lot of screen space. I have, you know, this regular laptop screen. I have a entire 4K second monitor. I have like Weird Al and Mr. Rogers Funko Pops helping me rubber duck, which definitely did not exist in 1976. I have, I have all of this space that I can put things that I don't necessarily have to keep in my brain, right? And I, I, as wonderful as command line tools are like it is hard for me to accept as somebody who's like done user experience research in the past, it is hard for me to expect, expect that that is like the be all and end all of the developer experience was like frozen in 1979 and we're never going to get better at it. Some of these tools are great and sometimes it's the right thing to do, but you don't need to be a command line expert at everything to be a real programmer. Like a lot of the tools that have great command line things, now there are also great non command line options that have certain deficits relative to the command line, but also certain benefits. And I think what I want, what I want you to be aware of is like where the cost is and where this kind of invisible cost of having to memorize all of these tools and all of these options comes into play. So let me put this a slightly different way and talk about three kinds of tools. This is a stenotype, the kind that a court stenographer might use. Yeah, these are kind of, these are amazing machines honestly. A trained operator can use this to keep up. I'm not sure exactly what they're using to live caption it, but it's something similar to this. Somebody, a trained court stenographer using this tool can keep up with human speech at 200 words per minute, which is like three to four times my typing speed and I'm not a bad typist. But at the same time, like if you sat in front of this, what would you do? The key to don't have labels, it actually turns out that the mechanism by which you use this is not a regular typing mechanism, it's a courting mechanism where you hit multiple keys at the same time and the left keys are consonants and the right keys tend to be vowels and all in all it's like really opaque and it takes months if not years to learn to be certified and it actually turns out that everybody creates their own idiosyncratic set of macros. So even if you know how to use one machine, if you sit out at somebody else's machine you don't know how to use it, so let's see. It's opaque, it takes a long time to learn, it has an idiosyncratic set up, oh my God, it's Vim. So my normal theory about Vim is that, here's what I believe, in some ways like every time you talk about tools that developers use you wind up, like Vim is like the magnet that you wind up talking about Vim somehow even if you don't wanna talk about Vim. I think that if you are an entry level developer and you do not already know how to use Vim it is not a good use of your time to learn how to use it. And my argument for this is pretty simple, other editors are also good. They may not be as good, they may not do 100% of what Vim does, but on a day to day basis they probably do 90 to 95% of it and they probably have like 20% of the learning costs. That seems like a good trade off to me and that is like, this is the thing that I normally tell novice developers, and I think that this is also true as a senior developer. If you're already using Vim and you're getting productivity about it out of it, great. Like you have crossed that curve and like Brad said, like there's some cost fallacy, like more power to you. That's great. I'm not sure at this point if you are comfortable with something else that like learning Vim gives you a whole lot beyond as Brad also said, like mowing like the five commands that will help you not kill yourself on a remote editor, although I'll show another solution for that in a bit, is useful but becoming an expert in it. And I've seen people who are tremendous experts in Vim and it seemed very productive. It feels to me like it optimizes the part of the process that I don't need optimized, but again, like one other thing that's true about this is that everybody reacts to tools differently because we are all different people, but I still think like from a cost to benefit ratio learning Vim is maybe not like the best thing that you can do as a novice level. I also, I have a little sidebar rant here which is like that the secret, that the reason that the fact that Vim is still successful like in 2018 means that something about user expertise or user experience or workflow that we don't understand. In the same way that they used to believe that bumblebees were impossible based on what we knew about how aeronautics works. Like Vim seems like it should be impossible given what we know about how user experience works but apparently like something about the way expertise and user experience interact I think is like under explored but that's kind of a sidebar. So all right, second kind of tool. This is a waffle iron. Waffle irons to me are a class of tools here. Here's the important fact about a waffle iron. It's really valuable if you wanna make waffles and it is basically useless if you wanna do pretty much anything else except possibly a paperweight. But at the same time like waffle irons are so easy to use that hotels around the world put them out for the general public to use and free breakfasts without expecting that people are going to burn themselves which is a pretty high bar for ease of use honestly. So there's a whole class of tools that we have that are like and I'm gonna show a couple of these later that are like single use but relatively easy to use if you're doing the thing. And this is also like on the command line this is like tools like Grapp is also like your terminal program to some extent your editor there's a lot of text editors that kind of fall into this. They're very helpful in optimizing a relatively well-defined task. The kind of tool that I'm kind of most interested in from a work close down point is reflected by this. This is a curb cut. So we're looking at the ramp leading up here. Do you know the story behind curb cuts? Does anybody know anything? Cool. Or you're just not paying any attention at all at this point I could say anything. Curb cuts although they're really, really common in US cities now are relatively new. They were first created in Berkeley and they were first used not created used on a like a significant basis in Berkeley in the early 70s to help a new inflow of electric wheelchair using university students who could not get around the city. There's a kind of an urban legend that activists went out with Jack Hammers and created a bunch of these. That's like overblown at best and possibly completely apocryphal. At the same time they did create these. And to me the interesting thing about this kind of tool from a like a workflow kind of perspective is that once it is there it takes no extra effort to use it. And not only does it take no extra effort to use it but although it was originally created to help people who are in wheelchairs it is also valuable for many, many other kinds of tasks. Like if you're on a bicycle, if you're on a scooter if you are pushing a stroller with children if you are pushing a heavy cart on wheels like all of these things the city becomes much more navigable for all of those things at essentially no ongoing cost. And so like these are very valuable and I think we actually do have a lot of these things in our potential work environment where there's some set up cost but once they're there they just provide value. So I'm thinking about like setting up your prompt putting things in your menu bar that you can, so with status information syntax coloring qualifies here. Like once it's there it just helps. There's a lot of things that sort of fall into this general category of they have an upfront cost but no ongoing cost. And no ongoing relatively little ongoing mental cost to keep them there. Okay so what? Like what does this have to do with anything? Just a couple of guidelines about what, how to think about the tools that you use. Like I think that like we have tools that are like stenotype machines and you should choose them very carefully which ones you want to become a part of because not only do they take a lot of time to learn they're a skill that needs to be maintained otherwise you lose it. So have a good sense when you pick an editor a programming language, you know an operating system of what you're going to get out of it. Not that you never do these things but that you have basically a limited capacity to do these things and you should choose it wisely. Waffle iron kind of tools like you have a limited counter space for them you'll notice that like professional chefs don't have 40 million knives they have like one good knife. At the same time like again like if there's something that you do regularly and there's a tool that makes it easier like these are great. The limiting factor here to some extent is the number of things that you can remember that you have like I don't know about you I have all kinds of single use tools on my computer that I forget that I have completely and therefore never use so they are not valuable. That is like the limiting factor here is how much of these things that you can remember that they even exist and that you installed them. How many of you had the experience of looking through your applications directory and going oh I didn't know that was there? That looks useful. But if you can find things that are curb cuts again because they have no cost and again especially like in modern displays you have like a lot of space to play with and there's a lot of things that you can do with them. There's an interesting tool that a few years ago I haven't seen it in development recently but there's a tool called Geek Tool which basically lets you dedicate arbitrary parts of your Macintosh desktop background to like run the results of arbitrary scripts. So you can have like arbitrary status at various points and you're like that's the kind of thing I'm talking about. Like it's just displaying information somewhat passively. Okay, that's like the vegetables part I guess. And here's the stuff that I actually use and think about. These are some tools that I think are generally helpful and I'll try to talk about how they're helpful and why they're helpful. Brad talked about bash prompts, shell prompts. Mine is a little bit different. This is the ZShell peep code theme with a little bit of customs stuff here. I have here, it has the present working directory somewhat less usefully. It has a smiley face or frowny face emoji depending on whether the last command succeeded or failed that has very little value but it's cute. It tells me what Ruby I'm currently running. It tells me what Git branch I'm in and what Git SHA I'm currently running. I've become pretty dependent on having the Git branch and Git SHA in those locations because I use them to tell whether I'm actually working in the code that I think I'm working in. But again, this didn't take long to set up and now it is just here. Brad also talked about aliases, shell aliases which I think are great. I have a good Jillian of them. Oh my ZShell defines a Jillian of them. I can't even remember all of them. And that's part of the problem, right? Part of the problem is remembering that you have these things. Again, like the theme that I keep coming back to. One of the ways that I mitigate that is I don't name, so I try not to use aliases although I do do some just to minimize typing. I try to do them to minimize complicated option strings that I don't wanna have to remember and I try to give them names that I will remember that are not like super cryptic. I'm not trying to play golf with my alias names. And I think that this helps. Another thing that I do for the use of server, on a server is I use, I actually use Alfred for this but TextExpander or something like that lets you create effectively like snippet replacements and those work wherever you type. So those will work if you are typing into a remote SSH server whereas your normal like shell defined aliases won't. It's kind of a workaround. I find it to be useful. I have a couple things that I do that with. But the most important thing that I do to deal with complex commands that I only run once in a while is aggressive use of command history. I use the ZShell command history plug-in which I'm gonna show a short little video here. I think that you can see this if I get this thing to run. There we go. So I'm typing a Y. You can see my keystrokes at the bottom. Typing, I'm trying to get a yarn command. I'm typing YA and then I'm going up arrow and it's showing me all my commands in my bash history that show yarn arrow and then I'm going down arrow doing that. There are more complicated ways to do this by default. It's not set up for this. You need the plug-in to do the up arrow, down arrow. If this was taken away, my productivity would crater because basically every important thing that I use, every complicated command that I use, I use this to find it. Like I run Chef commands like once every three months and the only thing I know about them is they contain the word knife. So I type knife and then up arrow and then it's like, oh, it's there. So this is, I on-board, I off-board a lot of memory to this command history and to turn up the command history as much as possible and there's a couple of other tweaks that you can do to make this more valuable. So I also use a tool, a command line program called Jump which is at this GitHub repo. What Jump does is you type J and then you type in like a piece of text and it goes to a directory that is either the most recent you've used or something you use a lot, you use like a combination score system that contains that snippet. As a result, I do not have to remember where on my file system anything is. I just need to know what it's called and if I've used it recently, then I just go to it with Jump. Brad showed Fuzzy Finder, I don't use it as much but I also use it. So here, Double Star gives you a little Fuzzy Finder thing here. Again, the way I use these things is to not have to remember where stuff is. Also a life hack that I learned from Justin Searles is that everything that I take from GitHub is stored in a directory called GitHub where the sub directory is the name of the GitHub organization and then the GitHub repo. So all my tableXI files are like slash tableXI slash whatever, all my personal ones are slash and will wrap and slash whatever. So the directory tells me where it is on GitHub. That's a tiny little life hack that I actually use, that I use all the time. If you're on a Mac and you use the like local, the default terminal program, like I highly recommend that you look at iTerm2. iTerm2 has a number of cool features. iTerm2 has a number of cool features that enhance, you'd think like, what can a terminal do to enhance like typing characters? iTerm2 does some neat stuff. One of the neat things it does is if you click on a URL or a file name, it will open it. So it will open the URL in your browser, it will open your file name in your editor of choice where you can, if you go to like profiles, whatever, whatever, you can pick what editor you want. If the file name has a line number, like it's file name colon line number, it will open that file to that line. So like if you are looking at like a stack trace and you wanna go to the line in the stack trace, it will do it. It also lets you option click to put the mouse anywhere on the line you're typing rather than having to arrow back and forth through it, which is very nice. It can show you a list of processes that are running in that shell graphically so that you can point to one of them and kill it from the GUI. It will, it also can, you can have a keyboard command to open a new tab in the directory you are currently in, which is a small thing that saves a lot of time when you're setting something up. It can be configured if you are logged into a remote SSH, it can be configured to if you drag a file on top of the window to SCP it to your remote directory. So a lot of these things that are like, it does a lot of things that are very nice. So I recommend looking into it. Okay, Git. Let's talk about your first second. Git has this like fantastic, very elegant internal, this terrible command line interface that is kind of ridiculous and overly complicated. A couple things that I'd use to sort of deal with it. Hooks, something Brad also mentioned. If you put stuff, if you put scripts in like .git slash hook slash like pre-commit or pre-push, like those scripts will automatically get run before at various times in the life cycle there's about a dozen of them. There's a link in the notes here that will take you to them. This is great. It happens automatically. You don't need to worry about it. This is the table Xi standard for like RuboCop in a pre-push hook. I think that what this is doing is only running RuboCop on the files that have changed which makes it faster because those would be the only ones that would potentially have RuboCop errors. It's a very useful thing to get used to. We also have a setup where we can set up a directory in our repo and have our Git like look there so that everybody's running the same hooks. It's also very nice. I really strongly recommend, another one that people are probably gonna look at me cross-eyed for, I recommend Git GUI tools rather than using Git from the command line for a lot of the same reason that I recommend doing all kinds of stuff from GUI tools rather than the command line. There are a lot of GUI tools for Git. Some of them are terrible. Some of them are really expensive. Some of them have really crazy user interfaces. I have come to like this relatively new one called fork which is for Windows and Mac. So if you wanna see a Git log, it will show you the Git log. Like this, here it is. There's my Git log. I still have the lines of stuff showing the branches. It gives me the name. This is a very small one because all of my complicated ones are client ones and I didn't wanna show any of those. But name, user, SHA, date. I can see all the origin ones. I can see the individual commit, the details of each individual commit when I select on it. I can also, for an actual change, I can see all the files that have been changed and I can see the individual changes and stage or unstage them on a case-by-case basis. I can also type in the commit here. It knows about the convention that the title of a commit is the first line and that only goes 50 characters. So it will warn you if your first line is over 50 characters. It does a bunch of other really cool things. It will allow you to interactively rebase. If you choose a rebase, it will show you all of the commits that are going to be rebased. You can change the order or choose not to rebase some of them. It's really nice and I like it a lot and it means that I don't, there's a lot of clutter in my brain of get command line options that I don't need to worry about. It's still good to know some of the basics. There's some things that this is not perfect at, but it's really nice and it's currently free. I don't know if it's gonna be free forever. GitHub. People know about typing T at GitHub on GitHub. Everybody simply live alone. If you, yes, if you type T on a GitHub file page, you get a fuzzy finder for the repo. I have found that people don't know that, so I thought I'd throw it in here. If you type in W, you go to your branch history. There's a couple of other ones. If you type in question mark on GitHub, you actually get a list of keyboard shortcuts that has a couple of things that I didn't know were there. GitHub also started doing this. When you push something to a remote server, this is really new, I think. They started doing it, I think they started doing it the last couple of months. If you push something to a remote server, GitHub throws out this line that you can create a pull request by going to that URL. I use iterm. I can click on that and I go right to there and I get the pull request is there and it's in the right branch and it's ready to go and I just need to edit it and go. This is very nice. I don't know when they started doing it. I just noticed it one day and I was like, that's strange. GitHub also maintains a command line tool called hub, which allows you to interact with GitHub from the command line. I usually recommend that you alias it to git and it just adds a bunch of other commands that let you do things like create pull requests. So I actually have this alias for a common case where I have a commit that has, I have a pull request that I wanna do that creates just one commit, it has just one commit. I've committed that and so now I have this git pull request quick alias. It creates a pull request using hub. It says no edit it so it takes the one commits, the first commits message and makes it the message for the pull request and the title of the pull request. It pushes it up and then it opens up the browser in the right window, all from the command line. So sometimes command line tools are really nice for this kind of thing. Editor tricks. How many people here use, what do we use here? Vim, Adam, Sublime, VS Code? Yeah. I've really taken to VS Code and Adam over the last little bit. I think their ecosystems are rapidly overtaking the ecosystems for some of the other relatively, that's certainly Sublime and some of the other ones. So here's just a couple things that they do. This is an Adam plugin called RegEx Railroad Diagram. It does not exist on any of the other editors. A lot of these other things do exist and multiple things. This does not exist in the other editors. If you put your mouse over the regular expression it gives you this railroad diagram at the bottom displaying what the regular expression does graphically. It's pretty cool, yeah. Cool, somebody said what, gasp, that's good. That's all I wanted out of this entire talk. Unfortunately it seems to have kind of been abandoned and nobody's done it for other editors but I thought it was really neat. This is Visual Studio. Visual Studio has this top level outline. Notice that it has my, I don't know how well you can read it but it has app and then models and then my, which is directory, directory, file name inside the file name. It has the class and it has all the methods. You can navigate this through this in Visual Studio code. There's also an outline view on the right which is not open here that does the same information. This is provided by Visual Studio by a gem called SolarGraph which is a language server. It parses Ruby into like a common format that editors can use to do this kind of thing. There's also Adam support for SolarGraph. It's not as far along but SolarGraph also does a couple of interesting things. If you like autocomplete you'll notice here I have a literal string talk. I've typed dot s and I am now getting recommendations of string methods because it knows that I'm typing in a string that start with the letter s. This is like the kind of thing that I would have thought was basically impossible to do in Ruby. SolarGraph is not perfect in this respect but it's kind of decent in many ways. You'll also notice that it is giving me the, not just the name of the method but it is also giving me the signature of the method. So that's using the SolarGraph support and Ruby support in Visual Studio code. If you type a lot of HTML or CSS you should know about a tool called Emmett. If you don't know a tool about a tool called Emmett already. Emmett lets you type in, here it's gonna, I'm typing in like div plus UL slash UI item times five and then I hit tab and it just creates that and notice that it knows I'm in a Hamel file so it's giving me a Hamel format. If I was in an ERB or an HTML file it would give me ERB or HTML. It has really good integration with all the different editors. It has a lot of different ways to like take a reasonably memorable and easy to use syntax and convert it into longer tools. It has a weird thing where you can put your cursor over a number and it gives you a command to increment the number in place which is, if you're doing like CSS and you have to do that a lot, it's kind of nice. So okay, I'm running out of time and I have other things to do so. This is just basically the change view in Visual Studio Code. You can see any change that you've made and revert it with the X, they both have great, they both have great get and give up support. This is also showing they have RuboCop support but I am running low on time. If you don't know about Fira code as a font, it is a font that handles ligatures type things where it will take two characters that go together and it will draw them as a common glyph. So it's doing a hash rocket in the first one and a shovel operator in the second one. It's worth looking at to see if it will help you make your code easier to read. A couple of web-based things. Rubular, which you probably all know about or you may know about is a testing tool for Ruby regular expressions. The thing that I did not know about Rubular until quite recently is it has this make permalink button where if you have a Rubular setup where you have your regular expression and test ring in it, you hit make permalink, it will give you a permalink that will come back here to the same regular expression in test string. We use it in comments for our code, every time there's a regular expression, somebody puts in a comment to a Rubular permalink so that you can see the regular expression in action. Similar tool for a time format called for a good stirftime that lets you build up, that lets you build up the, I can never remember these things. You can build them up on here and it will tell you exactly what string you need to do exactly what you want. A couple of Mac things that I just want to bounce through because I am getting low on time. Alfred, if you don't use Alfred, Alfred is a program launcher that lets you launch programs using your keyboard without doing a lot of mouse digging. It does it by text. It has a tremendously powerful plugin ecosystem. Here I am using the GitHub plugin to search my GitHub repos, to go to my GitHub repo. It also is a calculator. The cool thing here is that if I hit the bottom action it will take the result, put it in the clipboard so I can paste it somewhere, which is very useful. I also use a thing called Better Touch Tool, which lets you create system-wide Mac keyboard shortcuts and system-wide touchpad shortcuts that do a lot of system-related things and also application-specific things. I have, for example, three-finger swipe set to move something to the next monitor. So if I have something on my main monitor I want to move it to my second monitor. It's a very satisfying three-finger swipe on the trackpad and it just goes over there. It's very nice. Dash, we were talking about man pages before. Dash is a really cool standalone Mac program that integrates documentation for all kinds of basically every programming tool. This seems like the most useless thing ever except it has great search and it integrates with editors and it formats this stuff really nicely so you can, rather than doing a bunch of Google searching you can just open up Dash and type in the keyword and see the definition of it. Transmit is Mac tool for file transfer. So I actually don't use Vim for remote if I can, for remote editing, if I can help it. If I can do it I open up the remote editor in Transmit and then Transmit will let me open up the remote file in my local editor and we'll save the result back when I'm done with it. Also for SQL visualization there's SQL Pro and Postico, SQL Pro does MySQL, Postico does Postgres. This is Postico. It is a visualization of the GUI. You can also edit stuff in place. If you, I may or may not have used this to edit production databases. In the past, it's a little bit safe. I will say that it's a little bit safer to edit a production database cell by cell here than it is to do it with a SQL update statement. But I don't recommend doing either one, so, you know, shh. But this is also really good. You can run arbitrary SQL commands in here. It has a terminal to run arbitrary SQL commands and show the results graphically. I find this useful. I find it more useful than a SQL command line. If you are finicky about Windows setups there's all kinds of tools that let you show, I'm actually gonna skip over this one because it's not as important, but I do wanna rehabilitate one particular piece of Mac tech that people love to kick on which is the touch bar. If you have a new Mac touch bar, from my perspective the touch bar is fantastic because it is like the best curb cut in the world. Like it is this thing that I can put up here that I can put like any 10 buttons I want for any public program I want to do whatever I need it to do because, and this is key, better touch tool lets you create custom touch bars on an application by application or system basis. So this is my Visual Studio code touch bar. It is basically 10 commands that I use all the time that I can't remember the keyboard shortcuts for and I put it up here in bright colors and now I remember them. I remember that they're there. I find this to be tremendously valuable. I have a similar one for iterm. Iterm actually lets you do this natively. Most of these just put small snippets of text into the code base and they save me a fraction of a second every time. They prevent me from mistyping things that I type all the time. It's generally pretty useful. If you have a Mac with a touch bar and you are down on it because you're missing your escape key, better touch tool will wipe. There's a whole ecosystem of system level things that are pretty cool. There's a lot of cool things that you can do there. Okay, so remembering that original GitHub task, finish some code, RuboCop, commit, create PR. Here's how I actually do it. I open up fork. I examine the changes easily and visibly in fork. I edit the commit message in fork and then I commit, my RuboCop runs automatically on the commit or on the push depending on how it's set up on that particular project. And then I have a couple of one step ways. Either I use the alias that I showed before. Fork can push it up to GitHub or I can click the link in the command line output. So I've taken this 10 step process and I've moved it down to a much fewer number of steps and also one that the examine changes is now like a first class part of it. It is almost impossible for me to go through this process and not interact with the changes that I've made and one by one interact, come in with them. There's a lot less other sort of junk that I need to remember in order to get this done. So, things to look for. Knowing that you're just getting in the mindset of can this be improved, can I do this better is a really important first step. Not accepting that the way that the tools are handed you is like the be all and all is fantastic. So look for, I do these steps all the time and maybe I can simplify them. Look for mistakes that you make frequently. Look for things that you wish you could see that you wish you had visualization into. So that's it, that's all I've got. I'm sorry I'm pressed for time so I'm sort of rushed here at the end. A couple things, again the bottom line there is a director's notes with all of this. These slides will be up online shortly. The podcast is at techdonewrite.io. Tablexide.com slash Kickstarter is a Kickstarter for a bunch of cards that you can use in meetings. We're calling them inclusion cards and there are a bunch of cards that you can show up that say like hey you interrupted me or hey this is a tangent or hey speak up and they're a really good way to have meetings flow better and make sure everybody gets heard in a meeting. One thing we also do with them is we give the CEO a limited number of cards with opinions on them and if he's ever gonna give an opinion rather than ask a question he has to play a card and he has a finite number of them. It's really cool, you can talk to me afterwards about that. That's all I've got. Thank you for your time. I'm sorry I ran a little bit over but I will be around if people have questions. Thank you. I'm sorry I ran in time.