User Stupidity Tolerance

---

Here are 3 tips I'd suggest to enable you to save your MP3 player if it falls into water. 

1. Turn off the power and disconnect the battery as soon as possible after immersion. The less water gets inside the circuitry of the device, the better!
   
   
2. Let the device air out in a warm, dry environment for at least 24 hours before trying to use it again. A hot, dry attic or an area with a steady flow of warm, dry air helps speed the process.
   
   
3. Find a belt pouch or ideally a waterproof MP3 player pouch and use it anytime you plan on being near a big body of water. If you manage to save your old player, it'll thank you for this, but if it dies, safeguard your replacement.

---

Here are the gory details. A few years back, I purchased a Sansa e250 MP3 player and later a pair of Blockade Noise-Isolating Earbuds, both via WOOT. 

I haven't at all been into the hype surrounding iPod, Zune, nor any other big-name players, I just wanted an MP3 player that was very portable, could store at least a few gigs of my music, and had good battery life. For these the Sansa definitely delivers.

Now the model is discontinued, it no longer even appears on the Sansa Music Players and Accessories page. Yet, despite it fading into the distance with countless other technology products into the proverbial sunset, I must sing its praises for one peculiar reason: user stupidity tolerance.

My wife and I went fishing this past week at Lake Panasoffkee. Beer and fishing certainly go well together, and as my bait lay in wait for some hungry fish, I sipped my third beer on an empty stomach, and pushed play on my Sansa and sat lazily outside, enjoying a cool morning breeze coming in from across the lake.

Ideally, my yanking on the earbud cord would've had the MP3 player leap out of my pocket, do a loop in midair, then land neatly in my palm with the controls ready for my commands. Beer, unfortunately, tends to knock the likelihood of an ideal situation down a few orders of magnitude.

Instead of landing in my outstretched palm, the tug of the cord caused the player to somersault up, over my hand, and like some hapless mountaineer getting a handhold at the worst possible moment, the plug popped out of the socket, and the player splashed down into the water. As I looked into the depths, I could see the bright blue LED of the volume dial glowing happily from beneath about two feet of tannin-stained lake water.  

As beer would have it, my judgment was impaired, so I wasted precious seconds dumbfounded at what had just happened. I lay down and tried in vain to reach for it with my hand, too far. I tried grabbing a bucket and getting the player up and in, and nearly lost my breath and the bucket in the process, water plus sand plus MP3 player is a lot of weight at that awkward angle. 

Finally I threw off shoes and socks and jumped in, grabbing the player. I did what I could to shake excess water off and out, and hit the power button. I ran inside our room, found a knife, and removed the screws fastening the back cover. 

A few shakes revealed that some of the lake water had indeed infiltrated the case, but surprisingly not a lot. I guess the designers anticipated it needed to at least be somewhat water resistant in case someone was using this MP3 player while jogging or otherwise sweating profusely. So much the better!

I quickly disconnected the battery and rinsed the inside of the case with tap water (tap water like lake water has electrolytes swimming around that might short out the electronics, but since I had no distilled water handy, I figured with the power off it would be better than nothing).

I decided to let the player air out near the space behind the fridge, since hot air is almost constantly being pumped out I figured it would help dry out the circuitry. I guess it did, because now, the player is back to its old self.

There's a good reason why I've featured the song "Amazing" by SEAL on the resurrected Sansa's playlist, I'm amazed it survived its brief underwater encounter, and thankful that it no longer swims with the fishes.

Headache Help

I don't typically suffer from headaches, but today I've got one that I liken to an icepick through the eyeballs. Here are some remedies for headaches that work for me, which you may find helpful, and don't require drugs.

• Headache nerve pinch. Using the thumb and index finger of one hand, grasp the webbing between the thumb and index finger of the other until you feel pain, and hold it with firm pressure for up to one minute. This will distract your brain pain, and hopefully take your mind off the headache.

• Juice it. Using a Magic Bullet™ or at the very least, a blender, create some juice with some fresh carrots and a hunk of fresh ginger root. Ginger is notoriously good at laying the smackdown on a headache, but by itself it's a bit difficult to stomach. Blending it with carrot juice makes for a sweet, tasty headche remedy.

