Anyone who's talked with me about software development will probably quickly realize that I am a big fan of design patterns. There's a a couple of reasons for that, mainly ease of communicating system design among developers and using proven techniques to solve common problems.

But like most things, there is a dark side to design patterns, and Alex Miller pointed out the downsides of a few patterns recently on his blog. First, he attacks probably the most widely known design pattern: The Singleton. He lists out some very key points that make the design pattern potentially problematic, but the biggest downside he lists to me is that it hides dependencies. When you build one, you usually think of a Singleton in terms of only wanting one instance of a class, rather than from the other side - any part of your code can use that one instance, and since that instance is (usually) global in scope, you can quickly lose track of how and where it's being used. Fast forward in your project, and that class becomes a brittle part of your system. Because it's potentially used everywhere in the system, changing it can easily break parts of the software you weren't thinking about - which brings up another one of Alex's points - they're hard to test because you can't mock it easily.

His alternative? Create an interface, and a class that implements that interface. Then create one instance of the class at the top level of your system and use Dependency Injection so all of your code uses that same instance. Now your code isn't using a "global variable" and is less coupled to the class itself, meaning you can now mock it to test it, because your code is based on interfaces rather than implementations.

Then he goes after Template methods. His basic argument is that it's not clear what your intent is, nor is it clear how the program logic flows. And again, his solution is interfaces and Dependency Injection.

Bottom line: understand the patterns you're using and understand more than just the pattern's strengths. You also need to know the downside, so you can code defensively to try to limit the impact of those downsides.

Oh, and use Dependency Injection!

I was excited this morning when I got up. It was around 6:45 AM, and I knew the Zune update should be posted by then. And it was. So I downloaded it and installed it, including the updated firmware for the actual hardware. Overall, I'm impressed, but there are a few things that leave me wanting - specifically, something that was already there yesterday.

But first, what I like:

• The Zune software interface looks a whole lot cleaner and looks better. It's more intuitive to get around in it. I've heard it's no longer based on Windows Media Player, which I'm neither happy nor upset about. I use Windows Media Player for playing podcasts locally, and have been pretty happy with it, so I didn't have an issue with the fact that the Zune software was based on it in the first place.
• The Zune hardware interface is better. It seems snappier and just plain looks better.
• Wireless syncing. I love that I can sync my Zune wirelessly, although it looks like it'll only work on one network at a time. That's not a huge deal, as I'll set it up for my home network, but being able to sync wirelessly at work as well would have been nice.

I don't really use the marketplace, so I can't really comment on that part of it.

Anyway, on to what is bad about the update:

• No auto-playlists. I don't sync all of my music to my Zune, for a variety of reasons. Before, I had an auto playlist that monitored my podcast folder, and it picked up all of my podcasts. Then I could sync that playlist, and have all of my podcasts on my Zune automatically. I did the same thing with certain genres of music as well.
• Podcasting support is, well, not bad, but not the way I want it. I want to keep all of my RSS feeds in one place - Newsgator online, FeedDemon, etc. That means my podcasts are all downloaded through FeedStation. That doesn't sit well with how the Zune software wants to do things. Right now, I have 12 podcasts in my FeedStation queue, but in Zune-land, there's only 9. It doesn't recognize DotNetRocks or RunAs Radio, for example. It can find them, but it adds them under music, not podcasts. It also has podcasts that are already deleted in the list, and isn't removing it from the Zune.

Bottom line, I like the interface better, but I fear that getting my podcasts and new music onto the Zune is going to be more of a manual thing than it was even with the original Zune software. Hopefully, they'll push out an update that will include auto playlists - then I'll be happy again!

Tags: Zune | Podcasts

I've recently written about how Tourney Logic has switched all of it's email over to Google Apps. Well, one side effect of that is that our applications had to be updated to send our email through the Google servers rather than the email servers we were using.

I was actually able to do it with only one minor code change and a change to the web.config. First, the web.config mail settings section:

   1:  <system.net>

   2:     <mailSettings>

   3:        <smtp from="user@domain.com">

   4:           <network host="smtp.gmail.com" port="587" userName="user@domain.com" password="pwd" />

   5:        </smtp>

   6:     </mailSettings>

   7:  </system.net>

Obviously, substitute your own email address and password, but once you've done that, this configuration should work. One shortcoming I see with the configuration is that it doesn't allow us to specify the use of SSL, which Gmail requires. So that's the one code change:

   1:  System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient();

   2:  client.EnableSsl = bool.Parse(ConfigurationManager.AppSettings["MailSSL"]);

