Author: jkavanagh58

Powershell + DevOps Summit 2019 has been going strong this week. Sadly I am unable to attend events like this so I do what I can to follow the action. One of the ways I follow it is via constantly updating a Twitter search for #PSHSummit. This has been a great feed of information.

One of the posts, not sure if it is specific to the Summit but was a quick tip like statement that made me say “dang”. I will go further with where I went with the content in an upcoming post but I just wanted to ink (digitally of course) my thoughts on it.

I am a Systems guy, we learn how to do things, we jot it down and then we “automate” it. No matter the shell, we create these scripts. In my case, they started as just lines of commands.

Time, many years for me, passes and we start sharing these and we begin to not only take pride in the actions of our scripts but we start adding comments, looking at the layout etc so that when we do share our work we have a little more pride.

With PowerShell and probably more so the editors we start utilizing we go even further with the format of the script as much as the complexity of the work it is performing. It is still evolving.

So this nugget touched on declaring variables, specifically for a file object. Ouch, I can just look at the code I was working on at the time and say…. [System.String] was what I was using to declare a variable for just that… Yes it works, but why didn’t I just go the extra step (and again with the editors/IDE’s available today it is right there) and declare it as FileInfo or DirectoryInfo. Lesson learned.

I mentioned an upcoming post because as soon as I read that I had to start testing… for the simple use of [System.IO.FileInfo], in just the script I was working on I could reduce lines of code I used right then and there…

End of the day… code looks cooler and I have a sneaky suspicion the execution of the code will be more efficient.

I started with showing how easy it can be to let your editor (in this case VSCode which personally I can’t see why you would be using anything else but …) come in and make your code look right. Let’s face it, we have an idea for what we are coding, and we want to stay focused on that. Between interruptions, writing, testing, writing again just focus on the task at hand is ideal. One thing that can help with that is the code formatting capabilities of your Editor/IDE.

So in the first video I have a simple scratchpad script where I am testing an If\ElseIf statement versus a Switch statement. There is nothing special in the code, matter of fact it just might be flawed, hence why it is a “scratchpad” script. The point is I was working through and then used Format Document to dress up the code (I believe there is also the use of “Trim Trailing Whitespaces” involved as well).

So as you see the format did dress up my sloppy code but I was not thrilled on how that destroyed my concise switch statement elements. Yes it formatted according to the settings in my settings.json file but…

I kept thinking about that scenario and then I remembered the setting that would probably work through this. In the following video I show the same code, format and the destruction, I mean expansion of my switch elements, Ctrl-Z, change the setting and the Format Document works to my liking…

So I stay in OTSB but because they are simple elements my Switch statement stays just a few lines.

This applies to other languages in Visual Studio Code but this is a PowerShell blog so… If you are using Visual Studio Code for PowerShell work, go into your Settings file (Use the ⚙ icon and select settings and then search for “PowerShell Code Format” . When you get to the Code Formatting: Preset check here for a great reference when you select the formatting style.

Again, I welcome any questions or feedback you might have. Now back to work.

I spent a good portion of time coming up with a scripted process to help some colleagues to make the move from the ISE to VSCode. It was hard enough to get some to see the value of PowerShell and now to get them off the PowerShell ISE…

Now VSCode prompts you to use a different (User versus System) install. Easy enough to download the file or use from a shared location but I have looked at both and I just don’t see a need for this variation or even the prompt…

By default, VSCode will update your installed extensions automatically. Personally, I prefer to be notified of extensions to be updated and view the Changelog. This is a quick recording of the process, to include the setting you can change depending on your preference, how to update your VSCode extensions.

So I was working on some documentation to help colleagues move off the ISE. ISE I love you but it’s time to go…

This is quick … Splatting has been my favorite technique, not sure it is a technique but.., and then a simple Format Select to align the key pairs. There is a great module for splatting in ISE but we are moving to VSCode

Okay in a bit of a rush and should have posted this one some time ago. In a rush because I was led along the lines ( thanks Bret Miller ) of using a GitHub Gist to better display (and share) code that I include in posts…

Yes this is very version 1. It was simply a utility I started writing for my own use. Then I found some folks who were running old versions of certain PSGallery installed modules like msonline, ImportExcel or the plethora of Azure Modules. Admittedly I watch Twitter and RSS feeds all day for PowerShell so I was rarely surprised by the results.

The code is a PowerShell function so it can be easily deployed. I recommend placing it in your profile (old school I guess but I still prefer profile.ps1) so you can call it in any PowerShell session.

Recently, well after I slapped a similar function together for auditing my chocolatey installed packages, I started to look at the next version. After making notes and beyond bad code I saw a few things so I am starting a new project to improve it. One quick upgrade will be making the display smart to show the primary module (for example VMware.PowerCLI and not all the sub modules that are part of PowerCLI) only. So now I am looking at creating the project (and learn how to use github projects). My next version will not display to the console with any great expertise like @jaykull but here is a rough version:

Not the first and probably won’t be the last but since I was talking about VSCode snippets. I started working on one for creating a [Parameter] statement to make building a Param() section easier. Was cool to provide a dropdown box for a variable (so lesson learned but not the subject of this) and now it is time to test it.

First debug, for that list of choices… at first I had |True,False| but I found using |$True,$False| just looked better, personal choice. Testing continues. Part of the snippet includes [VariableType]$variablename. A possible variable type is “PSObject” but looking at the snippet this should work right?

I would type PSObect and the snippet menu would come up as I type pso… Ugggh. Then it dawns on me I had created a snippet months ago for creating Custom PS Objects and the prefix was … psobj. Lesson Learned, even Snippets have reserved words 🙂 !