 Hey, thanks for having me. As you said, I was pulled in on Tuesday, so this is a bit of a rushed job on this talk. Please forgive me. I also have another caveat that I ripped a contact yesterday, so I can see blobs, but I don't know who you are. So my name's Ryan Davis. I'm with Seattle Darby. I also work for AT&T Interactive. Thanks to them for making this possible for me to come down. So I had to figure out really quickly what to talk about, and all my favorite topics were taken. Evan had the open source thing, and everyone else had the testing thing. Jim nailed the lateral thinking thing, so I was talking to Josh and everything, figuring 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 talk about something that I just don't see at many conferences at all, and that is our actual workflows. And that means what we do, 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 butchers in the world. I want to be able to have a dialogue about how we get things done at the end of the day. So real quick workflow definition. Essentially, the sequence are processes which get a piece of work from initiation to completion. And everyone in this room, even if you work together, just slightly does everything different from everyone else in this room. Absolutely everyone. And it's these differences that make us what we are in our daily tasks. So 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. And between the three of us, we're now up to just under 150 gems and just under 1,000 gem releases across all of our projects. And while that may be laudable, the awesome thing that I get to participate in every day is I get to stand next to those guys and code with them and watch what they do and how they do it. So I had to balance this talk because yesterday I was getting terrified watching everyone talk about these nice constrained topics and going over time. And I'm like, well, there's no way I can do 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. So I'm going to show what I do with a little more detail than these guys are going to be able to. But then we're going to have a dialogue. So I am 100% E-Max. I do it almost full screen. I like to have the bottom edge and the right hand edge for extra tools like Addium so that I can communicate with others. And I split it once. And it looks roughly like that. And that's actually visible. Cool. So on the left hand side, I have my shell, my code, my test, almost everything that I do in my work-in. And on the right hand side, I have Autotest running. This 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-y stuff. But I'm now doing SSH mode inside of E-Max as well. And by not leaving E-Max, I am more productive. The big thing about Ryan's previous talk is he was nice that he was able to get into the details and everything. And that Control-X, Control-E, or whatever it was, to be able to bring up a command in your editor, you have that automatically when you're running shell inside of E-Max. You have full editability of both your command and your previous command's output. So you can go up and grab something, morph it, and then paste it back into the command line. And it worked great. I also wrote something called autotest.el and toggle.el. Autotest integrates Autotest into E-Max. It fires it up and it runs it in what's called compile mode, teaching E-Max what the backtraces look like, so that backtraces are hyperlinkable. And you can click on a line in one of your errors and go straight to the code that failed. Toggle gives me a quick key command that lets me flip back and forth between the unit test and the implementation or the functional test and the controller. And you're able to teach whatever naming schemes that you use, but it gives you a very quick ability to go back and forth between the two. And between the two of those, autotest.el and toggle.el, I'm able to fly all over the code and do all sorts of things very, very easily. You click on an error and you go to a unit test that's failing, you look at the unit test, you use toggle, you flip over to the implementation, you fix whatever is done, autotest automatically fires up, passes your test, reruns everything and you're good to go. I don't use what's called code folding. Most editors have it, I don't like it. I want to be able to see all of my code so that as I'm passing over things, my implicit mammalian pattern matcher is going and I'm able to get more refactorings out of it that way. I'm able to see more patterns and go, oh, this could be refactored this way and I'll do that. And I just feel like it works better for the way I pattern match. I try to use, contrary to a lot of people's beliefs, I try to use as few pixels as possible. I don't find that my productivity scales with a number of pixels. It actually goes down a little bit. And most importantly, I swear a lot when I code, I think that's very important. Helps you get your anger into your tests or something. Eric Hodel who's not here, I'm gonna represent him by proxy, I've been coding with him for about nine years. He uses a completely different setup than me, other than laptop. He uses Vim and he uses the terminal and he doesn't do full screen, he does about two thirds of it dedicated to coding and he's got it split twice instead of once. So his setup has one terminal window and one Vim window. The Vim's on the left, so he's got test and implementation. And then on the right he's got a fixed terminal command that brings up two terms side by side in a fixed position. He's got auto tests running there and he's got shell. So immediately he doesn't have some of the integration stuff that I have, but he also has a setup that works perfectly for him. So he can't fault him for it. He folds his code 100% by default. So when he opens up a Ruby file, all he sees is the outline form of it. He doesn't see any of the details and the outline always starts off as one. So just class X. And he finds that that helps him navigate a file much easier, especially when we're dealing with like our tests, you're able to see a quick catalog or summary of what the tests are and get through them very quickly. He likes larger laptops, more pixels for him is more productive and he swears very little. And then there's Aaron, who is the cyclone of terror only with more pink and kittens. Aaron and Eric's workflow are pretty close to the same but Eric uses a lot more rigidity and his placement and everything and Aaron is much more free flowing on where his windows are. He's bringing up a lot more VIMs left and right whereas Eric tries to stay within one and a fixed position. But otherwise the workflows look quite a bit the same. So that's what we do different and what do we do in common? Well, 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 with some balance in your life. We all do TDD with either test unit or mini test and that's contrary to a lot of people in here. How many people use just regular test framework like test unit? And how many people use RSpec? Statter. Did you guys not see the benchmarks yesterday? I'm so much faster. We do our movement through incremental search and this is not a thing that's in every editor but it's pretty close. Basically what that means is instead of cursoring down somewhere or instead of mousing somewhere we're gonna start doing an incremental search which means as you type each character you're gonna go to the next match that works. And that lets us jump through the file pretty quickly. We also use something called C tags and more specifically the implementation called exuberant C tags. How many people use C tags? Okay, that's the one thing we're gonna fix today. If you're on a Mac and you use Mac ports or Homebrew you can install exuberant C tags very, very easily. Emacs and Vim have built in support in a vanilla install and it is brilliant. You can jump to any function at any time no matter what, it's not like a text mate where you have to have the files open in order to do searches across them. It's everything you've tagged into a tag file. We do distribution via gems and we do project automation with rake and hope. That sets up both our project structure and gives us a template of tasks that we use across all of our projects. We're generally OS 10 folks but we also deploy to BSDs. New term, Yagney comma D is you're not gonna need it, damn it. And I'm not gonna try to pronounce that but that's to do the simplest thing that could possibly work, damn it. We issue over mocking and in fact I think across all of our regular gems we don't mock at all in any of our tests whatsoever. There might be a couple exceptions. I like this corner over here. Autotest, Autotest, Autotest. That's probably my biggest productivity boost. I have tightened the communication feedback loop as tight as I can get it for Ruby and Rails development with Autotest and there's just nothing beating that right now. And don't, don't, don't. We don't pair. That's contrary to a lot of popular beliefs out there but we do review often, often, often, often like 20 times a day, usually before we commit. So that's kind of a what do you view of three of us in the Ruby community and in order to time constrain I have to basically defer to my panel here in order to get some more views out there. So we've got Evan Phoenix, Jim Wyrick and Rain 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 beginner to me but it's not necessary. Put your hand down, put your hand down. What? Redshirt? Come to me. So while, while you're facing the screen, while you're facing the screen these are the questions that I want answered. So have that in your mind. We're gonna have the other guys go first because they've thought about this more. So why don't we start with Jim? Okay. I have a screenshot. I have a dark screenshot. Hold on, I got it. On OS 10 that is control option command eight. It does not work while Keynote is running. You have to pop out but it works well enough. So this is Jim. Okay, 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 20 some years. I have downloaded most of my brain into Emacs macros. So in fact people ask me, well how did you just do that in your editor and I have to stop and think and physically move my fingers in what I just did. Oh it's this keystroke because I don't actually remember the keystrokes anymore. So I use a very highly customized setup for my Emacs. I will split my windows. Here's a typical setup. I like the dark screen which unfortunately doesn't show up well on the projector but looks beautiful on your monitor. I will split the screen if I've got a large monitor. I'll split it horizontally like this. If it's a smaller monitor I'll tend to split vertically. I'm not, I don't care which panel has the code or test or implementation. I just know wherever it pops up I'm absolutely okay with that. I know one of my coworkers likes it positioned exactly so and none of my setup works for him because I just let it pop up anywhere. So Emacs is the editor. It's a couple things in there. I do use Toggle to toggle between the test and the code very quickly and that's beautiful. I also have enhanced a little bit so it's project sensitive. If a different project uses RSpec versus test unit versus a different naming convention so I can customize it on a per project basis. I also use the Rails, let's see the, what is it? Rennari, Rennari I think is the name of the Rails macros. That's Phil Hagoberg's. Yeah, yes. And I use most of it but the pieces I really like are the macros that take you between the views and the controllers and between the models and there's a couple things that work really nice there. The RHTML mode in that is half decent. It's not the best in the world, it could be improved but it's certainly workable. I have a what I call find and code script that will go and grep through a project and we'll find patterns and it's designed to chest check the files I consider important which are basically Ruby files or rake files or RHTML files or any of the template files and I've recently added JavaScript files to that because I'm doing more of that. It'll find it, it'll print out the lines in format that Emacs will recognize and I can hyperlink direct to the file. So I'll say finding code, bam, bam, bam I'll get a bunch of lines, I can put my cursor on this line, hit my function F2 key and bam, I'm right there on that line in my source code. I use exuberancy tags that 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 in the method and whatever file it's in it's popped up and so a lot of the file system where things are stored those worries are gone now. What else do I use? I will, I tend to be test system agnostic. I've used test unit for most of my own personal projects but I'm comfortable with RSpec and we'll use that and I've been using that a little bit more for some features that I kind of like in it. What else? And everything's checked into GitHub. Yes, Edgecase does all our projects on GitHub so all our stuff is there. All my personal projects on GitHub. All my personal directories like my Emacs setup and my Bash setup and everything else like a lot of my scripts I run from the shell even though we all hate the shell. I have lots of scripts I do from them. Those are all in GitHub so I can, when I move from machine to machine it's just a quick checkout and it's there. So if anyone wants to see my Emacs setup it's out there under my GitHub account. I'm gonna have to call time. How am I doing with time? I'm up on time, okay, so that's it. So let's start from the shell. My workflow is, I'll get to this in a second. I use Bash for my shell. I've tried ZSH and it's okay but it's not a game changer for me personally. I don't think it matters too much which one you use, I vote great. I keep both my Vim directory and all of my home directories.files on GitHub. I use Git for everything. I use Jeweler to build gyms. Let's see. My workflow when I'm working is that I have MacVim on the left and... Sorry, I have MacVim on the left and I have a terminal running screen on the right. MacVim on the left is split into test and implementation. The screen on the right is split into auto test on the top and a general shell window on the bottom. When I'm using Rails, I have a screen RC that I load up that will do this and also have another shell running the script server. So I can tab through to that more easily. With Vim, I don't use a lot of plugins. 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 within Vim except for exuberant C tags. And the exuberant C tags that comes built into Mac OS X is actually broken. So I would recommend, like Ryan said, installing for Mac ports or Homebrew, I use Homebrew, the exuberant C tags, which it compiles with the dash dash without suck option enabled. And you can run C tags and actually also in addition to method descriptors, output file descriptors and that basically totally absolutes all of your Vim navigation if you learn how to use the C tags instead. It's brilliant. It really is a game changer. You heard earlier about disconnecting from the file system and thinking conceptually about the organization of your system and C tags really helps you do that. How long you switched to have and now you're trying to speed things up a little bit because I went a little long. Okay, so I don't have a slide but my setup is actually pretty simple. I mean, I have basically, I use Vim, Mac Vim and just a terminal window for the most part that I do the other things in there with tabs inside the terminal window. It's nothing you haven't seen for the most part. I'm sort of more of an oddity, I think. I'm a, although maybe not, I'm a very editor, slim editor usage person for the most part. I have people who, oh, that sounds cool. Could you teach me how to do that? Could you teach me how to do that? And they show me how to do it. And it's, within a day, I've completely forgotten. I don't even remember that we maybe even had the conversation or that I even needed that functionality. So my, the going the slightly longer route for doing most of those things just simply doesn't bother me. And even to go so far as that I, this is probably a familiarity with the code base. I work for the most part in my own code base that I have been, that I am the architect of and have been for many, many years. So I don't need C tags as much because the C tags has been melded into my brain for the most part, right? So that when I know that I want to go look at a method, I know what function, or I know what file it is. And I can just go and open it up and it, that the, if you force me to think about doing that, I suppose I could tell you that, yeah, I go and go, you know, colon E and then the name of the file or whatever like that. But I don't, it happens just sort of like, oh, I need to open that file. There's no friction, there's no friction to do it. It's all muscle memory. Yeah, and the other thing is that if people have told me this is weird, so I guess it is, but I very rarely close buffers in Macfim. For the most part, I use Buffer Explorer, which is probably the biggest part of my workflow. And I will just do comma B E to get into it. And then use incremental search to actually look through the buffers that are open. So if I know that I've been working in a particular file, I can do that, go to the file and have it right there and not go search around and try to type in the actual padding. And there's been many cases where I've had 500 buffers open in Macfim. I think that's an important point that I'd actually like to ask the audience about. How many people are, are Vim users here? And how many people quit Vim more than five times a day? Oh, yeah. Stop quitting. Yeah, for the most... Vim users are not quitters. That's one of the things that we teach every time we pair with someone new at Seattle RB is that you gotta get out of the habit of quitting Vim all the time because you're losing your context. Suspend, don't quit. Yeah, and since Macfim got good and people started moving to Macfim, that went way down. Cause you know, quitting Vim was a habit that I had, but that was because it was in the shell. And so you felt like, okay. As soon as you have this hing over to a server, that goes out the window and you go back to your old habit. Right, totally. The other thing that I'll just finish with this is I don't like feeling super, I mean, it's fine if I feel comfortable in my setup. I don't really give my setup all that much thought. I just sort of use what the setup I have and as long as the tools are there. But I like to mix up my setup. So like a good example is that the, like yesterday I just completely deleted my Vim directory and my Vim RC and took bends. And I've been using bends for the last two days or so. Cause I don't, the familiarity with your setup means that you get stuck in ruts that you don't realize you're in. So whereas if you go and use someone else's setup or use, even if it was in Vim, you know, you don't have so much friction, but it's like a good example is I almost never did side by side pains, which is whichever split that is. See, I can't even remember if that's a vertical or horizontal split, that's side by side pain mode. And I would just make up and down pains, right? And so just in the course of doing this, I was like, oh, that might be nice having two things side by side. But it hasn't really bothered me up to this point. I don't really put a lot of effort into my editor config because it doesn't give me much friction, so. Okay, last, who are you? Hi, I'm Dennis Collinson. How long have you coded? I've been coding professionally for a year now. So I rely heavily on GNU screen, which is really awesome. I don't split it though, I seem to be rare in that. I generally keep it full screen, but I have a little system. The zero buffer is always my Vim. And then the second screen that I have is an ER. So one is my test and then two is an ERV and three is the server. And then four through seven are just kind of generic bash that are kind of replaceable. And then eight is my slacking off an IRC. And yeah, I use Vim to navigate around my code. There's gem open, which is really good if you're relying on other people's code. Anyone else here use gem open? It's really nice if you're working with another library. Just go to say gem open, gem name, and it'll pull it up and whatever you have editor set to. So that combined with C tags is really nice for digging through other people's code when you're like in some library, what the fuck does this do? Excuse me. You just go down and figure it out really fast. So yeah, I also in Vim have many buffer explorer at the top, so I've got a list of all of my open buffers generally stay around 20. I recently switched. Temasella had a blog article about using pathogen which Tim Pope made to manage your Vim setup. So it's essentially good package management. So I've been using that to, I copied his script but changed it, it's up on my github, github.com, Dennis collective slash Vim I think or whatever. So I've got a pretty long VMRC, but I use this pathogen so that I can really easily add and subtract new plugins, play around with that pretty experimental. And I need to get better with having a mechanism for jumping between failing tests and the code more automatically, something like you wrote in Vim, that's the one thing I could probably improve. So yeah, I guess that's my setup. So we've got about three more minutes. Do we have any questions? I have a comment. Kevin? Okay, the equivalent for, because we had, because Vim won up on stage. The equivalent of toggle.el is a, at least for me, the one that I use is a.vim, like that letter a, not e-h.vim. It's not a Canadian script, so. And it is just a, it's a general purpose companion file switcher, right? So like in the case, like when I'm doing C plus plus and I hit comma a, it takes me to the header file for that thing, right? And if you're in, and you can, I think it comes by default with ones where it'll say like, okay, if you're in a Ruby file, you hit comma a, it looks for the test directory and then the thing underscore test, or test underscore, it has some rules to just go through and do it, so. That's cool. Vim also has its own make and it will work with whatever error format you can program it to work with and what it will do is it will run make and then it will parse the error output and assign that to the quick fix list, which you can then use to navigate to the points in the error output. And the Ruby Vim files come with compilers and error formats so that you can use make for test unit and for Rspec. And so what you can do is you can set your compiler in your Vim RC, for instance, so if you're in a spec, it's set to Rspec. Run make percent, which is make on current file and then your quick fix list will pop up with a list of all of your failing file and line numbers. I have a plugin called red, I have a plugin on my GitHub. It'll be obvious when you look, it's red green something and you bind it to a key map and it will give you a red green bar at the bottom and then take you to the first failure. So that may also be useful if you're trying to get the red green refactor cycle into your Vim. Let's get some questions, we have two minutes. So one of the things that you guys didn't talk about. I'm not hearing you, is the mic on? Should be a green dot. All right, well, I'll just speak louder. So, hello, there we go. So one of the things you guys didn't talk about or rather what you talked about is all the tools, the plugins you can use in your text editors. And I find that fascinating, I love learning this kind of stuff, but every three months or so, I get this urge to go out and customize my editor better because I'll be a better programmer. If only I could save three keystrokes, I'll be a better programmer. And in practice, that's just not true. The greatest hack I've found for myself is a frickin' whiteboard. It's not a better text editor. It's like step away from the code and think about what you actually wanna solve. Thinking about the problem is better than being fast at iterating on the wrong thing. So I'm curious to hear your thoughts on that because obviously the environment matters, right? But what do you guys use to do that? I completely agree with you. Thinking about your problem, getting the solution correct first is important, but so is the ability to implement it. And sooner or later, you gotta get text into a file or if Rich has his way into something. And so you're gonna have to use tools sooner or later. But I completely agree that the whiteboard or your brain or talking to your pairing partner or whatever is the first step, bar none. Yeah, so real quick thought on that. I think that you can, okay, so you can be too fast at putting stuff in, in my opinion. Like having to go out and search for the file and do the thing that I need to do to find the thing is helpful in the same way that, I don't know if you've ever heard the analogy that people, if you write something out longhand, you use better vocabulary than if you would if you typed it out. Because the act of writing it out, of actually taking the time to write each word takes you however long. But you imaginatively have disconnected from the actual writing tasks so that by the time you finish one word, you've come up with a better way to phrase the rest of that sentence. So in that same way that like, even if you feel like you're slow in your editor, it's not wasted time because all that is manual stuff that you're having to do anyway. And once you get, you may be so fast at getting to where you wanted to add the thing and then be not ready to add it now. So. Someone take the microphone please. We have time for one more question. So am I the only sucker for IDs? Like I use RubyMind. Yeah. Nice. Can I see a raise of hands if people use RubyMind? Whoa. Keep your hand up if you work it. And I don't work for RubyMind. I would not have guessed that it was that much. Textmate? I guess we know who won. Okay. That's all we have time for. Thank you much. Actually, if I can interject one extra thing. I wanna see what your guys' workflow is. And so if you take my workflow and distill it as keywords, you get all of this. Get your heads down. And I wanna know what yours is. So if you guys could email me, RyanD-Ruby at ZenSpider.com. Plain text mail, subject, Garuko keywords. Separate your keywords by line. And I will not be using your email address for anything, except maybe to ask a clarifying question or two. I would love to see that. We're gonna try to get an interesting visualization of the data that I get from this. And I'll blog it and possibly at the next conference talk about what we learned. Blog that. I will blog this. I will blog this slide specifically. Thank you. Awesome. Thank you guys for talking about all of this. Fabulous.