Workflow

by Ryan Davis

In his talk at GoGaRuCo 2010, Ryan Davis discusses the workflow of software development, emphasizing the importance of understanding how individuals approach coding and testing. He encourages the audience to analyze their methods and identify areas for improvement. Davis defines workflow as the sequence of processes that take a piece of work from initiation to completion, emphasizing that each developer has a unique approach.

Key points of the talk include:

Personal Experience: Ryan shares insights from his experiences with Seattle.rb and coding alongside skilled developers in the Ruby community. He underscores the creativity within diverse workflows and their impact on productivity.
Enviroments: He describes his own setup using Emacs, highlighting the integration of tools like AutoTest and Toggle, which improve navigation and communication during coding. His preference for a single, full-screen interface contrasts with other developers' setups and promotes a more streamlined workflow.
Variety of Workflows: During the talk, panelists including Jim Weirich and Evan Phoenix share their workflows, demonstrating that although they use different tools (e.g., Emacs and Vim), they still adhere to common principles like Test-Driven Development (TDD) and continuous code review.
Common Practices: The panelists discuss shared practices such as incremental search and ctags, stating their importance in enhancing navigation and the efficiency of their coding processes. They emphasize the significance of maintaining familiarity with their chosen editors while exploring new configurations to avoid stagnation.
Takeaways on Productivity: One of the significant conclusions drawn from the discussion is that optimizing workflow and tools is essential for productivity. The panelists collectively agree that understanding your tools and ensuring a suitable workspace setup are fundamental to becoming more effective and enjoying the coding process.

The session concludes with an open dialogue, encouraging participants to consider their workflows and the impact of tool choice on their coding practices. Ryan invites audience members to submit their workflows for further discussion, reinforcing the idea that collective sharing of knowledge can foster growth in the developer community and improve practices across the board.

00:00:05.040 Hey, thanks for having me. As you said, I was pulled in on Tuesday, so this is a bit of a rush job for this talk. Please forgive me; I also have another caveat that I ripped my contact yesterday, so I can see blobs, but I don't know who you are. My name is Ryan Davis, and I'm with Seattle.rb. I also work for AT&T Interactive. Thanks to them for making this possible for me to come down.

00:00:34.880 I had to quickly figure out what to talk about, and all my favorite topics were taken. Evan had the open-source topic, and everyone else had the testing thing; Jim nailed the lateral thinking topic. I was talking to Josh and thinking that I could just stand up here and yell at all of you, saying you're doing it all wrong, but I've given that talk before. So, I thought I would like to discuss something that I just don't see at many conferences at all: our actual workflows. That means what we do and how we do it. I want the three-foot view, the view between the brain and the laptop screen. I don't want to be a methodologist; we have enough Grady Boochs in the world. I want to have a dialogue about how we get things done at the end of the day.

00:01:23.120 So, real quick, workflow definition: it essentially comprises the sequence of processes that get a piece of work from initiation to completion. Everyone in this room, even if you work together slightly, does everything differently from everyone else in this room—absolutely everyone. These differences shape our daily tasks.

00:02:02.000 I helped found Seattle.rb, and I have the honor and privilege of working with two of the most creative and prolific developers in the entire Ruby community. Between the three of us, we're now up to just under 150 gems and nearly a thousand gem releases across all of our projects. While that may be laudable, the awesome thing I get to participate in every day is that I get to stand next to those guys, code with them, and watch how they do things.

00:02:26.400 I had to balance this talk because yesterday I was terrified watching everyone talk about these nicely constrained topics and going over time. I thought I could not possibly conduct an interactive dialogue with the audience about something completely unbounded and keep it within 30 minutes, so we came up with the idea of doing this panel. I'm going to show what I do in a little more detail than these guys will, but then we're going to have a dialogue.

