Saturday, September 11, 2010

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.

Thursday, September 9, 2010

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.






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.




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








Friday, July 16, 2010

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.

Wednesday, June 16, 2010

Long Live the Classic Start Menu!

At work, I have finally received a brand-spanking new Dell Latitude E6410 laptop, complete with Windows 7 Pro.

I'm certainly loving the speed so far. As you might expect, stuff that seemed to take ages with XP goes blazingly fast under 7.
 

But, what's this?? Where's my beloved CLASSIC START MENU???

Apparently, Microsoft believes that since time marches on, all Windows users shall march in cadence with it. Some fanboys, too, wonder why all us holdouts don't simply drop the crude old Classic start menu altogether.

Absurd!

While I'm certainly happy for those who've enjoyed the new start menu, I for one would much rather keep the venerable Classic menu. I'm accustomed to it, I'm comfortable with it, and frankly, I don't really see a real need to switch.

Classic
works for me.

Along those lines, I've found ClassicShell. The creators of this add-on compatible with Windows 7 allows users to once again have their Classic start menu available.

Please, don't get me wrong, I'm certainly all for innovation and efficiency. However, is it truly more efficient to force users to become accustomed to a new start menu, and eliminate one that a significant number of users have been comfortable with for years? 




Isn't it more innovative to allow users to maintain their own customizations and preferences, despite changes in the underlying operating system? Personally, I'd like to keep my grubby paws on the Classic start menu as long as I can, because frankly I don't care to explore the new start menu which Microsoft slaps upon Windows 7 users.

In my humble opinion
, Microsoft would do well to ensure that their underlying OS works like a charm, and leave users to enjoy the preferences that they have come to enjoy, nay, expect, from their products.