Articles from 2015 on PowerShell.org - Welcome Automaters!

PowerShell.org's Nonprofit Status

Tue, 29 Dec 2015 15:11:16 +0000

We learned today that The DevOps Collective, Inc., (the company that officially owns and runs PowerShell.org, the PowerShell + DevOps Global Summit, etc.) was accepted by the US Treasury as a 501(c)(3) public charity.
That means that the company is quite literally owned by the American public now, and run by its Board of Directors. No human or business entity owns the company and its assets, which is exactly our intent. Further, no human or business entity can profit from the company, which is also our exact intent. Regardless of who’s running it, it’s now big-time illegal for any Director (for example) to just partake of the organization’s money. Previously, it was merely unethical, but completely legal, as the company was technically for-profit. So we’re right where we want to be.
Donations to the corporation are now tax-deductible, charitable contributions. However, a donation is when you get nothing of value in return; unfortunately, Summit registration fees - since Summit itself is of considerable material value - are not charitable contributions. Your registration is likely still deductible as a business expense (namely, education, along with your travel expenses), something you or your organization’s accountants should determine. Sponsorships - given that sponsors don’t receive anything of material value from us - are considered deductible contributions in most cases.
I’m very proud to have brought the organization to this point, and I want to point out that it’s due in part to Microsoft’s own recent activities, such as bringing Core CLR, the WS-MAN stack, DSC client, and other bits to non-Windows operating systems, as well as their progress in open sourcing so many critical pieces. Those activities - and our expanding focus on DevOps in general - have taken us away from being an organization that supports a commercial product (MS Windows) to a much broader organization that was qualified for this beneficial status. I also want to offer a big shout-out to my fellow Directors, and especially Jason Helmick, who put in a lot of work with our own accountants to get this all in order for the IRS.
For the organization itself, it means our main revenue activity - Summit - is now nontaxable for us. That means we get to keep all of our money to spend on organizational operating expenses, instead of losing some of it to taxes. That gives us a 15-25% boost in being able to operate our TeamCity public build server, this very website, our TechSession webinars, and other activities. This new status also, I believe, places us firmly on a path toward long-term existence. PowerShell.org is now, in a very binding legal way, something _we all own, _and something it’s on all of us to continue growing and supporting.
Thank you for that support, and Happy New Year!

My Favorite DSC Feature Suggestions on UserVoice (upvote!)

Mon, 28 Dec 2015 19:35:27 +0000

Hopefully, you’re aware that Microsoft is moving to UserVoice for accepting feature requests and bugs. DSC in particular has 30-odd suggestions at present, and I thought I’d run through some of my fav’s. Log in and up-vote the ones you like, or add comments to expand the discussion!

Add Maintenance Windows Awareness to DSC/LCM. This is one of mine, but it came from several customer suggestions.
Change the Pull Server database to SQL Server. Broadly, this is a great idea. In theory, you should be able to modify the web.config file and direct it to a SQL Server already, but nobody knows the database schema that the pull server expects.
Refactor the LCM’s validation logic. This is another of mine, and it’s crucial. Right now, only the LCM can validate multiple partial configs and tell you if there’s a validation problem like a duplicate key. This means our only possible point of failure is the target node, which is the worst possible place for that to be. Factoring the logic out would let us built a pull server that could combine multiple configurations _server-side, _and spit out a combined, pre-validated MOF for the target to consume. We could also use the configuration logic to manually combine and validate MOFs in a test or RSoP mode, perhaps with a cmdlet.

There’s plenty more - have a look, vote for ones you like, and add your own suggestions! And there’s a lot more besides DSC in there - see anything that you think is important?

Microsoft's Brave New World Needs Version Numbers

Mon, 28 Dec 2015 19:21:23 +0000