00:03:11.360 I am 100% Emacs. I do it almost full screen, liking to have the bottom edge and the right-hand edge for extra tools, like Adiam, so that I can communicate with others. I split it once, and it looks roughly like that. Cool! On the left-hand side, I have my shell, my code, and my test—almost everything I do my work in—and on the right-hand side, I have AutoTest running. That is the view of my laptop screen most of the time. I try not to use the terminal app; I was using it to do SSH stuff, but I'm now doing SSH mode inside of Emacs as well. By not leaving Emacs, I am more productive.

00:05:10.720 The big thing about Ryan's previous talk is that he was nice to be able to get into the details and everything, and that Control-X Control-E, or whatever it was, brings up the command in your editor. You have that automatically when you're running shell inside of Emacs. You have full editability of both your command and the output of previous commands, so you can go up, grab something, morph it, and paste it back into the command line, and it works great. I also wrote something called autotest.el and toggle.el. AutoTest integrates into Emacs; it fires it up and runs it in what's called compile mode, teaching Emacs what the back traces look like, so the back traces are hyperlinkable. You can click a line in one of your errors and go straight to the code that failed.

00:06:17.680 Toggle gives me a quick key command that lets me flip between the unit test and the implementation or the functional test and the controller. You're able to teach it whatever naming schemes you use, allowing you quick ability to go back and forth between the two. With both autotest.el and toggle.el, I'm able to navigate the code and perform various tasks very easily. You click on an error, go to the unit test that's failing, and you can use toggle to flip over to the implementation, fix whatever is wrong, and AutoTest automatically fires up, passes your test, reruns everything, and you're good to go.

00:06:50.480 I don't use what's called code folding; most editors have it, but I don't like it. I want to see all my code so that as I'm passing over things, my implicit mammalian pattern matcher is going, and I'm able to get more refactoring out of it that way. I try to use as few pixels as possible. I don't find that my productivity scales with the number of pixels; it actually goes down a little bit. Most importantly, I swear a lot when I code, and I think that's essential; it helps you get your anger into your tests or something.

00:07:39.840 Eric Hodel, who is not here, is represented by proxy. I've been coding with him for about nine years. He uses a completely different setup than I do, other than laptop. He uses Vim, and he has the terminal open. He does not do full screen; he dedicates about two-thirds of it to coding and has it split twice instead of once. His setup has one terminal window and one Vim window; the Vim is on the left, with test and implementation, and the right has a fixed terminal command that brings up two terminals side by side in a fixed position. He has AutoTest running there along with the shell. Immediately, he doesn't have some of the integration I have, but he also has a setup that works perfectly for him.

00:09:09.760 He folds his code 100% by default when opening a Ruby file. All he sees is the outline form of it, which always starts off as one class. He finds that helps him navigate a file much easier, especially when dealing with tests, allowing him to see a quick catalog or summary of them and get through them quickly. He likes larger laptops; more pixels help him be more productive, and he swears very little.

00:10:03.680 Then there's Aaron, who is the cyclone of terror, just with more pink and kittens. Aaron and Eric's workflows are pretty similar, but Eric uses a lot more rigidity in his placement; Aaron is much more free-flowing where his windows are. He brings up a lot more Vim instances left and right, while Eric tries to stay within one in a fixed position. But otherwise, their workflows look quite a bit the same.

00:10:57.760 So, that's what we do differently. As for what we do in common, we all know our editors quite well, and the more time you spend on that, I think the more you get out of it on a daily basis, alongside finding some balance in your life. We all do Test-Driven Development with either Test Unit or MiniTest. Contrary to a lot of people in here, how many people use just the regular test frameworks like Test Unit? Oh, it's so sad! And how many people use RSpec? Sadder. Did you guys not see the benchmarks yesterday? I'm so much faster.

00:11:37.840 We do our movement through incremental search. This isn't something found in every editor, but it's pretty common. Instead of cursoring down or mousing somewhere, we're doing incremental search, which means as you type each character, you jump to the next match. This allows us to navigate through the file pretty quickly. We also use something called ctags, more specifically the implementation called Exuberant ctags. Raise your hand if you use ctags. Okay, this is the one thing we're going to fix today! If you're on a Mac and use MacPorts or Homebrew, you can install Exuberant Ctags very easily. Emacs and Vim have built-in support in a vanilla install, and it is brilliant.

