Edit: This first article might be a bit dense at times. However, I promise, if you stick through and read at least until Parts II and III (Loops are Evil) you will see major benefits that will totally transform your code (even C# 2.0 code!). In fact, to the first 3 people that can show me that these practices will NOT result in better code in many enterprise apps, I'll give $100 each. Post a blog comment or email me (mgg AT telefinity dot com).

Redundancy in source code is a common degeneration. But for the C# programmer, her weapons to eliminate it have been unwieldy at best. She has been able to eliminate simple, blocky, patterns, but truly writing reusable code at a fine level has not been easy.

This series will demonstrate how you can take advantage of functional programming (FP) in your work, today. The first task is to dispense with the notion that functional programming is difficult and strange. Most FP articles start with a recursive definition of the Fibonacci sequence and then talk about currying functions. Here, we're going to start off with something that every C# programmer has used many times. I can guarantee that after you absorb this series of articles, you'll be writing more concise, less buggy, more powerful software. I've seen many C# modules get cut down drastically in size. I've seen new C# code written that does multithreading and it was written correctly on the first go. I want you to see these things too.

Refactoring out common blocks of code is familiar. Probably every developer has written a helper method to initialize a database command or prepare a commonly used object. Unfortunately, refactoring only tends to happen to contiguous blocks. We do not see refactoring of complex patterns that do not fit into neat blocks. Consider the following visualizations of a program. The red blocks are the unique parts of the program, and the grey ones represent common statements.

                                             becomes

It is easy to refactor the first sequence: move the common parts into another function and call it. However, the second pattern poses quite a problem. The individual "common" blocks are too simple to move into another method. The call to the refactor method would be the same as the method itself! How can we refactor it correctly?

Well, C# itself contains keywords that refactor some of these patterns. Consider the using keyword. The following two methods are nearly equivalent:

void usingPatternExample()
{
    string result;
    StreamReader sr = new StreamReader(filename);
    try {
        result = sr.ReadToEnd();
    }
    finally {
        if (sr != null) sr.Dispose();
    }
}

void usingKeywordExample()
{
    string result; 
    using (StreamReader sr = new StreamReader(filename)) {
        result = sr.ReadToEnd();
    }
}

I think it is obvious why everyone uses the using keyword over writing out this long init-try-something-finally-dispose pattern repeatedly. When we read code that uses the using keyword, the intent is instantly clear. We don't need to go validate the pattern to make sure it does what we think it does, we can just see "using" and know that it is correct. As an extra benefit, we can declare our disposable variable inside the using scope, so that we don't accidentally use it after it is disposed.

This is all good and dandy, until we realize that we are stuck with the handful of patterns defined as C# keywords! If I wanted to declare the variable result as an output of the using statement, I'm out of luck. If I want to initialize multiple objects in one using block, then that is just too bad. Part of the reason for this is that it was extremely ugly to do this in C# before version 3.0. Consider this C# 1.0 example to recreate the using keyword as a user-defined function:

delegate void UsingAction(IDisposable obj);
void Using(IDisposable obj, UsingAction action)
{
    try { action(obj); }
    finally { if (obj != null) obj.Dispose(); }
}

So far, so good – nothing ugly yet. The usage of this user-defined Using function on the other hand:

string result;
void UsingExample1()
{
    Using(new StreamReader(filename), new UsingAction(readIntoResult));
}
void readIntoResult(IDisposable obj)
{
    StreamReader sr = (StreamReader)obj; 
    result = sr.ReadToEnd();
}

Atrocious! The pattern of the code is shattered and complicated to follow. The main part of the code (getting the result) is forced to sit in a separate method many lines away. We're required to use fields to pass data in or out. And just to top it off, lack of generics forces a cast – we had to write StreamReader three times. The utter syntax hides our intention. In short, it is completely unusable.

C# 2.0 makes some progress. First, we can change UsingAction to Action<T> and allow the caller to specify the type. All that is needed is a constraint on the type to IDisposable. The new declaration of Using looks like this:

void Using<T>(T obj, Action<T> action) where T : IDisposable

This says that we need something of type "T", and the only restriction is that T must be a type that implements IDisposable. Then, we want an Action that works on that same type T, whatever it is. By using T instead of a specific type, we are essentially saying "we don't care about what type your object is; our function works with all sorts of types". This is the source of the name "generics". Our code is more generic; it's not tied to a specific type. Generics are an extremely important tool for refactoring patterns because patterns occur across different types.

To clean up the calling code, C# 2.0 has a feature called anonymous methods. They are exactly as they sound: methods without names. They can be declared inline, right along with the rest of the code. Additionally, they "capture" local variables, making it unnecessary to declare fields to pass data in and out.

void UsingExample2()
{
    string result; 
    Using(new StreamReader(filename), delegate(StreamReader sr) {
        result = sr.ReadToEnd();
    });
}

What a major improvement! C# 2 can infer the type of T for Using, avoiding having to write Using<StreamReader>. Apart from having to type StreamReader twice, this code is starting to approach the level of clarity that the using keyword provides.

C# 3.0 introduces lambdas. Now, that's usually a scary word from functional programming, but it's actually very simple. For C#, it's just an easier way of writing anonymous methods. Instead of having to write "delegate(ParamType paramName) { }", we can just do "paramName =>". That's all there is to it! Nothing scary at all. For example, if I want to write a lambda to add two numbers, I’d write it like this:

Func<int, int, int> add = (int a, int b) => a + b;

The part Func<int, int, int> says we have a function that takes two ints and returns an int. Next, we declare our two integer parameters: (int a, int b). Then, we define the lambda body by using the => operator. Our body consists only of “a + b”. With lambdas, if we only have one statement, we don’t need to explicitly use braces or the return keyword. Alternatively, we could have written it as:  

Func<int, int, int> add = (int a, int b) => { return a + b; };

Behind the scenes, the compiler goes and creates a method and creates the Func delegate on top of it. So, armed with this new syntax and power, let’s take another look at our Using method:

This shows there is nothing that special about the built-in keywords. It is also the first step in demonstrating that some parts of functional programming are not very foreign to the C# programmer. The next articles in this series will provide some real-world application of these ideas and show how you can reduce the amount of code you have to write (and reduce the number of bugs at the same time!).

C# with lambda syntax and extension methods (in lieu of compositional operators) gets us so far, but the syntax and compiler could use a bit of polish. I'll show some exact examples later, but meanwhile this picture sums up my feelings at the moment:

Edited to add: Inspired by http://xkcd.com/297/

Edited to add: Just to be clear, this isn't a compiler or IDE issue: it's a spec issue (AFAIK). The C# spec simply doesn't allow certain things (like type inference from a method group).

We were rolling out a new database that is transactionally replicated to a few other nodes. In test and staging, everything worked fine, but in production, on a cluster, the distribution job failed. The snapshot runs as the SQL Agent account, but the distro runs as a separate account to distro just that database to the subscribers. The error is:

Unable to start execution of step 2 (reason: Error authenticating proxy DOMAIN\SomeUserName, system error: Logon failure: unknown user name or bad password.). The step failed.

We spent about an hour trying to figure out what was going wrong -- all the ACLs were right, the user was in the PAL. Everything was identical in permissions to the other environments.

After a bit of time on the line with PSS, we noticed that if we ran everything as the SQL Agent Account (the cluster service), then it worked. But, this required adding the cluster's account to the subscriber DB, and that was not acceptable.

Finally, our PSS rep suggested we check that the SQL Agent account was trusted for delegation. Bingo. On staging and test, the SQL Agent account is Network Service (or Local System). But in a cluster, it runs as a separate account, and that account is not trusted for delegation. Hence, the impersonation call failed. Simply going into ADUC and trusting it for Kerberos delegation, then restarting the SQL Agent, allowed us to use the proxy accounts without problem.

It seems like this message comes up a lot in context of replication and clusters. Hope this helps someone else!

My friend just dealt with an oursourced project. Yes, outsourced as in sending it to a place that charges a lot less money than, say, developers who actually know what they're doing.

One of their deliverables was a program that compressed an XML string into a gzip file. Should be a minor thing, right? The C#/.NET 2 code is less than 10 lines. Well, their first delivery produced files that contained the text "System.Byte[]". This was not accepted and they vowed to look into it in more as they were sure the code was correct.

Their next files were a bit larger and supposedly were really correct this time. But still, no zip program could read the data. Well, a quick look at the beginning of the file shows the bytes EF BB BF -- the UTF-8 BOM. The rest of the file was ASCII digits. Yes, they wrote the bytestream out as a UTF-8 interpretation.

If we define evolution as "the non-random survival of randomly mutating replicators", we can define their approach as "the non-random acceptance of randomly mutating programs."

Having just got a dSLR (Nikon D50, rather low-end) with the cheap kit-lens (some Quantaray lens), I had been looking for a better lens. Most of the photos I take are inside, mainly snapshots. I've never seen flash photos that look that great, so I prefer to use the existing light. Of course, indoors, this makes for some really nasty blur in most cases. There's just not enough light inside my house to be able to get a fast enough shutter speed.

I read some reviews about the Nikon VR (Vibration Reduction) lenses, and that they supposedly compensate for 3 full stops. I tried one VR lens out in a store, and it seemed pretty interesting, so I ordered the Nikkor 18-200 VR. Unfortunately, Nikon apparently doesn't know anything about logistics or manufacturing, and this lens is backordered 2-6 months (depending on who you ask). Since I don't want to be taking crappy shots for that long, I grabbed the Nikkor 24-120 VR as a temporary lens. Well, I'm not sure it'll help my crappy shots, but at least they won't be blurry.

I got home, it's dusk, and decided to try it out. For fun, I set the exposure to 1 second, and well, let the results speak for themselves:


VR Off:


VR On:


Ignore the actual value of the image (I'm not a photographer), but just look at the blur. Granted, I was lying against a sofa, so I had a bit of something to lean on, but the difference with VR on == wow! So, given a bit of support, I can take pictures, handheld, with exposures > 1/15, no problem. Worth every dollar.

Yes, I know this is nothing new, but I'm so impressed I wanted to write it down (also helps my rationalization on buying the lens :)).

Sniping is placing your bids seconds before an auction ends. This allows the buyer to get an item for less money, since there is no bidding war. eBay allows and encourages sniping. Google for eBay sniping to find services that do this.

People say this helps them save money since there is no bidding war, and they don't accidentally get carried away. Well, if you have no self control, then you've got other problems.

Sniping fundamentally goes against eBay's system. Let's take sniping to its logical conclusion: everyone snipes. In this scenario, you essentially have a sealed-envelope auction. Everyone submits their bid, then at the end of the auction the person with the highest bid wins. But eBay is NOT a sealed-envelope auction. If it were, then why would eBay have outbid notifications?

A lot of the justification for sniping is ridiculous:
    "It helps us control spending." -- So does eBay: type in your "true max" into the eBay proxy bidding, and you're done.

   "It allows us to be away from the computer." -- So does eBay's bidding.

   "If auctions auto-extended to avoid sniping, then we'd be on for hours." -- Only if you wanted to exceed your "true max" as snipers are so fond of calling it. This contradicts the "controlled spending".

eBay simply contradicts themselves on that simple premise: why offer services (outbid notifications, showing bid history, etc.) that go against sniping, if sniping is something that should be done? Moreso, why does eBay themselves not offer a sniping service, and instead makes you pay a 3rd party? The lack of critical thought in this country is astounding.

Any pro-sniping people out there, feel free to post a rebuttal in the comments. If there's any real reason 3rd party sniping sites should exist, I'd love to know.

Edit: Removed horrible wording at beginning :).

Just got an Xbox 360 and tried Burnout Revenge on Xbox Live. For some lame reason, you have to play on EA servers (I believe it's so they have more of an excuse to get your details). Anyways, they ask for your permission to use your Xbox live data. The prompt looks like this (paraphrasing):

Can Microsoft share your Xbox Live account with EA?
A = Yes , B = No

This is the standard Xbox 360 convention, where A = Accept/Next/OK and B = Reject/Back/Cancel.

Then they ask two more questions, Can EA spam you with their newsletter, and can EA share your details with other companies. This time the responses are:
A = No, B = Yes

Of course, you're trained to press B for no and by the time you realise they've tricked you it's too late.

Way to go EA, thanks for just making sure we have a reason to hate your company. And Microsoft, WTF? What about making sure the user is in control? MS should not allow their partners to behave like this.

I got this error while using Team Build today (from the event log):
TF53010 ... Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression ... sp_InsertProjectDetails ...

According to http://geekswithblogs.net/cyoung/archive/2006/03/09/71820.aspx, this is a bug in the RC (yes, I still haven't had a chance to goto RTM). I'm not sure if it's fixed in RTM or not. At any rate, my issue was that I had 2 shared projects (projects that are included in more than 1 solution). The second shared project references the first. These seems to cause Team Build to die, with no error in the build log. The event log has more details. So, I added a hack of a file reference instead of a project reference for that solution and things seem to build.

Here's one thing I love: Vista Tablet capabilities :). The tablet input area is always visible as a ~5 pixel deep tab, and it throws a drop shadow on windows in the foreground:

One of the big features of Vista was supposed to be that it was resolution-independent so that high resolution displays can be used. This makes extra sense when you think of Media Center on high-res systems. I have a Dell 24" LCD, 1920x1200 resolution and I run Media Center on it. Outside of Media Center, things look horrid. So I gleefully installed Vista Beta 2...


You still have to reboot after changing DPI. Sigh, ok... And then? Things look like crap. Half the windows seem to scale somewhat decently, half don't. And the ones that scale? Ever blown up an image in Photoshop? Yea, it looks worse than that. Seriously, WTF? There is supposed to be all these advanced graphics rendering capabilities, but they still can't render high DPI stuff correctly. Even the "Back" button (the round circle with arrow) looks like a horrible upscaled image. Pathetic. I've got no problem shelling out the $$$ that Vista ULTIMATE (sigh, MS marketing and sales needs to be caned) will cost IFF it's gonna make my home PC/MCE be one extremely slick amazing thing. But they've got a way to go, apparently.

Anyone else having this issue? When I use Outlook, it sometimes just spikes to 100% (well, 50% since I have hyperthreading). This is making the magnificent Beta 2 release of Office 12 almost unusable.

-- OK, seemed to be the indexer, as I left it alone for two hours and now it's behaving... strange...

Other than that... WOW. Sending an email never looked so good :).

This night, at around 23:30 we went to the hospital because Gaby was having contractions (3 months early). Exactly one year ago, to the hour, we went to the hospital for Mei. Fortunately, this time it wasn't as big a deal, a few injections and tests later and we're back home, everything ok for now... Just very... odd/coincidental/? that down to the hour we were going back to the hospital, one year later.

Mei was born a year ago, on 19 May 2005. Happy Birthday, Mei!


We love you forever Mei

Well, after almost exactly 6 hours, I've succeeded at installing SQL Server 2005 Reporting Services on a server with more than one website.

We're running Reporting Services on separate web servers. So, after the install of reporting services, you run their little configuration tool. This of course, accomplishes very little :). See, apparently Reporting Services wasn't designed to work on a server running, *gasp*, more than one application.

If you have a decent IIS install, the default website isn't there and thus requests to http://localhost/ aren't gonna work. Reporting Services doesn't take this into consideration, and happily tries to request http://localhost/ReportServer/ even after you've specified this in the config tool. If this is your issue, you'll get a “HTTP Error 400: Bad Request“ when trying to access the ReportManager (/Reports/) website.

You'll need to edit the config files in Program Files\.....\ReportManager and ReportServer. rsreportserver.config needs to point to http://the.reporting.host.name/ReportServer in the UrlRoot element. In RSWebApplication.config, ReportServerUrl will need to have the same value. The ReportServerVirtualDirectory element must be deleted. You will get a “The configuration file contains an element that is not valid. The ReportServerUrl element is not a configuration file element. “ message. This is because the config reading code apparently doesn't fail gracefully. What it's trying to say is “the ReportServerUrl and ReportServerVirtualDirectory elements are mutually exclusive”. I'm still unsure why there should be anything besides a URL...

Around here, you might notice a bunch of DCOM errors in your Event Log (or before this point). To fix these, you'll need to go into dcomcnfg and edit the COM security for My Computer. Give the account you're using (like Network Service or “MyReportingServicesAccount“) permissions for local activation and local launch. You need to reboot for these changes to take effect (I think). But don't reboot just yet...

Finally, you end up with a 401 Unauthorized when accessing the Reports site. You might have also noticed you are also unable to authenticate when browsing the Reports or ReportServer sites from your the local server. Why?
“Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.” So I'm guessing NTLM susceptible to this type of attack, and Microsoft is saving us from it. Well, it also hoses us in this case because from what I can tell, ReportManager (the thing in the Reports vdir -- why it wasn't called ReportManager by default...) needs to connect to ReportServer. It sends a request, which is denied because of the loopback protection above. A quick registry edit fixes this: http://support.microsoft.com/default.aspx?scid=kb;en-us;896861

