Hackable Knowledge

I read an interesting article and wanted to basically use this article as a spring board for this blog's post idea.

Throughout school the main focus was always tests. Quizzes would evolve to tests and tests would evolve to exams. These things would make or break your grade as you got older. Some classes would have exams worth 90% of the class, with the often homework barely worth anything.

Now what if I told you that these exams were hackable? I'm not talking about stealing answer keys or anything, but the tried and true method that the A+ students mastered.

Lets take a look at a snippet from my networking book.

So what we see here is three items describing what a local-area network is. This is a perfect list to add a fake 4th answer and design a question like "Select the item that does NOT describe a local-area network."

Additionally, take a look at the bold section which helps explain that LAN stands for Local-area network. This is another perfect example of an easy multiple choice question about finding the correct acronym.

You can continue to read the next paragraph and maybe you'll find something of interest, but a sure fire way to exceed at tests is find testable material. Those students that always exceeded did just that.

Lets take a step back now and examine those two questions we made up. In real life, who really cares what the book definition of a LAN is? I can assure you probably nobody, because that knowledge is pretty useless. When you are describing a LAN - you are simply describing a local network. Your home network is a LAN and that's why LAN parties can exist, because you bring multiple network devices together to communicate.

So with some clever reading skills and ability to pull apart the testable knowledge and memorize it, you are set. Just regurgitate this information for a brief test and let it fade away in your memory. You can hack tests, but will that pan out in the real world?

Lets pivot again.

I took a great deal of computer classes in school and one thing about them that bothered me is how we learned syntax. Something as simple as a loop was taught with a sample program adding 1,2,3...100 to a variable. It was a simple way to help teach the concept that if you needed to iterate - use a loop.

However, when you teach things with situations that probably won't ever happen the correlation may be lost on some. So I looked back at some code I wrote 10 years ago before any programming class. I learned from discovery WHY I needed a loop.

private void unselectAll() {
    $this.layer_1.setText("");
    $this.layer_2.setText("");
    $this.layer_3.setText("");
    $this.layer_4.setText("");
    $this.layer_5.setText("");
}

Instead of writing the same line 5 times to clear all the values in my form. I could put all the items in an array (another concept) and use that array in a loop to clear the field name. Now instead of the same line 5 times with one change, I have a loop.

private void unselectAll() {
    $fields = array('layer_1', 'layer_2', 'layer_3', 'layer_4', 'layer_5');
    
    foreach ($fields as $field) {
        $this.$field.setText("");
    }
}

I've now written a loop and the reason was driven from discovered knowledge instead of instructed knowledge.

This code has so many errors though, it almost hurts to leave it as is. I should fix the method name, return type and fix the horrific naming. Though, it served its purpose for this demonstration.

So if I was trying to teach a loop to students. I would present code that had obvious replicating lines that could be optimized via a loop. I would ask the students to add another iteration for "x" and see how they did it. I would then ask for them to add 10 more. As the number increases, it would drive home the point of leveraging loops.

Of course its easy to just rant without any formal proof of this theory of thinking, but the reason is simple. I think learning via experience and WHY trumps anything else.

Our last point is taking that train of thought to test.

In my early development years, the idea of "NoSQL" databases was blowing up. You basically weren't cool in the development space if you weren't using a NoSQL database. This is of course exaggerated, but this led me to being convinced to use MongoDB to solve some issues I had with logging Halo stats.

I rewrote my project badly to leverage MongoDB and began dumping Halo analytics into it. It was working, but something wasn't right. My database was growing way quicker than it should and disk space in early 2013 for cheap wasn't easy.

I began doing research and realized that since MongoDB wasn't relational with a strict schema format meant it required storing the keys as well as the data together.

So I had a data key for every single player called "BestGameAssassinationTotalGameId".

So this meant in my old database storage, this key was actually stored inside the database as some integer. The technical term for this is "tokenization" and basically means why store the same string over and over again? Give that key a token, which is much smaller and store it in correlation to that.

That was a benefit I didn't realize I had with MySQL, but only learned how much it hurt me with MongoDB at the time.

So my database was growing too large due to each entry taking extra space from the addition of the key for each field leading to frequent downtime. So I decided to figure out why MongoDB wouldn't tokenize. This led to a bug report which led me to the discovery of handling tokenization in my own application.

I built support in for it, but then my database at an analysis level became unreadable because instead of reading human readable strings I was stuck with like "0x22" and "0x2d" which turned administration into a challenge. Not to mention I had old data and new data, so basically meant writing a script to convert data or lose old data.

After switching databases and breaking things so many times. I lost all my visitors and the site basically died. It was not worth my time, so I shut it down. However, the amount of knowledge I learned from relational and object databases was huge. This was first hand knowledge I picked up.

So the next time someone wanted to convince me to use MongoDB, I was armed with real world knowledge of pros and cons. Which I'll say again, I believe real world knowledge is better than anything you read.

This post got a bit too large, so I'll cut it off here. I think I basically described what a trade school is, so maybe this is all moot.