Work Journal for Monday, June 10th 2013

Note: This is a "work journal" entry. Historically, I've kept these in a file on my work machine, but I'm getting sick of trying to maintain that system. Instead, I'm going to start dumping it here. Feel free to ignore this post as it's mostly a way of me figuring things out at work when I'm really, really stuck. Future work journal posts will probably be posted here too. I hate to admit it, but course development stalled after Wednesday last week. With the oven and AC installation, I was just too frazzled to get much work done. Thankfully, I did manage to find something mindless to do with my time. I picked up a copy of Slide:ology. It's a book about making effective and beautiful presentations in a business context. Most of it is directed to high-stakes situations such as keynotes or pre-sales presentations, not IT Education. Still, it was recommended by a local Lullabot. After DrupalCon, it seemed obvious that many of the presenters there were following the same body of work. I decided to pick up a copy, thinking that if nothing else, I could spend Thursday and Friday reading through it all. I picked up a DRM-free PDF at O'Rielly. Perhaps unsurprisingly, the book is astoundingly excellent. I managed to get the expense approved by my boss, so I essentially got the book for free. Now that it's Monday, I'm once again facing this class and what to do with it. The problem right now is that when I outlined the current module (think "unit", such as in a textbook) in the course design process, I decided to expand its scope beyond the original Q Nami class. Originally, I ignored all the activity extensions the product provides and instead focused on only the one that used WebSphere MQ. This made sense at the time as MQSoftware was in desperate need to educate the people it sold the product to, and they all wanted to do monitoring through WMQ alone. So, while other extensions were known to exist, it simply wasn't relevant. Now that the product is owned by BMC and given the much less endearing name, "BMC Middleware and Transaction Monitoring", it's hard to justify it the same way. At present, I have no idea what extensions are predominantly used. I have some suspicion that HTTP input filters, and JEE Servlet filters are used instead. Those could be used to monitor large web applications much easier, especially if REST or something else like that is used. Still, it's hard to ignore the WMQ stuff without knowing for certain. I've pinged some of my old coworkers, maybe they can give me a vague idea. The worst they can say is that WMQ isn't used at all any longer, and most of the material I have built is useless. Either way, I'm still facing the problem about what to do with this module. By deciding to cover multiple extensions, I've made this module a bit unwieldy. As a rule, most developers hate deep, methodical lists of product features and capabilities. They prefer brevity in lists, concepts laid out clearly and efficiently, and one solid example covered in detail to show them how it's done. After that, they want to figure it out themselves. One thought I had last week was to create a "Extension Map", grouping similar extensions together like continents. It'd do the job, be slightly humorous, and a non-linear presentation can be used to make all the detail opt-in. That'd cover the kinds of extensions, pretty well, but that's only a part of the module. Really, what this module should be is about how to capture transactions by instrumenting infrastructure. What's really involved with instrumenting infrastructure?

First, you need to know what you're going monitor. It's too easy to say "everything" and then you have a lot of unnecessary cruft in your infrastructure that you may not need. Some companies may find this easier if they have lots of automation tech for system management, but most will do this the old fashioned way. Knowing what you're going to monitor requires a lot of research in model design. So now you need to involve IT admins, business people, and the model developers in order to get things moving.
Once you've identified which bits of infrastructure you're going to instrument, you need to start planning the deployment process. Mostly this is going to come down to scheduling an outage window. If the number of systems is small, you can do them all at once. For big deployments, you should stage it so that any performance or configuration problems can be isolated. Different teams may be responsible for specific pieces of infrastructure by type or vendor, and thus they may want to schedule their own independent outage window.
Deployment starts by staging files to the target servers. While they can be dumped anywhere, it's best to put them all in a standard directory. I think I recommended "lib" in the agent installation directory, but I think I may change that to "extension-staging". Extension files must be deployed to the local workstation first by using the Management Console, then uploaded to the target servers through normal IT processes. Automation can be used here to make things easier when the environment is large.
Activating the extension is different for each kind. Most involve some sort of configuration to be made to files or in the GUI. Some require only files be put in a specific directory and a CLI command run. Some also may require that the piece of infrastructure be restarted, although I think WMQ v7 no longer requires this.
Once activated, the extensions need to be validated that they are functioning correctly. There's easy way to do this, really. In general, you should look at the infrastructure logs to see if the extension was indeed loaded correctly. You could also see if logs appear in the MQS_HOME folder generated by the extension. That's usually a pretty good indication that the thing is working. Nothing beats deploying a model specifically designed to check if the extension is working, however. That gives you an end-to-end verification.

I've actually already written something like the above, but I simply wasn't happy with how it turned out. I threw it aside in disgust on Friday, probably because I was just bored with the standard interactions that the BMC Edu toolkit restricts me to. I was considering developing a graphic or an animation that would give it more personality, but I only have a vague idea about just what that should look like.

So, I got back an email about what extensions are in the most use by customers. Thanks to my old boss Eric for providing a quick and concise answer: