Work Journal for Monday, June 21st 2013

Work is being annoying and difficult today again. 

Yesterday I got so stuck on the diagram I was working on that I had to tear myself away from it, and work one something completely different in order to feel like I did anything productive today. Now, I'm on the verge of getting stuck there as well. The problem is that much of class I've written is based on the old instructor-led class. The problem is that that class is so throughly wedded to the labs, that it's hard to simply replace that with Captivate demos and call it good. The product is really, really repetative. That's fine in a lab, but in a demo, it's just mind numbing. I can trim some of that out, but it doesn't really solve the problem. 

Until this point in the class, we've been working with really simple models. There's been no need to build larger ones, as doing so would have been too much detail too quickly. Now, however, it seems unavoidable. Building smaller models to demonstrate each individual concept would too be counterproductive. 

What might help is to change my focus a bit. 

At present, I have a separate model for the XML formatted message, and one that seemingly combines everything. What I could do, is discard my earlier Captivate file and focus on building just one model for the entire module. The only reason I had two models before is that I covered message formats in two units previously, not one. Building two models made sense in that case. Now, however, it makes more sense to stick to one and build it as completely, and carefully as possible. That way, students can see how the model is supposed to work end-to-end, rather than bits and pieces and a gallon of supposition and inference. The only problem is that we'd have to build the model backwards.

Broken down that way, the first demo would be about building the last three nodes of the model. This would show how to use the XML format, as well as how the you can still get a functional model when mixing activity extensions and instrumented applications. I could copy the very last node as well, making things quite a bit faster in the demo. The next demo would be about building the first two nodes. They're basically copies of each other as well. For some reason, I had thought one of them was a channel process. Hm.

It wouldn't be impossible to change the model to make it a channel process. It would just be a little...strange. We wouldn't be tracking the transport time between queue managers in that case. Granted, that could also be a good point too. Networks are generally considered fast today. The time betwen the Generator's put and the channel receiver's put would basically be transport time. It would include the transmit queue as well as the network transport time. We skip the translator get because the application is instrumented with two points. The point were the applicaiton initially gets the message, and the time it puts the output to outbound queues. This reduces the BS in the model, but also cleverly folds in channel transport while making a point about what to cover and what not to cover in a model. Not to mention, I can use this for SLAs later!

What would be required to make this work is create a remote queue on the USA queue manager called BATCHTOXML.RQ. I don't know if that's good MQ practice or not, but I no longer care. The point is to make it as clear as possible for the student. This remote queue would point to BATCHTOXML.IN on the CANADA queue manager. The model would only need to be modified for the first two nodes. All the rest can remain the same.

Okay. Much happier. I decided to actually make three demos with reguard to building the model, rather than two. I realized after I started putting the model together than creating a demo solely for the one BTM API node actually allows me to demonstrate a lot of core payload concepts without overloading the student. This just leaves adding the two ending activityies -- HIGH and LOW -- and the front two activities. It's tempting to just plow through these until I have all the screenshots, but then I wouldn't have anything to do when I'm braindead Monday morning. 

Besides, I have that stupid performance objectives email to write.

And I put in an extra hour today already.