One of the things that motivated us to develop PowerShell was the belief that we (Microsoft) had been doing a poor job supporting the Admin Development Model.
All the effort seemed to have gone into treating Admins as GUI-only users or as though they were developers that couldn’t handle the complexity of parenthesis. I never quite understood the thinking there. On the one hand, you expect the admin to comprehend the mind-numbing complexity of WMI and ADSI but on the other hand, you invest in a language that allows them to avoid typing the parentheses in an IF statement? Was that really the problem? Don’t get me wrong – for what it is, VBScript is great but at the end of the day, a lot of VBScripting is full blown systems programming with a simplier syntax. There is nothing wrong with that. The vast majority of Admins are super smart folks that can do systems programming WHEN THEY HAVE THE TIME TO.
Therein lies the problem. Systems programming takes a lot of time and effort and is pretty formal. The Admins I know don’t have a lot of spare time because they run around with their hair on fire. When your hair is on fire, you need a bucket of water and systems programming is not that bucket of water. What admins need is a set of tools that match the reality of their work. Admins need an interactive shell.
An interactive shell that allows them to quickly, easily, and iteratively investigate and manipulate their systems. Since the nature of admin problems/issues change constantly, they need to easily compose solutions by leveraging a set of base, domain-specific, commands and a then set of powerful, domain-independent, utility cmds. Bruce Payette once said something to the effect that, “the lifespan of 95% of the scripts in the world start at the prompt and end at the carriage return”.
Once you have an interactive shell that supports great compositional scripting, then, depending upon the problem and the odds that you’ll want to do that operation again, Admins save that script into a file and run it instead of having to figure it out/type it every time. Over time, they may decide to generalize the script so that it can deal with more and more situations. Later they may choose to make it more formal and do better error handling. Sometimes, they’ll want to make it part of their formal management of production servers at which point they’ll want it to be very formal, leveraging types/constraints, rich error handling, digital signatures and all that.
This range of activities, from interactive shell, to quick and dirty scripting, to formal production scripting is what we call the Admin Development Model. (Note that model of work is NOT limited to Admins – many people use this but it is critical for Admins.) PowerShell is very focused on supporting the Admin Development Model. That is why we have an interactive shell. That is why we struggled hard to find the right balance in our syntax and semantics between interactivity and scriptability. That is why we support a wide range of scripting styles from quick and dirty (bash-style) scripting to more advanced (Perl-style) scripting to more formal .NET programming. We wanted to ensure that you could learn a single tool and then decide how you were going to use that tool to solve the particular problem at hand.
It is NOT the case that beginners will do the simple stuff and experts will do the sophisticated stuff. We expect everyone will do do everything at some point in time – it is question of the problem they are trying to solve and the skills they have at the moment. (e.g. The highest end of scripters are still going write lots of quick and dirty, ad hoc scripts – because that is the right tool for lots of situations.).
The great thing about having a single tool to do this is that it becomes economical to invest in learning the capabilities of the tool because it can be leveraged in so many situations. It also increases the pool of people that form the community that help each other solve problems. It also makes it easier to grow your career, as you gain expertise and become more productive and opens up more job opportunities than expertise in a very narrow toolset provides (this is another reason why we leveraged .NET – learning .NET makes you more marketable. If you are a hiring manager leveraging PowerShell – the job is more attractive to people and there is a larger pool of experienced people to hire from.)
PowerShell supports the Admin Development Model because it allows PowerShell to be the right tool for the right job for the maximal range of problems and lays the groundwork for a large and vibrant ecosystem.
<Switching gears>
Now let’s see the Admin Development Model in action.
A few days ago, I posted a entry Send-SignatureToClipBoard to highlight the Philosophy of Automation. I had noticed that I did an operation over and over again and decided to automate it. The Send-SignatureToClipBoard script copies the content of a file to the clipboard so that I can then paste it into an application. I then found myself doing something similar to this when I cut and pasted some HTML styles for the code examples in this blog.
Now it was time to take the next step in the Admin Development Model and generalize the script I wrote. Why just send signatures to the clipboard? I decided to generalize it by sending SNIPPETs to the clipboard. I created a directory C:\Snippet and any file in that directory would be a snippet that I could specify as a parameter and send it’s content to the clipboard. Here is the code I now have in my profile file:
########### SNIPPETS #####################################
$SnippetDir=”C:\Snippet”
function Get-Snippet($Name=”*”)
{
Get-ChildItem “$SnippetDir\$($Name).txt”
}
function Get-SnippetPath($Snip=”Signature”)
{
$path = “$SnippetDir\$($snip).txt”
return $path
}
function Remove-Snippet($Snip=”Signature”)
{
Remove-Item $(Get-SnippetPath $Snip)
}
function Resolve-Snippet($Snip=”Signature”)
{
Get-Content $(Get-SnippetPath $Snip)
}
function Set-Snippet($Snip=”Signature”,$text=””)
{
$text > $(Get-SnippetPath $Snip)
}
function Send-Snippet($Snip=”Signature”)
{
Resolve-Snippet $Snip |Clip.exe
Write-Verbose “Sent [Snippet:$Snip] to Clipboard”
}
Set-Alias gsn Get-Snippet
Set-Alias rsn Remove-Snippet
Set-Alias rvsn Resolve-Snippet
Set-Alias ssn Set-Snippet
Set-Alias snsn Send-Snippet
########### END SNIPPETS #####################################
Notice that the following:
-
It uses the standard Verb names so it is easy to learn, understand and remember
-
It leverages the standard alias shortcuts to provide aliases were are easy to learn and remember.
-
It provides an initializer for the Snip parameter so that you don’t have to provide a parameter if you want the “Signature” [which is what I’ll use the most]
-
Because it leverages GET-CONTENT, you can use wildcards so you don’t have to travail between having pithy names for productivity vs explicit names for clarity.
Here is an example of using these scripts (modulo an actual PASTE):
PS> $VerbosePreference = “Continue”
PS> gcm *snippet
CommandType Name Definition
———– —- ———-
Function Get-Snippet param($Name=”*”) Get-Child…
Function Remove-Snippet param($Snip=”Signature”) R…
Function Resolve-Snippet param($Snip=”Signature”) G…
Function Send-Snippet param($Snip=”Signature”) R…
Function Set-Snippet param($Snip=”Signature”,$t…
PS> gal *sn
CommandType Name Definition
———– —- ———-
Alias gsn Get-Snippet
Alias rsn Remove-Snippet
Alias rvsn Resolve-Snippet
Alias ssn Set-Snippet
Alias snsn Send-Snippet
PS> gsn
Directory: Microsoft.PowerShell.Core\FileSystem::C:\Snippet
Mode LastWriteTime Length Name
—- ————- —— —-
-a— 12/28/2006 2:51 PM 3254 BlogStyle.txt
-a— 12/28/2006 2:11 PM 245 Signature.txt
PS> set-snippet Test “This is a Snippet Test”
PS> gsn t*
Directory: Microsoft.PowerShell.Core\FileSystem::C:\Snippet
Mode LastWriteTime Length Name
—- ————- —— —-
-a— 12/31/2006 9:21 PM 50 Test.txt
PS> resolve-snippet test
This is a Snippet Test
PS> rvsn test
This is a Snippet Test
PS> snsn t*
VERBOSE: Sent [Snippet:t*] to Clipboard
PS> snsn
VERBOSE: Sent [Snippet:Signature] to Clipboard
PS>
The other (perhaps the most important) step in the Admin Development Model is to SHARE. Do you work and then share it with others so that we can all get better faster together. By sharing, others get the benefit of seeing how you solve problems and it gives others the opportunity to point out how you can improve your scripting or to make you aware of things that you didn’t know that you could do.
Last post of 2006. See you in 2007. Happy Scripting!
Jeffrey Snover [MSFT]
Windows PowerShell/MMC Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
0 comments