Q is for Heat

"Atlas Shrugged" - The Obligatory Review

2011-04-17T19:14:00.001-07:00

Shame on you, Paul Johansson.

Many of you saw my brief posting about Atlas Shrugged. And most of you knew how much I was looking forward to finally seeing my favorite book portrayed on the big screen. The previews looked fantastic. The casting looked great. I couldn't wait. Then, about halfway through, I realized I was watching the real train wreck unfolding right before my eyes.

No Passion

If I could sum up the movie in one word, it would be "dull." Most of the characters were flat. The plot was hurried, confusing, and downright nonsensical in places. The primary conflict of the first part of Atlas - the race to complete the John Galt line - lacked the sense of urgency that the book portrayed so well. In the movie, it looked like Dagny was completing the railroad on her own schedule, and that it was smooth sailing. Far from it! Her whole reason for breaking away from Taggart Transcontinental and forming the John Galt line - to complete the line without damage to TT - was depicted as an entrepreneur's indulgence, not as an answer to a crisis. When the first train finally ran, the audience was supposed to feel the triumph and exaltation of overcoming impossible odds. What I felt was more like, "So what?"

Ellis Wyatt's importance was not stressed enough. In the story, his oil company is what keeps the nation afloat. Without his oil, there would be no gasoline, and no cars on the road. This is not made clear. When the flat monotone Dagny (played by Taylor Schilling) yells "Noooooo!!!" at the end, it just looks stupid.

And speaking of Dagny, what the heck was that love scene about? Forget about the fact that she threw herself at Rearden, which is not how it happened in the book. I think Ned Flanders from The Simpsons could have written a steamier scene. It was completely emotionless and mechanical. It would have been far better to cut the scene entirely and let our imaginations do the rest.

A Jumbled Mess

Actually, they should have cut a lot more, rather than try to cram in as many details. The film was a jumble of non-sequiturs that confused the audience. It was almost as if the producers were saying, "Hey look! We've included this part! We're staying true to the book!"

The biggest problem I had with the movie was that John Galt showed up at the wrong times. In the book, he revealed himself to a person at a a critical time, when they realized that the world was against them. Although I could forgive the initial appearance to Midas Mulligan, and maybe even his later appearance to Dick McNamara, I had a big problem with his visit to Ellis Wyatt on the night of the John Galt Line's first run. That is absolutely the wrong time to show up. He was supposed to show up after they passed the legislation that penalized Colorado. A big miss.

When Rearden was introduced, he was portrayed as the president of Rearden Steel, but you had no idea that he owned his own ore company, coal company, or any of his other enterprises. Thus, the passage of the Equalization Of Opportunity Bill seems irrelevant, until they show Rearden selling off his businesses. I'm sure the audience was thinking, "Oh, he owned all that?"

Another example is when Dagny goes to visit Dr. Robert Stadtler at the State Science Institute to ask about their article condemning Rearden Metal, he tells her about his three students at the Patrick Henry University. And I mean, just like that, out of the blue. Why? Even Dagny didn't know why he was telling it ("Dr. Stadtler, I don't see what any of this has to do with Rearden Metal.") It did nothing to move the story, and would have been better saved for Part II.

And what's with the ending? Having John Galt show up and announce that he and his buddies have a secret location? Ellis Wyatt announcing to the world that he is on strike? Maybe Johansson realized near the end that his audience would be totally confused, so rather than fix the film, he would reveal the mystery. I guess Parts II and III aren't coming.

What They Did Right

I guess a review wouldn't be complete (or fair) without mentioning what was good about the movie. The most entertaining aspect about the movie was Graham Beckel's portrayal of Ellis Wyatt. Although physically he looked nothing like the character, his acting was spot-on. He was outspoken, confident, obnoxious - and fun!

The way they modernized the movie was clever. The plot starts on September 2, 2016, five years into the future - enough for a looter-driven society to take hold. The Dow Jones has fallen to 4,000, and is steadily decreasing. Gasoline is at $37 a gallon - a little too unbelievable, but it gives a nice explanation as to why rail travel has supplanted air travel. For starters, they modernized it, and it worked. Atlas Shrugged was published in 1957, when televisions were just becoming mainstream, and long before the age of cell phones and computers. The movie makes use of news reports to provide backstory, and cell phones to allow the characters to communicate across the continent.

I also liked Patrick Fischler's portrayal of Paul Larkin. He made the most of a secondary character, and it worked well.

All in all, if you are an Atlas geek like me, by all means, see it, but wait for the DVD. Watch it once, then bury it and forget about this embarrassment of a film.

How not to buy a condo

2010-08-11T09:59:00.000-07:00

I don't usually do this. I don't make it a point to dump my personal business online. It's nobody's business but my own, and most of us have bigger problems anyway. Besides, most of the time, my life is just not that interesting. Of course, I usually blog about programming, which is even less interesting, but you know what I mean. So bottom line -- if you don't care to hear about my personal trials and tribulations, you can safely skip the rest of this post.

Most of my friends and family know that I'm going through a divorce. I won't get into that, except to say two things: (1) it's been going on for a year and a half, and (2) it's what you call an "amicable" divorce. "Amicable" sounds like it means "friendly," but when it comes to divorces, it more closely means "boring." And, especially when there are kids involved, "boring" is the best you can hope for.

Anyway, my wife and I agreed that she would buy out my share of our house, and that I would move to another place in town, in the same school district. So I looked around, and found a great condo. How great? How about a complete finished basement with two extra rooms? How about a stone's throw from the town's largest park? How about close enough to my (former) house so that our son could easily bounce between the two places? I fell in love with this condo, which of course in business is a no-no. But suffice it to say, it was perfect. And of course, that's a sure sign that something is too good to be true.

I actually met my realtor during the showing of the condo. He was showing the place for someone else in his office. He's a great guy, a 40-something bachelor-for-life who wasn't pushy and who also showed me some other condos. But it kept coming back to this place. He also recommended my real estate attorney to me, another 40-something bachelor-for-life who -- get this -- lives in the same development. Too perfect, indeed.

Both my realtor and my attorney recommended a mortgage company called Gateway Funding. (Actually, another realtor also recommended them to me, but that's another, less interesting story.) So I went to Gateway and filled out the paperwork and gave them copies of my tax return and let them run my credit. I should mention that, and I say this with no hint of braggadocio, that my credit is damn near perfect. My wife and I scrimped and saved for years. We didn't go on extravagant trips, we rarely ate out, and we pretty much plowed all of our extra cash (when we had it) into reducing the principal of our house. And lo and behold, we actually managed to pay it off. Yep, we owned it free and clear. Which means it was really easy to execute the buyout.

So there I am, not a homeowner anymore, but sitting on a pile of cash. (Don't get me wrong -- I'm still living in my former house, I have plenty of time before I have to move out. Plus, it's an "amicable" divorce, remember? Nobody is going to kick anyone out.) You would think that a former homeowner, with near-perfect credit and a 40% down-payment, would be able to secure a mortgage. Yeah, I thought so, too -- right up until two days before the closing.

It started when the mortgage company said they had contacted my condo association, asking for the "deliquency rate;" i.e., the percentage of owners who are late paying their condo association fees. The number came in at 16%, which was a little high. In the condo mortgage business, that's a red flag. Note that 15% is not a red flag, but greater than 15% is. So they asked for a little more information, including proof of fidelilty bond insurance.

And just what is fidelity bond insurance? It's basically insurance that a company can take to protect itself from theft, etc. Gateway Funding -- or at least, the underwriter behind Gateway -- wanted to see it. And guess what? They didn't have it. So, two days before closing, after the moving trucks have been ordered (on both sides), the insurance obtained, and all that other good stuff, I was told that they couldn't give me the loan.

I did wind up calling the condo association and spoke with the manager. He told me that this was the first time that a mortgage company asked for proof of fidelity bond insurance. He also told me that, a few months ago, he recommended to the board that they get it, but it was voted down. I asked if I could show up at the board meeting and tell my story -- but he told me he would tell them the story. I also suggested he ask the board how it felt that their condos were unsellable. He laughed. They are definitely pursuing the bond insurance now.

What makes things worse was that apparently, the 16% deliquency rate wasn't really that accurate. Although association fees are due by the 1st, they aren't considered delinquent unless unpaid by the 15th. So the actual number was 7%. So the mortgage company told me, "good news. We can get you the loan."

But the next day, the story changed again. Apparently when the mortgage company told their underwriter about the discrepancy, the underwriter said, "well now you are changing the information. This is an even bigger red flag, so tell the association that they need all this additional documentation."

The mortgage company told me to wait a few weeks while the association was getting their fidelity bond insurance. I told them I was tired of being jerked around, and told them to go to hell.

So... the following day, my wife gave me the number of one of her friends, who works at a mortgage company. By the end of the day, I was preapproved at a different mortgage company. For a better rate, I should add. See? I told you it was amicable.

But what about the deal? Well, obviously, the closing is now moved for at least a month. You would think the sellers would be pissed -- and indeed they were. But they called me -- that's right, the sellers called me directly,which is also a no-no, but it was a sincere gesture. I had met them twice before, once during a showing , and a second time during a private inspection. They are nice people, and they wanted to know if I would be interested in moving in and renting the place from them.

Of course, I still don't want to cancel my moving truck, and for many reasons, I need to move out of my (former) house and into a place of my own. So as we speak, our lawyers are drafting up a rent and occupancy agreement. This takes the time pressure off, and with any luck, I'll be moving into my new place soon, even if the closing doesn't take place for another month.

And one last note: Gateway called me back and told me that, assuming the association got the fidelity bond insurance, they would still grant me the mortgage. Gee, where have I heard that before? They even told me they would lower my rate (which still wasn't as good as the other rate). What fun to tell them to go to hell a second time.

These loan conditions regarding the association were not in my contract -- at least, not that I could find. That's what annoyed me the most. That, and the fact that I didn't know about the problem until two days before closing. I am a little mad at the association, but most of my anger is at the mortgage company.

The moral of the story? If you're going to buy a condo, ask about the things they want to see in the association. And find out yourself, first.

The Secret to a Great Cartoon

2009-11-07T06:43:00.000-08:00

"Dad, why don't we have a panic room?"

When it comes to questions from kids, I consider myself well prepared. If they want to know why the sky is blue, I can give an age-appropriate description of Rayleigh scattering. If they want to know about the "birds and the bees," I'm ready for that talk too. Nothing is taboo; good, honest, unbiased information is what kids need.

But this question from Nicholas threw me. "Where did you hear about panic rooms?" I asked, wondering if the kids at his school were watching a Jodie Foster marathon and if I'd have to explain what exactly Hannibal Lecter was trying to smell in that one scene.

"It was on Phineas and Ferb. Candace said she was going down to the panic room for a while."

"Oh!" I said with relief. "Basically, it's because it's too expensive. We're saving for your college first. And frankly, our house will need a new roof before it needs a panic room." Truth is, I'd love having a panic room, but I would make mine look more like a finished game room, complete with TV, pool table, and fridge. (Wouldn't a fridge stocked with glucagon have come in handy during the movie!)

If you've never seen Phineas and Ferb, you are missing out on a great show. I've known and watched all the shows that Nicholas has been into, ever since Elmo and the Playhouse Disney days. I'm a fan of SpongeBob Squarepants (although I didn't see the latest special yet), I can quote episodes of Chowder, I love Penguins of Madagascar and Back at the Barnyard, and I can even identify a good number of Pokémon. So when Nicholas was getting bored with TV, I suggested to him what some of my coworkers suggested: switch over to the Disney channel (of all things!) and give Phineas and Ferb a try. We both love the show! I won't go into too many details about the show -- you can read about it anywhere on the web -- but believe me, you are in for a treat.

So I got to thinking of what makes a great cartoon. And when I mean great, I mean timeless. Every once in a while, I'll pop a Warner Brothers DVD in and watch "Baseball Bugs." ("Wham! A homer! Wham! Another homer!") Still great stuff, but why?

The obvious answer is, well it's because of all the adult humor. But it's more than that. True, you do need humor in a cartoon, as well as good strong characters. I think the main measure of a cartoon's staying power is how well it relates to the real world. If a cartoon is grounded in real-world references, it will appeal to adults as well as children and it will be talked about by everyone. Phineas and Ferb references a lot of cultural icons, like 80's hair bands ("Love Handel"), monster trucks, and, of course, panic rooms. The same thing can be said of SpongeBob Squarepants; one episode ("The Krusty Sponge") actually mocked SpongeBob merchandising itself. And you can't help but laugh at the American Idol parody "Do You Gots It?" found in an episode of Back at the Barnyard.

Contrast this with shows like Ben Ten. Oh it's a good show, don't get me wrong, but it has limited appeal. It just doesn't tie into anything in the real world. And I challenge you to look at Chaotic or Bakugon and pick out anything "real" about them. You'll hear very few adults yelling "Bakugon Brawl!" in the workplace, and those that do will get very strange looks.

But sing "Agent P!" in the office, and watch how many parents will sing back "Doofenshmirtz Evil Incorporated!" (Of course, you have to sing it the right way...)

Did 1996 music really suck that much?

2009-09-06T15:01:00.000-07:00

I don't have satellite radio. So whenever I drive to other cities, I have to use the seek button and look for good stations. Ok, it's a bit of a pain, but I do love it when I find a good station. And when I went to Baltimore last week, I found one of those "play whatever we want" stations. In this case, it was WQSR 102.7 -- or as they say it, 102.7 JACK FM.

It was Monday morning, around 9am. They had a segment where they would play 15 songs from a given year, and that day, they chose 1996. So I turned my personal wayback machine to 1996, and got myself back into that state of mind. It was the year that Lisa and I bought our house. I was working at Betz Laboratories, at my first "real" programming job. Cool! So what was playing? Here's what I heard:

"Missing" by Everything but the Girl (you know, "... like the deserts miss the rain")
"Change The World" by Eric Clapton
"It's All Coming Back To Me" by Celine Dion (all 7:36 of it).

Then it was time for a commercial.

Good God, I thought. Did all the music from 1996 suck that much? There had to be something good from that year. It was the year after Alanis Morissette released "Jagged Little Pill", so maybe one of those songs would be there, hopefully? And what about "I Love You Always Forever" by Donna Lewis? That was a cute little song, and I remember it was playing the night when Lisa and I drove to our new house. So even though we had almost arrived at the Baltimore Aquarium, I thought I'd give it a few more minutes, hoping that a "good" song from 1996 would be played after the commercial break.

It was "Macarena" by Los Del Rios. What's even sadder is that I like that song more than the first three!

So I made a note to check with the Internet. I said to the Internet: Hey Internet! What were the popular songs from 1996? And by using a clever little query, Google gave me this site. And I was right. The music from 1996 did suck, at least in my opinion. Go have a look!

Well, not all of it. Two songs from Jagged Little Pill did make the list: "Ironic" and "You Learn", which are two of the better songs (especially"You Learn.") "I Love You Always Forever" was there as well. And I could only find two other songs that didn't suck: "1979" by Smashing Pumpkins, and "Name" by the Goo Goo Dolls. Too bad "Name" was overplayed -- it became the "tired song" on the "tired radio."

Even Rush's album "Test for Echo" wasn't that great, although I love "Half the World."

2009-08-10T18:00:00.000-07:00

And now for something unexpected... coding! Since this is the first time that my blog is hooked to my FaceBook account, I feel I should give this warning: Geeky article ahead! Seriously, if you're not a programmer, you won't find this article very interesting.

In this case, I'm talking about SharePoint -- not just SharePoint, but a SharePoint publishing site that we recently deployed. I won't bore you with the details on how we settled on SharePoint. But I will share a little story about how I forgot the finer details of thread synchronization. I spend way too much time on nontechnical tasks, but that's another article.

Here's a quick overview of our publishing site. Think of it as a knowledge base. Each article gets its own page (e.g., /Pages/Abc.aspx). Each article also gets a folder with the same name (/Documents/Abc). On the page, we have a web part that displays a list of the documents in the folder, as well as some custom properties. So far, so good. For performance reasons, once the list of documents is read, the web part caches it inside the HttpRuntime cache. (The cache gets invalidated if a new document is published, and once each night during the app pool recycle.)

To further increase performance, I intended to use a lock so that if 50 users request a page, the web part would only build the list once, and the other 49 users would simply wait for the list. Simple locking scheme, eh? I thought so. Remember, I said it's what I intended to do. What follows is a reasonable representation of my code. Here I show a DataSet used as a cached object, but in reality I used a custom data structure. Plus, I'm leaving a lot out. Anyway, here's the first pass:


private static object _lockObj = new object;

...


DataSet ds = HttpRuntime.Cache.Get(key) as DataSet;
if ( ds == null )
{
  lock ( _lockObj )
  {
    ds = HttpRuntime.Cache.Get(key) as List;
    if ( ds == null )
    {
      try
      {
        ds = FetchDataSet(...);
        HttpRuntime.Cache.Insert(key, ds);
      }
      catch ( Exception e )
      {
        LogException(e);
      }
    }
  }
}

Great, except for one problem. See that static object used as a lock? Well it can't be a local object, that's for sure -- each page request would get a brand new local object, which would be useless for locking purposes. But the problem with a static object is that it is common for the entire application. Which means, that if 10 users are querying 10 different pages, each page would encounter the same lock and wait for the previous one to finish! As you can imagine, performance was dreadful. Even worse, our performance tests did not account for this use case -- which was, in some ways, a more serious flaw than the code itself.

What I wanted was page-level locking. So what to do? Well, I remembered an article I had read waaay back in MSJ -- but I can't seem to find it (and I've looked!) The article was written back in the days of C++ and Win32 critical sections. It explained a technique that let you have thousands of objects appear to each have its own private critical section. The idea was simple -- create a fixed pool of critical sections, store them in an array, then have each object always use a dedicated critical section. The odds that two objects would use the same critical section were low. A well-written, reliable hash function would do the trick.

