And yet it's not uncommon at my house to see a stack of phones and tablets on a table. I resolve it in my mind as an acknowledgement that we'll never be rid of UI gaffes or incompatibilities.

Actually, that was Bill Atkinson: http://www.folklore.org/StoryV...

Wow, what an easy pitch. :-) At Mozilla, we've put together a tool called DXR ( https://github.com/mozilla/dxr... ). It indexes your code and lets you do text and regex searches. But if you can get your project to build under clang, you can really have some fun, with queries that find...

* Calls of a function (great for dead code removal)
* Uses a type
* Overrides of a method
* Uses and definitions of macros
* etc., etc., etc. There are something like 24 different structural queries you can do.

Because all of this is informed by the internal data structures of the clang compiler, it's nigh on 100% accurate (aside from more dynamic behaviors like sticking function pointers in a table and passing them around). You can also explore a hyperlinked version of the source, bouncing from #include to #include and drilling into methods.

Here's how to set it up: https://dxr.readthedocs.org/en...
Here's our production instance you can play with: https://dxr.mozilla.org/mozill...

If you run into trouble, pop into #static on irc.mozilla.org, and we'll be happy to help you.

At least for #2, you can fix that in Firefox by setting browser.tabs.drawInTitlebar to false in about:config.

I'm with you. My pet peeve with Google Docs is that the page randomly scrolls to different parts of the doc while I'm editing--and not due to anyone else editing.

Web apps are awful, and I'm saying this as a professional author of them. Maybe in another 5 years, we'll be back where we were in 1984, UI-wise. With an infrastructure that wasn't designed to handle them, web apps are also harder to write than desktop ones. Their one saving grace is that you don't have to go around porting or installing them, which can be significant in a cross-platform environment. As for me, my UI Nazi tendencies keep me on local apps whenever possible. See http://www.subethaedit.net/ for how apps ought to be.

You hit the nail on the head with "theoretically". We now have such joys as presentation through JS and semantics through CSS. Will the madness never end?

You bring up an excellent point: ZODB doesn't do any referential or data-type integrity checking; it's pretty much just a dumb (though rather concurrent and durable) graph store. Thus, ZODB-using apps have to take care of data integrity themselves or else interpose another layer (which you'd want to do in a "shared" situation like you mention).

I guess that's the tradeoff ZODB makes: really fast and agile development (no schemas to maintain, etc.) in exchange for no particular constraint enforcement. In practice, the latter is mitigated (and lots of painful debugging saved) through use of constraint-enforcement frameworks like Archetypes, but that still makes me queasy in a multi-app situation, as you'd have to make sure everybody uses the framework.

Personally, I'm both a ZODB and a Postgres wonk. What I'd love to see is the best of both worlds: a language-agnostic graph DB with internal constraint enforcement and, as my pony, a declarative ad hoc querying language. :-)

To be fair, I wouldn't say the Zope database (ZODB) is not a "solid foundation". It's one of the best parts of the Zope stack and, in 3 years of dozens of clients using it in Zenoss, Plone, and other apps, I've never had it corrupt or lose any data. It's a proper DB--ACID, MVCC, and all that--and you can even lop transactions off the storage to go back in time. Don't expect it to be a relational DB with the ad hoc query tools typical thereof; it's an object DB, with the aim of persisting graphs of Python objects transparently.

Now, if you aren't familiar with it, the ZODB can indeed seem opaque, but, just like any DB, there are tools to read and modify it. At the highest level, just stick "manage" after your Zenoss URL, e.g. http://example.com/zport/dmd/manage . That'll get you into the web-based Zope Management Interface (colloquially, "the ZMI"), where you can poke around at any object that someone's bothered to write a UI for. Deeper than that, you can connect to ZEO (a server that brokers access to the ZODB over a socket) and mess with the object graph using normal Python. When you're done, "import transaction; transaction.commit()". (The Zenoss developers are probably trying to scare you away from such digging around in fear that you'll violate their objects' invariants and leave them a real mess to solve.)

Now, I don't say that Zope isn't scary; it has over 10 years of scary stored up in it. But the ZODB is a cuddly, loving part.

Cheers!

I should mention that we use a ticketing system (Trac) for more involved stuff, but IRC is great for quick or rapid-fire-interactive requests.

Funny that this is modded funny. Here's how we use IRC at our internal consultancy at Penn State University to field questions from our 70-or-so clients. Combine with Mibbit and a copy of supybot, and you've got brain-dead-simple-to-use semisynchronous communication that also spits out Googleable logs.

At my 12-person (and 70-client) internal web consulting shop, we use the heck out of Trac's wiki. Here are some examples.

On the contrary, session-dependent web apps are bankrupt design-wise. They violate the (stateless) page metaphor, breaking the standard UI and confusing the user, simply because some programmer couldn't be bothered to find a good way of maintaining state. Some of my favorite denizens of the Session Hall of Shame are...

• Apps emblazoned with "Don't use the Back button while you're here or the world will come to an end! Oh noes!11!1!oneone" (Concur Solutions, I'm looking at you.) 60% of web users employ the Back button as their primary means of navigation. Usability issues surface when the Back button doesn't work the way they expect. It's an old observation, but I've yet to see it knocked down.
• The ubiquitous session timeout: go to lunch, come back, and you get to re-enter all your data. Is server space really at such a premium that you can't let sessions last a week, if you do insist on using them?
• Breakage of parallel surfing: I have the habit of opening 3 or 4 links from a page in background tabs all at once. In many overly sessiony sites, this causes weird behavior.

In these days of >100KB page loads, it's silly to sweat over 4KB typed into a textarea. If you find it painful to maintain state from request to request programmingwise, you're not using enough framework. Find something nice that'll stow user data client-side without making you think about it. Or, if you're in the mood for something exotic, try a continuation-based framework like Seaside: those let you forget about the statelessness of HTTP altogether, though admittedly at the cost of tokens which feel a bit like session identifiers but aren't quite. (They still don't break the Back button or parallel surfing, and you can set the timeout to a week.)

What I really mourn is the passing of HyperCard for the web. There was a time back in the nineties where it looked like HyperCard was going to get rolled into QuickTime and thus be available in any browser that could run the plugin. Now that would have been sweet. I suppose Flash isn't a much different result, though I hear its roots in linear-chronology animation still poke through when trying to develop apps on it. If the Flash UI were a little better--using native widgets, letting standard text selection and copy and paste work--I'd likely be won over. I suppose the best choice today is session-free AJAX with a good framework to keep the details out of your face.

Thanks for reading to the bottom of my rant! I feel much better now. :-)