Time to summarize 3rd event of Scripting Games 2013. I must admin – I learn few new tricks while reading entries for this event. But I still see some things I really can’t stand. Especially in beginner category, where many people decided that putting everything in one line makes it “special”. It doesn’t. If you still think it does – read this article by Richard Siddaway. If you still think line break is cursed – read it again. Repeat. 
Looks like we just passed mid-point in Scripting Games 2013, at least for fun part: writing scripts. I must say that I really couldn’t find anything that I’ve seen as “learning experience” in this one – we already did more complex WMI reporting in previous event. We were requested to create very basic HTML report, and we have cmdlet for that. So… I guess I just went lazy with this one. No real error checking, because design claims all have been taken care of. Sweet. 
Have you ever wanted to use splatting outside it’s normal use with PowerShell commands? Splatting is great to pass (named) parameters to commands, but there are other elements that have named parameters. Perfect example: static methods that exist on .NET types. Unfortunately, in current version of PowerShell we can’t extend splatting concept to other language elements. But I guess a lot of people would agree with me: it would be great to be able to do something like:
$ToSplat = @{ format = "Using 'splatting' hashtable: {0:N2} and {1:N3}" args = [math]::PI, [math]::E } [string]::Format(@ToSplat)
It may happen one day, but can we do anything about it now? Well… sure!
OK, I’ve seen your entries, and I must say – in general, I like what I saw. But it wouldn’t be helpful to tap you on the back and pretend everything is perfect, would it?
As previously, I will mention few pain points I’ve seen. I will also try to mention what I liked about entries. Let’s jump to beginner category first.
Now that event 2 is closed for new entries – time to let you guys know how I would do it. Again: feel free to complain, comment, judge. I hope I will show you few tricks here and there that will help you with next event, or at least: will help you understand what you might have done wrong. Not that I’m assuming you did, I just noticed few gotchas in this scenario that I wanted to addresses. Have I succeeded? As you probably already know, there is no definite answer to that question. 
PowerShell Web Access is great new feature, that allows us run PowerShell inside web browser. So far I was thinking of it as something that is either save but slightly inconvenient (when we have to connect to constrained endpoint running with RunAs credentials) or slightly insecure with cool features like tab completion and full cmdlet coverage, including all *-Object cmdlets (if we connect with more privileged account to “normal” endpoint). Either – or. But last Friday I came up with idea that can give us a little bit of both. Idea, that I would like to share.
How often do you find yourself in situation, when you would like to import functions from one of your scripts? Issue with that is related to the fact, that most of scripts I write have some purpose and they “do stuff”. When I want to import functions from the script I do not want to perform tasks that script would normally do – I just want function(s).
Recently on various occasions I was talking about consuming PowerShell remoting in a ways different than one that is usually used in demos. What you will usually see is connecting in good-old ssh fashion – using console window directly. One of two chapters I wrote for PowerShell Deep Dives book is about consuming PowerShell remoting using PowerShell Web Access. Today I would like to share practical implementation of other wonderful pair: PowerShell remoting constrained delegated endpoint and GUI script, that is build on top of it. It was used at my work for few months and because primary reason it was built for in first place is no longer valid – it will be removed soon.
IT Pro PowerShell experience 