5 Jun 4705 - Probability Spike

This will be partly for me to organize my thoughts, and partly to actually express what is going on and why it is unreasonable for me to do it. First, some lattice work.

Because of an aspect that I am still forbidden from bringing up, I have taken on a project at my workplace in addition to times when I am simply there waiting for clients. While on project hours, I can tell clients to bugger off, which is nice.
My task is the simple translation of a workshop from an old system to a new one, where by system I mean the over-arching teaching method that the lab employs, with specific ramifications of which software packages we support or not. For me, I am to learn how to accomplish everything in the old workshop well enough to teach it, then update it to use the now different software and learn how to teach that, as well as produce all the relevant materials, including handouts, scrap paper, multimedia online learning modules, the works. In other words, it should be a blast and well occupy my time in the lab while I'm not helping clients.
Seriously it has all the trimmings of a kick-ass project. There is everything about it to suggest that it is worthwhile or even fun. But this is no such project.

This is the project from hell, thanks to a probability spike I found along the way.

A probability spike is where, on a probability v time (or other timelike counting equivalent, like a function value or something, sometimes called a cdf or cumulative density function or in this case pdf or probability density function) you're going along with low probability and then for some reason there's a sudden and sharp rise in the probability. For me, this time, this is prohibitive.

The problem is exactly this: the server in question was long ago set up to handle microsoft server functions, for example linking Frontpage html documents to Access databases stored remotely. The workshop was written with this in mind. So when my task is to translate the workshop from Frontpage into Dreamweaver, I'm naturally a little apprehensive but clearly not wary enough. Specifically, the part where in Frontpage you simple right click somewhere and set the form to submit to a database. Frontpage and Access shake hands like they were preordained to do, and you're essentially done. No code, no worries. That's the good part about having your server admin hassle over the nitty-gritty of keeping a microsoft server about. It will be inconsistent as hell and useless everywhere else, but for this one feature, its easy as pie.
Well Dreamweaver never met a database that it liked, and I'm thinking never actually met a database in the first place. There is no such command in Dreamweaver, in this version or any other. It is not set up to work with a microsoft server automatically, or even consider the platform at all behind the "runs on windows OS" feature that lets me talk to it in the first place. So when the project outline goes along, and I read the milestones as translated into inverse probability graph, there's a probability spike on the part where it says "link the dreamweaver form to the access database."
It may as well read "accomplish the impossible."

The workshop will survive this little hangup. I'll drop the access database as an option, and learn how to make the cgi, php, or asp script that can handle simple forms, and teach others how to as well. Ideally, we try to keep coding out of our workshops because its not popular with the crowd we teach. This is clearly an exceptional case. They only have to learn enough to make it work, and the experience will be good. Also that can be a "part 2" of the workshop, an evil twin without whom the team is nothing. Kindof a dirty trick to pull on people, I admit, but worse is to shove all this into a single seminar and likewise shove the code down their throats.

Which brings us to the next little spike, admittedly a smaller one. The standard channels for Dreamweaver knowledge are all spinning the same yarn about what you're s'posed'ta do with your form once you've made it pretty.

Make the form, then make it send an email in the action part of the code. Then give up on that because no one configures their browsers to send email ever. Then send it to a cgi or other script instead. Done.

Oh, did we not tell you the first thing about what that script should actually be like? You're on your own. Ciao. Jerks.

You'd think that a program that lets you begin your session by saying "Create New ASP VBScript" would maybe have some built-in wysiwyg features to generate code for a script that can talk to a form that it can automatically generate. I was holding out hope that there may be a teachable way, but its really going to be a lot of putting Dreamweaver down and picking up Notepad or Notepad++ and rolling up of sleeves. They'll hate this workshop to damn death, but as soon as I can actually script something that works and teach people how, they'll love the way I teach it.

Back to News