Some websites I’m working on….

I’ve been fairly busy with creating some websites,  so I thought I’d share:  is where I will be posting some of my CGI art work.   The rule of thumb is that if I don’t mind my mom seeing it,  I will post it here.  is where I will be posting the saga of Faith Keller.  This will be a PG to R rated website.   There’s no nudity or violence there as I write this, but that will change.  So if you’re not 18 and aren’t offended by graphic novels with graphic violence and some adult situations feel free to check it out.


I am looking for help with that project.   Unpaid help…its a hobby 🙂

Professionally I’m always looking to expand my knowledge and reach out to other programmers,  so I’m still working on content for:


“HL7”  is the messaging standard used to integrate different medical systems.   I’m pretty good with an the Mirth Integration Engine and enjoy a minor reputation for being helpful within the Mirth community.


Of course I do have a place to post the stuff I wouldn’t want my mom to see. 😉





RTOD: Sometimes you just need to not look so hard to see the problem…

No matter how much you stare at it,  glare, walk away in disgust…the following line will not alter your database

var strSQL = “Delete from SecondarySites where employee = ‘” + empID + “‘”);

without this bit: 

var result = dbConn.executeUpdate(strSQL);

this won’t work either:

var result = executeUpdate(strSQL);                   //oddly the program will want to know which database connection you’d like to send the command to


var result = dbConn.executeCachedQuery(strSQL)  //Queries pull data from the database, not the other way around

Those last two will at least throw errors.

Yeah, yeah…its been a long day 🙂

For non-programmers… The first line loads a command that tells my database to delete everything in the table SecondarySites that belongs to the employee contained inempID into the variable strSQL

That’s all it does.

The second line actually sends the command to the database.

Sort of like putting a letter in an envelope and forgetting to drop the envelope in the mail box.   It will do nothing but look pretty!

Yes, its a programming fail.

But look at it this way.   I am so freaking awesome that I can post my fails on my blog 😀

Real life is different from tv…

You see “computer experts” on television shows who can pretty much do anything by tapping their keys and blabbering out a bunch of words the writers have heard their computer geek friends say.   Then they will do things that will make computer geeks laugh, or scoff.    Like:

Non-Geek Character:  “Omg, what’s happening??!!  I can’t get into Facebook!!!!”

Geek Character:  “They’ve launched a denial of service attack on our wireless router!!!”

NGC:  “FIX IT!! FIX IT!!!  I need to post this lolcatz to my wall!!!”

GC:  “I’ll brute force their DNS server!”

5 seconds later….

GC:  “I’m in!!!!”

So yeah…tv computer geeks never make mistakes and can always fix problems in the blink of an eye.   I’m not even going to explain why the above imaginary tv conversation is wrong on so many levels.

In real life the conversation would go like this…

Non-Geek Character: “Omg, what’s happening??!!  I can’t get into Facebook!!!”

Geek Character: “We blocked it.”

Non-Geek Character: “Oh”  …goes back to work.

I usually ignore some of the technical nonsense I see on TV.  Things like Criminal Mind’s Penelope breaking pretty much every privacy law ever made   (and quite a few technical ones),   but it seems that regular non geeky IT people are influenced by the massive technical prowess displayed on television and expect the same from technical people they encounter in their daily lives.

So here is a dose of reality for you:

The cool, quirky uuber techno wizard you see on television is, in fact,  an actor who probably has difficulty programming his/her PVR in real life.

In real life, uuber techno wizards look a lot like this:

Real Life Techno Geek

Bugs, glitches and equipment failures happen.   Even if there isn’t a plot hole to fill.   Everyone makes mistakes, and programmers are no different.   You know when your favorite software gets updated?   Yeah….bug fixes!  🙂

Sometimes computers run amok.  In movies and television it will often prevent the intrepid heroes from doing something,  or the running amok computer might be causing the end of the world…it’s important to remember that every piece of equipment that requires electricity to operate can be unplugged,  or somehow disconnected from its power source without the world ending.  This will stop The Bad Thing the computer is doing in its tracks,  every time,  even if the Bad Computer has a sinister looking countdown and flashing lights.

No matter how good you look in form fitting black ninja clothes,  it usually takes more then 3 or 4 minutes to download an entire hard drive to a USB flash drive.    If you can get to the point where you can stick a flash drive into a computer,   you can just download a program that will email you everything you need.   But really, there are a million ways to get that software onto someone’s machine without the need to have a carefully coordinated plan involving 5 people sneaking into a building supported by a guy in a van using a impressive array of electronics that could be replaced with a 1st generation smart phone.

Sometimes writers put no effort at all into their technical solutions.  Its important to remember that reinstalling Windows will not help, especially if you’re using a Linux server.

When someone hacks into a system they are not presented with a fantastical land of 3D imagery where security software is represented by bad men chasing the hero.   In real life, when you hack into a system,  you are usually presented with….

The underscore  (which is an old-timey cursor)  would be flashing if that helps at all.

Sadly,  once you get to this point there is about 50/50 chance that you can find what you’re looking for by presuming that many security settings were not changed from default.

Sometimes you will see some smart young kid who dances circles around old stodgy technically inefficient,  incompetent technical experts employed by the government.   This happens in the movies and while it might happen irl on occasion in most cases no.   The people who work technical security are people like me.   We grew up with technology when there was no internet…no google.  We had to figure it out all by ourselves,  sometimes with the aid of books but most of it was trial and error.    Essentially if you haven’t had to completely rebuild a system because you wanted to try something then you couldn’t really consider yourself a hacker.

