Where has TimeZone2 class gone?

If you are following blogs about .net 3.5 you might have across this interesting post. It explains the benefits of new TimeZone2 class residing in .net 3.5 System.Core assembly. The best feature of TimeZone2 for me is the ability to convert time from and to different time zones. Perhaps it is worth to mention that dealing with time zones (read: dealing with daylight saving time) is something I would really like to avoid. Unfortunately world leaders don't think so and they are not just keeping up with daylight saving times, oh no, they keep changing the rules often, just to make it worse.

Before TimeZone2 was introduced one had to do the conversion between different time zones manually - as old TimeZone class knows only to transform from/to current time zone (ToLocalTime, ToUniversalTime). So, hura, for new TimeZone2 as described in the post mentioned above. I'll just use it.

<few minutes pass>

Hm, where is TimeZone2? No sign at all of it. Even reflector can't find it. After a little more reflectoring (using clues that TimeZone2 resides in new System.Core dll under namespace System) I've soon found the best new class that resembles the TimeZone2: TimeZoneInfo. Perhaps this change is mentioned somewhere, I just couldn't find it.

To make it short: if you are looking after TimeZone2 you should use TimeZoneInfo instead, the swiss knife like tool for dealing with time zones - this is what TimeZone should be from the beginning.

UPDATE: Here is a post that mentions renaming of TimeZone2.

LINQ to SQL showstoppers

I have to say that I like LINQ to SQL, heck, I even do presentations about it. So, it is a cute ORM. What is that good about it features LINQ. However, there are some serious showstoppers in there. One are more serious than the others. I won't deal with what's good about LINQ to SQL, rather I'll dive into showstoppers as I see them. So, let's take a look at them:

  1. Support for SQL Server flavors only, not even Katmai (SQL Server 2008).
    This might or might be a showstopper for you. One of the great advantages of ORM products is that they are abstracted from database, meaning the same code works with different supported databases. You probably won't write an application that is totally abstracted and you'll have to write few database dependant stuff but it is still true for the majority of the code. So, why would I bother learning an ORM that deals with SQL Server only when I have plenty of other ORMs that supports a bunch of different databases? Why would I bother to tie my application to SQL Server only when I could have an application that works with all the major databases out there?
  2. Poor n-tier support
    A good ORM would let you send all the modified entities to the server tier with a few of method calls and store changes to the database with few other method calls. But not LINQ to SQL. Oh, no. Doing n-tier with LINQ to SQL requires a fair amount of coding and lot of manual work that should be done by LINQ to SQL itself. IOW LINQ to SQL is very client-server oriented. Looks like n-tier was added afterwards.
  3. Designer that doesn't sync with database
    Imagine you have a Context with myriad of entity types on it. That's very messy by itself since you can't isolate a certain set of entity types you might be interested in but you always have to look at all of them. But that's not the real issue here. The real problem arises when database metadata changes (right, you always define your database structure in stone before you start coding and you don't modify it ever) - perhaps this is a bad project management, but it does change through the life of the project. And when it does, LINQ to SQL won't help you modifying the Context. Nope, you are on your own. So, you can recreate the context manually and reapplying all the modifications done to it (you are certainly looking forward to this) which is not only boring, but error prone, too. Or you can manually sync the Context with database which is not that boring but error prone and tedious. So, this one is a huge showstopper if you ask me.
    Luckily there is [CodeSmith] with its PLINQ templates that supports database synchronization. While not a perfect solution it solves many problems. Furthermore it allows you to modify the templates to your requirements - IMO the [CodeSmith] path is the only path if you are serious about LINQ to SQL.
  4. No source code
    [MS] is probably releasing LINQ to SQL source code, but even if they does, you won't be able to fix problems as you can't modify it in any way. Not a big problem.
  5. Slow development cycle (tied to .net 3.5)
    If you need a fix quickly you will have problems as LINQ to SQL is part of .net 3.5 framework. And knowing the speed of [MS] applying bugfixes it might take years before official update is available.
  6. No direct execution against database
    Imagine you have a task that has to update all item prices for 10% for whatever reason (it acually happened last month in Slovenia for bread and milk items). All orders have to be fetched from the database to the application, each order has to be properly update in application and all of them have to be persisted back to database. Right, you can't execute the operation directly against database from the code. OK, you can issue a SQL statement or use a stored procedure but the former breaks strong typing (SQL statement is a string, compiler won't help you catching the errors) while the later is unnecessary burden.
  7. There is plenty of better competitors out there
    Apart from the (obviously) LINQ advantage there is plenty of better and proven ORM products out there. Even the LINQ, major LINQ to SQL's advantage will soon be integrated by the competition as some of them already feature LINQ (to Entities) while others will soon.

