PowerShell for Developers So you’ve decided to write a bunch of commands to help automate the administration of ____. Awesome! Let’s try and make sure you get off on the right path, with this high-level overview of command design.
Start with an inventory
You’ll need to start by deciding _what commands to write, _and an inventory is often the best way to begin. Start by inventorying your nouns. For example, suppose you’re writing a command set for some internal order-management system. You probably have nouns like Customer, Employee, Order, OrderItem, CustomerAddress, and so on. Write ’em all down in an Excel spreadsheet, one noun per row.
Then inventory your verbs. For each noun, what can you do with it? For example, you can probably create orders, so a New-Order command will be needed. Make a “New” column in your spreadsheet, and put an “X” in the row next to the Order noun. However, you probably can’t remove an order from the system, so although your spreadsheet might have a “Remove” column to cover things like Remove-Employee, that column won’t get an “X” in the Order row. Orders might be voidable, though, so what’s a good verb for that? https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx has the official verb list, but there’s no “Void” or “Cancel” that seems appropriate. Don’t go making up new verbs!!! Instead, it might be that Set-Order could be the answer, enabling approved changes to orders, including cancelling them (but retaining the record).
Finally, pick a prefix for your nouns. If your order system is named “Order Awesomeness,” then maybe OAwe is a good noun prefix, as in Set-OAweOrder. The prefix will help keep your command names from bumping up against other people’s, so making sure that noun prefix is pretty unique… is pretty important.
I’d appreciate your help in testing HTTPS/SSL here on PowerShell.org. Right now, it’s “voluntary,” meaning you have to explicitly ask for https://powershell.org. If you have any problems, please note them in a comment on this article.
Some notes and known problems:
- Most pages will not show the “lock” address bar icon in your browser, because we’re delivering mixed content. For example, the site logo is being hardcoded as http:// by some Javascript in our theme, which I need to sort out.
- Your connection will be to CloudFlare, which is who issued the certificate you’ll see. We’ve also SSL’d the traffic between them and our server using a DigiCert SSL certificate. We’re also going to enable client certificate authentication, so our server will only deliver content to CloudFlare, which then delivers it to you. That’s ahead.
I think we can solve the mixed-content problem by forcing HTTPS, which is easy, but I want to make sure it’s otherwise working before taking that step. We already have a WordPress plugin in place that’s rewriting http:// or https:// with just // in URLs, but there’re a couple of places where that plugin isn’t able to help, and that’s why we’re delivering mixed content still.
I’ll point out that this is mainly a bonus-points project; because almost everyone logs into the site using an external account, we don’t store many passwords (and thus don’t transmit them in the clear or otherwise). We don’t store or transmit any other personally identifiable information. Still, SSL has some other benefits, and it shouldn’t hurt to have it on, so we’re giving it a shot.
Thanks!
Quick as you can, can you explain what each of these different parentheses-, brace-, and bracket-laden expressions does?
${save-items} ${C:tmp.txt} $($x=1;$y=2;$x;$y) (1,2,3 -join '*') (8 + 4)/2 $hashTable.ContainsKey($x) @(1) @{abc='hello'} {param($color="red"); "color=$color"} $hash['blue'] [Regex]::Escape($x) [int]"5.2" When you’re reading someone else’s PowerShell code, you will come across many of these constructs, and more. And you know how challenging it can be to search for punctuation on the web (symbolhound.com not withstanding) !
That is why I put together a reference chart containing all of PowerShell’s symbology on one page. making it much easier when you need to look up a PowerShell symbol as you read code–or to browse for the right construct when you are writing code.
Download the Complete Guide to PowerShell Punctuation wallchart from here.
Join the Mississippi PowerShell User Group virtually on Tuesday, June 14th 2016 at 8:30pm Central Time when Microsoft MVP Robert Cain will be presenting “Pester the Tester: PowerShell Bugs Beware!”.
So you’ve been developing PowerShell for a while, or perhaps you’re taking over maintenance of an existing set of scripts. It would be great to get extra confidence in your scripts through testing, but how? You’re in luck, there’s a new module in town, Pester!
Pester is a friendly testing framework designed for testing your PowerShell scripts and modules. In this session you’ll be introduced to Pester. You’ll see how to use Pester to uncover bugs, as well as using it for test driven development. Make your own PowerShell more robust through the use of Pester. Kill those PowerShell bugs, dead!
Visit the Mississippi PowerShell User Group website to learn more about Robert and to find out more details about this month’s meeting.
The Mississippi PowerShell User Group Meetings are held online (via Skype for Business) on the second Tuesday of each month at 8:30pm Central Time and are free to attend. The system requirements to attend these online meetings can be found on the MSPSUG website under the “Attendee Info” section.
Register via EventBrite to receive the URL for this meeting.
Note: It is not necessary to live in Mississippi or join our user group to attend our meetings or present a session for our user group.
µ
PowerShell 5 brought class based DSC Resources, which majorly simplifies the process of writing custom DSC resources.
During my time working on some custom resources, I developed some tips a long the way which should save you some time and pain during your DSC journey.
The tips cover:
- Structuring your class based DSC Resources
- Making it easier to get IntelliSense based on your DSC resources without constantly copying them into the module path
- Using PowerShell ISE IntelliSense when writing DSC configuration
- Troubleshooting resources which aren’t being exposed correctly from your DSC Module
- Testing classed based resources with Pester
Head over to https://hodgkins.io/five-tips-for-writing-dsc-resources-in-powershell-version-5 to take a look at the tips.
If you’re deep into DSC and delving into DevOps, then my summer “Camp” event is probably meant for you - and now there’s a detailed agenda, overall agenda, and full event brochure. This is a really limited event - under 20, including product team participants, and we’re down to just a few seats left.
DevOps and DSC Camp Detailed Agenda
Putting on an event like the PowerShell and DevOps Global Summit involves a lot of planning. We started the planning process for the 2017 Summit BEFORE the 2016 Summit started!
We have to work so far in advance that we’re taking guesses at the topics that will be of high interest next April – remember that we fix the agenda 6 months before the actual Summit.
Part of the process of creating the agenda is that we publish a ‘Call for Proposals’ where we ask potential speakers to submit session proposals. We then use those proposals as the basis of the agenda. Session proposals can be taken as they are or we may suggest changes to the speaker to ensure a more cohesive agenda.
Having a platform that enables ChatOps can be a game changer. You can quickly see changes, alerts, build status, discussions, emergency chats, and more, all in a single, searchable interface. If you can sift through the gifs.
Bots are a hot topic these days, and and it’s well worth checking out Matt Hodgkins bit on integrating PowerShell with Hubot. Bots are a great alternative to trying to spin up a web front end for PowerShell.
On top of bots, systems like Slack often offer a wealth of integrations, allowing you to hook into systems like Nagios, PagerDuty, GitHub, Trello, and many others.
Occasionally, you might have something that doesn’t integrate natively. Maybe you want to integrate Slack messages into your SCOM command notification channel, your CI/CD build process, orchestration system, configuration management systems, or even ad hoc scripts.
If you’re using Slack, check out the Slack API methods, or an incoming webhook. With the API in particular, you can do some handy stuff!
If you like the idea of re-usable tools and abstraction, check out PSSlack, a PowerShell module that we’re starting to build out, which can simplify sending messages, searching messages, and more.
By the time you are using PowerShell to automate an increasing amount of your system administration, database maintenance, or application-lifecycle work, you will likely come to the realization that PowerShell is indeed a first-class programming language and, as such, you need to treat it as such. That is, you need to do development in PowerShell just as you would with other languages, and in particular to increase robustness and decrease maintenance cost with unit tests and–dare I say–test-driven development (TDD). I put together several articles on getting started with unit tests and TDD in PowerShell using Pester, the leading test framework for PowerShell. This series introduces you to Pester and provides what I like to call “tips from the trenches” on using it most effectively, along with a gentle prodding towards a TDD style.
Part 1: Getting Started with the Pester Framework
Starting with the ubiquitous “Hello, World”, this introduces Pester, showing how to execute tests, how to start writing tests, and the anatomy of a test.
Part 2: Mock Objects and Parameterized Test Cases
To be able to create true unit tests, you need to be able to isolate your functions and modules to be able to focus on the component under test; mocks provide great support for doing that. Another topic of “power” unit tests is making them parameterizable, i.e. being able to run several scenarios through a single test simply by providing different inputs.
Part 3: Validating Data and Call History
The final part of this series provides a “how-to” for several other key parts of Pester: how to validate data, how to determine if something was called appropriately, and how to address a particular challenge with Pester, validating arrays. I’ve included a library for array validation to supplement Pester.
For a more general treatment of unit tests, I refer you to Roy Osherove’s canonical text on the subject, The Art of Unit Testing.
This is a follow up to Jacob Moran’s article Keeping it simple - Line breaks in PowerShell.
I am strongly in the pro backtick camp, but I won’t get into that debate here. Instead, I’ll cover more of the common ground between the two camps.
In addition to after a pipe, there are many, many more places where you can put in a line break without a backtick and without breaking your code.
As a rule of thumb, any spot where the syntax unambiguously must be followed by something more, you can break the line.
As an extreme example, this:
