Archive
Vim Tip – Registers and Macros
Let’s say you’re a beginning vim user. You know how to yank, put, substitute and change. You know how to do forward searches within a line or do searches ’til’ a certain character; you can use /, ?, *, # effectively. You can combine your searches with commands to work some serious magic. You’ve seen the light. Vim is your One True Editor.
So what’s next? If you’ve mastered the basics, registers and macros are a good place to go turn pro. I’ll briefly explain both concepts, and then use an example to show how these features complement each other.
Registers
A register is like a variable in a typical programming language. It’s a location in memory where you can store something. We’ll look at two usages for registers: storing text, and storing macros.
Normally when you yank a line with yy, it’s contents get saved into the default, unnamed register, called “” (quote-quote). If you want to yank something into another named register, say register a, you have to prefix your yank with “{register}. The same goes for puts.
So for example…
yy yank the current line into the unnamed register "ayy yank the current line into register a "ap put the contents of register a
Simple right? At first it might seem that this is only marginally useful, but registers can greatly simplify some macros. So we’ll talk about that next.
Macros
The q{register} command starts recording a macro. While you’re recording a macro, press q again to signal that you’re finished.
I like to use the q, w, e, and r registers for macros, simply because they’re easiest to reach. So for example, to start recording a macro, I’ll press qw, record my actions, and press q to signal the end of the macro.
The @{register} command executes a macro. So I can execute my new macro with @w. Usually once I know that it works, I’ll also have to run it many times with something like 100@w.
Tying it together
This came up a few weeks ago when I was generating some characterization tests. I had written a quick script to generate some test data in CSV; in reality it was a bit more involved than what follows, but this gets the point accross:
Input, Output 34523451, true 65434092, true 45810353, false (~1000 more of these)
I had also written a single test at the bottom of the file, and I wanted a thousand more that all followed the template.
[Test]
public void Test() {
Assert.AreEqual(IsNumberValid(INPUT), OUTPUT);
}
So I used a vim macro — the vim keystrokes are in brackets () after each step:
- Cut the test template into register a (/\[Test<Enter>”a4dd)
- Move to the beginning of the file, start the macro (ggqq)
- Copy 34523451 into register b (“byw)
- Copy true into register c (f l”cyw)
- Delete the current line (dd)
- Put a copy of the test template at the end of the file (G”ap)
- Replace INPUT with the contents of register b (/INPUT, dw, “bP)
- Replace OUTPUT with the contents of register c (/OUTPUT, dw, “cP)
- Move the cursor back to the beginning of the file (gg)
- End the macro (q)
- Execute the macro 1000 times (1000@q)
Using the above, I was able to generate a ton of code in a minute or so. If I had tried to cobble together a script to do the same it would have taken at least several times as long. I use vim macros almost daily. I don’t often have to combine them with registers, but I’ve found it to be an invaluable technique in certain situations.
Mocks, Stubs and Spies! Oh my!
I’ve been pretty involved in helping out new developers at Point2. I try to ease them in to our agile, Scrum/XP environment easily, but there are usually a few roadblocks. So far, the most troublesome obstacle has been the use of Test Doubles. To try and mitigate this a bit I’ve written a 3-part series on this topic.
Part I is on stubs.
Part II is about mocks.
Part III covers spies.
Enjoy!
By: Kevin Baribeau
Book Review: Crucial Conversations
I’ve recently started exploring what I’ve heard called the “soft” side of software engineering. I think it’s a lot more important than most people (even in the industry) realize.
You can read about my first foray into this area here: http://kbaribeau.wordpress.com/2009/05/03/book-review-crucial-conversations/
By: Kevin Baribeau
Focused Practice
We all want to be better at what we do, right? But how do we go about improving our skills? I think the answer is the same, whether you’re an aspiring software developer, musician, martial artist, or whatever. The key is focused practice. You need to put time into developing your skill. You can’t just put time in either. It has to be focused time. This is time where you’re consciously thinking about your craft, critically analyzing your work, and looking for ways to improve it.
Some of this possible during your day-to-day life; but in my experience, you always get better results by setting aside a special block of time to work on a skill.
Code Katas
The best way I’ve found to apply this to software is through code katas. A code kata is a problem simple enough that developers of any skill-level should be able to solve them. A kata is also small enough to solve in a reasonable period of time. My learning process currently goes something like this.
- Pick a skill I want to improve at.
- Pick a kata to solve, and a language to solve it in.
- Solve the kata while focusing on how to apply that skill to the kata.
For example, let’s say I wanted to work on my TDD-fu. I would pick a kata that I knew reasonably well; in my case that’s the bowling problem. I would pick a language that I knew well, and had a good testing framework; that would be java and junit. I would then implement a solution while thinking about things like…
- How much code am I writing per test? Should I be writing more? Less?
- Is my test naming clear?
- Am I remembering to think about refactoring every time I see a green bar?
- Am I aware enough of what’s going on to know when I’ve made a mistake and chosen a bad test?
You can use code katas to improve your skills with just about any technique related to software development. Just to name a few, they work well for improving your pairing practices, new languages, writing good OO code, and learning new tools. You just have to pick a focus.
A Coding Dojo
There’s been lots of success stories recently about coding dojos. A dojo gives us a social context in which to work on our katas with other like-minded people. It’s a great mechanism to get feedback on your work, but the downside I’ve found is that a lot of people are intimidated by this. I think the best way to deal with it is just to work on a kata in your own time until you’re comfortable with it, and then bite the bullet and seek some feedback.
You can find more information about code katas and dojos at http://codingdojo.org. See the kata catalogue if you just want to get started. There is another list of problems I’ve found useful here.
By: Kevin Baribeau
Hard Problems
I ran into a hard problem today at work. Here it is:
Given two strings, check that the first does not contain a sequence of 3 consecutive letters that are also contained in the second.
Look easy? It should. I don’t know of very many easier problems. After implementing it though, I can’t truthfully say that it was easy for me. But, I don’t think the lessons I learned today are easy either. As far as I can tell, I made three mistakes:
Lesson #1: Be careful when picking your test cases
It’s easy to pick a test case that’s either too hard, or too easy to implement. If you pick a test case that’s too easy, you and your pair risk getting bored. Oddly enough, this is almost never a problem unless you’re actively trying to avoid picking a test case that’s too hard.
So, if you’re bored, then your tests are too easy… how do you tell when your tests are too hard? Well, that’s another hard problem. I don’t think I’ve nailed this down completely yet, but here are some clues I’ve learned to spot:
- It takes more than one try to get your newest test to pass
- When you do get your test to pass, another test fails
- Your pair doesn’t understand what you just did
- You find yourself wanting to refactor against a red bar
My advice when you run into any of these indicators is to stop. Stop writing code. Revert to a green bar. Now you have two options: Refactor, to make things easier; or pick a different test.
Sound easy? Try it. There’s two reason why it’s not.
First it’s hard to admit when you’ve picked a test case that’s too hard to implement. We’re programmers (craftsmen if you will), it’s our job to solve hard problems. We take pride in our ability to do so. We want to make that next test case work. Taking a step backward and reverting the code you just wrote (that doesn’t work) is an admission that you’ve made a mistake. Admitting this mistake is especially hard to do when you’re working on an “easy” problem.
Second, both of these options require you to THINK. It’s tempting to think that if you tweak a conditional here or extract a method there you’ll see a green bar soon. This rarely turns out to be the case. Even the easiest problem is going to require you to stop and think about the solution; probably more than you expected to.
If you run into this, Stop. Think about the problem. Discuss it with your pair. Then, take another crack at it.
Lesson #2: Commit Often
Today, my pair and I ran into all of the clues listed above, and failed to stop. It was at this point that we got burned by lesson #2. We realized what was going on, and wanted to revert to our last green bar. We hadn’t committed in 90 minutes. We were stuck with broken code. Oops.
I don’t have a strong opinion on when you should commit. Ideally, I would say you should commit on every green bar, or after every refactor step; whichever is easiest to remember for you. Of course, some teams are cursed with long running unit tests. Since you don’t want to commit without running your tests; this makes it difficult to commit so frequently. Do what you can to keep your tests running quickly, but in the meantime, find some balance between committing often and not letting your tests slow you down.
Lesson #3: Focus on your work — No Distractions
Today, during the “embarrassing pairing session”, I had an interesting email thread zipping through my phone, which dutifully beeped at me every few minutes. Every once in a while I’d try to keep up with it, meanwhile completely losing my focus on the problem and relying on my pair to get me back up to speed when I was done.
Please, be wary of checking your email or other distractions when pairing on a problem. If you’re not at the keybaord, your job is (among other things) to help figure out the next test, watch for warning signs like the ones I listed above, and maintain code quality. You probabaly can’t (I know I can’t) do any of these things while checking your email, or carrying on a casual conversation with a friend. Also, respect your pair. If they’re working, you should be too. They’re going to resent you if you don’t pull your weight.
By: Kevin Baribeau
Share on Facebook
Recent Discussions