Again, don't take me wrong. LINQ to SQL has plenty of good features. It is just that it has too much of show stoppers for me and knowing problems of certain technology before using it is usually a valuable knowledge. So, what can you do? Pick an alternative of course, either one of commercial or free 3rd parties or wait for Entity Framework which will see light next year, sometime after .net 3.5 RTM.

What will I do? Actually nothing. I am very happy with [LGP] that is much superior to LINQ to SQL except for the LINQ. Also [LGP] is getting LINQ support supposedly this year so it shouldn't be long before I am be able to happily LINQing with ORM.

And let me know if there are other problems you foresee with LINQ to SQL.

The unknowns of .net 3.5 framework library source code licensing

Frans has an interesting post (and an update here) regarding .net 3.5 framework library source code licensing and he is raising an interesting question: "Should we look at this source code or not". AFAIK he is the only blog poster so far that is concerned with [MS] .net 3.5 framework source code hot topic. All the others, including me, is very happy to see this happen. So, should we have concerns, too?

Well, yes and no. First, Frans is developer behind excellent [LGP] ORM that will be a competition to [MS], once .net 3.5 is released. Actually [LGP] will (future tense because none of [MS] products is out there yet) be superior, except for LINQ integration, to both [MS] products: LINQ to SQL (which is very limited anyway) and Entity Framework (whose release data is unknown, but after .net 3.5 RTM for sure). So, he is not a typical developer like you or me, he is a component developer and he competes with [MS], or better, he will compete. So, he has to take in account any possible drawback for looking at .net source code and his concerns are legitimate - who says [MS] won't try a legal action against competition based on .net source code license agreement?

Next, I doubt that anybody actually understands the licensing. That's because licenses are written in legal dialect which is unreadable to humans and understood by few lawyers at most. And even those lawyers understand it differently. A good example is TestDriven.net saga. So, forget about common sense and hire a bunch of good lawyers if you want to have your back partially covered - afaik there is no other way to understand the license. You can't ask [MS] whether you can do this or that - they will redirect you to your lawyer(s). And if you are dealing with [MS] lawyers you would probably need many of your lawyers - the more the better. As per us, "normal, non competition" developers, I don't think this is a problem in real world nor will [MS] bother.

Frans also says that looking at reverse engineered code (i.e. Reflector output) isn't the same as looking at source code. Actually, looking at reverse engineered code might actually be worse. I don't think anybody is allowing anybody to reverse engineering the code in the beginning (big brother doesn't yet have cameras at our work places, so it is tolerated for now). Anyway, looking at or using reverse engineered code sounds same to me as looking at or using source code. If there are patent issues it won't matter where did you get code from.

True, you can only look at the source code and not touch it or use it. I am going to say: at least I can look at it. I didn't ever think to modify the .net library anyway. But then I can't fix the bugs that I am having problems with (assuming I would know how to fix them). True, but knowing the enemy is half of the victory - IOW if I understand why the bug happens and what's going on behind the scenes I might be able to create a workaround. Next, there is no better documentation than source code. Period. And comments are even better - a cherry on the cake (who knows what they'll look like). And ability to step into the methods is very good, too. So it does solve real problems as it did Reflector. If we'd be able to temporarily use (in the case of [MS] bugfix cycle this means at least 3 years ;-)) recompiled assemblies for our own application it would be even better. But heck, even releasing source code took many years. Less restrictive licensing might take next n-years but it might happen as well. If the demand is there of course.

The bottom line is that Frans is looking through eyes of the competition developer and he has to be prudent in what he does. While for the rest of us, source code is still a great benefit, and I don't think there are real problems as long as we don't do anything really stupid. Take also note, that I am not a lawyer nor I did read [MS] Reference License carefully so my opinions are opinions of a developer.

Post CodeCamp impressions

On saturday I held a speech and co-host a "round table" at CodeCamp in Zagreb in front of a crowd of ~60. My presentation was well received and understood (at least I was told so) even though my Croatian is not perfect - English and hand gestures helped. The entire event was at high level with world-class speakers (not counting me in this category) worth attending.

And I have to tell that community in Croatia is amazing. They are passionate, communicative, skilled, some of them came even from Dubrovnik (500km) or Slavonija region, and  lastly, they are willing to sacrifice entire warm sunny Saturday for an indoor event. OK, they got plenty of very useful swag, but still, they were there for the content. It is a pleasure speaking for such crowd and among great speakers.

Speaking at CodeCamp in Zagreb, Croatia

CodeCamp2007Banner I am pretty busy lately and also have been attending CEE MVP Open Days 2007 summit in beautiful Cavtat right next Dubrovnik in beautiful warm weather. Nevertheless I've found enough time to (re)deliver LINQ to SQL presentation and co-moderate ORM - hero to zero round table on Saturday, 29th of September at CodeCamp. The event will happen in [MS] Hrvatska building located in Zagreb, Croatia.

I have to say that this is my first engagement in non-native and non-English language and I am curios whether attendees will understand me at all. See you in Zagreb!