§ March 19, 2012 12:57 by beefarino |

CODEPALOUSASo I get back from CodePaLOUsa with a full head and abused liver to find that the Louisville Courier Journal decided to use my ugly mug in their article on the conference (they managed to misspell my name though – can’t win ‘em all). This picture was taken during an open space on raising geeks.

We’ve already had some fun with this on twitter, but I wanted to make sure everyone has their chance to poke some fun at me. So I’m having a caption contest!

If you want to participate, go here and enter a caption you think is funny. At the end of the week I’ll look over the entries and pick a winner based on lulz. I’ll announce the winner early next week.

Rules: your caption must be publishable on my blog. This basically means that if I consider the language or content of your caption inappropriate it’ll get nixed.

First and only prize: link to your blog from mine. Hey, it’s not as lame as it sounds, I get around 6K unique visitors a month...

So get crackin…

Vote for CodeStock 2012 Content

§ February 29, 2012 16:28 by beefarino |

imageIt’s that time of year again.  The voting for CodeStock sessions has been opened!  Looking over the list of possible talks, I’m really excited and highly encourage you to go if you can.  CodeStock was my first conference and speaking experience, and I can’t help but think it is a huge part of why I enjoy speaking so much.

And while we’re on the topic, I’d really appreciate you voting for my sessions this year.  I’m changing things up a bit, a reflection of my changing priorities and attention.  Oh, I have PowerShell sessions, don’t worry.  Two in fact:

However I’ve also submitted two sessions of a different ilk.  The first is part of my 2012 resolution to learn various maker-craft, such as crochet, robotics, electronics, etc.  Fun with Lilypad! promises to be a unique and engaging session.  I mean seriously, how often can you say you saw someone program their hat?

The other session is a group panel on Raising the Next Generation of Geeks.  I want parents to share their experiences of fostering the geek in their children – what works, what doesn’t, what the major obstacles are.  I want to hear about projects you do with your kids that sparked the fuse on their nerd-bomb…

If you plan to attend and think you’d like to experience one or more of these sessions, then I humbly ask for your vote.

Upcoming Speaking Engagements

§ February 24, 2012 13:00 by beefarino |

Just a quick note about two upcoming speaking engagements where you’ll have the chance to soak up some PowerShell love.

In mid-March I’ll be presenting Stupid PowerShell Tricks for the .NET Developer at CodePaLOUsa.  If you write .NET code – be it for the web, the enterprise, or a device – I’ll show you how PowerShell can make mincemeat out of large, boring, and repetitive tasks.  In addition I’ll be showing off how I’ve personally integrated Mercurial and Git into PowerShell, how I use PowerShell to drive my software build process (including running remote tests), and how I automate massive changes to my source code.

Then on April 14 I’ll be in Atlanta for SQL Saturday #111, where I’ll discuss PowerShell Modules you Should Know About.  If you’re new to PowerShell, this will be a great session to attend as it will show off a wide diversity of the things that PowerShell can do – from database management to simple UI to spooling Hyper-V virtual machines. 

I’m looking forward to both of them, and I hope to see you there!

StudioShell 1.2 Release

§ February 23, 2012 10:24 by beefarino |

image_thumb1_thumbA bit late to the blog, but I’m happy to say that StudioShell 1.2 has been released! This release has been a long time coming, due largely to my lack of focus and a rather ambitious feature set.

This post is a breakdown of the key elements in the 1.2 release. I’ll elaborate more on some of these items in future posts.

NuGet Support

While I prefer the StudioShell console experience over NuGet, NuGet has a user base that is 170 times larger than StudioShell. It’s silly not to do everything I can to support that environment – both in terms of enabling StudioShell features in the NuGet host and in leveraging the NuGet distribution mechanism.

In the previous releases, the majority of StudioShell features were available from the NuGet console; however, some of the more “luxurious” features wouldn’t work – for instance, you could add menu commands from the NuGet console:

1 PM> new-item dte:/commandbars/menubar/help ` 2 -name clickthis -value {"hello world!" | out-host}

The “clickthis” menu item would appear, but it wouldn’t do anything when you clicked on it. The 1.2 release addresses these shortcomings – you can now expect full support for StudioShell functionality from the NuGet package manager console.

In addition, you can now install StudioShell via NuGet. Just search the public repository for the “StudioShell” package:

1 PM> install-package StudioShell

PowerShell Support

One of the most frequent requests I receive is to use StudioShell from the standard PowerShell console. This would be a great enabler for automated build scenarios and software factories.

This is now possible with the 1.2 release. You can pull StudioShell into your standard PowerShell console just like any other module:

1 > import-module StudioShell

This results in a DTE: drive that is attached to a new instance of Visual Studio that you can use to load solutions, edit projects, create code, etc.

Experimental SSMS Support

A friend of mine is interested in using StudioShell in other Visual Studio shell applications – specifically in BIDS. We haven’t gotten that far, but the StudioShell 1.2 MSI installer does allow you to integrate with SQL Server Management Studio 2012 (Denali).

Not all of the DTE: drive is available – in particular the project and code models don’t seem to be supported in SSMS. At the same time, there is still a lot of useful functionality available. E.g., the debugger hive is fully functional, allowing you to spelunk stacks, locals, etc. during a SQL debugging session.

This feature should be considered highly volatile until we can get some people using it regularly and reporting the issues. Use at your own risk.

DTE: Drive Topology

In the past year I’ve learned quite a bit about designing useful PowerShell providers. I’ve applied some of this knowledge to the StudioShell PSDTE provider by changing the layout of some of the drive nodes.

In previous releases the code model and project model occupied a shared space on the DTE: drive. This made sense from an object-model perspective – projects contain files, files contain code. Unfortunately it made for some slow pipelines; for instance, applying global code changes:

1 ls dte:/solution -rec | ` 2 where {$_ -match 'codeclass' } | ` 3 set-itemproperty -name Comment -value (get-date)

would force iteration of all project items, properties, and code. Very slow operation during which the shell and Visual Studio remain unavailable. The new drive topology moves the code model to a peer of the project model:

1 ls dte:/solution/codemodel -rec | ` 2 where {$_ -match 'codeclass' } | ` 3 set-itemproperty -name Comment -value (get-date)

effectively isolating code from projects and enabling faster “bulk” operations.

These changes are breaking for existing scripts that rely on the old path topology, but 1.2 includes a simple way to revert the drive topology to the previous version when you need to:

1 > use-pathTopologyVersion 1.0

In a nutshell, this command tells the PSDTE provider to use the drive topology that existed in the specified version of StudioShell. If you have a script that relies on these old paths, just add a call to use-pathTopologyVersion to the top of the script and StudioShell will re-enable the old paths. When you’re done, you can bounce back to the current topology just as easily:

1 > use-pathTopologyVersion -current

Cleaner Codebase

StudioShell started as a very … organic project. It grew as I needed it to grow, and it still does. As a friend once understated, “it’s a bit monolithic.” The code needed some serious refactoring before any of the previous features could be realized.

A quick shout-out to two vendors who proved key in this process: NDepend was essential in teasing apart concerns, and PostSharp greatly simplified several feature implementations.

Bug Fixes

Of course this release contains plenty of fixes as well. A special thank-you to everyone who supports this project by submitting issues and discussing features. Keep ‘em coming.

Looking Ahead – looking for help

So what’s next for StudioShell? First and foremost is a more aggressive release pipeline. With 1.2 comes a PSake build, the next step is to incorporate automated deployments to NuGet and CodePlex. I don’t want to wait another 6 months to package a release.

I’m also looking at expanding the DTE drive topology to include some other Visual Studio services. More on this later.

I’d also like some help getting StudioShell usable in other shells, especially the SQL family of Visual Studio shells. If you have the inkling to help, please get in touch.