Monday, June 29, 2009

Simple and easy site monitoring with PowerShell

In the *nix world, I really like monit for watching and managing small to medium apps. A while back we wrote an intranet app in Grails, running on Tomcat on a Windows 2003 server. The client was hosting the app themselves, but didn't have any IT staff whatsoever, so monitoring and managing this app was a little tricky.

I searched around for something like monit for windows, but didn't find any good free or cheap tools to do what it does, which is primarily to monitor and restart services upon failure. There's a million monitor and alert tools out there, but none that I found had a clean way to restart my Tomcat service if something went wrong. The closest thing I found was Hyperic's open source monitoring solution, but after 30 minutes of futzing around, it seemed too klunky to me for this small problem. I'm sure it's fine, and for bigger solutions it would probably fit well.

Then I ran across a couple PowerShell scripts that intrigued me - the first was for scraping a web page. After that find, it was just a matter of googling to find the remaining piece - restarting a windows service. Bingo! I hadn't done any PowerShell scripting yet, but it turns out to be a really sweet solution for this type of problem. All I had to do after that was to tweak the code to be a little more reusable, and I also created a simple grails view that would exercise the integration features I wanted to include in my ping test. From there it was just a matter of calling the script on a regular basis. In my case, I used the windows task scheduler. Here's what the script looks like:

$webClient = new-object System.Net.WebClient

###################################################
# BEGIN USER-EDITABLE VARIABLES

# the URL to ping
$HeartbeatUrl
= "http://someplace.com/somepage/"

# the response string to look for that indicates things are working ok
$SuccessResponseString
= "Some Text"

# the name of the windows service to restart (the service name, not the display name)
$ServiceName
= "Tomcat6"

# the log file used for monitoring output
$LogFile
= "c:\temp\heartbeat.log"

# used to indicate that the service has failed since the last time we checked.
$FailureLogFile
= "c:\temp\failure.log"

# END USER-EDITABLE VARIABLES
###################################################

# create the log file if it doesn't already exist.
if (!(Test-Path $LogFile)) {
New-Item $LogFile -type file
}

$startTime
= get-date
$output
= $webClient.DownloadString($HeartbeatUrl)
$endTime
= get-date

if ($output -like "*" + $SuccessResponseString + "*") {
# uncomment the below line if you want positive confirmation
#"Success`t`t" + $startTime.DateTime + "`t`t" + ($endTime - $startTime).TotalSeconds + " seconds" >> $LogFile

# remove the FailureLog if it exists to indicate we're in good shape.
if (Test-Path $FailureLogFile) {
Remove-Item $FailureLogFile
}

}
else {
"Fail`t`t" + $startTime.DateTime + "`t`t" + ($endTime - $startTime).TotalSeconds + " seconds" >> $LogFile

# restart the service if this is the first time it's failed since the last successful check.
if (!(Test-Path $FailureLogFile)) {
New-Item $FailureLogFile -type file
"Initial failure:" + $startTime.DateTime >> $FailureLogFile
Restart-Service $ServiceName
}
}
I posted my question (and my own answer eventually) on stackoverflow here, so keep an eye on that if you're looking for improvements to it. There's a lot more you can do with this script, like email upon failure, or monitor multiple sites. Hopefully this helps some other folks out there with problems like this. It was a really nice experience for me; simple and powerful. So hats off to the authors of PowerShell - I'll be reaching for that tool more and more in the future.

Sunday, June 28, 2009

Domain names for daughters

Though the biggest domain name purchases are probably long-gone since the initial dot-com boom, they still remain a valued property. They'll never be as valuable as real land of course, since we can always create more of them, as opposed to things like lake-front property.

The recent mad rush for facebook profile names reminded me of this new global scale of gold rush activity. And yes, I'm a little annoyed that someone that has been farming this interweb as long as I have was offered a name like dan.tanner2 (in my day, we used Mosiac. And we liked it!). It also reminded me of something I'm hoping will come in handy for my two daughters some day - their very own short and memorable domain names.

