The Digipede Network is now certified as a SQL Server 2005 FrontRunner. Among other things, this means that we have passed the SQL Server 2005 component of the Platform Test for ISVs.
Thanks for the quick turnaround, Veritest and thanks to Microsoft for inviting us into the program.
I finally jumped into making my own PowerShell (nee Monad) CmdLets. I took the name change and, more importantly, promotion to release-candidate status, as the impetus to try it out. A rich command-line interface to the Digipede Network is on our future-list and I’m doing some prototyping now — it seemed as good a time as any.
I won’t go into what the PowerShell is, much has been written about it. I do want to commend the PowerShell team, though. I wrote a CmdLet and found how very easy and powerful their model is.
I started by writing a CmdLet to present simple job status. Turns out, the meat of the code is just this:
protected override void ProcessRecord() {
foreach (int jobId in mJobIds) {
WriteObject(mClient.GetJobStatus(jobId), true);
}
}
This code goes through all of the Job IDs passed on the command-line (or from the pipe), gets JobStatusSummary objects representing their state, and writes each one to the receiving pipe. Those of you familiar with our API will recognize the DigipedeClient.GetJobStatus() method. ProcessRecord() and WriteObject() are parts of the PowerShell API.
OK, granted, there are a bunch of lines of code required to wrap around all of this, but not too many. It all took a couple of hours start to finish (including reading and grokking). The result looks like this:
PS C:\> get-job-status -credential $me -host localhost -jobid 1
IsReadOnly : False
Collection :
JobId : 1
TimeCreated : 4/26/2006 1:10:32 PM
TimeModified : 1/1/0001 12:00:00 AM
StatusChangeTime : 1/1/0001 12:00:00 AM
Status : Waiting
LastTaskTimeFetched : 1/1/0001 12:00:00 AM
LastTaskTimeCompleted : 1/1/0001 12:00:00 AM
TaskTotal : 100
TaskTotalAssigned : 0
TaskTotalCompleted : 0
TaskTotalFailed : 0
TaskTotalActive : 0
TaskTotalWaiting : 100
TimeStarted : 1/1/0001 12:00:00 AM
TimeEnded : 1/1/0001 12:00:00 AM
EstimatedTimeEnd : 1/1/0001 12:00:00 AM
IsFinished : False
TaskStatusSummaries : {}
FailureReason : None
FailureMessage :
Again, if you are familiar with the Digipede API, you’ll recognize this as a JobStatusSummary. I wrote zero lines of code to do this, because PowerShell uses .NET Reflection to interrogate the object directly. Of course, this can all be reformatted with built-in PowerShell commands. This is excellent — we can layer CmdLets on top of our existing APIs without having to write a bunch of formatting code.
Now I know how easy this is, the next step is to step back and look at the bigger design.
Thanks to the PowerShell team for such a cool product.
Tags: .NET, Digipede, Monad, PowerShell
Nick Bradbury has an excellent post on how Dvorak is wrong about Internet Explorer (perhaps Dvorak is reading Kevin Burton’s blog).
I agree with Mr. Bradbury on the value that Microsoft brings to developers by making IE easily embeddable into applications. Having this capability built into the OS makes it all the easier for the distribution of new products without the weight of an IE install.
So, yes, I too am glad that Windows has a browser. I do wish it were better and easier to extend; but, I think IE7 will help us there too.
Last week I got into a morass on some prototyping I’m doing. I had made some changes to several different modules. I ran the standard tests: all good. I decided to run a slightly more obscure test (one that requires special orchestration). Failed. I wasted much time tracking this down. Turns out (of course) that the original code also didn’t work on my machine. Works every where else. In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else).
On Friday, my wife and I were talking about the week and I said that it was kind of frustrating. I gave her a little detail on the issue. Her response was:
That seems really common in your job (i.e., frustrating and non-productive time developing software).
That gave me pause. Is this common in my job or common in software development? Is it even common in my job?
Perhaps I have a tendency to talk about the frustrating without talking about the rest (the part that is creative and fulfills a need for artistic expression).
But, it got me thinking. What are the sources of frustration developing software?
Poor Tools / Development tools don’t work
This is generally not a problem; though I have a tendency to use addins from beta or early-access programs. Certainly while tools have been upgraded to work with VS2005, I’ve had a fair amount of uninstall / re-install / disable of addins. I wouldn’t bother, but some addins you just can’t live without (like TestDriven and ReSharper).
Of course the solution is to keep your dev machine fairly clean. Good idea, but hard to do in practice.
Too many manual steps
This is not uncommon when building something for debugging or testing on a remote machine. If between build and debug you have to switch to some other application, manually select files or folders, copy (ftp, . . .) files, restart something, run a test, wait for results, . . . then you have a source of real frustration and, worse, the chance of introducing error.
I try to root out manual processes as soon as possible.
Maintaining someone else’s poorly documented code or code with poor/nonstandard style
Not generally a problem at Digipede, but certainly can be frustrating.
Using poorly documented APIs
This can be frustrating for obvious reasons. One can easily get into a situation of just trying different things until the API works as you expect. Still doesn’t work? Try a different method or change this other argument. Combinitorics quickly can make this a black hole.
As an author of APIs, I know this can be hard to get right. How much documentation is needed? How many user scenarios are enough? How much knowledge should be assumed by the user of the product and other issues (like proper OS configuration, security practices, etc.)?
Other things that are frustrating?
What things am I missing? What frustrates you when developing sofware?
Tags: Programming, software, Software-Development
As Steve Gillmor points out, the GestureBank private beta is now live. Happy gesturing.
The week of June 19th is really full.
I’ll be going to Redmond and I hope to BloggerCon IV.
We need eight days a week, eight days a week, eight days a week.
BTW: Marc: that is the longest post slug I’ve ever linked to. đ
Tags: BloggerCon, Digipede, Microsoft
I’ve started reading Practical .NET2 and C#2 with the intention of reviewing it. Even though the book is intended for beginner to intermediate programmers, I’ve already learned some things I missed while porting to .NET 2.0. When my review is done, I’ll post it as a new article.
It is written by Patrick Smacchia, author of the excellent NDepend. If you haven’t used that, go and check it out. Once our code is all Code Anaylsis-clean, I’ll probably play with using its Code-Query-Language (CQL) to enforce other standards.
Note to Patrick: I would have called it ILQL for Intermediate-Language Query Language (pronounced ill-quill) since CQL is presumably prounounced sequel. My guess is that this pronunciation match was intentional (and it is kind of cute), but in describing it to others I’ve had to call it by other names so I don’t confuse them (e.g., “not-SQL” and “code query language”).
I’ve been messing around with .NET Remoting recently.
I’ve noticed this in the debugger, searched around online, and now confirmed it in Rotor (as a proxy for .NET 2). Many have asked the question, but I have yet to find an answer.
Why does the default BinaryFormatter used in .NET Remoting set the State property of the StreamingContext to Other (and not Remoting)?
I’m wondering too if I can use Other as a proxy for the Remoting state (i.e., that I’ll never see Other in a non-remoting context).
Anyone know?
Someone suggested that I’ve stopped posting while Robert Scoble is taking a blog break — but come on, not that many of my posts link to Robert.
Of course, RSS is a great mechanism for occasional posters, though I don’t intend to be one.
For me it is just business as usual: kids in preschool bring home germs, wife has knee surgery, Digipede, tagging music, other projects, a tinfoil constitution, and the craving for sleep.
More soon.
Tags: Digipede
We have been getting good press at Digipede. My recent favorite is the 5-star CRN review here: Grid Computing Turns .Net Into Enterprise Powerhouse.
If you are interested in getting Digipede news straight from the horse’s mouth (as it were), subscribe to: Digipede News and Announcements.
FriendFeed Status
About me
Main feed
Email subscriptions