February 2003 - Posts
The more I use Remote Desktop on XP, the more it pains me to go back to VNC. Not that I don't admire VNC - it's a phenomenal tool, especially if you need to go cross platform (where cross platform can mean as little as "not XP"). Super light-weight, super easy to install (and the viewer piece doesn't need an extra install at all - in fact, it's entirely optional if you want to use the web browser client). But the seemlessness of remote desktop can't be beat. As a heavy keyboard user, I find VNCs less-than-complete support for keyboard navigation problematic. I need my Alt-tab and Ctrl-Esc, dammit! Also, the full screen mode of RD makes the illusion of local access nearly perfect, and the ability to easily share local resources with the remote machine is very handy.
Now if only XP Home supported it so I could do proper remote tech support for my parents.
Here's another example a Microsoft "what were they thinking" decision. When I first started looking at the generic databinding architect in the control framework, I thought "wow, this plus web services could be a pretty killer combo". Web services can return collections of "objects", and the controls can bind directly to them - what could be easier? That would make snapping together simple web (or win) applications a piece of cake.
Bzzt. Sorry, wrong, thank you for playing. The proxies generated by WSDL.EXE expose their information as fields, and the databinding stuff only looks at properties. Totally incompatible. What's up with that? Is it an example of the left hand not knowing what the right is doing? Or maybe Microsoft is still too wrapped up in the DataSet world (generally DataSets are pretty crappy for web services). I don't know, but it was a seriously lame decision.
Now, it turns out that there is a partial workaround. Some of the controls (the grids, in particular) will look for an interface called ICustomTypeDescriptor during databinding. If it's implemented, it will use the methods of that interface to retrieve the property information for the object rather than using reflection directly. I was able to put together a generic adapter class that reads a class' fields and exposes them as properties through ICustomTypeDescriptor, and it worked. But not all of the controls use that interface (I've found that the combobox definitely doesn't). So it's a partial solution, and one that shouldn't be necessary. It's not fixed in the framework 1.1, but I'll hold out hope for 2.0.
Microsoft has a madding habit of getting things 99% right, with the last 1% making it impossible to do what I want to do. It drives me absolutely bonkers some times.
Case in point. I'm working on a set of ASP.Net server controls. Being a good little XP programmer, I want to write unit tests for the controls. I'd rather not require a real web application to host the controls in order to test, so I figured I'd create my own subclass of Page that can simulate the lifecycle of a server control. Seemed like a reasonable idea to me. After all, session data, viewstate, form data - they're all just name/value pairs, right? Not too hard to save and restore as needed. I figured I wouldn't be able to test every bit of control functionality this way, but I should be able to test a lot.
It didn't take very long before I hit an impasse. About 5 minutes, actually. One of the controls has the option to use session state for data storage. When a new Page object is created, its Session member is null, and there's no setter for it. Aha, I think. the getter is virtual, I'll override it and return my own HttpSessionState object. Wrong. The HttpSessionState class is sealed and has no public constructor. Heck, HttpSessionState doesn't even implement IDictionary, so I can't treat it generically. So I'm stuck.
The Sealed Sucks thread on Chris Sells' Spout has a rousing discussion on the topic of sealed classes in the FCL. Obviously Web Forms is just as prone to this as Windows Forms.
Oh, and by the way, isn't ASP.Net session state a perfect example of where interface-based programming makes sense? Hmm...state information that's presented in a consistent way but with multiple options for backend storage - in-process, state server, and sql server. Why on earth would they elect to make a monolithic class that supports all three options? Can you say "pluggable session state back-end"? I guess Microsoft can't. So much for the idea of session state stored in an Oracle server.
Anybody out there writing unit tests for server controls? Care to share your strategies?
I have a major spam problem at work. I get a ton of it. Recently I discovered Spammunition - a free Outlook add-in that uses a Bayesian filtering system to catch spam. It rocks - great filtering, very low false positive rate. It's still pretty early beta stuff, but I couldn't go back to life without it. Highly recommended.
http://www.upserve.com/spammunition/default.asp
Mini-rant: What's the deal with Hotmail? I have NEVER used my hotmail account for any emailing of any kind (I just got it for MSN Messenger), and yet I get loads of spam there. That pretty much guarantees that I never will use it for email. Microsoft, you may want to work on your spam filtering engine (or just license Upserve's code). Neither my Yahoo nor my Earthlink accounts have anywhere near the spam problem that Hotmail has, and I actually give those email addresses out.
Oh, the first rant. Where to start? First of all, let me start with a disclaimer. I make no claims of original thought here. Undoubtedly, whatever I rant about has already been ranted about umpteen times over elsewhere. I will certainly try to give credit where credit is due, and will link to other blogs or pages on the topic of my rants. If I don't, I'm not trying to rip of other people's ideas, I just didn't see it.
I guess I'll start with the low hanging fruit. The name. Why does Microsoft insist on coming up with names that give search engines fits? .Net? C#? J#? X#? Are they deliberately trying to keep people from finding information about their products? Fortunately, Google can handle the # these days, but ".Net" still isn't searchable. And other sites don't handle it as well as Google.
On the topic of searching for .Net, the list archives at discuss.develop.net are a great resource for .Net questions and answers. But the search engine is CRAP. It would be so much more useful if you could do a reasonable search on it. And the limitation that you can only do a cross-list search if you subscribe to the list is annoying. Those LSoft guys need to license someone else's search engine in a hurry.
Greetings, all. It took me a while, but I'm finally getting around to writing my first post. First of all, I'll insert the obligitory thanks to Scott for hosting this. I've been wanting to blog for a while, but I've been too lazy to set up my own feed, and Radio just didn't speak to me.
Why do I want to blog? Mainly to rant - hence the title of the web log. I have no idea if anyone will ever read this, so I can't claim to be performing a public service here. I'm not a natural writer, but nothing gets my writing juices flowing like some inane limitation that makes my life a living hell. The best thing that could possibly happen is that some of this makes its way back to the Microsoft folks and they address the issue. Far more likely is that I just vent and feel better. And that's cool.
Since this is DotNetWebLogs.com, I should say something about my .Net background. I starting playing around with .Net back in the beta 2 days. I recently completed my first production development project with it - a web service API for my company's (eiStream) workflow and imaging product. My next project is a set of web controls that make it easy to build browser-based applications that are clients of that web service. After about 8 months of heavy development with the .Net framework, I've got plenty to rant about. Oh, I may throw a bone to Microsoft now and then, but they've got legions of 'softies acting as their advocates. We've got Don Box with his "Favorite .Net Feature of the Day" - think of this as my "Least Favorite .Net Feature of the Day". Of course, I'm sure I won't be limiting my topics to .Net.
Let the ranting commence...
More Posts