So I adopted this technique to our web part. The code remained relatively unchanged, except for the part that determined which object to use as a lock. In this case, I took the key and used its hash code to determine which lock was used.


private const int LOCK_POOL_SIZE = 50; 
private static object[] _lockPool = new object[LOCK_POOL_SIZE]; 
static Class1() 
{ 
  for (int i = 0; i < LOCK_POOL_SIZE; i++) 
    _lockPool[i] = new object(); 
} 

...

DataSet ds = HttpRuntime.Cache.Get(key) as DataSet;
if ( ds == null )
{
  int lockIdx = Math.Abs(key.GetHashCode()) % LOCK_POOL_SIZE;
  object lockObj = _lockPool[lockIdx]; 
  lock ( lockObj )
  {
    ds = HttpRuntime.Cache.Get(key) as List;
    if ( ds == null )
    {
      try
      {
        ds = FetchDataSet(...);
        HttpRuntime.Cache.Insert(key, ds);
      }
      catch ( Exception e )
      {
        LogException(e);
      }
    }
  }
}

This worked well enough -- except for one further problem. What if, for some reason, the code that loaded the data failed? What if FetchDataSet throws an exception? Well, the cache would never be filled -- which would result in many requests waiting, waiting for a cache that would never fill, essentially backing up the requests until ASP.NET started queueing requests.

My solution to that was to insert a "poison" object into the cache -- but for only a few minutes. In this case, the "poison" object was an empty DataSet, but you could put in whatever you need. This would alleviate the lock condition, allow the code to display an error, but also allow the problem to be addressed and the code to self-correct. (Sidebar: When dealing with SharePoint, 99% of the time, these "problems" are permissioning setup problems. And yes, we developer have had to solve a fair number of these.)


private const int LOCK_POOL_SIZE = 50; 
private static object[] _lockPool = new object[LOCK_POOL_SIZE]; 
static Class1() 
{ 
  for (int i = 0; i < LOCK_POOL_SIZE; i++) 
    _lockPool[i] = new object(); 
} 

...

DataSet ds = HttpRuntime.Cache.Get(key) as DataSet;
if ( ds == null )
{
  int lockIdx = Math.Abs(key.GetHashCode()) % LOCK_POOL_SIZE;
  object lockObj = _lockPool[lockIdx]; 
  lock ( lockObj )
  {
    ds = HttpRuntime.Cache.Get(key) as List;
    if ( ds == null )
    {
      try
      {
        ds = FetchDataSet(...);
        HttpRuntime.Cache.Insert(key, ds);
      }
      catch ( Exception e )
      {
        LogException(e);
        HttpRuntime.Cache.Insert(key, new DataSet(), null, DateTime.UtcNow.AddSeconds(120), System.Web.Caching.Cache.NoSlidingExpiration);

      }
    }
  }
}

And there you have it. Note that you can change the lock pool size to fit your own needs.

She's coming back!

2009-01-27T19:32:00.000-08:00

Yep, she's back.

I'm talking about Asli Bilgin, of course. A few years ago, she (along with some other Microsofties) came to Merrill Lynch and talked about .NET 3.5. Well now she's back and she's going to be talking about .NET 4.0. Can you tell I'm excited! What's not to love... a cute babe talking about technology.

This time, however, I won't be asking about the Gaming Engine. For the moment, I've lost the passion for the Gaming Engine. Hopefully, it will return someday.

But for now, I'll just enjoy the talk from Ms. Bilgin.

Lazer Tag is Tres Cool!

2008-12-27T08:17:00.000-08:00

I have a love-hate relationship with Hasbro. For a while there, it seemed the company had lost its creative edge, and only made lame toys or re-hashed versions of older toys. Being a fan of the old Worlds Of Wonder Lazer Tag from the late 80's, I was reasonably suspicious of the new Lazer Tag game by Hasbro. But oh was I pleasantly surprised... this new version is a cool product, and in my opinion is way superior to the WOW version.

Nicholas got it for Christmas. Naturally, guess who he's playing it with?

This is what you get in the box (plus instructions):

You can see that the guns (or "taggers", as they are called) have the target mounted right on the guns themselves (the red dome at the top). The guns also come with the ability to add attachments. The big attachment shown above is the "Shot Blast" attachment, which adds grenade-throwing ability. (More on this in a sec.) Instead of the Shot Blast, you can attach the video game module (that blue thing on the right) instead. Alas, the video game module only works with old-fashioned CRT televisions, and you need a video attachment as well. The other little attachment that goes on top of the gun is a scope, which displays a little green dot to help you aim better. Each gun takes six AA batteries.

The first thing you notice is the array of switches all over the gun. Here are the various switches:

The power switch, which also can select solo mode (free-for-all), Team 1, or Team 2. During team play you cannot hit your own team members.
A 10-or-25 strength setting (i.e., hit points)
An indoor/outdoor switch (presumably affects accuracy)
A small lever which releases the ammo clip (not all the way). The lever is present on both sides, to accommodate right- or left-handed individuals.
Two triggers; one for firing and one to activate the shields. Yes, shields.

There are also two gauges on the rear of the pistol. The one on the left shows your strength (i.e., health or hit points), the one on the right displays your ammo:

It's one thing when you hold one of these pistols in your hand. But when you fire it -- wow! Inside the gun there is a recoil mechanism, which gives a satisfying kick to your hand and an even more satisfying clicking sound. It actually feels like you fired a round. And the speed! You can easily shoot 3 rounds a second. (The old WOW pistols could barely shoot once per second.) If you have the Shot Blast attachment on, then you have grenade-launcher ability. Simply pump the gun, then fire, and you essentially do a triple-shot. The gun also rumbles when you are hit.

One big difference is the reload feature. After six shots, you have to reload. But Hasbro took this potentially annoying feature and made it fun. You hit the lever with your thumb, which extends the "clip" out about half an inch (it also lights up). A quick, satisfying slap with your free hand, and you're good to go. The grenade launcher does not use any ammo.

Another difference is the shield. During a game, you get 10 seconds of health during a 10-strength game, 25 seconds during a 25-strength game.

I've been playing this with Nicholas, and I cannot wait to introduce this to my friends.

I'm still lukewarm on Hasbro's online presence. If you go to LazerTag.com, it simply redirects to Hasbro's site. According to the directions, the site would list the products that Lazer Tag was compatible with. Yeah, at the bottom of the "Game Tips" section, I found a paragraph that states the game is compatible with Lazer Tag Team Ops, an earlier Hasbro product. The rest of the site has a few interesting things (like various ideas of games you can play).

Ok, but is the game compatible with the old WOW Lazer Tag? No, it isn't -- I tried. That would have been nice. But after playing with these pistols, I don't even want to touch my old Lazer Tag. Seriously. It's that good.

Gotta get in the picks

2008-12-04T18:59:00.001-08:00

Here's what my program picked for week 14. And I swear it didn't know that San Diego is currently killing Oakland:

OAK at  SD:  SD
JAC at CHI:  CHI
CLE at TEN:  TEN
PHI at NYG:  NYG
MIN at DET:  MIN
HOU at  GB:  GB
ATL at  NO:  NO
CIN at IND:  IND
MIA at BUF:  BUF
 NE at SEA:  NE
 KC at DEN:  DEN
NYJ at  SF:  NYJ
STL at ARI:  ARI
DAL at PIT:  PIT
WAS at BAL:  BAL
 TB at CAR:  CAR

Still More Football

2008-11-27T07:09:00.001-08:00

Happy Thanksgiving!

Just for the record... my program's Week 13 Picks:

TEN at DET:  TEN
SEA at DAL:  DAL
ARI at PHI:  ARI
 NO at  TB:  NO
IND at CLE:  IND
 SF at BUF:  BUF
BAL at CIN:  BAL
MIA at STL:  MIA
NYG at WAS:  NYG
CAR at  GB:  CAR
ATL at  SD:  ATL
PIT at  NE:  PIT
 KC at OAK:  KC
DEN at NYJ:  DEN
CHI at MIN:  CHI
JAC at HOU:  JAC

More football

2008-11-20T15:18:00.000-08:00

Because the Thursday night game is only hours away, I present my program's Week 12 picks:

CIN at PIT:  PIT
HOU at CLE:  CLE
 SF at DAL:  DAL
BUF at  KC:  BUF
MIN at JAC:  MIN
 TB at DET:  TB
CHI at STL:  CHI
NYJ at TEN:  TEN
PHI at BAL:  BAL
 NE at MIA:  MIA
OAK at DEN:  DEN
NYG at ARI:  NYG
WAS at SEA:  WAS
CAR at ATL:  CAR
IND at  SD:  IND
 GB at  NO:  NO

In my opinion, there's no real surprises this week (maybe Miami taking down New England). And, unlike last week, this week actually has a few visiting teams winning (like the Giants...).

Last week was crazy. I don't have time to tally right this second but I think it got six wrong. And no, it would not have predicted a tie (but it did pick Cincinnati). I do want to play with this algorithm. Instead of relying solely on team record, I'd like to try points-for and points-against. Or maybe even touchdowns scored/field goals scored. I don't know. The boring part is collecting the data; to my knowledge, there are no free XML feeds out there (and RSS would involve parsing). But once the data is there I am free to play!

Week 11 Picks

2008-11-11T18:10:00.001-08:00

In my last post I described a quick little program that made NFL predictions based only on team record, and that gave the home team a slight edge. I didn't want to tweak the algorithm that much, but I decreased the maximum winning probability from 0.90 to 0.85. So, without further ado, here are the program's predictions for week 11:


NYJ at  NE:  NE
DEN at ATL:  ATL
DET at CAR:  CAR
MIN at  TB:  TB
BAL at NYG:  NYG
OAK at MIA:  MIA
 NO at  KC:  KC
PHI at CIN:  CIN
CHI at  GB:  GB
HOU at IND:  IND
STL at  SF:  SF
ARI at SEA:  SEA
TEN at JAC:  JAC
 SD at PIT:  PIT
DAL at WAS:  WAS
CLE at BUF:  BUF

There's some surprises there (Cincinnati over the Eagles?!?!) but that's what I love about it.

Football and so-called experts

2008-11-09T08:01:00.000-08:00

