views:

57

answers:

2

Hi.

We have a flexible process control system by which automation engineers configure up large application comprising thousands of small logical units that are parameterized and integrated into the control flow.

There are many tasks that are repetitive on the granular level, and there are a multitude of proprietary productivity tools that have been made to meet this demand. We have different business segments, and the automation engineers vary across the board in skill sets and interests. Fancy GUI and usability versus flexibility is a common discussion.

At first glance, powershell seems to be a sensible platform to implement such tooling and which also would be a advantageous cross-over skill to manage the IT aspects of the system setup and deployment as a whole.

This should allow the script savvy their desired flexibility (they are already a scripting crowd) and the GUI dependant could still get their desired GUI underpinned by powershell.

But I can't seem to find many people/groups who have tried to use the scriptability and object passing of powershell extensively to accommodate a heterogeneous user community outside the realm of IT management.

Do anybody have any tips or word of caution? Am I missing something obvious as to why this shouldn't be done?

Shouldn't powershell be taking over the world? ;-)

+1  A: 

Powershell is obviously capable of doing this kind of work and it's only going to get more capable over time. It's also flexible and extendible so as you need to add things to it, you can. Clearly, its support lifetime will be measured in decades. The obvious downside is vendor lockin.

Knox
I think we sold our soul to MS long time ago. As a .NET developer, I feel like an archangel, in that respect ;-) But your point is well taken.
Tormod
+4  A: 

Hi Tormod. I totally agree with you, PowerShell should be taking over the world and your statement is where PowerShell is heading.

GUIs over PowerShell makes a alot of sense. I did a screencast How to Host PowerShell in a WPF Application

Microsoft Exchange's GUI is all layered over the PowerShell. What you can do in the GUI you can do at the command line. Exchange can even "record" the GUI steps and present them as a PowerShell script.

Going this route takes you up the learning curve. Embedding the PowerShell engine, runspaces, collections of PSObjects, error handling and more.

There is not much out there yet.

Doug Finke