PowerShell Scripting Game

§ June 9, 2012 16:24 by beefarino |

After our May meetup of the Charlotte PowerShell Users Group, one of the members offered an exciting idea: run a single Scripting Games-style event at our next script club.  Normally we use our script club meetups to help each other with PowerShell issues, but many of our group members commented on how much they learned by solving those realistic problems during this year’s Scripting Games, so I thought it would be a worthwhile effort. 

And I was right: not only did we have a blast, but everyone walked away learning something.  In fact, it was such a hit that we’ve decided to run another event at next month’s meetup.

Running the Game

The game started with me laying out the rules:

  1. We will run the game “just like” a real Scripting Games event, except the problem will be smaller and you’ll have to solve it faster.
  2. You may work alone or in a group.
  3. Scripts will be judged by two independent PowerShell smartypants on a 5-point scale.
  4. The script with the highest average rating wins a prize.

Then I presented the game parameters; these were proposed by group member Brian Wilhite.  In order to be rated, the script must do the following:

  1. Query the local computer for all installed software from Microsoft.
  2. Export the software Name, Vendor, and Version into a CSV file in the temp directory of the current user.
  3. The CSV file should not contain any extra type information.

Game players had 30 minutes or so to work on the script.  In true Scripting Games fashion, after 15 minutes a few of the more experienced scripters began to offer guidance to those who needed it.  After about 40 minutes total, members presented their solutions to the group for discussion and rating.

Our two judges for the evening – Brian Wilhite and Ed “Scripting Guy” Wilson – rated each script independently.  After everyone presented their scripts, the winner (member Glenn Hurley) was chosen as the script with the highest average rating.  Thanks to our sponsor SAPIEN, Glenn walked away with a license for PowerShell Studio 2012!

All in all the event took about 2.5 hours to run, which left little time for our regular Script Club activities; however no one seemed to mind.  In fact, they got so much out of it they want to do another game at our next meetup.

What Worked

I think the game was a hit because 95% of our members are at the same level of PowerShell experience: little to none.  The problem was scoped correctly for them, and they walked away from the experience knowing a little more about WMI and filtering.  If they had been a more diverse group it would have been difficult to find a problem that would challenge everyone.

I also like the idea of having the members present their own scripts to the group.  Part of the user group experience is flexing those presentation muscles and putting your neck out in front of your peers in a safe and neutral environment.  Everyone seemed comfortable with it, which made me happy.

What Didn’t

A few things I want to change for next month…

I want to make members “submit” their scripts somehow.  It’s just too tempting to listen to all the critique and change your script before you present it.  Of course no one did that – I’m just thinking ahead to keep things fair.  Nothing fancy, even just emailing their script to me and presenting off of my laptop would work.

Instead of having the judges announce their ratings, I’m going to have them record them silently.  Critique will still be offered of course, since that’s why everyone is there.  But keeping the actual ratings a secret until the end builds suspense, and turns the game into a show. 

Which bring me to…

Where I Want This to Go

Other user groups in Corpus Christi and Arizona are asking about the game (which is why I’m writing this post).  I would *love* it if other groups started doing something similar.  If it catches on we can start adding some formality to the events and turn them into Iron Scripter competitions.  I think there is an opportunity there to foster learning and friendly competition year-round, with special Iron Scripter sessions at local SQL/Sharepoint/PowerShell Saturday events with prizes including the opportunity to claim one-of-a-kind titles like: “Iron Scripter – SQL Saturday #321”.

So, whatcha think interweb?



Introducing SeeShell

§ June 5, 2012 15:40 by beefarino |

SeaShellI’ve been pretty quiet lately and for good reason.  My company (Code Owls LLC) has just released their first commercial software product. 

The product is SeeShell, and it aims to fill a void that exists in the PowerShell space: visualizing data.

PowerShell gives you access to tons of data sources: WMI objects, performance counters, event logs, files, databases, system events, etc.  And with PowerShell remoting these data sources can be remote, multiplying the amount of data accessible by the size of your network.  Clearly getting the data is no longer a problem – PowerShell has evolved to fill this gap.

PowerShell is still limited in the ways it can show this data: tables and lists.  To be sure, these are very useful, but there are times when they are simply the wrong choice.

An Example of Awesomeness

Ever wanted to correlate an event log against a performance counter?  I’m not talking about a systems monitoring or Big Data situation – just a time when you wanted to snoop out a performance counter’s relationship to a set of events that appear in the event log.   Perhaps you have a hunch and just want to confirm it.  Maybe an app is consuming memory at specific events and never releasing it.

Think about how you might solve that problem on your own for a minute … no seriously, think about it for a minute …

… and then see how the problem is solved using SeeShell.  This script:

   1: import-module seeshell
   2:  
   3: {
   4:   get-counter '\memory\available bytes' -continuous | `
   5:     select -expand countersamples
   6: } | out-chart -name memory -type spline -plot CookedValue -by Timestamp
   7:  
   8: {
   9:   $i = 0;
  10:   while( $true ){
  11:     $e = get-eventlog -log application -source MyApp -newest 1 | `
  12:       where {$_.index -gt $i };
  13:  
  14:     if( $e ) {
  15:       $i = $e.index;
  16:       $e
  17:     }
  18:   }
  19: } | out-chart -name memory -type timeline -plot Message -by TimeGenerated

produces this visualization:

seeshell-demo1

that shows a clear relationship between the Starting Operations event logged by the application and a massive consumption of memory (around .5 Gigabytes) that immediately follows it. 

The visualization overlays the events logged by MyApp on to the performance counter data values. The events and the counter share a common axis: the timestamp of the counter sample or event.  SeeShell is smart enough to see that the X axis of the counter and the X axis of the event series are both datetimes, and assumes that you want them plotted on a common scale.

This is one small example of what SeeShell can do.  If you think this is cool, head on over to the SeeShell product demos page and check out the videos there.  Your mind will explode with joy.

Rationale

I’m a visual thinker – I find it far easier to intuit the meaning of data when it is presented visually than numerically.  Gauging the reactions of those who’ve seen a SeeShell demo, I can see that there are many others in the same boat.

I’m also lazy – not the procrastinating or passive-aggressive kind of lazy, but the good kind of lazy that makes me want to have flexible tools I can bend to my current needs.  It’s the reason I’ve globbed on to PowerShell for most of my software tooling on Windows. 

PowerShell provides a platform where:

  • tools are small and simple
  • each tool does one thing very well
  • simple tools can be composed to solve complex problems

SeeShell aims to be one of those simple tools, nothing more.