I first saw AutoHotKey on Scott Hanselman's awesome tool list. As a side note, he's updated his list for 2007.

Anyway, I'd looked at AutoHotKey and it looked pretty cool, but I never really had a use for it, until I upgraded to Vista. I use SlickRun, and that's a great launcher tool, so I was all set. And on XP, I had a program that added global hot keys to Windows Media Player (something lacking from WMP in my opinion).

But then I upgraded to Vista - towards the end of last year - and the program I had wasn't Vista compatible. So for the past few months, whenever someone stopped by, I had to Alt-Tab to WMP and pause it with the mouse or the key combo it wanted. It's a pain when using Virtual PC, as you have to use your mouse to get out of the VPC window - you can't just Alt-Tab away from it.

I was able to deal with it because I got a Bluetooth headset that had pause/play functionality right on them, and that solved a lot of my issues. But I don't always use the headphones when listening to podcasts or watching videos, so I was still looking for something.

Enter AutoHotKey. With it, I was able to add play/pause functionality to a global hotkey - the same one I had before. For anyone who's interested, here's my script:

; Ctrl-Alt-1^!1::

SendInput, {Blind}{Media_Play_Pause}

return

; Ctrl
-Alt-4^!4::

SendInput, {Blind}{Media_Next}

return

; Ctrl
-Alt-3^!3::

SendInput, {Blind}{Media_Prev}

return

You can bind to the Window, Alt, Control and Shift keys - or any combo of them. The above uses the Ctrl-Alt combo - which is what I had before. Pretty simple and straight forward, and it accomplishes the task. I'm looking for other useful scripts - There are 1,000s of pre-built scripts for it, plus you can build your own, so there's lots of options. One I did find is to be able to minimize a program to the system tray, called Min2Tray, which works pretty good.

I'm back with my week two picks. The spreads are large this week. Half of the games have a spread of a touchdown or more, and three are double digits. Large spreads are accompanied by large money lines. This is when you start to wonder if it makes sense to pick a few underdogs in the hopes that one hits. For example, the KC vs. Chicago game has a money line of 600/-800. Remember, this means that if you pick the favorite, you have to bet $8.00 to win $1.00, but if you pick the underdog (and they win), you'd be winning $6.00 for your $1.00 bet. While the "sure bet" is to pick the Bears, the payoff of picking the Chiefs is big enough, it might be worth the risk.

Another thing to note. I used to adhere to a "rule of betting" I came up with - if the spread was more than 10 points, take the underdog. A few years ago, that rule held - if you were a dog by 10 points or more, you usually ended up covering. Last season, however, that rule didn't hold, and I gave up on it. Still, when you see a large spread like that, I'm more inclined to take the underdog. This isn't college football, where you can schedule cupcakes to pad your record (right, U of M?). This is the NFL, where parity rules. Yeah, you have the Texans, who make you think of parody more than parity, but even they were favorites last week (and covered!).

Anyway, on to my picks.

• Atlanta vs. Jacksonville* (-10) (34 O/U):
• Buffalo vs. Pittsburgh (-9.5) (37.5 O/U):
• New Orleans (-3) vs. Tampa Bay (42 O/U):
• Green Bay vs. New York Giants (0) (37.5 O/U):
• Houston vs. Carolina (-6.5) (38 O/U):
• San Francisco vs. St. Louis (-3) (44.5 O/U):
• Indianapolis (-7) vs. Tennessee (46.5 O/U):
• Cincinnati (-7) vs. Cleveland (42 O/U):
• Seattle (-3) vs. Arizona (44 O/U):
• Dallas (-3.5) vs. Miami (40 O/U):
• Minnesota vs. Detroit (-3) (42 O/U):
• Oakland vs. Denver (-9.5) (39 O/U):
• Kansas City* vs. Chicago (-11.5) (34.5 O/U):
• New York Jets* vs. Baltimore (-10) (33 O/U):
• San Diego vs. New England (-3.5) (47 O/U):
• Washington vs. Philadelphia (-7) (40 O/U):

My four "solid lock picks" this week would be Jacksonville (-600), Pittsburgh (-500), Carolina (-280) and Denver (-500). The numbers in parenthesis are the number lines I'd be getting.

I'll be back next week to review the results.

