I can't be the fist person to notice this, but Powershell is immensely powerful as a code generator. Here-docs  plus the lack of a need for print statements make the process soo painless. Here's my function for generating audit tables:

function Output-CreateTableBlock(
    [string] $auditTableName, 
    [Microsoft.SqlServer.Management.Smo.TableViewBase] $baseTable) {
@"
print 'Creating table $auditTableName'
go

CREATE TABLE [dbo].[$auditTableName] (
    AuditID                int identity not null,
"@
    $baseTable.Columns | ForEach-Object { Output-ColumnDeclaration($_) }    
@"
    AuditAction                varchar(12) not null,
    AuditDate                datetime not null,
    AuditApplicationUser    varchar(200) not null,
    AuditDatabaseUser        varchar(200) not null,
    AuditApplication        varchar(100) not null,
    AuditFromHost            varchar(100) not null
    CONSTRAINT [PK_$auditTableName] PRIMARY KEY  CLUSTERED 
    (
        [AuditID]
    )  
)
GO

"@
}

This is inside a bigger script that enumerates all the user tables in the database and generates the drop, create, and trigger blocks to hook up our audit tables.

The conundrum I am facing now is: Is it better to have good code or an easy to read template. I started with one giant function that looked up a bunch of stuff then a giant here-doc with the template, then refactored that into functions with one specific purpose each.

I'm not a big fan of code generation anyway (except in special cases such as this - where I am literally just making a easily computable transformation to some other data/metadata that I don't want to be part of my application) so I think I am going to stick with the well-factored approach. I wish code generation was just built into the language like macros in lisp or boo. Then I would just use that language to build everything.

I sometimes find it convenient and necessary to run scheduled tasks or services as myself. I know this is bad, but what can I say. I've been cleaning up my act.

We recycle passwords every 45 days. Password reset day is always kind of stressful for me. I am going along with my business and bam! Locked out. Call help desk. "You again?" Get unlocked...

Next time, I'll be ready:

@('localhost','server1','server2','server3') `
| %{gwmi -Class Win32_Service -computerName $_ `
| where {$_.StartName -like '*cbilson'} `
| select Name, StartName, Status }

So that's the services, what about scheduled tasks? Well, there is the Win32_ScheduledJob WMI class, but it looks like that doesn't find scheduled tasks created using the scheduled task wizard? It's not working for my scheduled tasks anyway. Bummer.

Of course, this is a band-aid. They should just check the event log on my login server and see why I got locked out. Or maybe monitoring this kind of stuff even. I wonder what they do when an authority figure locks out their account. Even scarier: when a service account locks out! Our help desk doesn't seem to know how to trouble shoot this problem though and since we're still in business, I guess it's not as serious a problem as I am making it out to be.

Jeffery Snover, an Architect on the PowerShell team, has a really good post here.

One thing I find, using PowerShell, is that it's natural to want to have one place to do everything, but the world really works better when you have specialization. PowerShell works really well for me as an integration tool. I often want to do things like threading, create new types, implement interfaces, etc., in PowerShell, but I'm kind of glad I can't.

In general, If I'm going to be writing new code, not integrating existing code, I think PowerShell is the wrong tool for the job. I would rather not have the language and the shell itself encumbered by the fact that people are using it to do things that should really be done in a systems programming language. Think about it: In C#/Visual Studio...I have intellisense, help, unit testing features, syntac highlighting (Code Rush!). That's where I want to write lots of code.

PowerShell is right in the sweet spot for automation and integration. I can go without Visual Studio (though it would be nice!) and TDD, because I'm not writing massive amounts of code in PowerShell. This is my virtuous cycle.

An old boss of mine, Josh McKone used to say, "Make it easy to do good things and hard to do bad things," as hid kind of mantra for API/library design. I think PowerShell hits this mark perfectly.