In Microsoft’s brave new world of agile, more-frequent software releases, including numerous pre-release cycles… Microsoft needs to rethink the way it communicates versioning.
Windows Management Framework (WMF) v5 has, for me, been pretty much the perfect example of what not to do, and the perfect example of Microsoft still shoehorning itself into old nomenclature that no longer fills the bill. I know a bunch of folks on the PowerShell team are probably still trying to figure out what works, too, so this isn’t meant to be a hammer-on-’em post, but WMF5’s lifecycle was, from a versioning perspective, pretty hellish.
We had several “technology preview” releases, which were simply named after their month of release. April 2015. November. Whatever. It was really difficult from within the product - e.g., via $PSVersionTable - to tell which one you were running, which made helping people difficult. None of these were supported in production until the “WMF5 Production Preview” released in late 2015, and in December we got “RTM” code. RTM means “Released to Manufacturing,” which is kind of absurd as a milestone, because there’s literally zero actual manufacturing going on. It’s just a word Microsoft is used to using. Windows 10 shipped with a production-supported version of WMF5, but it still wasn’t “final,” meaning RTM WMF is better than what shipped with the RTM OS. God willing, what ships in Windows Server 2016 will be v5.1 or something, because if we get yet another 5.0 release folks are going to start throwing up their hands and quitting.
Now that Microsoft’s all lovey-huggy with open source and Linux and stuff, can we just copy what those guys do?
Every time you release code, increment the version number. It’s that simple. There’s no “production preview,” there’s just “5.3.” And you maintain a list of what’s supported in production. If 5.3 isn’t a production milestone, fine - say so. But it’s still a real version, because it was released unto the world. The next release is 5.4. Then 5.5. And maybe 5.6 is supported in production, but once 5.7 is out, 5.6 remains supported for only 90 days. Or whatever. Just have a list of what’s supported, and increment the version number every time you release it. 5.8 might only last a week before someone finds some heinous bug and releases 5.9 - that’s fine. After that comes 5.10, and then 5.11, and so on.
6.0 is the first release of a major new evolution in the product, and it’s probably a “preview” release. 6.1 will be a bit better, with fewer bugs and more features nailed down, but it won’t be until maybe 6.5 that we get a “supported in production” release.
All of this is a lot easier to keep track of than vague “version” numbers like “April 2016 Production Preview.”
And while we’re at it, let’s have a Get-PSVersionInfo cmdlet. It can wrap around the existing $PSVersionTable variable, of course, but it can also ping a web service on Microsoft.com to tell you what the latest version is, what thelatest supported version is, and whether or not your current version is supported in production. OMG, that would be _wonderful. _

`PS C:> Get-PSVersionInfo Name Value

PSVersion 5.8 ProductionOK False LatestPSVersion 6.0 LatestProductionPSVer 5.9 `This tells me that I have 5.8, and it isn’t supported in production at this time. I can get 5.9, which is supported in production, although there’s a newer 6.0 which obviously isn’t supported in production.
So please.Vote for this on UserVoice.

]]>