So yeah,  if you show us something new,  we’ll pick it up pretty quick….because we’ve been learning and implementing new tech stuff while your parents were still in grade school 😉

Whiteboarding can be fun!

I was tasked recently with coming up with a way to update our Omnicell User Access automatically based on the active users in our Meditech Hospital Information System.

Omnicell is an automated drug dispensing system.  Now, before you all get your hopes up and flock here with change in hand,  I’m not talking about a machine where you can insert change and it will give you recreational drugs.

It actually has a rather impressive set of safeguards to prevent that sort of thing.  But anyway…

I won’t bore you with why but the requirements make designing this system a bit complicated.   To hardcore programmers like me designing complex systems is sort of like heroin (not that I have any first hand experience).   You lose yourself in your code and the world goes away.

I had to jot down some stuff on my whiteboard because I knew I was missing something.   I got to the end of what I had in mind and I knew I was still missing something.

I realized that I was sniffing marker way too much because I wrote down the first thing that came to mind…

…yes I know I’m not following any flow charting convention…this is my version of a cocktail napkin!

Technology will always fail…eventually…

I’m a programmer.  Its what I do for a living.  My specialty is HL7 Integration using the Mirth Integration Engine.  I am a multi-lingual programmer which is a fancy way of saying that I know several programming languages (don’t worry, I won’t post my CV here).

I also play World of Warcraft.  I mention this only because the best example I can use of “User Rage” is on the WoW forums.  People rage about how they’d fire the entire development team over some stupid little bug, or something that has really nothing to do with the background code.  But sometimes they do have a point.  Something passes QC (Quality Control) that shouldn’t.

Someone asked me why it was so hard to write a program that works perfectly every time.
That’s not hard!  Its dead simple…watch…

In Javascript:                       document.write(“Hello World!”);

in .NET :                               label1.caption(“Hello World!”)

in PHP:                                 <?  print ‘Hello World!’ ?>

There…perfect code (well, maybe there’s a type, this is untested /shrug).  This is some real code.  It works.

Programmers are human and we make mistakes (as demonstrated above (did you notice?)).   Testing won’t pick them all up….I guarantee it.  While the typo might be dead simple….it can sometimes take hours to find and fix it.

When designing software we take everything we know into account.  The more complex a project, the greater the chance that something will be missed.  Some process that someone forgets to tell us about, or gives us inadequate information.

Then there are the things we do.  We’ll run into a road block and make a presumption.  We’ll add something thinking it would be nice for the users to have,  or not realizing (whether consciously or unconsciously) that we really don’t understand a requirement and coding it anyway.   We all do these things.

Diligent testing should pick up all this, but it won’t.  Some of these mistakes will make it into the Production environment.  This is why software projects have implementation phases post Go-Live where everyone (including the development team) is ready to respond to problems immediately.

Its all well and good talking about this, but lets demonstrate it.

Let’s say you’re a programmer tasked with coding a script to guide a robot driver through an intersection where it has the right of way.   You write the following code in the programming language Plain English.   This is what you write:

If  intersection is mine then keep going

You test it, it works fine and you go for coffee.  You come back and you’re asked “What about the other idiots on the road”  You go back and write

If intersection is mine AND if intersection is clear of idiots then keep going otherwise stop

You test this and realize that you haven’t told the driver when to proceed.   You go through several rounds of testing and finally come up with this…

If Intersection is mine AND
If intersection is clear of idiots AND
If number of pets or children that may dash in front of car unexpectedly < 1 AND
If number of police officers directing you to stop < 1 AND
If construction blocking traffic ahead is false AND
If gas sufficient to reach destination is true THEN
Stop Until idiots, police, children and pets = 0 Then Proceed to Destination unless insufficient fuel then proceed to nearest gas station.

So, this code eventually goes into production and your robot driver performs flawlessly until one day you find out that your robot driver slid out of control and caused an accident!
You feel horrified and sick.  You look at the logs and see something that you didn’t consider in your design, brake failure, its one in a million, but you decide to change your “stop”  to a procedure (a set of often repeated commands).   You write

Define Procedure Stop(urgency,safedirection)
if brakes fail steer to safedirection, shift to neutral  and sound horn, disengage engine when vehicle stopped.  If collision = true notify emergency services else phone home.
if urgency is immediate and anti-lock brakes = true then steer to safedirection and apply full pressure to brakes unless anti lock brakes = false then threshold brake
if urgency is immediate and safedirection = 0 then brake, horn  and pray
if urgency is fast stop then apply increasing pressure to brakes until rate of stop > distance to target
if urgency is normal then apply slow pressure sufficient to stop in time

That goes into production and things run great.  Then you run into other conditions that programmers encounter.   No notice of changing conditions.  The robot calls you and very angrily chews you out because in the past 3 days it has received 3 tickets for running a stop sign.  When you explain that you didn’t know that a stop sign was there the robot yells “Its NEW!” calls you a bunch of names and then hangs up.

No one at City Works knew you had a robot driving a car through that intersection and neglected to inform you of the change….

So, you write some code to accommodate for the new stop sign.  Feeling a bit angry about being called names, you add some code that will make the robot roll down its windows and belt out show tunes whenever the vehicle’s speed is less than 30km/hr.  Your mouse hovers over the deploy button, but you think better of it and copy and paste the show tune code into a text file in case you change your mind later.

Writing code for complex systems may sometimes sound pretty easy when the process is described, but I hope I’ve shown you that it isn’t.

Oh yeah….in a nod to Isaac Asimov you add a line of code to your robot’s programming:

if danger to humans is true then self destruct

You decide that its better to not tell the robot….because, well, he called you names…