I'm a fan of football. Although, I'm almost ashamed to admit it, it's mostly due to peer pressure back in high school. Back then, all the guys would talk about the sports teams, and I really could not follow what they were talking about. I wouldn't even know it was Superbowl Sunday.

But that changed one year. It was 1985, and I made up my mind that I would actually sit and watch football games. It seemed like a modest investment of time; a few hours on a Sunday afternoon. So I followed the New York Giants, and I listened to John Madden and Pat Summerall, who, at the time, did a good job of explaining the game. Sure enough, after a few weeks, I got the hang of it. And the Giants did okay that year (10-6), so it was fun to watch. I was hooked. (That was also the year that the Chicago Bears beat the New England Patriots -- remember the Superbowl Shuffle?) I played a little fantasy football during my years at Procter & Gamble, but that just ruined the game for me. Sure, you get to be a real expert on the league, but you can't enjoy a game the way it was meant to be enjoyed. I prefer to remain a purist.

I like football and I like talking about it. But here's what I don't get: sports analysts. I'm not talking about reporters; they have a job and they do it. But analysts? Why? What possible value do sports analysts add? They get paid to write their opinions in the newspaper, about sports. But why? Who really cares what they think? It's not like coaches are going to start coaching differently based on what the analysts say. It's not like business analysts; at least they write about stuff that actually affects people, like investments. (Although business analysts are wrong just as often as their sports-spewing brethern.) And don't get me started on talk radio/TV shows. That's just uselessness magnified.

What makes me laugh are the so-called experts and their "picks." For instance, check out http://sports.espn.go.com/nfl/features/talent. (Yeah, the URL really contains the word "talent" -- oh the irony.) Ok, so these guys pick their winners. Nobody does really great; as of today, Mortensen seems to be doing the best at 87-44, which means he is correct about two-thirds of the time. What caught my eye was something called AccuScore, which supposedly simulates the game play-by-play to arrive at a prediction. AccuScore has the exact same record as Mortensen (87-44), which means it beats all the other experts. (And forget about the crowd-sourced Pigskin Pick-'em, where everyone else picks the winners. It's doing the worst, which explains how sports bookies stay in business.)

But then I thought it would be fun to write my own program to "predict" the outcomes of games. Why not? So, I created a few XML files that contained the matchups and the previous team records (I couldn't find this info in XML format anywhere for free, so I keyed it in myself). My algorithm was simple: I computed the "odds" that the home team would win, generated a (pseudo)random number, and compared it against the probability. The probability of a home team victory is simply the weighted average of the home team's winning percentage and the visiting team's losing percentage, plus 0.1 for a home-field advantage, but never greater than 0.9. Now, I couldn't figure the Thursday night game, but here's what the program generated for this week's games:


 NO at ATL:  NO
TEN at CHI:  TEN
JAC at DET:  JAC
BAL at HOU:  BAL
SEA at MIA:  MIA
 GB at MIN:  GB
BUF at  NE:  BUF
STL at NYJ:  NYJ
CAR at OAK:  CAR
IND at PIT:  PIT
 KC at  SD:  SD
NYG at PHI:  NYG
 SF at ARI:  ARI

I'm curious to see how it stacks up against the "experts." None of picks exactly match what the "experts" say, so I'm actually optimistic.

About Dr. Knox

2008-09-29T20:00:00.001-07:00

njit_brochure_1990
Originally uploaded by JamesQMurphy

I just learned yesterday that Dr. Dana E. Knox passed away. Dr. Knox was one of my favorite professors at NJIT. He was one of the youngest professors I had, which meant he could relate to us students. He was only 53.

Dr. Knox taught Thermodynamics. That's right, thermo -- where the Q is for heat. (Yep, it was after his class where I got the "Q" in JamesQMurphy.) This cover is the NJIT Brochure around 1990, and on it, you can see our thermo class. It was the first nice day of spring in 1989. We asked Dr. Knox if we could have class outside, and he said, "Sure, why not!" The next thing you know, we were outside, reviewing an exam I think. A passing photographer snapped a picture, and it was used on the brochure the following year.

You can see Dr. Knox on the cover. I'm the one in the pink shirt (hey, it was 1989). The friend who gave me the Q? Right behind me, in the blue shirt.

He was cool. He'll be missed, but never forgotten.

I am Ted

2008-09-23T19:30:00.001-07:00

Yes I'm back, and I've got rants. Lots of rants. Hey, I'm still working at Merrill Lynch, and ever since the takeover by Bank of America, the workplace has become a fertile ground of rant-worthy material. But before I jump into those, I thought I'd start with a happy little personal observation.

You see, I am Ted. Ted who? Why, Ted Forth, of course. Ted Forth from the fabled comic Sally Forth.

I've been a fan of the strip for years, but over the past few years, I've noticed a lot of similarities between Ted, the father figure in the strip, and myself. Ted is a kid at heart. He often shares the same attitudes as their 10-year-old daughter Hillary. In fact, the two of them are often seen playing together, and ganging up on Sally. Ted is quick to pull out a quote from the 80's (such as "Kneel before Zod", while playing Monopoly). When Ted was laid off from his job last year, he was seen driving home, windows rolled down, singing along to "I am Superman" by R.E.M.

I didn't think it could get more eerie. Last week, I was talking with my son (now 9!) about science fiction movies, and for some reason, I thought about The Last Starfighter. I described it to him, and promised that if it ever came on, we would watch it together.

The very next morning, I saw this Sally Forth strip in the paper:

I immediately recognized the quote, but the following day's strip explained it for those who didn't:

Eerie indeed, but proof-positive that I am Ted. (I also sneak a Pop-Tart from the vending machine on occasion.)

By the way, the strip has now taken a very interesting turn. Ted has been at his new job for five months, and has yet to make a single friend. Sally has encouraged him to try and make friends, but his clumsy attempts (by attempting to talk sports) have backfired. Suddenly, in walks Aria, the woman quoting The Last Starfighter. Finally, Ted has found a kindred spirit -- and it's a woman!

At this point, he has not yet told Sally of his new friend. I'm dying to see Sally's reaction. Ted would never cheat -- he is too innocent to do so -- but it will be great to see where the strip goes. Stay tuned!

Sanibel Trip -- and some useful stuff

2008-04-18T14:13:00.000-07:00

Ok, so three months without a post might be considered an abandoned blog. But in my defense, I find that if I'm not blogging, it means I'm doing. And I have been doing stuff, but before I bore you to tears with that stuff, let me bore you with our trip to Sanibel, Florida. Here's some useful tips just in case you've stumbled upon this blog and just happen to be planning a trip to Sanibel (or Captiva).

For those of you who don't know (or don't use Wikipedia), Sanibel Island is an island just off the west coast of Florida, near Fort Meyers. And I mean just off -- you drive over a causeway to get to it. Captiva Island used to be a separate island, but thanks to a major storm filling in the gap, the two are now connected. Sanibel has got everything a normal town would have, except traffic lights. And let me tell you, a couple of traffic lights would serve this town some good. If you're like me, and you're used to driving in New Jersey, then driving in Sanibel is maddening, because they drive slowly. Don't speed -- you'll get a ticket. I suppose that's a good thing -- there's plently of wildlife on the island, and the last thing you want to do is harm some poor unsuspecting creature. But it takes getting used to. And nobody there understands the concept of a four-way stop -- which is why some traffic lights would be helpful.

