Thought Palace

Brent “NetNewsWire” Simmons raises the idea of “an open protocol (and open source server) for syncing RSS/Atom subscriptions”:http://inessential.com/2010/02/08/idea_for_alternative_rss_syncing_system, that is, a way of keeping multiple local newsreader apps (like on a Mac and an iPhone) in sync with each other, so that they share the same set of subscribed feeds, and remember which articles have already been read. You can think of it as “IMAP for RSS”.

NetNewsWire already does this using Google Reader, and Apple’s PubSub framework (which is what Safari and Mail use) shares the read/unread state using MobileMe. But it would be nice to have an open protocol.

I have some experience with this, having implemented the sync system used by PubSub. It’s an interesting problem—you might think I would have just used Apple’s SyncServices, and it’s true that it would have worked great for the subscription list, but it doesn’t scale well to huge numbers of rapidly-changing “read/unread” flags.

I have two suggestions (which I would have made on Brent’s blog, except he doesn’t allow comments anymore.)

As everyone knows who works in the pet-food industry (or computer software for that matter), it can be hard to start eating your own dogfood. Case in point: I just this week set Chrome to be my default browser, though I’ve been working on it for four months now.

Partly that’s because when I started in July the Mac version of Chrome was too immature; and partly it’s because a web browser is something you need to have running and working all the time—especially since the Chrome project’s bug tracker and code-review tool are web-based.

But Mac Chrome is quite stable enough to use now, and as I haven’t been doing much Chrome development on this MacBook Pro lately (it takes too long to compile compared to my souped-up Mac Pro) I’ve installed the latest dev-channel build and replaced Safari with it.

I’ve been working at Google since last August. The Big G’s hiring process is rather weird—when you interview, it’s not for any specific team. It’s only after you get an offer that you decide which team to join, of the ones with open positions.

I decided on Google Sites, which I knew and liked from its days as JotSpot, a hosted wiki with some powerful features. It ended up not being the right place for me, for a couple of reasons:

Currently, Sites’ priorities are in website publishing, as a replacement for Google Page Creator (which is being phased out soon.) It’s quite good at it, but I’m less interested in that than in collaboration features.
Google’s server-side infrastructure is really, really, really huge and complex. There is an endless landscape of internal technologies and tools—the few that have been described in public (MapReduce, BigTable, Chubby, etc.) are just the tip of the iceberg. I have discovered that I am not very interested in this kind of stuff, and I quickly became frustrated by the deluge of technologies I needed to learn to get things done.
Running a large web service is like running a nuclear power plant or an electric power grid. It [...]

So, Web 2.0’s heyday is over, and somewhere out there, Web 3.0 is slouching toward us waiting to be born. What will it be?

There’s really no such single thing as “Web x“, of course. And all predictions are really just wishes. That being said, my wish is that Web 3.0 will be about distributed systems. To oversimplify:

Web 1.0 built up big brand-name websites with their own content—things written by them, or repurposed from the media companies that owned them, or stuff to buy.

Web 2.0 embraced “user-created content” and interaction between users. The content creation has become less centralized, outsourced to whomever wants to register an account and post stuff, but the sites managing, storing and serving the content are still centralized.

Web 3.0, I hope, will take the decentralization to the software, and the storage. Monolithic web apps run by huge server farms—Facebook, Blogger, Twitter, Flickr, etc.—will be at least in part supplanted by apps that users run locally (or at least ‘nearby’) and which share data among each other.

Why is this important?

