Handy Reference: Cursor Styles

How about a little front-end fun? Here are some cursor styles, cut and pasted from the following web site: http://rainbow.arch.scriptmania.com/css/css_cursor_control.html. Mouse over the stuff below to see the cursor change.

cursor: auto	the default cursor
cursor: crosshair	gun-style cross
cursor: default	no change
cursor: pointer; cursor: hand	the normal link-hand
cursor: wait	the hourglass
cursor: text	the text-selecting 'I-beam'
cursor: help	an arrow with a question-mark
cursor: move	crosshair with arrows on the ends

Development posts

I'll be mixing in development-oriented posts here until such time that I create a separate blog, or just change the title. I'd like to put in some handy reference materials. For example, it'd be nice to have one reference to string formatting that has every instance, and a few examples of each in action. There are a few such things out there, but they're not as good or clear as they could be.

They made me a developer

There was a bit of a shake-up here at work. They let go the full-time tester, moved me to development, and made the support guy the QA guy. Which is grand for everyone except my QA protege, and I'm not sure what it says about my testing ability. Granted, I'd been angling for a shot at development all along, and I consider this a move in the right direction. I'll always consider myself a tester, regardless of my job title. At least, I hope so. Testing is intellectually exhilarating when done right, and when intellectually exhilarating testing is asked for by the employer/customer.

My casual post-mortem of the shake-up leads me to the following conclusions:

• Our business model doesn't require as many people dedicated to testing, since our clients generally provide their own QA personnel.
• Our testing is not an on-going thing. It happens on an on-demand, by-request basis. Paying two guys to be full-time testers doesn't make sense in our small company. The utility that is gained just can't justify the costs, not unless management and/or QA find better ways to utilize their time.
• If I hadn't shown some proclivity in programming previously, I would be riding into the sunset alongside my colleague (whom I referred to this job, making that whole affair all the more difficult).

In the end, I can see how it was the right way to go. There will come a time when we will have different QA needs. It will evolve into something similar to what we had. I would love to see QA being done by developers. I mean real QA, not cursory checks and over the wall she goes. But that would require the devs to laterally learn that which they're not super-pumped about. It'll be interesting to see how that goes. Implementing new systems and new initiatives around here is a bit like pulling teeth.