Often when writing a script I follow a multistep process. The first thing to do, of course, is to come up with a bit of code that will do what I am after. For example, if I want to obtain information about the BIOS on a computer, I will first figure out how to do this. In general everything in the script is “hard-coded” meaning that no variables are used. Here is an example:

Get-WmiObject –class win32_Bios –computername “localhost”

The next step is to put the value for the comptuername parameter into a variable, and then to move it into a function. To do this, I use the function keyword, and create a function. It looks like this:

Function Get-Bios ($computer)

{

  Get-WmiObject –class win32_Bios –computername $computer

}

The problem with this approach, is that if I know ahead of time I plan to put my code into a function, and to supply input from outside the script I can skip the first step and immediately write my code as a function. This will save a bit of time. In addition, if I know that I will be supplying more than one value, I may decide to change the name of the variable I use.

Once I have a variable to hold my input, I can then use whatever method I wish to assign a value to that variable. I can read a text file, I can query Active Directory, read a database, or do other things as well.

On Monday, we begin looking at designing input for a script over at the Script Center. It will be a cool series of articles.

Yesterday I had a conference call that lasted all day long. It was not nearly as bad as it might sound. I was attending a meeting that in the past would have required me to fly to Seattle. From Charlotte, there is one flight a day to Seattle. If you are lucky enough to get this flight, and if you can afford the premium price tag the airline places on the flight, it will take five hours of flying time to get out there. If you catch one of the other flights you will go through Dallas, Chicago, Atlanta, or Phoenix with a very real possibility of missing the connection or having your luggage lost. Those flights take anywhere from 8 1/2 hours to 10 1/2 hours depending on connections. But wait that is not all, because you cannot just magically appear at the airport. From my house in South Carolina it takes 45 minutes to get to the airport in Charlotte, and then you need to be there two hours in advance. So even if I caught the five hour flight, and the flight was on time, it would require 7 hours and 45 minutes … not counting the time it takes to get a rental car and drive from SEATAC to Redmond.

All this will presuppose one day to fly out to Seattle. Then you spend the day in the meeting, and if you are lucky you can catch an evening flight out and arrive back in Charlotte around 7:30 AM the following day … jet lagged, and exhausted due to no sleep on a cold uncomfortable plane, and starving to death due to no food. In general, I prefer to spend the night in Seattle and arise at a normal time, and arrive back in Charlotte reasonably rested. Still it takes three days for a one day meeting. This does not take into account the toll on your health. Spending 10 to 18 hours cramped in an air plane causes me to ache … my legs cramp, my back hurts, and my sinus throb at the end of such a flight … not to mention the risk of catching strange and exotic diseases from your fellow travelers. All of which put a cramp in my productivity as well.

I could go on about the risk of getting your laptop stolen, your luggage lost, missing the meeting all together due to missed connections, and canceled flights. What about the food they serve at these kinds of meetings? Generally pizza or cold sandwiches … it was a working meeting after all. Neither of these ubiquitous foods are on my low carb diet. Speaking of diet, when I travel like this, it is generally impossible to get my workout scheduled. So traveling impacts my health as well as my mental well being.

What is the alternative? For my meeting this time, we had set up Live Meeting. I was completely integrated into the meeting. I clicked the invitation, it opened up the PowerPoint slide deck, called my land line, and I was in the meeting. Total commute time … 30 seconds. Yes, but what about the discussion? Dude, we used Office Communicator. I had a designated person who way my question proxy. When we broke up into small groups, Ralph and I chatted. He relayed my questions and my contributions to the meeting to the small group. The added bonus was he had a complete transcript of our conversation. Incidentally, there was a guy from Germany in our virtual meeting, and a lady who at home recovering from surgery. We all shared the same Office communicator session … with a group chat.

Oh for food? While they were munching on pizza, Teresa brought a nice bowl of Gazpacho, and a plate of Ceviche. After the meeting? I commuted another 30 seconds, and got on my tread mill for an hour. This morning, I am not jet lagged, not bloated, not sore, not sick, and am raring to go for an exciting and productive day. Live meeting, where were you 10 years ago! Life is good.

The 2009 summer scripting games are nearly half over, or still have half to go depending on your perspective. They have been absolutely awesome regardless of your disposition. I have enjoyed reading over the scripts submitted by the participants, as well as those written by the guest commentators. It has been an excellent learning opportunity and I feel my skills have improved during the process. In fact, I used a new technique I learned during the scripting games yesterday to answer a question I received via Scripter@Microsoft.Com.

We are in the process of recruiting new moderators for the Official Scripting Guys forum. The cool thing is the number of people who are willing to take the time to help other people learn often confusing task of scripting. This is the thing that makes the IT Profession unique, the feeling of community, and the willingness to keep plugging away far into the night. In general, I believe IT Pros work more hours than about any other group of professionals. You do not see accountants buying books on Excel and staying up to all hours of the night trying to get an Excel macro to work just so. You do not see crane operators bring home the big rig, or setting up a big rig in the back yard so they can practice their skills? While there are certainly forums and email lists for other professions, none are as robust as the ones in the IT community. Try finding a personal blog written by a plumber that covers all the plumbing repairs you can do by yourself! You may find such a beast, but typically it is run by a home hardware center, or a do it yourself magazine.

Today we begin the third day of the 2009 Summer Scripting Games. One thing has become clear to me as I have been reviewing hundreds of scripts, all of which are designed to do essentially the same thing, is that there is not a single way to accomplish a given task. When I designed the events for the 2009 Summer Scripting Games, I wrote “solutions” for each event. This was how I decided if an event was a beginner or an advanced event.

For problems that required a great amount of thought, or perhaps a great deal of code, I decided that was an advanced event. For problems that I solved quickly, or required a minimal amount of code, I labeled the event as a beginner event. This is, of course, a fool proof approach.

The reason is that we all approach problems in a different manner. Some of the advanced events have been solved quickly, and using a minimum amount of code. Why? Because the person writing the script used a different approach than the one I envisioned. Some of the beginner entries have been horribly convoluted and complex for exactly the same reason.

The one thing I believe I did right in crafting the events for this years Summer Scripting Games is I deliberately left the tasks a little vague (and in some cases really vague), I was able to do this because this year the games are not a competition, rather they are a show case. It has been extremely fulfilling to see how different people approach the same set of guidelines.

This is where collaboration comes into play. It is obvious that no single person has all the answers, or all  the best approaches to a task. Clearly experience exposes one to a variety of disciplines, methodologies, and insights that can be gainfully employed in a judicious manner to craft novel approaches to mundane problems. However, the naivety of inexperience can likewise play a significant role when  the simple question, “Why can’t we just …” is raised at the appropriate time in the planning process. Experience often rules approaches out of hand without serious consideration because such a solution has failed to meet our needs in the past. It is the gift of inexperience that allows for a fresh examination of previously tried and discarded approaches.

What would be cool for next years Scripting Games would be to have the events written way ahead of time, and to farm them out to a group of people and have them rate the event as beginner or advanced. Of course having 40 people work on a single project instead of a single person does not make the project go 40 times faster … it is not exactly like 40 times slower, it just seems that way.