Gmail is such a terrible email interface.  My IMAP connection failed in mid-send, so I thought "that's fine, I'll just check the web interface".  Except I cannot, for the life of me, determine if the email was ever sent.  I see it there -- in the inbox, in some weird conversation mode -- but it's entirely unclear if it's sent.  It doesn't appear in the Sent folder, at least, and the conversation is marked to suggest that at least one of the entries (unspecified which) is a draft.

Ok, fine, so I just go and send it with the web interface.  Problem solved, right?  Except I get no response to my email, and it *still* doesn't show up in my Sent folder.

What is so wrong with the tried-and-true "show your emails in chronological order" interface perfected over the last thousand years?

Be a good citizen and go to the Google Suggestion page, check "Switch Conversation View on or off" on this page, type in your email address, and click Submit.  The internet will thank you for it.

-david

While working on some bank import engines for Expensify I found I was getting duplicates.  Naturally I assumed I was screwing things up, but despite a full sweep through the code I couldn't find any bugs.  The only theory I could come up with was the <FITID> attribute was changing on a given transaction.  But that's impossible, right?  From the OFX spec:

"3.2.3 Financial Institution Transaction ID <FITID>

An FI (or its Service Provider) assigns an <FITID> to uniquely identify a financial transaction that can appear in an account statement. Its primary purpose is to allow a client to detect duplicate responses. Open Financial Exchange intends <FITID> for use in statement download applications, where every transaction (not just those that are client-originated or server-originated) requires a unique ID."

Yep, sounds pretty permanent to me.  Except it's not.  In fact, it's quite common for the FITID to change, at least for US Bank .  I'm guessing it changes as the state of the transaction changes -- only the last two digits appear to change.

Anyway, this is probably just a random bug with US Bank, right?  Not according to this forum.

Ugg.  What a pain.  How hard is it to just follow the rules and make a truly unique identifier? 

-David Barrett

For Expensify I'm finding that I can't avoid coding in half a dozen languages simultaneously.  At any point in time I will have active windows in C++, PHP, HTML, JavaScript, CSS... and... English.  Half a dozen.  Anyway, it's a nuisance and I'd like to consolidate.

In particular, I don't like how I generate and manipulate HTML in two places, with two different languages: PHP and JavaScript.  PHP spits out a bunch of HTML, along with a bunch of JavaScript to manipulate that HTML via the DOM.  It generally works OK, but I'm finding that I generally end up writing the same code twice.  Not exactly, but enough to be annoying. 

Consider the case of a dynamic page, like a web-based email reader.  Something where there's a ton of data that is transformed into HTML in some sophisticated way.  There's a range of ways to do it:

Web 1.0 way: Read everything into PHP memory, process, output into static HTML with links.

That works fine, except every time you do anything you need to ask the server to regenerate the page.  Which leads to:

Web 2.0 way: Read everything into JavaScript memory, process, output into dynamic DOM.

This lets the browser do everything locally and avoid asking the server unless it's really necessary.  But it has a downside: when the page loads it's completely blank while the JavaScript does its thing.  (Similarly, if the browser doesn't support JavaScript, it's just dead.)

As a result, I'd like is some combination of the two where the same code and execution engine is used on both the server *and* client.  Then the process would go like:

1) Server reads everything into server-side JavaScript memory

2) Server generates HTML DOM according to whatever logic

3) Server serializes the entire state of the page -- both the HTML DOM as well as the JavaScript VM -- into a big HTML/JavaScript blob.

4) The browser deserializes this blob straight into the HTML DOM and JavaScript VM -- without any big "onload" handler that builds the page from scratch.

5) The exact same code that was initially used by the server to generate the page is used by the browser to manipulate that page.

Make sense?  So rather than having two sets of HTML modification code (PHP to generate it, JavaScript to manipulate it), have just one set of code that is run on both the client and server.

And to top it all off, if the browser doesn't have JavaScript, it'll still get a fully-formed HTML page.

In this model, the programmer wouldn't even think of "generating an HTML page with associated JavaScript".  Rather, you'd think of building a page up using a series of JavaScript, CSS, HTML, database, and other resources, and then just calling "document.serializeToBrowser()" or something when the page is in a state that you want to send to the user.

Does something like this exist?  I see lots of stuff up on Wikipedia, but none of it quite fits the bill.

-david

A while back I mused about creating an index of all content and then linking to pirated copies when available.  I suggested copying IMDB, but some clever pirates came up with an even better idea: just layer their tools *overtop* IMDB.  And Amazon.  And pretty much anybody who already maintains a structured index of all content.  Brilliant!

Not the most creative title, but then again, it's not written by the most creative guy.  Rather, it's written by the guy who was literally given those orders: go into the mountains of Tora Bora and kill Bin Laden.  Bring back a thumb as proof.

I first learned not of the book, but of the controversy of the book ever being written.  See, officially, the Delta Force doesn't even exist.  I know, the name sounds so Hollywood, and the notion of a secret elite military organization that swoops around the world in -- get this -- black helicopters, ya, it sounds crazy.

But it also happens to be true.

So when the secret commander of honest-to-god super-soldiers goes on to recount a first-hand experience of a battle that, officially, they took no part in -- people who prefer those secrets be kept were justifiably upset.

Despite that (or even because of that?) it's definitely worth a read.  Indeed, I'd suggest you stop right now and go pick up the book.  Kill Bin Laden.  Hard to forget that title.

For the rest of you, I'll summarize as follows: Kill Bin Laden is a single book that tells two stories.

First and foremost is a story of how utterly bad-ass the Delta Force is.  In a matter of days, precision airstrikes, a dozen Delta soldiers, and a ragtag group of bickering Afghani mercenaries accomplished what the Soviet Union failed to do with tens of thousands of highly-trained soldiers: evict Bin Laden and his soldiers from Tora Bora.  The enormity of that success can't be overstated.

But the second, more poignant story is the complete failure to catch Osama Bin Laden, despite having him boxed in from all sides to a tiny ten-mile square -- and covered day and night with total air superiority.

There are many, many fascinating components of each of those stories, but I'll only mention two here:

On the good side, I had no idea what a game changer it is to have people on the ground.

When watching CNN, I sorta got the idea that targets are selected by satellite view, conveyed to the pilots, programmed into the bombs, and then dropped.  It all seems handled from such a distance.  But in practice, the constant drumming of remotely-targeted bombs as small as grenades up to the massive Daisy-Cutter had almost no effect.  They were so dug in, and so well concealed, they were completely untouchable.

But the moment a Delta operator got into position, that changed.  Bombs that previously struck harmlessly on the mountain sides started dropping straight into tunnel entrances and hardened bunkers.  After every hit, people would scatter and reveal more tunnels and more targets.  With nothing more than what they could carry on their backs, this tiny crew of Delta operators turned the Air force from an impotent noisemaker into a devastating machine for precision destruction, literally overnight.


It's an amazing transformation to read in the book.  But even more amazing is the futility of it all.  After all, the mission wasn't to destroy their compound.  The mission was to catch Osama Bin Laden.  And by that measure, the mission was a complete and utter failure.

It's hard to convey the anti-climactic end without reading the book.  But our guys were just getting up to speed -- finally gaining and holding ground (unlike the Afghani soldiers who just raided every morning and came home for dinner every night, regardless of whether they won or lost) -- when Al Qaeda surrendered and all our Afghani allies just sorta gave up and went home... with Bin Laden disappearing in the confusion.

There's this great scene where our Delta operators are still high atop the barren, snow-laced mountains, looking for targets that would never appear, just refusing to give up despite every living person in the area -- friend or foe -- having left long ago.


And I think that's what makes the book so great.  It's not a celebration of might.  It's not even a finger-pointing exposé.  It's simply a retelling of what happened, warts and all, from the only person in the world who was in a position to know.

Sure, mistakes were made.  Some of those mistakes probably allowed Bin Laden to escape.  But the only way to learn from those mistakes is to know what they were, and this book is the only authoritative book on the subject.