Welcome to our day two coverage of the 2022 PowerShell + DevOps Global Summit. Jordan Hammond and Andrew Pla are recapping as much content as possible from the conference for folks who couldn't attend. If you missed our coverage from the first day of the conference, you can catch up by reading our day one recap.
Day two of the summit was packed with some fantastic content presented by some incredibly talented people. From building your own PowerShell editor to automation, day two included something for everyone. Here's a summary of some of the presentations we were able to attend.
Build a PowerShell editor in 90 minutes
Speaker: Adam Driscoll
This topic immediately grabbed my attention because, as many in the PowerShell community transitioned away from ISE, I feel like I held onto it longer than most. It's not that I don’t love the PowerShell extension in VS Code; it's actually quite amazing. However, I do take pride in my resistance to change. Consequently, I found myself overly critical of minor issues that I would occasionally run into. So here was a fantastic chance for me to learn. And if I am going to be critical, I should at least have a basic grasp of things, right?
Well, mission accomplished. I came away with a ton of respect for the work that went into creating a PowerShell editor. Adam’s first line was “This will be C# heavy,” which let me know I would be learning things I had not expected. Building the editor required loading in several libraries and XML files to access the necessary classes. And for those who are curious where my C# ability ranks going into this presentation, I learned that you call out these libraries with a “using” command. While most in attendance seemed to view this as common sense, I was interested to learn it!
It seems like a good portion of the process is knowing what libraries you need, finding the classes you want, then specifying what you want them to do. It was very similar to calling out .NET classes in PowerShell when you don’t have an existing command, which I feel a lot more comfortable doing after this class. Who does not love some unintended side benefit while learning?
At the end of the session, I definitely could not create what he did in 90 minutes. But, for the first time, I felt like I gained a beginner's grasp of C#. Not that I could confidently write something using C#, but now when I see something written in C#, I think I could follow along and decipher what it was doing. It was not what I expected to take out of the class, but I am happy I was in it. I also have way more appreciation for all the hard work that goes into things I would usually just take for granted. This presentation was a great way to start day two of the conference.
Writing your own CLI tools with PowerShell: A case study of SQLTop
Speaker: Mark Wilkinson
In this session, Mark Wilkinson walked us through the process of creating a CLI tool. A CLI tool is a tool that runs in your command line. Mark wrote a similar tool as the top command in Linux, except for SQL Server, called SQLTop. While creating SQLTop, he learned a lot of lessons that he shared with us, and I’m always happy to borrow someone else's work if they have already solved a problem for me. While I learned a lot during the presentation, I will definitely be reviewing his code and slides after the conference to get more out of it.
With basic PowerShell commands, you run a command, and the output is returned. With this CLI tool, you run the tool, and it takes over the PowerShell window. He showed his approach to getting a flicker-free redraw.
He tackled issues such as using runspaces and ensuring the data types you are using are thread-safe. He also demonstrated why it’s helpful to add color to your tool. While I could list all of the issues he ran across and the solutions he shared with us, I wouldn’t do it justice.
One point that he really emphasized was that PowerShell .NET classes are powerful and to use them when it makes sense. Most of your admin scripts are in PowerShell already; a UI can help!
If you are interested in creating CLI tools in PowerShell or learning more about CLI tools in general, this presentation is definitely worth watching when it's made public in October. By the end, you'll be equipped with a lot of code pieces, and you'll have a good understanding of what to expect when you develop your own CLI tools. I'll absolutely be bookmarking this one.
Non-coding skills for successful automation
Speaker: Gael
I promised myself more soft skills, and I delivered! I really enjoyed this session as it forced me to look at how I perceive my work pipeline. The first point that really stood out to me is that it doesn't matter how good your code is if nobody adopts it, so you need to consider the needs of who is requesting it. I'm sure I'm not alone in wanting to do things the way I'm most comfortable, but if I create a lesser product that people use, it has more value than a better version that's not utilized. This gets you thinking about tailoring to people's needs first. We're introducing change, but our responsibility is to make sure that change gets adopted.
To ensure the highest adoption rate, you need to include your customer early in project discussions. The more they're involved, the more enthusiastic they'll be about your work. One trend that I found interesting is that he viewed the DevOps we do as a business transaction more than a project. The person with the request is your customer; your code and automation are the product. The tech is the easy part for us. We've spent our careers learning all we can about the tech side of things. Communicating with those who will use the end product is often the more difficult task.
After two soft skill sessions, I think the main takeaway is that soft skills aren't always intuitive but make a lot of sense once you take the time to think about them. Even defining what skills I need to learn is not always clear. I'm happy to be taking some of that time now.
PowerShell Prompt Customization Rodeo
Speaker: Justin Grote
I loved this session! I generally stick to default settings with most of the applications I use, and when I don’t like something specific, I just learn to ignore it. Ignorance is bliss, right?
Justin Grote is different. He makes his environment exactly as he wants it, which is really cool. He uses a tool called Oh My Posh that helps him get the full customization he's looking for. For those who've utilized this in the past and felt the console was too slow, it's been completely rewritten in Go, and the performance has dramatically improved. He recommends using winget to get the latest version.
Overall, he likes his screens to be context-sensitive and relevant to where he is. He doesn't want to have to think about it, as any interruption can break his flow. He's made a lot of changes. For example, he's made simple changes, such as displaying a home icon instead of a path when he's at his home path, and he uses a construction sign when moving into a project he's working on. He's also made more complex changes, like different alerts if code fails and a GIF of "The Great Gatsby" running in the background if his code runs successfully. He displayed the code for Gatsby GIF, and it was very extensive.
Overall, this was a fun session that generated some interesting questions. Needless to say, there are far more customization options than I had initially thought, and it's inspired me to customize my space to fit my needs when I get back home.
Code Golf: The Zen of Writing Bad Code
Speaker: Kevin Marquette
Code golf is the challenge of solving problems with code in the fewest amount of characters possible. It provides a creative way to practice your PowerShell skills. Now, don’t get it twisted — you will not learn the proper way to code with code golf, but you will learn the nitty-gritty parts of the language. It’s also just fun to use your PowerShell skills differently, and doing challenges like this can help you discover cool things about PowerShell that you would NEVER have seen otherwise.
Kevin presented several clever ways to save space in your code, from reducing whitespace to tricks with ternary operators. This talk had a bunch of disgustingly ugly code that works. Kevin showed off the code.golf site and challenged the community to see if anyone could take him off the leaderboard.
The real highlight of this talk was when Kevin walked us through attempting to solve the classic Fizz Buzz programming problem with PowerShell. He starts with a simple submission and slowly keeps removing characters, showing you the techniques required along the way. It was mind-melting and oh-so enjoyable. If you want to have some fun, check out this session.
Lightning Demos
I love Lightning Demos. Lightning Demos are where attendees get to show off some of the code they've written. It's so cool to see code that has been written to ease people's day-to-day issues.
Here are a few of the demos I wanted to highlight:
PSSubnetCarver: Chris Martin
This module lets you enter any number of IPs you want, and it will run all of the network math and build VNets for you in Azure. If you hate network math, this is a huge help.
Argument Completers: Sean Wheeler
This demo covered adding dynamic ways for your functions to have customized arguments. This allows commands with hard-to-remember or changing arguments to populate your parameters automatically.
The untitled Carl Davis demo: Carl Davis
Carl Davis wrote a web request for pulling down information from network devices. The issue was he needed 9900 total and was timing out. He uses a URL from his pull request where he pulls 500 at a time, avoiding the time-out issue. Because the result is an object of objects, it converts it to a PSCustomObject, creating clear results of needed data.
Halfway through the conference already?
Day two from the 2022 PowerShell + DevOps Global Summit has come to an end, but we still have two more days of exciting PowerShell presentations to look forward to.
Make sure to check back tomorrow for our day three coverage of the event. We'll be answering some crucial questions, such as: Do Jordan and Andrew have enough energy drinks to keep up this pace for two more days? And which one is more likely to be found asleep in an empty conference room? There's only one way to find out, so stay tuned.
