Pictures from our trip to the New York International Auto Show: 2007 are up.

Enjoy

I also have some non-auto show photos that I thought came out really well:

We stopped by Bryant Park since I had to make a trip to the Taiwan Cultural and Economic Building (or something like that) to renew my Taiwanese passport.  I love it when I can kill two birds with one stone.

While I never liked working in NYC, as I commented to my wife, there's just so much visual texture that it's still refreshing to visit once in a while.  It's in the faces of all of the people you see, in the architecture, in the smells (and many of them are admittedly nauseating...), in the shops, in the food, and in the very space itself.  Your eye glances everywhere and it's visual overload.

Seems like someone knows the answer.

Talking good.  Shooting bad.

Why can't we all just be adults and stop this posturing?  Whatever happened to dialogue (at least give it a try)?  In the end, we're all human beings sharing the same planet with the same goals in life right?  We all want to live a happy, healthy life and to be surrounded by friends and family.  What does it matter our other differences if we all have this in common?

Sometimes, diplomacy at the highest level of our government seems like simple name calling and schoolyard taunts/threats.

So the big news today is that EMI is going DRM free.

A few months ago, in a hotel room in King of Prussia, I had a short debate with Brad and Jim (CEO and CTO of the company I work for). 

One of the technologies that we circle around frequently is Microsoft's Information Rights Management Server.  The gist of it is that it allows administrators to control the actions a user can perform on a document such as printing, emailing, copy/pasting text, and so on.  In short, it is a software solution to controlling distribution of a document, much like DRM when it comes to distribution of digital media like music and movies.

However, to me, this has always seemed like a big sham.  Why?  Because any user that wanted to counter this could do so quite easily.  It only adds a false sense of security, which is doubly dangerous if the documents in question are highly sensitive. 

For example, if printing were to be disabled on a document, the user could still use print screen to capture the image and print that instead.  Disable print screen, and the user can still take pictures with a high resolution digital camera.  Force employees to check all digital devices before entering the building, and the employee can still take notes by hand.

In short, IRM, like DRM, simply presents an encumberance to legitimate users of the digital content while not preventing losses to anyone that really wants the information or content illegitimately.  As we've seen in the DRM space, no form of digital rights management will ever work.  Ever. 

Just to share some findings on working with SharePoint features:

• The Elements.xml file that you include with your feature deployment cannot contain XML comments; if it does, you will encounter an error when you try to activate your feature using STSADM.exe.  Why?  Who knows.
• The <type/> element in the Elements.xml file, according to the schema documentation, can only occur once.  This seems to imply that you will need a different Elements.xml file to subscribe to each event type that you want to handle.
• And of course, Microsoft does not include the list of valid values (and if they do, it's not easy to find in the documentation).  Instead, I pulled the values using Reflector from the SPEventReceiverType enumeration.

The following is the enumeration listing:

public enum SPEventReceiverType {
    ContextEvent = 0x7ffe,
    EmailReceived = 0x4e20,
    FieldAdded = 0x2775,
    FieldAdding = 0x65,
    FieldDeleted = 0x2777,
    FieldDeleting = 0x67,
    FieldUpdated = 0x2776,
    FieldUpdating = 0x66,
    InvalidReceiver = -1,
    ItemAdded = 0x2711,
    ItemAdding = 1,
    ItemAttachmentAdded = 0x2717,
    ItemAttachmentAdding = 7,
    ItemAttachmentDeleted = 0x2718,
    ItemAttachmentDeleting = 8,
    ItemCheckedIn = 0x2714,
    ItemCheckedOut = 0x2715,
    ItemCheckingIn = 4,
    ItemCheckingOut = 5,
    ItemDeleted = 0x2713,
    ItemDeleting = 3,
    ItemFileConverted = 0x271a,
    ItemFileMoved = 0x2719,
    ItemFileMoving = 9,
    ItemUncheckedOut = 0x2716,
    ItemUncheckingOut = 6,
    ItemUpdated = 0x2712,
    ItemUpdating = 2,
    SiteDeleted = 0x27d9,
    SiteDeleting = 0xc9,
    WebDeleted = 0x27da,
    WebDeleting = 0xca,
    WebMoved = 0x27db,
    WebMoving = 0xcb
}

Of course, these values are in hexadecimal and for some reason, the <type/> element insists on the integer values.  So just be sure to convert the value to integer (try using Google for that).

Whoa.  This is a first:

I waked up this morning with some notices that new code has gone into our main repository.

So of course, I perform a checkout to get the new code and what do I get?  Argh!  The commiter added the _svn directories (possibly from a previous working copy) into the repository!  So of course, the checkout fails and I need to revert to a previous version.

Now I'm a little annoyed.

Then I go in and check the directories to confirm that indeed, the _svn directories were checked in like any other directory.  I also find that our naming rules, which I had thought we all agreed on, are not being followed.  In addition, we had discussed building all projects off of the main solution and building sub-solutions from that main solution trunk.

Nope.  We have a solution sitting in it's own directory.  To top it off, it's a solution file that doesn't follow naming conventions.

Then there are other various little things which just add to the morning frustration; the use of "Sharepoint" instead of "SharePoint", "Engr" instead of "Engineering", inconsistent naming of image files, the existence of an App_Data directory (why is there an App_Data directory in this solution???????), referencing obsolete libraries (I could swear we discussed this)...

These little things all matter in the end in creating a sense of professionalism and coherence in the final product when DLLs and classes are named according to guidelines, file naming is consistent, and spelling (misspelled words in code annoy me to no end) is correct.

Man, these things just grate me so much.  I dunno, am I just OCD about my code?  This kind of stuff just drives me batty.  It literally freezes my brain until the issue is resolved.  Nobody seems to care much about the artistry and craftsmanship that goes into their code...that is until we need to do a customer or partner facing code review, then the only code they want to put up for review is mine...

*Sigh*

So CNN has a video on the mythical Japanese Gyroball.

After watching this, I'm more curious about their dubious use of information from the Net.  From YouTube, specifically.  Uh, when did random people commenting on YouTube video logs count as newsworthy sources?  And when CNN pulls something like this, do they have to contact that commenter for permission to use the comment?

But in any case, speaking of the gyroball, for anyone interested, there is a great little (skit?) article over at ESPN by Patrick Hruby.

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.