Load-bearing paint (alt: structural paint) is a term that I've heard in relation to house remodeling where the existing structure is, shall we say, questionable. Things are so poorly constructed, or more often, modified (shoddy repairs on top of shoddy remodeling on top of more shoddy remodeling) that what seems to be purely cosmetic is in fact an integral part of what is holding things together. It works - for now, just barely, as long as you don't stress it too hard - but to do anything reasonably with it you need to tear the whole thing out and start fresh. And that takes time and money... so why not just add a new coat of paint, to strengthen it up a little?
Now imagine this as a piece of software.
Nov 24, 2014
Jul 24, 2011
Help, my CEO is a better programmer than me!
Ha ha, no, he just read "Learn Visual Basic in 21 Days" (well, he skimmed the first few chapters) and he thinks he can program. And he's a "hands-on" type, and feels that if he's not mucking around in everything, he's not doing his job. (Mind you, he actually *is* good at his real job - executiving and shit - he's just not a programmer)
For dealing with such people, have you ever thought about leaving in some really obvious awful stuff that they can point at and say "Hey! Fix that!" and they can go away feeling useful and you can save the buffer that already had that change made and get on with work? Or does that nagging doubt that maybe he *won't* see it - or worse, will like it - prevent you from taking such action?
For dealing with such people, have you ever thought about leaving in some really obvious awful stuff that they can point at and say "Hey! Fix that!" and they can go away feeling useful and you can save the buffer that already had that change made and get on with work? Or does that nagging doubt that maybe he *won't* see it - or worse, will like it - prevent you from taking such action?
May 31, 2011
Yahoo Mail - what happened to GBS?
Yahoo's YUI has a great idea called "Graded Browser Support". Read about it at http://developer.yahoo.com/yui/articles/gbs/
In short, it says "we know specifically what browsers suck, and specifically what browsers don't suck, and if we don't know about it, we assume you're a geek and your browser doesn't suck." Or in their terms, C-Grade, A-Grade, and X-Grade.
The problem is that Yahoo Mail - generally a great product - isn't on board. They're about to release their "All-New" new mail ui. And they've sent out lots of messages about it, to avoid surprising users. Yet their browser detection fails to figure out that Seamonkey - a Gecko-based browser, pretty much the same as Firefox internally - should get the fancy stuff. By my reading of GBS, Seamonkey should be X-Grade, which gets all js and css. But instead they give me "Upgrade to a supported browser!"
I understand that they don't want to answer tons of support crap about "it doesn't work with IE6!!". That's the whole point of GBS. I know the risks. The current "all-new" yahoo mail also doesn't recognize seamonkey, but it at least gives a "go ahead anyway" option. Now could they just do the same and let me at least try it with my almost-Firefox browser?
In short, it says "we know specifically what browsers suck, and specifically what browsers don't suck, and if we don't know about it, we assume you're a geek and your browser doesn't suck." Or in their terms, C-Grade, A-Grade, and X-Grade.
The problem is that Yahoo Mail - generally a great product - isn't on board. They're about to release their "All-New" new mail ui. And they've sent out lots of messages about it, to avoid surprising users. Yet their browser detection fails to figure out that Seamonkey - a Gecko-based browser, pretty much the same as Firefox internally - should get the fancy stuff. By my reading of GBS, Seamonkey should be X-Grade, which gets all js and css. But instead they give me "Upgrade to a supported browser!"
I understand that they don't want to answer tons of support crap about "it doesn't work with IE6!!". That's the whole point of GBS. I know the risks. The current "all-new" yahoo mail also doesn't recognize seamonkey, but it at least gives a "go ahead anyway" option. Now could they just do the same and let me at least try it with my almost-Firefox browser?
May 30, 2011
The difference
The difference between perl programmers and java programmers, presented with the same problem:
The perl programmer thinks, "I can solve that in one line with regexp".
The java programmer thinks, "I can solve that by adding in a new framework."
The perl programmer thinks, "I can solve that in one line with regexp".
The java programmer thinks, "I can solve that by adding in a new framework."
Oct 7, 2010
Online Poker
I've been thinking about a scheme for online poker where cheating is impossible.
By cheating, I mean strictly two things:
- no proper subset of the players can control the cards dealt
- no proper subset of the players can know any cards dealt to any players outside of the subset
In other words, the dealer can't stack the deck, even with help; and you can't peek at other players' cards, even if you control the server. An immediate consequence of this is that there is no single trusted entity, house or otherwise.
Here is the basic scheme I propose:
Each player generates a secret encryption key (K).
The dealer shuffles the deck and encrypts each card with his key.
[the dealer now has complete knowledge of the deck, but no one else does]
Each player in turn repeats this process (shuffle, encrypt).
[now no player can tell what any card is by looking at it, and the order has been randomized so it is different from the dealer's original shuffle]
The encrypted deck is visible to all.
To deal a card, the card is given to each player, who partially decrypts that card with their own key and passes it to the next player who does likewise, ending up with the recipient of the card who decrypts it ending up with the real card. In this way, each player other than the recipient sees only a card that has been encrypted by one or more keys.
When the hand is over, all players can reveal their secret encryption keys so the encryption steps can all be verified.
This scheme requires an encryption method that can be applied multiple times with different keys, and that can be decrypted with those same keys in any order, such that decrypting with fewer than all the keys provides no information about the fully decrypted message.
The simplest example of such an encryption method I can think of is a caesar cipher. Each player picks a number between 1 and 52, and rotates each card by that amount. To decrypt, they each rotate it backward. But this has a few flaws. The relative positions of the cards stay the same (a king is always one more than a queen, etc.) And revealing any single card reveals all cards belonging to that player. So something stronger is needed.
Clearly, each card must be encrypted by itself. A caesar cipher plus a keyword (a Vigenere cipher) won't work, since it is position sensitive, and the cards get reordered.
A simple one-time pad approach should work, where the pad is a permutation of the numbers from 1-52, and each number is replaced with the number in that order. The pad is completely private, so there is no problem with exchanging them. Implementation would be straightforward.
The devil with encryption is that there are potentially so many non-obvious flaws. Are there any places where my proposed scheme fails?
An abstract example:
There are 3 players, A, B, and C. A is the dealer. He shuffles the deck, encrypts each card with A, passes it to B. B shuffles the deck, encrypts each card with C. C shuffles and encrypts and returns the deck to the dealer. Now the deck is in a random order, and each card is encrypted with ABC(c).
A deals a card to B: he first decrypts the card with his own key, leaving BC(c). He gives the card to C, who decrypts it with C leaving B(c). The card is then passed to B who can decrypt it leaving plain c.
A deals a card to C: he decrypts it with A, leaving BC(c). He gives it to B who decrypts it leaving C(c). The card is passed to C who can decrypt it to plain c.
A deals a card to himself: he passes the card ABC(c) to B, who decrypts it leaving AC(c). It is passed to C which decrypts it leaving A(c). It is returned to A, who can decrypt it to plain c.
By cheating, I mean strictly two things:
- no proper subset of the players can control the cards dealt
- no proper subset of the players can know any cards dealt to any players outside of the subset
In other words, the dealer can't stack the deck, even with help; and you can't peek at other players' cards, even if you control the server. An immediate consequence of this is that there is no single trusted entity, house or otherwise.
Here is the basic scheme I propose:
Each player generates a secret encryption key (K).
The dealer shuffles the deck and encrypts each card with his key.
[the dealer now has complete knowledge of the deck, but no one else does]
Each player in turn repeats this process (shuffle, encrypt).
[now no player can tell what any card is by looking at it, and the order has been randomized so it is different from the dealer's original shuffle]
The encrypted deck is visible to all.
To deal a card, the card is given to each player, who partially decrypts that card with their own key and passes it to the next player who does likewise, ending up with the recipient of the card who decrypts it ending up with the real card. In this way, each player other than the recipient sees only a card that has been encrypted by one or more keys.
When the hand is over, all players can reveal their secret encryption keys so the encryption steps can all be verified.
This scheme requires an encryption method that can be applied multiple times with different keys, and that can be decrypted with those same keys in any order, such that decrypting with fewer than all the keys provides no information about the fully decrypted message.
The simplest example of such an encryption method I can think of is a caesar cipher. Each player picks a number between 1 and 52, and rotates each card by that amount. To decrypt, they each rotate it backward. But this has a few flaws. The relative positions of the cards stay the same (a king is always one more than a queen, etc.) And revealing any single card reveals all cards belonging to that player. So something stronger is needed.
Clearly, each card must be encrypted by itself. A caesar cipher plus a keyword (a Vigenere cipher) won't work, since it is position sensitive, and the cards get reordered.
A simple one-time pad approach should work, where the pad is a permutation of the numbers from 1-52, and each number is replaced with the number in that order. The pad is completely private, so there is no problem with exchanging them. Implementation would be straightforward.
The devil with encryption is that there are potentially so many non-obvious flaws. Are there any places where my proposed scheme fails?
An abstract example:
There are 3 players, A, B, and C. A is the dealer. He shuffles the deck, encrypts each card with A, passes it to B. B shuffles the deck, encrypts each card with C. C shuffles and encrypts and returns the deck to the dealer. Now the deck is in a random order, and each card is encrypted with ABC(c).
A deals a card to B: he first decrypts the card with his own key, leaving BC(c). He gives the card to C, who decrypts it with C leaving B(c). The card is then passed to B who can decrypt it leaving plain c.
A deals a card to C: he decrypts it with A, leaving BC(c). He gives it to B who decrypts it leaving C(c). The card is passed to C who can decrypt it to plain c.
A deals a card to himself: he passes the card ABC(c) to B, who decrypts it leaving AC(c). It is passed to C which decrypts it leaving A(c). It is returned to A, who can decrypt it to plain c.
Subscribe to:
Posts (Atom)