Ok, aftermath time. In Winter Scripting Camp I saw some very cool stuff, but I know folks want to learn from this event too, so I want to call out some stuff that I didn’t like so much, and explain why. I’m keeping these brief - if you’d like a longer explanation, hit me up in the PowerShell Q&A forum. BTW, none of the discussion below implies anything about the grade I awarded the entry. I considered a much broader range of criteria and opinions in awarding grades.
We’re well into our beta for the VERIFIED EFFECTIVEâ„¢ Windows PowerShell 3.0 Toolmaker exam, and expect the program to go live in March or April of 2013. There’s a good bit of information on the program home page that you should review if you’re interested in getting verified.
[As a note, once the program goes live, it’ll be available to anyone worldwide - although the exam will only be available in English for the foreseeable future; we don’t have the resources at this time to offer localized versions]
I should point out first that we’re doing this program through my company, rather than directly through PowerShell.org, mainly because of some legalities. My company (Concentrated Tech) has the insurance and other items in place needed to do something like this, and I didn’t want PowerShell.org, Inc., to have to pay for those things. That said, a lot of folks have been involved in vetting and designing the exam scenarios. Another advantage of using Concentrated Tech is that the company is set up to do a lot of the interviewing and statistical analysis needed to make a relevant exam.
The cost is the second thing I’ll discuss: at $150/person, I know it’s not cheap. But at least two human beings look at each person’s work - there’s no machine grading - and they gotta get paid. We also need to recoup some of the substantial investment that went into the exam design. Over a 3-year period, it’ll hopefully be about break-even. We’ll see.
On to the exam itself. There are a variety of “forms” for the exam, meaning everyone isn’t getting the same assignment. That said, the approach for each form is pretty much the same. You’ll get 2-3 “assignments” to complete, all of which involve writing scripts and/or commands. You get a specified amount of time to complete your assignments.
(as an aside, making multiple different exams that all test substantially the same skills is really tough, which is one reason we did a lot of testing and statistical analysis - to ensure the equivalency of each form - as part of the development process).
Some assignments are straightforward: write a script that does this, this, and that. You’re given a bunch of criteria and just have to spew out the commands. There’s room for creativity - so long as you (a) meet all the criteria and (b) comply with the stated best practices, you pass. “Extra” stuff doesn’t count against you, and the exact approach you use isn’t graded - so long as you achieve all of the results and comply with all of the stated criteria.
The “main” assignment in each form is harder. You’re given a shell transcript, and you’re asked to look at it and duplicate the tools you see used in it. For example:
Everything’s been going pretty smoothly, so we’ve decided to open Winter Scripting Camp to everyone! Read everything below carefully for the best camping experience!
Scripting Camp is a precursor to the Scripting Games, which will kick off in late April. During Camp, you’ll have the opportunity to participate in two events. We aren’t offering any prizes, but we will announce winners in the PowerShell.org blog, on Twitter, and so on. Camp is really a way for us to kick the tires on our new software platform. If you want to participate, here’s how:
We’ll be announcing Winter Scripting Camp the first week of February. This is a special invite-only event that will be open to subscribers of the PowerShell.org TechLetter. It will work just like the Scripting Games, but will feature only a couple of events and will not include any prizes. We will, however, announce the top scorers. Scripting Camp is primarily an opportunity for us to audition our new platform, to kick the tires, and make sure everything’s ready for the official Games, which will kick off in April at the PowerShell Summit 2013 North America. If you’re interested in Camping with us, please sign up for the TechLetter this week (prior to Feb 1st). We’ll be sending out a special notification to the TechLetter subscriber list with sign-up instructions.
We’re already planning for the 2014 Summit… you have to get way out in front of these things to secure space, plan a budget, and more. Here’s what we know:
We’ll definitely still be in the Seattle metro area. That’s the best way to ensure participation from the PowerShell team, since it doesn’t require them to leave town for days at a time.
We’ll be in April 2014. We’re going to try for April 14-16 to avoid Easter, or April 28-30.
We’ll be in a bigger venue. We hope to support a crowd of up to 300, although we’re still aiming for a smaller group. That’ll give us more flexibility in session planning, along with the possibility of on-site evening events.
We will open up early bird ticketing for 2013 alumni the week of April 29-May 3. 50 tickets will be available. If there are any of those tickets left after May 3, they’ll be offered to the public May 6 through 10. Any remaining early bird tickets will be converted to full-price tickets after May 10, when general sales will begin. Early bird pricing will be in the $650 range. Full pricing will be around $850. This is more than 2013, but will help us (a) fully reimburse speaker travel expenses, which we couldn’t do in 2013, (b) pay for the larger conference venue, (c) offer a full hot breakfast every day and beverages throughout the day, and (d) allow for bussing to the event venue (see below). Early Bird tickets will be fully refundable until the end of 2013.
We are going to try and hold a percentage of our full-price tickets for release in January 2014. That way, people who can’t get budget until the year-of will still have a shot at tickets. This will be a small block of tickets, though - probably less than 30 - so if you can get budget to buy your tickets in 2013, do it.
We will offer bussing from one hotel complex to the event venue in the mornings, with return busses at night. It will be crucial that you book your hotel as soon as possible once we announce, so that you can lock in a room. This can help eliminate the need for a rental car, and lower your trip expenses. At least one hotel option at around $100-$110 a night will be offered, although it may be a limited room block. For folks in the US, you should be able to attend for about $2,000 including air, hotel, and registration. Add in dinners (which we don’t provide) and you should be able to attend for under $2500 including expenses. Not bad!
As you can see, we’re still trying to keep things as affordable and accessible as possible, in keeping with the nature of a community-owned event. We’re also trying to build this event into one that can support itself and continue to grow. I know a lot of folks who wanted to come in 2013 missed out… so that’s why I’m giving you as much heads-up as possible. Start getting the boss on board. Get purchasing on board. Start planning to have the credit card ready in April 2013. We’ll get as many folks as we can into the 2014 Summit!
When I wrote Microsoft course 10325A, their original 5-day Windows PowerShell course, I saved variables until Module 11. My thought at the time was to focus on teaching just what students needed for what they were about to do - and no more. “Just in time learning” can be effective, because it lets you immediately experiment with whatever you’ve just learned, and helps minimize the need to store up concepts for later use. I’d also had a lot of class experiences where bringing up variables too soon engaged a defensive mechanism in some students: “I’m not a programmer, variables are programming, and I’m shutting down right now.” The biggest piece of MCT feedback from 10325A was, “don’t do that.” Trainers told me they were often teaching module 11 much sooner. Jeff Hicks had what I think is the best explanation for why: Without variables, you’re locked into the one-liner approach in PowerShell. While one-liners are neat, and effective, they aren’t always easy to read or to mentally de-construct. Using variables earlier in the course, Jeff argued, let you break things down into smaller logical chunks. Now, one thing I’ve had to accept in writing 10961A is that I can’t please everyone. The feedback on 10325A is incredibly contradictory. Some MCTs want more programming, others want none at all. Some want classes to run 9am-4pm; others want 8am-6pm. Some want less content on the slides (actually, most wanted that). So what I decided to do is try and provide the material to accommodate what it felt like everyone was asking for, and rely on MCT’s ability to mix things up as needed for their classes. (As an aside, I do think some MCTs jump into the “programming” aspect of PowerShell too quickly. It’s fine if you’ve got a room of people with programming experience, but it keeps students from learning some valuable fundamentals and turns the class into a “scripting” class awfully quickly. I’m not sure every MCT has done a really thorough cognitive analysis of their class results to determine if the programming-first approach is best; my experience with Month of Lunches readers suggest it isn’t.) But I still didn’t want to do the full deep-dive on variables super-early in the course. So here’s what I think I’m doing: early in the course, you’ll be exposed to variables, in a very simplistic sense. They’re described as a named place to store objects, and used to de-construct a complex one-liner into a multi-line series of logical steps. Early in the course, I don’t go into naming rules, the double quotes tricks, or anything else. You learn exactly enough about variables for the task at hand - and no more. In module 7, which is right before the module where you turn a command-line into a parameterized script, I cover variables more formally. I cover their rules, usage, double quotes, all that stuff. So you learn a wee bit about variables early, and then learn the full details later - just before you need to use variables more seriously in a script. So, keeping with the just-in-time learning. The variables material is broken out into its own lesson in module 7, so an MCT hell-bent on teaching everything about variables right up-front can do so.While the feedback from 10325A suggests that MCTs think every course should be designed for the way they teach, I’m not sure they all realize how differently they all teach. The best I can do is provide the material in standalone chunks that MCTs can rearrange as needed. After all, the whole point of having a live instructor, as opposed to a recording, is the instructor’s ability to teach to your specific needs. So MCTs will have to be happy rearranging the material a bit as-needed; my outline is the recommnded approach that will work best across the broadest array of students, but it isn’t perfect for everyone. Nothing could be. As a point of reference, 10961A doesn’t dive into scripting as deeply as 10325A did. PowerShell 3.0 has enough new, extra stuff that a 5-day course doesn’t allow for deep programming topics. You do take a command and walk it through to being a script module, so you see the range of scripting options, but you don’t practice them in depth. It’s inch-deep, mile-wide coverage of scripting, as opposed to something deeper and more focused. I’m hoping Microsoft can find budget for a full-on “scripting/toolmaking” class in the future, but 10961A ain’t it. So… what do you think of this approach?
I’ve been working to update my three free PowerShell ebooks for this month:
Secrets of PowerShell Remoting
Creating HTML Reports in PowerShell
Making Historical and Trend Reports in PowerShell
The updated versions will be made available to subscribers of the PowerShell.org TechLetter on January 15th. If you’re not already signed up to receive this, you can [sign up right now][1]. The January issue will also feature a walkthrough article of how I started creating a new, better ConvertTo-HTML command, which gets used in the ebook on HTML reporting. Going forward, I’ll be making updated ebooks available primarily through the TechLetter. If you’re not a subscriber and don’t want to be, well fine. I’ll just take my ball and go play in someone else’s sandbox. Kidding . I’ll post the updates at the end of January. However, right now access to the books still requires a subscription to the newsletter, although you can immediately unsubscribe if you want to. I had to put that “hurdle” in the way because we were losing a ton of bandwidth to people direct-linking the download files. Mostly from China, for some reason. You’re welcome to host the files on your own server, if you want to (they’re licensed for that), but bandwidth costs me money, so I’m trying to conserve a bit. Anyway, keep an eye out for the TechLetter in your inbox on Jan 15th. Check those spam filters, and make sure newsletter@powershell.org is in your address book, so that your mail server will know it’s a legitimate sender.
Microsoft’s a big company, and that makes it a big target for lawsuits. We all know that. But what doesn’t always sink in is how careful the company has to be. For example, in Microsoft Official Curriculum course 10961, Automating Administration with Windows PowerShell 3.0, I have to type Windows PowerShell every single time. I’ve actually been using “the shell” a lot, just to break things up a bit. We all casually refer to the shell as PowerShell, but Microsoft never does. Their trademark is on Windows PowerShell, and believe it or not someone has a trademark on PowerShell. I think it’s a sporting equipment manufacturer. As I’m writing the course, I started using Windows PowerShell on first reference, and then naturally - for me, at least - used just PowerShell from then on. Nope. Had to go fix ’em all. Weird, huh? I mean, technically… legally… you don’t trademark an entire word. You trademark it for use in a particular field. So it’s theoretically possible for Microsoft to own the trademark PowerShell in the world of computer software, and another company to own the same trademark for making backpacks or ski boots or whatever. But… I get it. You gotta be careful, and it’s easier just to not overlap with someone else’s trademark. Maybe they should have named it FrabulouShellâ„¢ instead, just to be really sure.
Microsoft course 10961, which will be a 5-day course on PowerShell 3.0, is officially in development! We received signoff on the outline this week, and I’ve submitted a first module for review. A big part of that review is making sure I’m using the template properly, as the authoring tool is fairly complex. It does, however, offer (more-or-less) one-touch publishing of the student manual, instructor slide deck, OneNote trainer pack, Lab Answer Key, and other documents, so it’s worth a bit of complexity. The outline process, along with the actual details of the writing, has been challenging. I pored through the feedback for 10325A, and the only consistent thing I took away was a general feeling that students and instructors worldwide are really, really different! Some European instructors cautioned against running class longer than 3 or 4pm. US instructors pointed out that a short day ending at 3pm often left students feeling shortchanged. Er. To try and accommodate both crowds, most days in 10961A will end in a significant lab, letting folks kind of free-form the end of the day however they want. Many folks pointed out that they liked to get into variables early in the course, not so much for scripting purposes but to simplify command-line stuff. Other instructors suggested I avoid variables too early, since they created the impression of a programming course, which scared off some students. Again… er. So I’m officially waffling on that one: I don’t formally cover variables until fairly late in the course (well, midway), but I introduce them quite early. It means students can potentially see and use variables on day 1, although I don’t get into all the details about how they work, naming rules, and so on. The way I’m writing them in, instructors also have the option to just gloss over them or skip them entirely if their students aren’t ready. I asked a few MCTs to look over some of my draft material and give me a delivery time estimate. I had pacing ranging from 2 minutes per slide to almost 8. Er. So I’m going with fairly simple slides that have minimal bullets (always, in most folks’ opinion, the right thing to do). Instructors can then decide how deeply they’ll cover the material based on their class’ needs. It does mean the instructor will need to be familiar with the material in advance - this will be a tough course to just pick up and teach ad-hoc. As, I believe, it should be. If there’s a theme here, it’s that you need a good instructor teaching you. As a courseware author, all I can really do is provide raw material, and an instructional design that leads most students through a sensible learning progression. But the instructor’s value-add is to be able to switch things up to meet the specific needs of their class. Every time an instructor tells me, “oh, I always move Module 11 to the second day of class,” I don’t take it as a sign of bad instructional design - I take it as the sign of a good instructor who hopefully is making the change to benefit his class. But classes vary widely, and I kind of have to write for the worst-case scenario. That can sometimes make a course seem overly timid - but that’s why the instructor is there, to add their own value, experience, examples, and demonstrations to further instruct and clarify. So the one thing I’m keeping in mind as I write 10961 is to leave room for the instructor to shine. Don’t fill the course so full of information that the instructor has no wiggle room. Give the instructor the ability to go slowly and less deep for classes that need it, and to go faster and deeper for classes that need that. Provide instructors with notes on what can be skipped if necessary, and what’s absolutely critical, so that they can triage. I’ll be doing a prep video to help provide even more context to instructors in that regard, and to let them know that customizing the delivery is absolutely okay, provided they’re doing so with an understanding of the original instructional design. Fingers crossed.
In September 2012, we incorporated PowerShell.org, Inc., and founded PowerShell.org. Our goal was to provide a solid Q&A forum, and to act as a portal to the rest of the PowerShell community. By any measure, we’ve had a great first showing. We have more than a dozen shareholders in PowerShell.org, Inc., making this the first community-owned PowerShell organization ever. We’ve signed on three Platinum sponsors - CBT Nuggets, SAPIEN Technologies, and Interface Technical Training. We’re now funded for 2-3 years of operation, including providing (upon request), gift cards to help local user groups pay for pizza and other monthly meeting expenses. PowerShell.org is now taking an average of 18,000 visits per month from more than 12,000 unique visitors, with a total of almost 57,000 monthly page views. Our forums have helped more than 760 people answer more than 850 questions. Microsoft’s Scripting Guy, Ed Wilson, has handed off the Scripting Games for 2013, and we’re preparing for a small-scale “Winter Scripting Camp” trial run that will include a purpose-built platform for reviewing events, submitting entries, and judging. And by the looks of things, that platform will run on PowerShell itself. We’ve announced our first PowerShell Summit North America, and have completely sold out. We’re already doing initial planning for 2014, aiming for a larger venue and hoping to accommodate twice as many attendees, and to fully cover speaker travel expenses. We’ve launched PowerShell People, accessible via PowerShell.net, where you can write a PowerShell script to create and post your own profile and “brag” page about your PowerShell activities and accomplishments. We’ve launched three free PowerShell.org-branded ebooks, and are preparing to launch our PowerShell.org TechLettermonthly (!!!) e-mail newsletter complete with feature articles, news updates, and more. That’s by (free) subscription only, so sign up if you haven’t done so already! We’ve also had help from Jason Hofferle on our new Books page, rounding up all the free and commercial PowerShell books out there. It’s been a whirlwind year, and it’s all thanks to you for supporting it. By asking questions in the forums, offering answers, creating your People page, registering for the Summit, signing up for the Newsletter - all of these little activities spur us all on to new heights, and we appreciate all the feedback you’ve offered. There will be more to come - follow the community on Twitter (and the Summit too, while you’re at it) for the latest announcements.If you’d like to contribute, just drop a note in the Suggestion Box forum - whether you want to help monitor a discussion forum, write book reviews, or whatever, there’s always room to contribute. There have been some setbacks. Will Steele, who had volunteered to populate our Events page, has had to step down due to health problems. Will has been a great contributor to the site and to the overall community, and we miss him. Our thoughts are with him and his family this holiday season. As we all wind down and look forward to the New Year, I wanted to personally express my gratitude to everyone who’s helped make all of this happen. Happy Holidays, Happy New Year, and I’ll see you again in 2013! Don Jones President and CEO, PowerShell.org, Inc.