Centralization creates concentrations of power, and that’s dangerous. The people who run the servers have total control over your (and everyone’s) data. They can snoop at it (however private [...]

Ruby has a wide variety of HTML/XML templating engines, but none of the ones I’ve found work the way I’d like. It’s quite possible I’ve overlooked some, though.

My current gold standard for templaters is the Python library Genshi (which was inspired by Kid)—what I like about these is that your templates are valid XML: the parameters and control structures are expressed as special XML attributes and tags. This makes it easy to edit your templates in syntax-checking XML editors, and guarantees that your app serves valid XML or HTML.

But as I said, none of the Ruby template engines I’ve seen work this way. They’re all either generic macro systems that intermix markup and Ruby (like ERB), or they’re ruby APIs that output markup (like Builder, HAML and Markaby). I don’t really like either approach.

If you’ve got a good suggestion, I’ve got a gold star ready to stick on your forehead!

I haven’t used Chrome yet, though I know people who work on it, and it looks like a good browser with some good new ideas. But I’m unsure of the benefits of one of its main talking points: that what web applications really need is to have less browser “chrome” around them. As I put it in an IM to Julian Missig yesterday:

I think the problem isn’t that the browser chrome has too much [UI], it’s that the apps inside have too little.

Too little what? What are the web apps lacking? Since you ask:

A menu bar. Despite today’s fashion to get rid of them, menu bars are really useful. They’re a great interface for discovering the capabilities of an app, and for accessing rarely-used but important features. That’s why they were invented. Denied standard menus, web apps have tended either to splatter buttons all over the screen, or implement their own menus out of DHTML (usually doing a terrible job of even basic usability.) Keyboard shortcuts, if present, are divorced from menus so they’re not discoverable; and on the Mac at least, they awkwardly use a different modifier key (Ctrl, vs. Cmd) than “real” shortcuts.

A filing system. Web apps let [...]

FYI, I ended up taking the position at Google. I started two weeks ago, and it’s been quite exciting, despite (or because of) the “drinking from a fire-hose” aspect of learning my way around the big G.

I’m on the Google Sites team. I’ve been interested in wikis for years, and now I get to actually work on one. (Although Sites, née JotSpot, is not a typical wiki.)

I could write a lot about my experience of Google so far. It’s quite an interesting place. Merely learning about how some of their internal systems operate has been jaw-dropping. (Do you have any idea how much hard disk space Google has? Or how many CPUs? Or how many search queries they handle? Unfortunately I don’t think I’m allowed to tell…)

For now I just wanted to say that I’m not in the job market anymore. Also, that I really like all the free food :-d

‘Prince McLean’, writing for AppleInsider:

Data transaction security in MobileMe’s web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple’s cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser’s SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.

If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats.

It’s pretty clear to me from this description that (a) McLean doesn’t know much about data security or HTTP, and (b) the system he’s describing would be patently insecure. And unfortunately, the actual system is just as insecure as I was afraid it was.

The most glaring problem is that, since the main page resources (HTML [...]

I’m fooling around with Soup, a newish micro-blogging service I just discovered. I’ve never signed up for tumblr or its other clones, but I’m kind of smitten with Soup, so I set up my own:

beautiful snej soup, yum

I’ve got it aggregating stuff from my del.icio.us, flickr and last.fm accounts, as well as this blog. And I’m directly posting some things I’ve run across today, via its very nice bookmarklet.

Part of the reason I got sucked in is that Soup has the single best new-user experience I’ve ever seen on the web. You just click the “try it” button on the home page, and you get your own soup blog. No signup, no registration, just instant gratification. Then you can slide open the control panel (that slider itself is a beautiful piece of UI), import from your other social sites, and fool with the settings, all in privacy. Only after you’re hooked do you need to press the Create button and choose a username and password, whereupon your soup goes live. It’s brilliant — the web equivalent of the “untitled document” UI introduced in the ‘70s by the Xerox Star.

Anyway, please take a look and join me! (It’s not obvious [...]

I just discovered that there is an ECMAScript 4—better known as JavaScript 2.0—in development. As a shameless language slut, I immediately dove into the language overview, and it’s pretty neat.

This turns JavaScript into a much more useable language, that I could see doing serious development in. I’m well aware that today’s JS isn’t a “toy”, that it’s got an interesting prototype-based object model under the hood; but I’ve found the language so loose as to be difficult to use. This new version adds a full class model, much better support for iteration, a form of generators/coroutines, and more.

Intriguingly, it also offers type-checking, which has been absent from most mainstream dynamic languages. I know it’s trendy to use “duck typing”, but I find that languages with no compile-time type-checking frustrate me because I make so damn many mistakes that aren’t caught until runtime; which means things I could have fixed in two minutes in C++ or Objective-C take half an hour to fix as I run the program over, and over, and over, discovering and fixing one problem at a time.

Given the concurrent developments in Apple’s JavaScript interpreter, I’m getting pretty excited for JavaScript. I hope that in addition to making [...]