Summary: Microsoft Scripting Guy, Ed Wilson, talks about examining the issues surrounding Windows PowerShell best practices.
Microsoft Scripting Guy, Ed Wilson, is here. One of the best things about TechEd, no matter where it is held, is the chance to meet up with people who we do not normally get to see. For example, this year in Houston, Texas at TechEd 2014, we had Jaap Brasser in the Scripting Guys booth with us. We first met him at the Dutch PowerShell User Group, and he helped in our booth at TechEd in Madrid last year. But this year when I was speaking at the Dutch PowerShell User Group, he was in China. The cool thing is that he came to Houston for TechEd to help us out.
Another person we do not get to see very often is Honorary Scripting Guy and Windows PowerShell MVP, Sean Kearney. Sean and I have been talking about doing a video since before the Windows PowerShell Summit in Seattle. Well, it finally came about, and we recorded it at TechEd 2014 in Houston. Check it out: Scripting Cmdlet Style video. One word of warning, the video is addictive.
Dudes and dudettes!
Why all the fuss about Windows PowerShell best practices? Windows PowerShell is merely a scripting language. It is really interesting. I wrote three books about VBScript, and I taught literally hundreds of classes worldwide. Only rarely was there any question about best practices. It might be that most people who were writing VBScript were people who had a development background anyway. All developers study patterns and practices, and most shops have style guides that cover what most people are calling best practices.
But interest there is. For example, at the last three TechEds, I (along with Jeffrey Hicks, Don Jones, and Hal Rotenberg) provided a series of talks about Windows PowerShell Best Practices. In each case, the talks were overflowing and we turned people away. In New Orleans and Orlando, they added additional sessions, and those sessions also sold outl. I even wrote a bestselling book on the topic for Windows PowerShell 4.0: Windows PowerShell Best Practices.
What is it about Windows PowerShell best practices? For one thing, Windows PowerShell is easy-to-use and very powerful. As Voltaire (and also Uncle Ben in Spiderman) said, “With great power comes great responsibility.” So IT pros who use Windows PowerShell want to know what is the responsible way to use this great power.
The peanut butter and chocolate issue
Windows PowerShell has a dual personality, just like the peanut butter and chocolate issue from in the 80s. This dual personality issue is something that complicates all discussions of Windows PowerShell best practices.
For example, a common Windows PowerShell best practice is to avoid using aliases. Although there is somewhat agreement, not all Windows PowerShell MVPs agree with not using aliases in scripts. The issue is not quite so easy. For example, I do an awful lot of configuration directly from the Windows PowerShell console, and I do not write as many scripts now as I once did. In fact, with all the cool modules in Windows 8.1, Windows 8, Windows Server 2012 R2, and Windows Server 2012, I do not have to write as much. For example, I can quickly start all virtual machines on my system, local or remote, with a one liner:
Get-VM | Start-VM
When I can do something this powerful without scripting, there is no reason to place this command in a script, and try to parameterize it, add Help, comments, and blah blah blah. Dude, it is a one-line command, and I think it is a best practice to not write such a script. Besides, with over 8,000 scripts on my laptop, I would have a hard time finding the script in the first place. Difficulty in finding some scripts is why I started typing the commands at the console. I can re-create the command quicker than I can find the script.
I am, obviously, not alone in this. Last week in my series about profiles, several people shared functions that relate to managing the transcript or history in their Windows PowerShell console. This tells me that some of the most advanced Windows PowerShell people on earth are spending a decent amount of time working interactively at the Windows PowerShell console.
But what about scripts?
For the sake of this discussion, I break scripts into two categories (although there could be more than two categories). I define them as one-off scripts and tool scripts.
One-off scripts
One-off scripts are written to be used one or two times in a limited set of circumstances. Typically, they will have hard-coded values instead of parameterized input. Quite often, they are straight-line (no functions) scripts.
These types of scripts are little more than a collection of commands one might enter into the Windows PowerShell console. As such, they may use aliases for cmdlets, use positional parameters, and comment-based Help is neither expected nor required. Some Help may be present in the form of single-line comments. These types of comments generally are limited to instructing the user about which values in the script need to be changed to permit it to run in a slightly different environment.
I often write these types of scripts. I am doing so when I want to illustrate a Windows PowerShell technique and I do not want to overly complicate my examples. Or I might write something for myself to automate something that involves more than a single line in the Windows PowerShell console.
In fact, when I am writing for myself, I treat these types of scripts as an extension of the Windows PowerShell console.
Tool scripts
Tool (also known as utility) scripts are written in such a fashion as to promote reuse. Typically, all points that could be configured are parameterized in such a way as to facilitate running the script from the Windows PowerShell console or from a scheduled task. Often these scripts take the form of advanced functions, and they are stored in Windows PowerShell modules. The best of this class act and behave just like Windows PowerShell cmdlets—in fact, they are script cmdlets.
The advantage of writing in this fashion is the ability to configure, extend, or modify the way Windows PowerShell behaves in your environment. The scripts are written to be used by others. In this way, they become like additional cmdlets, but they are customized for the environment. They behave exactly the way they need to in order to facilitate the work to be done. For these, we want to use the power of Windows PowerShell to ensure reliability and readability, and to promote discoverability.
That is an overview of the issues surrounding Windows PowerShell best practices. Best Practices Week will continue tomorrow when I will talk about Windows PowerShell best practices in the Windows PowerShell console.
This week, I will discuss various Windows PowerShell best practice scenarios. Feel free to chime in to the discussion via the comments section, or via Twitter, Facebook, or scripter@microsoft.com. As always, you can post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy