I used to dread having to search backward in vim, because that meant scrunching my right pinky and ring finger next to each other to hit ?. So I remapped it. I used cc because I don’t use cc to change lines—I use S for that (it does the same thing). It’s much easier for me to hit cc than to hit ?, and since c is in the bottom row along with the / key it’s not hard for me to remember to use it.

The remapping is simple:

map cc ?.

After mapping this, I realized that the downside to having a funky vim setup is that I can’t have someone else who knows vim type in my window very easily. I am thinking of making pair and unpair commands that turn off and on my funky keymaps, respectively. Rather than duplicate the mapping code, I’ll just call unpair in my .vimrc file.

I am still using MacVim with my enter key mapped to escape. I use shift-enter or enter followed by o to insert multiple lines. I switched back to the normal setup for a while before realizing that the number of one-line inserts I make far outweighs the number of multiline inserts I make. I have found that is the best way for me not to have to reach for the esc key (I use ctrl all the time and have my caps lock key mapped to ctrl, so mapping caps lock to esc was out of the question).

I have ctrl-J and ctrl-K mapped to insert blank lines, and use them whenever I can remember to do so. I took the code from the Vim Tips Wiki, and switched the Ctrl for Alt in the remappings, so Ctrl inserts and Alt deletes. I use the command for inserting more than to deleting because I find it easy enough to just go down a line and hit dd than to remember to use a custom remapping.

Roughly two years after reading Snow Crash, I finally started reading Cryptonomicon. I’m really enjoying it so far. I can’t help but feel a little bit angry with myself for not reading it sooner, though. I really enjoyed Snow Crash, but after I finished reading it I didn’t immediately start on another Neal Stephenson book, but instead started on a book by another author. The other book wasn’t as exciting as Snow Crash, and it took me more time to read, and when I finally got done with it I had moved on to a different group of books, forgetting how much I enjoyed Snow Crash.

A couple of weeks ago, having lost interest in another book I was reading, I started carrying Snow Crash around with me. Two days ago I started reading it a second time. After I finished the first chapter, my interest in Neal Stephenson was re-kindled, and I picked up a copy of Cryptonomicon. And I am really enjoying it, and it’s helping me deal with stress.

I learned a couple of lessons from this experience:

  • I shouldn’t rely on passion alone to drive me to pursue my passions. Few, if any, pursuits are immune to distraction. Setting specific goals is important even when it’s for something I really want to do.
  • It doesn’t take long to rekindle a passion. If I’m feeling bored, and there’s something I remembered really wanting to do, but am considering putting off to pursue other interests, I can just try getting back into it for a short while. If my excitement returns, I can pursue that, rather than try to do other things I’m only mildly interested in. If not, I’ve only spent a small amount of time on it.

There’s no silver bullet to motivation, but it’s comforting to know that I’ve got a couple more tools in my motivational tool box.

In an earlier post, I said that I am no longer going to deny myself the pleasure of dabbling in different editors. It was my interpretation of the “use one editor; use it well” mantra I got from the pragmatic programmers. It was probably a misinterpretation of it. They also would recommend using the best tool for the job, and how can you know what the best tool for the job is without learning about all the alternatives? And, in the case of text editors, it’s practically impossible to know every one of them well enough to judge which is best.

One day I was feeling frustrated with vim, so I fired up emacs. I wanted to remind myself of one thing it has that vim lacks—the ability to view/edit a single buffer in multiple frames. Pretty nifty, really. If you’re unfamiliar with the terminology, in Emacs a frame is a top-level window (think JFrame), and a window is a split within a frame, or the whole frame if it isn’t split. In MacVim, each frame has its own vim instance with its own set of buffers, so you can’t view the same buffer in two different frames, which would be nice for having a big frame and a frame that can sit alongside other windows. In emacs it works without a hitch.

While I was in emacs, I noticed something else I like about it—the scratch buffer. In vim there’s a blank buffer that shows up when you start it, but it seems like vim would rather pretend it’s not there. If you delete a buffer, it closes any window (i. e. split view) that is associated with it, unless there is only one window in the frame, in which case it grudgingly shows the scratch buffer (or the last buffer if there’s another buffer still open).

I can think a couple of things that I gained from this experience. First, I can see that there are other developers who can sympathize with my experiences. If I ever get frustrated with vim, I can take refuge in the emacs community. Same for when I got frustrated with emacs and became a vimmer. Second, I was able to take the scratch concept and apply it to another part of my computing experience. I created a directory in my home directory called “scratch”. It’s going to be my new temporary working directory. I had one called sandbox but the name never quite felt right and I never got in the habit of using it.

I don’t know which editor I’ll be using a year from now. But for now, it’s vim, for the most part. I do want to try out SLIME and see how viable Viper-mode (vim emulation in emacs) is, though.