00:12:11.680 You can jump to any function at any time, no matter what. It's not like TextMate, where you have to have the files open to do searches across them; it's everything you've tagged into a tag file. We do distribution via gems and project automation with Rake and Hoe, which set up our project structure and give us a template of tasks to use across all our projects. We're generally OS X folks but also deploy to the BSDs.

00:13:07.680 The new term, YAGNI, means 'You're not going to need it, damn it!' I won't try to pronounce that, but it's all about doing the simplest thing that could possibly work, damn it. We eschew over-mocking—in fact, I think across all our regular gems, we don't mock at all in any of our tests whatsoever; there might be a couple of exceptions.

00:13:50.240 AutoTest is probably my biggest productivity boost. I have tightened the communication feedback loop as closely as I can for Ruby and Rails development with AutoTest, and there's just nothing beating that right now. And, dun dun dun... we don't pair! That's contrary to a lot of popular beliefs out there. But we do review often—often, often, often, like twenty times a day, usually before we commit. So that's a bit of an overview of the three of us in the Ruby community.

00:14:30.720 To time constrain this talk further, I have to defer to my panel here to get some more views out there. We’ve got Evan Phoenix, Jim Weirich, and Rayne Henricks up here, and I would love to get one volunteer to come up and talk about how they do their work. Can I get anyone? Preferably a beginner to me, but it's not necessary.

00:15:15.840 Put your hand down... Put your hand down... What red shirt? Come to me!

00:15:17.960 While you're facing the screen, these are the questions that I want answered so keep that in your mind. We're going to have the other guys go first because they've thought about this more. Yeah, so why don't we start with Jim?

00:16:39.600 Jim says, okay, I have a screenshot... Sorry, I got it hold on. 10 is Control-Option-Command-8. It does not work while Keynote is running. You have to pop out, but it works well enough. So, this is Jim. Actually, my workflow is not that different from Ryan's, although it does differ a little bit. I am an Emacs user; I have been using Emacs for probably about twenty-some years. I have downloaded most of my brain into Emacs macros. In fact, people ask me how I just did that in my editor, and I have to stop and think and physically move my fingers and think it was this keystroke.

00:18:34.720 I've been using a very highly customized setup for my Emacs. I split my windows, here's a typical setup. I like a dark screen, which unfortunately doesn't show up well on the projector but looks beautiful on your monitor. If I've got a large monitor, I'll split it horizontally; if it's smaller, I'll tend to split vertically. I don't care which panel has the code, test, or implementation—wherever it pops up, I'm absolutely okay with that.

00:19:53.280 Emacs is the editor for me; it's a couple things in there. I use toggle to toggle between tests and the code quickly, and that's beautiful. I've enhanced it a little bit so it's project-sensitive—if a different project uses RSpec versus Test Unit or different naming conventions, I can customize it on a per-project basis. I also use the Rails macros, Renari. I use most of it, but my favorite pieces are the macros that take you between the views and the controllers and between the models and there are a couple of features that work nicely.

00:21:44.320 I have a finding code script that will grep through a project and search for patterns. It's designed to check the files I consider important, basically Ruby files or Rake files or our HTML files or any of the template files. I've recently added JavaScript files since I'm doing more of that; it'll print out the lines in a format Emacs recognizes, and I can hyperlink directly to the file. Using 'finding code,' I can get a bunch of lines and jump to the exact line in my source code. I use Exuberant Tags, which has totally cured me of my desire to worry about where things are in files. I just say take me to this method, and bam, I'm there.

00:23:35.360 Regarding testing frameworks, I tend to be agnostic. I've used Test Unit for most of my personal projects but am comfortable with RSpec and have been using that more for features I like in it. Everything is checked into GitHub—Edgecase has all our projects there, and all my personal directories, like my Emacs setup and bash setup, are also on GitHub. This way, when I move from machine to machine, it's just a quick checkout.