To shield ourselves from code changes in the future, we added an app setting to determine if we want SSL. That way, in the future, if we move back to a non-Gmail account to send mail from, we just change the mailSettings section, change MailSSL to be false, and we're good to go.

Just a note that I did try port 465 (another port supported by Gmail) to send mail initially, and got a timeout every time, so I switched to 587, and mail started going through just fine.

Tags: Gmail | System.Net.Mail | C#

Brian spent a lot of time this past week getting Pay It Square's new look and feel posted, and he announced that he launched it on Saturday.

I really like the new concept - it's very pleasing visually, and the homepage rotating image is a great idea. I know - it sounds cocky, but it wasn't our idea, so it's not really! I'm also very happy with the new logo:

Before, we just had a green square. Given that the site is a payment system, having the dollar sign in it is a pretty good design - again, not our idea, but we benefit from it!

Brian also revealed that he's set Pay It Square up on WidgetBox.com, so you can add a payment widget to your own page.

Tags: Pay It Square | WidgetBox

Another week, and another set of picks. I spent most of the week preparing for a presentation, so that's why it's later than usual. Anyway, here they are.

• Atlanta vs. Carolina (-4) (36 O/U)
• Philadelphia vs. Washington (-2.5) (38 O/U): I was a little surprised to see Washington as a favorite.
• Minnesota vs. Green Bay (-6) (40.5 O/U)
• Cleveland* vs. Pittsburgh (-10.5) (47.5 O/U)
• Denver vs. Kansas City (-3) (37.5 O/U)
• Buffalo (-3) vs. Miami (41 O/U)
• Jacksonville vs. Tennessee (-4) (35 O/U)
• St. Louis* vs. New Orleans (-13.5) (46 O/U): Is New Orleans back? Who are they really? The team from two years ago (and the start of this season), or the team from last year? I think they're closer to last year, but it took them too long to hit their stride this year. By the way, my first trade, where I got Westbrook, I gave up Brees. Since the trade, he's actually doing better the Westbrook.
• Cincinnati vs. Baltimore (-4) (44.5 O/U)
• Dallas (-1.5) vs. New York Giants (48.5 O/U)
• Chicago (-3.5) vs. Oakland (38.5 O/U)
• Detroit vs. Arizona (0) (44.5 O/U)
• Indianapolis (-3.5) vs. San Diego (44.5 O/U): I'd hate to San Diego right now. Your team is already bad enough, and now you have to play a motivated team coming off a big loss. Oh - and San Diego's situation isn't that good anyway.
• San Francisco vs. Seattle (-11) (39.5 O/U)

My "Lock Solid" picks this week are Green Bay (-260), Pittsburgh (-475), Indianapolis (-200), and Seattle (-500).

Check back next week for results.

Tags: NFL | Picks | Odds

This morning, I gave my presentation on continuous integration, and as promised, I'm posting my materials for anyone who wants them.

For those who were at the presentation, this is the contents of my C:\Build folder (the one that would be on the build server). I've removed all of the .svn folders, as well as the bin folders from the compiled code. I've left all of the tools' binaries in there, though.

Over the next week or so, I'm hoping to write up (with screen shots) what I did for the demo, so look for those coming soon, but for now, here's a few more links, including the ones on the last slide:

