UCS Power Scripting Contest Guide

Document created by jeffoste on Mar 25, 2014Last modified by bishield on Apr 8, 2014
Version 3Show Document
  • View in full screen mode

UCS Power Scripting Contest Guide


March-May 2014





Welcome to the 2014 UCS Power Scripting Contest. This Guide is written to help you understand quickly how the contest works, and what you can expect. The complete terms and conditions can be found in the official rules document.  Any member of the Cisco online community can participate, however, only US residents are eligible for prizes.  Cisco employees are not eligible for prizes identified in this Guide.   For detailed eligibility rules please refer to the official rules document.

About the contest


To participate in the contest join a Cisco community at http://communities.cisco.com.

To participate in the contest navigate to the UCS Power Scripting Contest group. (https://communities.cisco.com/ucsscripting ).  You can participate by making a submission, asking a question, commenting, reading the content and voting. You can make multiple submissions.

The group is your resource to ask questions, get answers, find startup kits, tutorials, videos, and other resources like the UCS Platform Emulator.  Please report any issues in the discussion area of the group. We’ll work hard to keep everything working as smoothly as possible.  UCS experts will monitoring the group for questions and provide guidance.

Entry submission

To submit an entry, login to the UCS Power Scripting group. Fill out the submission form and upload this to the group.   Once submitted, a moderator will ensure it is a valid submission, and then post it to the group.  Comments and questions are then possible on the submission. All submissions will be published and considered part of the public domain.  You can submit an entry through 11:59PM PT May 11th, 2014.

Important Dates




March 25

Contest starts – Group open for participation

April 10

Intermediate Prize #1 Announcement

April 24

Intermediate Prize #2 Announcement

May 8

Intermediate Prize #3 Announcement

May 11

Deadline for Contest submissions

May 14

Finalists Announcement @ Microsoft TechEd

May 20

Winner Announcement @ CiscoLive



Cisco Panel – (Pick finalists and intermediate prize winners)

The judging panel will consist of Technical Marketing Engineers from Cisco.

Celebrity Judges

  • Jeffrey Snover – Architect of PowerShell
  • Don Jones - PowerShell.org
  • Rob Willis  - Author of PowerShell deployment toolkit
  • Hal Rottenberg - PowerShell MVP
  • Thomas Maurer  - Hyper-V MVP

Judging Criteria for picking finalists

After the entry submission deadline, our expert judges will go to work. We will use a detailed judging criteria as outlined below, although our judges also have some leeway to exercise personal discretion.

Scoring Criteria:
- 20 Points: Documentation
- 20 Points: Re-usability
- 20 Points: Quality of coding
- 20 Points: Efficiency of coding
- 20 Points: Creativity
- 10 Points: Bonus Points (For cool factors)

Disclaimer:  Sometimes, some people prefer things one specific way, and others would prefer to have those things done another way. A judge may knock off points for something you feel you got absolutely right.   We have multiple expert judges with the intent of giving as fair a score as possible.

We’ve tried to make the scoring criteria as objective (e.g., not subject to opinion) as possible, but there’s always going to be room for interpretation.  Scores for individual submissions will not be published.


Judging criteria for Prizes


Prize distribution:

All prizes will be distributed at Cisco Live on May 20th during a reception held in the DevNET Zone 5-7pm for winners in attendance. Prize winners not in attendance will have their prizes shipped to them.


Grand prize:

Apple iPad Air w/ WIFI 32 GB Space Gray

Following selection of the top five winners, the five-member panel of Celebrity judges, in combination with members of the UCS Community group (“Community Group”), will determine the Grand Prize winner based on a 2000 point grading scale:

- The PowerShell Panel shall award a total of 1000 points, with each judge allocating 200 points among one or more finalist(s).

- The Community Group shall award a total of 1000 points, such points to be allocated the same percentage amount as the votes cast (for example, 33% of Community Group votes translates to 330 points). 


Intermediate prize(s): April 10th, April 24th, May 8th 

Beats by Dr. Dre in ear headphones

In addition to the Grand Prize, three Intermediate Prizes will be awarded by the Cisco Panel based on:

a) Most Active Contributor (first Intermediate Prize)

b) Most Powerful Single Line Script (second Intermediate Prize)

c) Best Cross PowerShell Module Integration (third Intermediate Prize)



The Grand Prize finalists and intermediate prize winners will be announced on May 14, 2014 in the Cisco booth at Microsoft TechEd.  All prize winners will be announced on May 20, 2014 at CiscoLive. The Intermediate Prize winner(s) will be announced in the community group.



