Beyond "Show, Don't Tell Me"

The Principle "Show Me, Don't Tell Me" is extraordinarily important.

But one can go even deeper, to an even more crucial principle.

That principle is ... well, let's do a case study.  The study is using unusual printer and reader devices associated with magnetic stripe cards.

Today TheHackerCIO saw a Zebra P330i Magnetic Card Printer/Encoder at work. Cards were loaded in the hopper. An attached laptop running Visual Studio was opened. Code pointing to an image, text and numbers was run. The printer whizzed a bit. Out came a card printed with the image. We then opened a 3M document reader, which can perform the OCR on a passport as well as the MSR (Magnetic Stripe Reader). We ran the newly printed card through the reader and voila! In Notepad, we saw the data wonderfully displayed.

Zebra P330i Magnetic Stripe Card Writer

Being shown a new technology is great.

It's so much better than if I had just been told how it worked. In fact, seeing it proved to me that the devices were working. Almost. To really be certain, I'd want to see another test where the data was changed and the changes reflected in the reader. And to be really thorough, before I went to production, I'd need to test that every track of the three available would properly encode data and that the text and image would print properly on the front and back of the card, as expected. But we covered this yesterday, under "Show, Don't Tell Me."

But what is really fascinating was what happened next.

TheHackerCIO didn't just remain satisfied that he had seen how to encode a mag card. He said to the demonstrator, "Let me drive." Thus, taking the Conn, I sat in the Captains Chair, seized the keyboard firmly, and began telling my demonstrator what I wanted to do.

The first thing that became apparent was that I couldn't even find Visual Studio. With a little help from said demonstrator, I found it was listed under "M," for Microsoft Visual Studio. Then, there were several versions, such as Express, 2010, 2012, etc. I had no idea which one to use!!! I discovered that the project had been built using 2010, not 2012, which was more web-oriented.

With this open, I was now able to familiarize myself with the code.

Then I realized I better load up a card. I pulled up the protector, and dropped in a card, face up. My gentle guide pointed out that there was already a card there, mentioning that the device fed from the bottom, and so I corrected my error by removing both cards, setting aside the one that had been on the bottom, and placing my new card at the newly opened bottom position of the hopper.

Returning my attention to the code, when I began to make a change, I attempted to put my name into the code as "James^Rothering." (The caret is used as a separator, I am told)  I got an error when I attempted to build it. Lower case is not permitted, as I discovered. Upon changing my name to "JAMES^ROTHERING" [the ISO 7813 standard uses the "caret" as a field separator] the code compiled and prompted me to enter various fields. I didn't know which of the many drop-down choices to select for the "Printer", but upon asking, the demo-meister told me to choose  "Zebra p330i card printer USB (copy2)". Why copy2 and not copy1 we didn't go into. I also selected "front" for print selections, and too quickly, I hit enter. I had not checked the "magnetic encoder" check-box. I knew this was an error an eyeblink after I did it and exclaimed to the demo-meister that I "messed up." He said, "Yes, I would expect that it will print the card, but not encode the changed data you typed in."

I agreed, and said that I wanted to view the card anyway, to ensure that it had failed as we expected. I then attempted to find the 3M card reader in the Start | Programs and had no luck. Demo-jockey pointed out that he simply had placed the binary in a directory under Downloads. After starting the ".exe" from that directory, I went to swipe the card, but found myself stopped. Demo-jockey said I could now minimize the panel displayed by the 3M reader program, but needed to have Notepad open, having focus at the time I swiped! So, I performed those actions and ... lo and behold. The card was erroneously encoded as it had been before I changed the data. That was expected, as you will recall.

So I went back through the steps of loading a card,  invoking a print, but this time carefully checking the box that caused it to actually encode the track. And this time .... ta da .... In Notepad I saw my beautiful name exhibited just as I had typed it in! Success at last.

The point of recounting this story is to illustrate the importance of taking the conn. Of moving rapidly beyond "Show, Don't Tell Me" onto "Walk Me Through, please!" The learning acquired by actually doing something, with a knowledgeable guide present is incalculable.

Walk Me Through, Please!!!

Walk Me through, now ...

I Remain,

TheHackerCIO

Show, Don't Tell Me (part 2)

click here for part 1

A midcourse correction is happening on this posting. It doesn't happen often. But I want to get to the point of "Show, Don't Tell Me," without waiting for the whole inductive example from the chapter of the aforementioned book.

Instead, I'm going to separate out the points from that book for a later discussion.

For now, TheHackerCIO wants to explain the awesome power of showing over telling.

There are a few indicators for seasoned technologists. If you don't back-up like a maniac, then you're still not seasoned. And,  if you believe something will work just because someone says it does, or because the manual says so, then you're still wet behind the ears. The principle that captures this is that of "Show, Don't Tell Me."

A perfect illustrative example of this arose this week.

We were working with an unfamiliar device: new to TheHackerCIO, anyway. It was a Magnetic Stripe Card Writer. You know these ubiquitous cards with a magnetic stripe down the back. They follow an ISO 7813 standard of three tracks of data. Our project involves writing on them, which is something I've not done before. It's pretty fun, actually. I printed a picture on the front of a card, and put my name and several numbers of my choosing on one last week.

But this was probably only because I had an experienced engineer helping me out!

As it turns out, the "storybook," as we call the sample program, won't work! The experienced engineer knew what to change, because he's worked on other mag writers. But it simply points out the necessity of calling for a demo.

If you haven't seen a demo from the vendor with your own two eyes, then you've all you can assume you've got is vaporware. Even if you've seen it, you still need to exercise caution about what you conclude, but at least it's a start.

That's why show, don't tell me is so crucial.

And it's also why TheHackerCIO is very dubious about claims found in books and elsewhere. Why is there so little in the way of backing demos for claims about -- well, everything! For instance, in the aforementioned book, the claim is made that:

"Relational databases could also be run as separate servers for different sets of data, effectively sharding the database. While this separates the load, all the sharding has to be controlled by the application which has to keep track of which database server to talk to for each bit of data. Also, we lose any querying, referential integrity, transactions, or consistency controls that cross shards." [reference: p. 8]

There is so much in this statement which is questionable, that I don't even know where to begin. You lose querying capabilities cross shards? In DB2 UDB, the database supports creating what are called partitioning keys. These have to be a primary key, but allow the distribution of certain key-ranges on specific backing devices (device placement), thus improving performance.  Such a tablespace is called a "partitioned tablespace." And there is no problem querying across the partitions. This is essentially the DB2 support for sharding.

In Wikipedia, sharding is defined as "a horizontal partition in a database ..." And in DB2, table partitioning is exactly that: a horizontal partition, based upon Primary key range. The RDBMS, namely DB2, explicitly supports this: there is no application involvement required! The application doesn't have to be aware of where the partitions are placed.

And, as the link above indicates, there is no problem querying across the partitions. Been there, done that. So I can't imagine what I'm missing about the storybook quote. I can't see any loss of querying, RI, transactions, or consistency controls across partitions in DB2.

Now, maybe this author is thinking about Oracle RAC, or some other DBMS. But the point is, there are other RDBMSs than Oracle or Microsoft Fecal Server! There's a whole world out there.

But I'm an open-minded technologist. Show me the problem you are talking about. Show, don't tell me!!! Put up an example of how you lose these features with your sharding, then I'll learn specifically, and precisely what you mean.

I'm going to be calling more and more for Show Don't Tell.

I Remain,

TheHackerCIO

Show, Don't Tell Me

Once again TheHackerCIO is ticked off.

Once someone asked "How do you choose what to blog about?" And I replied, "I write about whatever pisses me off the most at the time of writing." That doesn't mean that I publish it immediately. I've got one or two sitting as "drafts," because it's wisdom to let things cool down sometimes. A lot of times, actually. Just to cite an example: "Dealing with Assholes," the promised secret inside scoop, is still in the cooler. It derives from actual events, and although the names have been expunged, I think even more details will eventually be removed. The principle will remain the same, but you won't be able to get the same salacious story. Only a privileged few insiders will be privy to that.

It was the book reading that ticked me off. Yesterday, on the plane flight, I started rereading NoSql Distilled. I recommend this as an excellent introduction to the new in-consistent databases.  And the author, Martin Fowler, with his ThoughtWorks consulting group is awesome.  The book is divided into two parts:

• Understand
• Implement

I only read the Understand section, and it was before the holidays. So, rather than continue with a poor remembrance, I just started over. 

TheHackerCIO is a "Strategos." That is, a "General," as the Greek word describes. But rather than explain how this is the case, we're going to take an inductive look at the kind of thinking that strategoi perform. And we're going to do it on the first chapter of this book: Why NoSql.

But now, TheHackerCIO, busy beaver that he is, has to go onboard a new major enterprise client for his boutique, Codojo. There must be three or four separate blog posts in that sentence alone!

[lets see, ...
1. How to onboard a client,
2. the innovations in the workplace of Codojo,
3. The effect of enterprise clients in a boutique alongside of Startups,
4. ???]

Ding ding ding ....

Times up.

Stay tuned for the rest ...

click here for part 2.

I Remain,

TheHackerCIO