February 2004 - Posts
This morning I found out that CodeAse, sells a tool, CodeAse 2.0, which is just LLBLGen 1.x but with different screencolors. LLBLGen 1.x is BSD licensed, but that doesn't mean you can simply rebadge it and sell it as if you wrote it! The BSD license clearly states you have to mention the original author of the work you use in your software in the About box and documentation. This didn't happen.
This apparently is the downside of releasing software under the BSD license: there are always lazy people around which just grab your hard work and act as if they spend 3 months of programming the stuff, because they didn't.
To all the people who want to purchase CodeAse 2.0: you can better get the free LLBLGen, it's the same code and it doesn't cost you a dime: http://www.sd.nl/software. To all the people who have already purchased CodeAse 2.0: you bought a product which violated the license of the code it contains. I'm not sure what that means for your situation, but if I look at SCO, I'd drop CodeAse on the spot.
I'm now almost done reading the docs of Subversion, and I can only say: this is open source done right, and when open source is done right, it's unbeatable by any software vendor. The system breaths quality, well thought out design and passion for software engineering. The documentation is very good, it reads like a novel. The win32 explorer plug-in (TortoiseSVN) is also very good, and offers a rich quality of services. Subversion has two more things to offer: it's free and it runs on a wide range of platforms (Win32, *BSD, Unix, Linux, MacOS X).
Often open source software is lacking in one area or the other: features are narrowed down to what the initial developers thought would be great, design is often applied 'ad-hoc' and documentation comes in the form of the sourcecode itself. Not with Subversion. The documentation, the installer, the amount of work that has been put into the design, it all screams: professional software. The quality it offers is the quality of a commercial toolkit.
I'm one of those happy few *knock on serious wood* who hasn't run into Visual Sourcesafe problems that often however some things get annoying: because of the big trees of code I have to work with, loading these projects into Visual Studio.NET takes ages. Three other things that get annoying (already are ;)) are: files are read-only on disk, merging back complete branches is a pain (you have to merge file by file) and I can't exclude one or two projects in my solution from source-control. Especially that last one is bugging me the most, because sometimes projects are completely created using code generation and I don't want generated code polluting my VSS database, since these might change often, creating lots of history records in VSS and which make the system utterly slow.
For VSS veterans, Subversion can be weird at first because it uses a different model for sourcecontrol: you don't work directly on the repository (lock a file there by checking it out, edit it, check it in), you work on your local copy and set commands there what should happen to the repository copy of that set of files and directories. However because the documentation is excellent, you are guided very smoothly through the steps of understanding this different model and you'll learn very quickly what the advantages of this model are and which pitfalls to avoid.
One thing subversion doesn't have is sharing: change 1 file and all projects sharing that file have the new version. This can be handy when you have a web project with for example asp files which is shared by a number of websites. It is a feature I use for my ASP 3.0 based administrator GUI for our CMS: every website has a shared copy of that administrator GUI, so keeping them in sync, sourcecontrol wise, is not that hard. You can of course work around this with the more advanced Subversion commands, but because the model is about local copies and not 'just' the central server, the actual sharing functionality can't be re-created for 100%. This is not a disadvantage per se, as VS.NET's integration with SCC providers is limited in this too: you can't simply share a project in your solution that's also in another solution: VS.NET gets confused and it results in having 2 copies of the same project in the sourcecontrol database.
Am I exited about this new sourcecontrol system? Absolutely. When the project just started, it was Linux only and I felt disappointed, however as it turned out, it's cross platform and works perfectly, no Cygwin libs needed, no gcc compiles required, it comes with a nice win32 installer and .chm packed docs. With this kind of quality offered for free on a lot of platforms, thus a lot of exposure, people who use it, advice others etc., it is a tough call for ISV's who try to make a living selling sourcecontrol systems. I hope for the fine folks at Sourcegear, their product, Vault, has enough USP's to keep them in the market.
This morning I was checking how my Xml serialization code was doing and I stumbled upon a phenomenon I hadn't seen before: the FullName property of Type will return a '+' instead of a '.' when the class is a private class. For testing I had defined some private classes and I set a property to an instance of one of those classes. My Xml serialization code will then add an Xml node with attributes for Assembly name and Type name. When examining the produced Xml, I saw:Type="DALTester.AdapterTester+OrderEntityValidator".
"Hmmm...", I thought. Examining my Xml producing code didn't give me the idea I had done something wrong, as the same code did produce correct type names for other instances and all it did was reading the FullName property of a System.Type object. After a while debugging back and forth it hit me: OrderEntityValidator was a private class! :)
So, if you run into this issue, it's not you nor your code, it's expected behaviour. :)
Consider the following enum definition (which is defined in a C# assembly)
public enum EntityState:int
{
New,
Fetched,
OutOfSync,
Deleted
}
OK, now, we have an object which has a property called 'State' and this property is of type EntityState. All great, let's set that property State to EntityState.New in VB.NET:
myObject.State = EntityState.New
Does this statement compile or not? I give you a hint: when I press '.' after EntityState, the intellisense of VS.NET does understand it's an enum and gives the 4 values possible.
No! It does not compile! I even have defined Option Strict, but the VB.NET compiler thinks I'm calling Public Sub New() on EntityState even though I have omitted '()' and the compiler comes up with this brilliant knowledge: "Type '...EntityState' has no constructors'. Gee..., really? Perhaps that was the reason I didn't specify '()' so you might already have known it wasn't a method call, it was an enum value specification, dear compiler.
I have to specify:
myObject.State = EntityState.[New]
What a magnificant solution... Instead of fixing the syntax once and for all: always require '()' for a method call, they opt for a horrible workaround: "add [] around the name that confuses the compiler". Apparently even though the compiler knows it's an enum type and the value is a value of that enum type.
Julien writes:
PSS is the first line of contact for issues and if you contact them and tell them about your issue we will look into it. If we have a hotfix available for it, even if the SP is not yet released, we will provide you it. If we don't have a hotfix and your issue doesn't have a good workaround, we will make a hotfix for you (that's how they get done usually).
Now, first of all, I'd like to say that it is great this facility is there. There are problems with this set-up however: the fix is not made public, other developers don't know about the fix and will spend hours debugging code that is not flawed. There is however another problem with 'hotfixes'.
Say, I develop a certain tool, ABC, using only .NET 1.1. During development I run into some issues with .NET 1.1. and it turns out .NET contains some flaws. After long debug sessions and Google searches, I'm totally desperate and call PSS. PSS walks me through the scheme Julien described and I get a couple of hotfixes for my problems. However this is a serious problem. How are my customers able to run my tool ABC if they do not have the hotfixes?
Am I allowed to distribute the hotfix to all my customers and demo-application downloaders? It's my understanding I'm not allowed to. If I'm not allowed to, do my customers have to call PSS themselves? If so, isn't that a little silly?
It's then far better to release a service pack, or a roll up, every month like the COM+ team did for years. Then, a customer of tool ABC can be pointed to the latest service pack for .NET 1.1. and there are no problems. That's support that actually works; the roll ups come with documented fix lists so they are easily findable in the KB search. Developers just have to install the latest roll up and they're set. Customers of tools like ABC: ditto.
I hardly dare to ask but: "Why is .NET support not like this and how are tool vendors able to solve this Hotfix problem?"
Jeff writes as a reply to my previous blog about Microsoft Support:
I found an actual bug in the framework (one of the RewritePath() overloads) and had a nice exchange started via the online support ticket system, finished by a member of the .NET team. It's one of three times I've had to contact MS directly, and every time my problem was resolved or at the very least explained. At the company level, I think they do a fine job.
The bug he talks about actually is fixed, in an ASP.NET hotfix roll-up (released june 2003). Now, I'm very happy for Jeff that his bug got fixed and the patch actually is released to the public and that the bug is documented in the knowledge base. However, are there any "hotfix rollup"s of winforms? Ado.net (I know the Oracle provider in .NET has some serious issues)? VS.NET designers? No.
While I can see the point of why Jeff looks differently at Microsoft's support, I hope he also sees how other people who have supplied perhaps a dozen bugs never got a reply back from Microsoft nor did their bug end up in the KB as being documented nor was there a fix released to help the developer and other developers. You see, there is nothing so frustrating as to find out after spending a lot of time debugging your software the framework contains a bug so your software would never work and the patch for that is not available.
I can live with feature requests not being granted, I can also accept that very silly little tiny bugs aren't patched individually and not before a next major release (like the winforms label text alignment misery), all fine. I can't live with the fact that I don't know about bugs being present and if they are recognized, that I can't download a fix so I don't have to write work-around code. The only resource helping the developer a bit is Google. If Google would die, MS developers would loose the number 1 source for information about bugs in Microsoft software.
Another reader, James Arendt, writes:
Microsoft could learn a thing or to from their competitors about providing useful access to bugs:
http://developer.java.sun.com/developer/bugParade/index.jshtml
http://bugzilla.mozilla.org/enter_bug.cgi?format=guided
I think this is the nail on the head. Developers are now left in the dark: "Is it a bug in my code or in the framework?" in other words: "Should I spend a lot of time finding this bug, while it could be in the framework?". You can't tell if it's in the framework other than to really spend that time. The frustrating part is that you probably are the 24,789th developer doing that. But you don't know that. You could search in Google groups, and often it offers you postings of fellow developers fighting the same issue, sometimes there is a workaround posted, but not in all cases. When you finally find out it is the framework and you report the bug, 10 to 1 you never ever hear from Microsoft (it happened to me 10 out of 10 times), left alone a patch for your problem.
Apparently Microsoft is very afraid of what we, customers, might get to know about the real quality of their software if the full bug database is exposed. If not, why isn't the bug database open for us, customers? Why do we, developers, have to fight with unexpected behaviour while it might be caused by a bug in the framework? Or does Microsoft think "Let Google serve them"? I hardly doubt that.
There also seem to be two types of support: the freebee give-away support and the raw 'product support'. I don't see them as two things: the customer buys a license of a product, he expects a given amount of quality, which includes support. As the producer of a piece of software you might think that giving a lot of freebee give-away support is helping customers enough that they think they got enough support for their money, but that's a skewed view on reality. Support is about helping someone. Support also means that if you as a producer, scr*wed up big time because you included some bugs, you have to fix them to give the customer the quality the customer thought he/she bought. But perhaps I'm thinking in weird ways. I've always learned that if you sell something you have to stand by the quality of the product you are selling, and if the product apparently isn't of the quality you think it is, you should do everything you can to make it the quality you think it is.
Microsoft can give away as much examples and free beta's at a show like Devdays (which was mostly about what will come and not about today's technology), that doesn't make up for the total lack of fixes for products like Visual Studio.NET and also .NET 1.x. because when you get home after visiting these shows, when you finish reading the examples, the hard reality of today kicks back in and won't simply go away: you have to finish the software you are working on with the technology available today, you can't do that with technology which isn't available yet, so it does hurt every day's work when fixes are not available, when essential bug information is not available. The KB has a page with .NET bugs listed. It's the same page as 6 months ago. Are all bugs ever found in .NET 1.1 on that page and in the last 6 months there haven't been found any new bugs? How naive must a person be to buy that? After all, the bugs I found are not on that list. Does it mean those bugs do not exist, or does it mean the page is outdated?
If this is the kind of support that is the best of the industry, I really feel sorry for the customers of competing products. Microsoft, you have the resources to do something about it, why aren't you doing something about it?
Alex Lowe wrote a blog about Microsoft and developer support. In there he ventilates his misunderstanding about a blog Roy wrote about information sharing.
In the blog, Alex writes these remarkable words:
I believe Microsoft has the most comprehensive developer support in the industry with its tools, paid support options, free support options like MSDN, and volunteer community (MVPs, 3rd party websites, etc.).
I was stunned when I read that. So I re-read it, and again, punched my arm to see if I wasn't dreaming, but it was real, it was there right in front of me.
Let me tell you, Alex, Microsoft's developer support sucks. Big time. Not because the large legion of support personnel is badly trained, not available, not working hard enough or giving the wrong answers. It's because Microsoft doesn't understand the difference between marketing and real support. It's because Microsoft has it's priorities set totally wrong so good support is impossible.
Because we're talking about developers, I'll give you a small list of developer-oriented examples why I think Microsoft developer support sucks big time.
- There are no patches released for Visual Studio.NET 2002, even though Microsoft promised a service pack for VS.NET 2002. It turned out people had to upgrade to Visual Studio.NET 2003, which always costed some money.
- There are no patches released for Visual Studio.NET 2003 up till today, while Visual Studio.NET 2003 is full of bugs (and if you don't believe me, read the newsgroups: locked assemblies during compile, project lists on the startup page, the totally unusable HTML editor, dying intellisense in C# in some situations etc.). Microsoft has officially stated earlier that for example the HTML editor can't be fixed in this version, so every user of that HTML editor for ASP.NET pages is out of luck and has to wait till Whidbey is released. If you think this is a small group, you're mistaken.
- Where's the service pack for .NET 1.1 to fix the bugs and issues with that .NET version? If you think there are no bugs in .NET 1.1, you are mistaken.
- It's nice to read about the new things in Whidbey, but we need solutions today, for issues bugging (pun intended) us today. I understand Whidbey is a big thing, and a lot of resources are put on that project, however why is it so hard to give users of the current version patches for issues they run into every day?
- When a bug is fixed in for example Windows XP or other technology, it happens a lot the patch is not directly released to the public, but can only be retrieved through PSS or through a service pack. For the people who do not know it, the CDSYS filesystem driver to read CDRom's on a windows PC has a serious flaw: it doesn't cache paths. This means that when you are installing Visual Studio.NET from CD it will take ages because of the small directories with all the examples, which make the CD read head to step from index to folder to index to folder etc. which is utterly slow. Microsoft has patched this for Windows Server 2003 and it will be released in Windows XP SP2. Is this patch available to us, developers, so we can install Visual Studio.NET faster from CDRom? No. This patch is already finished for some time, however we have to wait till Q4 2004 till we can use it. Who can still say this is the best support you can get from a software company? I think you're mistaken, Alex.
- I read various newsgroups on the MSNews server, every day. Some newsgroups are apparently read by Microsoft personnel because they posts there, answering questions, however for example the ADO.NET newsgroup seems to be "off limits" for support personnel. How come? Does Microsoft think questions related to ADO.NET are not worth replying to? And why are 90% (I estimated this rather low) of the questions in the Visual Studio.NET newsgroups left unanswered by Microsoft personnel? Are these questions not worth answering?
I think you, dear reader, got the picture by now. Sorry to gripe about this, but I have the feeling too less people really think through what Microsoft actually does for support to the developers. Again, I'm not saying individual employees at Microsoft do not work hard enough or are not skilled enough to help developers out there, it's the organization Microsoft itself which makes the mistakes here. Therefore I'd say: Alex, your statement is wrong. Support is not about tossing out some basic examples, which are nowadays also a lot about Whidbey, but about solving problems too.
Support is part of the quality of the software. For starters: that means that people who buy your software do that because they expect quality. How Microsoft treats developers at the moment is the same as a second hand car salesman selling you a bad car with no warranty: fixes not included.Microsoft, you're clearly in denial about the state of your developer support.
Jimmy Nilsson blogs about AOP, or Aspect Oriented Programming.His article combines some different insights on the matter, good links to articles about AOP and is a good starting point for the people who have ignored AOP for a long time and find this the right moment to get started with AOP and what the fuss is all about.
Personally I think AOP has a lot of potential and with the right tools it is in my opinion a technology which should be on everybody's mind when they're designing their software.
Ralf Westphal has written an excellent article about Objectspaces and orthogonal design. Highly recommended food for your mind.
More Posts