00:24:01.760 I have to time myself here; I'm running on time! My workflow starts with the shell. I use Bash for my shell. I've tried Csh, which is okay, but it's not a game-changer for me. I keep both my Vim directory and all my home directory dot files on GitHub. I use git for everything and Jeweler to build gems. My workflow is that I have MacVim on the left and a terminal running screen on the right. MacVim is split into test and implementation, while the screen is split into AutoTest on top and a general shell window below.

00:25:40.960 When I'm using Rails, I load a screen RC that will do that and also have another shell running the script server so I can tab through more easily. I don't use a lot of plugins in Vim; I do use rails.vim because I think you're insane not to if you do Rails work. I don't use any special navigation functions or plugins in Vim except for Exuberant Ctags, which are built into Mac OS X, but they are actually broken. I recommend, like Ryan mentioned, installing from MacPorts or Homebrew.

00:27:17.040 The Exuberant Ctags compiled with the --without-suck option enabled allows you to run Ctags and output file descriptors. This totally obsoletes any Vim navigation; if you learn how to use Ctags instead, you'll find it brilliant. It really is a game-changer! You heard earlier about disconnecting from the file system and thinking conceptually about your system's organization; Ctags helps you do that.

00:29:16.160 I'll switch to Evan now; I'm trying to speed things up a little because I went a bit too long! I don't have a slide, but my setup is simple. I use Vim (MacVim) and just a terminal window for the most part. I work with tabs inside the terminal. I’m a bit of an oddity; I’m a very minimalist editor user, for the most part! I have tried various setups but find that sticking with fewer features works for me because, as long as I have the tools right there, I'm fine.

00:30:56.160 So people ask, how can you teach me your setup, and I can’t remember the features. Of course, I learn better by working in my codebase where I have been the architect for many years, so I don't need Ctags as much. This means I don’t have to search as much; I know what file a method resides in—I just open it up without friction. In fact, I rarely close buffers in MacVim; I use the buffer explorer and go through open buffers, often having over 500 open. A frequent tip is to avoid quitting—stay in your buffer.

00:32:35.760 A good example is I just deleted my Vim directory recently and switched to a different plugin for managing my Vim setup. I think mixing things up helps avoid getting stuck in ruts. I also remind people that side-by-side pane splits might be beneficial but I've never really needed them.

00:33:29.680 I concluded that I’m not very particular about my setup; I use what works for me without much thought. It’s important to maintain comfort in your setup while still being willing to try new configurations, especially to avoid getting too comfortable in your setups. So, last call, who are you? Hi, I'm Dennis Collinson. I've been coding professionally for a year now.

00:34:59.840 I rely heavily on GNU Screen, which is great! I generally keep it full-screen. However, I have a system where the zero buffer is always my Vim; the second screen shows my test, and the third is for the server. The others are general Bash commands. I use Vim to navigate around my code and 'gem open' is useful for code libraries.

00:36:01.920 I also have mini buffer explorer at the top to manage around 20 open buffers. Recently, I switched to using Pathogen, a package management tool to manage my Vim setup. It’s pretty versatile, making it easy to add and subtract new plugins. I need to improve how I jump between failing tests and code more automatically. That’s my setup.

00:37:28.480 We’re nearing the end, about three more minutes left for questions. Here's something you didn't discuss—it fascinates me the variety of tools and plugins you can use in text editors. I find every so often I get the urge to customize my editor to be a better programmer, but I realize that thinking about the problem is often more beneficial than seeking speed in the wrong direction.

00:38:34.240 Someone says, I completely agree! Thinking through the problem is important for implementation, but sooner or later, you’ve got to text it to a file and work with tools. A participant chimes in that while it's great to be efficient in your editor, forcing yourself to think through your task first is crucial as well.

00:39:53.920 As we wrap up, I notice that many use IDEs like RubyMine. Can I see a raise of hands for RubyMine users? Wow! Keep your hands up if you work there or not! Well, that's all we have time for. Thank you, and if you want to email me your workflows as keywords, please do so, and I'll share those insights.

00:41:08.160 Thank you so much, Ryan, for organizing this, and thanks to everyone for discussing all of this fabulous information!