As is custom, after the games have completed, I'll review how I did, including how much money I would have won or lost had I bet $10.00 per bet. Remember, I'm making three bets per game - straight up winner, spread winner and over/under, so that's a total of $30.00 per game, or between $420 and $480 per week, depending on how many games are played each week. Last season, overall, I ended up almost $130 for the year. Considering it would have involved putting down over $8,000, it's not a great return, and I wouldn't recommend betting on every game every week. Personally, I don't actually bet on any games at all - I just enjoy seeing how good (or bad) I would do.

Anyway, as promised, here's an explanation of how lines play into payouts. When you look at an actual line, it looks something like this:

Lions +4 (-110), +150, 37.5 (-110)
Bears -4 (-110), -170, 37.5 (-110)

This means that the Bears are favorites to win by 4 and the total of the two scores is expected to be 37.5 points. Where things get complicated are the lines. In the above example, the Lions have a line of +150. This means that for every $1.00 bet, you get back $1.50 - so a $10.00 bet would return $25.00: your original $10.00 plus $15.00 in winnings. You get better than even money because the Lions aren't favored, and therefore aren't expected to win. For the Bears, a line of -170 means that you have to bet $1.70 to win $1.00. So a bet of $10.00 would get you $15.88 back - your original $10.00, plus $5.88 in winnings. The -110 for the spread and the over under are fairly common, and indicate that if you bet $10.00, you're only going to get $9.09 in winnings. This ensures that the sports books always get a take.

Which brings us to the question of how lines are set. Basically, sports books have been doing it a while, so they get it pretty close to start with. They initially set the lines, and they move throughout the week based on how people are betting. The goal is to keep the money the same on either side - so ideally they'd have as much money picking the Lions as they have picking the Bears. If more people are picking the Lions than the Bears, the line will move (as will the spread) to make it more attractive to people betting on the Bears and less attractive to people betting on the Lions.

So there's a decent explanation of how lines and spreads work. Next, I'll explain how my results look, and what they mean. Here's a sample result:

• Lions* 17, Bears 24 (-4) (37.5 O/U) [P: ($10.00), S: ($10.00), O/U: $9.09, T: ($10.91)]

My original pick is still there - the Lions are bold, meaning that's who I picked to cover the spread. The * indicates they'll still lose, and the bold O says I picked over. Since the result is red, it means I was wrong. The final score is listed (Bears won 24-17), and the green O/U indicates I was right. After the scores are the amount I would have won or lost on that particular game based on a $10.00 bet for the pick, the spread pick and the O/U. In the above result, I lost $10.00 on both the pick (P) and spread pick (S), and won $9.09 on the over/under (O/U), for a total loss (T) of $10.91.

So with that, here's my (dismal) results from week 1.