Finding a decent available domain name is a tenaciously difficult PITA. It's an exercise in creativity and luck, and girls names are especially tough. Not only do you have to wrestle with the general lack of availability, but also the likelihood that they'll change their name when they get married. In my case, that's sometime after age 28, when they've agreed to start dating.

In my case, my girls are named Maria Mae and Daniela Teresa. All good variants of maria and daniela were taken, which would've been ideal. And no last names were considered because of the potential marriage name change. After tinkering around for a while, here's what I ended up saving for them:
mariamae.com and danielat.com
They're both fairly mnemonic, and they're both flexible enough to last. And they're both shorter than my domain name!

It'll be a few years, but hopefully they'll be useful. Not to mention give me a little boost in the cool dad category. Not that I'll need any help in that category.

Now...where did my favorite plaid pants go?

Tuesday, April 14, 2009

In praise of refreshingly efficient meetings

Everybody dreads bad meetings. Meetings are often too long, too often, or don't accomplish anything. At some companies, this is what they are all like.

You can implement processes to help have better meetings (which is another meeting of course). Heck, I just attended a meeting last week whose title was how to structure our meetings to have less of them.

Like everything else in the thought-based industries, the effectiveness of a meeting is 10% process and 90% people.

The other day, I attended a meeting that was remarkably crisp and effective. It was a brainstorming session, so I wouldn't have expected it. The meeting started with a general leaning towards one solution to the problem, and 15 minutes later (15 minutes early), the meeting ended with a clear path towards the exact opposite style of solution.

I walked out of the meeting thinking, "Wow! That was fun!"
To which I quickly looked in the mirror wondering why the hell I would have just enjoyed being in a meeting. Developers have been bred to hate meetings, so I obviously needed to do some serious soul-searching.

What seemed unique to this meeting vs. so many others were the following attributes:
  • An inherent sense of urgency by role: The key person in the room was a company officer with a ton of experience making decisions on a limited schedule. Sure, everybody's busy, and some people are really busy, and have that ability to keep people in the room at attention. Maybe it goes with the title, maybe it's decades of experience, maybe a little of both.
  • Flexibility in thought (an open mind): There weren't any fixed or hidden agendas, which allowed the discussion to flow quickly through the options without getting hung up.
  • Real-time calculations: Part of the discussion involved ROI. We could've marked that data as follow-up items, which would've left the discussion muddy and forced another meeting, but it wasn't necessary. With the business having a good handle on their critical numbers, and the technology team having a good rough estimate for the project size, we were able to do the math in our heads and flip through the choices in minutes.
The simplest written analogy to this that I've seen is the chapter titled "Rattle Yer Dags" in the book Adrenaline Junkies and Template Zombies, by the legendary Tom DeMarco and Atlantic Systems Guild. (Highly recommended.)

And you can follow the guidelines given when you google "how to run an effective meeting". That's all good stuff...the unfortunate reality for most is that meetings like this don't happen often enough.

So, cheers to refreshingly efficient meetings.

Gotta go...I'm late for another meeting.

Wednesday, March 4, 2009

Who needs developers when you have IBM?

It used to be that software vendors sold customers bridges based on the lie that business analysts could write the software with their awesome new tools...eliminating the need for programmers.

I just ran across some interesting marketecture for IBM's Integration Developer product. They appear to have conceded that a BA can't program with the tool. But possibly even worse, the introduction to the product advertises the following:
WebSphere Integration Developer enables integration developers to assemble complex business solutions that require minimal skills, whether they involve processes, mediations, adapters, or code components. Users can construct process and integration solutions using drag-and-drop technology without having a working knowledge of Java.

Sounds like a great plan, huh? Hire an "integration developer" to implement a java-based integration without a working knowledge of java. Because you're just "assembling" complex business solutions...IBM's products take away the complexity for you! Show me someone that fits their target audience that can even properly define the words mediation and adapter.

