rwandering.net
The blogged wandering of Robert W. Anderson
Archive for October, 2007
October 30, 2007 at 12:22 pm · Filed under .NET, Grid Computing, Miscellaneous
Today I was in a conference call doing a demonstration of the Digipede Network.
One of the demos includes using Excel as a front-end to a distributed code-behind calculation. A common follow on question was asked (heavily paraphrased),
what about code trapped in Excel workbooks?
The answer is, yes, we can (and have several customers that do) distribute Excel workbooks for distributed execution. Our software moves the workbooks, launches Excel through COM, executes calcs in the workbook, saves them, and brings back the workbook.
The prospect says,
That is both commendable and horrifying at the same time.
Heh.
As is most of the work we’ve done to provide stable, registration-free COM contract for the Digipede COM users.
Tags: .NET, COM, Digipede, Excel, QOTD
October 26, 2007 at 5:43 am · Filed under .NET, Grid Computing
On Tuesday I posted about the new Digipede SnapIn for PowerShell.
One question I didn’t get into is, why write a SnapIn when PowerShell supports full scripting for .NET APIs? The short answer is that we can provide a better command-line experience with PowerShell cmdlets than the “out of the box” PowerShell experience. Windows PowerShell Architect, Jeffrey Snover, did a great post on this a few months back: Cmdlets vs. APIs.
I thought I’d give an example of the difference as it relates to the new Digipede SnapIn.
For example, suppose you want to enumerate the pools on a Digipede Network. Natively in PowerShell, you can do the following:
[System.Reflection.Assembly]::LoadFrom("C:\\Program Files\\Digipede" +
"\\Framework SDK\\v2.0\\Net2.0\\Digipede.Framework.dll")
$DigipedeClient = New-Object -TypeName Digipede.Framework.Api.DigipedeClient
$DigipedeClient.SetUrlFromHost("MYSERVER")
$DigipedeClient.Management.GetPools() | ft
That is pretty verbose (note the first line is split in two to improve readability in my blog). This same operation becomes much simpler with the Digipede SnapIn:
Add-PSSnapIn DigipedeSnapIn
$DigipedeClient = New-DNClient -Network MYSERVER
Get-DNPool
And what about the output? Without any extra information, PowerShell will format output on its own — a very cool feature. The former example produces a default table output:
IsReadO PoolId Name Descrip Collect Schedul Potenti TotalCo JobTota TaskTot
nly tion ion ingAlgo alGhz mputeRe lComple alCompl
rithm sources ted eted
------- ------ ---- ------- ------- ------- ------- ------- ------- -------
True 1 Mast... Mast... {Mas... ...rity 66 19 665 57584
True 601 Fifo {Mas... ...tOut 18 3 0 0
PowerShell can’t determine which properties should be included, so it makes a guess. The DigipedeSnapIn includes formatting information to give much more readable (and useful) default output:
PoolId Name Description Resources Potential
GHzH
------ ---- ----------- --------- ---------
1 Master Pool Master Pool 19 66
601 Fifo 3 18
So, the SnapIn definitely provides a better command-line experience. And the great thing? These two worlds are not mutually exclusive. For example, suppose you want to specify the default pool for a DigipedeClient object? We haven’t exposed that as a property on New-DNClient nor provided a cmdlet for this purpose, but the API includes the PoolId property. Just do this:
$DigipedeClient.PoolId = (Get-DNPool -Name "Fifo").PoolId
Now, the default pool is a pool named “FIFO”.
This brings me back to something I wrote in my previous post: PowerShell is cool.
Tags: .NET, c#, Cmdlet, Digipede, PowerShell
October 25, 2007 at 6:25 am · Filed under .NET, Grid Computing
I’ve been playing with LINQ here at Digipede for various reasons, one of which is to put together a sample for using LINQ on top of the Digipede APIs. I haven’t gotten together any code to post (primarily because I’ve been pushing on our PowerShell SnapIn in my “spare” time).
A pleasant surprise this morning: Matt Davey posted a code sample on his blog: GridLINQ and Digipede.
I knew he was working on something. Yesterday, Nathan helped Matt with some installation issues (kudos to Nathan and thanks to Matt for the assist). Anyway, at some point Nathan says to me:
You know, Rob, you should connect with Matt on IM. He tells me he tried LINQ with the Digipede Network and “it just worked”. He’s IM’ing me about it and I’ve never even seen a line of LINQ code!
Thanks for the posting, Matt. Keep up the posts and we’ll put you up for Digipede MVP!
BTW: It looks like Matt’s sample will run on either Digipede Network 1.3 or 2.0 — I want to point out, though, that Digipede Framework collections only started supporting IEnumerable<T> directly in version 2.0; so v2.0 is more LINQ friendly.
Tags: .NET, c#, Digipede, grid, linq
October 23, 2007 at 11:34 am · Filed under .NET, Grid Computing
Today we posted a preview of our PowerShell SnapIn for the Digipede Network — go to the Digipede community site for details and download instructions.
This preview provides a functioning command-line interface to much of the available Digipede Network management APIs. This functionality will continue to be enhanced along with the underlying APIs (more on this in a future post).
This preview is a little bit of a departure for us at Digipede. While we have targeted previews to customers in the past, this is the first time we have made one publicly available. A bigger departure, though, is that we are also including full source code to this preview.
Digipede is not open-source, so why release the SnapIn code?
- The SnapIn provides excellent examples for the Digipede Management APIs. The SnapIn is also a good example of a PowerShell SnapIn.
- By providing a sample as a SnapIn we are reducing the startup costs for our customers to develop their own cmdlets (for the Digipede Network and otherwise).
- We hope that some community members will provide feedback in the form of suggestions, fixes and maybe even new cmdlets — this will help make the SnapIn better faster.
Another question might be, why do a PowerShell SnapIn at all? After all, PowerShell does a great job with .NET APIs without any additional support.
- PowerShell does do an excellent job with .NET APIs (and COM APIs too, for that matter). But this support is better suited to scripting than to a great command-line interface. I will post an example of this difference later this week.
- For some customers, a command-line interface is important. PowerShell provides a standard framework into which such interfaces can be built — the days of writing one’s own custom command-line interfaces are thankfully past.
- PowerShell is really cool.
If you are interested in PowerShell, the Digipede API, or a command-line interface to the Digipede Network, please take the time to try out the preview. We would love to get feedback from you on what else it needs, any problems you find, and ideas for other cmdlets — implementations even better!
To learn more about Windows PowerShell, visit the Microsoft Windows PowerShell home page as well as the PowerShell Team blog.
Tags: .NET, c#, Cmdlet, Digipede, PowerShell
October 12, 2007 at 8:41 am · Filed under Miscellaneous
Vista has a cool feature called “Problem Reports and Solutions”. This tracks problems and periodically looks for their solutions. These kinds of problems include system and application failures, connectivity issues, etc.
Today it notified me it found a new solution, so I immediately went to see what it was:
Of course, immediately I thought which problem with Windows Vista? And I’m not being sarcastic here. I’ve had several intermittent issues with Vista related to networking, hibernation / sleep, sluggishness, etc. (btw, the sarcasm is best applied to the possible solutions 
.
So I clicked on the link and got a dialog with this further information:
Again, my question of which problem. Nothing in the main part of the text says anything other than “the problem” and the “Technical Information” box describes some generic problems.
I would like to see two improvements here:
1. Improve the solution title
Instead of “the problem”, how about:
Follow these steps to improve the reliability of Windows Vista.
The actual title may be limited to the software product to which it relates. If so, that is a shortcoming, because the actual messaging is pretty unhelpful . . . and it opens Microsoft up to further sarcastic jabs.
2. Provide more information about why this solution was chosen for me
The dialog is pretty unhelpful. Instead of sending me to the knowledge base, how about some specifics about my own machine? Something like:
There are X problem reports on your system indicating that this update will improve the functioning of your system. Click “here” to view these reports.
I would actually like to know specifically what this update is intended to fix.
Tags: KB, Microsoft, Vista
October 3, 2007 at 5:31 pm · Filed under Miscellaneous
With my help (and Ken’s help too), we just revamped the kukunest Web site (
). It is easier to navigate, faster, and now hosts more products.
Now they have more themes of children’s bedding and art work plus full and toddler sizes.
Great stuff — check it out.
And now back to the regularly scheduled program.
Tags: kukunest
October 1, 2007 at 11:29 am · Filed under Miscellaneous
On Friday, I updated my laptop using Windows Update; the entire install process went smoothly.
Things I’ve noticed.
- In the past, remote desktop connections to non-Vista machines always prompted the user to confirm connection. New in Vista SP1 is the ability to turn off that warning on a computer-by-computer basis. A small thing, but I found this really irritating in the past. Cool.
- The Start -> Search menu is gone. A little strange, I think. You can get the same functionality from any explorer window, so I don’t see how this levels the playing field for other search vendors.
- Strangely enough, when I installed the prerequisites (which are purportedly related to improving Vista update performance), my Alps touchpad tray icon appeared for the first time ever. I clicked on it and found that, again for the first time ever, the touchpad’s unique “device select” tab was available in the mouse control panel. Weird, but good. Now I can turn off the tap while typing.
Things I haven’t noticed.
- Any changes in stability. In general, I feel that the stability of Vista has improved over the year, but my Reliability Monitor tells a different tale. My reliability index moves between 1 and 3 and hasn’t gotten over 5 since July 31st. I hope that this changes in SP1, though it isn’t clear how much of this is the OS and how much is bad application behavior. I wish I could weight failures on the system for how they impact me and possibly exclude them from the Reliability Monitor.
- Any changes in performance.
All in all I’ve been getting happier with Vista as the year has progressed. I initially had all sorts of networking problems, but Dell or Intel seems to have mostly solved those. Long gone are the days when I had to reboot my machine to get it on a network. We even now have a VPN solution that supports Vista.
Aside from the trouble, I like Vista. The only part I don’t like about it is feeling like an early adopter with it. After all, why did I install SP1? To provide feedback to Microsoft, yes, but also in hope that it makes my experience better sooner.
Tags: Microsoft, SP1, Vista
About me
Main feed
Email subscriptions