• CI Servers
• CruiseControl.NET
• CruiseControl
• Build Scripting Tools
• MSBuild
• NAnt
• Ant
• Unit Testing
• NUnit
• MbUnit
• JUnit
• xUnit
• MSTest (as close as I can get to a link to it)
• Code Analysis
• NCover
• Simian
• FxCop
• Source Monitor
• Documentation
• NDoc (Note that the version included is slightly different than the SourceForge version. I found a modified one that worked with .NET 2.0, but can't find the download link now)
• SandCastle
• Additional Resources
• Continuous Integration: The Cornerstone of a Great Shop
• Martin Fowler's Post on Continuous Integration
• Mike Swanson's Ambient Orb Configuration
• Lego Animation Agile Development Video

Note that not all of these tools are free. NCover requires a license, and Simian is only free for free or open source software.

For everyone who attended, thanks for allowing me to present on something I am passionate about, and hopefully there's something that will benefit you on your future projects.

Tags: Continuous Integration | CruiseControl.NET | NUnit | NAnt | NCover

And not only that, but I'll be presenting on Continuous Integration:

The next release is looming in the distance, and you’re responsible for integrating the changes for all of the developers on the team. Last time, it took all day just to get it to compile. There’s got to be a better way! In this day and age of Agile software development, release cycles are getting shorter and shorter. As the build cycle gets squished, it’s imperative that a team doesn’t waste days at a time creating a build. Using Continuous Integration, development teams can “feel the pulse” of their project and be sure that builds aren’t a major headache. In this session, we’ll look at how a team can use continuous integration to enable quicker and easier builds, garner faster end user feedback, perform automated testing, and make deployments faster. Then we’ll dig into some of the common tools used to make continuous integration possible, followed by a demonstration of creating a simple, extendable build process.

I wrote that description back in July, and then the actual presentation a couple of months after that. Luckily, the presentation follows the description fairly closely!

Since this is a brand new presentation, I did a "dry run" at NuSoft this past Monday, asking for feedback on anything that wasn't clear or didn't come across very well. I got a few tips, but for the most part, they thought it was good, so I feel pretty confident going into tomorrow.

I'll be posting the materials tomorrow or Friday, so if you're interested in what I did, feel free to take a look. And if you're going to be at the conference, leave a comment.

Well, now I'm off to run through the presentation one last time!

Tags: GLSEC | Continuous Integration

I'm a huge fan of HttpContext.Current.Items, and have been for a while, but I rarely see others using it. I have mixed feelings about that - am I off-base in using it and don't realize it, or did I stumble onto a gem that just isn't used as much as it could be?

I'm starting to lean towards the latter, especially after seeing this post by Mike Duncan about how he uses it. He's got a couple of great ideas that could be implemented fairly quickly. He lists out three main uses:

• Preparing common objects early so they're available to the page
• Making parameters and pages more testable.
• Populating dynamic user controls easier

I've primarily used it for the first option. For example, over at Tourneytopia, we store the current pool you're looking at in a context wrapper (so it's strongly-typed). It's used on just about every page / control, and we lazy load it - so while Mike mentions populating the context with an HttpModule, we only load it the first time it's actually accessed:

   1:  public Pool Pool

   2:  {

   3:      get

   4:      {

   5:          if (HttpContext.Current.Items[Constants.ContextItems.Pool] == null)

   6:          {

   7:              Pool pool = Pool.GetPool(this.PoolId);

   8:              if (pool == null)

   9:              {

  10:                  return null;

  11:              }

  12:              else

  13:              {

  14:                  HttpContext.Current.Items[Constants.ContextItems.Pool] = pool;

  15:              }

  16:          }

  17:          return (Pool)HttpContext.Current.Items[Constants.ContextItems.Pool];

  18:      }

  19:  }

That way if it's not used at all, it never gets loaded.

His other two suggestions are interesting as well. Being able to have an alternative way to populate typically "webby" data, such as query strings, is something that's always been difficult to figure out. By using a context wrapper that's based on an interface, you can inject your own implementation into it, so you can substitute a "windowish" implementation for unit testing.

I haven't found a situation where I'm adding a lot of dynamic user controls, but any time you can get rid of calls to FindControl(), it's a good day!

Before I get too much into my picks, I have to mention my fantasy team. There's rumors that Larry Johnson is on the shelf for the year. If that's the case, that'll be my third running back to hit IR this year - I had Ronnie Brown and Cadillac Williams as well. I still have Willis McGahee, who left his game with a concussion. That basically leaves me with Westbrook, who I traded for two weeks ago. It's amazing that I'm 6-3, considering the number of running backs I'm going through!

Not much to say on this week's picks. They were pretty even. 7-7 across the board.

I was, once again, 2-2 with my "Lock Solid" picks, losing $12.91. So much for last week's performance. I'm now down $22.18, but 25-11 overall.

By the way, I was curious as to what would have happened if, instead of putting the money on games every week, I put the money into an index fund. So far, for the season, there's been $3,900 in bets, and I've lost $276.50. By putting the weekly money into the Vanguard 500 Index (VFINX), I'd be down $87.90, and that assumes a $10 transaction fee for each transaction - 9 weeks worth. Ignoring the fees, it would actually be up $2.10. And yes, I realize that funds are a long term investment option, but it's still interesting to look at how betting compares to investing.

• Washington 23, New York Jets 20 (-4) (35.5 O/U) [P: $5.00, S: $10.00, O/U: $9.09, T: $24.09]
• Carolina 7, Tennessee 20 (-4) (35.5 O/U) [P: $4.76, S: $10.00, O/U: ($10.00), T: $4.76]
• Jacksonville 24, New Orleans 41 (-3) (40 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Arizona 10, Tampa Bay 17 (-3.5) (37.5 O/U) [P: $5.00, S: $10.00, O/U: ($10.00), T: $5.00]
• Denver 7, Detroit 44 (-2.5) (46 O/U) [P: $6.90, S: $10.00, O/U: ($10.00), T: $6.90]
• San Diego 17 (-7.5), Minnesota 35 (41 O/U) [P: ($10.00), S: ($10.00), O/U: $9.09, T: ($10.91)]
• San Francisco 16, Atlanta 20 (-3) (37 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Cincinnati 21 (-1.5), Buffalo 33 (43 O/U) [P: ($10.00), S: ($10.00), O/U: $9.09, T: ($10.91)]
• Green Bay 33, Kansas City 22 (-2) (37 O/U) [P: ($10.00), S: ($10.00), O/U: $9.09, T: ($10.91)]
• Seattle 30, Cleveland 33 (-1.5) (46.5 O/U) [P: ($10.00), S: ($10.00), O/U: ($10.00), T: ($30.00)]
• Houston 24, Oakland 17 (-3) (41.5 O/U) [P: $13.50, S: $10.00, O/U: $9.09, T: $32.59]
• New England 24 (-5), Indianapolis 20 (56.5 O/U) [P: ($10.00), S: $10.00, O/U: $9.09, T: $9.09]: This game reminded me a lot of the MSU vs. U of M game from the day before. In the college game, MSU was up by 10 with 7 minutes to go, and ended up losing by 4. Indy was up by 10 with 5 minutes to go, and lost by 4. Two unanswered touchdowns spelled doom for the home team in both cases.
• Dallas 38 (-3), Philadelphia 17 (46.5 O/U) [P: $5.26, S: $10.00, O/U: ($10.00), T: $5.26]
• Baltimore* 7, Pittsburgh 38 (-9) (36 O/U) [P: $2.33, S: ($10.00), O/U: $9.09, T: $1.42]: The hit by Hines Ward on Bart Scott was rough. He's been streaky this year, but he's an all around receiver. He routinely throws hits and blocks - the types of plays that make you loved by your teammates but don't make the stats sheet.

Results Summary

• Picks (this week): 7 - 7 (50.00%) - Winnings: ($27.25)
• Picks (season): 81 - 49 (62.31%) - Winnings: ($91.05)
• Spread (this week): 7 - 7 (50.00%) - Winnings: $0.00
• Spread (season): 56 - 65 (46.28%) - Winnings: ($90.00)
• Over/Under (this week): 7 - 7 (50.00%) - Winnings: ($6.36)
• Over/Under (season): 61 - 65 (48.41%) - Winnings: ($95.45)
• Total Weekly Winnings: ($33.62)
• Total Overall Winnings: ($276.50)

I'm already working on next week's picks, so those should be up shortly.

Tags: NFL | Picks | Odds

I ended up getting a Zune last week. They're pretty cheap right now since V2 is coming out soon. You can get it for under $100 if you look hard enough.

I've never had an iPod, so I can't really compare the two, but I've been pleasantly surprised by how well it works. I'm not thrilled with the synching software, but it's not horrible either. Maybe it's because I'm used to Windows Media Player. The interface is pretty much exactly the same, but with a few less features. There was one nice side effect of installing the Zune software is that the codec for .mov and .mp4 files is better than the one I've been using that's part of the K-Lite pack. Before, I could play the files, but not see how long the file actually is. Now, I can see how far into it I am, and can fast forward or rewind.

Anyway, I'm already looking around for what else I can use it for besides music, videos and pictures. I don't have 30 GBs of music - more like 4 or 5. I don't have videos that will fill up the rest of it either. I'd like to be able to use it as a hard drive, but the solutions I've seen thus far are hacks. Now, I'm not above using a hack, but this is too much even for me.

I'm also looking forward to the new features in V2, since they'll also be added to V1. Being able to wirelessly sync will be nice - I hate wires. Unfortunately, right now, all I have to charge the thing is a USB cable. I may have to pick up a dock.

And yes, in the picture, I was listening to the latest TWiT. The other item in the picture is a Bluetooth dongle that plugs into the stereo jack (Jabra A120s, $24.22) and allows me to listen via my Bluetooth headphones (Jabra BT620s, $41.89) - meaning I'm listening to my podcasts wirelessly. Nice! Yes, those are referral links, but they're items I use on a daily basis and I've been extremely happy with them and Amazon has the best price I've found.

Bottom line: I'm having fun with my new toy.

Tags: Zune | Podcasts | Bluetooth