Halloween costumes I'd never let my teenage daughter1 wear #6573:
Circuit Breaker, from Transformers
1 Hypothetical -- I didn't run out and adopt one in the last couple of weeks...
Wednesday, September 20, 2006
Saturday, September 16, 2006
Friday, September 15, 2006
For those in Seattle: If you ever get a chance, I recommend seeing a performance by the Squirrel Butter duo. Yes, those percussion sounds are all generated by her feet.
Monday, September 11, 2006
I've updated my tidal calendar creator so that the UI doesn't suck as much, it outputs PNGs instead of SVGs that nobody can really read, and autoscales according to the data received (rather than hardcoding -3ft and +18ft, which is only reasonable for Puget Sound).
It's also much slower, alas... generating PNGs is not easy. Also, I threw in an expensive antialiasing call in there to make things prettier.
Oh, and because I forgot to mention it earlier: the source code is also up there for the curious. You'll also need the location database I generate for this.
It's also much slower, alas... generating PNGs is not easy. Also, I threw in an expensive antialiasing call in there to make things prettier.
Oh, and because I forgot to mention it earlier: the source code is also up there for the curious. You'll also need the location database I generate for this.
Sunday, September 10, 2006
Silly xtide tricks
Working on automagically rendering tidal calendars. It's a work in progress -- the scale is optimized for one location (Eagle Harbor, Bainbridge Island), you need an SVG enabled browser to see the results, the interface sucks, and a number of important disclaimers ("NOT FOR NAVIGATION") and credits are missing, but...
http://kanga.org/~dacut/tidecal.cgi
http://kanga.org/~dacut/tidecal.cgi
Tuesday, September 5, 2006
The pains of REST
No, I'm not talking about sleep. Rather, some ranting about REST originally sent to a work alias.
I felt the need to actually write a bit of code this weekend, but wanted a distraction from actual work. I decided to try writing a C/C++ interface into S3 (with the ultimate goal of making a filesystem driver, but that's more than a weekend). This also gave me a chance to take a good look at REST.
After hacking on this for about 10 hours, I don't get it. Why is this an appealing "protocol"? (I put protocol in quotes because REST is all about not having a protocol, piggybacking entirely on top of HTTP.)
The major disasters I encountered:
1. What would have been about 10 lines of code interfacing into the Sun RPC library exploded into a mess thousands of lines of code getting libcurl (HTTP library) talking to libxml (XML parsing library).
2. Application errors and transport errors are completely indistinguishable. HTTP error codes are used for both. I spent 2+ hours debugging my "list buckets" implementation, trying to figure out why S3 was sending a 302 code back to me ("Location moved? This isn't in their list of errors..."). Breaking out ethereal and comparing its output vs. the S3 sample client finally revealed that S3's documentation is not entirely up-to-date, and the HTTP server I was talking to wasn't the actual S3 application server.
3. HTTP has a massive forest of possible states (chunked encoding, keep alive connections, continuation responses, etc.), but only a subset of these should be applicable to a given call. With REST, you need to deal with all of these if you want a robust client.
4. There are 3,527 different ways of encoding the same data, and you have to do it properly for this day of the week. For example, all requests into AWS have to be signed with your secret key; the request to be signed includes a subset of the HTTP headers and the date. In this case, the date must be in the form, "Tue, 05 Sep 2006 10:42:33 GMT". You duplicate this in the Date: HTTP header. Unless you have an X-Amz-Date header, in which case you use that. Unless you have an expiration date, in which case you use an integer representing the number of seconds since the epoch, and you put that in the HTTP request line. When S3 returns a date to you, it's another beast entirely: "2006-09-05T10:42:33".
It seems like REST came about because people didn't like any of the existing protocols (ok), but realized that designing a protocol is hard (yes) so they just threw it out the window entirely (uh oh) and just started hacking on code without any regard for the consequences (cries).
I felt the need to actually write a bit of code this weekend, but wanted a distraction from actual work. I decided to try writing a C/C++ interface into S3 (with the ultimate goal of making a filesystem driver, but that's more than a weekend). This also gave me a chance to take a good look at REST.
After hacking on this for about 10 hours, I don't get it. Why is this an appealing "protocol"? (I put protocol in quotes because REST is all about not having a protocol, piggybacking entirely on top of HTTP.)
The major disasters I encountered:
1. What would have been about 10 lines of code interfacing into the Sun RPC library exploded into a mess thousands of lines of code getting libcurl (HTTP library) talking to libxml (XML parsing library).
2. Application errors and transport errors are completely indistinguishable. HTTP error codes are used for both. I spent 2+ hours debugging my "list buckets" implementation, trying to figure out why S3 was sending a 302 code back to me ("Location moved? This isn't in their list of errors..."). Breaking out ethereal and comparing its output vs. the S3 sample client finally revealed that S3's documentation is not entirely up-to-date, and the HTTP server I was talking to wasn't the actual S3 application server.
3. HTTP has a massive forest of possible states (chunked encoding, keep alive connections, continuation responses, etc.), but only a subset of these should be applicable to a given call. With REST, you need to deal with all of these if you want a robust client.
4. There are 3,527 different ways of encoding the same data, and you have to do it properly for this day of the week. For example, all requests into AWS have to be signed with your secret key; the request to be signed includes a subset of the HTTP headers and the date. In this case, the date must be in the form, "Tue, 05 Sep 2006 10:42:33 GMT". You duplicate this in the Date: HTTP header. Unless you have an X-Amz-Date header, in which case you use that. Unless you have an expiration date, in which case you use an integer representing the number of seconds since the epoch, and you put that in the HTTP request line. When S3 returns a date to you, it's another beast entirely: "2006-09-05T10:42:33".
It seems like REST came about because people didn't like any of the existing protocols (ok), but realized that designing a protocol is hard (yes) so they just threw it out the window entirely (uh oh) and just started hacking on code without any regard for the consequences (cries).
Sunday, September 3, 2006
I'm sure that this is some internet phenomenon which happened way back when, but this is the first I've heard of it.
Amazon.com (all hail the company) recommended a DVD called Bikini Calculus to me today. (No, I don't know why. Yes, my recommendations are all messed up because I have to test the site frequently. At least, that sounds like a plausible explanation to me.) Yes, it's two girls in bikinis. Giving a tutorial on the calculus of a single variable.
There's even a snippet on Google Video.
I'm undecided whether it's amusing, sexist, or effective. Probably all three to varying degrees.
Amazon.com (all hail the company) recommended a DVD called Bikini Calculus to me today. (No, I don't know why. Yes, my recommendations are all messed up because I have to test the site frequently. At least, that sounds like a plausible explanation to me.) Yes, it's two girls in bikinis. Giving a tutorial on the calculus of a single variable.
There's even a snippet on Google Video.
I'm undecided whether it's amusing, sexist, or effective. Probably all three to varying degrees.
On Tuesday, my laptop started acting flaky. Well, ok, it's been flaky for awhile, but I just attributed that to Amazon's weird setup. This was flakiness in ways I've never before observed.
And then it bluescreened. Hard. Upon bootup.
I took it down to deskside, the folks who support user computers. They confirmed that the hard drive was toast. "But don't worry, you can have this new laptop."
Insert paniced look on dacut's face here. I mean, shiny new laptop is good, but it doesn't have my files. And I don't back up my files because I currently have nowhere to back them up to in a way that doesn't violation our IT security policy. The one place I can put them -- my desktop -- is perpetually full. Oh, yeah... I'm also lazy.
Thankfully, they managed to recover most of my documents. I don't really care about the rest.
I'm currently working on an interface to S3 that will let me mount a bucket there as a filesystem. If necessity is the mother of invention, panic is the drug which induces labor...
And then it bluescreened. Hard. Upon bootup.
I took it down to deskside, the folks who support user computers. They confirmed that the hard drive was toast. "But don't worry, you can have this new laptop."
Insert paniced look on dacut's face here. I mean, shiny new laptop is good, but it doesn't have my files. And I don't back up my files because I currently have nowhere to back them up to in a way that doesn't violation our IT security policy. The one place I can put them -- my desktop -- is perpetually full. Oh, yeah... I'm also lazy.
Thankfully, they managed to recover most of my documents. I don't really care about the rest.
I'm currently working on an interface to S3 that will let me mount a bucket there as a filesystem. If necessity is the mother of invention, panic is the drug which induces labor...
Subscribe to:
Posts (Atom)