"Design Patterns for Powershell"

[rferrisx]

In learning Powershell, once you are over the humps of the pipeline,
automatic variables, conditional loops, .NET, network admin tricks
etc. (e.g. a "better cmd line"), you are faced with absorbing the
intent of the architects in creating and using functionality like:

params for Functions
scriptlets
[cmdletbinding]
Cmdlet architecture

etc. and a subset of other dev skillsets like error handling,
debugging that would make the difference for between someone who is
rewriting his 10 line cmd scripts or someone who is creating
significant functionality in Powershell scripts. I think what I would
like is book with a title like "Design Patterns for Powershell" that
provides examples and discussion on how to best implement Powershell
for performance, for re-usable design, when something more "lambda"
than "imperative" makes sense and the converse. Currently, there is a
lot of research leg work to go through to come up with this "all by
your lonesome". Other pieces of this might be a Visio or VisStudio
design template(s), advice on writing testable and easily debugged
functions, PSIE extensions that provide for intellisense or design
templates. It's true folks like Bennet, Lee, Snover, Payette, Holmes,
and the Powershell team have some discussion and some examples about
this...but I find myself with many questions...and feeling a little
confused. Do I need to master "Design Patterns for C#" or understand
Functional Language style vs. Imperative Language issues before I
write elegant, correct, re-usable functions, and scriplets for
Powershell?

[Marco Shaw [MVP]]

rferrisx wrote:
> In learning Powershell, once you are over the humps of the pipeline,
> automatic variables, conditional loops, .NET, network admin tricks
> etc. (e.g. a "better cmd line"), you are faced with absorbing the
> intent of the architects in creating and using functionality like:
>
> params for Functions
> scriptlets
> [cmdletbinding]
> Cmdlet architecture

Well, yes, PowerShell does provide a learning curve, but I don't know
whether this learning curse is steeper than any other
scripting/programming language. I'm not saying its any easier either
though.

What I do think is good is that it can be approached in layers when
learning.

Yes, a decent C# background would be a good based for the advanced
functionality you mention above, but it all can still be learned by
people new to the language.

And the good thing is that one doesn't ever need to know about advanced
PowerShell development to actually use it.

I am still very interested in your comments. I think it will take time
for PowerShell to evolve and standards to be communicated.

Marco

--
*Microsoft MVP - Admin Frameworks
https://mvp.support.microsoft.com/profile/Marco.Shaw
*Co-Author - Sams Windows PowerShell Unleashed 2nd Edition (due December
15th, 2008)
*PowerShell Co-Community Director - http://www.powershellcommunity.org
*Blog - http://marcoshaw.blogspot.com

[Marco Shaw [MVP]]

> Yes, a decent C# background would be a good based for the advanced
> functionality you mention above, but it all can still be learned by
> people new to the language.

As a developer (which you seem to be), I think this is a very good
standards-oriented/developer-focused blog by a fellow PowerShell MVP:
http://keithhill.spaces.live.com/blog/

That's just one of many good blogs out there...

Marco

[Josh Einstein]

Great idea. I am a developer that wandered into PowerShell and I see it from
a developer's perspective. I always try to maintain consistency and
cleanliness in my scripts and I'd like to discuss with others who share that
perspective. PowerShell is great in that it can be used for "quick and
dirty" stuff as well as structured and designed stuff.

On my blog at www.josheinstein.com I plan on posting more of my scripts and
conventions. I've got about 5 posts in the "draft" state because I want to
get them nice and polished before I post.

Josh

"rferrisx" <rfe...@rmfdevelopment.com> wrote in message
news:3eccebea-0250-4947...@e1g2000pra.googlegroups.com...

[rferrisx]

Josh:

I like your blog. I am adding it to my reading list. I think to some
extent Marco is right...there is lots of Powershell material and code
available. However, I picked up this book: "Windows PowerShell
Programming" by some of the devs who worked on Powershell:
(Kumaravel,White,Li,Happell,Xie,Vutukuri) and decided to read it all
the way through along with the Windows PowerShell SDK:
http://msdn.microsoft.com/en-us/library/ms714469.aspx. After that, I
think I will go back and look at Function/Scriplet/Cmdlet development
as regards to maintainability, testability, debugging, etc. The
reason for this is that Powershell has some PERL like "syntax
flexibility" (??) that allows the user to not necessarily code with
elegance,readability,etc. An example of this you describe in your blog
here: http://einsteintech.spaces.live.com/blog/cns!89E05724AF67A39E!250.entry.
I don't really see the point of mashing-up up a bunch of functions or
going on with learning Powershell until I've absorbed this type
background and thought/hacked/pondered it a bit. At best, I will
stumble through writing a lot of dubious script that will look ugly
six months or a year from now. I appreciate your blog. It goes
beyond: "Here's the cool stuff we can do..." and helps more with the
dialog: "Here are the best practices..."
As an example consider this question: If you were writing a script-
cmdlet or script with functionality that could be derived from WMI
or .NET which would you choose and why? Which (WMI or .NET) do you
think receives more testing?

Ryan

On Feb 2, 9:02 pm, "Josh Einstein" <josheinst...@hotmail.com> wrote:
> Great idea. I am a developer that wandered into PowerShell and I see it from
> a developer's perspective. I always try to maintain consistency and
> cleanliness in my scripts and I'd like to discuss with others who share that
> perspective. PowerShell is great in that it can be used for "quick and
> dirty" stuff as well as structured and designed stuff.
>

> On my blog atwww.josheinstein.comI plan on posting more of my scripts and

> conventions. I've got about 5 posts in the "draft" state because I want to
> get them nice and polished before I post.
>
> Josh
>

> "rferrisx" <rfer...@rmfdevelopment.com> wrote in message
>

[Josh Einstein]

Thanks, I'm glad you found my recent posts useful.

I definitely hear what you're saying about trying to figure out what
conventions you'll use before writing a bunch of scripts, but if you're
anything like me, your conventions will probably always be a little bit
different than they were the month before. I'm always fighting the urge to
go through all my scripts and rewrite them. I did however start converting
most of my scripts to the advanced function syntax, even if they don't need
advanced function features just because I am a nazi about consistency.

Regarding your question about WMI vs .NET, personally I would probably
choose .NET because of the fact that I am a .NET developer and have an
extensive background in that. I rarely have had the need to get into WMI but
I know how to get to it if I need to, just not necessarily what I'm looking
for. Also, I think WMI probably has a ton of overhead to make it accessible
to VBScript and PowerShell. But then again, when you're trying to work with
remote machines, platform API's and .NET usually aren't up to it.

Josh

"rferrisx" <rfe...@rmfdevelopment.com> wrote in message

news:ea508894-85d8-404c...@r10g2000prf.googlegroups.com...

[Marco Shaw [MVP]]

> As an example consider this question: If you were writing a script-
> cmdlet or script with functionality that could be derived from WMI
> or .NET which would you choose and why? Which (WMI or .NET) do you
> think receives more testing?

A year or so ago, I figured WMI was on its way out... Dropped from
Exchange 2003->2007, for example.

But along comes Hyper-V, and its public API is 100% WMI... So, WMI is
still here for some time to come.

So which is more tested? Depends... ;-)

--
*Microsoft MVP - Windows PowerShell

https://mvp.support.microsoft.com/profile/Marco.Shaw
*Co-Author - Sams Windows PowerShell Unleashed 2nd Edition