Explore articles and content from this author
22 articles published
Having a platform that enables ChatOps can be a game changer. You can quickly see changes, alerts, build status, discussions, emergency chats, and more, all in a single, searchable interface. If you can sift through the gifs. Bots are a hot topic these days, and and it’s well worth checking out Matt Hodgkins bit on integrating PowerShell with Hubot. Bots are a great alternative to trying to spin up a web front end for PowerShell.
Are you intimidated by scripting? Does PowerShell seem too much like programming to you? You aren’t a developer, why should you learn this mumbo jumbo? It turns out, PowerShell is quite easy to get started with. Can you run ipconfig? Do you know how to give someone instructions? You could probably pick up the PowerShell basics in a month of lunches or so. Don’t believe me? I spent a few minutes to compare a simple task in four languages.
Have you ever wondered what LDAP queries were hitting your domain controllers? Even outside of fun investigations, it can be insightful to get a sampling of queries hitting your domain controller. The more services you have integrated with Active Directory, the more likely a vendor or sysadmin unwittingly configured their service to produce evil queries. Mark Morowczynski from Microsoft wrote a great post on finding these expensive, inefficient, or long running queries - But something was missing.
Earlier in August we mentioned that modularity and abstraction are quite helpful. PowerShell modules can help enable these concepts. You might ask “Modules… why can’t I just write a function?” There are a number of benefits to bundling your functions into modules: Simplify code organization Group related functions together Share state between functions, but not with the user Re-use “helper functions” that you don’t want exposed to the user Improve discoverability: Find-Module MyModuleGet-Command -Module MyModule * Simplify distribution: Install-Module MyModule `Where does that last bullet come from?
Modularity and abstraction are a huge benefit in scripting and coding. Which of the following blocks of code are easier to understand? $SQLConnection = New-Object System.Data.SqlClient.SQLConnection $SQLConnection.ConnectionString = 'Server=SqlServer1;Database=MyDB;Integrated Security=True;Connect Timeout=15' $cmd = New-Object system.Data.SqlClient.SqlCommand("SELECT * FROM Table1",$SQLConnection) $ds = New-Object system.Data.DataSet $da = New-Object system.Data.SqlClient.SqlDataAdapter($cmd) [void]$da.fill($ds) $SQLConnection.Close() $ds.Tables[0] Or… # Invoke-Sqlcmd2 -ServerInstance SQLServer1 -Database MyDB -Query 'SELECT * FROM Table1' If you aren’t a masochist, the latter probably looks a bit nicer.
Are you starting to use version control at work? Are you being pestered by fellow PowerShell aficionados to start learning version control? Did you catch the PowerShell.org Crash Course in Version Control and pick up some Git and GitHub experience? Shameless plug, sorry : ) Version control is just the start. What if we want to automate testing? To deploy our files, folders, and other artifacts out to production or other environments?
Have you ever needed to communicate between scripts, perhaps running on different servers and in different languages? Did you use a non-standard “messaging” solution like the file system or a SQL database? Did you try to avoid this and squeeze everything into a monolithic, delicate script? RabbitMQ is a solid messaging solution that happens to have a handy REST API and .NET client, which means we can use PowerShell! Wrote a quick hit on setting up a simple RabbitMQ deployment and using PowerShell to manage the solution and send and receive messages.
Ever wonder how PowerShell seems to know how to format objects? When you run Get-ChildItem or Get-WmiObject , you only see a few key properties, but a wealth of other information is available through commands like Select-Object and Get-Member . Have you ever written a PowerShell function that you nearly always pipe to Format-Table ? Wouldn’t it be nice to specify some default properties and force them into a table?
The PowerShell code you write can turn up in interesting places. Production services might rely on it. Your co-workers might take a peak and borrow ideas from it. You might decide to share it online. Someone might see your code online and use it in their own solutions. Hit the link for a quick bit on how we can help create more reliable, consistent, and secure solutions. Simplified to one line: always ask yourself “what could go wrong?
First off - thank you to everyone who participated in the version control survey! We’ve had a fun few weeks - Somehow the PowerShell Summit, Build, and Ignite were scheduled back-to-back-to-back. Among a host of other announcements and tidbits, we found that Microsoft has open sourced the DSC resources on GitHub, that Pester will be included in Windows, and saw a cool demonstration from Steven Murawski on using Test Kitchen to test DSC resources.