Sep. 5th, 2008
Cindy McCain, Aristocrat
Sep. 5th, 2008 10:19 amIn a recent flurry of conversation, the question of whether or not Cindy McCain's calling Obama "elitist" was inappropriate while she wore $280,000 earrings and someone, during the conversation, said that there's a difference between "wealthy" and "elitist."
There certainly is. But in America, there's also a difference in the way wealth is perceived. As John McCain put it, echoing a Jonah Goldberg talking point, "Americans don't hate the rich. They want to be like them."
I think that statement is mostly true. Americans don't hate Warren Buffet or Bill Gates for their wealth. We may not love their products (in Buffet's case we may not even understand it), but we understand that these men have, more or less, earned their wealth. They've done something, they've run something to make themselves so wealthy. They have created wealth for others in their wake.
We can't say that about Cindy McCain. She's a trust fund recipient and an "absentee owner" of her own company. She's bankrolled her husband's campaigns and stood beside him, but we don't see her leaving a wake of prosperity. She is quintessentially the kind of rich person that Americans instinctively dislike: rich by inheritance, maintained by a parasitic infrastructure that moves money around, feeding off attention and acclamation for which she is completely without merit. Unlike Buffet or Gates, if she's not elitist she is aristocratic.
Putting her up in front of the Republican National Convention was a mistake. She belongs to Bush's people: "the haves and the have mores." With no demonstrable meritocratic story to advance, she only helps to turn the middle class against her husband.
There certainly is. But in America, there's also a difference in the way wealth is perceived. As John McCain put it, echoing a Jonah Goldberg talking point, "Americans don't hate the rich. They want to be like them."
I think that statement is mostly true. Americans don't hate Warren Buffet or Bill Gates for their wealth. We may not love their products (in Buffet's case we may not even understand it), but we understand that these men have, more or less, earned their wealth. They've done something, they've run something to make themselves so wealthy. They have created wealth for others in their wake.
We can't say that about Cindy McCain. She's a trust fund recipient and an "absentee owner" of her own company. She's bankrolled her husband's campaigns and stood beside him, but we don't see her leaving a wake of prosperity. She is quintessentially the kind of rich person that Americans instinctively dislike: rich by inheritance, maintained by a parasitic infrastructure that moves money around, feeding off attention and acclamation for which she is completely without merit. Unlike Buffet or Gates, if she's not elitist she is aristocratic.
Putting her up in front of the Republican National Convention was a mistake. She belongs to Bush's people: "the haves and the have mores." With no demonstrable meritocratic story to advance, she only helps to turn the middle class against her husband.
I once characterized my writing style as a form of mining: I generate a ton of ore, and eventually sift through it all looking for the stories. It's harder to do that nowadays, what with a full-time job and two kids and a real social life, than it was a decade ago. It's harder for other reasons, but that's fodder for another post. (Good bloggers always keep something in reserve.)
For the past eight days or so, I've been having the absolute pleasure of working on a pure research project, re-implementing FireWatir in Python. The project is known internally as "Whiskey," (FireWatir without the R) and at some 1805 lines is faster and more concise than firewatir's 6522 lines.
The real trick was to stop sending huge masses of javascript back and forth with every operation, but instead to encapsulate all of the javascript FireWatir generates and transmits per transaction into a javascript library, upload that once, and then just issue one-line calls to the JSVM through the library. This skips a very expensive interpretation step and allows context identity to be maintained more explicitly.
Also, on the client (python) side, finding objects became a matter of doing things like:
Oh, a fun inner implementation issue: doc.input(name="username").style.background.set("#ffffff"). Here, "Style" has to dereference not to a function, but to value that's not scalable-- it's a reference to a DOM Style object, so I needed an inner class to be instantiated, that knew what object was being manipulated, in order to manipulate it.
And finally, there are alternatives: doc['input[name=username]'].set("user") will do the same as the first line of the first example. And doc[4] will return a handle to the fourth child element (not node!) of the root document object. This can be really useful when doing things like: doc.table("#accounting")[4][4], although to be honest that has a special case handler to skip table headers and go straight for the body.
But what I learned while writing this is that I really do code very much like I write. I wrote a ton of crap, and then when I started to get serious about what I was trying to accomplish, when I started documenting my code, huge amounts of code simply got thrown away. The most common through was "I never did need that." "I never used that." "I haven't implemented that well, let's take it out and see if we need it later."
I also seem to thrive in an Extreme Programming environment. I've known for a long time that I do that well, and this was no exception; the best development periods were when I had my UI partner looking over my shoulder and the two of us leapfrogged each other's thinking patterns to home in on exactly what was needed.
For example, the doc[4] started life as a specialized override of __getitem__(), with just a numeric handler for Table and TR objects. He suggseted I push it up into the base Element handler and use it everywhere, and make the Table handler a special case if the Table had a Tbody (oh, and push that logic into the Javascript library to avoid round-tripping the conditional), and I immediately saw the utility of putting a type conditional in __getitem__ so that if you passed it a string you could treat it like a CSS selector.
Anyway, I've been having more fun that a programmer should be allowed to have this past week.
For the past eight days or so, I've been having the absolute pleasure of working on a pure research project, re-implementing FireWatir in Python. The project is known internally as "Whiskey," (FireWatir without the R) and at some 1805 lines is faster and more concise than firewatir's 6522 lines.
The real trick was to stop sending huge masses of javascript back and forth with every operation, but instead to encapsulate all of the javascript FireWatir generates and transmits per transaction into a javascript library, upload that once, and then just issue one-line calls to the JSVM through the library. This skips a very expensive interpretation step and allows context identity to be maintained more explicitly.
Also, on the client (python) side, finding objects became a matter of doing things like:
doc.input(name="username").set("user")
doc.input(name="password").set("mypassword")
doc.input(typ="submit",value="Submit").click() You'll note that I've seriously overloaded the dot operator (.); in some contexts, it means "get child object of", and in other it means "get attribute of", and in yet a third it means "dereference function attribute of and call function." Yet as you can see from the example, that's not tragically confusing. (And yes, "type" is misspelled "typ", to avoid conflicting with the python keyword type.)Oh, a fun inner implementation issue: doc.input(name="username").style.background.set("#ffffff"). Here, "Style" has to dereference not to a function, but to value that's not scalable-- it's a reference to a DOM Style object, so I needed an inner class to be instantiated, that knew what object was being manipulated, in order to manipulate it.
And finally, there are alternatives: doc['input[name=username]'].set("user") will do the same as the first line of the first example. And doc[4] will return a handle to the fourth child element (not node!) of the root document object. This can be really useful when doing things like: doc.table("#accounting")[4][4], although to be honest that has a special case handler to skip table headers and go straight for the body.
But what I learned while writing this is that I really do code very much like I write. I wrote a ton of crap, and then when I started to get serious about what I was trying to accomplish, when I started documenting my code, huge amounts of code simply got thrown away. The most common through was "I never did need that." "I never used that." "I haven't implemented that well, let's take it out and see if we need it later."
I also seem to thrive in an Extreme Programming environment. I've known for a long time that I do that well, and this was no exception; the best development periods were when I had my UI partner looking over my shoulder and the two of us leapfrogged each other's thinking patterns to home in on exactly what was needed.
For example, the doc[4] started life as a specialized override of __getitem__(), with just a numeric handler for Table and TR objects. He suggseted I push it up into the base Element handler and use it everywhere, and make the Table handler a special case if the Table had a Tbody (oh, and push that logic into the Javascript library to avoid round-tripping the conditional), and I immediately saw the utility of putting a type conditional in __getitem__ so that if you passed it a string you could treat it like a CSS selector.
Anyway, I've been having more fun that a programmer should be allowed to have this past week.
Fun with programming...
Sep. 5th, 2008 12:52 pmOkay, you have to be a heavy-duty Babylon 5 fan to understand the amusement value, but I realized the other day that my pet program Thinksaber was the perfect set-up for another silly toy. It'll be a few days yet, but I now have the basic framework for Sounds From The Spoofarm.
Right now all it does is simulate a spoofarm during breeding season, and not terribly well (it sounds too busy to be a spoofarm; c'mon, I wrote it over a lunchbreak). I'll need to work more on the timing, get more spoo into the mix, and find the sound of a machete hitting meat, along with some better volume control, to simulate harvest time.
Right now all it does is simulate a spoofarm during breeding season, and not terribly well (it sounds too busy to be a spoofarm; c'mon, I wrote it over a lunchbreak). I'll need to work more on the timing, get more spoo into the mix, and find the sound of a machete hitting meat, along with some better volume control, to simulate harvest time.
Kouryou-chan's school meet and greet
Sep. 5th, 2008 10:05 pmOmaha and I went to the park where Kouryou-chan's school has their annual "let's meet everybody" potluck picnic. The potluck was fortunately not too Seattle, people brought chicken and pizza, so I wasn't starving to death. I met Kouryou-chan's teachers for this year, more or less the same folks as last year, and got to observe upclose the faultlines in Kouryou-chan's social circle, which seems to be falling out between those who love to go outside and kick the ball around (Kouryou-chan), and those who want to stay inside and practice more girly pursuits-- the latter of which includes her best friend. Still, she seems to get along with an awful lot of kids there, which I count as a good thing. Even her teacher wants to know what happened to her over the summer, as "her poise and restraint are remarkable."
Unfortunately, as we were planing to leave, I snabbled a brownie off the table. I say "unfortunately" because the brownie turned out to be little more than a hunk of butter softened and blended with sugar and cocoa. I've been nauseous since we left.
Unfortunately, as we were planing to leave, I snabbled a brownie off the table. I say "unfortunately" because the brownie turned out to be little more than a hunk of butter softened and blended with sugar and cocoa. I've been nauseous since we left.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}