OSCON 2007: Monday

Monday and Tuesday of OSCON are made up of tutorials during the daytime (there are also some evening events). A tutorial is an in-depth presentation of a specific topic, and it lasts 3-to-4 hours.

This morning I went to "Advanced Vim Scripting", for which the speaker was Steve Oualline (it was originally going to be Damian Conway, but they changed speakers a couple of weeks ago--dunno why). It was a good talk. I'm sort of new to vim (I've used joe for about ten years). Here are a few lines I've added to my .vimrc file today, as a result of the tutorial:

iab #p #/usr/bin/perl -w
iab teh the
map \1 :s/^/#/<CR>
map \2 :s/^#//<CR>
map \3 :%!perltidy<CR>
map \4 G:r!svn diff<CR>:sp<CR>gg<C-W><C-W>gg

The first two lines define a couple of abbreviations: if I type #p, it'll be replaced by #/usr/bin/perl -w. And I think I probably misspell the more often that I spell it correctly, so the second one will probably help a lot.

The first three map items allow me to do some tricks I've previously talked about doing in joe. The first two comment or uncomment a region (determined in visual mode), and the third runs perltidy on the whole file. The fourth is useful if you have vim in your VISUAL or SVNEDITOR envariables. When you type svn commit, svn opens vim so that you can record a commit message. If you type \4, the macro sends inserts the output of svn diff at the end of the file, splits the screen, sends each half to the top of the file, and leaves the cursor in the lower half. So you're ready to page down in the lower half to review the changes while recording the commit message in the upper half.

The afternoon tutorial was "Linux Performance Monitoring" with Darren Hoch. This was very interesting to me, as it covered lots of diagnostic techniques for troubleshooting server performance problems. Darren covered vmstat, iostat, mpstat, ps and a few other programs. He pointed out that it's a good idea to run these things when the system is quiet and when it's under load, and to archive this information. This gives good baseline data. In fact, I'm thinking about setting up some cron jobs to do this sort of thing on a regular basis, and maybe doing some trend analysis.

Darren also talked about iptraf, and this may be a good way to track the amount of traffic coming in and going out on various tcp and upd ports. I'd previously tried a very complicated process involving user-defined iptables chains and parsing the output of iptables -L -v. But I may be able to get comparable data by running iptraf for a few minutes at the top of every hour or something.