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.
> 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]
One thing to consider is that the creators might very well believe it works themselves.
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.
If you question it, you might find a way that works better. Then you have to redo all of it, and that's more work, so just keep plugging away, blissfully ignorant!
It's an example of a time when I'm fooling myself into believing that some stupid little thing has an effect on my code. It probably won't break if I remove it, but this is how those situations go down:
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
That's perfect! I program by coincidence all the time. The very definition of a hacker... "it works, I must have done it right". And if it doesn't work, keep adding more console.println statements until you find something unexpected, then add a "x = x" to fix it and BOOM I just wrote Snapchat give me lots of money.
I'm joking, but it hits a little close to home because all of us have done that before. You're at the end of your rope and just need this thing to fucking work and you'll deal with the "why" later. For now, x = x works dammit, and it doesn't matter why. Meanwhile the console is filling up with all of your variables being printed out because you couldn't figure out where the value of x was being corrupted.
The next morning you switch to functional programming and forget that day ever existed.
To be fair, as science becomes a parody of itself in the general populace, informal poorly structured tests are becoming the norm. E.g., that's what all of mythbusters is.
According to Amazon this product's dimensions are 1.1x2.1 in. ISO/IEC 7810 cards (your average card with a magnetic stripe) is 3.370 × 2.125 in. I would bet that they get thrown out/ defect cards (probably not bank cards), clean and reprint the surface and cut them into three pieces.
Probably for inventory control so they don't send something out for Fleas when a customer purchased one for Ticks.
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.
It's definitely re-encoded. There are words "FLEA" and "TICK" encoded on the cards for respective insects. My bet is on recycling mag cards by cleaning them up, cutting in three and reencoding.