Scripting Guidelines


The scripting guidelines are adapted with permission from the Powershell.org Scripting games and encourage best practices for coding.

They’re not rules, and judges won’t universally agree on every one. So don’t think of this as a magic checklist that will make you win. You don’t even need to force yourself to do all of these things – but keep ‘em in mind.

  • We love to see error handling. But we don’t like error suppression. That is, if an error occurs, we should either see the error, or you should be doing something about it like logging it or displaying an alternate message. The exception: it’s okay to suppress an error that means “everything is going fine.” For example, you try to delete a file that doesn’t exist, and get an error. Well, that’s fine. At the end of the day, the file isn’t there, and that’s what you wanted. If you do choose to handle an error, make sure you’re doing so intelligently. Don’t wrap your entire code in a big Try{} block. Only wrap the commands that you anticipate having an error, and Catch{} (and handle) that error.
  • We hate seeing people do more work than is necessary. For example, you shouldn’t ever prompt the user for a missing parameter. Use PowerShell’s Parameter() decorator to mark the parameter as mandatory.
  • We love self-documenting scripts. That doesn’t just mean comments – although those are pretty awesome, too, especially comment-based help. Using full command names, full parameter names (and no positional parameters), stuff like that makes a script more self-documenting. Other examples are less obvious. Here’s one: if you’re accepting input arguments, do so via declared, named parameters, not by using the $args collection. $ComputerName (a named parameter) is a lot more meaningful than $args[1].
  • We hate inconsistency. In whatever you write, try to be consistent with what’s already in PowerShell. A parameter named –ComputerName is great; a parameter named –ComputerNames is not great. Nothing else in PowerShell uses the plural, so you shouldn’t either.
  • We love scripts and commands that output objects and not formatted text. That means you shouldn’t embed a Format cmdlet in your script, nor should you use Write-Host in most cases. Exceptions are made by the name of your script or command: we’d expect a command named Show-Info to show information on the screen, implying Write-Host is being used. A command named Get-Something, on the other hand, should output unformatted objects.

We’ll pipe those to a Format command ourselves if we want them formatted.

  • We hate scripts that are hard to read. With scripts (as opposed to one-liners), focus on neat formatting. Avoid the backtick (`) as a line continuation trick because that little bugger is hard to see.
  • We love elegance. For example, a lot of folks think the expression "$computer cannot be reached" is easier and less complex than ("{0} cannot be reached" –f $computer) even though those two expressions produce the same result. Both of those are prettier than ($computer + “ cannot be reached”). Just keep that in mind.
  • We hate redundancy... well, not in server farms, but definitely in code. For example, in the command Get-Service | Select-Object –Property @{n='Name';e={$PSItem.Name}} – is all that really needed? Couldn’t you just go for Get-Service | Select-Object –Property Name and get the same effect with less typing? We’re not saying this kind of thing will land you on a judges worst list, but for some judges we know it’ll keep you off their Best list.
  • We love functions that use [CmdletBinding()] and take advantage of the features it enables. For example, if you’re manually setting something like $VerbosePreference or $DebugPreference at the top of your script... then you’re missing the point.



  • We hate scripts that pollute the global scope. It’s not yours. We don’t track mud into your house, don’t litter up our global scope with your variables. Exception: if you write a script module that politely adds global “preference” variables, and then politely removes them when we unload it, that’s cool.

What Not to Over-Obsess About


In some event scenarios, we’ll give you an example of the expected output. It’s an example, not a mandatory deliverable. Basically, so long as you have all the right property names, and the values look legitimate, you’re fine. They don’t need to be in the order we list them, and they don’t need to exhibit the exact same formatting, unless the event scenario calls out a specific requirement. In many cases, the example output is formatted to fit in a PDF – it’s gonna look different in the PowerShell console, and we’re cool with that.

Let’s be clear on something: if your goal going into the contest is to get on every judge’s Best list... then you’re playing for the wrong reasons. This is a learning event.

Here’s another way to think about it: you’re going to have your script peer reviewed by dozens of people, and possibly get some expert feedback from some of the biggest names in the industry. That alone is worth participating. The prizes are just icing on the cake!

DO NOT treat the previous list of guidelines as some kind of Secret Checklist for Winning. It isn’t. They’re pretty good ideas in general, but they’re not the only good ideas, and like all rules they come with their own exceptions.

DO obsess about finding a clever, elegant, well-written solution to each problem. Knock our socks off!