I certainly don't want this to turn into a video blog of fish, but I got some more video of the fish in our stream, and it's so unbelievable to me as someone new to this area that I simply must post it.  I've also done some tweaks to my custom Silverlight player as well as used some different encoding techniques (I haven't decided whether I like them yet).

Again, enjoy me sounding like an idiot.

[UPDATE:] The way I have embedded the player this time seems to prevent it from showing in most RSS aggregators. click through to my blog to see the video.

Here I am sticking Dan while he tries to score a flag capture.  Halo 3 rocks.  This is a screenshot of real gameplay.

[I ended up uploading to Flickr while I figure out how to link to the screenshot on bungie's servers]

[UPDATE] Some people have complained about my "real gameplay" statement.  Let me clarify.  After the game, I replayed the film of the game, during which I paused at this frame, detached the camera, took this picture (which automatically makes it available from bungie.net).  I am the guy at the top of the ramp.  I've just thrown a grenade toward Dan, which subsequently stuck to him and killed him.  So, no this is not what I saw during the game, but if someone else was in the game with there head where my camera was, you would have seen this.  My point was that it is not a "cutscene", manually posed render or other pre-rendered sequence (although you could argue the pre-rendered point since screenshots are slightly higher resolution than is being processed in-game).

So, the salmon are running in our stream.  They're really big.  I caught this video today of a smaller female (I think).  Hopefully I'll get some bigger ones on video soon.  This is also an experiment with Silverlight.

Oh, by the way.  I'm like giddy with the thought of salmon in my stream, so I sound like an idiot.

I wish I had time to come up with more concrete information (examples/code) in this post, but I don't have the time to work that stuff up.  I did think it would be useful for people searching for solutions to this problem, so here it is in all its ambiguity.

I was playing with expression tree inspection and dynamic interpretation the other day, when I hit something that I was sure was a bug.  I was inspecting an expression tree, identifying "branches" of interest, and generating lamdba expressions from them on the fly.

You might do this to break up an expression into separate units of execution to spread across multiple processors (a la PLINQ), or to replace parts of a tree requiring local execution before passing off to another layer to be transformed into another domain like SQL, or whatever.  In any case, I was doing it.

I found that if the type of the expression was a value type, I could not create a lambda expression returning object from it, even though there is an inheritance relationship.  You get a fairly straightforward, but perhaps surprising exception.

After some back and forth with the Linq team, I discovered that this was by design.  In the case of value types, the boxing operation required to make an object must be represented by a unary convert expression. The solution is to wrap such expression trees with a call to Expression.Convert(expression, typeof(object)).

Today is my 1-year anniversary at Microsoft.  I've been having a blast working on all kinds of crazy stuff including but not limited to:

• Silverlight
• VS 2008 (Orcas)
• Windows Vista
• Windows Server 2008 (Longhorn Server)

And, Seattle has turned out to be a really fun place to live.

Today is my buddy Dave's birthday.  Here's a picture of him from a few weeks ago when he visited, which was a blast.  I've really missed Dave since we moved to Washington, so it was awesome that he could visit.

Luckily, Halo 3 is coming out soon, so we'll be hanging out alot more virtually.

Happy Birthday, Dave!

An interesting pattern I've seen emerge since the early releases of Orcas is what I might refer to as "delegate properties".  What I mean by that is a property (or field, I suppose) that returns a delegate.  This pattern has some interesting implications.

First, in a language that treats delegates as directly callable objects, this pattern looks just like a method (someInstance.TheProperty(args)).  You can't tell the difference (although VS gives you different intellisense) by looking at a callsite like this. Among other things, this leads to some interesting naming issues.  Do you name it like you would a method?

Second, it opens up opportunities to do some really powerful (and slightly insane) hybrid inheritance models.  Think about a virtual delegate property that has both a getter and a setter, now think about trying to predict what that delegate will do when you call it.  It doesn't sound like something to recommend as part of a public API, but I think there are some interesting scenarios there.

If I come up with something interesting and useful, I'll let you know.