More robust verification

Fragile: relying on certain behavior between action and response, and using this to know when to validate the response

Better: make no assumptions about the behavior. Instead, continuously check for a valid response for a reasonable amount of time.

e.g.:

Fragile:
- perform action
- wait for loading ui (if the devs change or remove loading ui, this will break)
- validate response

Better:
- perform action
- check for valid response
- wait a second or two
- check again...for 5-10 seconds

The second is only invalidated if the response changes (less likely). The former is invalidated if the loading UI changes (apparently, any time the PM/devs get bored).

TimeStamp100nSec is DateTime FileTime

The TimeStamp100nSec value of CounterSamples is in the same format you get from DateTime.ToFileTime() (or maybe DateTime.ToFileTimeUtc() in some situations, not sure).

This was not made clear to me in any documentation I could find, but some example code half-way down this page spells it out.

To go from TimeStamp100nSec to a DateTime object, use DateTime.FromFileTime(timestamp100nsec).

Division of labor for automation

Devs should maintain robust task library of functions that perform and validate user interactions (e.g. "Select", "Resize"), so they can easily update these functions at the same time the behavior changes in the build.

Test should maintain the scenarios that use these basic actions. This way, they can stay above the nitty gritty of changes to buttons, DOM, etc, and focus on building a large library of interesting/eclectic scenarios and test files.

This is especially bad with actively changing features -- if test is responsible for the tasklibrary as well, then they get stuck churning code just to keep the most basic functionality tests up to date. This is made worse if dev hates the automation system test uses...

My bash prompt

Here's my bash prompt (in ~/.bashrc):
PS1="\[\033[1;32m\]$(date +%H:%M)\[\033[0m\]:\[\033[1;34m\]\W\[\033[0m\]$ "

For an explanation of the control codes (the parts that look like gibberish), go here.

The result looks something like this:
16:29:Downloads$

In other words, it shows the time and the name of the directory I'm currently in (not the full path; if I need that, I can just run pwd)

Most prompts show the user and/or machine name, which is probably a good default, but I usually don't care about it so much. What I found far more useful in multi-machine situations with command prompts was to change the color of the timestamp (e.g. my laptop was green, my home server was yellow, various school machines were white), since I'm personally much more likely to notice differences in color than differences in name.

I also find the time to be useful in a variety of situations (e.g. how long did that command take to run? when was the last time I built?)

You can certainly do more elaborate prompts with all kind of information in them, but I like mine because it's very compact and leaves lots of space, even in 80-char windows

On mazes as levels

Turns out mazes are no fun as levels in games. Designing good levels requires actual design skill/experience, and designing an algorithm to randomly generate good levels requires even more.

Randomly generated maze? Nowhere *near* cutting it.

Hide the resize grip in Ubuntu 11.04

In Ubuntu 11.04, they added a gray box/triangle to the lower right hand corner of GTK windows (to help people who were trying to resize by dragging it, I guess). For those of us that use Alt+Right Mouse Button to resize their windows, it's pretty obnoxious. Hide it by putting the following in your .gtkrc-2.0 file:

style "default-style"
{
GtkWindow::resize-grip-height = 0
GtkWindow::resize-grip-width = 0
}

class "GtkWidget" style "default-style"

See here for more info.

EDIT: It looks like the .gtkrc-2.0 file will be overwritten by Gnome every time you change your theme. However, it will always include the contents of .gtkrc.mine, if it exists. I recommend putting the above in there instead.

Disable volume OSD in gnome (workaround)

By default, when you use the media keys to change the volume in Gnome, an On Screen Display (OSD) appears, telling you what the volume is. This is distracting when you're trying to watch full screen video (especially in flash), and can cause other problems with full screen apps.

There doesn't seem to be a good way to turn it off, but here's a way to work around it:

1. In Gnome's "Keyboard Shortcuts" dialog, use "Add" to add 3 custom shortcut
   
   
   
   • Increase volume: amixer -c 0 sset Master,0 1+ unmute
   
   
   • Decrease volume: amixer -c 0 sset Master,0 1- unmute
   
   
   • Toggle mute: amixer -c 0 sset Master,0 toggle
   
   
   
   


2. Assign these to the media keys

The keys should do the same thing they did before, without showing the OSD. (If you want to change volume more quickly, use 2+, 3-, 4+, etc instead of 1)

Disable flashing notification in Windows

Use regedit to set HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundFlashCount to 1 (more info here)

There's also ForegroundLockTimeout, I'm not quite sure what that does.

Be sure to log out for the changes to take effect.

Center mouse after aero snap keyboard shortcut (auto hotkey)

True X-Mouse has a few problems. The most noticeable (for me) is that if the window the mouse is over moves (ie: you use the Aero Snap keyboard shortcuts, practically my favorite command in Windows 7), the window focus changes to the window below it. (This can really mess with your muscle memory!)

Turns out AutoHotKey can remedy the situation (I'm new to AutoHotKey, so there's probably a more elegant way to do this):

; Aero-Snap Mouse
; Move mouse to center of windows that are aero-snapped (True X-Mouse won't do this)
CenterMouseInWindow(Title)
{
WinActivate, %Title% ; True X-Mouse may have taken focus away when we moved
WinGetPos, X, Y, width, height, %Title%
center_x:=width/2
center_y:=height/2
MouseMove,center_x,center_y
return
}

#Left::
WinGetTitle, Title, A
SendInput #{Left}
CenterMouseInWindow(Title)
return

#+Left::
WinGetTitle, Title, A
SendInput #+{Left}
CenterMouseInWindow(Title)
return

#Right::
WinGetTitle, Title, A
SendInput #{Right}
CenterMouseInWindow(Title)
return

#+Right::
WinGetTitle, Title, A
SendInput #+{Right}
CenterMouseInWindow(Title)
return

#Up::
WinGetTitle, Title, A
SendInput #{Up}
CenterMouseInWindow(Title)
return

#Down::
WinGetTitle, Title, A
SendInput #{Down}
CenterMouseInWindow(Title)
return



This captures the aero snap shortcuts, gets the title for the current window, sends the aero snap shortcut to windows (which moves the window), then re-activates the old window and centers the mouse.

It's not instant (even with MoveMouse speed=0, I tried it), so you can't do Win+Shift+Left/Right rapid fire, but it works pretty well other than that.

Focus follows mouse for Windows

True X-Mouse does a good job of focus-follows-mouse in Windows. It's *really* nice for switching focus from remote desktop to local windows, since alt-tab is (intentionally) eaten by the remote machine

It also does some clip-board stuff to simulate X-Windows cut/copy/paste behavior, which I don't really care about (but so far hasn't gotten in my way).

My new favorite vim theme

xoria256. She's a beauty!