I just discovered Mark Pilgrim’s Recommended Reading. This nifty page lets you type in your url and generates a list of blogs you might want to read. It worked quite well for me.
(I found this site thanks to a comment by Baldur Bjarnason on but’s she’s a girl).

I used to start my Saturday afternoon web surfing by posing an interesting question to Google, but lately I’ve been “ego-surfing,” as I hear its called, at Technorati. While some bloggers strive to increase their readership, I don’t mind living in a small corner of the blogosphere. The few folks who do link to my site provide me with interesting reading. I’ve noticed that Technorati doesn’t think this page is a blog… how would it know?

From The Truth Laid Bear, I like the concept of the new blog showcase but alas found no interesting reading. I added myself to the ecosytem. I expect I’ll be categorized as an insignificant microbe, and that’s fine with me.

Recently I have found myself talking about what we put in the gutter of a blog. I’ve heard that the term gutter comes from publishing — that space near the book binding which you want to keep blank, since it is hard to read anything printed there. I’ve also seen web page design documents that refer to the gutter as the space between collumns. I’ve heard this terminology over the years and it has never been an issue for me. However, it feels unsettling, even disturbing to call the collumn on the right of my blog, a gutter. Nonetheless, this term seems frequently used in the blogosphere.

<rant>
When I think of gutters, I think that I should really clean out the leaves and other debris that may have collected in the gutters on my roof. In real life, I don’t much look in the gutter at the edge of the street, particularly in crowded neighborhoods, where I’m likely to see unsavory items discarded there.

In blog surfing, my eye is drawn to the left or right side of the page. Far cooler than a google search, I browse the web through the recommended links of my favorite bloggers. Nifty tools, like blogrolling, are appearing to help people put interesting and timely bits of information in this precious screen real-estate.

Who wants to live in the gutter? I keep some of good friends there, people I admire, and places I like to visit. I feel honored when I find myself in someone else’s gutter.
</rant>

It’s funny. But is it funny (ha ha) or just funny-strange? you tell me.

Don Park recently spent some time with the Laszlo Presentation Server and drew a nice architecture diagram in his blog. Generating an LZX from a JSP is one way to create applications in Laszlo. A more common development pattern is to simply write an LZX file that references an XML data source. I’ve drawn a diagram with a similar structure to Don’s that shows the HTTP requests from the browser, to illustrate how this works.

1. The user goes to the web page “http://mysite.com/hello.html”
(a) the browser requests “hello.html” from mysite.com
(b)The web server sends that document it to the browser.

2. The browser notices that “hello.html” references “http://mysite.com/hello.lzx”
(a) The browser requests “hello.lzx” from mysite.com
(b) The Laszlo Presentation (LPS) finds “hello.lzx,” creates a SWF and sends it to the browser.

3. Your app has referenced a data source (an XML file on the server’s local file system, on any other server, or dynamically created XML develivered over HTTP)
(a) The LPS-generated SWF makes a native Flash call that causes the browser to send a request to LPS
(b) LPS fetches the data (which is in standard XML). It transforms the data into native Flash goop and sends it back to the browser.
(c) It appears in the SWF auto-magically datamapped to the appropriate view or whatever you asked it to do in your LZX file.

What Laszlo has done is to normalize the Flash runtime for the creation of applications. It all ends up running in the Flash player, but there is a bunch of Laszlo magic that lets you focus on application development and interface design. Laszlo provides a framework, which includes a view system, data mapping, layouts, constraints and all sorts of useful stuff.

One last technical note, LPS does a bunch of smart caching. If an LZX file or the data source hasn’t changed, LPS efficiently delivers the same bunch of bits it created for the previous request. Incremental compiles are achieved by breaking up your app into separate files, typically using the <library> tag. Then LPS only compiles the file that has changed.