Expert Texture
The blogged wandering of Robert W. Anderson
Archive for August, 2006
August 31, 2006 at 8:35 pm · Filed under Miscellaneous
If this blog has a topic, this is certainly off it.
I have recently been listening to the musical version of the War of the Worlds. This was given to me as a present by my sister last year. I had never heard of it before, but I guess it was big in England at some point (it was released in 1978). Kind of campy and fun, it’s kind of a disco / rock opera clearly influenced by Jesus Christ Superstar.
I’m not really into musicals, but in the right mood you can coax me into singing “Heaven on their minds.” But, I’m straying off the off-topic.
The music of this piece is too upbeat. It completely misses the horror you would expect from a Martian invasion. It is just too upbeat. While listening to the words:
With the smoke of battle clearing,
Over graves in waves defiled.
Slowly disappearing,
Farewell Thunder Child!
I’m feeling:
Hey, yeah, we’re all going to die! Yeah!
And now, back to your regularly scheduled program.
August 28, 2006 at 10:01 am · Filed under Miscellaneous
In a post about Akismet being out of commission, Robert Scoble notes that it has blocked 64,000 comment spams for him. This is since he moved to Wordpress (approximately 321 days ago). Akismet has blocked 45,000 for me (over approximately 259 days). This means that my blog has 89% of the readership of his, right?
Of course these are the lowest type of “reader”: the spammer bot.
Look out, Robert, here I come!
Perhaps this means that some spammer bots avoid Wordpress.com hosted sites (mine is self-hosted). If this is true, that is another bonus of Wordpress: more spammers avoid it from the get-go.
Wordpress and Akismet really rock.
August 28, 2006 at 6:15 am · Filed under Grid Computing
Dan writes about the new version of the Digipede Network coming out soon:
But, most exciting: we’re getting ready to release the Digipede Network 1.3 next month. The development for this release has gone very well (mostly due to Rob, his adoption of some agile development techniques, and his devotion to automated builds and tests). We’re on schedule for a September release.
Thanks for the nod, Dan, but it is everyone on the team making this release happen — even you 
Tags: .NET, Digipede, grid
August 20, 2006 at 7:39 am · Filed under Miscellaneous
I am out of facility for the next week. Off the grid. Disconnected. Laptopless and without an Internet cafe. I expect lousy cell connectivity.
In Antarctica?
Nope, just on vacation with the family.
Tags: blog
August 14, 2006 at 6:33 am · Filed under .NET
Recently I complained about how the XmlSerializer treats the ObsoleteAttribute.
My desire was to deprecate a property with ObsoleteAttribute without it being ignored by the XmlSerializer. I still think that the attribute should be ignored for serialization, but here is a workaround:
Before:
[XmlAttribute]
public bool A { … }
After:
[Obsolete("This property has been deprecated; use property B instead.")]
[XmlIgnore]
public bool A { … }
[XmlAttribute("A")]
[EditorBrowseable(EditorBrowseableState.Never)]
public bool DeserializingA { … }
[XmlAttribute]
[DefaultValue(false)]
public bool B { … }
The ObsoleteAttribute tells the compiler to issue warnings to developers about the old property (and, as I said above, the XmlSerializer also ignores it).
The XmlAttribute.Name property directs the serializer to read a property from an XML attribute with a different name.
The EditorBrowseableAttribute hides the deserializing property from Intellisense. You can also hide it from the debugger using the DebuggerBrowseableAttribute (not shown).
The example shows this for XML attributes, but the same approach will work for other XML elements.
Not too much extra work, though I would still prefer the XmlSerializer to just ignore the ObsoleteAttribute.
Tags: .NET, XML
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
Main feed
Email subscriptions
