I thought I’d check out Microsoft Max, but Don Dodge says it doesn’t support OPML.
What? A new RSS aggregator that doesn’t even import OPML?
I’m beyond surprised, and won’t check it out. I’m sure it looks beautiful (as everyone is saying), but without OPML support what value does it bring to me?
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 😉
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.
. . . 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.
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
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
Yesterday Dan posted on his experiences getting a grid running behind SharePoint with Excel 2007.
It turns out that it is remarkable easy if you use the Digipede Network.
Check it out: West Coast Grid: Putting a grid behind Excel 2007.
Good job, Dan.
Tags: .NET, CCS, Digipede, Office2007, SharePoint
I almost forgot . . . thanks to Dan for the reminder . . . we are making it even easier to try out the Digipede Network.
Today we announced that the Digipede Network Developer Edition is free. This has all the capabilities of Team Edition, but it is limited to two processors.
Go here to fill out a form to get your copy.
C# 2 has anonymous delegates. I like them. Of course, they enable advanced constructs like closures and continuations, but one of I’m a pushover for language and environment features that improve readability and maintainability of code. Before C# 2, if you wanted to perform a task on another thread, you might do something like this:
/// Do something worker callback
private void DoSomethingImpl(object callerData) {
// implementation here
. . .
}
/// Do something on a threadpool thread
private void DoSomething() {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(new WaitCallback(DemoJob));
}
With anonymous delegates, you can just do this:
/// Do something on a threadpool thread
private void DoSomething() {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(delegate(object o) {
// implementation here
. . .
}) ;
}
Fewer lines of code. Easier to maintain. Logic easier to follow. The pattern gets even nicer when your worker method needs arguments. For example:
/// Do something on a threadpool thread
private void DoSomething(int a, double b, SomeClass c) {
// invoke on threadpool thread
ThreadPool.QueueUserWorkItem(delegate(object o) {
// implementation here can use a, b, and c
. . .
}) ;
}
To pass the three arguments a, b, and c to a named method would require a custom class or packaging in a collection or array. I won’t show you how to do it. It is tedious, after all.
Just yesterday I compared the Digipede Network to Sun Grid. One point I made was that our product is very easy to use . . .
Of course, I’m biased, but: stay tuned for an upcoming independent review that contrasts the Digipede Network favorably against Sun Grid on this very point.
Little did I know that the review would be just a day away.
The review Gridlock Alert For Sun Grid? goes further than I thought. It slams Sun Grid and speaks well of our product. You can see it all in the article’s subheading:
Analysis finds hidden costs in Sun platform, while competing Digipede offering shines
The article also specifically supports my earlier point.  The reviewing engineers gave up after spending five hours trying to get something to work on Sun Grid.  On the Digipede Network, it took approximately 1/2 hour. In the reviewer’s words:
The difference in ease of use in Sun Grid vs. Digipede was enormous.
Thanks for the great review!Â
CRN has a more comprehensive review of the Digipede Network here: Grid Computing Turns .Net Into Enterprise Powerhouse.
FriendFeed Status
About me
Main feed
Email subscriptions