Concern

I went to this. I’d like to go to more of these, but it’s a bit out of my way to go to San Francisco. I think I saw _____ ____ ________ there, who I had _ ______ _____ _____ __. But I’m not sure if it was ___.

But, this was the first time that I drove myself into the city. This seems somehow significant, because I haven’t liked driving that much in the past, and I’m really I was really afraid of driving around a big city like that. I also recently drove myself all the way out to _______; I went out there, and managed __ _____ __ ___________ ___. That was weird, but significant, that I managed to drive myself all the way out there, and ___ __ ___ ___ _____ __ ___ ____ _______, ______ __ ____ two hours later.

Does anyone know why FedEx has started to suck so much more then they used to? Because, it seems like every package I have delivered by them gets left out on the street, or delivered to the wrong people (in the right building, but still, to the wrong people).

Dear journal,

I got to have lunch at Google’s campus in Mountain View, today, along with a handful of other Summer of Code participants. It was fun. We ate food and talked to people.

Ironic introduction aside, it was kind of neat. I work in a depressing-ass cubicle farm in Sunnyvale, so seeing Google’s campus makes one gawk. It looks almost like a college campus, but everyone there is paid really well. I can’t help but regard it as almost cultish, what with that many beautiful, incredibly smart people hanging around a really cool-looking space — it’s like out of some sci-fi future, there’s got to be some kind of gag. I can’t help but feel like an ugly fuckup who wouldn’t belong there. But maybe there’s a basement.

They also have a huge number of people in a small space. No, check that, it is not a small space. It’s actually quite large. But they have a huge number of people and the buildings and parking are really crowded. They have valet parking in some lots, not because it’s Google and awesome, but because it’s fucking crowded.

I ate Indian food, which was really pretty good. It beat out the Indian buffet that’s across the street from us in Sunnyvale, but that isn’t hard to do. Someone else in the group had steamed oysters. It’s bizarre to eat this well in a corporate cafeteria. They had sodas with real sugar in them, not the corn syrup swill you’ll find everywhere else.

We got to meet Chris DiBona and Leslie Hawthorne, and listen to Chris chat about some things. They’re both nice. OK, Chris isn’t so nice, but he’s intelligent and tells funny stories.

Google are good people.

Oh, wow, Eclipse supports Emacs key bindings.

That is awesome. Eclipse is now officially “good,” in spite of its flaws.

It came to me as a real flash of inspiration, and it seems exceedingly simple in hindsight, but I figured out what I need to do to implement handshake message output (see my previous post on this).

It’s quite simple really; boiling it down to a high-level algorithm:

if there is a buffered handshake fragment
  write bufferd data to output buffer
while we have a handshake message to write
      and there is space in the output buffer
  write the next handshake message to a temporary buffer
  write as much of this buffer to the output buffer as possible

This is kind of obvious, but the flash of we have to build each full handshake message in a private buffer was what made me grok the problem fully.

The only issue is that we don’t know, a priori, how big that private buffer has to be. The current API treats the underlying buffer as fixed: the caller allocates it, trims it to size, and swaddles it in the protocol code. Everything you write to a protocol object has to fit in the original buffer.

But, maybe, we could add a “resize mode” to each protocol object. So the caller can say instead “here’s a buffer. It may be too small to hold what I’m going to write to it, so if any setter call runs out of space, resize the buffer for me.” Very often we can tell if the buffer is too small very easily in all setters, and if we can’t, we can fall back to catching BufferOverflowException.

Adding that to the existing protocol objects wouldn’t be hard, but may be a bit ugly, and we might lose some opportunities for optimization on the read side (the underlying buffer can’t be final for one, but that probably doesn’t matter much). I think splitting the protocol objects into a base read-only class, and a readable/writable subclass, is the nicest, but that’s a lot of busy work that doesn’t make much progress on the library. And the deadlines, they loom, as deadlines are wont to do.

(This blog is kind of turning into my own TODO list, and impromptu note pad. I’m sorry if this bothers you, but no, I don’t care.)