What I'm confused about here is why the ShooTag actually has any data on it at all. Surely it would be cheaper to just make part of the plastic card black, instead of actually going to the trouble of encoding something on it.
http://rationalwiki.org/wiki/Shoo!Tag
> In an apparent effort to deflect criticism of the above investigations, as of April 2011 the ShooTag FAQ has carried a claim that "Customers can take their shoo!TAG® to any retailer that carries a magstripe (credit card) reader and swipe it through. The type of tag (i.e. fly, mosquito, tick) will show up when scanned." This is demonstrably a blatant lie. The card, when swiped, will, on standard credit card readers, throw a card read error. The FAQ continues: "If there is no name, then the shoo!TAG® tag has lost its efficacy." What this means in effect, is that anyone who doesn't know better will swipe the card and assume their card has expired. It seems self-evident that the manufacturers of ShooTag would not find such a test desirable, in any case. As most people know, credit cards will last for a lot longer than 4 months, the stated maximum period of effectiveness of the ShooTag. In addition to this, the ShooTag patent application explicitly says that "…the trivector data stored on the three tracks (of the tag's magnetic strip) is not readable by a conventional credit card reader."[8][28]
It's easy to fool yourself into believing something you want to believe. They might even have done some informal, poorly structured tests and gotten the results they were expecting for other reasons, reinforcing their beliefs. Hell, I've done this to myself (ie when debugging) so I can totally empathize.
I was actually reminded of "Hidden Messages in Water" - https://duckduckgo.com/?q=%22hidden+messages+in+water%22
x = x //this doesn't need to be here but it breaks if you remove it
1. Something is broken
2. Try to fix it. Still broken.
3. Try to fix it. Still broken.
4. Sleep on it. Try to fix it in the morning. Still broken.
5. Refactor. Still broken.
6. Make a whole bunch of changes, including adding x = x.
7. It works! x=x must have fixed it! Stupid programming language.
8. Add x=x to all future code because it works because Python sucks and is stupid.
9. (optional) Go on Stack Exchange and HN and tell everyone that you need to say x=1.5 and follow it with x=x because Python is stupid and I am so smart to have figured this out.
Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn’t ever seem to work right.
Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place. It seemed to work, given the limited “testing” that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion. Now, most intelligent people may know someone like Fred, but we know better. We don’t rely on coincidences—do we?
Sometimes we might. Sometimes it can be pretty easy to confuse a happy coincidence with a purposeful plan
If not then maybe, just maybe, I'm actually spending way too much time thinking about what I write, and maybe should stop and just write more code.
The next morning you switch to functional programming and forget that day ever existed.
If you figure out some amazing workaround, ask yourself why it works. If you don't know, don't trust the workaround.
Anyone interested in slightly used magnetic bracelets? I don't think my dog will ever forgive me for having him wear them. LOL! ...... ok, just kidding.