00:00:15
How many people were just here for the previous talk that Brad gave? Okay, I see a significant amount of you. That's interesting. That's good.
00:00:23
Brad and I have a somewhat different perspective than he does. This is our mini-track on developer tools. Hopefully, both of our perspectives will be interesting to you. This talk is about workflow and tools, so I want to start by discussing a workflow that I engage in frequently.
00:00:42
I have a routine I follow every day, often several times a week, if not several times a day. It’s my code wrap-up workflow. When I finish a piece of code, I run RuboCop or ESLint, depending on what else is going on. I then commit it to Git, push it to GitHub, and open a pull request. I assume most of you perform similar tasks throughout your day.
00:01:09
Now, if you were to utilize these tools in the same way you would show them to a new developer on a fresh machine—who hasn’t had the chance to optimize their environment—this is a multi-step process with a lot of complexity. I've counted it; it can be as many as ten distinct steps. First, I run 'bundle exec RuboCop' or whatever linter I'm using.
00:01:30
Then I check the Git status to see what files have changed. Next, I run 'git add' to stage them, followed by 'git commit' where I edit my commit message in my editor. Then, I execute 'git push origin branch_name', open GitHub, and press the button to create a pull request. After that, I edit the pull request and hit another button to finalize it. This may sound exaggerated, but it really is a complicated process.
00:02:01
This multi-step workflow requires me to keep in mind several different Git commands, plus other tools like RuboCop, among others. Therefore, what's the most critical piece of this workflow? For me, the most important aspect is ensuring that the changes I believe are being committed to the repository are actually being committed.
00:02:23
That crucial step is the 'git add' step, but it is often surrounded by other steps, and if you start cutting corners out of frustration with the complexity of these repeated tasks, it’s easy to overlook this important piece of the process.
00:02:57
Moreover, although this is part of my routine, I recognize that it is likely not what you do on a day-to-day basis. Each of us creates our unique workflow for these tasks, shaped by our personal toolkit and preferences. This is somewhat akin to the tribal knowledge that often circulates, as was discussed yesterday.
00:03:19
There’s a marked difference between novices and experts in this regard. I noticed this while working with some apprentices last summer. Their lack of familiarity with tools like Git and terminal windows presented a larger knowledge gap than even our varying levels of understanding Ruby.
00:03:37
This talk is titled 'The Developer's Toolkit.' My name is Noel Rappin, and you can follow me on Twitter at @noelrappin. There's a strong possibility that we won’t have time for Q&A at the end of this presentation, so feel free to reach out on Twitter with any questions.
00:03:55
I’ll also be around throughout the conference. I work for a consulting company called Table XI in Chicago. We’re currently running a Kickstarter for some cards that we’ll discuss at the end of this talk. Additionally, I host a podcast called Tech Done Right, featuring guests who include conference organizers and keynote speakers.
00:04:18
If you’re enjoying the conference, you will likely enjoy the podcast as well. It covers a range of topics beyond Ruby, and the links to everything I will discuss in this talk will be shared at the bottom link, bit.ly/devtoolkitsheet, which I will show again at the end. You don't need to take pictures or write down all the URLs; they’ll all be available online, and the slides will go up afterward.
00:04:54
There are two parts to this talk. The first part outlines why this topic is important and what makes tools useful to developers. The second part, which I'm sure many of you are eager to hear, will list various tools that I use, which could make your life easier. I promise we will get there.
00:05:24
Before diving into tools, let’s first talk about what makes something useful. One aspect of programming is the continual need to manage a variety of details, spanning from individual bits and bytes to codes encompassing millions of lines and gigabytes of data. Our ability to manage this detail is limited.
00:05:49
Therefore, the essential role of the tools I utilize is to help me focus on the most important pieces of information. We often debate the value of tools that save us keystrokes, but it’s important to remember that the ultimate goal isn’t merely about saving effort. It’s more about preserving your mental focus and minimizing mistakes.
00:06:12
Simplifying our workflows reduces the number of steps to complete a task and minimizes cognitive load, helping us keep our attention on what’s crucial rather than being overwhelmed with incidental complexity.
00:06:27
One key to success in development is the ability to decrease the cognitive load on your brain regarding the multitude of tasks and responsibilities at any given moment. Effective tools can help ease this load or, conversely, create barriers that hinder productivity.
00:06:47
As Brad mentioned earlier, the flexibility of our tools is impressive, and our developer community has a unique relationship with the complexity of our environments. We often become desensitized to this complexity.
00:07:06
What may seem like a simple process, such as committing code to GitHub, can feel intricate and convoluted to someone new to the task. As experienced users, we might overlook the complexities we navigate effortlessly but may not be as obvious to others.
00:07:30
We often place high regard on mastering complex tools, as if that mastery equates to being a competent developer. However, it’s essential to recognize that being a good programmer does not solely hinge on your ability to master complex tools.
00:07:50
Command-line tools have certainly evolved over the decades and are indeed powerful and flexible, but they can also be opaque and memory-intensive. We must remember that we bear the burden of remembering the intricacies of these tools, their options, and their aliases.
00:08:06
While the UNIX command line emerged in a time when computers looked vastly different from today, we now have extensive workspace capabilities, yet we often still rely on outdated mechanisms to manage our workflows.
00:08:25
With the ability to have multiple screens and advanced tools, the expectation of only using command-line tools for everything feels archaic. You don’t need to become an expert in everything to be an effective programmer.
00:08:45
Among the available tools, there are indeed effective non-command-line options that may have limitations compared to command-line tools, but they also have distinct advantages. It’s essential to understand their costs, particularly the invisible costs related to how many tools and options we must mentally track.
00:09:01
Let’s consider three types of tools. The first is a steno typewriter used by court stenographers. This machine allows a trained operator to keep up with human speech at speeds of 200 words per minute—three to four times faster than my typing speed.
00:09:30
However, utilizing this tool requires months or even years of training to reach expertise, and it’s worth noting that each operator ends up creating their unique set of macros. Consequently, knowing how to use one machine doesn’t translate to being able to use another.
00:09:53
The next category of tools is much simpler—waffle irons. Waffle irons are excellent if you want to make waffles but are virtually useless for anything else. There is a straightforward, intuitive quality to these tools that makes them user-friendly.
00:10:05
A key lesson here is about the value of simplicity in tools. If you can accomplish a single well-defined task with minimal effort, you’ll likely be able to use that tool effectively without extensive training.
00:10:20
Now, the third type of tool is represented by curb cuts. These came about in Berkeley to assist electric wheelchair users and have since benefited others using bicycles, strollers, or carts. Once established, curb cuts require no additional effort to use and provide significant value.
00:10:47
They illustrate the principle that tools can enhance our workflow without imposing extra demands. Much like setting up a development environment, there can be an initial setup cost, but ideally, they should offer ongoing benefits with minimal effort.
00:11:05
So, how can you apply these principles when considering the tools you utilize? Choose your 'steno tools' carefully, as they involve significant time investments. Likewise, remember that while 'waffle irons' are limited, their simplicity and effectiveness can be advantageous.
00:11:38
In contrast, curb cut-type tools can provide continuous value without demanding extensive cognitive load. Consider the potential gains from establishing tools that streamline your workflow and minimize distractions.
00:12:00
So, what tools do I recommend? I’ll highlight several that I find generally helpful. First, let’s talk about shell prompts. My prompt utilizes Z shell with a specific theme that displays the present working directory, indicates whether the last command succeeded or failed, and shows the Ruby version and current Git branch.
00:12:45
I’ve become dependent on seeing the Git branch and SHA-1 hash in those locations, as it assures me I am working in the correct codebase. Setting this up didn’t take long, and now it’s part of my workflow.
00:13:20
Another useful tool is Git aliases. They can save a ton of typing. I have numerous aliases enabled in my Z shell, and while I can’t remember all of them, they help reduce cognitive load. I aim to name them in ways that are memorable, avoiding overly cryptic naming.
00:13:45
I also use a text expansion tool that works across different platforms, enabling me to create snippet replacements anywhere I type. This has been particularly useful when working on remote SSH servers.
00:14:15
In addition, I rely heavily on command history management tools in Z shell, which enhance my productivity. For instance, I can recall previous commands with a simple up arrow after typing a keyword, making it easier to retrieve commands I use infrequently.
00:14:37
This significant improvement in my workflow means I can access all important commands quickly, without needing to memorize every detail of complex commands I tan rarely.
00:15:09
I'll also mention the tool 'jump,' which allows me to navigate directories efficiently. By typing 'j' plus a part of the directory name, I can quickly move to recently used or frequently accessed folders.
00:15:25
Brad talked about fuzzy finders, which I utilize too, but my primary focus is discovering files and directories using targeted keywords. This helps me avoid the mental overhead of remembering exact file paths.
00:16:00
In addition, I leverage a workflow where all repositories I clone from GitHub are neatly organized into directories based on their GitHub organization and repo names. This system simplifies my navigation and reduces the clutter in my file structure.
00:16:20
If you're a Mac user, I highly recommend evaluating alternative terminal applications like iTerm2. This tool has several features that enhance the user experience, such as being able to click on URLs or file names within the terminal to open them directly in your browser or editor.
00:16:45
iTerm2 also allows for convenient keyboard shortcuts to open new tabs or execute other functions seamlessly. This can substantially save time, especially during repetitive tasks.
00:17:05
As for Git, it possesses a powerful internal architecture with a cumbersome command-line interface. Utilizing pre-commit and pre-push hooks is a fantastic way to streamline your Git processes and enforce coding standards, like running RuboCop automatically on your changes.
00:17:31
I recommend setting up a directory within your repository for everyone to use the same hooks, enhancing consistency and minimizing errors.
00:18:01
I also advocate for using GUI Git tools instead of the command line for several tasks, especially those involving visualizations of changes. I have come to prefer a tool called Fork, which operates on both Windows and Mac.
00:18:30
Fork provides a clear display of Git logs, branches, and changes, allowing for straightforward navigation and task management. It simplifies tasks such as interactive rebasing and checking logs, thus minimizing cognitive clutter.
00:19:00
Being able to visually inspect changes and see details on a per-commit basis makes it easier to manage projects effectively, especially for developers with increasing project complexity.
00:19:37
A helpful feature of GitHub is using the 'tee' command on a repository page, which activates a fuzzy finder—something many users don't realize exists. Various keyboard shortcuts also enhance interactivity and ease of use that can often be overlooked.
00:20:05
Another recent feature GitHub integrated is the ability to create a pull request directly after pushing code, streamlining the workflow significantly.
00:20:30
Keep in mind that GitHub maintains a command line tool named 'hub,' which adds commands for interactive GitHub operations. I regularly recommend creating Git aliases that utilize 'hub' to create pull requests with minimal effort.
00:21:03
Many of us use various editors like Vim, Atom, Sublime, or VS Code. Personally, I favor VS Code and Atom lately, as their ecosystems are flourishing.
00:21:26
Atom has an interesting plugin called the regex railroad diagram, which visually represents regular expressions, enhancing comprehensibility—something not found in other editors.
00:22:00
In the ecosystem of VS Code, there's also robust support from a gem called Solargraph, which parses Ruby and provides useful autocompletion, including method signatures.
00:22:35
Moreover, tools such as Emmet prove valuable when working with HTML or CSS, granting significant time savings by auto-generating repetitive markup structures.
00:23:00
At its core, both VS Code and Atom offer excellent support for Git and GitHub integration, helping keep your workflow seamless.
00:23:27
Now let's discuss a couple of Mac-specific tools that enhance productivity. Alfred, for example, is an application launcher that allows you to search and open applications quickly using keyboard shortcuts.
00:23:56
Additionally, BetterTouchTool enables the creation of system-wide keyboard shortcuts and touchpad configurations to streamline everyday tasks—for instance, moving a window between monitors with a simple gesture.
00:24:30
If you employ man pages, I recommend 'Dash' as a powerful standalone resource that aggregates documentation from different programming tools and languages into a single, easily navigable interface.
00:25:03
Another valuable tool for file transfers is 'Transmit,' which I use mainly in connection with remote editors to manage files efficiently.
00:25:30
For SQL database visualization, 'Sequel Pro' serves as a robust GUI for MySQL, while Postico offers similar benefits for Postgres databases. Both tools excel at executing arbitrary SQL commands and displaying results clearly.
00:26:03
While this is true with their command-line counterparts, I find graphical interfaces less stressful for database management and queries. Although manual editing of production databases is risky, the GUI offers a more manageable approach.
00:26:35
One surprising tool gaining traction is the Mac touch bar. I see the touch bar as a remarkable innovation enabling users to customize their application experience with personalized shortcuts and controls.
00:27:00
By using BetterTouchTool, I can create custom touch bars for each application, which help me recall commonly used commands. This means I can engage with my software efficiently without needing to memorize each keyboard shortcut.
00:27:40
Now let's revisit my original GitHub task: finish some code, run RuboCop, commit, and create a PR. By using Fork to examine changes visually and editing the commit message there, I can push to GitHub and create pull requests with ease.
00:28:15
This systematic approach has drastically reduced the complexity of what was initially a ten-step process. The improvements to my workflow mean I genuinely interact with the changes I’ve made.
00:28:55
These considerations help me evaluate tools and methods effectively. I encourage you to identify tasks you perform regularly and assess how they can be streamlined or simplified.
00:29:20
Reflect on improvements that can be made, mistakes that are recurring in your workflow, or information you're missing that would benefit your tasks. That mindset is essential.
00:30:00
To conclude, I apologize for rushing through this talk. Please feel free to reach out to me with any questions; I'm looking forward to continuing the conversation. Thank you for your time!
