We at http://groovymag.com/ are trying to help with the recognition bit, although it does at times feel a bit like an uphill battle ;)

It'd more than an hour. The purported restrictions say "1 hour before landing". Landing = touchdown, not deboarding. It's almost always at least another 15 minutes from touchdown before you're actually *off* the plane in the terminal.

vakuona was responding to the parent post, which said "Only thing that I can see save them now is to offer a Java based API and standard J2ME runtime."

His point was that verizon lost money from him as a customer - Verizon needs to institute better training/QA for their stores. Or just make up the loss from people leaving by increasing fees for simply holding the phone in your hands.

The prob is the people in the stores are powerless. Doesn't matter what they say. You'd need to record the phone calls with the reps on the 800 number ("for quality assurance purposes") but there's no way in hell we'll see smartphones being able to, you know, *record phone calls* any time soon.

It's a bit of a catch-22, because while it's still above that magical 1% mark, you'll do everything you can to cater to those people and make sure the site works 100% for them. This gives them far less reason to upgrade in the first place. And 1% of sales volume is likely pretty darn low, compared to the extra cost of ensuring a 100% experience for IE6. For someone selling $1,000,000 a year, that's $10,000 you're catering towards, when it likely costs more than that in developer time to futz with the site and testing for IE6. For many smaller businesses, a 1% loss, in order to ensure a better experience for everyone else, is usually acceptable.

And both Frank Zammetti (posted a comment below) and Jay Garcia (the one you mentioned) have contributed pieces to JSMag about ExtJS :)

Why the switch away from Dojo to ExtJS in the first place, if you don't mind my asking? And why not move back to Dojo instead of YUI?

a "Document Operating System".

"I mean, if you're going to be some kind of start-up search engine or "semantic company" (whatever that means), shouldn't Web spidering be your core competency? If you're going to differentiate yourself in the market, how can you buy spidering as a commodity?"

Raw spidering is pretty much a commodity already. You're issuing GET requests over HTTP (for the most part). The "semantic" stuff comes in to play analyzing the results and doing interesting things with raw information you get back. If people can spend more time focused on doing the 'interesting bits' and less time on having to scale up to pull in the raw data to analyze, they'll be better off for it and more likely to be able to focus on creating something new/interesting/distinguishing.

People (generally) don't write their own web servers, nor their own TCP/IP stacks, often don't write their own session handling logic, or security code. All of these things have been commoditized. Perhaps too many people are relying on 'cloud computing' these days, but hosting and storage 'in the cloud' is where all the cool kids are playing right now (I don't necessarily agree with it, and probably wouldn't put all my eggs in that basket myself, but others are doing so). Spidering may be the next frontier to get commoditized.

Perhaps not everyone is comfortable 'partnering' with Google for everything? If someone was going to work on developing the 'next big thing', would you rather invest in something where the people had spent an inordinate amount of time building network capacity up to do drone work, or used a service like 80legs, or built the prototypes on Google's servers? Depending on the project, any of those make sense, but I'd prefer to use a service like 80legs myself. They're small enough and hungry enough they should give top notch customer service at this stage, whereas Google's not going to give you a number to call for direct service (maybe they do if you're spending loads of money, but then you're back to wise use of money).

The P2P aspect of how they're doing the spidering may be clever, but I'd rather see a more direct use of data-center resources around the globe, rather than relying on a seti-like participation model.

"chomping" is correct too. http://en.wikipedia.org/wiki/Bit_(horse)

That was my first thought too. I did get back something closer to 11 gig, not the 7 some others reported (and what Apple says on their website).

Looks like some of it has been moved in to $HOME/.grails instead of each project directly. I see webdefault.xml files (for jetty, might not be there if you don't use jetty - not sure) and standard "web.xml". Plugins are configured via XML, but there's rarely a need to touch those by hand. I've got ivy.xml files, not sure where those came from, and that's all I see *now* - I could swear there used to be a few more last year. There's still the option of wiring up Spring stuff manually, and you use XML for that, but the need for that seems to have gone down a lot from last year.

FWIW, there's still a load of XML config files (you probably already knew that!) it's just that following the convention of Grails they're automatically handled for you. There's probably fewer than an equivalently functional straight Java app, but there's still quite a few XML files - more than I care to see. Still your point about discovering fun with Groovy and Grails is well taken. They were fun enough to inspire http://groovymag.com/ (shameless plug!) :)