A couple years back, I saw a presentation at NFJS by Neal Ford that pretty much matched my viewpoint exactly in my own experience. He sums it up in this blog series. Yes, integration is hard. Yes, it takes very experienced developers to get it even done at all, and even those very experienced developers will make a lot of mistakes and produce less than ideal solutions because this is a new field, and remote computing sucks regardless of how smart the solution is.

The bottom line is that you can't hide the complexity under a rug. Products like this will get you 80% of the way there, and by the time you figure out that they're not the right solution, it might be too late. You might have run out of budget, haven't finished, and have a bunch of unhappy customers mad at you. But congratulations, you've just helped your can't-get-fired-for-buying-vendor fund their next line of bridges to sell you.

Want to do it right? Simplify your problem by defining what information needs to go from A to B first, and then listen to the right people that have done this before and aren't getting paid based on how much of their product you buy.

Sunday, March 1, 2009

The Development and Infrastructure Team Dysfunctional Relationship

If you spend any time making software in a big company whose primary job isn't making software, the following patterns about the development and infrastructure teams probably apply:
  • The development and infrastructure manager are different people.
  • The managers and their staff sit too far apart for osmotic communication.
  • They are in calls or meetings together all the time.
  • Yet angst abounds between the two groups all the time, whether it's overt or simple passive aggression.
If you're lucky, the managers are technically competent and secure enough to have the good hard conversations that are necessary, thinking about things from the customers perspective and from each others perspective. Or if they're not technically current enough to have the conversation themselves, hopefully they can step aside and get the right heads together from each team to figure out things out together correctly.

Unfortunately, as the mighty MC Hawking likes to riff, Order from disorder is a scientific rarity.

Whether it's outright silly and misguided arguments, or the "WTF are they thinking?" kinds of conversations had within each group after a meeting, it seems these two groups consistently spend too much time acting like slashdot commentors and not enough time reading Peopleware.

What's difficult about this problem is that it's not a technical problem. It's the natural result of two diametrically opposed organizational forces.

If the developers would just stop writing crappy software.

If the infrastructure manager would just stop being such a grump.

If the business would just go away.

Believe me - they'd love to. This whole time they're wondering why your crappy system costs them millions of dollars, and still doesn't work as well as their free Picasa photo album, which arguably does more than your system that's shoveling bits from A to B just like all the other thousands of companies exactly like yours. But that's a whole 'nother story coming up...(the software sausage factory from a normal person's point of view).

Monday, February 23, 2009

Is this a cheeky feature, or an ironic bug?

Thursday, February 19, 2009

Line 6 BackTrack Review


I don't normally blog about the products I buy, but the Line 6 BackTrack rules. I've looked for ages for a good band recording practice tool, and this is finally it. In the past, I've used:
  • A digital 8 track (too cumbersome)
  • A portable mp3 recorder with an expensive portable mic (too clumsy and hard to balance, and I had to use some super flaky and buggy software to transfer files)
  • A laptop (again, too clumsy, and hard to work with on the fly)
Why does the BackTrack rule?
  1. It just works. You turn it on, and it records your stuff in really good quality for practice purposes. Marking stuff you like on the fly is a nice little bonus to help sift through stuff later.
  2. It automatically chops up the files for you based on pauses between sound. No more tedious manual splitting of tracks in Audacity or whatever your file splitting tool is.
  3. It's easy to get the files onto your computer - it works as a USB storage device, so you can drag and drop.
  4. It fits into my guitar case. No lugging some big piece of recording gear around any more, or even worse, forgetting it.
The only issue I had on the first night of practice with it was that I had configured it to a preset of Rock Band levels...meaning its recording threshold was pretty high and the mic gain was pretty low. On one of our lovely ballads, it missed the song's intro because it was below the recording threshold. (Or maybe it's a feature to discourage ballads.) It was easy enough to solve though - I just lowered the recording threshold a little.

All in all, some serious w00t factor...thank you Line 6!