Olá,

estou, mais uma vez, afastado do meu blog nos últimos dias. O motivo, claro, são minha agenda. Estou envolvido mais uma vez na organização da 10ª Semana da Computação (aka Semcomp) do ICMC, na USP de São Carlos. Ao contrário do ano passado, em que fui presidente da comissão, este ano estou trabalhando somente com o site do evento, além de negociar alguns contatos com patrocinadores e palestrantes.

Mas vim aqui para falar de outra coisa: PowerShell 2.0. Jeffrey Snover, PM do time do PowerShell, deu uma entrevista no site WinIT.com sobre o que vem na versão 2.0. Já é conhecido que uma das coisas que será alterada para a versão 2.0 era a questão da velocidade, que comentei aqui mesmo vários meses atrás. O PowerShell pode ficar incrivelmente lento se você fizer alguma coisa errada (como por exemplo carregar um arquivo de log com alguns gigabytes em uma variável). Veja, na íntegra, a entrevista dele. Você pode ler também a entrevista e mais um monte de coisas legais no próprio site do WinIT.com.

Since TechEd in June, 300,000 more IT shops have downloaded command line scripting language PowerShell, bringing the total to 1.3 million downloads in the last nine months. Small IT shops to large enterprises are using PowerShell to cut hundreds of lines of code down to a single command line. As a result, IT managers are becoming more productive. They are able to complete in a matter of minutes administration tasks that used to take them hours.

Jeffrey Snover, the creator of PowerShell and a Windows Partner Architect at Microsoft, spoke with SearchWinIT.com recently about the scripting language's potential to save time and cut tasks, new third-party tools that use PowerShell and some features that IT shops can expect in the next version, PowerShell 2.0.

SearchWinIT.com: What's next for PowerShell?

Jeffrey Snover: We've been pretty up front that the need of IT admins is [for remotely administering machines]. It's a new model for [remote management] to 10 machines, 100 machines, maybe even 5,000 machines. So basically, 'remoting' will be built into the heart of the PowerShell engine and then exposed as a set of language features and commands versus 'remoting' being done as a bolt-on afterthought. People who in the past were intimidated by 'remoting' or found it difficult will find this simple.

What are some examples of how IT shops are using PowerShell?

Snover: When I was at TechEd, a guy came up to me and said he replaced his 481-line Visual Basic script with a single PowerShell line. He did a hardware inventory across multiple machines and generated a report with a single PowerShell line of code. The reason why is because with PowerShell you get a set of objects, pipe it out to HTML and, voilà, you've got an HTML report.

Another customer came in and brought their scripts with them, and we rewrote their VB script to PowerShell. One of their VB scripts was 750 lines of code, and we replaced it with a 15-line PowerShell script.

Can you give me an example of a tool in PowerShell that will make a real difference for an IT shop?

Snover: The ability to compare objects. You can get a set of objects that are stored in Excel, XML, a database or your hardware configuration as it exists right now. Then using a single line of code, you can compare the objects in those forms against the current running objects that show the difference [between the two]. So I've got a set of XML files that take snapshots of when the system is working. Then I compare them against the current state and show you all the processes that were created since then or used to exist but don't exist now. And you do that with a single line of code. Taking it to another level, you can take the working set and round it to two megabytes and say 'Only show me the working set having changed if it changed by more than two megabytes.' That's incredibly powerful to do with a single-line command.

Some say that learning PowerShell is easy, some say it's not. What is the learning curve?

Snover: IT guys, their hair is on fire. If something doesn't look like a bucket of water, they're not going to address it. That's why Exchange 2007, VMM [Virtual Machine Manager], Desktop Protection Manager have admin GUIs layered on top of PowerShell. So an IT admin can be using PowerShell and not even know it. But, at some point, they may say this GUI doesn't do quite what I want, and they're going to notice that each of these products allows them to see the command-line equivalent for the operation they just did. They can take that command-line equivalent and cut and paste it into a line or into a file and modify it to meet exactly their needs. PowerShell can be the simplest scripting tool out there like Bash in the Unix world, or it can be a very sophisticated tool for the IT guy running the Federal Reserve.

What kind of third-party development are you seeing around PowerShell?

Snover: In some cases, there are people producing PowerShell commands and then making them available so that PowerShell can manage their products. The second is hosting tools. PowerShell is an interactive shell, but that's just one of the hosts. PowerShell is also an embeddable engine like a library that you can plug into anything. There are folks like PowerGui.org. They wrote a GUI that allows people to take commands and expose them as graphical elements in a GUI. Another is PowerShell Analyzer, which is modeled after SQL Query Analyzer, where they've got this Interactive Development Environment, but you have syntax coloring. You can select portions of your script and execute them, or you can execute your whole script. Then you've got PrimalScript, the number one VB scripting IDE, that has PowerShell support as well.

Any well-known application vendors jumping on board?

Snover: We've had quite a few discussions with companies that are doing PowerShell work but aren't public with that yet. With these vendors, we're taking their product as is and then loading in PowerShell and being able to do extensions to make their applications scriptable through PowerShell. You'll have heard of these vendors and [those announcements] will probably be made by early next year I think.

Microsoft has said that all of the admin GUIs in its products would be based on PowerShell by 2009. Where does that stand?

Snover: All the products will have PowerShell available. Whether or not [the product teams] will have converted over their user interface layer on top of that is up to them. That's not required in the 2009 time frame. A bunch of [Microsoft product teams] are doing it, though. It really comes down to the question of were they planning a major rewrite of their GUI.

Where can IT professionals get trained? What resources are available?

Snover: We underestimated the rate of PowerShell adoption and, therefore, the need for training. We knew books would be an important element, so we worked hard with the book vendors, and there are 11 books and another five coming on board. A lot of people are getting trained that way. We also have a number of external partners doing training like Sapien, Desktop Engineering, Ameritech; and Global Knowledge just licensed Sapien's training. There's also a bunch of Microsoft field organizations providing training for the customers they support.