Over the last week I’ve been learning how to quickly develop simple applications in Rails without looking at API documentation. Each day I’ve been starting from scratch and seeing what I can create in an hour, only consulting documentation when I really need help. The first day I didn’t use scaffolds and I only got creating, reading, and deleting working with a single model. From the second day until today I’ve been using scaffolds. On Friday I got two models with a has_many association and image attachments (using paperclip) working. Each day I start from scratch, not copying or referencing the code from the previous day (though I do save the code). I think starting from scratch each time has helped me learn more quickly than I would if I were to use the last code each time.

Today I went back to working without scaffolds. Since I’ve been trying to read the documentation as little as possible while developing, I had to figure some things out for myself. One thing I had to think of was the list of actions to type when generating a controller. Here is what I came up with:

script/generate controller Planets index new show edit create update destroy

I’m obsessive-compulsive, so not only did I try to remember what actions are used in scaffolds, I tried to put them in an order that makes sense to me. I put index first because index is special. After that, there were two sensible approaches I could think of to order the remaining actions. I could either order by CRUD or order by whether or not the actions have views. Either way, I would use the other ordering technique within groups. I went with ordering first by whether or not actions have views, and then by CRUD. I started with the actions that have views because it’s nice to have them at the top when jumping from a view to its controller.

Here’s my thought process in a tabular format:

Create Read Update Delete
Has View new show edit *
No View create ** update destroy

Notice that there are a couple of holes in the table. The first one (*) is missing because the interface for deleting is built into the index. It doesn’t have to be this way, and in fact varies widely on the web. It could have its own page, or it could be on the show or even edit page (Side note: I think it’s bad UI to put the delete button on the edit page because the edit form doesn’t fit into the workflow of deleting an item. The user may want to look at an item before deleting it to make sure it’s something they don’t need, but they’re unlikely to want to edit an item). The second one (**) is missing because in the simple case reading is achieved entirely through GET requests.

One thing that’s convenient about having the ones without views at the end is that it makes it easy for me to remember which skeleton views to delete after running the generate command. It’s the last three.

It used to take me a minute or a few to remember what actions I need, but now that I have this mnemonic it should only take a few seconds.

Now, I place a certain level of importance on conventions. After I came up with this mnemonic I looked at a scaffold to see how rails orders things. The only difference between my ICRUDCRUD ordering (index, CRUD with views, CRUD without) or ICRUCUD ordering and the standard scaffold ordering is that the show and new actions are swapped. So rails uses the RCUD ordering. Fair enough. I have pontificated on whether the ordering in CRUD makes sense or is a bacronym. Create and read are pretty useless without eachother. Below is the table with the RCUD ordering. I threw index into the empty cell. If you read the first line left to right, then move down, like a book, the order is the same as it is in a scaffold:

The order of actions in a scaffold
index Read Create Update Delete
Has View show new edit *
No View ** create update destroy

Now, how to remember RCUD? Well, remembering to swap C and R is one way, but I prefer to think of a Rails cow chewing its CUD.

rcud

Original image from cerulean5000 on flickr. Used by Creative Commons license.

I just watched Corey Haines’ lightning talk from this year’s acts_as_conference:

He makes a lot of really good points in a short amount of time. One of the things he says is that if we have to look at documentation for a technique, we’re unlikely to use that technique when we’re in a time crunch. I think this is a very good point. Another time when I might not use the documentation is when I’m just dabbling.

To learn things, he suggests doing arbitrary tasks repetitively to get them engrained into our minds.

I spent a number of hours doing arbitrary tasks with vim, and I’ve gotten pretty good at using vim IMHO. I wish I could say I was as good at jQuery, but I haven’t got it down as well despite doing real projects in it. I think perhaps it’s best that I pick an arbitrary task, or at least do a real, but small, task repetitively, or keep trying to improve it, until I start to really get the hang of it.

On a side note, Corey Haines’ has quit working a regular job and started traveling around and pair programming with people in exchange for room and board. He calls himself a Software Journeyman. It will be interesting to hear what he learns from the experience. I hope his journey takes him to Arizona at some point!

This is just a quick update on how I’m using the enter key in vim. The sticky shift-enter key configuration didn’t work out for me. After pressing shift-enter once, I found that I would press shift-enter again, expecting it to create a newline. I wound up just remapping <CR≫ to <Esc>, and using shift-enter to insert newlines, or pressing enter and then “o” or “O” to create a new line above or below the current line. I use the latter option most. The only time it doesn’t work is when I need to split a line into two. For that I use shift-enter.

Shift-enter doesn’t work when using vim in a terminal, so the remapping doesn’t work quite as well in the terminal. I use it anyway, though. I should remap something to split a line into two, but so far I haven’t. I use vim in the gui (MacVim) most of the time. The couple of times I’ve had to split a line in the command line, I’ve hit:

  • D to delete the rest of the line and yank it
  • o to open a new line
  • Enter to get out of insert mode (since it’s remapped to Esc)
  • p to paste the rest of the line, that I deleted earlier

