Building Advanced PowerShell Functions and Modules

Understanding Advanced Function Parameters
Hello. This is Adam Bertram, and this is the module Understanding Advanced Function Parameters. In this module, we'll dive headlong into building smart parameters in your advanced functions. By the end of this module, you should know everything there is to know about parameters, their attributes, and why you may want to use various attributes in your advanced function parameters. In this module, expect to learn a ton about parameters. We're going to cover all facets of function parameters. Since you should already know the purpose of a parameter, the majority of this module will be covering using parameters to enforce and to validate input. Near the end, we're also going to go over parameter sets and why defining sets of various parameters may be a good thing. Have you ever seen Crocodile Dundee? It's about this Australian named Mick from the bush that goes to the big city. There's this one scene where he gets mugged by a guy with a switchblade. Mick sees the little blade and then pulls out this enormous buck knife and says, "Now, this is a knife. " How's my Australian accent? This is what I think of those little piddly basic parameters versus advanced parameters. Now that you've got advanced functions, be prepared to see what a real parameter can do.

Playing It Safe with WhatIf and Confirm
Hello. This is Adam Bertram, and this is the module Playing It Safe With WhatIf and Confirm. In this module, I'll show you how you can leverage built-in safeguards into your PowerShell functions. We'll cover a couple of different ways in which you can write your functions in a way to test out first before actually committing. I always say it's better to be safe than sorry. In this module, we're going to cover three topics, the built-in -WhatIf parameter, and the method to turn it on called SupportsShouldProcess. We'll also talk about the -WhatIf parameter and also the -Confirm parameter as well. We'll also talk about the control variables that control both of them called $ConfirmPreference and $WhatIfPreference. Expect to be armed with the knowledge that you now have no excuse to ever blow anything up with your functions again. Wait! Maybe you should actually skip this module. I mean, this might just ruin your plausible deniability claim the next time a script goes south. Have you ever done this? Don't tell Pluralsight this, but I might have actually sneaked in a test or two in production once or twice in my life. What's it going to hurt anyway? This code can't do that much damage. I just changed a few---I guess I was wrong. Does that sound familiar? How do you prevent it? Well, let's find out.