Charlotte PowerShell Users Group

§ December 5, 2011 02:18 by beefarino |

CharlottePoshUgI’m very excited to announce that exactly one month from today will be the first meeting of the Charlotte PowerShell Users Group.  Moreover, I’m giddy with anticipation as this first meetup will play host to Ed Wilson of the Microsoft Scripting Guys blog and “the Scripting Wife” Teresa!

We’ll be meeting at the Charlotte Microsoft campus at 6pm on January 5, 2012.  The schedule for this meeting is roughly as follows:

  • 6:00 – 6:30 pm: arrive and socialize.
  • 6:30 – 7:00 pm: sponsors, group roundtable.
  • 7:00 – 9:00 pm: Ed Wilson discusses PowerShell Best Practices

If you are near Charlotte, North Carolina and use PowerShell in any capacity, I encourage you to join the group and attend this meetup.  Not only will you reap the benefits of Ed’s talk, but you’ll help shape the group to best serve the local PowerShell community!



Automating Code Changes with StudioShell

§ October 3, 2011 04:27 by beefarino |

imageIn the last few talks I’ve given on PowerShell for Developers, I’ve focused on build, test, and code automation.  When discussing StudioShell, I’ve pulled a very effective demo from a real-life project…

After wrapping up an iteration with a client, they returned to me with a new 300,000-line code base spread over about 200 (very messy) files.  They were in the process of implementing a set of “corporate” coding standards and wanted some help getting their existing codebase to these standards.

One standard in particular was that and property that meets these criteria:

  1. is public
  2. returns a boolean

should start with “Is”.  So in this example code:

public class Demo 
{
   public bool Enabled { get;set; }
   public bool Valid { get;set; } 
   public bool IsRunning { get;set; } 
   public string Name { get;set; } 
   private bool Applied { get;set; } 
}

The properties Enabled and Valid need to be renamed to IsEnabled and IsValid (lines 3 & 4).  The IsRunning property already meets the standard (line5), the Name property returns a non-boolean type so the standard doesn’t apply (line 6), and the Applied property is private and excluded from the standard.  In the end this file needs to look as follows:

public class Demo 
{ 
   public bool IsEnabled { get;set; }
   public bool IsValid { get;set; } 
   public bool IsRunning { get;set; }
   public string Name { get;set; }
   private bool Applied { get;set; }
}

While it’s entirely possible to apply this standard by hand, the thought of scouring 300,000+ lines of code for properties that meet this criteria is not an attractive task.  FxCop can probably find these properties for us, but it can’t apply a fix – that still requires human intervention.  Best case scenario, I’m looking at days of mind-numbing monkey-on-a-keyboard work.

This is the kind of problem that screams for automation.  This is where StudioShell shines.  Here’s how I slashed through this Gordian knot…

First, I isolated a single code file in my StudioShell console, so I could work out the pipeline logic I needed without obliterating the codebase:

> cd DTE:\solution\codemodel\demoapp\program.cs

Second, I use PowerShell’s filtering capabilities to isolate all public properties in the file:

# spacing added for readability
> ls -recurse | where { 
     $_-match 'property' -and
     $_.access -match 'public' }

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
-----  ----                          --------- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid 
d+ < vsCMElementProperty IsRunning 
d+ < vsCMElementProperty Name
Once I have all the properties isolated, I need to filter the properties to those that returning booleans.  This required a little investigation using get-member, but once I found the Type property of the CodeProperty class, I was home free:
 
#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
    $_.access -match 'public' -and
    $_.type.asFullName -match 'bool' } 

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 

        Kind                         Name 
        --------------              ---- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid 
d+ < vsCMElementProperty IsRunning

The last factor to consider is the property name – I only need names that do not start with “Is”.  Easily done:

#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' -and
   $_.name -notmatch '^Is' } 

Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
        -------------               ----- 
d+ < vsCMElementProperty Enabled 
d+ < vsCMElementProperty Valid
At this point, my pipeline is filtering out the correct properties – only public properties returning a boolean that do not start with “Is” are being included in the pipeline output.  The next step is to take corrective action against these offending property names.  The RenameSymbol method will execute the appropriate rename activity for me, ensuring that the new name is propagated across the entire codebase that is loaded in Visual Studio:
 
#spacing added for readability
> ls -recurse | where { $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' } |
foreach { $_.RenameSymbol( "Is"+$_.Name ) } 

> ls 
Location: dte:\solution\codemodel\demoapp\program... 
File: program.cs 
Code Container: Class Demo 
Available Operations: d+ < 
        Kind                         Name 
        --------------              ---- 
d+ < vsCMElementProperty IsEnabled 
d+ < vsCMElementProperty IsValid 
d+ < vsCMElementProperty IsRunning 
d+ < vsCMElementProperty Name 
d+ < vsCMElementProperty Applied
Once I verified that this worked as expected, applying the changes across the entire code base was a trivial matter of changing the root of my recursive search to the root of the code base:
 
#spacing added for readability
> ls dte:/solution/codemodel -recurse | where { 
   $_-match 'property' -and
   $_.access -match 'public' -and
   $_.type.asFullName -match 'bool' 
} | foreach { $_.RenameSymbol( "Is"+$_.Name ) }

Done.  The total time it took me to complete the task across the 200+ files, including the necessary research, prototyping, and the full script execution: less than 30 minutes.  My input focus never moved from the StudioShell console, and my hands never left the keyboard (except when the script was running across the code base, during which time I helped my kids study their math facts).

This is why I made StudioShell – so I can scale iterative code and IDE solutions the same way an IT pro scales administrative solutions.  If a solution can be applied to a single line of your code, StudioShell can be apply it to all lines of your code.



Stupid PowerShell Tricks #1

§ September 20, 2011 07:01 by beefarino |

imageLast weekend I did two talks at SQL Saturday #89: one on StudioShell that seemed well-received, and another titled “Stupid PowerShell Tricks” that was basically an hour of laughter and learning.  Many thanks to the volunteers and sponsors, and to everyone who attended for all of their positive energy.

As I promised the attendees, this post will outline each of the techniques I demonstrated during “Stupid PowerShell Tricks.”  First though, some background…

What is a Stupid PowerShell Trick?

As I defined it in the session, a Stupid PowerShell Trick is any PowerShell element that has the potential to make your life or work easier.  These are not full solutions to exact problems, but rather small techniques you can employ in various situations.

The idea for the session came to me after going over some notes for previous PowerShell and StudioShell sessions.  I found that the most frequent and at times energetic question from the audience was:

What was that you just did there?

Most of the time this question was shouted in response to some shortcut I have built-in to my session instead of the main point of the presentation.  Turns out, I have more than enough of these little things to create a talk around them!

And the name?  It’s a derivative (read:ripoff) from David Letterman’s Stupid Human Tricks:

You may never need it, but if you ever need to stop a fan with your tongue, its empowering to know that you can.

So without further ado, here are the tricks I presented at SQL Saturday #89:

Trick #1: push-project

This is one of those personal work-habit shortcuts that integrates well with PowerShell.  I organize my work under a single Project folder in My Documents.  The name of each folder is typically the client for whom the work is being done, the name of an open-source project, etc.  This makes finding the project from the shell easy – I just navigate to the project folder and add the name of the project to the path:

1 # navigating to a project folder 2 PS> cd ~\documents\project\MyAwesomeProject

That’s an awful lot of typing though, and the only piece that changes is the name of the project.  So, I added a push-project function to my profile script that lets me navigate to these locations with less fuss and tabbing:

1 function push-project( $project ) 2 { 3 pushd ~/documents/project/$project; 4 } 5 6 New-Alias -Name pp -Value push-project;

In addition, an alias associates the shorter ‘pp’ to the push-project function, allowing me to navigate to a project with the much shorter:

1 PS> pp MyAwesomeProject

Yeah, like I said, the tricks are stupid.  But this saves me countless keystrokes a day and I move from client to client, project to project.

An Even More Stupider Trick

An audience member (can’t recall his name) had an awesome suggestion – assume $project is a pattern to match against the project names!  Turns out this no-brainer was easy as pie to pull off:

1 function push-project( $project ) 2 { 3 $path = "~/documents/project/$project" 4 if( -not( Test-Path $path ) ) 5 { 6 $path = ls ~/documents/project ` 7 -Filter "$project*" | select -First 1 ; 8 } 9 pushd $path; 10 }

Line 3 defines a full project path string using the input from the user in the $project variable.  Line 4 tests whether this path exists; if the path does not exist, it is assumed that the project name is incomplete, and lines 6-7 search the project tree for the first matching project name.  Line 9 completes the function by pushing the full project path onto the location stack.  In the end, getting to my projects has never been so tight:

1 PS> pp my

Trick #2: invoke-item

This next trick is a PowerShell gimmie – it’s built right in to the default session configuration.

There may be times when you want to open a text file, word doc, spreadsheet, etc from the console.  You can always invoke the program directly:

1 PS> excel supersecretdata.xls 2 PS> word supersecretdata.doc 3 PS> notepad supersecretdata.txt

But then you have to know what program to run; e.g., you can’t open a spreadsheet in notepad and expect to be able to read it.  So why not let PowerShell figure it out for you – use the invoke-item cmdlet to invoke the default shell action for a given file:

1 PS> invoke-item supersecretdata.xls 2 PS> invoke-item supersecretdata.doc 3 PS> invoke-item supersecretdata.txt

The example above will open each file in the appropriate application.  No fuss no muss.

“But Jim,” you say, “that’s a lot of typing!  Oh how I wish there was some way to accomplish this without all those keystrokes!”

Fear not PowerShell trickster!  There is an alias you can use:

1 PS> ii supersecretdata.txt

One of the more useful cases for this trick is when I want to open explorer at my current location in the shell.  Easily done:

1 PS> ii .

This takes advantage of the fact that the default action for a folder in Windows is to display it in explorer.  The dot in the command represents the “current path location,” which is always a folder.

Trick #3: PowerShell Here

imageThis one plays compliment to the previous trick.  Sometimes I need a PowerShell prompt open in the folder I’m looking at in explorer.  For that I use the PowerShell Here registry hack from Scott Hanselman’s blog.

This hack adds a PowerShell Prompt Here entry into the context menu for file folders.  Clicking the menu item will, as you’d expect, crack open a new PowerShell console that is pre-navigated to the correct folder. 

Super-handy to have when you need it.

Trick #4: Use VIM

imageVIM is a super-handy text editor that can run inside of your PowerShell console session.  Wait, let’s go over that again: it’s a text editor that runs inside of your PowerShell console.

VIM’s been around for … well, forever basically, in one form or another.  It’s a cross-platform port of the Unix VI tool, and it works the same in Windows, Linux, MacOS, you name it.

Mind you, I’m not at the point where VIM is my editor of choice – but when I need to make a quick edit to a file while I’m working in the shell it’s sooOOOoooo much faster to jump in and out of VIM than it is to bounce from the shell to notepad or PowerGUI and back to the console again.  My hands stay on the keyboard, which reduces the chance of my RSI coming back.

Now, VIM’s no picnic, but the juice is well worth the squeeze.  I highly recommend bookmarking the VIM docs, printing out some cheat sheets and jumping in.

Trick #5: clip

These last three tricks all have to do with pushing data someplace.

The first trick uses a built-in windows application named clip.exe to move data from PowerShell to any other application through the clipboard.  Very handy little trick:

1 PS> ls | clip

This example copies the list of files and folders in the current directory to the clipboard.  You can paste the list in any program – notepad, word, email, etc.

Of course you’re not limited to file lists – perhaps you need to add a list of event log entries in an email to some vendor support engineer:

1 PS> get-eventlog application -newest 20 | clip

Or maybe you need to copy the contents of a file:

1 PS> get-content myapplog.txt | clip

Or a list of every PowerShell variable name and value:

1 PS> dir variable: | clip

Or… oh whatever, you get the point.

Trick #6: out-gridview

Another trick to get data out of the console…

There is a handy built-in PowerShell command called out-gridview.  PowerShell n00bs tend to really like this command because it produces a UI – specifically a nice WPF grid displaying whatever data you pipe it.

Rather than show you what this does, I’d rather you play with it for yourself – take the examples from Trick #5 and replace “clip” with “out-gridview” and see what happens.

This one is really great when you want some data to hang around while you execute other commands.  The console is awesome, but the output doesn’t stick around too long. 

Trick #7: out-voice

And finally, the piece de resistance, the coup de gras, the penultimate of the first round of Stupid PowerShell Tricks – I present to you in all its glory … out-voice.

A few months back @shaylevy posted a little gem that demonstrated the use of the Microsoft Speech API from PowerShell.  I’ve already blogged a bit about it, and how using PowerShell to explore new APIs is both fun and rewarding.  This trick is basically an extension of that tweet from Shay.

One day I was working on a rather convoluted build while trying to help my daughter with some math facts.  The build took a long time to run - I wanted to give my little girl the full attention she deserved, but I also needed to get this build out.  So I rigged up a way for the computer to tell me when the build was completed.  This way, I can ignore my computer the way my daughter deserves, and still know exactly when the build has completed.

I added this code to my profile script:

1 $voice = New-Object -ComObject SAPI.SPVoice 2 $voice.Rate = -3 3 4 function invoke-speech 5 { 6 param([Parameter(ValueFromPipeline=$true)][string] $say ) 7 8 process 9 { 10 $voice.Speak($say) | out-null; 11 } 12 } 13 14 new-alias -name out-voice -value invoke-speech;

The $voice variable is set to a Speech API COM object in line 1.  Line 4 defines a function named invoke-speech; the param statement on line 6 and the process block on lines 8-11 allow this function to receive pipeline input.  The magic happens on line 10, where the input passed to the function is sent to the speech API for processing.  Line 14 aliases the command out-voice to the new function.

So how did this help me know the build was done?  Easy!  Add the above code to your session and try this:

1 PS> 'Hey beef, the build is done!' | out-voice

This is a great trick ignoring your computer during long-running processes:

1 # pretend this is a long-running process 2 sleep -seconds 5 3 "all done!" | out-voice

And, as the audience pointed out, the potential for abuse is significant.  Next time you leave for lunch, run this little quip, replacing my name with the name of your least-favorite coworker:

1 PS> while(1) { 2 sleep -seconds (get-random -min 90 -max 500); 3 'Jim, I need you over here now' | out-voice; 4 }

The ideas grow unbound from this point.  Read a file:

1 get-content myfile.txt | out-voice

Read the event log:

1 get-eventlog -log application | out-voice

… and so forth.

Conclusions

Stupid?  Maybe.

Useful?  Certainly.

Fun?  Oh yeah.  I highly anticipate you blogging on your own Stupid PowerShell Tricks; send me a link through the contact form or add a comment with a link to your blog!



Summer (and Fall) of Speaking

§ September 12, 2011 03:10 by beefarino |

SOOOOoooooOOOO… I’ve been a bit incognito lately and I thought I’d take a moment to summarize what’s been happening in the last three months,and give everyone a head’s up for the rest of the year.

May was consumed largely by two things.  The first was volunteer work at my kids’ school during EOG testing.  I was basically there for 5 hours every day for three weeks, so the teachers could administer 4 exams for each of their 24 students one-on-one as mandated by the school board.  I couldn’t stop the testing, but I did what I could to ease the pain on the school, teachers, and kids.  The second thing was prepping talks for the summer conferences – CodeStock, MADExpo, and DEVlink – and various code camps in the Carolinas and Georgia.  I headed out to CodeStock at the end of May, where I spoke about StudioShell; it was another fantastic conference experience, the highlight for me was getting to kick Charles Petzold out of the room so I could give my talk immediately after his.  I mean, freaking Charles Petzold.

June was full of CodeStock and MADExpo.  MADExpo went off rather well for a first-time conference.  The maker-esque focus is something I hope they elaborate upon next year – the sessions on netduino, robotics, and the like were a real hit across the board, and the kid’s area was a blast with snap circuits, legos, etc.  I’m considering submitting an origami session next summer, just to do something completely different…

July was comprised of work, work, work … and a vacation in the east Texas desert, during which I managed to line up a substantial contract that consumed most of August … except of course for DEVlink.  This was my first DEVlink experience and it was a good one (despite the lack of wireless and cell coverage and no, I didn’t stay at the Choo-Choo either).  I definitely made more connections – social and professional – at DEVlink than at any other conference thus far.  I did another StudioShell session there.  Jaws hit the floor, it was well-received.  I also attended PowerShell sessions by other speakers –  Sarah Dutkiewicz and Joe Webb – I love seeing how different people approach teaching this technology to others.

With the summer over and school back in session, my speaking focus is shifting back to user groups and events.  This Thursday, September 15, I’ll be speaking at the WNC .NET User Group about PowerShell for Developers.  I’ve expanded this talk to include PSake, Pester, and StudioShell; I look forward to the feedback on the new topics.

Then on Saturday, September 17th, it’s SQL Saturday #89 in Atlanta.  This will be my first SQL Saturday ever, and I’m so glad to be bringing the PowerShell and development love to the database community.  I have two sessions – the first is using StudioShell to automate Denali, and the second is a brand-spankin’ new talk titled “Stupid PowerShell Tricks”.  I got the idea from going over some of my other talks and realizing that the most frequent question I get asked is “What was that you just did there?”  I also find myself asking this question quite a bit of others – especially when I’m around admins or DBAs.  Since there is obviously much we can learn from each other, I decided to make a session out of it.  I’ll show you my stupid tricks and you show me yours, and we’ll all walk away with new ways to get stuff done!

Later this month – September 22nd to be exact - I’m heading to the Triad Developer’s Group to spread more PowerShell love to Carolina software developers.  In October it looks like I’ll be a guest on Talk TechNet (details to follow).  In November I’m heading up to the Raleigh .NET User Group to demo and discuss StudioShell.

Whew… at some point I’ll need to fit in some project work… I’ve got a couple of decent irons in the fire, some will go open-source and some won’t … more on that in another post…