July 2004 - Posts
When is a bunch of people actually a community? I started thinking about this a couple of days ago mostly out of disappointment with the product feedback center. Last wednesday I commented about how a suggestion of mine was closed with the resolution By Design, after which it was promptly re-opened only to get closed again with the same resolution, only rephrased as Won't Fix. Now, this didn't disappoint me because I want Microsoft to do whatever I suggest, I've done too much development using other people's frameworks and middleware to know that you'll never get what you want, but because all I really wanted was an explanation about why it's not going to be implemented. What was done now is basically update the issue to thank me for my input twice. I don't suggest things to be thanked. In fact I'd rather be called a complete idiot for even bringing it up, if at least someone would tell why it's so stupid of me to suggest it in the first place. In a way it's those interactions that create a community: they educate members on how to interact and play by the (unwritten) rules.
Another example is related to a bug I filed, which was closed again with the usual thanks from Microsoft and the information that this issue is already fixed as part of fixing 273102. What is 273102 anyway? Searching for it in the product feedback center only gets me my own bug, clearly because the number is mentioned there. Searching for 273102 on Google gets me all kinds of interesting stuff, but nothing related to any TabControls, Windows Forms or the .NET Framework. So perhaps this is some internal issue numbering system? Which is exactly what I don't like about it: instead of becoming part of the community around its' products, Microsoft is basically just allowing people outside a quick look at what's being done inside, without any actual interaction. Which is another fundamental thing to community-building: the members must actually be involved in what's going on.
I'm not bringing up these things because I enjoy whining about Microsoft, in fact, after doing work on a couple of opensource projects and even dabbling in the Java world a couple of years ago, I'd say that the community around Microsoft is one of the more welcoming and friendly places around. I spoke to a lot of people at TechEd about a month ago, both from Microsoft and independent and had a great time. I visit dutch usergroup meetings and am generally quite happy with the effort everyone's putting into the community. But still I feel that from Microsoft's side, a lot more can be done.
The reason opensource projects are getting so much attention, specifically from developers, is because they make them feel like a part of something: instead of buying a piece of software and then having to deal with uncooperative support people, they can e-mail the author directly, create some changes they personally want and even get called names when they submit patches that contain new bugs. It might sound strange but the reason that kind of hostility doesn't really hamper those projects is because the people involved see those projects also as their own, so they get motivated to do better, because they know that in the end, what they do does actually move things forward. If Microsoft wants to create that kind of warm and fuzzy feeling among the developers using their tools, they somehow need to make people feel the same way.
I filed a new bug regarding the standard Windows Forms TabControl which is something I ran into with .NET 1.1 and somehow still hasn't been fixed. My other TabControl-related suggestion is now officially resolved. What's funny is that the resolution is By Design, which is kind of strange on a suggestion. I mean, what does that mean when you're talking about a suggestion? The fact that I was filing my issue as a suggestion shows that I'm aware of the fact that it's currently working as planned, I was merely suggesting that it's made a little more workable. So I guess the only way to interpret a By Design resolution on a suggestion is by reading it as Sucks On Purpose.
Perhaps I should suggest a couple new resolution types instead? I'm just a little afraid of how that will be resolved. Anyway, after a week down with the flu and then having my DSL disconnected for nearly the entire next week, I hope to be a little more active again.
In .NET 1.x, disabling a TabControl's TabPage is awkward at best: setting its Enabled-property to false doesn't disable it, instead it disables all controls on it. The MSDN solution is even worse: use the SelectedIndexChanged-event to check whether the tab is available and if it's not, send the user somewhere else. Regardless of whether the approach works, the result is ugly because the clicked TabPage does appear, so when a tab ends up not being allowed, you see it flashing by. It's also questionable from a usability perspective, because if the tab looks like any other tab, then shouldn't it work like the other tabs?
Another often proposed way to disable a TabPage, is to remove it (temporarily) from the TabPages collection the TabControl has, so it disappears entirely. I don't like this idea, especially since I've actually implemented it once this way and users kept calling me asking where the tab went. It seems that if users are looking for a tab they can't find, they'll assume it's somewhere else and they simply can't find it, instead of concluding that perhaps they can't use it right now. Which is a reasonable conclusion, because whenever I want to configure my TCP/IP in Windows for instance and I can't find a tab, I'll just look around to see if perhaps it has been moved or perhaps I didn't remember where it was in the first place.
So what is the way to disable a TabPage? I think the best thing to do is pretty simple: grey the text and let nothing happen when you click it. Basically the same way every other control is disabled in Windows. Anyway, I thought of this today because I was using a TabControl in a small Visual C# Express Beta 1-project and unfortunately, everything still is the way it was. Let's hope my feedback helps!
It seems the VS 2005 Beta 1 still hasn't been released. Not that I particularly mind if it's delayed, but the subscriber downloads on MSDN does list the Beta 1 as available but it turns out, according to Peter Van Ooijen, that it's just a rename of the original preview release. What's weird though is that the MSDN post about VS 2005 suggests that it's available as well. I heard about some delay at TechEd, but when you see something called Beta 1 posted you sort of expect it to be solved.
I just hope there's some clarification when the actual version gets put online, since it's no longer discernable from the filename. For all I know it was just a temporary mistake and the real beta has been available for a couple of days! At least the other people here at the office will be pleased, otherwise I would have downloaded the 3.5GB right away and hog their bandwidth for the afternoon :)
Update: Because of some feedback in the comments claiming that the current download is the actual Beta 1, I will be hogging some bandwidth today. Thanks!
Last friday, on TechEd's final day, I decided to visit some alternative sessions during the afternoon. One of them was a session called The Nerd, The Suit and The Fortune Teller by, respectively Clemens Vasters, Rafal Lukawiecki and Pat Helland. The format was basically one big discussion between a software developer, his manager and an oracle, or let's say an expensive consultant. The point of the session was clearly to get across the concepts behind the Service Oriented Architecture (I can't believe that they've now gotten me to the point that I'm writing about SOA on my weblog!) The manager was complaining about wasting lots of money on information technology without ever getting a proper return on investment while the developer was frustrated by the manager's inability to understand the underlying complexity of what he's asking from his developers by constantly changing requirements. The fortune teller attempted to get them to accept a new look at the way they use and develop information systems to make both their lives easier.
This session was good because it touched upon all the typical frustrations that both managers and developers have with eachother. Furthermore it gave me a good idea of how Microsoft sees the Service Oriented Architecture. The point appears to be that instead of trying to define fairly abstract requirements based on all processes, communication and datamodels inside an organisation and then turning this into one huge system, instead you first define all the different processes, or departments if you will, and then create a relatively smaller system for every one of them independently. Then you let them communicate across a service boundary (i.e. they send XML messages to eachother, although the implementation of that is ofcourse arbitrary). An important aspect of doing it this way is to ensure that you seperate all the information and responsibilities appropriately, otherwise you'll end up with similar problems as in the original approach. The advantage would be that this hard seperation and forced communication through messages makes it easier to modify these seperate systems.
During the session I definately liked this concept and even though I still do that, I'm not sure whether I truly buy into it as a solution to most of the traditional problems. In the traditional approach, you're supposed to do so-called subsystem decomposition which seperates the different responsibilities of the components making up your system. Also, after getting all the information that's floating around in your organization together, you normalize the datamodel so that all pieces of information that are supposed to depend on eachother do so in the most efficient and correct way.
All in all what it comes down to for me is that SOA makes sense if your developers are unable to properly create a system that accurately reflects your organisation's subsystems and datamodel. Still, if in practice people have a hard time to properly do this because it's simply too easy to make mistakes, then ofcourse it's a worthwhile approach to make it easier to do the right thing. I just wonder if people won't end up with services that are so focussed on the communication with the other services they were developed with, that adding a service will end up being just as complex as it used to be.
It's the final day of TechEd Europe 2004 and even though I still have a couple of sessions to attend, I can say it's been a very interesting and fun week! Most of the sessions had some really cool content, although I personally would have liked to see a couple more advanced level sessions (or at least not have those that are held be planned in the same timeslots). This morning I went to Visual C# 2005: Language Enhancements, presented by Dan Fernandez, the Visual C# product manager. First of all I'd like to say that he's a very good speaker, the session was very quick-paced (mostly because there was so much ground to cover) but never confusing or unclear.
The most important thing and because of that discussed in the greatest detail were ofcourse generics. Because of their significance I had already read some articles about them (such as Jason Clark's two articles in MSDN magazine last year) so that contained little new information, especially since I've already been playing with them for the last couple of days with the Visual C# Express beta. Still, the part about constraining generic types was new to me, but besides that it was good to get another overview with live samples
Next was a discussion of anonymous methods which will fortunately end the relatively large amount of code needed to create simple eventhandlers, although one of the examples contained an entire inline method, about 10-15 lines of code, which would be a bad idea to actually use I think, because those things don't really make code more readable. Mostly because the idea of methods-within-methods are fairly unknown to programmers of other regular languages (C++/VB/Java), so that would make reading C# more difficult for non-C# developers.
Then there was a discussion of nullable types, iterators (of which the new yield concept made me think about co-routines), property accessors, static classes and fixed-size buffers, which all sound like great new additions, even the namespace alias qualifiers.
One thing didn't make me happy though, which is partial types. I really don't see the advantages in having them. For instance, you might say, it moves the generated Windows Forms and Web Forms clutter into another file so you don't have to deal with them in your main sourcefiles. Well, there's actually this cool #region feature the IDE supports that lets you collapse them. In fact, all the generated code (also for stuff like interface implementations) is always put into collapsed regions by default. However, I do often use some other editor when looking at other people's code or to quickly try to understand something in a class by opening it in some text-editor and searching for a methodname. No longer can you rely on finding it because it might reside in some other file which contains another part of the class you're looking through. How to figure out where all parts of a class actually are? By forcing some naming convention on files? That would be a step back (towards Java) so that doesn't sound like a good idea.
What I disliked the most is that the session demonstrated that the VC# IDE is totally capable of dealing with multiple files that contain a single class like they're all together in a single file, which means Microsoft has invested quite some time into developing this, even though it adds absolutely nothing on a functional level. But hey, if everybody wants it, I suppose I understand it would get implemented eventually. Personally, I think I'll stuff all the generated partial types into std_afx.cs, along with the new no-warning-policy-evasion mechanism with #pragma.
I've just submitted my first Visual C# Express Beta 1 bug! It has to do with automatic formatting, for which there are luckily lots of options in this new version. I barely customized anything though, because I'm very much used to the way VS.NET 2002 and 2003 do it by default. Today was the first day that I've actually been playing with the VC# Express Beta for a bit, something that I'm very happy with is the ability to reference executables (instead of just dlls as was the case in the previous versions).
I was actually wondering why referencing executables is not allowed in the earlier versions and I suppose it's because it's better to have shared functionality seperated from regular application logic that resides in the executable. However, I found this to be pretty uncomfortable because besides an interface library that's in a different assembly, there are often some additional classes that are versioned along with the main application but that are used in related applications. For instance a bunch of base classes used in plug-ins. You can include them in the interface library but personally I'd rather not have code in there with the interfaces, forcing me to make multiple class libraries to distribute an application, some common classes and an interface library.
In the meantime I'm still at TechEd Europe and during this morning's .NET Versioning session by Juval Lowy, there was mention of a new attribute, InternalsVisibleTo, that allows assemblies to reference classes marked internal in other assemblies. I think this is a pretty cool addition since besides default internal behaviour, classes can now be made internal on an application or even vendor-wide basis (although that last will be a hassle to accomplish).
Something else that I found to be pretty cool was that during Peter Sollich's CLR - Under The Hood session, he showed some IL code that was originally compiled from C# that had some pretty strange instructions around the end of a method: popping a value from the stack, branching to the next instruction and then pushing the value back on the stack again. He called this "C# compiler stupidity" which was quite a relief for me since I've been wondering about code like that for a while. I actually noticed code like that in examples in both Inside Microsoft .NET IL Assembler and Shared Source CLI Essentials which both didn't really explain where this code came from.
In the meantime it's about time for the TechEd party, so I'd better go and see what's happening!
More Posts