I had a dream… that one day I would become an author. I couldn’t tell you how I had gotten there, but I dreamt that I had a book, with my name on the cover, that people would buy. Now that dream is coming true.
So, Sarah, how did you get the opportunity to write?
Last summer at devLink, I spoke on PowerShell for Developers and caught the attention of my friend Matt Hester
. He hadn’t realized I was interested in PowerShell until then, but once he realized that, he asked me to be his tech editor on this PowerShell book that he was writing. I agreed, as I had been an editor for a national publication for students in ACM
while in college and really enjoyed editing technical content.
Shortly after bringing me on board as his tech editor, he mentioned that there were some appendices that needed a developer’s hand at writing. He offered it to me, and I took it. So started the “wrediting” process…
Why PowerShell? Aren’t you a developer?
You wouldn’t believe how often people – even as close as my friends – challenge my developer status because they see PowerShell as an IT scripting language and possibly inferior to typical developer skills. However, that closed-mindedness just contributes to the misunderstanding of the IT-Developer relationship. While PowerShell has a lot to offer IT people in terms of scripting and automating a lot of administrative tasks, it also is extensible enough to allow us developers to create PowerShell cmdlets, providers, and other components to allow IT to create scripts that interact with our .NET objects.
Yes, I’m still a developer. Knowing PowerShell and how to extend it makes me more versatile and more powerful, as I can take my PowerShell and C# skills and give IT teams more automation than if they just used PowerShell out of the box.
How hard is it for a developer to pick up PowerShell?
If you’re familiar with scripting languages or working at a command prompt, you should find PowerShell fairly easy to pick up. Looping and conditionals are similarly structured to what we use in C# and VB, other than syntax. In PowerShell, the operators are a little different – for example, using -eq instead of == or using -and instead of &&. But other than that, the logical structures themselves should be very easy to grasp.
What can we do as developers to extend PowerShell?
Well… you can create custom functions, cmdlets, and providers to start. If you want to know how you can do this, stay tuned for our upcoming series on PowerShell stuff. And if you want a reference on some of the things that you can do, make sure to pre-order Automating Windows Server 2008 R2 with Windows PowerShell 2.0.
While the title suggests it’s all about Windows Server 2008 R2, the appendices will get into extending PowerShell and how to make outside .NET libraries accessible to PowerShell.