I hate to seem negative, but I’ve noticed a few things about a number of the advanced entries that seem like folks didn’t read the instructions, or just weren’t careful about details.
There were a surprising number of entries that had [string]$ComputerName instead of [string[]]$ComputerName in the params section and then went on to treat the parameter as if it were an array.
- Somewhat related to the array issue, the problem statement indicated that there could be several files that had computer identification for piping into the solution. Several scripts went beyond the minimum by accepting a filename property to process those files directly. I don’t think that extension is out-of-bounds, but scripts that accepted only filenames and excluded ComputerName input didn’t get my vote.
- The instructions asked for a “full help display”, but many of the entries had fairly limited documentation. One thing I especially missed was a .PARAMETER description.
- My last negative comment is about parameter names. Although there’s nothing in PowerShell to prevent it, best practices in parameter names should be followed. The parameter ought to be $ComputerName, not $Name, $Server, $Computer, etc. I know it’s easier with verbs and nouns because of the Get-Verb and Get-Noun cmdlets, but please pay attention to how you name your parameters.
On the whole, though I really liked the effort everyone put into their scripts. Those that exactly met the requirements were short, sweet, and to the point. There were several extensions that I also liked.
This time of the year always feels like someone is holding down the fast forward button. I blinked and here we are Friday morning another week of scripts in the rear view. I spent most of my week in the beginner class this week, and was greeted by a combination of beginners and scripters who weren"™t quite ready to step up to advanced. More of the latter if I"™m to be honest. This was a pleasant surprise as it"™s another sign of the continuing growth of our community. Now on to the scripts I knew when I signed up to do this, that at least one of these weeks I"™d talk about formatting. It"™s one of those best practices that you don"™t appreciate until you"™re asked to review someone else"™s code.
Don"™t Crunch the Code, and for the love of all things, Hit Enter!
I did not deduct any points for readability, but you didn"™t make my good list either. Personally I find it disrespectful to share an ungodly one-liner, but it"™s downright wrong if that single line has semicolons! We"™re not printing these scripts the crunch gets us nothing. I"™m not going to call out the litany of scripts that were manually formatting the data directly which is even worse, but consider the following.
Event 3 will be open for entries in about ten minutes, but I thought I’d share some Event 2 information. Keep in mind that Event 2 is open for voting until the 14th, GMT.
Our Beginner Track had 120 entries this time, while the Advanced had 124. That contrasts with 165 and 159 from Event 1 - a perfectly normal falloff that’s occurred during every edition of past Games. Folks get busy, maybe get discouraged, but we’re keeping right on the trendline.
Voting is down… that happens, too, as the thrill of event 1 falls off. We had 3,966 Beginner votes and 2,775 Advanced votes in Event 1; so far we’ve gotten 1,446 Beginner and 1,131 Advanced in Event 2. Of course, we still have almost a week of voting left to go in Event 2, and in Event 1 we took a lot of votes up to the last minute.
The good news is that Event 2’s votes have, so far, included a much higher percentage of comments. Event 1 Beginner has about 55% comments, while Advanced had 58%. In Event 2, Beginner is tracking to 63%, while Advanced is at 59%. Good job, guys - those comments are a big help. As you know, we’ve also put up some general guidelines to help keep everyone on the same page with what the score levels mean, so hopefully that’s helping, too.
Something’s sure helping. The average score in Event 1 Beginner was 2.5585, and Advanced 2.3870. Event 2 is up a notch, at 2.6957 and 2.6631. That’s a 5% jump in Beginner scores and over 11% jump in Advanced scores. I know, people are tough on the scoring. And in some cases, I’m seeing comments that indicate the comment author had some misunderstandings. That’s okay - it’s an opportunity for us all to learn together, especially after the Games complete and we can start diving into this mess of data.
I hope you’re already to start on Event 3! Our fastest entry so far is just over 51 minutes, and I might be saving some special prizes for the overall fastest entry (don’t worry - I’m going to look at it to make sure it’s decent).
May the Games be Ever in Your Fav… ugh, sorry. Don’t know where that came from. Good luck!
Today I finally had some time to look at all entries in both categories. What I liked, and what I did not like about them? You can find answers, as previously, either in Polish, or in English. I focused mainly on things I did not like, but I would anyway say that scripts are really good (overall) this year. Still: few poppies died. If you are responsible for it - remember: at the end of the day, it is you who is tossing away strength that PowerShell offers: Object Oriented Pipeline. 1* note is nothing in comparison with report, that will exists only as long as your host, very same that you want to write on so much… 😉
Jan Egil Ring is a multiple-year recipient of the Microsoft Most Valuable Professional Award for his contributions in the Windows PowerShell technical community.
He has a strong passion for Windows PowerShell, and regularly writes articles on his blog. He occasionally also writes articles for others, such as the PowerShell Magazine.
As a judge in the Scripting Games, he will be writing articles on his blog reviewing both good and bad observations in the reviewed scripts. Clean formatting and avoidance of using aliases in scripts is among the things he will be paying attention to.
Event 2 is in the books and with that, it is time to take a look at all of the scripts submitted and make the difficult decisions as to which ones I liked and which ones I didn’t quite like. Just because a script landed on my “˜Not so Favorite”™ list doesn’t mean it was terrible. It was just that I felt that there were some things here and there that could have been looked at a little differently. In fact, the amount of submissions that were great really made my decisions much for difficult. Everyone has really shown just how much knowledge is out there and how there are many different approaches to a single problem!
Check out my picks here.
First of all, congratulations! It looks to me like a lot of learning is going on; the 2nd event entries look really good to me. I especially liked the way a number of you built up a one-liner by starting with a_ Get-WmiObject Win32_ComputerSystem -ComputerName (Get-Content file.txt)_ and piping it into Select-Object to generate the data. However, there were a couple of areas within the Select block that make me think that some more discussion of what $_ means in a pipeline would be helpful.
Within the Select block, it is necessary to make a call to Get-WmiObject Win32_OperatingSystem to get come additional information. It looks like everybody got the format correct: @{Name=‘OS’;Expression={Get-WmiObject}} where folks got into trouble was in specifying the ComputerName property. Some didn’t even include it, meaning that the OS value would be taken from the local computer and not the remote one. But, more often than not, the code contained a plain $_ : @{Name=‘OS’;Expression={(Get-WmiObject Win32_OperatingSystem -ComputerName $).Caption}}. So, what’s wrong with this? The problem is the value of $ at this point in the pipeline.
Let’s try an experiment to show what I mean. Try this:
While reviewing Event 1 (and now Event 2) I’ve seen some scripts that don’t quite have the correct pipeline support and others that do a great job with it. Whether it is an unneeded Begin or End statement, or throwing everything into a Process block and not quite getting the expected output or even having a Process block when ValueFromPipeline/ValueFromPipelineByPropertyName is not even enabled. Before I start working through my notes for Event 2, I wanted to get this post out of the way. I hope that what I put together here will help those out who are working to implement pipeline support in their code as well as providing a method of troubleshooting the parameter binding using Trace-Command. The blog post is available here to view.
