rwandering.net
The blogged wandering of Robert W. Anderson
Author Archive
August 9, 2006 at 5:51 am · Filed under .NET
Some time ago I wrote a plea to Microsoft to decouple the release of .NET 3.0 (then WinFx) from the release of Vista: A Vista plea to Microsoft.
At the time (i.e., back in March), I received some comments and other information from Microsoft employees telling me and that this kind of decoupling wasn’t in the cards.
There is a lot of chatter that Vista isn’t ready yet and that it may get delayed even more.
So, I renew my request to Microsoft:
Please, while retaining focus on quality, release WinFx .NET 3.0 and IE7 as soon as possible. Please do not wait for Vista’s release to make these components ready in final form.
August 8, 2006 at 12:37 pm · Filed under .NET
. . . or respect the IsError property.
I found a problem in some code today. The class is a data-holder for XML serialization. One property has been deprecated and attributed with the ObsoleteAttribute to produce a compile-time warning for developers. Previous versions of the XML data must still be readable, but we want to make sure all of our code uses the correct property.
I assumed that on XML-deserialization, the property-setter would be respected; however, it is not.
This is wrong.
If a member is marked as obsolete with warning (i.e., deprecated) it should still be observed. This is the case throughout .NET 2.0: deprecated members continue to function compatibly.
The only way that I can see the XmlSerializer observing this attribute is if IsError == true; however, even this is a stretch. Really, this attribute should only impact compilation, not runtime.
Better yet, if a user wants a new version to exclude deserialization, we already have an attribute for that: the XmlIgnoreAttribute.
Argh.
Tags: .NET, XML
August 7, 2006 at 7:57 am · Filed under .NET, Grid Computing
On Wednesday, August 9th, Digipede Product Evangelist Kim Greenlee will be speaking at the Central California .NET User Group about threading and grid technology. The title of her talk is “From Threads to Grid — Application Scalability and Performance for the 21st Century.”
My guess is she’ll mention the Digipede Network too. 😉 Kim is an experienced developer and speaker.
If you are in the Big Valley, check it out.
August 4, 2006 at 9:30 am · Filed under .NET
I rarely come across mentions of ReSharper in my aggregator (though I have posted about it myself). I did find these two recently: Why Microsoft should buy JetBrains and one on Visual Studio Rosario by mdavey.
Both of these posts criticize Visual Studio and point to JetBrains (the developer of ReSharper) as Microsoft’s salvation.
I assumed his first post to be tongue-in-cheek with:
Even with Visual Studio 2005 new refactoring support, to be truely productive you still need ReSharper.
but then it goes on with:
If Microsoft still can’t understand the concept of refactoring in 2006, then maybe its time for them to give in, accept they will never build a decent IDE, and buy JetBrains to resolve the issue.
This (and his follow up post) make it clear that he is pretty frustrated with VS2005 and Microsoft, but what struck me most about these posts was the “to be truely productive” statement.
One cannot be truly productive with VS2005 without ReSharper? What were you doing before editors had refactoring (much less Intellisense, or even ran in a GUI)? Were you not productive? I sure was.
Now ReSharper does enhance my productivity and maybe IntelliJ IDEA is a better IDE than VS2005 — I’ve never used it. That said, I think the majority of Visual Studio users are not only happy with VS2005, but also are very productive with it.
And don’t get me wrong, Microsoft, go ahead and buy JetBrains. Their products (at least ReSharper and dotTrace) really rock. And there is no doubt that these products makes Visual Studio a whole lot better. It helps me be even more productive.
Tags: JetBrains, Resharper, vs2005
August 2, 2006 at 10:22 am · Filed under .NET, Grid Computing
Yesterday we achieved code-feature freeze for the Digipede Network version 1.3. There are a few remaining issues, significant testing (system, install, upgrade), and much documentation left. You know: software development.
Thanks especially to Mark and Jeff for meeting this internal deadline.
Now that we are through that I can spend some time on some other things. Dan and I have an article to write; I owe quite a few emails; more product planning, roadmaps, etc., . Oh yeah, and a vacation!
Tags: Digipede, Software-Development
August 1, 2006 at 8:13 am · Filed under .NET
Since my conversation with Jeffrey Snover at the ISV CTO Summit (blogged here), I have wanted to post on some benefits of adopting PowerShell as an ISV.
Many products can be greatly improved by the addition of a rich commandline interface. Obviously this enables a user to type commands at the console, but this can also enable more advanced scripting of your application. The typical way an ISV provides such an interface is to develop a custom set of console application(s). Alternatively, a Microsoft ISV can build on top of PowerShell (using CmdLets) and get so much more.
Here are some pros and cons of these two approaches (with a nod to J. LeRoy for using Mind Maps in posts):
Custom (console applications)
Pro Multi-platform: includes any version of Windows (or anything else for that matter) that you target.
Con Design “from scratch”: Every aspect of the commandline (e.g., argument naming and syntax, formatting, etc.) needs to be designed. As there are few clear guidelines and virtually no consistency on the Windows platform, you will have to design this with a “least-worst” mindset.
Con Lots of coding: You have to write a fair amount of code for even simple use cases to enforce / interpret your arguments and to format your a report properly.
Con Advanced use cases hard (Lots more coding): Enabling complex user scenarios through your commandline may require a lot of development. For example, if you already have a rich API and want to expose this through your commandline, you may need to painstakingly map new commands to existing methods.
PowerShell CmdLets
Con Recent Windows only: Windows XP, Windows 2003, Vista, Longhorn Server (and specifically not Windows 2000).
Pro Easy design: Since PowerShell includes clear guidance on CmdLet design (e.g., argument naming) it is much easier to design your entire commandline with few design decisions.
Pro Object pipeline. PowerShell supports an object pipeline. This greatly eases the scripting use cases. For example, instead of having to make sure that your command outputs a piece of text that can be interpreted for use in a subsequent command, you simply need to return a .NET object.
Pro Formatting. The output formatting is not only automatic but plugs directly into other PowerShell utilities to format your output as tables, lists, to sort it, etc.
Pro Advanced use cases are easy. Combining the object pipeline with PowerShell’s ability to script .NET objects, you get a commandline that enables advanced use cases without you having to design for them directly. For example, the Digipede API already enables advanced use cases. With PowerShell we don’t have to design in each of those use cases. By making it easy for a PowerShell user to get an instance of our DigipedeClient object, we have enabled all (or nearly all) of the use cases enabled through our API.
Pro Simpler docs. Less documentation needs to be written to explain the basic use cases for your interface, because of the PowerShell design guidelines.
Conclusion
PowerShell is a really good choice for Microsoft ISVs. It delivers a lot of value to the ISV in exchange for relatively little effort.
From my perspective, PowerShell is yet another example of how Microsoft provides a terrific platform for ISVs: we get a great command line for the Digipede Network with little effort and can focus on the core value our product brings to the market.
Tags: ISV, PowerShell
July 31, 2006 at 6:13 am · Filed under .NET, Miscellaneous
Many have written on the transition of TestDriven.NET from freeware to a per-seat license. My sense (without any numbers to back it up) is that TestDriven.NET is the leading unit test integration with Visual Studio. It has had two things going for it: it works quite well and it was free. The former is still true, and the latter shouldn’t make much of a difference. The new prices seem reasonable (anywhere from $95 to $105 depending on license and quantity). I wish Jamie Cansdale luck with his product, though I suspect the transition to a profitable product will be challenging.
We (at Digipede) have long been users of both TestDriven.NET and the JetBrains product, ReSharper. In addition to tremendous refactoring, analysis, and searching functionality, ReSharper 2.0 also supports running and debugging unit tests (though I had not been able to get this to work). The transition in the license for TestDriven.net forced this issue: a quick trip to the JetBrains forum and I found out was wrong. Now that we can do all of our test-debugging in ReSharper we have uninstalled TestDriven.net.
I quickly found that I greatly prefer the user experience of ReSharper: it is more tightly integrated into Visual Studio. Most significantly, it has rich UI to visualize and control the unit tests across the solution. This UI is presented in menus, a dockable view (somewhat like the Nunit GUI), as well as with unit-test indicator buttons in the left bar of the source-code window. This makes it easy to select tests and run or debug them. I can easily visualize the test results, view stack traces for failures, etc, and trivially navigate to the failing source code. This is undeniably richer than TestDriven.NET (i.e., with menus and results relegated to the Visual Studio output window). In addition, ReSharper integrates its unit testing with their dotTrace performance measurement tool.
TestDriven certainly offers a different set of features than ReSharper (e.g., support for more test frameworks, compatibile with Visual Studio Express, NCover integration). I suppose it comes down to individual choice as to which integration a user prefers; however, the excellent refactoring support provided by ReSharper makes it a better value (at $199 per seat). My guess is that Jamie will begin pursuing tighter UI integration with Visual Studio. Once this is done, Jamie may end up with superior unit testing; however, I suspect he’ll have to find ways of delivering more value (maybe outside of running tests) for his product to be a financial success.
Tags: .NET, Resharper, TestDriven.NET
July 23, 2006 at 10:29 pm · Filed under Grid Computing
I’ve been really out of the loop lately (hurtling towards a code freeze has a tendency to do that to me), so one thing I did tonight was to catch up on my reading. I was reminded about the The Eight Fallacies of Distributed Computing as enumerated by Peter Deutsch (thanks, Kevin Burton):
Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
It is a classic. I came across this before at some point in my career when working on one of several enterprise and Web products I’ve worked on. I’d like to say that I kept this in mind when architecting the initial concept of the Digipede Network; however, I didn’t really.
It must have been lurking in the back of my mind, though, because we score rather well. We get a 0. 0 for 8.
Update for Dan: This is like golf. A lower number is better.
Tags: .NET, Digipede, Software-Development
July 14, 2006 at 11:09 am · Filed under Miscellaneous
While my post is a little late in coming, I want to thank Don Canning for the nice words about Digipede. And Kudos to John, Nathan, and Dan . . . their efforts partnering with the Microsoft Financial Services group are bearing fruit.
It is official, we are a success!
July 14, 2006 at 10:19 am · Filed under Miscellaneous
I’m sure this will result in my subscriber numbers going down further, but:
Every time I don’t post for a week I lose 20% of my subscribers.
Are my subscribers so fickle? Do the numbers get inflated when I do publish? Is this some side effect of aggregator cacheing? Is this a bug?
Just wondering.
« Previous entries ·
Next entries »
About me
Main feed
Email subscriptions