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.
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.
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.
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.
Complex page state is kept on the server, in a session-associated database. If requests are sending a little more, no harm. If they're sending a lot of data every time, which isn't user-entered on that specific page, they're not very well coded.
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...
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.:-)
Before CACert will believe you own domain.com, you have to demonstrate that you can read email sent to root@domain.com, webmaster@domain.com, or any of a few others. I think it's a pretty good tradeoff between convenience and security, since, if somebody can read your root mail, you're pwned anyway.
You can buy Palm batteries here: http://palm.pdainternalbattery.com/. As another data point, my Clie PEG-SJ20's battery has held up fine for 2 years, even though I often use it for 4 hours at a stretch with 40% backlight and a Stowaway keyboard. Lithium batteries like to be charged often; I charge mine nightly.
I've had this happen, on and off, in many previous versions of 10.3.x (and maybe 10.2.x too). What happens is that it activates the wrong ColorSync profile for some stupid reason. Go into System Preferences->Displays->Color and click your preferred display profile to get things back to normal.
I use Palm Desktop (ugly but featureful) for calendaring and tasks but Address Book for contacts. iCal still has no support for repeating tasks, something which absolutely boggles my mind: how else is one expected to get the bills paid every month?
Some folks use MS Entourage, too. I can't render an opinion on it, myself.
You don't need Missing Sync. Just download Apple's iSync 1.2 Palm Conduit. Combined with Palm Desktop, it works great with my Clie PEG-SJ20. Clie, Palm, whatever--the only difference, as far as the desktop machine is concerned, is the logo on the front.
I don't mean to deprecate the work of Hertzfield, but MacPaint 1.0 was written by Bill Atkinson, according to both its own "splash screen" (actually just a brief text message in the window titlebar) and this apple.com page (the original page having disappeared). QuickDraw was written by Hertzfield and Atkinson together, according to its Wikipedia entry.
Slashdot Mirror
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...
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. :-)
Thanks for filling in the holes. :-)
Before CACert will believe you own domain.com, you have to demonstrate that you can read email sent to root@domain.com, webmaster@domain.com, or any of a few others. I think it's a pretty good tradeoff between convenience and security, since, if somebody can read your root mail, you're pwned anyway.
Google didn't write it; they bought it as a Windows-only program from somebody else.
Mac equivalents include WhatSize (free), OmniDiskSweeper (commercial and no reason to buy it, as WhatSize clones it completely), and even the Finder.
Not to mention that you can't open two files of the same name, at least in the Mac version. They should be ashamed.
That would make it harder to fund new translation efforts.
You can buy Palm batteries here: http://palm.pdainternalbattery.com/. As another data point, my Clie PEG-SJ20's battery has held up fine for 2 years, even though I often use it for 4 hours at a stretch with 40% backlight and a Stowaway keyboard. Lithium batteries like to be charged often; I charge mine nightly.
Something like ReiserFS's plug-ins might be useful here. See this example of how /etc/passwd could be split up to improve privilege granularity (search for "Take /etc/passwd for example"), all without breaking existing programs. This would also give you finer-grained modification timestamps, which would help you figure out what that pesky installer just did.
I've had this happen, on and off, in many previous versions of 10.3.x (and maybe 10.2.x too). What happens is that it activates the wrong ColorSync profile for some stupid reason. Go into System Preferences->Displays->Color and click your preferred display profile to get things back to normal.
I use Palm Desktop (ugly but featureful) for calendaring and tasks but Address Book for contacts. iCal still has no support for repeating tasks, something which absolutely boggles my mind: how else is one expected to get the bills paid every month?
Some folks use MS Entourage, too. I can't render an opinion on it, myself.
You don't need Missing Sync. Just download Apple's iSync 1.2 Palm Conduit. Combined with Palm Desktop, it works great with my Clie PEG-SJ20. Clie, Palm, whatever--the only difference, as far as the desktop machine is concerned, is the logo on the front.
I don't mean to deprecate the work of Hertzfield, but MacPaint 1.0 was written by Bill Atkinson, according to both its own "splash screen" (actually just a brief text message in the window titlebar) and this apple.com page (the original page having disappeared). QuickDraw was written by Hertzfield and Atkinson together, according to its Wikipedia entry.