• New Orleans 10, Indianapolis 41 (-6) (52.5 O/U) [P: $3.85, S: $10.00, O/U: $9.09, T: $22.94]
• Philadelphia 13 (-3), Green Bay 16 (43.5 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Atlanta 3, Minnesota 24 (-3) (36 O/U) [P: $6.25, S: $10.00, O/U: $9.09, T: $25.34]
• Miami 13, Washington 16 (-3) (35 O/U) [P: $6.06, S: $0.00, O/U: ($10.00), T: ($3.94)]
• New England 38 (-6.5), New York Jets 14 (41 O/U) [P: $3.64, S: $10.00, O/U: ($10.00), T: $3.64]
• Tennessee* 13, Jacksonville 10 (-6.5) (37.5 O/U) [P: ($10.00), S: $10.00, O/U: $9.09, T: $9.09]
• Denver 15 (-3), Buffalo 14 (36.5 O/U) [P: $5.71, S: ($10.00), O/U: ($10.00), T: ($14.29)]
• Pittsburgh 34 (-4.5), Cleveland 7 (37 O/U) [P: $4.35, S: $10.00, O/U: ($10.00), T: $4.35]
• Carolina 27, St. Louis 13 (-1) (42.5 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Kansas City 3, Houston 20 (-3) (37.5 O/U) [P: ($10.00), S: ($10.00), O/U: $9.09, T: ($10.91)]
• Tampa Bay 6, Seattle 20 (-6) (41 O/U) [P: $3.64, S: $10.00, O/U: $9.09, T: $22.73]
• Chicago 3, San Diego 14 (-6) (42.5 O/U) [P: $3.64, S: $10.00, O/U: $9.09, T: $22.73]
• Detroit 36, Oakland 21 (-1.5) (39.5 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• New York Giants 35, Dallas 45 (-5.5) (44 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Baltimore 20, Cincinnati 27 (-2.5) (40.5 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Arizona 17, San Francisco 20 (-3) (45 O/U) [P: $5.26, S: $0.00, O/U: $9.09, T: $14.35]

Results Summary

• Picks (this week and overall): 9 - 7 (56.25%) - Winnings: ($27.61)
• Spread (this week and overall): 7 - 7 (50.00%) - Winnings: $0.00
• Over/Under (this week and overall): 7 - 9 (43.75%) - Winnings: ($26.36)
• Total Weekly and Overall Winnings: ($53.97)

And this right here is why 1.) you never bet on week one and 2.) you never bet all games. If I would have picked just a few games, I would have picked Minnesota over Atlanta, Pittsburgh over Cleveland, Seattle over Tampa Bay, and Kansas City over Houston. I'd never bet the O/U, and I'd probably bet straight up - no spread. That'd be 3-1 for the week, dropping $40, and winning $4.24. Not exactly a big number, but it's over a 10% return in a week!

Anyway, I'll be back later in the week with my picks for week 2.

Robert Prouse at Alteridem Consulting has a great post about how you can make debugging easier with attributes, which I've used extensively with a few nice to have modifications to a framework I maintain.

It definitely makes debugging an object simpler because you can pick key information to be displayed when you debug an object. For example, by default, the description for an object is it's namespace. If you have a list of the same type of object, then you get the same description for each one. By adding a DebuggerDisplay() attribute, you can give more info about that object - we use the primary key info, and it makes it much simpler to pick out which object in the list you need to look at.

The other attribute I like is the DebuggerStepThrough attribute - being able to tag that on simple gets can really make debugging go faster. Imagine a method that takes 5 parameters, and you're passing in all simple properties of an object that the getter just returns a private field. If you're stepping into that method in debug mode, that saves something like 15 "F11"'s. Granted, I wouldn't take the time to add this to most of the code I write - but for a framework, it's nice to add some of those types of features when lots of people will be using them.

I'm also toying with the idea of adding DebuggerNonUserCode attributes to the methods in our framework code. This would mean that in most cases, when you debugged with code on top of the framework, you wouldn't step into the framework - it would just run - like the way it does when you debug code that uses .NET framework classes. For those that don't know, Visual Studio 2005 has a "Just My Code" feature that honors the DebuggerNonUserCode attributes, but that can be turned off in the options so you can still step into the code.

Again, these are nice to know about, but for most code, this is probably overkill. It's nice to have in frameworks though.

I thought this issue had been beaten to death in the past year, but I figured I'd check out Kirill Osenkov's take on interfaces vs. abstract base classes, and, as is the norm, I took something away from it that I wasn't expecting to. I'd pretty much thought of them as essentially interchangeable, with the decision coming down to whether you had a default implementation or not.

Kirill points out that interfaces are better used to add or define features or abilities of a class. For example, IEnumerable doesn't define a list. It just adds the ability to enumerate over the items in a list. By contrast, a base class defines the derived class. If you have an Animal base class and Dog and Cat inherit from it, it's because Dogs and Cats ARE animals. If a Dog and Cat implement IPet, that's a feature of certain animals.

Don't get me wrong. I've been doing things this way. In our framework, we have the ISaveable interface - it's a feature of an Entity, so it's an interface. We have EntityBase, which is our base class for all Entities - because EntityBase defines all entities. It's just that I haven't seen it written out quite the way Kirill did - and it crystalized it for me.

And in case you only read part of Kirill's post, towards the bottom is interesting as well, where he warns against "burning the base class" - inheriting from a class just to add a small piece of functionality, while losing the ability to add any other type of functionality. It's good advice, although I think he takes it too far when he says an interface should only define one member. Sometimes, one member isn't enough to define an ability. I still think an interface should define one ability, but I think it's too limiting to say one member per ability.

I've resisted using Windows Live Writer for a while. Why did I resist? Because I couldn't get it to work with b2evolution, and without that, it was pretty much useless.

With the release of the Window Live unified installer, I decided to give it a try again. Lo and behold, beta 3 works with my blog. Still, I wasn't sure it was what I wanted to use - I'd already rolled my own posting tool, although lately, I've been working up a list of features that I wanted to add to it. It's getting long, and most of them are satisfied by Windows Live Writer's plug in system. And if one isn't, then I can add functionality through writing my own plug ins.

I also like that it can pull down my blog skin, so when I write posts, it actually looks like my blog. That's key, because when I post code snippets, I can ensure they fit in my width, and if not, adjust them accordingly. It's ability to save and track drafts is also nice, as I like to jot down ideas for blog posts when I think of them, and then come back later to finish the post off.

Anyway, if you're not using an offline blogging client because you can't find a good one, then Windows Live Writer might be for you. It works with most blogging platforms (any that support the MetaWeblog API), and it (in my opinion) makes blogging easier.

I'm working on some framework code tonight, and I'm struggling with one issue that I can't seem to find any information about. We lazy load a lot of properties for speed reasons, which works out great for us. The problem comes when you need to debug them. Here's a customer object from the Northwinds database while debugging in Visual Studio 2005:

All I've done so far is get it. The Orders property is lazy loaded and hasn't been accessed in code yet, but it shows a count of 12 - it gets loaded as a result of examining the customer object in the debugger.

Thus far, I haven't heard anyone complain about this, but the fact that you could now get two different behaviors from an object depending on whether you've debugging it or not isn't a good thing.

Any ideas of what to do about this? All of our lazy loaded properties have a private field behind them, so I could show the fields instead, but that doesn't sound like a clean solution to me.

Tags: Visual Studio, Debugging

I have to say, there's something wrong about this.

For those readers who are new in the past year, every fall, this blog shifts focus, and takes on a decidedly sports feel.?Every week until the Super Bowl, I'll be posting my picks for the weekend's games, and then following up with the results early the next week.

If you're curious, I make three different picks for every game each week: the outright winner, the winner against the spread (ATS), and whether the total score will be above or below the Over/Under (O/U). As an example, if I have a pick that looks like this:

• Lions*?vs. Bears (-4) (37.5 O/U)

Here's how that pick should be interpreted: The spread is -4, meaning that the Bears are expected to win by 4 points. The Over/Under is 37, meaning the combined score between the two teams is expected to be 37.5 points. Since the Lions are bold, I think they'll cover the spread. The * indicates I think that the Lions will still lose though. If there's no *, then I think my spread pick will also win the game. Since the O is bold in the O/U, I think the combined score will be more than the 37 points predicted.

I have a spreadsheet that I track all of this in, and it keeps track of the lines for me, as well as calculate how I'm doing once I enter the actual scores. I'll review how the lines relate to payouts - something that used to confuse me until I sat down and finally figured it out.

Anyway, on to this week's picks. I may periodically make a few comments about the games, but that'll depend on how much time I have!

• New Orleans vs. Indianapolis (-6) (52.5 O/U)
• Philadelphia (-3) vs. Green Bay (43.5 O/U)
• Atlanta vs. Minnesota (-3) (36 O/U): Vick, Vick, Vick. That's gotta suck for the Falcons.
• Miami vs. Washington (-3) (35 O/U)
• New England (-6.5) vs. New York Jets (41 O/U)
• Tennessee* vs. Jacksonville (-6.5) (37.5 O/U): I was kind of surprised to see them cut Leftwich.
• Denver (-3) vs. Buffalo (36.5 O/U)
• Pittsburgh (-4.5) vs. Cleveland (37 O/U)
• Carolina vs. St. Louis (-1) (42.5 O/U)
• Kansas City vs. Houston (-3) (37.5 O/U): It's not often that you see Houston as a favorite. Is K.C. that bad?
• Tampa Bay vs. Seattle (-6) (41 O/U)
• Chicago vs. San Diego (-6) (42.5 O/U): I wonder how many of those 42 points the oddsmakers thought San Diego would put up?
• Detroit vs. Oakland (-1.5) (39.5 O/U): Oakland as a favorite?
• New York Giants vs. Dallas (-5.5) (44 O/U)
• Baltimore vs. Cincinnati (-2.5) (40.5 O/U)
• Arizona vs. San Francisco (-3) (45 O/U): So let me get this straight. Arizona?and San Francisco on Monday night? Against each other? I thought the NFL knew what they were doing!

I'll be back next Tuesday with the results...

Technorati Tags: NFL | Picks

...this makes me laugh.