If anyone's not yet aware, Pester recently released a new major version: 5.0. This comes with a slew of breaking changes and some fancy new functionality, and some pretty solid performance improvements to boot. A user in the PowerShell Discord server recently came across some tests written for Pester v4 that they wanted to refactor for use in Pester v5. I decided to take a thorough look, and it proved to be quite a bit more complicated than I'd initially expected, mainly due to the way the tests were written.

Before we even begin, let's just take a moment to remember something very important. In PowerShell, everything is an object. Although you'll normally see scriptblocks used to declare functions, or perhaps as a command parameter, and so on… they are themselves just an object.

I've always been a fan of using subexpressions to tidy up my code. They tend to help me collect and store output where I need it, without requiring that I add complex loops and delve into .NET collection types. The pattern seems to be a bit of a rarity among a lot of other scripters I see, so I thought I'd write a post on subexpressions and all the ways you can use them!

Well, it's certainly been a while since I posted on here. Trying to get back into the swing of things for 2020 now that I'm mostly settled in at my new job. So, let's take a look at a classic problem that never fails to confuse folks just getting into PowerShell. I've also seen plenty of more experienced folks trip over it quite a lot, so here we are.

In case you couldn't already tell, I rather like playing around with regex in PowerShell. There's something very enjoyable about poking it in just the right way to get it to do exactly what you want. I've already talked a bit about how we can use it to create PSCustomObjects.

There are a few different kinds of errors in PowerShell, and it can be a little bit of a minefield on occasion. There are always two sides to consider, too: how you write code that creates errors, and how you handle those errors in your own code. Let's have a look at some ways to effectively utilise the different kinds of errors you can work with in PowerShell, and how to handle them.

Through a bit of fiddling with PSWordCloud I've found some rather neat features of System.Drawing that are a little on the weird side, and also not the most discoverable, so I figured I should talk a little about them.

Functional languages differ from typical, more concretely object-oriented languages in a few important ways. One of the simplest to point out and demonstrate is that in most functional languages, every code path returns a value — there's effectively no such thing as a method that exists purely to create some side effect like there often is in object oriented languages.

It's been a little while now since I started contributing to PowerShell Core, so I thought it's probably an apt time to talk about it a little bit. I've come to the conclusion that sooner or later, we should probably all look to see if we can contribute anything to whichever tools we happen to be using. After all, there really is no one better suited to guide the development of the tools you're using on a daily basis than you. I'll try to break down why I think we should all look to contribute a little something back to the tools we use in our day-to-day lives wherever we can.

It's been a handful of months since I started working on the PSKoans module, so I thought I'd take the time to set down the story behind the PSKoans module. It borrows from some koans modules from other languages, and the concept of koans as a programming tool seems to originate from a Ruby project — although at least a handful of other languages now have koan libraries available for learners.

PowerShell's Abstract Syntax Tree, or AST for short, contains a full listing of all parsed content in PowerShell code. This means that it contains just about everything you need to be able to figure out precisely what is going on in someone's code — all without ever having to delve into regex or other text parsing messiness. About the only thing it doesn't contain are code comments, but in this instance that's not what we're here for anyway.

When dealing with some of the more interesting .NET code classes, and also in regular PowerShell use, one often finds that we can come to a point where we feel as though we need half a dozen parameter sets, just to handle the different ways that a user might want to input rather important parameters for our functions. Thankfully, PowerShell has a very effective answer for this: [System.Management.Automation.ArgumentTransformationAttribute].

Sometimes I stumble across a particularly intriguing idea which just captures my attention until I finish making it work. This was suggested by @sifb in the PowerShell Slack & Discord group after I detailed the process of writing Export-Png here. This time around, his suggestion was to take the code from Export-Png and use it to create a word cloud generator.

An all too common pattern I see get used in some more advanced scripts is the use of dynamicparam where it isn't needed. Unfortunately, dynamicparam can be complicated, quirky, and frustrating to work with, and is really best avoided in a majority of cases when creating advanced functions or script cmdlets, as I've occasionally heard them called. Thankfully, there are a few alternatives that are often a good bit easier.

ShouldProcess is something that a lot of folks get wrong, even some of the more seasoned scripters. Even some official modules don't quite handle it properly, perhaps most notably the Set-ADAccountPassword cmdlet from the ActiveDirectory module — more on that here — although it is more commonly seen in scripts and third-party modules. Let's take a look at some of the ways you can get it terribly wrong, and then how you need to be doing it.

This isn't exactly a common requirement, but it turned up as I was working on PSKoans. Essentially, I had a slight problem: the koans in AboutDiscovery that deal with Get-Command were consistently finding commands that were intended to be hidden to the user; commands internal to the PSKoans module itself. So, I needed a way to have the koan files evaluated outside the module scope.

PowerShell is built directly on top of C#, written in C#, and has access to almost everything that .NET can give you. As a result, a lot of PowerShell syntax has very similar C# analogues, and much of C# can be translated into usable PowerShell code without much hassle.

Regex is often considered something of a black art, and not without reason. It is, arguably, the antithesis to PowerShell in terms of syntax. It's terse, unforgiving, and difficult to get meaningful debug data out of. However, sometimes you just have to parse text, and there often is no better tool than some well-applied regex.

Thankfully, these days a majority of our functions and cmdlets are kept tucked away in easily-installed modules. However, on occasion I have still found myself wishing I could just pull a function directly into a remote session to use.

PowerShell sits in quite an unusual place in terms of classifying programming languages. Most languages can be pretty easily categorised; C# is an object-oriented programming language. Haskell is the classic example of a functional programming language.

I'm sure we've all been there. Some command takes a solid 30s to run to completion, and then… just dumps all output to the console. And it is only then that we realise that we needed to process or reuse that output.

PowerShell has had only very basic support for numeric literals for longer than I've been using it, having only two basic suffixes and a handful of numeric syntaxes.