I started watching Gary Bernhardt’s Destroy All Software screencasts recently and after watching a specific episode, I had to have his Ruby testing setup. After sitting in Vim config for a while, with some improvements I made, I started feeling like I should somehow contribute my changes back. After I started adding a few more changes suggested by fellow Taconaut Steven Harman, I decided it really needed to be a Vim Plugin.

Announcing vim-vroom! An easy way to run your Ruby tests without leaving Vim. If you’re hackin’ away at some Ruby code, you can open up your test file and hit r (mapped to :VroomRunTestFile) to have it run that file. Now you can bounce around anywhere in your application code and just be a r away from running your last test file. If your testing framework supports it, you can also use R (mapped to :VroomRunNearestTest) to run the nearest test in the file as well.

Currently, MiniTest/Test::Unit, Cucumber, and RSpec are all supported. I’ve tried to ensure everything is easily customizable for whatever workflow you may have, and whatever preferences you may have. Things such as clearing the screen before running tests, color usage, key mappings, and more, are all optional and can easily be toggled on or off with just 1 line in your Vim config. Everything is documented for easy access in or outside of Vim. There aren’t any known issues at the moment, but if you run into one, please file a GitHub issue, or, if you’re particularly vimscript savvy, fork the project and send me a pull request!

The post vim-vroom appeared first on Big Nerd Ranch.

As a developer, I always try to follow the “Boy Scout Principle” when it comes to the code I’m working with. Simply put:

always leave the code cleaner than when you found it

based on the idea that Boy Scouts always leave a campground cleaner than when they found it.

It is tempting to make sweeping changes and clean up lots of code while implementing a small new feature, however, it’s also good practice to separate commits that don’t include any unrelated changes. Occasionally this means that a file that has a few small changes that clean up code, and others that are dealing with some functional changes, needs to get committed. Luckily, git has an awesome feature that allows us to get exactly what we want: hunks.

[Many of the git subcommands can be passed --patch or -p for short. When used with git add, we can compose a commit with exactly the changes we want, instead of just adding whole files. Once you hit enter, you get an interactive prompt where you’re presented with a diff and a set of options.

Some of the more important options are y (yes), n (no), q (quit), and s for “split into smaller hunks”. Using this we can easily create a commit with only the changes I made to clean up a file, instead of any other changes I made. When this isn’t enough, you can also use e (edit) which will open $EDITOR and allow you to modify your diff and get it just right. Once you save, git will make sure that it still applies to the files you’re editing.

Using git add -p allows us to make nice small self-contained commits that only change 1 thing at a time. However, we can use hunks in other places too. git reset -p will allow us to do the exact opposite and unstage things we don’t want to commit by hunk. We can also use it with git checkout to completely get rid of changes we don’t want and may have accidentally added.

This small feature changed how I work, allowing me to crank through a bunch of code and then go back and compose good commits. Are there any small git features that you really enjoy?

The post Using Git Hunks appeared first on Big Nerd Ranch.

At Highgroove, we like using the right tool for the job, but we also don’t like getting too bogged down in thinking about what we should use. We recently switched our internal company chat from Skype to Campfire, but it wasn’t a just simple switch to flip.

We like to use Skype to talk to our customers, since it allows us to be in constant contact with our customers, and it makes it easy to have face to face conversations with them when we can. Since we were already using Skype to talk to customers, we also made a group chat for Highgroovers to talk to one another.

It wasn’t a perfect solution, but it was an easy one. As we’ve been growing, the issues have started to bother us more and more, but it’s conveience was impossible to beat. So how do we switch? It’s hard to give up something that’s already so integrated in our day to day lives. We weren’t even sure if the benefits of switching outweighed the convienence of the current solution.

We decided the best way was to run an experiment. We had heard great things about Campfire, and it seemed nice, but would it fit our needs? Our null hypothesis was that Campfire was just as good as Skype, and our alternative hypothesis was that Campfire was better and would fit our needs better. To test this, we decided to use Campfire for 1 week and then evaluate it afterwards.

Starting on a Monday, we all opened up Campfire as well and didn’t talk at all in our old Skype group chat. We quickly found things we enjoyed, like inline images, flexible notifications via Propane, and Pivotal Tracker integration, along with things we missed, such as direct messages. Anytime we ran into something we liked or hated, we were vocal.

I collected these opinions, and at the end of the week, asked how they had changed or if they were still issues. As a team we saw that the benefits outweighed the drawbacks and switched. While we would have eventually switched to something better if we sat around longer, we’re already enjoying Campfire, and working to improve our experience (like setting up Hubot) with it now, something that would have had to wait for us to decide on the best chat system if we didn’t just bias towards action.

How does your organization make decisions? Do you try to decide on the best solution and then use it, or do you try to throw spaghetti against the wall and see what sticks?

The post The Great Campfire Experiment appeared first on Big Nerd Ranch.

Here at Highgroove, we do code reviews, which ensures everyone is reading some code on a regular basis. However, being a developer usually means you’ll be reading code regularly anyway. In the past, I used to avoid this if I could. However, now I’ve learned how much I can get from it, and use it to improve myself as a developer.

Reading code isn’t easy, and I certainly didn’t want to do it when my only goal was figuring out why a gem wasn’t doing what it promised. It was much easier to just find someone familiar with it and pick their brain. However, there’s more to be gained from reading source code than you may think.

Recently, I had project which relied heavily upon Resque. While working on this project, I had a multitude of questions about Resque and how to achieve different things using it. I dug into the source code, and not only found the answer to all my questions, but learned quite a bit.

By taking a hard look at a system I was completely unfamiliar with, I was forced to think about the general requirements for a background worker library, and was able to see how Chris Wanstrath & contributors worked within them. I also gained familiarity with something that my project was going to be interacting with regularly. On top of that, I also found a few Ruby snippets that I really liked, and not only made a note of, but also was able to use on different projects.

I’ve long mastered enough Google-fu to get me out of a jam when I have an issue with a random gem. However, sometimes The Googles aren’t enough, and I used to dread having to roll up my sleeves and start digging into the gem source code. Now that I’ve grown used to reading code, I look at it as an opportunity to look at someone else’s programming style, and hopefully learn a thing or two.

What about you? Do you hate reading code, accept it as part of being a developer, or have you learned to love it?

The post The Value of Reading Code appeared first on Big Nerd Ranch.

I’ve now been working at Highgroove for just over a month. While most of this has been part time, as I was finishing up my Fall semester at Georgia Tech, I’ve experienced quite a few differences from my previous jobs.

At first, it felt a lot more chaotic. With the results only work environment, everyone is allowed to be independent. This is a huge plus, and allows for a lot more flexibility, but is initially a bit scary. I’m used to being given a task or two, completing it, and then getting more from my supervisor. At Highgroove, I came in on my first day, and right away I had a virtual meeting with a client and started writing out stories on what to do, and then having an open dialog with them as I ran into issues or finished a feature. Now that I’ve started to get into the swing of things, it’s fantastic!

There’s also less structure in regards who’s on when. I have been used to working standard hours with pretty much all the other people I work with. At Highgroove, some people are on Hawaii time, while others are on Eastern time. It was a bit odd to get my first code review while I was up late studying. It also takes some discipline, or silencing your iPhone & closing Mail.app, to not get distracted by other people working when you’ve got something else that needs your attention.

The non-standard hours, along with Highgroove being between offices at the moment, means I see some people almost daily at Ignition Alley (where I’ve been going regularly), and almost never see others, which is strange. The good thing is that we still try to get together for lunch, so we can at least see each others faces and enjoy each others company once in a while.

Overall, Highgroove has taken a bit of getting used to, but it’s been a blast, and I’m looking forward to continuing working full time through the summer.

The post Working at Highgroove appeared first on Big Nerd Ranch.