• Go outside. If you've been in a stuffy office all day, your headache may be a hint from your body that you need a break. I find that walking outside and getting some fresh air and sunlight can help combat a headache.

Pharmaceutical companies would have you believe that their drugs are the ultimate solution to headaches, but there are at least a few reliable home remedies that can relieve headaches without popping pills. Hopefully these will help you as they've helped me.

Adobe Flash Player Download

-= UPDATE =-

Nice try, Adobe. I notice that now the links depicted in the image below now simply refer you back to the main install page for Flash and other players.

Click below to obtain the installers for Flash without the Adobe Download Manager.

Flash for Internet Explorer

Flash for Firefox, Chrome, Opera and other browsers

Adobe also provides links to previous major releases of the Flash player, and a link to a Flash uninstaller for those times when it needs to be manually removed.

Archived Flash Player Versions

Flash Uninstaller

We can't live without Flash, now can we??

Optimizing SQL Views Profit++, Fun--

While working feverishly towards meeting a looming deadline on some SQL code, a problem arose. A particular UI that relies on a particular stored proc to perform a particular task was bombing. 

I brought up SQL Profiler and retraced the user's steps, and found the culprit, a convoluted view I was joining to as a step within the update seemed to be taking way too long to retrieve data.

The view started out relatively simple, a SELECT over several busy tables joined together along with a few scalar function calls and a very few subqueries nestled within some CASE statements. It evolved, thanks to lack of time and impatience and poor choices on my part, into a bit of a behemoth; it took roughly 1:30 to return the full result set. This didn't seem like a big deal at the time, however, because I planned to use it to pluck out specific entries, for this purpose it returned results in less than a second or two, which was acceptable.

Using it in a join though was a relatively new, hastily chosen design decision, and apparently it was proving a very poor choice since it was causing the UI to time out. I began by optimizing the view, minimizing the interaction with the busy tables as much as possible, avoiding subqueries unless absolutely necessary, and creating some new scalar functions to replace previously funky logic. No joy, however, as this only shaved around 10 seconds off the runtime for a SELECT, too little, I thought.

So began the quest to create a table-value function instead, full of optimizations like stuffing frequently used values into variables and creating a subset of the main tables in a table variable (impossible from within a view) and minimizing the use of scalar functions and even resorting to applying the WITH (NOLOCK) and eliminating string searches wherever possible...

It turns out, however, that the entire two paragraphs of chronicled woe were completely unnecessary. Here's a SELECT from within the stored proc which joins with the aforementioned view, notice anything odd?

SELECT TOP 1 @Fruit = 
        
  CASE 
      WHEN v.Operation IN ('APPLE', 'BANANA', 'GRAPE') THEN v.Operation
      ELSE NULL
  END

FROM dbo.ViewOfPain v
WHERE v.ID = ID 
ORDER BY v.InputDate DESC

  

Let's see, looks like I'm just trying a simple SELECT from the view with a CASE statement, checking the ID against the ID, yeah, that looks fi-- O SHI

Notice the missing '@' sign before the ID in the where clause??! I did, after spending a few hours writing a table function that I turned out not to need. The problem wasn't with the view, but with this bit of code in the stored proc, it was doing the equivalent of a SELECT on the entire view plus a bit more overhead to assign a value to the @Fruit variable. I ran this statement by itself in query analyzer, and indeed, it took well over 1:30 to execute!

Below is the code as it should've been, which returns almost instantaneously.

SELECT TOP 1 @Fruit = 
        
  CASE 
      WHEN v.Operation IN ('APPLE', 'BANANA', 'GRAPE') THEN v.Operation
      ELSE NULL
  END

FROM dbo.ViewOfPain v
WHERE v.ID = @ID
ORDER BY v.InputDate DESC

I'd spent hours optimizing and then finally creating a new table function to replace a view that turned out not to be the culprit. If I'd spot-checked my syntax in the stored proc, it's likely I could've picked out this omission of the '@' much sooner, but I was so tired and far gone into troubleshooting that I was getting increasingly desperate. 

The moral of my story is, take a break, unhook yourself from the problem, and review it again later with a fresh mind.