Summary: Microsoft Scripting Guy, Ed Wilson, discusses some of the early entries to the 2012 Windows PowerShell Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. One of the things that is always a challenge in creating the Scripting Games is trying to come up with the right balance between challenge, practicality, and appropriateness. In some respects, it is like attempting to walk a six inch I-beam 100 stories up in the air. It looks more precarious that it really is. But like one sage told Harry Potter, “You best keep your wits about you.” And so it is with the Scripting Games—you best keep your wits about you.

Complexity is not always required

This year, I tried. I really did try to reduce complexity. One of my goals for this year’s Scripting Games is to force you into the documentation (think about using the Get-Help cmdlet on a regular basis) so that you will discover some hidden gem hidden amongst the thousands of parameters that exist for the hundreds of Windows PowerShell cmdlets. Obviously, I was not entirely successful.

The point is this: In Windows PowerShell, lots of tasks are ridiculously simple when you have figured out the secret. Of course, when a parameter exists and it is documented in Get-Help, I am not sure that it really qualifies as a secret—but hey, who am I to argue?

Some things really are easy

It has become nearly a cliché since I first wrote that there are three important cmdlets in Windows PowerShell. These three cmdlets are Get-Help, Get-Command, and Get-Member. It was really important in Windows PowerShell 1.0 when I first set this down. For beginners, in Windows PowerShell 2.0 (and especially in Windows PowerShell 3.0), I do not think that Get-Member is quite as important as the other two discovery cmdlets. This is because each new version adds new cmdlets and additional parameters that bring interesting members to the foreground, therefore make discovering obscure members less important. Even with Windows PowerShell 3.0, using Get-Member is important for the more advanced scripter. But each new version makes it easier to perform common tasks, so digging into the object model becomes less of a daily task. I think that these days, I use Select-Object and Measure-Object more often than I use Get-Member.

Scripting is not required

I know they are called the Scripting Games, but this is more a legacy artifact of the VBScript world that spawned the first Scripting Guys and consequently the first Scripting Games. Nearly all of the Beginner events in this year’s Scripting Games (and many of the Advanced events) can be completed with a one-liner. To some, these famously (or infamously) powerful commands epitomize the elegance of the Windows PowerShell language. You can save a one-liner in a .ps1 file and voila, you have a script. Of course, you can also save your one-liner in a text file if you wish. In fact, I actually do both. I have lots of .txt files that contain various one-line Windows PowerShell commands that I spent a decent amount of time creating; and therefore, I wanted a way to save the product of my brilliance.

Keep in mind that at its most basic element, a Windows PowerShell script is simply a collection of one or more Windows PowerShell commands. If I can type it in the Windows PowerShell console, I can place it in a .ps1 file, and I have a Windows PowerShell script. This is one of the great things about Windows PowerShell—it is a shell. It is also a scripting language. It is also a shell. It is also a scripting language. It is like a chocolate peanut butter cup—it is chocolate, but it is also peanut butter. When I teach a Windows PowerShell class, I generally spend the first two days working exclusively inside the Windows PowerShell console. But, I make it really clear to the students that everything we are doing applies to Windows PowerShell scripting. I love a tweet Jeffrey Hicks made when he showed dumping the commands from command history to a .ps1 file and automatically creating a script from his Windows PowerShell console command history. This is the perfect example that working interactively at the Windows PowerShell console is, in a real sense, scripting.

Now, let’s get back to my Windows PowerShell classes. Even after I finally introduce the Windows PowerShell ISE, I still end up doing many examples directly in the Windows PowerShell console. One reason is because the Windows PowerShell console has a built in transcription tool, and the Windows PowerShell ISE does not. Being able to hand out a transcript of everything that I typed in a class makes a great teaching tool. It also prevents writer’s cramp on behalf of the students.

Sometimes it seems that students are disappointed they do not do more traditional scripting in my Windows PowerShell classes. But the simple fact is that in the Windows PowerShell era, quite often scripting is not required. Many traditional tasks that required lengthy and complex scripts in the VBScript world, are simple one-liners in Windows PowerShell. Like I said, if you miss scripting, go ahead and save your one-liners as .ps1 files.

A great work ethic does not require lengthy scripts

In Windows PowerShell, often you do not need to write a big, long, complex script. In fact, I would say that on many occasions, this is true. It has quickly become the rule, rather than the exception. I can also say from experience, at times I am still too quick to fire up the Windows PowerShell ISE. After all these years of exclusively writing Windows PowerShell on nearly a daily basis, I am still surprised at how easy things can be accomplished. So what am I really saying? In Windows PowerShell, often more work goes into producing a one-liner than in creating a 15-line script. When I am making presentations to a Windows PowerShell User Group, I am often asked questions, and I will respond by firing up the Windows PowerShell ISE and dashing off a quick script to illustrate the technique I am trying to explain. At times, someone in the group will ask why I did not do XYZ. Often the answer is that I did not think of doing XYZ. Windows PowerShell is so powerful, that there is often more than one way of accomplishing the same task.

In the end, it is about getting work accomplished

In the real world, and in the real world of the 2012 Scripting Games, the end game is to accomplish work. As long as a script or a command accomplishes the task at hand, it works. Jeffrey Snover once remarked that no one learns Windows PowerShell simply to learn Windows PowerShell. Rather, they use Windows PowerShell to solve a specific problem. This is one thing I try to reflect in the Scripting Games—real-world problems seeking real-world solutions. But I do disagree with Jeffrey in one important respect. I know lots of people who have absolutely fallen in love with Windows PowerShell simply because Windows PowerShell is fun, powerful, and a great tool. Many people, including myself, find ourselves playing with Windows PowerShell and exploring the intricacies of Windows PowerShell because of this fun factor. The person who wrote Space Invaders in Windows PowerShell did not do so because his boss asked him for a Windows PowerShell port of Space Invaders. Rather he did it because Windows PowerShell is so fun to play with, and it is great that it has the ability to create fun games like Space Invaders.

Great solutions to regular problems

One reason I love the Scripting Games is that I also view myself as a learner. Whereas I write solutions to each of the tasks, I am often surprised at the sheer elegance of some of the solutions that come in from the participants. In many cases, I look at code and wonder, “Does that work?” I stare in amazement when it really does. This is one of the most exciting things about Windows PowerShell—there are many many many ways of accomplishing the same tasks. The great thing about the 2012 Scripting Games is that you work out solutions to real-world problems. I have had numerous emails from participants in prior Scripting Games where they thanked me for the games and stated that they had already had occasion to use a script at work that they wrote for the games. Cool. Learning that is fun, and useful—a great concept.

Join me tomorrow when I will continue to talk about some of the concerns I saw while grading scripts.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy