« November 2003 | Main | January 2004 »
A slightly underweight effort that was nonetheless entertaining. The problem with "these kinds of movies" is you know that there's going to be one of three "surprise endings" and there are no real clues to point you to which one -- it's totally arbitrary, which makes the movie as a whole less satisfying. I wish they had done more Spy School stuff, and the movie gets a little too Pacino in the end, but it was packaged nicely with just enough intrigue to keep you involved.
Kind of a "Straight Dope for the Geek Guy", here's an attempted explanation for the ban on electronic devices at certain times during your flight. Still seems a little dubious to me, but what are you going to do? Some airlines are better than others. I'm never flying Iberian Airlines again with their "ningunos dispositivos electrónicos permitidos" policy: flying from Chicago to Barcelona without being able to use your laptop, MP3 player, or even noise-cancelling headphones s-u-x sux.
As suspected, the reason you can't use your cell phone has nothing to do with potential interference with navigation in the air, but instead with the ground-based infrastructure that isn't equipped to deal with a phone having line-of-sight to hundreds of cell towers at once.
Not a movie in the conventional sense, more like a work of art. You probably don't realize it, but you have most likely seen large chunks of this movie: images of cars speeding on expressways at night, people crowding to get on an escalator, the moon rising over the city, all sped up. A lot of amazing photography, and it has held up amazingly well (the movie is twenty years old). I have always liked the music of Philip Glass, but others might find him grating. I loved it and find this to be the perfect chill-out experience. The first in a trilogy.
A fitting end to an incredible trilogy. I really liked the way Peter Jackson weaved together the different storylines into an effective presentation. I don't think the movie needed to be as long as it did ... a few too many scenes were shown in slo-mo that (imho) weren't enhanced by the effect, and some of the parting scenes had me looking at my watch. But on the whole, an amazing cinematic acheivement that I was glad to witness.
Sam Ruby gave this presenation at the XML Conference last week, and it details the motivation for wanting to rev another syndication format. It more or less boils down to tightening up the spec so there's less ambiguity in what is allowed where in a feed. The presentation does a great job of comparing and contrasting how the existing specs (and psuedo-specs and spec interpretations) handle the different feed elements.
One other thing I wanted to call attention to is the format of the presentation itself. The slides look beautiful in Mozilla, less so in IE 6.0, but do a View Source on a couple of those slides. Isn't that fabulous? Snaps for Sam Ruby for the awesome and appropriate use of CSS.
Source: Sam Ruby: Atom in Depth
Some more tantalizing hints as to how a syndication client on Longhorn might take over the world.
Prediction: in a couple of years, RSS clients (or whatever syndication format emerges as the standard) will look a whole lot more like Headline News than Microsoft Outlook. If there's any client that's going to get there before Longhorn is released it'll most likely be a killer-app developed on Macromedia Central. It's a race.
Source: The Scobleizer Weblog.
As more and more people wake up to the idea that a fundamentally polling-based RSS distribution model might have some "scaling challenges", different ideas to handle this come to the fore. Here's an interesting model: using the BitTorrent peer-to-peer infrastructure to distribute RSS feeds.
BitTorrent is a cool bit of engineering that solves the "Tragedy of the Commons" problem that plagues many p2p protocols: you gotta pay (i.e., offer some upstream bandwidth) to play (download). The Java-based client Azureus is my client of choice, but it's really the protocol that's the smart stuff here.
Getting back to how this works with RSS, I personally think this is overkill for the scaling issues at present: I think getting the clients and server-side aggregators/publishers to agree on a push protocol and transport is a more pressing concern. I think the P2P idea is a good thing to keep in our pocket when RSS starts getting bulkier.
I love how Google just quietly introduces new features that (to borrow a phrase from somewhere in my past I can't put my finger on) "surprise and delight" the user. Here's the latest batch of fun things you can do, just in time for the holiday season:
Check out the rest of the page Google Web Search Features for other tips you might not have seen before.
We've been hard at work here at the Burning Door compound banging out a big ole' scalable Java web application, and it's fun to see how the platform has evolved over the years. When we first created spyonit.com, J2EE didn't even have an acronym yet, so Enterprise JavaBeans didn't even exist yet. So what did we do? What most everyone did back then: we rolled our own persistence layer, our own RMI-based distributed fault-tolerant component architecture, and all sorts of other plumbing that didn't really have anything to do with the "business logic" of the application.
Guess what? It worked. It was a big pain to have to maintain all of the infrastructure code as well as the app code, but since we had built it, it was transparent and we could go ahead and fix what needed fixing. Would I do it the same way today? No f'ing way.
In fact, when we were acquired, we embarked on an effort to refactor the application using EJBs, JMS, and all that J2EE goodness so we could deploy on top of a "real" web application server like WebLogic. Then we wouldn't have to worry about all that infrastructure code and get all sorts of magical benefits like "linear scaling" and "distributed transaction management".
I learned a few things during that effort. First, there's no real "halfway" when you start down the EJB road: it's best just to bite the bullet (to mix metaphors) and refactor things to the "EJB" way even if it doesn't really map to the system architecture as it existed before. Second, when treated as a whole, the J2EE spec really is an impressive bit of engineering design, and it's nice to be able to stand on the shoulders of people that think about that stuff all the time. Third, if something ever went wrong when you actually deployed your app, good luck trying to find which of the 29 configuration files you messed up on, assuming you haven't stumbled upon some undocumented limitation of the app server itself. It really makes for an overall slow, "unagile" development process and some miserable debugging.
Which brings us to an article I read a little while ago entitled "Simpler Java". Fully buying into EJBs is just so heavy and ponderous that there's a bit of a backlash which results in some intriguing options. There are so many amazing open source frameworks and libraries available today, you can save yourself an incredible amount of time and effort by surveying what's out there. That's what we're doing here. I just wanted to share with you what my classpath currently looks like and my thoughts on the various packages we're leveraging here at BD.
This is a great Christmas movie done in the classic style (I was going to say "old school" but I didn't want to get my Will Ferrell movies mixed up). I give Will Ferrell tons of credit for playing it straight and never once winking to the camera. Good job by Jon Favreau for showing restraint and nodding to Christmas movie traditions. Completely inoffensive, somewhat sappy, very funny movie.
Upon reflection, there really wasn't a whole lot going on in this movie: three little girls doing a whole lot of walking. It still managed to capture my interest, though, and the photography was outstanding. A simple story well-told.
A very nice article from salon.com that talks about the building wave of RSS and content syndication. It's funny, around the office we've been making the exact same analogy: that RSS feels a whole lot like HTML did in 1994.
It's worth sitting through the ad to get to the article.
The template that Movable Type comes with to represent an RSS 2.0 feed, while valid, can be construed as a little bit "funky" because it uses some Dublin Core elements instead of just core RSS 2.0. That's fine, but I prefer to stick to the spec if I can. Here's the template I use that seems to validate at Feed Validator:
Just copy and paste it into your "RSS 2.0 Index" template in MT. Remember to edit the <managingEditor> and <webMaster> elements, as well as change the timezone from "CDT" in the various MTEntryDate tags (haven't figured out how to generate that from the format parameter).
The well-intentioned Atom Feed syntax effort is at a critical point right now. Many developers are fed up with the contentious turn that the discussion has taken lately and want some kind of resolution sooner rather than later. This frustration has prompted Don Park's proposal (see also the corresponding Wiki entry) that Atom just start with RSS 2.0 as the base syntax and "fix" it. A totally reasonable proposal that was exactly Dave Winer's intention when he finalized the RSS 2.0 spec.
A very good summary of the situation is given by Diego Doval in his blog posting, which spurred an interesting series of comments. For the record, here's where I sit:
<pubdate> and <dc:date>. I personally go with RSS 2.0 with <pubdate>.This will be good to keep following, that's for sure!
A little while ago I posted what Jerry Michalski thinks about social networking tools (like Friendster and LinkedIn), so I figured it's appropriate to follow that up with Esther Dyson's opinions on the matter. Guess what? She doesn't really like them either.
Huh. Well, I thought I had Nextel's marketing strategy figured out, and there they go keeping me guessing. Introducing the "Russell Simmons Phat Farm II Signature i733" from Nextel. It's on every enterprise sales manager's and construction site foreman's Christmas list!
And my favorite:
Phat!