One of the new features in C# 3.0 makes absolutely no sense to me: automatic properties.

I have two issues with this approach. First, Wouldn't it make more sense to just have VS ask: "Do you want to generate a public property" when a user creates a field (like when VS detects the user adding an event handler)? From the description, it seems like the private field doesn't get generated until compile time, meaning the class writer is working against the public property as well. This seems odd since one of the main scenarios for using public properties and private fields is so that the class writer can manipulate the internal data representation without affecting the external interface. Scott himself mentions:

The benefit of this is that from a type-contract perspective, the class looks exactly like it did with our first (more verbose) implementation above. This means that -- unlike public fields -- I can in the future add validation logic within my property setter implementation without having to change any external component that references my class.

Which leads me to wonder why the developer would not just write the private field declaration and auto-generate the get/set methods instead, a much more logical approach to class design which leads to more legible code.

I can appreciate that it saves space in the code view by omitting otherwise "useless" lines, but don't code regions already accomplish the same thing?

Seems like a pretty useless feature to me that ultimately leads to more abstract code (less readable, in my opinion).

Aside from that, the code usage itself looks suprisingly similar to an abstract class.  From a design standpoint, if it's not clear what the validation logic or some other property masked logic is at the moment, if it's not clear how the internals of the class should function, wouldn't it make sense to program against an abstract class and put the actual logic into concrete classes at a later time when that logic is available?  It seems to me that what the automatic property is saying about the class is that: "I know what my external interface looks like, but I don't know what my internal representation and logic should be", which is one of the reasons we have abstract classes, right?  So that we can substitute the actual representation of the internal logic of the class at any time down the line while maintaining the external interface contract.  I dunno, just seems like a useless and otherwise bad feature to me.

One of the other main features, LINQ, already has me shuddering in anticipation of the nasty code that I'll inevitably have to face down the line.  Can you imagine the horror of code mixed with complex data queries in any application of significance?  For the same reasons that one would put a public property as a facade to a private field, it only makes sense to use a stored procedure, view, or table valued function as a facade to the underlying data (now I could see a case being made for it with a framework that allowed the queries to be loaded and cached dynamically at runtime from external files with a cache refresh callback on file change).

Yummy.

I think I need to drive into New Brunswick.  Right now.

Damn you, MSNBC!

So my interest in NHibernate is picking back up again.  The 1.2 beta release that's circulating now (the candidate release has been out since February of this year) addresses various issues with NHibernate in my previous time with it.

Specifically, the biggest issue was native support for generic types.  In addition, it seems like there are various other goodies in the 1.2 release such as stored procedure support.

And to think, I just got the team to standardize on Microsoft Enterprise Library 3.0.  I'm wondering how to break this to the team.

I guess in a sense, they are not completely incompatible.  Roll your own queries and data access routines are still the way to go for more complex queries (does NHibernate handle FOR XML EXPLICIT?) and anywhere high performance is critical.

The beauty of this whole thing is that as NHibernate has gained traction since the first time I used it like 2 years ago, the tool support has evolved tremendously.  Combined with MyGeneration and user templates, I was up and running (although the generated output had some minor errors in the XML mapping file) in minutes.  Not only has the tool support improved, the documentation has improved as well.

There is still some conflict, internally, as I was just ragging on LINQ last week with another group of developers for the simple fact that it creates a tight coupling between code and the raw data.  Whereas with stored procedures, you can have dedicated DBAs write highly performant code and you can modify the underlying data retrieval and layout so long as you maintain the same resultset, with dynamic queries, you lose a lot of that flexibility.  In addition, you lose a bit of testability as well since many times, it's just really helpful to be able to test the SPROC independently of any code (or perhaps breakdown subqueries in the SPROC to test small subsets of data).

In actuality, I think that having the mappings as XML is probably better than using LINQ since the XML mapping files can be loaded at runtime, meaning that the deployed mappings can still be manually updated whereas LINQ would necessitate a recompile of the source (my understanding of it).

So if you haven't checked out NHibernate for a while, now's a good time to get a refresher and re-evaluate the library.  I think it will still stick around even after LINQ is released.

See if you can figure out how much your company's deployment of MOSS2007 will cost:

• Feature Matrix (in Excel, no less)
• Baffling Pricing List
• "How to Buy"

Mindblowingly convoluted.

Anyone who has used the .Net XmlSerializers have surely encountered the dreaded namespace bloat which makes the serialized objects grow to ridiculous sizes.

There's a nice little article over at TopXML on how to deal with this bloat.

If you're using WSCF, on the client stub, I've gotten into the habit of writing custom serialization overrides in partial classes which ensure that if the client needs to serialize objects into XML, I'm doing so in an efficient manner.  It'd be nice to see it added to the server side class constructors as well.  Add your vote for this feature over at the WSCF dicussion boards.