After that... you might have a working SQL Reporting Services 2005 install! (Next up: Getting it to work with SSL...)

Really, apart from the horrible setup/configuration, it's a very very fine product. I'm actually pretty impressed. The report I wanted to setup (and the subscription so it's mailed out) only took about 10 minutes (first time I've ever used RS)! I'm just at a loss why Microsoft makes it so hard to setup. This configuration can't be that unusual. And, even stranger, most (if not all) of this configuration issues could take care of these problems. In other words, their little configuration app should automatically fix this stuff (or at least give explicit instructions on how to do so). Or maybe I just didn't RTFM that well... but this is a Microsoft product... you're supposed to just shove the DVD in the drive and click next, right? <g>

P.S., if you're getting a “Object Reference not set to an Instance of an Object“ when you add a new subscription, ensuring everything else is 100% working should make it go away...

http://webproject.scottgu.com/Default.aspx

YEY!!! Finally, after 2 years, we get VS2003 functionality back in VS2005. The biggest pain point I have, every single day, is dealing with the vile VS2005 web sites. Microsoft has finally realised that this monstrosity spawned to soothe the demented minds of webmonkies who think HTML is a programming language is actually bad for real developers. Really, how does catering to the people who think “build“  refers to writing code help them? (Oh wait, I know. It allows them to gain access to “web developers“ while knowing that people who know what they are doing still won't defect.)

This is exactly like I predicted -- Microsoft will have to back down. I guess it took the final RTM launch for everyone to try to upgrade their apps and then find out that the new model is unusable. I wonder how many PSS cases/pieces of feedback they got.

Well, I can't wait to change our projects to this format. I was planning on restructuring our solution (22 projects in VS is unwieldly) anyways, and this will go great with it. I know a few developers who are gonna be real happy when they come back after the holidays! Maybe this means that doing a public refactoring in our solution won't take 45 seconds anymore? Maybe these apps will build in less than a minute (like every other C# app)?

Oh, BTW, I'm far from ungrateful, even though I might sound like that. I'm actually very happy that the ASP.NET team is doing this, despite the fact that I might roll my eyes and say “yea, about time!” :). But after going through all the pain I have... perhaps its understandable.