Comment Stacks of PADDs (Score 1) 197
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.
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.
* 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 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.
It's time to boot, do your boot ROMs know where your disk controllers are?