So I filed my taxes pretty early this year (this is the first time I've ever owed taxes) using TurboTax.  At the end of the submission, I was given an option to pay with a credit card, direct debit, or check.  Since I don't want to carry around a several thousand dollar balance and since I didn't have the requisite funds in my checking account at the time, I had to settle for a check.

I took care of the state taxes first since it was a much smaller sum and I had enough in my checking account to cover it.  Intuitively, as you logged into the state tax payment site, it would pull up the information regarding the e-filed tax returns, show you how much you owed, and ask if you wanted to pay in full.

Fast forward 20 days.  After I transferred the funds from a savings account, I found out that to pay online (since TurboTax didn't show the payment options interface again), I needed an EFTPS account, which for some reason or another takes 15 days to process the account setup.  So after receiving the account information and activating my account over the phone, I proceeded to log onto the site and attempt to pay the balance owed on my 1040.

Unfortunately, this process came to a screeching halt once I reached the "Tax Type Selection" screen which presented the following 6 options:

• Estimated 1040ES 
• Balance due on Installment Agreement 
• Pmt on an amended return 1040X 
• Extension 
• UnderReporter CP2000 
• Audit Adjustment 

I knew for sure that the last two options were not applicable, but for the life of me, I couldn't figure out which of the other four I should be using.  The help on the page is completely useless, presenting the following information:

The payment due information, such as a Federal Tax Deposit for businesses or an Estimated Tax Payment for individuals. This is the type of tax you are paying. The options shown here are those available for the Tax Form you selected above.

And of course, selecting three of the other four options lead to the same exact form...To make it even more "user friendly", the forms were not populated with data that made sense.  Instead of pre-populating the amount with the amount I owed and the "Tax Period" date with "2006", the date entered is "2007".

Being completely baffled by this system, I proceeded to call the EFTPS customer service line.  Surprisingly, I got through on a Saturday in no more than 1 or two rings.  Unfortunately, the service rep. that I got was definitely clueless and instead, referred me to the IRS offices.  Since the IRS offices are closed on the weekends, I had to postpone the whole ordeal until this morning.  The funny thing is, after speaking with the IRS rep., she admitted that she had never actually seen the system and couldn't help me pick an option (but she was nice).  Instead, she referred me back to EFTPS customer service.

Grrrr....

Fortunately, the woman I reached this time seemed to know my problem right off the bat (you know, as if she'd received like, a million calls about it already).  It turns out that the second option, "Balance due on Installment Agreement", is missing some text and should really read something like "Balance due on Installment Agreement or Current Tax Return".

What really baffles me is why my data wasn't just pulled up when I logged in.  It would only make sense that once I was authenticated through this whole ordeal of linking a funding account, obtaining a PIN, and activating my account over the phone, the software would be able to pull up my already submitted e-file with the amount owed with a text box asking me how much of the balance I wanted to pay and a button labled "Pay Now".

I've found that in software/UI development and working with other people, if you make a process (any process, software or human) intuitively easy, even people who would otherwise wince at the suggestion of doing something will accept it.  Imagine if everytime you shopped on Amazon and you wanted to add something to your cart, you had to click the item and it would take you to a screen where you had to enter the SKU from the previous page... 

One would think that the government would want to make it easy for citizens to pay their taxes.

My goodness...

Via WindingRoad.com.  I am sooo looking forward to NYIAS this year.

You know it's a slow newsday when the AP decides to run a story on how they didn't run stories on Paris Hilton.

AP: We ignored Paris Hilton

NEW YORK (AP) -- So you may have heard: Paris Hilton was ticketed the other day for driving with a suspended license. Not huge news, even by celebrity-gossip standards. Here at The Associated Press, we put out an initial item of some 300 words. But it actually meant more to us than that. It meant the end of our experimental blackout on news about Paris Hilton.

And of course, they celebrate by patting themselves for not reporting non-news and putting out a 1000+ word long article on how they ignored Paris Hilton.  All the while, they've been wasting all too much effort on reporting the Anna Nichole Smith story - thanks for keeping me in touch on that guys, not like there are more pressing concerns, right?  You know, like a stock market dip?  The war in Iraq?  The President's outrageous budget and tax cuts for the upper echelon?  Yeah, I didn't think that stuff was important either.

These guys deserve some sort of award...for stupidity.

If you're expecting the WF (Windows Workflow) passivation services to work out of the box, well, you're half right. 

From one of my workflows, I've been able to trap that an error was being thrown at some point during execution, but it wasn't clear what the actual error was or what was causing it.  I knew it had to do with passivation services since everything was just fine and dandy once I removed the passivation services from the equation.

From the runtime level, I received the following not-so-helpful error message:

System.InvalidOperationException: Workflow with id "[some-guid]" not found in state persistence store.

Just on a whim, I attached SQL Server Profiler to the database instance where the persistence store is attached to track the queries and lo-and-behold, the mystery culprit surfaced:

declare @p10 int
set @p10=0
declare @p11 uniqueidentifier
set @p11=NULL
exec InsertInstanceState @uidInstanceID='2686AB8F-35A4-49C3-AED8-9F239D00D3AC',@state=0x,@status=3,@unlocked=1,@blocked=0,@info=N'Type
''Zorch.Alta.EastCastle.Workflows.DataProviders.Implementation.MockStepProvider'' in Assembly ''Zorch.Alta.EastCastle.Workflows, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null'' is not marked as serializable. Type ''Zorch.Alta.EastCastle.Workflows.DataProviders.Implementation.MockStepProvider'' in
Assembly ''Zorch.Alta.EastCastle.Workflows, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'' is not marked as serializable.',@ownedUntil=''9999-12-31
23:59:59:997'',@ownerID=default,@nextTimer=''9999-12-31 23:59:59:997'',@result=@p10 output,@currentOwnerID=@p11 output
select @p10, @p11

Well, yeah, duh!  It seems so obvious after the fact.  So the moral of the story is to make sure that all of your classes are marked with serializable :P I'm just not sure why they decided to place the error message in the procedure call to insert the instance state.  Why not actually raise an error to the workflow runtime that a class was not serializable?

Windows Vista is Windows ME Part 2. It took five years to develop because three of those were spent building a brand new code base that didn't work at all and wound up getting scrapped, and the remaining two were spent just tweaking the XP code base. Almost all the features we were promised early on were discarded and what we end up with is a warmed over Windows XP that doesn't even do us the dignity of working properly out of the box. I think it's particularly telling that they've already announced the next major Windows release for late 2009.