It's the first day of the PowerShell Summit! I am going to recap some of the presentations and information I found interesting in hopes that it will fill in a gap for you and provide you with a great start to your research.
The first session was presented by Jeffrey Snover and Joey Aiello. This is always one of my favorites, because it gives you some great insight into what will be coming to PowerShell in the future. Jeffrey and Joey started the session with a quick recap of PowerShell history. If you are curious about how PowerShell came to be, from the words of those who made it happen, I recommend Shell of an Idea.
The main focus of this session was on current PowerShell. The biggest takeaway was that PowerShell is no longer just for Windows. By building it on .NET core, your PowerShell can run on just about anything in your organization, whether it is in the Cloud or On-Prem. If you are still using Windows PowerShell 5.1, based on the certain module you use often, make sure you check to see if it is compatible with PowerShell 7.
PowerShell is something that is open to everyone. If you want to take part in improving it, you can help out with any of the over 8,000 modules in the PowerShell Gallery, join the Community Call held every third Thursday of the month, or share your code with the community.
I will be honest, I had never heard of GitHub Actions before this presentation by Chrissy Lemair. While this one quickly went into territory that was over my head, I learned enough to know that the subject will be one I focus on in the near future.
GitHub Actions allow you to implement continuous integration for your PowerShell projects. It requires understanding Yaml and Syntax specific for Actions. This seems to come with a learning curve, but once you dive in, you can automatically test new commits, automate your documentation and release notes, check for passwords or vulnerabilities, and test on multiple platforms (if you are not a Windows-only environment).
Stephen Valdinger started off by making a great point: if your user experience sucks, it does not matter how good your code is, because people will be unlikely to use it. He did a fantastic job of breaking down some module best practices to ensure everyone can get the most out of them, including:
Don’t skimp on your commit messages.
The commit message should be specific.
Make sure the message is associated with an issue.
Don’t use aliases in your code.
If the logic is complex, list a short explanation proceeding it.
Be sure to use approved verbs (Get-Verb will let you know what they are).
If you're learning how to use PowerShell, familiarize yourself with Get-Help often, to ensure your functions have proper documentation.
Allow for pipeline support.
If you ensure that your code follows those rules, the code will be usable to everyone without issue. I need to do better, myself, at all of these.
Assessing and mitigating outside threats is concerning for any company. There are many tools that do a lot of the work for you, but those usually come with a significant price tag. The solution is to use PowerShell! It is already in your environment, and it can do a lot. Fernando Tomlinson broke down a lot of areas that you can cover, and - even better - he has a robust repo of many of the tools he built. If you have an interest in security, take a look at how he approaches it as a great way to get started.
For example, you can parse your IIS logs to list them as an object, making them easier to interact with. Take the IP from those logs and get the location of the IPs.
I have not been able to attend the PowerShell Summit for a few years, and quickly forgot how overwhelming it can be. So much information is shared there, by true PowerShell experts. If you get the chance to attend any of the conferences, I highly recommend it. Not only will you find a great community, but it will help you take your PowerShell to the next level.