Who to vote for in 2008

I’ve come up with an easy way to decide whether or not to vote for an incumbent in any congressional election this cycle.

Here are a pair of links:
House Roll Call Vote on “Emergency Economic Stabilization Act of 2008”
Senate Roll Call Vote on “A bill to provide authority for the Federal Government to purchase and insure certain types of troubled assets for the purposes of providing stability to and preventing disruption in the economy and financial system and protecting taxpayers, to amend the Internal Revenue Code of 1986 to provide incentives for energy production and conservation, to extend certain expiring provisions, to provide individual income tax relief, and for other purposes.”

Here’s how to vote: lookup the incumbent candidate in your area. If they voted NO (or Nay) on the appropriate piece of legislation, vote FOR them. If they voted Yes (or Yay, or I’m an idiot and will listen to political panic rather than economists), vote AGAINST them.

See? Isn’t that easy?

NANO 2008

There’s likely going to be a bit of random noise this year on my blog with regards to National Novel Writing Month. In previous years, I’ve had a plugin setup in advance to filter NANO-related posts from my standard RSS feed. This year, well, I haven’t had enough time to set one up, but the forums are so lagged I’m about to start posting here in lieu of waiting for the Nano forums to start working. Apparently, they didn’t anticipate quite the amount of usage the servers receive at this time of year… just like they didn’t last year.

I did it wrong!

“To help struggling homeowners, the plan requires the government to try renegotiating the bad mortgages it acquires with the aim of lowering borrowers’ monthly payments so they can keep their homes.”
Deal reached on financial markets bailout

Obviously, I should have gotten a highly suspect mortgage two years ago, rather than actually reading the fine print and deciding NOT to gamble with my financial future. Had I done that, Super Government would save me, too!

EDIT: Proposed legislation. Reading it now.

Consistency is key

On top of the aforementioned SERVER ERROR 500 issue occuring because I didn’t specify a USER_AGENT that matched the white list, I’ve been spending the last week trying to track down exactly why I couldn’t upload a file. I used the stock GalleryRemote program (isn’t sufficient for automation purposes) to test my server, and it all worked fine.

Well, after over a week (admittedly, I’m only poking it on the bus every few days, and only while driving into work), I managed to puzzle out enough from the source code of the Gallery Remote to figure out why my code wasn’t working.

If you’re executing a command, your message must be:
application/x-www-form-urlencoded

However, if you’re trying to upload data, your form must be:
multipart/form-data

Apparently, the system DIES if you try to consistently use one or the other. The former is simpler; the latter provides better performance for binary uploads. Mind you, this isn’t commented ANYWHERE.

I can understand the usage of the former when possible, and the latter when necessary. I can almost understand why no one bothered to mention it (After all, the W3 recommendation for form submission clearly indicates to use both as necessary). However, what I can’t understand is WHY my usage of the latter in all cases isn’t mapped the same way within PHP.

I mean, come on! Regardless of the way the data is submitted, the application platform should, for purposes of the dictionary-based lookup that PHP provides via the $form variable (I think that’s right, I don’t speak PHP), shouldn’t both submission mechanisms be abstracted away unless you want the added complexity?

I’m tired and have a cold, otherwise I would extend this rant into the direction of work. However, you may all count yourselves lucky. For I am going to sacrifice a kitten to my desire to snuggle something cuddly when I don’t feel well, and then I am going to bed. Nice deal, eh?

EDIT (16 Sept 08): Err. Maybe my bad. Turns out that while, by convention, a multipart/form boundary is specified as “———-” + RandomData, the actual usage as a boundary requires it to be prefixed with an additional two dashes. In other words, the actual, in use, boundary should be “————” + RandomData. Which, if you try to just look by eye, is far from visible. Unfortunately, if I had paid more attention to the documentation, the example they give isn’t prefixed by a series of dashes, and it’s far, far clearer. Still could have been explicitly documented (ABNF, anyone?). However, I’m not going to lambast the PHP team; they could have been working just fine all along.

All that you can’t leave behind

I’ve recently (finally) burned the majority of my pictures to backup DVDs. I kept the ones that were halfway decent or better, but I have some that are utterly unnecessary to keep.

Unfortunately, that meant I needed someplace to put twenty archive DVDs. I don’t have cases handy (working on it, believe me), but in the meantime, I have a half-dozen CD binders from my college years that I figured I could misappropriate. So I tracked down a couple of them (a guy couple — three (I had this argument with a female friend in college; I asserted that “couple” meant “2 or 3”, she took the monogamous definition. Oxford English Dictionary agreed with me… just sayin’)), and began consolidating. WOW I have random stuff kept.
Read more