…which is terrible. If I start using command-line vim more often I’ll add a mapping for it.

This might seem like a pain, but for me it beats reaching for the Esc key. YMMV.

Update: zenzike pointed out in the comments that if you remap CR (the enter key) in the terminal, Control-CR still inserts a newline. So you could use Control-CR to insert a newline if CR was remapped to Esc. Unfortunately, this doesn’t work for me in OS X’s terminal or in iTerm by default. It does, however, work in gnome terminal running under Ubuntu on VMWare Fusion. I’m not sure why it doesn’t work in either of the two OS X terminal programs. I would be curious to learn why it doesn’t work and how to fix it, though, as this otherwise a very nice solution.

A few weeks ago, I started using vim as my main text editor. Soon after that, I installed the vimperator Firefox extension on my main computer. A few days into the use of these two tools, I was really excited about both of them. It takes more than a few days for me to know whether I’m comfortable with using a particular piece of software regularly, though.

I’m still using vim every day, and I like it. It’s powerful, ergonomic, and customizable. There are a few annoyances. I still haven’t figured out how to properly configure Firefox to use MacVim as an external editor. Vim doesn’t support having multiple frames for a single instance of vim (emacs does). The official wiki, hosted by Wikia, has horrible ads, and I refuse to install an ad blocker, because I don’t want to turn a blind eye to virtual blight like the maintainers of vim have. Nevertheless, I’ve become quite comfortable with vim and will continue using it. While I’d like it much more if it didn’t have these annoyances, it has relatively few annoyances compared to some other editors I’ve tried, and the good things about it outweigh the bad.

My experience with Vimperator was different. As with vim, I really enjoyed using it at first. Over time, though, I found myself growing tired of it, even though it enabled me to browse faster. The biggest problem for me was that the commands only work if I’m in the normal mode, and it’s very easy to get thrown out of the normal mode. The two things that most often put me in the wrong mode were full-page Flash files and JavaScript that placed the focus in text boxes. Another issue was that I couldn’t easily use the keyboard to scroll in a div. I can’t easily do that with normal Firefox either, but Vimperator is supposed to make browsing with the keyboard easy, and it does it for the most part.

I uninstalled vimperator, but I miss its functionality. I’d like a lightweight extension that makes it easy to click links or jump between form fields with the keyboard. I don’t think that the vim input model is suitable for keyboard navigation within a browser, because the browser environment is too unpredictable. I’d like to see a couple of multi-key combinations that activate keyboard input, though. These would work inside of text fields. Flash would probably still break them some of the time, but to deal with that I could install FlashBlock.

I really enjoy trying out new development tools. I think the next thing I’ll try out is a visual CSS editor. Any suggestions?

I just went to BIL. It was a fantastic conference. I met a lot of interesting people and saw a wide variety of talks. It was my first BIL. The first BIL was last year and about a third of the people at this BIL were there last year. Repeat attendance is always a good sign. It’s quite likely that I’ll go next year.

The first talk made the greatest impression on me. It was Brad Templeton of the Free Software Foundation talking about the problems with Cloud Computing. I always felt I was giving up flexibility and privacy by having most of my computing take place on an application service provider’s service, but this talk helped solidify that feeling. I’m going to see about getting my email under my control soon (I use GMail right now).

Of the rest of the talks, these ones really stood out:

  • Seasteading: how to homestead the high seas and why it will make politics work better by Patri Friedman – Really interesting idea. But could it actually work? After hearing the talk, I think it might.
  • California’s Water Crisis – What YOU can do! by Ryan Arroyo – As a future California resident and connoisseur of Californian produce this is really close to my heart. He gave lots of good water-saving tips. I asked him what the impact of the water shortage might be on farmers and he said that it looks like it will be tough for small farmers. I’d like to get involved in making sure the organizations that control the water supply are fair to small farmers.
  • Secrets of Social Influence (How to get a Date) by Francisco Dao – I finally got a good definition of what “hovering” is, in the context of flirting. I have done that in the past and will avoid doing it in the future.
  • The art of Conference Crashing by Chris Axton – It turns out that the easiest way to crash a conference is to volunteer. Go figure. Lots of great photos and stories, though.
  • What’s Funny about the Interwebs by Ben Huh of icanhascheezburger.com and failblog.org fame – Even though his work (taking user-generated content for free and slapping absurd quantities of ads on them) annoys me, it was great to hear him talk. And I can’t blame him too much. He talked about the lifecycle of a meme, using RickRolling as the example. Good stuff.
  • Color by Numbers – The Wonders of Algorithmic Art by Matthew Shultz – A fractal art demonstration using both visual tools and code.

