I wanted to mention a really nice new feature of our 1.0 toolkit that greatly simplifies using it versus the Beta release. At the same time I want to introduce Andrey Anastasov, the toolkit’s architect and the guy who is perhaps most responsible for all the time saving goodness the toolkit brings to VI administrators.
As people began to experiment with the Toolkit over the past 8 months or so, one question kept coming up again and again. You can basically boil it down to "why do I have to use all these funny parentheses everywhere even when I want to do something as simple as create a VM?" As an example of what I mean, consider this:
|
1 |
<p><span style="color: #000000;">new-vm -vmhost (get-vmhost myhost) -name myname</span></p> |
The syntax doesn’t look natural and is confusing when you sit down in front of the Toolkit for the first time. This can create a bad first impression, after all if you can’t figure out how to do something as simple as creating a VM, you’d probably guess that doing hard stuff would be next to impossible.We knew we had a usability problem that we had to fix. I think the team has done an excellent job solving the problem using what we call "Object By Name".
In fact, our PowerShell architect, Andrey Anastasov, has this to say about it:
"For its Beta, VI Toolkit implemented the get-then-modify usage pattern. Examples include Get-VM "My VM" | Start VM and Start-VM (Get-VM "My VM"). While constituting the very backbone of PowerShell, this pattern isn’t always convenient. And, as VMworld user feedback revealed, it’s not intuitive at all. So, for version 1.0 we added what we call object-by-name. It’s essentially shorthand which allows specifying an object’s name where an object is expected. For example, the old:
|
1 |
<p><span style="color: #003366;">New-VM -vmHost (Get-VMHost "My Host") -name "My new VM"</span></p> |
can now be conveniently rewritten as
|
1 |
<p><span style="color: #003366;">New-VM -vmHost "My Host" -name "My new VM"</span></p> |
Wildcards are there if you need them:
|
1 |
<p><span style="color: #003366;">Start-VM "Web*"</span></p> |
Intuitiveness is just one of object-by-name’s virtues. A more practical example makes it evident that it also saves tons of typing, not to mention the wonders it works for readability:
|
1 |
<p><span style="color: #003366;">New-VM -vmHost (Get-VMHost "My Host") -datastore (Get-Datastore "My Datastore") -network (Get-Network "My Network")</span></p> |
becomes
|
1 |
<p><span style="color: #003366;">New-VM -vmHost ‘My Host’-datastore "My Datastore" -network "My Network"</span></p> |
So, it’s neat, intuitive, and convenient. What else is there to add? Well, it follows the bliss principle – what you don’t know about won’t hurt you. Actually, object-by-name is so unobtrusive you can easily miss it if you don’t know it’s there. The unobtrusive characteristic was one of our design goals. While we finally settled for a design which just quietly accepts names in place of objects, it wasn’t the only option we looked at. As an alternative, we considered adding extra parameter sets, the way a cmdlet like Stop-Process does it. But when you think about it, multiplying parameter sets and documentation isn’t a price you’re ready to pay when your objective is simplicity.
Looking back, the greatest challenge the team faced with object-by-name was in determining where to search for objects in multi-server scenarios. We found that if a cmdlet is invoked with a mix of object names and objects from different servers, there’s no universal strategy that’s both useful and intuitive. So we finally settled for limiting the ability to mix objects from multiple servers with object-by-name. This way, we’re leaving the door open for a future extension. Users already helped us a lot by producing the idea for object-by-name. Let’s see what they have to say about its implementation and possible enhancements."
Why is simplicity so important?
Have you ever felt like it would be quicker to do it yourself than to explain how to do it to someone else? That’s not necessarily a bad thing. A lot of times when a problem comes up that’s too hard for the sysadmin to solve, the problem gets turned over to a solutions team, who are experts at things like automation and integration. This sounds good in theory, but in practice it’s extremely hard to transfer knowledge from one head to another, and this can lead to a long and frustrating cycle of getting the problem almost solved. The way we look at it, a tool that 95% of people can use to solve their most urgent problems is better than a tool that 5% of people can use to solve every problem imaginable.
P.S. If you’re going to be at VMworld this year, be sure to stop by and say hi to Andrey and me, either at our session, or at the PowerShell demo area, hope to see you there.
