The Admin Development Model and Send-Snippet

The Admin Development Model and Send-Snippet

  • Comments 4

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:

  1. It uses the standard Verb names so it is easy to learn, understand and remember
  2. It leverages the standard alias shortcuts to provide aliases were are easy to learn and remember.
  3. 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]
  4. 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

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • PingBack from http://adminspotting.net/headlines/scripting/The-Admin-Development-Model.html

  • &lt;Updated script on 1/1/2007 to reflect fixes suggested by James Manning&gt; Dennis Verwiej is doing

  • Hi,

    I think the Powershell is a giant step forward from cmd.exe. But I think, it is a pitty, that you mainly address to admins. I am just a regular windows user and I am mainly using the command shell, because most part of my job is solving problems by scripting. At the job we first mainly used VMS then added Windows. So scripting is also part of the job for many of my collegues (though none of them is a programmer). The cmd.exe is a very poor environment to do the job, so I liked the powershell the first time I used it. But there are three things which bother me:

    1. It seems to me, as if it is still cmd.exe - interacting with the Powershell is very poor compaired to bash or 4NT.

    2. It does not run on Windows2000 - we will definitly not change to a newer Windows version at my company in the next years, since Win2000 does the job and WinXP and Vista do not bring any advantages for a regular user in a company. So it would be great, if it could run on any platform which runs .Net.

    3. It is obvious, it is not made for regular users. I instead see the PowerShell as the central place for all sorts of user defined automation on windows. In MSOffice, you have VBA for automation, but in practice, it is more comfortable to use automation from outside of an application, because most of the time, the application does only a small part of the job, the rest is done by other applications and self written scripts. I see Powershell scripts as a glue to glue several applications together to do a certain job.

    I hope, this little comment gives you an idea, how the Powershell could be so much more than just an admintool. Not only admins run around with their hair burning ;-)

    Regards

    Thomas

  • the design of this page is very hard to read - the lines of text overwrite each other!

Page 1 of 1 (4 items)