One thing that Steve Loughran talked about at the March 2002 Web Services DevCon was about scheduling loads.  His philosophy is this: it takes 10 minutes to load a server, but only 1 minute to find a bug.  Therefore, you should load at most once a day, to avoid running in circles.

How true this is.  I've had a lesson in load discipline over the past few weeks.  In the system I'm working on, it takes about an hour from the time a build is kicked off until the time the code is delivered from the staging area.   To load on our "copy" system, where customers develop code against, it takes about 5 minutes each to load 2 app servers and another 15 minutes each to load 2 web servers.  And that's the problem: it takes about 90 minutes and at least 3 people (me, the sysadmin who actually executes the install, and the change management coordinator)to build and install the system, and a minute to find the bug.  Case in point: this morning, we loaded the system with the output of Friday's daily build.  But somebody had checked in a stylesheet and apparently hadn't done much testing, and this completely broke one of the web services,which we found out not 5 minutes after the load was complete.  If we'd let the build settle on a testing system, we'd have shaken that problem out there rather than on a (semi-) production system.  So the first point is that you have to get a day of testing on some server that doesn't fall under change control.

The second problem is that when you do find a bug, the worst thing to do is to patch the bug and slam an update onto the server you've just loaded.  This just puts you further behind the 8-ball; now everybody's life is on hold until the server's up.  The better solution is to do some triage:can the server live until tomorrow in its current state?  If so, then work towards shaking out the problem on development servers; if not, then roll back the install and fix the problem on development servers.  Either way, if a load fails, it's not getting fixed until tomorrow.  I don't care who's screaming for a fix; unless somebody's life is at risk, it's not happening until tomorrow.

What's so wrong with doing more than 1 load a day?  Number one,it wastes time.  Even in a heavily automated environment, a load takesa lot of time, much longer than finding bugs.  Number two, with all the wasted time, the amount and quality of testing goes down, and you end up testing on production servers, where it's most expensive to fix.  And finally, it puts too much pressure on everyone involved.  Developers start to try to squeeze changes in before the build without adequate testing. The build monkey screws up an install script.  Sysadmins start making typos.  People under the gun make mistakes.  This isn't trench warfare, it's software development,so don't go acting like you'll get a medal for heroics.  It's far better to get into a rhythm and let the process work itself out.

Dvorak and Text Editors

I started using Dvorak about a year ago and am way too comfortable with it to go back now. I can't type as fast as I could on QWERTY (yet) but I'm already faster than most people. Switching to Dvorak wasn't about speed, though. I was starting to experience pain in my wrists and switching to Dvorak alleviated that. There was also a certain amout of geek pride in using a keyboard layout that nobody else I knew could use. It's fun seeing people's reactions when they sitdown at my computer and see nothing but gibberish appear on the screen.

The one problem that I have is keyboard shortcuts. They're designedfor people who use the QWERTY layout and often much harder for us Dvorakfolk. I don't know why but my brain doesn't use shortcuts the same way thatit types. I often find myself looking at the keyboard to find a shortcut(even though I never look when I type). For that reason, I think of Ctrl-Cas Ctrl-I, Ctrl-X as Ctrl-B, Ctrl-V as Ctrl-., and Ctrl-Z as Ctrl-/ (becausethose are the letters I see when I hit the right keys to invoke those shortcuts).This can't be good for my poor little brain.[Jason Diamond]

I switched to Dvorak almost 5 years ago, because I was frustrated by my inability to touch type on QWERTY.  Plus, I'd heard all the stories about how QWERTY was intentionally designed to slow a typist down, and my brain rebelled against this.  When I started at my current job, I decided that it would be a good time to bite the bullet, since my workload was pretty light at first.  The result: after 7 years of hunt and peck (since Ichanged majors from Music to CS - ironically, pain hasn't been a big issuefor me with typing, though it's one of the reasons I dropped my music major.),in 2 weeks, I was touch typing.  Last I checked, I could do 60 WPM,not very impressive, but certainly competent.  

As far as accelerators, I've just learned the new layout.  This was pretty easy because I tend to use the arrow keys for editing.  I think that the reason is that since I wasn't touch typing, I didn't lose much by having my hands leave the home position.  Now, it really bothers me, so I'm gradually learning to do everything from home.  So it's not much of a re-learning process, because I never developed those reflexes.  One program that I use a fair amount, Attachmate's Extra! 3270 emulator, seems to implement its own accelerators, so the editing keys are Ctrl+ ':', 'Q', 'J', and 'K'.  This drives me bananas!  One other issue is the systemdefault keymap: at home, it's Dvorak, but at work I leave it alone, so otherscan log in on my machine.