October 2004 - Posts
Note: this entry has moved.
ClariuS already has a big fan:

Note: this entry has moved.
The conference has been great. We're approaching the end, and I have to say I'm very satisfied. Even if I was one of the speakers, preaching the benefits of
Schematron (which went pretty well I think), and therefore didn't have to pay to be here, I'd have gladly done so. The level of talks is high and you get to meet a lot of cool guys from the entire XML space (definitely not only MS guys). No marketing, no beginner's topics, just XML and fun.
If I don't have some really exciting topic to talk about next year that Chris is willing to have on the conference, I honestly expect to be able to come back as an attendant. It's really that good.
Well done Chris!
Note: this entry has moved.
If you get
this face when you explain what you're using XML for, you will know you've not passed the test....
Note: this entry has moved.
The
one bug I wished was never fixed in VPC has been fixed in SP1. And you need SP1 in order for VPC to run fast in WinXP SP2. Damn!!!!
I'll investigate working with VPC without SP1, and using the addons from Virtual Server 2005, which used to work before....
Note: this entry has moved.
The XmlSerializer has a farily well-known problem: the first time you use it, it will generate a class to read instances of the received type, compile it, and then load it. Of course, this can take considerable time, directly related to the complexity of the type and all its members and member types.
Unlike common wisdom, this is something that can be avoided and I have explained (albeit rather confusingly) in a
previous post. The usage was not great, though, as it was a command-line tool: ouch!
So, the
Mvp.Xml project debuts with a new package:
Mvp.Xml.Design. Now, in order to get a design-time version of a custom XmlSerializer for a type, you just assign the Mvp.Xml.XGen (renamed from the old SGen name that could be confused with a Whidbey tool of the same name), and you'll get a class to perform serialization of the type. The custom tool will take the first type in the file if multiple classes exist in it. Here's how it will look like:
The package comes in two flavors: an MSI installer or the raw source. The former also installs the sources besides the custom tool.
Go download it!
Note: this entry has moved.
A couple months ago I posted about a major regression happening in ASP.NET v2. It's amazing that even after an overwhelming difference of 10 to 1 people voting to keep the Components tray in the designer, which allowed wizards, designer verbs, and extender providers to provide an incredible powerful enhanced visual experience in the IDE, Microsoft decided not to fix it.
So, you can kiss bye-bye to your UI-technology agnostic components and IDE integration. You'll have to keep two codebases and use the ugly gray-rendered "controls" (can't understand why you have to inherit from Control or WebControl if you're not doing any UI stuff, and why it has to live in the HTML design surface). A huge step backwards in what seemed to me like an important evolutionary step towards software factories based on highly reusable components.
They definitely ruined my day. But I plan to publish an extensive article of what you'll lose, and all the features you can exploit from this powerful model. Hopefully, if I get enough developers to use it, they will put more effort in bringing it back.
Note: this entry has moved.
The more I use Test Driven Development (TDD), the more I learn that I must not trust myself. You see, before TDD, I used to develop big chunks of applications, doing some minimal (relative to TDD approach) testing from the end-user perspective. This approach to app development assumes you trust yourself in the code you write, as you know what you're doing, right? Well, my experience (and a lot of other's too) tells me that a huge number of subtle and hard to repro/track bugs can result from this approach (specially if they happen deep inside your libraries). (not that I've discovered anything new, of course....)
The more time I spend using TDD, the less I trust in my coding. I've found and fixed lots of bugs in my code before even checking the code in the repository. So, unless I have some NUnit tests that tell me from **outside** my code (the code I'll deliver for production, actually) that what I did actually works as expected, I do not consider the code to be trustworthy. Initially, it seems as it slows down your productivity, as I tend to spend an equal amount of time writing tests as writing the actual features. But in the long term, the code is much more robust and stable, and you can always do some refactoring without risking the entire project. The tests ensure you don't break other parts of the product.
If you're not doing TDD yet, you're really missing something...
Note: this entry has moved.
Read
this entry where Scoble uncovered the secret, and if you need to, follow
these detailed steps. BTW, once you grabbed the newer VPC additions from the Virtual Server 2005, you can just uninstall it and continue working with VPC 2004 as usual.
More Posts