Speaking of wildlife, there's the J.N. "Ding" Darling Wildlife Refuge. If you like birds, or even if you like a nice bike ride, then plan to spend half a day here. Yes, you can drive through if you're in a rush like us (or if you're just lazy), but you'll miss a lot. It's about 4 miles of path, followed by a four-mile trek back along Sanibel-Captiva road back to the education center. You'll see birds, but you have to look and listen for them. And it's a lot easier to do that from a bike.

The beaches in Sanibel are not nice and sandy. They are littered with shells. Which, if you like to look for shells, is a great thing. Hey, some people take it so seriously that they call it "shelling." Really, as in, "Let's go shelling." It's not like it's a sport. Oh well. One thing that surprised me was just how calm the Gulf of Mexico is. There are no waves, and there is no "roar of the ocean." Good things if you want to take little ones to the beach.

Ok, so what about food and nightlife. First, let me say, that if you're looking for a bar-hopping scene with hundreds of twenty-somethings, then turn around, head back over the causeway, make a right at Route 835, and head to Ft. Meyer's Beach. Our friends took us there on Saturday night, and it looked like a lot of fun. But if you want to stay on the island, Sanibel and Captiva are chock-full of great restaurants. Most of the restaurants are on the main drag in Sanibel -- Periwinkle Drive. If you go to Sanibel, get your hands on the dining guide -- they have the menu from almost every restaurant printed in this guide. Our hotel had it, and I'm sure most other hotels have it as well. Just look for something that suits your style, and you're golden. Note that prices are a little high here, but that's to be expected, since it is a tourism-based economy.

Here's the places we visited, in the order we visited them. We didn't take our son, but I'll mention which places looked kid-friendly.

Mucky Duck Tavern. This place is way out on Captiva Island. On Wednesday night, we got there at 5:30, hoping to beat the crowd (they open at 5:00). We got the last parking space available and had to wait 45 minutes -- and one of the bartenders said it was a slow day! But it's worth it. The best part about waiting is that you wait right by the beach (not quite on the beach -- but near it), and you can have a drink (or 3) while you wait, listening to some guy with an electronic keyboard sing "Sweet Caroline" and such. The kids will amuse themselves, and there's plenty of other kids to run around with (yes, running is okay, you're right by the beach after all). Casual atmosphere -- we were wearing jeans because it was still a little chilly, but most people wear shorts and sandals. Once inside, both Lisa and I had fried grouper sandwiches with fries -- awesome. You can opt for more dinner-like food if you want. Plenty of kid-friendly food as well. It'll run you about $25 a plate plus drinks.
Gramma Dot's Saloon. On Thursday, we decided to go here for a drink before dinner. Ok, finding this place is fun -- you go down Periwinkle drive and turn left at North Yachtsman way. You think you're entering a private driveway, but you are really entering the marina. Gramma Dot's is a restaurant with a bar, but it's still kid-friendly. I'm told they also have great breakfasts. Lisa and I wanted to sit outside and watch the boats, so we couldn't get a drink at the bar itself, but rather, at the attached convenience/yachting store. So yeah, we walked right past the yacht supplies and grabbed a few cans of Heinekin, then sat out and watched the pelicans. We even saw a few dolphins swim by.
Lazy Flamingo. There are two Lazy Flamingo restaurants -- we went to the newer on, in Sanibel. Much more kid-friendly and very casual. Not quite as good as other restaurants, but it's still a good time. Maybe $20 a plate plus drinks. Kinda reminds me of a Joe's Crab Shack.
The Jacaranda. After we scarfed down our food, it was just after six o'clock, so we headed over to The Jacaranda to catch the last bit of happy hour. Now this place was not so casual -- everyone there still had shorts, but the men were wearing shirts with collars. Don't bring your kids here unless they can sit still. Still, it looked like a nice place. The bar area -- oh excuse me, it's a lounge, not a bar -- is called "The Jac", and wasn't so bad. There was a band there playing classic rock, and they were okay. Mostly couples in their fifties. Hey, if that's your scene...
Pinochio's Ice Cream. We wanted some ice cream, so we skipped the Dairy Queen and drove over to Pinochio's. Smart move! It's a little place in a shopping plaza, but it's good. Real good. It closes at 9:00, so avoid the last-minute stampede.
Island Cow. On Friday, after our cruise (see below), we headed to Island Cow for lunch. We got there at 12:50 and had a 30-minute wait. That should tell you how good the food was -- and it was good indeed. Kid-friendly, real casual, and lunch cost around $12-$15 a plate. This place has breakfast and dinner as well, and it looks like a great place to go. Lisa and I both had fajita salads that were really good.
The Green Flash. Nice, pricey, and formal. Don't bring your kids here, unless they can sit still. You can still wear shorts and sandals, but wear a nice shirt. The food was good. About $30 a plate, unless you're ordering the $50 lobster tail. Oh, and if you do go, make sure you use the restroom -- that's all I'm saying. (One nit about The Green Flash: It's named after the atmospheric phenomenon of the same name -- you can read about it here -- but oddly enough, the restaurant is not situated on the Gulf. That's right -- you can't actually observe the real "green flash" here, despite the little handouts they give you.)

Bicycles: If you can, bicycling is definitely the way to go. As I mentioned, the traffic drives slowly, so you can actually make decent time on a bike. Our inn had some loaner bikes that fit the bill, but if you want something decent, or more exotic like a bicycle-built-for-two, then there are some rental places on the island (everyone seemed to rent from Billy's Bikes). We rode from our hotel over to the lighthouse area, just because we were in the mood. There's nothing special there -- the lighthouse itself is ugly -- but it was a nice ride.

We went on board the Stars & Stripes and cruised around the northern part of the island. It was the best fifteen bucks (each) that we spent. You get a 90-minute cruise, and the dolphins will jump and play in the boat's wake! The cruise takes off right outside Gramma Dot's (see above). If you have a boating license, you can rent your own 20-foot boat as well.

That's Sanibel. Not exactly a romantic getaway, but still a nice place to visit.

StarCraft: The Board Game

2008-01-20T09:29:00.000-08:00

A long time ago, I extolled the virtues of perhaps the most perfect video game ever created, StarCraft. Well when Fantasy Flight Games put out StarCraft: The Board Game, I just had to have it.

What's In The Box?

Overall, the game is beautifully manufactured. Most of the game elements are on cardboard punchouts. The cardboard is heavy and durable. The elements are double-sided, as well -- and line up perfectly. There are six total factions to play: Two Terran factions (Acturus Mengsk, Jim Raynor), two Protoss factions (Tassadar, Aldaris), and two Zerg factions (The Overmind, Queen of Blades -- not sure why they didn't go with the name "Kerrigan"). Each player gets their own deck of combat cards, a technology deck to enhance their combat deck, a sheet to track upgrades and resources, and a quick-reference cheat sheet. Each player also gets figures -- I'll get to those in a second. Here is a shot of the game contents, minus the figures:

The Figures

Each player has several types of units. For each race, there are three of each type. (Note that Terrans have nine types; the other races only have eight.)

Terran Units. Back row (from left to right): Goliath, Science Vessel, Wraith, Battlecruiser. Front row: Marine, Firebat, Ghost, Vulture, Siege Tank. Note that the Terrans get nine types of units, whereas the other races get eight types.

Zerg Units. Back row: Scourge, Queen, Ultralisk, Guardian, Mutalisk. Front row: Hydralisk, Zergling, Defiler.

Protoss Units. Back row: Scout, Arbiter, Carrier. Front row: Zealot, Dragoon, High Templar, Archon, Reaver.

Missing and Broken Pieces

Unfortunately, the game arrived with some broken pieces and one missing piece. Here's a shot of my broken pieces:

Can you believe that all three of Tassadar's Arbiters were broken? I suspect Aldaris set out to sabotage him. Anyway, in addition to the broken pieces, one of Kerrigan's Queens was missing as well:

I guess she got hungry and consumed one. Anyway, from reading on Fantasy Flight's forum, it looks like this is a common occurence, but that their customer service is outstanding and will replace any broken or missing pieces. I've sent them an e-mail; we'll see how it goes.

Game Play

Well, I haven't played the game yet. But I've talked with my game-playing friends, and there's some interest in giving the game a try. FFG has posted the rules in PDF-format here. First impressions? It kinda seems like a combination of Risk and Pokémon. The Risk element comes from the fact that players have territory, and the more territory you have, the more troops you are able to get. The actual game play board, which consists of planets that are interconnected, is generated at the start of the game by player placement. The Pokémon aspect shows itself through battles; each player has a combat deck of cards that are used to play. Also, it helps if you've played the StarCraft video game, so you'll be familiar with the units and attack styles.

I'll let you know how it goes!

Which Rendering Engine

2008-01-18T18:16:00.000-08:00

I haven't been working on the Game Engine for the past two months. Instead, I read Charles Petzold's book Applications = Code + Markup to see if WPF would be a more-suitable rendering solution for the Game Engine.

Actually, that's only partially true. I am actually considering doing the game rendering using Microsoft's Silverlight Plug-in. I was under the (somewhat mistaken) impression that Silverlight was simply "WPF in a box". It's not. (Or at least, version 1.0 is not.) Silverlight 1.0 is a XAML renderer, not a WPF engine. Yes, you can draw buttons and even hook code up to the buttons, but any such client-side code must be written in Javascript. Communications to the server are done via AJAX.

Now it is possible to implement my game design this way. However, recall that in my design, I wanted to have it so that the developer would only have to write the GameState object once. (The GameState object is like the business layer -- it wraps the raw GameData and translates it into something useful, and enforces some rules.) But with Javascript on the client, it would force the developer to write the GameState object twice -- once for the server side in a CLR language, and once for the client side in Javascript. Now, I could do something like have the server side load a Javascript runtime and run Javascript on both ends, but the truth is, I'd rather have the developer write C# or VB.NET on both sides.

Enter Silverlight 1.1, which promises that you can write your client code in C# or VB.NET. This does hold some promise, but I will need to take a closer look. I'm going to be playing with Silverlight 1.1 over the next few weeks and evaluating its potential for the Game Engine.

Popsicle Stick Bridge Contest

2007-12-23T13:38:00.000-08:00

How about a quick break from programming?

This past fall, my third-grade son was in a school-sponsored Family Science night, where a local science teacher has the families perform a few science-oriented activities (such as studying the properties of a cornstarch mixture à la Mythbusters Walking on Water). He really doesn't teach the concepts, however; he just lets the kids do the activies and have fun with them.

The long-term project was to build a bridge out of popsicle sticks and Elmer's glue. We were given a bag of 49 popsicle sticks (we were supposed to receive 50), a small length of twine (which we lost), and the bottle of glue. The bridge was to span a length of 12 inches, and we could use any resource that we wanted, including the Internet.

I figured that the lessons were:

Triangles are strong
Computers can be used to design bridges

So after poking around the Internet a bit, I ran across the West Point Bridge Design contest, and their software:

http://bridgecontest.usma.edu/.

This program lets you design and submit a bridge for the West Point contest. Of course, I was not interested in entering the West Point contest, but the software does do a good job of analyzing your design. One of the cute features of the program is that after you lay out the design, it will drive a truck across the span, and if the span does not hold, the truck will plunge into the river. (This kept my son occupied for hours!)

After some playing, we came up with a basic design and built our bridge:

As you can see it was a simple truss design. I especially like the triangular beams that are holding up the cardboard deck (we did that for fun -- the deck was not permanently attached and we did not take it with us to the contest). Also, it's hard to tell from the picture, but the topmost beams in the center are doubled. This was because the software indicated that these members would be the most under compression. You can see this better in our shot of the Presidential Limousine crossing the bridge:

Unfortunately, I didn't bring my camera to the competition. About half of the bridges were trusses; the other half were simple spans. Of course, the simple spans snapped after about ten pounds of load. The trusses fared much better, each holding over 40 pounds. One bridge made it up to 55 pounds... it was tough to beat, but we did it! Our bridge made it to 60 pounds before it started to creak and then finally fail:

It was very interesting to see where it failed. The center stayed put; it was the ends that collapsed.

The bridge is still in pieces, but maybe over Christmas break I'll glue it back together. We still have the cardboard deck. And hey, it's fun to play with!

2007-10-28T08:15:00.001-07:00

Given that the plumbing of the Gaming engine was able to support TicTacToe, I decided that I wanted to work a bit on front-end presentation. Up until now, the front-end was using Windows Forms, which has been around since .NET 1.0. It's straightforward to use, and if you grew up with programming the Windows API (like I did), it's easy enough to learn.

One of the things I want the Gaming Engine to do was grey out the playing area while waiting for other players to join. The game owner would also have a special control window that allows him/her to move players to different seats, to invite players, and to eject them. I want it to be in a window that sits on top of the playing window, but I also want the window to be somewhat transparent so that the immediate effects of the game can also be witnessed.

The problem is, for out-of-the-box Windows Forms, only the Form class supports an Opacity property. It's a neat property, but it makes the whole form translucent, not just the child window.

I started reading up on alpha blending and looking at some Win32 API extended styles. Although I knew I could figure it out, I decided not to pursue it, for a few reasons:

I knew that WinForms was not "the future", so to speak.
Using P/Invoke to access the Win32 API is straightforward enough, but the Gaming Engine loads the game assemblies into AppDomains that have limited privileges, for security reasons. Although the engine will have the necessary rights for P/Invoke, setting up the necessary Asserts() is tricky, and I'd rather not do it unless I had to.
If other technologies solved the transparent child window problem, then it's less work for me.
Since I'm already using WCF for the Gaming Engine communication layer, I'm already committed to .NET 3.0

So I decided to put the Gaming Engine on hold for a bit, and focus on learning Windows Presentation Foundation (WPF).

I'm about halfway through Charles Petzold's book Applications = Code + Markup. And I have to say this: WPF is a good thing.

If you've been putting off learning WPF, and clinging to Windows Forms as I had been doing, stop doing it now. WPF does things a whole lot better. Here's what it does:

If you want, you can lay out a window like a web page, with tables that automatically size themselves.
They finally got the command-routing code right. I've toyed with a few solutions of my own, but their command binding solution is very clean.
They've got a document-view construct similar to that of MFC.
And of course, you can apply Opacity to a child window.

I love how Petzold doesn't even introduce XAML until the second half of the book. He has several code examples, and once you've written all the code, you'll appreciate the declarative nature of XAML, and why it was developed. The only thing I don't like about his book is that he doesn't illustrate all his samples -- you've got to actually run the programs to see the output. (I'm reading his book from books24x7.com, so it's just copy/paste for me.)

Here's a program that illustrates a child window with Opacity. I've derived two classes from label: Clock and SeeThruMessage. Clock is just a label with a timer, and just displays the time. SeeThruMessage is a label with Opacity set to 0.5. The great thing is, even when SeeThruMessage is in front of the Clock, the Clock still continues to redraw. This is exactly what I want.


using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Threading;

namespace JamesQMurphy.Test
{
   public class TestOpacity : Window
   {
      [STAThread]
      public static void Main()
      {
         Application app = new Application();
         app.Run(new TestOpacity());
      }

      Clock _clock = new Clock();
      SeeThruMessage _mymsg = new SeeThruMessage();

      public TestOpacity()
      {
         Canvas canvas = new Canvas();
         this.Content = canvas;
         
         canvas.Children.Add(_clock);
         Canvas.SetLeft(_clock, 0.0);
         Canvas.SetTop(_clock, 0.0);

         canvas.Children.Add(_mymsg);
         Canvas.SetLeft(_mymsg, 0.0);
         Canvas.SetTop(_mymsg, 0.0);
         _mymsg.Width = 400;
         _mymsg.Content = "Howdy!";
         _mymsg.Opacity = 0.5;
         _mymsg.Visibility = Visibility.Hidden;
      }
      protected override void OnMouseDown(MouseButtonEventArgs e)
      {
         base.OnMouseDown(e);
         _mymsg.Visibility = Visibility.Visible;
         e.Handled = true;
      }
   }

   public class Clock : Label
   {
      private DispatcherTimer _timer = new DispatcherTimer();

      public Clock()
      {
         _timer.Interval = TimeSpan.FromMilliseconds(500);
         _timer.Tick += new EventHandler(_timer_Tick);
         _timer.Start();

         this.Background = Brushes.Blue;
         this.Foreground = Brushes.White;
         this.FontSize = 20;
         this.FontFamily = new FontFamily("Comic Sans MS");
         this.Width = 250;
         this.Height = 75;
      }
      protected override void OnMouseDown(MouseButtonEventArgs e)
      {
         base.OnMouseDown(e);
         MessageBox.Show("Click clock!");
         e.Handled = true;
      }
      private void _timer_Tick(object sender, EventArgs e)
      {
         this.Content = System.DateTime.Now.ToString();
      }

   }

   public class SeeThruMessage : Label
   {
      public SeeThruMessage()
      {
         this.Background = Brushes.Orange;
         this.Foreground = Brushes.White;
         this.FontSize = 40;
         this.FontFamily = new FontFamily("Comic Sans MS");
      }
      protected override void OnMouseDown(MouseButtonEventArgs e)
      {
         this.Visibility = Visibility.Hidden;
         e.Handled = true;
      }
   }
}

Game Ratings

2007-10-09T18:12:00.000-07:00

A quickie... Coding Horror is one of my favorite blogs. This post talks about game ratings. Definitely good material for the Gaming Engine!

State of the Game State

2007-09-30T09:06:00.000-07:00

Way back when, I outlined the basic workings of the Game Engine. To summarize, there exists a single Game object on the server that controls the game. The Game object manipulates the GameState, and has complete knowledge of the game. Each player receives a limited, filtered view of the GameState. As the Game object manipulates the GameState, each player receives (filtered) updates to their local GameState object.

But as I actually worked with this model, it became apparent that it was difficult to write the code that did the work of managing the state and filtering when appropriate. So I introduced a new object into the mix, the GameData object. Basically, the GameData object is a set of two dictionaries -- one public, and one private. Any values stored in the public dictionary are broadcast unfiltered to everyone. Values stored in the private dictionary are broadcast only to the player who "owns" the value. Other players (and spectators) know that there is a value stored; they just don't know what it is.

Forgive the cheesy diagram, but here is how it looks:

This simplified things immensely. The GameState object essentially becomes a wrapper around the GameData object, allowing the programmer to put game-specific logic around the data. (Think of it as a business layer.) For example, while writing the TicTacToe game (which only uses the public dictionary), the logic looks something like this (and forgive the cheesy code -- this is illustrative only):


class TicTacToeGameState : GameState
{
   // other code omitted

   public string GetSquare(int nSquare)
   {
      string key = "SQUARE" + nSquare;
      return this.GameData.Public[key];
   }
   
   public void SetSquare(int nSquare, string XorO)
   {
      string key = "SQUARE" + nSquare;
      this.GameData.Public[key] = XorO;
   }
}

To make things easier, the base GameState class has events that fire whenever a value (public or private) is updated. Thus, the client can render the necessary UI whenever the changes happen. Simple, yes, but consider what happens in TicTacToe:

Client submits the command ("X" in center square)

The command reaches the Game object

Game object calls SetSquare method on GameState object

GameState updates GameData object

The changes gets propagated to each client's GameData object

The client notices the change and updates the UI

Note that there is a delay between the time that the player makes the move ("X" in center square) and the time that the UI actually gets the notification (center square now has an "X"). I actually went back and forth on this, but in the end I went with the simple solution: Game Clients can freely update the local GameData object, via the local GameState object. In this case, in addition to submitting the Command, the client application can locally call GameState.SetSquare. The resulting change event fires immediately, and when the change finally arrives from the server, nothing happens, since the value does not change.

I actually do have code that does this, but at first, I added in a whole bunch of extra code that checks for "unexpected updates" (suppose the client marks the square with an "O" instead of an "X"). But lately I decided that this was overkill. Once I remove all the extra code, I'll try and see if I can post TicTacToe as it exists now. You'll even see some of the additional problems that have surfaced.

How do you layout your classes?

2007-09-18T18:16:00.001-07:00

I'm still in the .NET 3.0 world... I haven't really gotten my feet wet with .NET 3.5 or LINQ or any of the latest stuff. But, I finally looked up the syntax of a cool feature of .NET 3.0... automatic properties. Basically, if you write a lot of this:


private int _prop;
public int Prop
{
   get { return _prop; }
   set { _prop = value; }
}

In C# 3.0, you can write it in one line:

public int Prop { get; set; }

The compiler will automatically generate the _prop backing field (although it calls it something like k__AutomaticallyGeneratedPropertyField0 -- see this article at Wriju's blog for more info). This is a very cool thing -- it let's you declaratively express the fact that you have a trivial property. You can write it like a field, but it actually gets implemented as a property. Plus, you can give the get{} and set{} methods different access modifiers:

public int Prop { get; private set; }

I love it, but I'm going to have to rethink the way I layout my classes. This is the structure that I use:


[Attributes]
public class MyClass
{
   // Any constants.  I use ALL CAPS:
   const int MY_VALUE = 4;

   // All static stuff goes here, usually in a #region block
   // The pattern of the static members follows the pattern
   // of the class

   // Any private nested classes

   // All data fields, which are always private by convention
   // Fields marked "readonly" generally come first
   // BTW, I usually use an underscore:
   int _noticeTheUnderscore = 0;

   // Constructors

   // Public properties

   // Public methods

   // Public events (which usually include a protected 
   // override method and a private "FireXXX" method)

   // Any explicit interface implementations
   // (in a #region block)

   // Protected members (properties, methods, events)

   // Internal members (properties, methods, events)

   // Private members (properties, methods, events)
}

Where should automatic properties go? With the properties, or with the fields? The nice thing about keeping the data members in one place is that you can easily get a feel for the memory footprint of the class. And by keeping all the public members in one section, you can see the public interface of a class as well. But automatic properties make this difficult -- do I put them with the private members, where I can see their footprint, or the public interface?

If I had to choose right now, I'd say I'd put them with the other properties. I suppose I could put a comment with the private fields, to help judge the memory footprint, but there is a risk that the comment would not be updated if the property is altered or removed.

Of course, I could simply stick to the old way. But I really hate boilerplate code!

Any thoughts?

2007-09-14T18:32:00.000-07:00

If you work at a big company, then you're probably familiar with the United Way. At my company, we have it too, but I'll give 'em credit: They've come up with some creative ideas to raise the money and have employees donate:

An eBay-like auction site, where employees donate items and services, and employees bid.
A 5K race (in which I'm competing)
An Oktoberfest carnival, where employees can set up fund-raising booths
Various golf outings
A singing contest a la American Idol. This always pulls in thousands of dollars.

Well, our manager has her turn in coming up with an event. And she did what any good manager does... she delegated the task to her minions. And then it hit me.

But first, have you ever seen the movie Midnight Madness? You haven't? Well go watch it... I'll wait.

Ok, our campus sits in the middle of Hopewell -- and I mean campus. It's twelve building sprawled out on grassy fields, complete with a lake (with a little foot bridge!), softball courts, etc. What a perfect spot to play Midnight Madness! So I pitched the idea to my manager, and promised her a more coherent idea by Monday.

Now, we can't have what went on in the movie. That would tear up our campus, and the maintenance folks would be none-too-happy. But, if you couple it up with modern technology, you can get something just as good, and it keeps the campus clean:

Teams start off with a clue. (Example: Geena, Rosie, and Madonna might be here)
The clue identifies a location on campus. (Example: The clue identifies the movie "A League Of Their Own", which implies that the location is the softball field)
Once solved, the team proceeds to the location, where they search for a hidden word.
Back at base, they punch the hidden word into a web site, which reveals the next clue.
The game proceeds on and on, until one team reaches the finish line.

The great thing about involving a web site is that it provides instant tracking, and that it prevents teams from entering clues out-of-order. (In the movie, there were two instances of teams skipping locations when they bumped into teams that had moved ahead of them.)

It's just an idea, but I think I can make it fly...

If I can find M57, so can you!

2007-09-08T18:36:00.000-07:00

There's more to life than game engines and programming... there's astronomy! And tonight I found my first deep space object: M57, the Ring Nebula.

Usually, I'm what they call an "armchair astronomer," which means I'm content to read Astronomy magazine and look at the pictures. But the weather's been nice -- nice enough to go into the pool even -- and the sky was a nice, deep cloudless blue. I took out the telescope (my father's old orange Celestron 8) and pointed it at Jupiter, which is in the southern sky these days. It just so happens that tonight, Europa is passing in front of Jupiter, but I didn't feel like staying up for it.

So I thought, what the hey, let me try for a deep-sky object. Now, you should know that I have never been able to find a deep-sky object. Planets, the Moon, the Orion Nebula -- that's the limit of my experience. So for me, actually finding a deep-sky object is a big deal.

And it's easy! Trust me, if I can do it, anybody can. It's actually located between two stars in Lyra (the names are Sulaphat and Shelyak). If you can find Cygnus, the Northern Cross, then here's where to look for M57:

Yes, it's a cheesy sketch. But I'm serious... just point your scope there and look. You really can't miss it.

A Waitable Queue

2007-09-02T18:30:00.001-07:00

And now for something completely different... a bit of code!

In addition to the Gaming engine, I also have a common library that I use to collect reusable classes and bits of code that I write. One such example is a waitable queue, which is sometimes called a blocking queue. It's a queue where readers can safely wait for an item to be enqueued. Once enqueued, a waiting reader will immediately pick up the queued item. Readers can specify a timeout period; if nothing is queued within the timeout period, the reader will be notified of this.

Most of the time, you won't need a structure like this. The built-in .NET thread pool has a queue; adding an item to the queue is as simple as calling ThreadPool.QueueUserWorkItem. The thread pool automatically wakes up a background thread to come and process the item. This works great for operations where each unit of work is concrete, separate, and does not depend on other items currently queued. As a result, you have no control over which thread actually gets assigned to your work item, and normally, you don't care.

But for the Gaming Engine, my needs are a little different. I want to ensure that Game objects process one and only one work item (Command) at a time, and that these occur in a definite sequence. Thus, instead of the thread pool, the Gaming Engine creates a fixed number of threads. Every game is "owned" by a thread; all calls into the game are guaranteed to be called from the very same thread. To do this, I needed my own queue. Basically, the Game Engine does this kind of work on one of these worker threads:


Queue<Command> _queue = new Queue<Command>();
Command cmd;

while ( false )
{
   Command cmd = queue.Dequeue();
   if ( cmd != null )
   {
      Game game = GetCorrectGame();
      game.SubmitCommand( cmd );
   }
   else
   {
      Thread.Sleep(100);
   }
}

This code is okay, but not great. If the queue is full, then items are processed quickly, but if the queue is empty, the thread sleeps. When an item is finally enqueued, the thread does not automatically wake; rather, it waits until it is done sleeping.

I wanted a class that would allow me to wait, but immediately wake once an item has been enqueued. Enter the WaitableQueue<T> class (code shown below). It functions just like a normal queue, with Enqueue() and Dequeue() methods. It also introduces the WaitAndDequeue method:


bool WaitableQueue<T>.WaitAndDequeue(int timeout, out T item);

If there is an item in the queue, this method functions just like Dequeue. If the queue is empty, the method will block until another thread calls Enqueue(), or until the timeout period is reached. As you can probably guess, the method returns true if an item is returned, or false if no item is returned.

This is a class I designed myself, although I did look at an example of a blocking queue to clean up my design (see the section on "Blocking Queue" in the May 2007 MSDN Magazine CLR Inside Out column. Basically, you can use the queue like so, assuming you have a class named WorkItem:


WaitableQueue<WorkItem> queue = new WaitableQueue<WorkItem>();
int timeout = 5000;  // arbitrary

// Let's assume another thread can call queue.Enqueue()

while ( !bTimeToQuit )
{
   WorkItem item;
   if ( queue.WaitAndDequeue(timeout, out item) )
   {
      // Do work with item
   }
}

The implementation is straightforward enough. The class contains a Queue and an AutoResetEvent. The event is used to signal to a waiting thread that there is an item ready to be picked up. After the item is enqueued, the event is Set, and any thread which is waiting on the event will be woken up.

The call to WaitAndDequeue is a bit more interesting. If there is an item already present, it immediately dequeues the item and clears the event, avoiding any wait. If not, it calls Event.WaitOne(), passing the timeout value. The lock(_queue) is used to ensure that only one thread is actively waiting on the event. The lock(_evt) is used to ensure that the state of the event (signaled or not) is kept in sync with the count of queue items.

Feel free to use this class, royalty-free if you like. Disclaimer: Use the code at your own risk -- I am not responsible for any use or misuse of this code in your project, or any losses you encur! Hey, it's my first code post, gotta be careful. :)


using System;
using System.Collections.Generic;
using System.Threading;

namespace JamesQMurphy.Common.Collections
{
   [Serializable]
   public sealed class WaitableQueue<T>
   {
      // The actual queue
      private Queue<T> _internalQueue = new Queue<T>();

      // Event used to trigger to readers that an item has been queued
      [NonSerialized]
      private AutoResetEvent _evt = new AutoResetEvent(false);

      // We lock on the objects above in the following ways:
      // lock( _internalQueue )
      //      Used by readers (dequeue-ers) only.  This ensures that only
      //      one reader is ever waiting on the event.
      //
      // lock ( _evt )
      //      Used by readers (dequeue-ers) and writers (enqueue-ers).
      //      This ensures that the state of the event is always
      //      consistent with the queue:
      //          Signaled ==> queue has an item
      //          Cleared  ==> queue is empty

      public bool Contains(T item)
      {
         // Locking is pointless here
         return _internalQueue.Contains(item);
      }

      public int Count
      {
         // Locking is pointless here
         get { return _internalQueue.Count; }
      }

      public void Enqueue(T item)
      {
         lock ( _evt )
         {
            _internalQueue.Enqueue(item);
            _evt.Set();
         }
      }

      public T Dequeue()
      {
         T item;
         if ( TryDequeue(out item) )
         {
            return item;
         }
         else
         {
            throw new InvalidOperationException("Queue is empty");
         }
      }

      public bool TryDequeue(out T item)
      {
         return WaitAndDequeue(0, out item);
      }

      // Note:  all dequeue functions go thru here
      public bool WaitAndDequeue(int timeout, out T item)
      {
         item = default(T);

         // Let only one reader in to wait and watch the event
         lock ( _internalQueue )
         {
            // If the queue is populated, no need to wait
            lock ( _evt )
            {
               if ( _internalQueue.Count > 0 )
               {
                  _evt.Reset();
                  item = _internalQueue.Dequeue();
                  return true;
               }
            }

            // Queue is empty.  Wait on the event; if it signals,
            // then something has been queued
            if ( _evt.WaitOne(timeout, false) )
            {
               item = _internalQueue.Dequeue();
               return true;
            }
            else
            {
               // Nothing queued while we waited; we timed out
               return false;
            }
         }
      }

      public void Clear()
      {
         // Make sure these are locked in the same order as WaitAndDequeue,
         // otherwise it will introduce a deadlock
         lock ( _internalQueue )
         {
            lock ( _evt )
            {
               _internalQueue.Clear();
               _evt.Reset();
            }
         }
      }
   }
}

The blog's not dead... really!

2007-08-30T12:13:00.000-07:00

What in the world happened? I'm not sure myself. One minute, you're getting geared up for summer; the next, it's almost over. A summer of lawn-mowing, baseball, and programming. Gone in an instant.

Actually, I do know what happened. Rather than blog about the Game Engine, I've actually been working on it. Or, more precisely, reworking it. I know, I know, it shows lack of discipline. The problem is, I've been so involved in reworking the engine that I really have had little time for anything else.

The first thing I did was redesign the communication layer to use WCF, which was actually quite easy, given the fact that I had already defined the contract, at least conceptually. I started from the ground up, creating new solution files, new NUnit test cases, and new dependencies. This gave me a chance to rename some of my objects (e.g., "GameObject" is now finally "Game"). I'll cover more about the WCF end of it in another post.

What I did want to talk about was the separation of display from game logic. This is one of the tenets of n-tier design: Design a business-layer that's independent of display logic, and then design your front end(s) against that business layer. This allows you to put several different types of front-ends (desktop application, Web application, cell-phone app, etc.) against the same back-end -- this reduces code duplication, which I believe is one of the fundamental evils of programming. It also allows easy reuse of code, especially if your business layer is easily accessible.

I wanted more than a conceptual separation of display and logic; I wanted a physical separation. On the (game) server side, there is no need for display logic, so I didn't want any display-related assemblies (such as System.Windows.Forms.dll) loaded. However, the gaming system will need display-related base classes and infrastructure. These would go in a separate base assembly. It would also require every game to be deployed into two assemblies (if not, then the display logic gets loaded into the server process), although a collection of games could be deployed in two assemblies.

Up until recently, I figured I had two choices for display logic:

WinForms. I'm familiar with this, but it would require the end user to download code.
Javascript/AJAX. Limited, but without the download problem. I'm not that familiar with it (although I have friends that are)

Two new technologies have emerged that caught my eye: Silverlight and XNA Game Studio, both from Microsoft. I'll be evaulating both of them to see which is best. But in the meantime, since I want something out there and completed, I'll stick with WinForms.

Next time... I'll introduce the new Game object properly!

One thing and not the other

2007-05-14T18:12:00.000-07:00

So, by now you would have thought, "Gee, he must be done with his system." Well, no. I did spec out a box, somewhat, but these are the things that have been holding me back:

First, I set out looking for a HD Tuner card with CableCard support. One problem... there aren't any. At least none for do-it-yourselfers like me.
Verizon just dropped fiber-optic cable to my curb (actually, my pole), allowing me to get FiOS if I wanted it. I'm not sure if I do or not... I hate Verizon, which is why I switched to Vonage. But I'm also not thrilled with Cablevision either.
I have had no luck finding hybrid hard drives on the market. These are the hard drives with on-board flash memory... it makes for a very speedy drive.

So, I'll wait.

In the meantime, I have actually been making some good progress on the game engine. A good review of the game engine is here, but there was one fatal flaw with my design. Recall that I had descdribed a "master" Game object that sits on the server, and each player had a "satellite" Game object on the local client that would be kept in synch. Players could submit commands to the master Game object, and a short while later, the satellites would receive synchronization events.

Well, it turns out that actually programming this way was difficult. Take TicTacToe. After submitting a command ("X in the center square"), the Game object would update the state (Center Square, X), then broadcast an event. Satellite game objects would receive the event and make the same update. In other words, there were two mechanisms to update state. This complicated things like validation ("Is it X's turn, and is the center square open?").

Then it hit me. I had the model wrong. Here is the refined version:

There is only one Game object. It sits on the server, and it responds to Commands.
The Game object updates a GameState object, which also sits on the server. The GameState object is just that -- state. In the TicTacToe example, it holds the state of the board, i.e., where the X's and O's are.
The stock GameState object will suffice for most games, although you can derive from it. The base class contains four collections:
a. A public collection. Everybody sees this.
b. A public per-slot collection. Everybody sees these as well.
c. A private collection. Nobody seese this.
d. A private per-slot collection. Each player sees his/her own collection, but not
Each player has his/her own GameState object, which gets used for rendering. The player's GameState has the same four collections, except that:
a. They don't have anything in their private collection
b. They can see the contents of their private per-slot collection, depending on what slot they are in, but cannot see what is in the other slots.

The GameEngine is capable of synchronizing the collections using Actions.

There was one catch: The Game object itself can freely update state, but in order to ensure that any state updates were transmitted, I protected the GameState object so that state can only be updated in the context of an Action. Thus, this code:


this.GameState.Public["some_element"] = "some value";

would only work if triggered from an Action. This worked out well, and in no time I had a clean TicTacToe implementation. I still need to work on end-of-game conditions, but once I do, I'll post it.

Building a PC

2007-03-19T17:48:00.000-07:00

I mentioned that I want to build a new PC for my family room. And here's my requirements:

It has to do DVR
It has to access my MP3 and my pictures, which are on my Networked Attached Storage (NAS)
It has to serve as a gaming console -- games should look good on a 32" LCD TV.
It has to act as a music synthesizer for my M-Audio Keystation 49e
It has to control my X10 devices
It has to look great

In short, I'm envisioning this as my master-control computer. I want my family room to be the "bridge" of my house.

I've built my own machines in the past, and I love doing it. It's really not that hard. I sat down and started to pick the components:

1. I actually started with the last requirement -- that it look great. I wanted a pretty case with front-facing USB ports (for importing pictures, hooking up the Keystation 49e, etc.) and with an LCD panel. I went over to performance-pcs.com and started to browse. Silverstone makes a lot of nice cases, but one that caught my eye was Kingwin's Supernova SN-213HTBK case. Gotta read up on it.

2. Most of the nice cases do not accept full ATX-sized motherboards. The Supernova accepts MicroATX. Okay, fine. Let's assume we're going with a Micro ATX-sized motherboard.

3. When it comes to motherboards, I only buy Intel. I've had bad luck with Asus boards. The Intel board I bought a few years back has never given me any trouble. Ok, Intel motherboard.

4. This actually presented some other questions. What kind of processor? I definitely want at least a Core 2 Duo processor. Yes, Intel introduced their Quad-core processor, but only their top-of-the-line motherboard accepts it, and besides the inflated price, it's full-ATX sized. The Core 2 Duo is fast enough, I reasoned, especially if you have a beefy graphics card, plenty o' memory, and fast hard drives. So I settled for the DG965OT -- it's got the 965 chipset and it's MicroATX. There's a limited number of slots -- in fact, there's only one PCI Express x16 slot -- but I knew that I would only be adding a few cards (graphics card + TV Tuner card).

5. Speaking of graphics card, I had a tough choice. I love my ATI Radeon 9800 series card in my current system, but since I knew I would be running Vista, I wanted a DirectX 10 card. Enter the NVidia GeForce 8800 GTX. And yes, I know that the 965 chipset doesn't support SLI (read about SLI here), but then again, there's only going to be room for one of these cards anyway. (Not to mention that this card runs hot -- hotter than Asli Bilgin.)

6. I've heard that the DVR capabilities of Vista are actually quite good, so I decided that I would run Vista. More on that later.

I also will touch upon hard drives and tuner cards in a later post. That's where it gets interesting!

So what have I been up to?

2007-03-16T03:12:00.000-07:00

Yikes, two months go by without a post! Here's what's up.

Weight goal: Forget it. What I've been doing instead is following the yearlong program at Men's Fitness magazine. Although I haven't been dropping weight, I have been adding muscle.

Gaming engine: Only a few minor tweaks here and there. Nothing substantial.

What I will be talking about over the next few posts is my building a new PC. I will be building a combination gaming machine and DVR (digitial video recorder -- like TiVo). This is actually not that common; most people usually do not build gaming machines that do DVR. But this is for a machine that I want to sit in my family room, and hook up to our 32" LCD television.

More to come!

2007-01-26T05:47:00.000-08:00

A few weeks ago, I mentioned my weight goal: A pound a week, starting at 185 pounds. Well, my progress hasn't been so stellar:

Week	Goal	Weight
0	185	185
1	184	183
2	183	184
3	182	???

I've been doing the first installment of the year-long workout in Men's Fitness magazine. They finally posted it here. This week, I did workout A on Monday, B on Tuesday, and C on Wednesday. Overall, I like them -- they've been a good "shock" to my body and I've been hitting my muscles differently than with my old workout. I've even hit a few that I never hit before! Today, I took the day off and I'm trying another shock. I will do my entire traditional routine in one day, then use my 20% coupon for a deep-tissue massage. Let's hope that gets me down to 182.

Pretty as an IP Address

2007-01-22T18:08:00.001-08:00

9block
Originally uploaded by JamesQMurphy.

This is my home IP address, shown using Don Park's Identicon algorithm. You can read about it here. You can see what yours looks like here.

Basically, the algorithm plugs your IP address through the SHA-1 hash to generate the pattern. Don uses it as an identifier and displays it next to poster's names. Pretty cool, eh?

Dogs and Ponies from Microsoft

2007-01-20T11:01:00.000-08:00

Occasionally, we have presenters from Microsoft come by and showcase the new technologies. This past Thursday, we had a couple of presenters come by and talk about Windows Presentation Framework, Windows Communication Framework, and Visual Studio Team System. Now, we are a Microsoft shop, although we do use other tools and technologies (Oracle, Rational ClearQuest, etc.). Still, the presentations do tend to come off a bit sales-ish. The best way to guard against this is to accept this; I went with the mindset that this was a Microsoft-only trade show. Once you get past it, you can enjoy the show.

Here's what transpired:

Intro to .NET 3.0
I can sum it up with a simple equation:

.NET 3.0 = .NET 2.0 + WPF + WCF + WF

WPF = Windows Presentation Framework
WCF = Windows Communication Framework
WF = Windows Workflow Framework (can't use WWF, that's for the wildlife federation)

Yep, .NET 3.0 does not contain a new version of the CLR. It installs right alongside .NET 2.0, and only adds the components above.

The presentation was given by Asli Bilgin, who is a brilliant presenter and always fun to listen to. Don't know who she is? Google her. Better yet, Google her image -- she is gorgeous! Well, at least I think she is.

Windows Presentation Framework
I'll be honest -- this presentation was a letdown. I expected a demo of the power of WPF and XAML, the XML-based presentation language. Instead, it was a sales pitch for Microsoft's new Expression line of web designer software (think Frontpage trying to be DreamWeaver). It started out good; Asli demonstrated the NY Times reader -- a smart client app that downloads the paper and displays it using WPF technologies. A very cool app! But then she started to demo Expression Blend by building a web app. Which web app? A simple click-on-the-thumbnail and see-the-full-size-image type of app. YAWN SNOOZE it was no easier than five years ago with Visual Studio 2002. Boo!

(Yes, I did ask her a question related to my gaming engine, but more on that at a later date.)

Windows Communication Framework
This one was about what I expected. I have been reading bits and bobs about WCF, and how it's supposed to be the be-all and end-all of any communications going forward. It was a good introduction, the instructor (I can't remember his name; he was good, but hey they can't all be as cute as Asli Bilgin) demonstrated how today's web services can be written as WCF service endpoints. Basically, that's the gist of the technology; you define interfaces (yes, .NET interfaces), attribute-decorate them as service endpoints, and then write classes to implement the interfaces. .NET takes care of the communications underneath, in a declarative-style configuration manner. I only wish that the sample was explained a little better. Case in point: The presenter had a class that called another class. Great, we saw the output. But then he switched the protocol mechanism to use gzip transmission, instead of plain text. The same output. He opened Fiddler (which is a great tool, btw) and showed that the request size shrunk. But why didn't he show the raw transmission? That would have made it much more effective. He glossed over a lot of details but it was a good talk overall.

(WCF is making me think a great deal about the gaming engine; specifically, how clients retrieve the Actions generated by the games on the gaming server).

Visual Studio Team System
This turned out to be a pleasant surprise; too bad we won't be adopting it anytime soon where we work. VSTS is a client/server based solution for software construction. It incorporates project tracking, source control, unit testing, and a build system, all-in-one. It incorporates FXCop and their test software (their version of NUnit) right into the package -- you can even have it prevent check-ins unless it passes the tests. It even has client applications for managers and non-developers, allowing other project stakeholders the ability to gauge project status. Very cool. But it also has some features that don't seem that valuable to me. For example, it also has the ability to "virtually deploy" the app to a "virtual enterprise", supposedly giving you the ability to detect deployment problems. (Yeah right!) I would have also liked to see some collaboration tools built in, like forums or wikis. And integration with other bug-tracking software is promised (we use ClearQuest, for example). But overall, I wish we were using the package today.

Mocking about

2007-01-10T03:15:00.000-08:00

I came across an excellent article on the difference between mock objects and stub objects on Martin Fowler's blog. The article is here. (And then there's Jeff Atwood's take on it here, with his brilliant illustrations of the different types of objects. If you are a coder, you should go read his blog, Coding Horror. I'm serious, go read it. Now.)

In my test cases for the gaming engine, I had a class named mock_Game that would be a test game. It was not a playable game -- it would only do a few things and only respond to a few actions. Its state would be exposed so that the unit test could inspect the results. Well, that's what you get for being new to test driven development -- this is a stub object, not a mock object. Mock objects are proxy objects that are used to test behaviors. With them, you test to see if certain methods were called, and in what order. Stubs are used to test state. You use them to see if the data matches what you expect.

Apparently, there are mock object libraries out there that take existing real objects and are able to construct mock objects. I think I'm going to look into this and see what's brewing. The notion of being able to test behavior is very useful.

On a separate note: At the gym, I ran 5K in 28:35 -- a new personal best! Today, I will be doing workout "B" in the Men's Fitness workout.

Giving it a try

2007-01-08T18:31:00.000-08:00

I mentioned my new Men's Fitness subscription, and how there's a year-long excercise program. I figured, what the hey, give it a whirl. And thus it begins.

I've been training for two years now, and this past year was my first serious training attempt. My problem is not exercise, however -- it's diet. Eating clean is tough, especially when things like ice cream exist. So I thought I would use my blog to chronicle my progress. Yeah, boring, but some people might say that programming a game engine isn't so riveting either.

My goal? Ten pounds in ten weeks. A pound a week, using my bathroom scale, Monday mornings, right out of bed. This morning, I was 185 lbs. If I make my goal, that puts me at 175 on March 19. (St. Patrick's day might make that tough, but here's hoping!)

10 pounds to go!

Not just programming

2007-01-04T18:27:00.000-08:00

Funny, I expected to see a lot of new people at the gym this past week. I did see two new people take a tour, but the gym wasn't crowded with newbies. Generally, there are two times of the year when the gym gets crowded: January and May. January usually brings the New Years' resolutioners, May brings the bathing suit shoppers.

For Christmas, I did get a subscription to Men's Health magazine. I'm going to try their year-long workout and see what kind of results I get. More to come on that.

Doing the Fisher-Yates Shuffle

2007-01-01T07:04:00.000-08:00

Turn the way-back machine to 1982. I was in 7th grade, and the most advanced computer in our house was the Atari 2600. But that was about to change. My father worked for IBM, and had ordered an IBM PC through the company's employee-purchase program. We waited all summer for the PC to come in (it finally came on September 1). But I wasn't sitting idly... I had read a fantastic book on BASIC programming. It was called Instant BASIC and it written at the perfect level for a 7th grader. I had finished the book by early summer and had already written some programs in a spiral-bound notebook by the time the PC arrived (most notably, Yahtzee -- I guess I've always had a penchant for games).

I was captivated by the last program in the book. It was a program to deal five cards from a deck of cards, and offer the user a chance to deal again from that deck or a new deck. The only problem is that it was used to teach two-dimensional arrays. The deck was a 4x13 array of flags. The program dealt a card by randomly determining the suit and rank ([1,4] and [1,13], respectively) and would use the array to see if the card had been dealt. The book pointed out that as you neared the end of the deck, it would take longer to find the remaining cards, and in fact would hang once you tried to deal the 53rd card.

That never sat well with me, and I vowed to find a better solution. Essentially, the solution that I came up with was to represent a deck as a flat array of 52 elements, and to randomly shuffle the contents. This is what I came up with (written in pseudo-C#):


Random r = new Random();
for ( i = 0; i < 10000; i++)
{
   r1 = r.Next(0,52);
   r2 = r.Next(0,52);
   SwapElements(deck, r1, r2);
}

I patted myself on the back and considered the problem solved. Until this morning, that is, when I read about the problems when doing this. It turns out that this problem has been solved already, by the experts. It is called the Fisher-Yates shuffle (or sometimes, the Knuth shuffle), and here is the correct solution:


Random r = new Random();
for ( i = 0; i < 52; i++)
{
   r0 = r.Next(i,52);   // Note the use of "i", not zero!
   SwapElements(deck, i, r0);
}

Several sources have identified "bad" implementations, and most list the example where r1 is between 0 and 52. This actually introduces a bias into the shuffle. My original solution is not equivalent to the "bad" solution, but it might be just as bad. It is certainly much less efficient -- I set the loop to an arbitrarily high number, which is not necessary in the Fisher-Yates algorithm.

It suffices to say, I'm glad that I found this out before I actually implemented any card-playing games in my gaming engine. This is one area of the engine that needs to be well-documented, and it would have been embarrassing had I implemented the wrong algorithm.

One other note: I don't actually use the Random class in the gaming engine. The Random class implements the Knuth pseudo-random generator, which is not sufficient for most real gaming purposes. I use the RNGCryptoServiceProvider class to generate my random numbers, which generates cryptographically-secure random sequences.

No, no, I'm still here!

2006-12-29T08:55:00.000-08:00

I hate when project work takes over life for a short while. Although I haven't been blogging, I have been able to sneak in the occasional minute and work on the gaming engine.

The only real progress I've made is on the seating rules. Recall how I had five states for a slot? (Occupied, Vacant, Open for Human, Open for Bot, Closed) I decided that I didn't need the "Vacant" slot. Instead, I introduced a "seating policy" that can be Autoseat, Player Choose, or Owner Choose. When the policy is "Autoseat", the game engine will automatically attempt to fill a slot that is marked Open for Human. When it's "Player Choose", then players can automatically take the seats themselves. "Owner Choose" means just that... only the owner can seat the players. Bots are always considered "Autoseat" and the engine will always fill slots marked as "Open for Bot."

Speaking of bots... I am tackling bots next. I figure once that is done, I can begin working on the Game Harness -- a program that actually lets a game designer play-test the game.

Later!

Did you notice...

2006-10-03T20:36:00.000-07:00

Is it just me, or does Ivan Rodriguez of the Detroit Tigers look like "Little Arturo" from the Powerpuff girls?

History Shouldn't Repeat (and also, a review of the Game Engine)

2006-09-27T10:17:00.000-07:00

Ok, so why don't I want to replay the entire history of Actions to new players when they join a game? In theory, this sounds like it would work, but there are problems with the approach. Before I explain, let's review the basic engine.

A game consists of a Game object, sitting on a server. The players do not have direct access to this Game object; rather, each has his or her own, separate Game object, which is used to track the state of the game. You can think of this local game object as a player's "view" into the game. Although the players cannot access the server Game object, they can interact with it by submitting Commands to the game, and by listening for the resulting Actions. Any Actions received are fed into their local Game objects, and the local Games are kept in synch. (This is similar to some forms of database replication.)

In so-called perfect information games, i.e., games that have no secrets, players generally receive the same Actions as everybody else. Consider chess. When a player makes a move, both players (and any bystanders for that matter) see the action plainly. In this case, the Actions do not need to be filtered. The same can be said for games like Backgammon, where even though the outcome is left to chance (a roll of the dice), all players have identical information. However, in most card games (like poker), players receive a limited view of the game in that they can only see their cards, and any public cards on the table. Tournaments aside, bystanders cannot see any of the face-down cards. Blind Man's Bluff is unique in that players see all the cards except their own. For this reason, Actions can be filtered and modified before being sent to the listeners. It is theoretically possible for every player to receive a different, customized Action. In most cases however, there will only be two flavors of an Action: filtered and unfiltered, and players will get one version or the other.

Now, consider what happens when a player joins the game. A local Game object is created on her computer, but this object, like a newly replicated database, must be synchronized with the server version. In theory, simply replaying the entire history Actions should do the trick. What are the problems?

For starters, filtering the Actions for the player becomes difficult. During normal play, the basis for filtering Actions is made by looking at the game state (Can this player see this card?). This is straightforward when the Action is current, but when replaying history to a new player, the decision must be made based on the game state at the time of the Action. Requiring this would place a huge burden on game developers.

Second, what if the game has been played for hours, with new players constantly switching in and out? Replaying this history is inefficient, but the situation is even worse with poker. Skilled poker players observe the betting habits of other players, and adjust their play accordingly. If history is replayed to a new player, this new player has a distinct advantage over the established players. The established players would know nothing of the new player's habits, whereas the new player knows exactly what types of players he is up against.

Ok, so then, how do new players get their game synchronized? I decided to punt. Whenever a PlayerChangeAction is broadcast, the game must also broadcast a GameStateAction. In other words, the game must broadcast its complete state, which includes a list of the players, the slots (described in my last entry), the players on standby, and of course, the details of the game. This means that, even if a player enters a game as a standby in the middle of game, the complete state will be broadcast to everyone, even though none of the players have changed. This does require that game developers implement functions to generate the game state on the fly(not including the player details, which would be handled by the engine), and to be able to synchronize to a given state when a GameStateAction event is received. I felt this was acceptable, and in fact also opens up other possibilities (for example, the ability to have a game be hot-swapped to another server, simply by transmitting the state).

Also note that GameStateActions can (and should) be filtered, just like all other actions. A player entering a card game would only see the face-up cards on the table, and not what is in the players' hands.

It should be worth noting that this research is leading me into the world of game theory. For example, the types of games I have been modeling are called extensive form games (as opposed to normal form games). Neat, huh?

Next time, I'll talk about the necessity of updating game state only during Actions (and not during commands). I encountered this earlier, and it's been bugging me ever since.

Slot Machine?

2006-09-25T18:28:00.000-07:00

I usually try to work on the gaming engine during lunch, but for the past two weeks, work deadlines have made that impossible. Nonetheless, I've been thinking about the engine, and as promised, I'll discuss the problems associated with adding and removing players.

During the course of most games, the progression is such: The players gather. Somtimes, as they arrive, they take their seats at the game table. The game is laid out, and sometimes, certain decisions are made. (I remember showing up to play a game of Dungeon, and both my friends had already chosen the coveted "Wizard" class, of which there are only two.) Once all the players have arrived, the game commences and progresses, until there is a winner. Sometimes players are eliminated, sometimes they stay until the end. Pretty simple, yes?

Now suppose a player has to leave. Traditionally, there have been three courses of action:
1. Abandon the game. Yuck.
2. Put the game aside and play it later. Essentially, save the game. Difficult to do in the physical world, where Mom and Dad would insist that the game be put away and there is little time to write down all the details. Easy to do in the virtual world, of course!
3. Have another player take her place. Perfectly acceptable, if everyone is willing. The advantage is that the game can continue.

Notice how (for most games) that the game cannot continue unless there are the same number of players. This model is straightforward to implement. There are, of course, exceptions: Poker and Yahtzee are two that come to mind. But this opens up a whole new set of problems: games in which the players can join and leave anytime. How can that be implemented? Even more importantly, what kind of model takes both types of games into account.

But wait, there's more. Consider an Internet-driven scenario, where a player starts up a type of game (say, the Cheapass game Fight!). This is the kind of game where the number of players is constant, but he may not know how many players will be joining. He may wait around, and once a certain number of people show up, then he will start the game.

I settled upon a moderated chat-room model. A player creates a game, and other players can come and go. The initial player is the "owner" of the game, and as such has total control of the room. She can invite players, boot players out, rearrange the seating, set up bots (Bots? more on that later), etc. The difficulty was that, once a game was started, how do you "freeze" the players so that no new players could barge in on the game, and yet not keep the players hostage, which is impossible to do anyway. Plus, suppose a game was waiting for a final, fourth player, and two players entered the room at the same time. One player would win the seat, obviously, but what would happen with the other player, who was expecting to join a game. Putting up a "Sorry, you missed!" message seemed, well, mean.

I got around these issues by developing this set of rules:
1. Games can hold an unlimited amount of people. (Not players, people). People can see who else is in the room and who is playing the game (and who is not).
2. Players can be invited to games, but they cannot enter a specific game on their own.
3. Players can "wait in line" for a certain type of game to open up. When such a game needs a player, it can invite the player in.
4. Games have a limited number of slots. These slots are for those players who are actually playing the game. The number of slots equals the maximum number of players that can play a certaing type of game. This is important; a type of game always has the same number of slots. Chess has two, bridge has four, Parker Brothers' Payday has four, even if only two are playing.
5. Slots can have one of five states: Occupied, vacant, open for human, open for bot, and closed. The game owner can freely change the state of any slot; this is how he can control the number and types of players. Here is what they mean:

Occupied -- a player is in that slot
Vacant -- the slot is empty, but available. Only the owner can place a player or bot in this slot.
Open for Human -- the slot is empty, but any player can enter the slot.
Open for Bot -- the slot is empty but is immediately filled with a bot by the game engine.
Closed -- the slot will not be occupied. This is how owners control the number of players in a game.

6. If a player is in a room, she can be either in a slot, or she can be on standby. While on standby, she can see who is occupying the slots, and can wait for a slot to open. (Typically, this would happen in a friendly game, where the player would know the owner).
7. Removing a player from the game does not necessarily remove him from the room, although the owner can do that as well if she so chooses. The player would simply be on standby until he was placed in a new slot.
8. A player can leave the room at any time. At this point, the slot would revert to the "Empty" state, where the owner can assign another player, a bot, or open it up to other players. Note that if the owner closes the slot, this could potentially end the game, as the number of players would have changed. This decision would be left up to the specific game.

It is important to note that when a player joins or leaves a game, or one of the slots changes state, an Action is generated and broadcast to all people in the room (not just the players in the slots). Remember, the basic model is that Actions are broadcast to all occupants, so therefore, the entire state of the room must be broadcast, so that the newcomer can receive a complete list of the occupants.

That's all for now, it's getting late. I still haven't answered the question I raised in my last post -- why not broadcast a complete history to newcomers. But you might be able to guess at some of the reasons. I promise -- more later.

Game: A series of (fortunate) events

2006-09-11T05:05:00.000-07:00

In thinking about how to design a game engine, I realized that every game (at least the ones that I can think of) are a series of events. Pawn to K4, Pawn to KB4, Knight to KB3. X in the center square, O in the upper-left corner. Purchase a hotel on Boardwalk. I chose to design the game around this concept -- it is an ordered sequence of things that happen. Rather than use the word "event", which is already used in most programming languages (including C#), I settled on the word "Action". By viewing a game as a stream of Actions, it solves some problems nicely:

1. Threading. I wanted game design to be simple, and by guaranteeing that games are single-threaded, this simplifies things. A game can sit happily on its thread, processing Actions one-by-one.

2. Scalability. Ordered lists translate very nicely to queues, which scale very well.

3. Auditing. By storing the stream of events, a complete record of the game is kept.

4. Persistence. Not only can a game be saved this way, but it can also be loaded by simply "playing" the stream from the beginning.

5. Transmission. For multi-player scenarios, Actions can be broadcast to the appropriate players, and each would have an updated version of the game state.

This works very well for deterministic games like chess, checkers, and TicTacToe, where Actions are 100% player-determined. Initially, this was my first attempt -- each player would submit an Action, and the engine would submit it to the necessary parties. Take TicTacToe, for example. Suppose the board consists of nine squares, numbered 1 thru 9 (1 in the upper left, 5 in the center, 9 in the lower right). When player 1 places an X in the upper-left corner, she would submit an action of "1", which would get broadcast to both players and any auditing routines. If player 1 tries to submit again, before player 2, this would be considered an illegal move and would be trapped. Once player 2 submits a move (let's say he chooses the center square, so he submits a "5"), the Action gets broadcast again.

But what about games such as Backgammon, where the roll of the dice can change the outcome? Certainly, a player cannot submit an action that translates into "I rolled a double-six." This caused me to alter the model slightly: Players would not submit Actions, they would submit their intent, which I call a "Command". In the backgammon example, a player would submit a command to roll the dice, and the server would generate the appropriate Action (a "6-2" was rolled, for example). Then the player would submit additional commands that indicated what her move was, which would in-turn generate more Actions. Note that the other player would still see a stream of Actions (a roll of "6-2", then a move). In the case of TicTacToe, the players submit Commands, which simply translate directly to Actions.

Implementing the Command/Actions scenario turned out to be a little tricky. Remember that one of my goals was to keep the amount of work simple -- I didn't want to have to design separate objects for the server version of the game and the client version. So, Commands generate Actions, and the Actions get echoed to every Game object in the mix, incluing the server version itself. This presented a little realization: I could only update game state during the Action processing phase, not the Command processing phase. This made sense: during playback, for example, there would not be any Commands, so all game state updating needed to occur during the Action phase anyway.

So far, so good. There were two challenges that I saw:

1. Filtering of events. During, say, poker, when a player is dealt a card, only that player can know what the card is. In my mind, this was an easy problem: simply filter the events before sending them to the players. The actual player would get a truly descriptive action ("a 2 of clubs was dealt"), whereas the other players would get a filtered version ("a card was dealt"). Auditing and history listeners would get the full, unfiltered version.

2. Adding/Removing players. This was a tough challenge, at least for me. When a new player joins, he does not have a list of all the Actions that led up to the current game state. (In fact, he doesn't even have a list of the players!) While I could have chosen to simply replay all the events to the new player, I didn't want to go that route, for several reasons. I'll describe my reasons and the solution in the next entry.

I'm not alone

2006-09-01T07:19:00.000-07:00

A friend of mine just passed on a link to this blog. I'll check it out!

http://www.codinghorror.com/blog/archives/000669.html

TDD -- Tofu Driven Development?

2006-09-01T05:03:00.000-07:00

I've been using TDD (Test Driven Development) on my gaming engine. How's it going? Well, it's going alright, I suppose. It definitely takes some getting used to. You know what it feels like? It feels like "eating clean" -- you know it's good for you, and you see some benefits, but you'd much prefer to slip into your old habits.

Eating "clean" is a term that bodybuilders use. It means eating only healthful foods, good, clean food that is good for your body. Naturally, this means no sweets, but it also means no processed foods, no bad fats, and no bad carbs (breads, pasta, etc.). It also means no dairy -- lactose is a sugar. In fact, Dr. John Emmett gives a compelling argument against dairy in his book, "Turning Back The Hands of Time". (His website is here.) His argument is simple: humans are the only mammal that continue to drink milk after being weaned. He claims that's why you see no pudgy lions. I've also seen this argument lots of places on the web. And come to think of it, housecats will also drink milk if it is given to them, and housecats also tend to be fat. I do work out, and I try to eat clean, but it's not easy -- especially when there's ice cream. Oh, and cheese. Me love cheese.

Anyway, what about Test Driven Development? Well it's like eating clean. It's good for you, it produces clean code, and it requires discipline. I've been programming my game engine and I can tell you that what I have so far is bug-free. But it requires patience. Whenever I create a new class (like my SeatManager which I'll describe another day), I create a set of test cases for it, to make sure the class behaves well. I fully exercise the class before introducing it into the code. This produces high-quality code.

But it's slow, at least at first. Because your forced to spend some time developing quality up front, it feels like your going at a snail's pace. The only comfort is knowing that there are very few loose ends -- and for those that are there, I have a failing test case.

Eat clean. Code clean. (Should that be my new motto?)

Game Engine -- Let's talk

2006-08-19T19:49:00.000-07:00

Okay, it's about time that I started talking about the gaming engine. I'll start by talking about the design goals; i.e., what I wanted to accomplish. I've mentioned that I wanted to create a framework that would allow me to create games without worrying about things like player connectivity, backup, etc. Essentially, solve these problems once, encapsulate it into the framework, and never worry about it again. I also mentioned that I was using Tic Tac Toe as a test game.

Well, when I finally got .NET 2.0 and NUnit installed, I decided to take what I learned and rewrite from scratch, using a TDD (Test-driven development) approach.

Here's the problems that I wanted to solve, listed out, along with some analysis:

1. Adding/Removing players. First, there's the number of players. Most games have a variable number of players, usually two to six or two to eight. Some games (such as chess and checkers) have two and only two players. Some games are elimination-style (think Monopoly). Other games, like poker, can actually change the number of players when somebody joins the game.

This raises another interesting problem: Who controls the players that join the game? Some games can be "open" and anyone can join, but most users would want some measure of control over who can join (and who they can give the boot).

2. Thwart cheating. This is fundamental, and a crucial problem for large-scale commercial gaming sites. But think about it for a moment. For games such as chess and checkers, can you really cheat? The only way to cheat at these types of games is to distract your opponent, and while she is not looking, rearrange the pieces on the board. (And any half-decent player will immediately notice!) Ok, the first type of cheating -- modifying game state -- is easy enough to solve.

But the second type of cheating -- accessing to privileged information -- is more commonplace and comes in many flavors. During a card game, if a player can read the cards of his opponents, he can better his game. If a player can predict the outcome of seemingly random events (i.e., she knows the next die roll during a Monopoly game), she can alter her decisions to take advantage.

This problem can have some subtle challenges. If a player is hosting a game on his computer, he technically has access to the entire game state. Moreover, if a gaming system is written so that private information is passed to the clients, it must be written so that other players' information does not get passed to the client. (Even if it is not displayed, it can still be "read" using debugging tools.) Again, not a problem for chess, checkers, or TicTacToe, but a problem for most games.

As you'll see later, I put this problem front-and-center. The solution specifically addresses this problem. (Hopefully it won't be months from now!)

Registry access bug in Visual Studio 2005

2006-06-21T18:47:00.000-07:00

At Merrill Lynch, I have administrator rights to my machine (they're not easy to obtain any more, by the way). Mostly, this is so that I can install tools, install the Merrill Lynch application frameworks, set up a local website, etc. Also, it allows me to run certain legacy applications (such as PVCS). Imagine the shock that Merrill Lynch will get when they learn that Visual Studio 2005 will also require admin access.

On my home machines, I run Windows XP Professional. I'm smart enough to create limited access user accounts for me, my wife, and my son. It's kept us virus-free for years. (My mother-in-law, who recently got a new computer and who runs as Administrator mode, managed to get SpyAxe on her computer. When my wife asked if we could get it, I could confidently tell her that there was no way SpyAxe would be able to drop its naughty DLLs in our Windows\Systems directory.)

Well, I was running Visual Studio 2005 (legally, mind you) on my home machine, from my limited user account. I plugged in my thumb drive and started to write some test cases for my framework. I went to add a file to the test project (Add New Item or Add Class) when I got a message box: "Requested registry access not allowed."

It turned out that there are a boatload of classes in HKEY_CLASSES_ROOT that do not have READ access for the Users group! I found the answer on the MSDN forum, and even posted my two cents (see it here.) Simply granting read access to the Users group did the trick. I modified these three keys; there are many more that I didn't bother with:

HKEY_CLASSES_ROOT\VisualStudio.cs.8.0
HKEY_CLASSES_ROOT\VisualStudio.csdproj.8.0
HKEY_CLASSES_ROOT\VisualStudio.csproj.8.0

Hope this helps somebody out there!

PS-- As far as my mother-in-law's SpyAxe infestation, a recent Microsoft update corrected the problem. She may run as Administrator but she does have automatic updates turned on thankfully.

Summer of TDD

2006-06-21T05:51:00.000-07:00

The official start of summer -- how's my summertime programming going?

Well, it's actually not as bad as it's been. I've got Visual Studio 2005 installed both at home and at work. I haven't tackled the game engine yet -- I've got a very small framework that I've been working on and converting to .NET 2.0.

I've also downloaded NUnit (http://www.nunit.org) and am seriously trying TDD -- test-driven development. TDD is something I've always believed in, and I've done it informally -- usually hacking together a test app or test page for web apps. NUnit lets you write test-case code, and it provides the harness that locates and runs all your tests.

Now, normally, I hate third-party components and avoid them like the plague, especially when it's something I can write myself. But I love NUnit. It's open-source, and you know what's nice? They tell you exactly what files are going where when you install it. Bravo! Another thing that I like is that NUnit itself is developed using TDD -- they eat their own dogfood (see Wikipedia to see what that means).

Here' how TDD works --you write the test first, then you write enough code just to get the test to compile, although it will fail when you run it. Then you write code that makes the test succeed. You refactor as needed, and you can refactor with confidence, since you have a boatload of test code that immediately tells you if you've broken anything.

The one cardinal rule about TDD is that you don't write a line of code until you have a supporting test in place. Another way of saying that is, if you have to write more code than you have tests, then you need more tests. The one thing I don't understand is, how does that work with GUI programming? Specifically, how can you test whether or not your program drew the graphic correctly? Comparing screen bitmaps seems to coarse a method. At least NUnit lets you download the source (and the test cases); maybe I'll see how they did it.

Like I said, I started doing my framework in .NET 2.0, using TDD. One of my classes that I'm particularly fond of is my CommandLine class, which encapsulates a command line and its arguments. Now, it's true that .NET passes the command-line arguments in a string array, but this is crude. My class is quote-aware, which means this command line:

xyz.exe "Hello world"

will actually report one argument. In addition, I look for named parameters and provide a handy accessor method, so that when passed the command line:

xyz.exe /a:One /b:Two

I can access it like this:

CommandLine cl = new CommandLine("xyz.exe /a:One /b:Two");
string paramA = cl.Named["a"];
string paramB = cl.Named["b"];

TDD is perfect for this kind of developent. Within a day I had about twenty tests, and I know that if I make changes to the class's implementation, I can run these tests in a split-second and see if I broke anything.

I just have to get to the gaming engine now!

Summertime programming... gotta love it!

2006-05-31T03:06:00.000-07:00

There's something special about programming in the summer, at least for me. Lounging by the pool with a good book, spending nights by the keyboard with the windows open and the warm summer breeze blowing.... you know how it is.

Some of my favorite summers were those spent programming and learning. In 1995, during my first programming job, I first learned how to program Windows. During the summer of 2000, I spent countless hours creating the user interface for Toadnode, a Gnutella client. In 2002 I first learned the .NET framework.

The summer of 2006 is off to an awesome start. The northeast had one of the nicest Memorial Day weekends in years. I'm set to make this one of the best programming summers yet.

Here's a list of what's needed:

A technology to learn. In my case, it will be .NET 2.0. I'm stoked about rewriting the game engine to make use of generics.

A project. Easy -- the afore-mentioned gaming engine.

A good book. Check -- "CLR via C#" by Jeffrey Richter. When you can't be programming, you can be reading in the sun.

Some good tunes. This I have to decide upon, but I'm leaning towards Alanis Morissette's acoustic release of "Jagged Little Pill."

The Game Engine and Why

2006-05-10T05:25:00.000-07:00

This is what working at Merrill Lynch has done to me.... five months without a blog entry. Shame. Well, at least we have a new director in place, and thankfully, he is not your business-as-usual guy. Very personable, as well.

Ok, ok, the game engine. Why? So I can be a better poker player, naturally! I believe that I can be a better poker player by writing a poker game, at least as far as getting a handle on odds and game mechanics and such. Yes, I know that true poker is a people game, but there is still much to learn about it by writing you own version.

I have never visited one of those online poker sites. If I did, I would surely stop programming in my spare time altogether! This is what happened before -- I had an idea for a really great game, but then I discovered Starcraft, which came pretty close to my vision of the "perfect" game. I stopped programming for about two years! (I still play Starcraft, on occasion...)

Here's how my thinking went. Many times, when reading a book that teaches a programming language, some of the examples will model real-life examples. For example, a book might teach two-dimensional arrays using a chess program. This works great with newer languages such as Java and C#: Their rich support of classes makes it possible to model just about anything. This is kind of the point -- well-written business class libraries model business rules, and leave storage and presentation details to other layers. One should program against Account objects, not against pointers to numeric arrays.

When learning C#, one of the first things I wrote was a poker-scoring algorithm, and it was fun to write. I then thought, hey, I have the makings of a good business layer, why not expand it? So I pondered the problems of an online poker game (presentation, keeping players cards secret, connecting players, keeping a permanent record of all games, etc). I would also want it to play variants of poker (7-stud, Omaha, etc.) and I would also want it to be played locally on the PC as well.

The thinking expanded. Occasionally, a friend of mine (the same friend who gave me the "Q" in my name) hosts a board game day in his basement. This is where I first played Puerto Rico and Age Of Steam. I thought about how I would love to write computer versions of these games, and also thought about how these could possibly be played online or locally.

I realized that all online games share fundamental problems: How to connect players, how to log all game activity for auditing purposes, authentication and security, etc. Some games also have the additional problem of player secrets; games like chess and checkers have no secrets, but virtually all card games do (the cards in each players hand). Then of course, each game has specific "business" rules, and each game also has different presentation rules (although games played with playing cards can share much of those presentation rules).

Thus was born the game engine, and I'll get into the design in future entries. As I mentioned, I started with one of the simplest of games -- Tic Tac Toe. So far, it has proved a good "straw man" of a game and has given me a good test bed.

More later... right now, back to my PL/SQL training course!

My Pet Project

2006-01-25T18:13:00.000-08:00

I'll go into details at another time, but my big pet project at the moment is a gaming engine. Right now I'm testing it with Tic-Tac-Toe (how lame!), but a future milestone is to write a more complicated game, such as chess. Problem is, I don't have the interest, inclination, time, etc., to write a chess engine.

That's when I thought, "Gee, I wonder if anyone has exposed such an engine over a web serice?" A quick Google search turned up www.valil.com. The actual endpoint of the service is here. The author, a guy by the name of Valentin Iliescu, wrote a .NET Compact Framework app that plays chess, using a web service as the back end. Clever! He even won a prize and wrote an article on it on CodeProject. Sounds like fun! This guy is pretty sharp and does a lot of Avalon work. Can't wait to explore his blog.

I wonder if police detectives feel this way

2006-01-10T14:44:00.000-08:00

Every developer has been there: Faced with a problem that occurs once in a while, with no apparent cause, armed only with a few sparse log files, the poor developer is asked to solve the problem. It's like trying to solve a crime with precious few clues.

That's where I was today, and it is quite literally the hellish part of my job. The sad part is that once solved, the developer usually gets no recognition, since, after all, it is his job. The only consolation prize is a heck of a war story (and maybe some good material for the year-end performance review).

Perhaps a good night sleep can help me find the problem. Go subconscience!

Container Pattern, or, So that's what I'm up to

2006-01-09T18:10:00.000-08:00

Ok, almost a month goes by and nothing to show.

Truth is, we are coming out of a monster of a release. I work for Merrill Lynch and am part of the Retirement Group, which means I work on their 401(k) website, Benefits OnLine®. If you happen to have your 401(k) plan record-kept by Merrill Lynch, and checked your 401(k) recently, then you know what I mean.

But, ironically, that's not what I wanted to talk about. It's about a rather silly article I read in the "Design Patterns" column of the September 2005 issue of MSDN magazine (yes, I'm behind). The article can be found here. Don't get me wrong; I'm a fan of patterns and glad to see Microsoft actually referencing them and using them. But this article spells out a rather mundane example of "Dependency Injection," which (at least to me) is just a fancy name for dynamically loading code. Snooze -- this sort of problem was solved with COM over ten years ago.

But, there was one thing that interested me. The column was also a shameless plug for a product called Spring.NET, which is a framework that offers some services. Funny thing -- that's also what I am working on: a framework. No, I am not trying to rewrite .NET (and neither is Spring, for that matter), but I do find that, in my own work, I tend to solve certain problems the same way, and I basically wanted a package that allowed me to easily reuse my solutions. I also wanted a way to easily inject workarounds for those pesky .NET problems like memory leaks and what not.

What was interesting? The article mentions that frameworks are an example of the Container pattern. Containers can provide common services to the objects they house (the Microsoft-y example being the Transaction context provided by COM+). Which is exactly what I am after.

So that's what I've really been up to... implementing the Container pattern. Like I said, I like using patterns.

Me? A blog?

2005-12-19T18:31:00.000-08:00

Well why on earth would I have a blog?

It's a recent decision, really. See, I'm a developer, and I was passed a link from a fellow developer. This link took me to another developer's blog, where he talked about some discoveries about static constructors in C#. I won't repost the link, because the entry itself was useless, but then, it finally occured to me.

Blogs are today's research journals!

Well duh! But it took me awhile to make that connection. And as I thought back over my ten-plus years as a developer, and all the systems I have worked on, I realized that I have collected a tiny bit of knowledge -- the kind of knowledge that can't be learned in a book, nor even a forum, but rather, the kind of knowledge that only experience can bring. The kind that comes from watching other skilled developers ply their trade. The kind that comes from all-night releases of web applications. The kind that comes from talking with the systems folks, listening to them ping and pinch and test connections.

So stay awhile! I hope you get to know me a bit.