PowerShell News Roundup (There's Been a Lot of it)

Mon, 21 Dec 2015 18:37:50 +0000

There’ve been so many under-the-radar announcements and news bits about PowerShell, that I thought it’d be worth a quick start-of-the-week, pre-holiday roundup.
First off, the big news is that **Windows Management Framework v5 has been released to manufacturing (RTM). **Not that there’s any real “manufacturing” anymore, but this means we’ve hit the milestone where it’s “done.” Now, if Microsoft is smart, whatever WMF ships with Win2016 will be “5.1” or something, so we can all keep track of what’s what. Fingers crossed on that.
Next, and you may have missed this, Microsoft is moving away from Connect and over to UserVoice for many products, and PowerShell is now amongst them. Spread the word on this, because feedback is super-important, the team _actually does listen, _and UserVoice is now where it’ll happen.
In the continuing move to open source, the PowerShell team **released a bunch of their tests on GitHub. **These are some of the tests they use to test PowerShell itself, and the ability for everyone to now contribute to those means the team can produce more error free code for us. This is a big deal, and proves this isn’t your grandfather’s Microsoft anymore.
The **DSC Documentation has also been open sourced, **meaning we can all finally contribute to that. Yeah, we all know Microsoft should be producing their own docs - and they are - but this lets us correct errors, add examples and expansions, and fill in the gaps Microsoft may have to leave. They’re not a bundle of infinite resources, after all, and this finally lets us help each other in a more effective way.
The PowerShell + DevOps Global Summit 2016 is about 1/3 sold-out. Currently, only 4-day registration is available. In February, we’ll begin offering any remaining seats for 3-day attendance as well as 4-day. We don’t recommend waiting much longer, because when we hit most people’s new fiscal year next month, it’ll be downhill to “sold out” again. Remember that registration cuts off at the beginning of March 2016, too.
Finally, the Scripting Games puzzles continue to be posted at the start of each month (usually the first Saturday). We’re actively looking for a moderator to take over the process of collecting puzzle submissions from the community, coordinating puzzle and solution posting, and reviewing community submissions for noteworthy ones to call out. If you’re interested, drop an e-mail to admin here at PowerShell.org. We already have content for January and February 2016, and are also looking for puzzle submissions. Drop an e-mail if you’d like to contribute a puzzle and a solution.
Happy Holidays from everyone here at PowerShell.org, and we wish you all the best in the coming new year!

Recap of the Dec 2015 PowerShell Editor Services Hack Week

Wed, 16 Dec 2015 01:30:17 +0000

Thanks to all those who participated in the PowerShell Editor Services Hack Week last week! Much progress was made on fixing bugs and adding new features to bothPowerShell Editor Services and thePowerShell extension for Visual Studio Code. Here’s a quick summary of the contributions that were made during the week:
Variable Display Improvements in the Debugger
Keith Hill made many great improvements to how we display variable contents in the Visual Studio Code debugger. First of all, he added support for variable scopes other than just “Local” as we had before. You can now inspect variables from both the Global and Script scopes. You will also see a special “Auto” section which filters the set of variables down to those that were defined in the current scope. This is really helpful for quickly checking the state of the variables in your functions!

He also added greatly improved the variable value display for collections such as arrays and dictionaries and also objects which implement the ToString() method in .NET. You will now see much greater detail for these variables in the debugger:

New Expand Aliases Command
Doug Finke contributed a new “Expand Aliases” command which searches your script file or selection for the use of cmdlet aliases. For any alias it finds, it replaces the text with the full command name. This is helpful for developers who want to quickly write out scripts using aliases but resolve them to their command names before committing to source control.
Here’s a GIF of the feature in action (click to play!):

Sublime Text Editor Integration
Work on the integration of PowerShell Editor Services in Sublime Text has progressed quite well this week. The basic protocol implementation is now working, enabling language features to be integrated over time. I’ve also implemented basic file management support so that opened files are sent to Editor Services for syntax checking and semantic analysis. From this point it’s just a matter of integrating the language features of PowerShell Editor Services into Sublime’s UI using its plugin API.
Check out the current code in theeditor-services branch of my fork of the PowerShell Sublime Text package. Once this effort is stable enough for an initial release, I’ll be submitting a PR back to theoriginal PowerShell Sublime Text package repo and future work will continue there.
Atom Editor Integration
Some work was started on an integration with the Atom editor but it was quickly determine that Atom’s APIs for language features were to sparse to make quick progress. However, with the experience gained from the Sublime Text integration, future work on the Atom integration should be much easier. Expect to see more effort in this area in the first half of 2016.
Miscellaneous Improvements

Mateusz Świetlicki improved the “Run Selection” command so that it will run the line that the user’s cursor is sitting on if there is no text selection
The default set of Script Analyzer rules used for semantic analysis has been reduced to provide helpful hints without giving too much feedback. (In the future the rule set will be completely configurable.)
A set of bugs around code completion text replacements were fixed so that using IntelliSense no longer eats your code 🙂

New Releases
As promised, I’ve prepared new releases of both PowerShell Editor Services and the PowerShell extension for Visual Studio Code which contain all of the contributions made during these week. The new NuGet packages for PowerShell Editor Services have been released on NuGet today (see the following changelog link). The Visual Studio Code extension will be released once a publishing issue has been resolved.
Here are the changelog entries for both releases:

Looking Ahead
Overall I am very impressed with the work that we accomplished this week even though there wasn’t a large amount of contributors. My guess is that PowerShell fans would feel more comfortable contributing by writing PowerShell rather than C#. I’ve got some ideas on how to make this possible in the future so keep an eye out for another Hack Week next year!
Thanks again to all the contributors and to all the users of these projects!

]]>

2015-December Scripting Games Puzzle

Sat, 05 Dec 2015 16:33:35 +0000

Our December 2015 puzzle comes from PowerShell.org board member Jeff Hicks, who wanted to share a little holiday fun for the season.