Thursday, July 29, 2010

powershell shortcut

Just thought this was cool.
Suppose you want to monitor or know or look at some applications running on a remote server through Windows Task manger.
You could rdp to the box, then start the task scheduler UI and look at them.
or you could open a command prompt (assuming you have powershell installed) and run:

schtasks.exe /query /S /U /P

you'll get a list of everything scheduled that you have privs to see, including Next Run time and Status.
This doesn't only include things in the task scheduler but even system processes scheduled to run. For example, things from
Folder: \Microsoft\Windows\Tcpip
like
IpAddressConflict1

Pretty cool stuff.

Sunday, July 18, 2010

worflow timeouts

just thought this was strange and it took me a bit of debugging so I thought I'd share.

Suppose you have a workflow that does database updates -- say SqlServer. Now your Sql updates have timeouts. So does your workflow. But these two timeouts are unrelated. If your Sql time out is longer than your workflow one, you can find yourself in the situation that your workflow times out before your query finishes. It's an easy mistake to make, especially if you have multiple people working on it or if you are using some of the default values and it's not obvious what the timeouts are.

There are a series of delegates you set up for workflows: OnWorkflowAborted, OnWorkflowCompleted, OnWorkflowTerminated, etc.

You'd think -- or at least I did -- that one of the delegate methods would fire if the workflow timed out. But it's not true. Instead, the workflow returns false when the wait handle is set. So :

bool Ok = waitHandle.WaitOne(WORKFLOW_TIMEOUT) ;

in case of a time out, Ok is set to false. And that's the only indication that the flow timed out.

So you need to do something like
if (waitHandle.WaitOne(WORKFLOW_TIMEOUT))
...
else // <-- timeout
// do timeout logic.

What I think is even more interesting is that I couldn't find this in any of the sample workflow code I saw on the web. Really, most of it doesn't even set a timeout, which is probably "not optimal" (i.e., "really dumb").
But even the code that does set the time out, never checks to see if it actually has timed out.

Anyway, thought this may help someone sometime, so I'd post it.

--kevin


Friday, July 9, 2010

a while

I've been kinda busy and neglecting this blog. My bad. I've got a few geek thoughts to document about Windows Workflow and some TSql things that are pretty cool. Also been playing with Studio2010 a bit.
If I can get that documented this weekend, I will.

Until then, I ran across this quote from Einstein. At first I blew by it, but then I realized how it fits software development. The quote is:
"A clever person solves a problem. A wise person avoids it."

The part that's always disappointed me about IT is that cleverness is rewarded but wisdom is not. If you write terrible code that blows up and you work all weekend to fix it, you're a hero. A friend was telling me that Intel used to reward people for the number of bugs they found. Unfortunately, the people they rewarded were the people who were writing the code to begin with. The clever people added a lot of very complex bugs and then were heroes for finding them. And they got a bonus for each one.
I've seen that. One of my prior employers used to give spot bonuses for extra work. The people who won them were always the folks who did crappy work, but then would work all weekend to fix the problems it caused. I remember a couple cases where the systems were so bad, that they asked me to take a look at them. I corrected the issues, so that they didn't fail anymore. And I got... nothin'. Not even an "atta-boy".

Of course, on the positive side, I got to sleep at nights, since my stuff didn't blow.
:D