Scott just finished writing about his boss (and now him) using Blat to help him Get Things Done.

I’ve been “Getting Things Done” for some time, and one thing that’s always annoyed me was how difficult it is to convert a desire into a categorized task. Outlook 2007 had the opportunity to make this better with the quick-entry field in the TODO bar, but tasks entered that way unfortunately have a due date for “Tomorrow.” While not terrible, it means additional fiddling around – which I wanted to avoid in the first place.

One question that comes up fairly frequently in our internal mailing list, the newsgroup, and the internet at large is how to call a webservice from PowerShell. In fact, several excellent PowerShellers have written about it: Keith, and Geert. In general, the guidance has been to use wsdl.exe to generate the webservice proxy, compile that proxy into a DLL, then finally load that DLL into memory.

This is a topic that I cover in my upcoming book, and initially wrote a script to automate these proxy generation steps. However, the prerequisite to running a script designed in that matter is fairly huge. Wsdl.exe doesn’t come with the .NET Framework, so you need to have the .NET SDK installed. That was something that made me uncomfortable, so I instead opted for a solution that could generate the web service proxy without wsdl.exe.

Allow me to be tragically late to the party in pointing out that Bruce Payette’s PowerShell in Action is now available.

As shown by its Amazon page, the reviews are immensely positive.

Unfortunately for me, I’ve sequestered myself from reading any of the PowerShell books until my own is complete. This one, however, calls longingly from co-workers’ desks as I walk down the halls :) Conversations with Bruce are always interesting, and this book is sure to not disappoint.

Over the last while, Scott Hanselman has been blogging a lot about some pretty cool ideas – controlling an IR port through C#, monkeying around with robots, and of course, PowerShell.

This all came together today, with the publishing of the second part of his Coding4Fun series, “Microbric Viper Robot with an Iguanaworks IR Serial Port and PowerShell.”

It turns out that the chisel nib on a thick whiteboard marker is actually exceedingly good for whiteboard calligraphy. It gives an x-height of about 20mm, though :)

The only problem is the guide lines – since on a whiteboard, there are none :) I’ve tried penciling them in, but that doesn’t work very well. I think my solution for that will be the true geek way – lasers.

One of the things people commonly ask about is support for rich keyboard macros and hotkeys in PowerShell.  For many, a pointer to the Doskey hotkey reference (which provides the history management functionality in PowerShell’s “cooked mode”) is enough: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/doskey.mspx?mfr=true.

Once you’ve become used to those features, though, you start to want more – especially if you’ve grown accustomed to some of the power available on traditional Unix shells. Typical questions include:

Martin Zugec recently wrote about a security concern he has with PowerShell: Once you have a credential (i.e.: from Get-Credential,) it is quite easy to get the plain-text password by calling its GetNetworkCredential() method.

The reason we don’t make this more difficult is that you already have the credential. In security, something is either possible or impossible – “hard” is just another way of saying “possible.” We designed the GetNetworkCredential() method to give you the System.Net.NetworkCredential class required by many network classes in the .NET Framework, so we definitely want it to be possible.

Ask any driver where they get their gas, and you’ve opened a deep discussion. There are the few that get it from wherever (including the canteen in the back of their trunk because they always run out,) but most drivers have a preference.

The first question is, “Where do you get your gas?” Do you go for the cheapest gas station you can find, or go to the expensive places because it must be better? For that question, it seems that there really isn’t a difference:

An interesting problem recently came up in the PowerShell newsgroup, where somebody was trying to use a tool (jpegtopnm.exe) that let you pipe its binary output into a file. This works on Unix (and from cmd.exe,) but unfortunately generated a corrupt image when done in PowerShell.

When PowerShell launches a native application, one of the benefits we provide is allowing you to use PowerShell commands to work with the output. For example:

Recently, Jeffrey wrote a post, “Blog your initial PowerShell  experiences.” I thought, “Even better, blog your automation!” So much of what makes people fall in love with PowerShell comes from the little problems it helps you solve. The more of those techniques we can help people learn, the better.

That post turned into “Break your Writer’s Block” – which is good, because there is already a good discussion going about blogging your automation here and here. Make sure to read the comments (if you haven’t already,) as they are an excellent source of reader contribution.