Coding, especially in PowerShell, is not about remembering the exact syntax of how to do something, it is more about knowing how to try things out and to get the information we need to do whatever we need to accomplish.
I read Jeff Hicks’s article about “Dancing on the table with PowerShell”. The content is really quite fascinating (go read it !), but I got hung up on something.
Recently, I had to roll out an upgrade of our software for a customer. The upgrade failed for about 80 client machines (out of around 400). There was a lot of head-scratching and quite a few :
Unit testing PowerShell code is slowly but surely becoming mainstream. Pester, the awesome PowerShell testing framework is playing a big part in that trend.
As you probably know, PSScriptAnalyzer is a static code analysis tool, which checks PowerShell code against rules representing best practices and style guidelines. This is a fantastic tool to set coding style and quality standards, and if we want to, we can easily enforce these standards within a ...
When writing a DSC configuration, separating the environmental data from the configuration logic is a best practice : it allows to reuse the same logic for different environments, for example the Dev, QA and Prod environments.
Many of us who are writing PowerShell code are using Appveyor (especially for personal projects). And most of us use this to run Pester tests. Automated testing is great, it allows to set a certain standard of code quality without slowing down code delivery.
As you may already know, the only PowerShell certification program is being abandoned. Some people in the PowerShell community are trying to justify this by saying “There is no need for PowerShell cert” or “it’s too difficult to test PowerShell knowledge”.
Recently, I had to manage the configuration of the remote control settings of client machines with PowerShell DSC. These settings are located in the registry key HKLM:\SYSTEM\CurrentControlSet\Services\HidIr\Remotes :
PowerShell Desired State Configuration (DSC) makes it easy to apply a configuration to a bunch of servers. But what if the servers are already in production, if the update requires a service restart and we need to make this happen with no service disruption ? That’s a different story.