This is just a sampling of the interesting talks I saw. I also missed some good talks. I can see many of them online, though.

I took this week off and am going to travel up the coast to San Francisco. I’m in Santa Monica right now. It’s been a wonderful vacation so far!

I set up vim to use enter to get out of insert mode. This prevents frequently having to reach for the escape key or use a multi-key combination. To insert a new line while in insert mode, I now use shift-enter.

An idea I had this morning is to make shift-enter swap the shift-enter and enter bindings. This way, if I’m in the mode of writing something new without manipulating text, I can push shift-enter once to enter a newline, then push enter for each additional newline, and push shift-enter when I’m done to get out of insert mode.
shift-enter

To implement it, I created a function that toggles the bindings, and added a call to the function to my bindings for <S-Enter>.

function ToggleEnterMappings()
  if mapcheck("<CR>", "i") == "<Esc>"
    iunmap <CR>
    inoremap <S-Enter> <C-o>:call ToggleEnterMappings()<CR><Esc>
  else
    inoremap <CR> <Esc>
    inoremap <S-Enter> <C-o>:call ToggleEnterMappings()<CR><CR>
  endif
endfunction
call ToggleEnterMappings()

Time will tell whether this is a good setup for me. I think if I do single-line inserts much more often than I do multi-line inserts it might.

After a friend recommended it, I gave Twidge a whirl. Twidge is a command-line microblogging client written in Haskell. It works with twitter and identi.ca.

Installing it on my mac was tricky at first, because I didn’t have instructions for installing it on Mac OS X, but once I figured out how to do it, it turned out to be really easy. I posted the installation instructions for OS X on the Twidge wiki.

So, how does it work? If you put twidge in your path, you can type twidge and it will provide a help screen. You can type twidge lscommands to get a list of commands. Of particular interest to someone who’s starting out is twidge setup, which asks for your username and password and puts them in ~/.twidgerc for later retrieval. Once it has your username and password, you can type twidge lsrecent for a list of recent updates by people you’re following, twidge lsreplies for a list of replies, and twidge update to post an update.

If -asu is specified on the command line to lsrecent, twidge will show all the updates since lsrecent was run. The -asu option has the same effect on lsreplies. In the Twidge HOWTO it shoes how to pipe lsrecent and lsreplies to less to enable checking all tweets with one command. I reversed the order so the replies would show up first, so I’ll see the replies even when I decide not to read all of the tweets. The command I put in ~/.bash_profile is here:

alias twidgecheck='(twidge lsreplies -asu; twidge lsrecent -asu) | less'

Now if I run twidgecheck, I can see all my updates. Nice! And once I’m done with them, I don’t have them showing up next time I turn to twidge. Update zero, if you will!

My main dislike with this system is that links are harder to visit with my terminal. If I was using the gnome terminal, I could just click them. Maybe I can find a way to make iTerm do that.

The other day I went back to an old branch that had about five files that were changed and I only wanted to incorporate two of them into my master branch. In order to just merge in a couple, I used git merge with the –no-commit option.

git merge --no-commit planner

This merges in all changes but doesn’t commit it. Since it isn’t committed, it’s easy to roll back individual files. I ran git status to get a list of files and rolled back several files with git checkout. When I was done, I had only the two files I wanted to merge showing up when I ran git status.

Yesterday I started trying out Vimperator, and so far I’m impressed. It’s a Firefox extension that puts a vim-like keyboard interface on top of Firefox.

After using it for a while, I wanted to turn the bell off, because I find it to be distracting. I turned to the documentation. I quickly found a visual bell option, but I find visual bells to be even more distracting. Then I saw the visual bell CSS style option, which can be set to an empty string for no bell at all. Bingo! Or so I thought.

It turns out that the page flickers when the bell is triggered. This is not the desired effect. So after searching the docs one more time, I unpacked a jar and poked around in the source code of Vimperator.

There’s a beep function in there. I changed the beep function to return false and Voila! It did nothing when you scrolled past the bottom or top of the page.

Rather than keep the code patched, though, I figured out how to implement my change in my ~/.vimperatorrc file. There’s a javascript command for executing a line of javascript. Vimperator’s beep function is in a global “liberator” object. Combining these two bits of knowledge, I came up with the following line which can be added to ~/.vimperatorrc:

javascript liberator.beep = function() { return false; }

It’s simple but it works. It would be nice if completely disabling the bell (including any visual artifacts) were built into Vimperator, but being able to fix it with a one-liner in the configuration file is the next best thing! Kudos to the Vimperator developers for writing code that’s easy to modify.

I’m not sure how often I’ll use Vimperator. I need to learn how easy it is to pass the input through to the current web page first. But it certainly seems to do a difficult job remarkably well!

Update: I started a Silencing and Disabling Bells WikiBook and put instructions for disabling bells in Vimperator, MacVim, and iTerm in it. Contributions welcome!