Summary: Windows PowerShell MVP, Jim Christopher, shares a mini-Scripting Games event from the Charlotte Windows PowerShell User Group.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome today, guest blogger, Jim Christopher. Jim is a Windows PowerShell MVP and the leader of the Charlotte Windows PowerShell User Group. He was instrumental in creating and hosting two Windows PowerShell Saturdays in Charlotte, and he is also an all-around nice guy. Let’s see what Jim has to say about himself…

I am a four-time Windows PowerShell MVP, and I help run the Charlotte PowerShell Users Group. I currently own and operate Code Owls, LLC, a small software and services company focused on automation and integration projects. I maintain a blog at beefycode—serving all of your beefy code needs, and you can follow my inane ramblings on twitter (https://twitter.com/beefarino). If you’re a real glutton for punishment, you can find some of my work at: GitHub: Jim Christopher, beefarino.

Now on to the little Scripting Games…

Communities are hard. They’re hard to start, and they’re harder to keep going. The Charlotte PowerShell User Group has been blessed with a strong core membership in addition to regular attendance by the Scripting Guy and Scripting Wife. But there is something else that keeps members coming back.

We’ve all but abandoned the expert-comes-in-and-presents-over-pizza format. It was far too difficult to find speakers who could address the needs of more than a few members. Instead, our regular meetings now take the form of a short Scripting Game. These games are simple to put together, easy to run, and they benefit every attendee from the Windows PowerShell noob to the MVP.

In this post, I will write about our most recent little game in June 2014. You'll learn about how I designed it, how it was run, and the end effect on the group. My goal in writing this is to reach out to other community organizers who may be struggling, and to get other users groups to organize their own little Scripting Games.

Designing a little Scripting Game

There are a few key things to keep in mind when designing a little Scripting Game.

The main objective of a little Scripting Game is to get your group members thinking and tinkering.

They need a problem to solve that requires some effort and strategy. Generally, I try to focus the game on a very general technology with which all members would be familiar, such as the file system. Alternatively, I’ll choose a focus that I wouldn’t expect any member to have experience with, such as image data processing. I’ve found both to be equally effective at getting members actively scripting. For our June meetup I came up with a simple scenario that offered creative leeway:

Write a script that updates a specific file periodically. At the same time, the script should try to prevent other scripts from updating their own files.

I like this scenario for several reasons. First, it requires members to divide their attention. Their script has two opposing problems to deal with:

• They need to update the file to win, but they also need to prevent others from updating their files. Moreover, they need to cope with the fact that other scripts will be attempting to stop their script in devious ways.
• The core technologies involved in the game are very accessible in Windows PowerShell.

I could immediately think of several ways to solve the problems. I might keep my script running by “forking” it—that is, by having the script spawn another Windows PowerShell process that starts the script again, or perhaps by running parts of my script as jobs. I might try to prevent other scripts from updating their files by killing any Windows PowerShell process that isn’t my own or by modifying ACLs on the files they’re trying to write.

In short, this game has a lot of potential solutions, and their effectiveness depends entirely on the tactics used by other scripters. It’s a slam dunk for a little game!

The little Scripting Games need to be able to be completed in an hour or so.

This really limits the level of complexity you can put into the game’s objective. I’ve learned to keep little Scripting Games more open-ended than, say, an Iron Scripter or week-long Community Games event. Fewer requirements also allow scripters to be more creative with their approaches. The scripter’s goal should be to solve a problem, not to check requirements off a list for a judge.

It needs to be fun.

This is vital. No one at the game wants to spend an evening doing more work. If they did, they’d have stayed at work. So I try to come up with games that foster a sense of competition. Sometimes it is direct, such as this game from June or one of the games we ran last year where we wrote scripts that played rock/paper/scissors against one another. In other cases, the competition is more subjective, and we have a set of judges determine a winner.

In any case, scripters know that they are expected to show their script and explain their approach to the group. This helps everyone learn from everyone else in a safe, constructive environment.

Finding the right combination of these elements can be difficult. It help me to brainstorm ideas with members of the group and keep a running list of ideas from which to draw.

Running a little Scripting Game

After you have selected a problem for your little game, you’ll need to think about how you’re going to run it. Part of this is building the prerequisites for the game. For instance, in our June meetup, I needed a server image on which to run the scripts because I really didn’t want our group members trashing my laptop. So I set up a disposable Microsoft Azure instance of Windows Server 2012 R2 that they could trash instead.

In other events we had virtual Active Directory labs available. Finding these resources and making them available can be the hardest part of running the game, and it typically takes the longest chunk of preparation time.

On the night of the game, we follow a simple procession:

1. Cover the general rules

2. Discuss the problem

3. Script!

4. Combat (or judging)

5. Present the scripts

Before every game I go over the general rules for the game. These are for newcomers mostly, but they also serve as a gentle reminder to our regulars that the game is meant to be fun. The rules are simple:

• Use any resource at your disposal.
• Work in teams or alone.
• For games involving judges, their decisions are final.
• Complaining is not allowed.
• You must share your solution with the group.

When we’re all on the same page with regard to expectations, we dig in to the game’s problem. This is where I spell out the specific requirements for the game and explain how a winner is determined. For our June meetup, these requirements were as follows:

1. Write a script that does the following:

• Updates a file periodically. The file should be found at the path C:\game\<yourname>.txt. The contents of the file do not matter, only the last update time.
• Inhibits other scripts from updating the file.

2. Use FTP to transfer your script file to the Azure VM.

3. The winner is determined by who is the user with the most recently updated file after a specified period of time.

After everyone understands the game parameters, we enter the scripting phase. This can take anywhere from 15 to 60 minutes depending on the game. In June, we had some scripters submit scripts in less than 15 minutes; others wanted more time after an hour. I find it best to set a hard upper limit on time; otherwise, some scripters will try to boil the ocean to solve the problem.

When the scripting is complete, the game enters the combat/judging phase. For the June script battle, this was a simple matter of firing up each script in its own Windows PowerShell process and letting them run unattended for a few minutes. In other games, this involves collecting the scripts for judging.

In either case, the most important factor is that there be a clear winner. This doesn’t always happen of course, and there are various ways to cope with that situation. I personally like setting an arbitrary metric for tie-breakers, such as “the fewest lines of script wins.”

When the battle is over, it’s time for scripters to learn from each other. Typically the winner starts. The winning script is displayed, and the scripter stands up and walks the group through the script and their thoughts behind it.

This is by far my favorite part of the evening. I’m always shown something new, either an approach I’ve never considered or a language feature of which I was unaware. In June, I learned more than I ever wanted to know about ACL management!

And the learning doesn’t stop with the event. I make the problems and scripts available to all of the group members via our Charlotte PowerShell Users Group Meetup site.

The untapped potential

I would love to see other Windows PowerShell Users Groups start running little Scripting Games. The benefits are real and immediate for your members, and it offers a new bond in your community that you won’t get any other way—the mix of competition and support between members is simply magical.

Which makes me wonder about what could come next…

If your local Windows PowerShell Users Group is running games, as a community we can get organized. We can have tournaments, brackets, titles, and badges. The opportunities for learning and sharing knowledge in this framework would be amazing.

The community has done itself a great service with the official Scripting Games. So who’s interested in taking it to the next level?

~Jim

Thank you, Jim. This is soooooo cooooool!

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