This whole thing isn't an issue any longer if the server containing the secret data is expecting random people to access it and implements auth with something more than cookies. Take a look at Twitter and Facebook. They both allow cross-domain requests.
janky.post will only work if the server is expecting the request (it won't allow arbitrary requests to anything on the remote server) and then, it's up to the remote site's engineers to make these endpoints secure.
I've done some interesting applications with Backbone.js over the last 2 months or so (for anyone that uses uTorrent, here's one: http://apps.bittorrent.com/ucast/ucast.btapp all in about 800 lines of code, just unzip the btapp file if you'd like to see the source). After trying other things like SproutCore, Cappuccino or Evently, I'll never go back.
I'm also a big CouchDB fan. Since backbone models are just documents, the integration with CouchDB is very minimal and you get instant serialization of user state (it really is that easy, to pimp one of my projects: https://github.com/pyronicide/backbone.couchdb.js). There are no server handlers you need to write (hell, don't forget you don't even need to run a web server, Couch'll do that for you!) and you end up with less complexity overall.
Right now, I'm just using qunit + sinon.js. I'm not super happy with it (I'd really like to get to the point where all my development is done via. writing unit tests), but so far it works. Honestly, one of the big advantages of backbone is that because of the structure it forces on your code, unit testing is easier.
Everything ends up being in a small testable chunk that you can stub out the interfaces for and test (see sinon.js, can't say enough good stuff about that). I've also got a small Backbone.sync implementation that just loads test fixtures and returns data from that, allowing me to have a db to test against that's fake and synchronous. With couchdb, all I have to do is take a DB dump of what I want to test, put it into a file in my test directory and I've got instant fixtures.
Any idea how easy or tough it is to integrate with JSTestDriver? I would like to use backbone for our projects but am finding it tough to implement TDD for Backbone controllers (for models its fine) because of the template. Through tests, I am not able to inject the DOM which is expected by the controller templates. I know this is off topic but if someone can help for the same, it will be great.
I can't recommend pivotal tracker enough. It's not a full featured bug/issue tracker like JIRA, but I think that's what I love about it (I also only really use it for projects with up to about 4/5 people on them). The interface is super easy to learn, but works very well for both bugs and features. You do have to prescribe to an agile style development cycle to get the most out of it, but alternatively, you could just leave everything in the icebox.
We use Pivotal Tracker at work and it's just awesome! I can't believe it's free, it's so good. At my last job we were using some enterprising scrum management software and it was slow, clunky, and expensive (unless you used the free version, which we didn't because heck, we've got an IT budget to spend and we need that burndown report!)
Thanks for that I was really hoping that Mythbusters had tested it.
"It was found that cell phone signals, specifically those in the 800-900 MHz range, did intefere with unshielded cockpit instrumentation. Because older aircraft with unshielded wiring can be affected, and because of the possible problems that may arise by having many airborne cell phones "seeing" multiple cell phone towers, the FCC (via enforcement through the FAA) still deems it best to err on the safe side and prohibit the use of cell phones while airborne."
So that is interesting, wonder if they suggested modern shielded planes. Also lends credence to ground interferance as the real reason for the "ban"
But that's the part I don't get; there's no "ban" at all! I can bring a bunch of phones on the plane and just not tell them about it. If they search my bags, they'll remove my 200ml of water citing "it's too dangerous" but they'll leave the cellphones alone.
That's not much of a "ban". So I still disagree that phones could interfere in any meaningful way with any aircraft's systems.
Firstly, if the TSA searches your bags and actually finds a "bunch" of cell phones, I bet that they will find an excuse to hassle you about it.
Secondly, your own example shows how shoddy this reasoning is; the TSA is not rational* about what they confiscate and what they don't -- your water isn't dangerous, and they took it, so why would you trust their judgment on cell phones?
Thirdly, the cell phone industry moves much faster than the airline security industry, so it's (vaguely, remotely) possible that some new phone released yesterday is dangerous, whereas old models aren't; the airlines wouldn't know the difference. One could say the same for almost all consumer electronics. So it would be hard to ban "bad" electronic devices and allow "OK" ones, and probably not worthwhile. Banning them all is an option, but just because it's a risk doesn't mean it's enough of a risk to be worth addressing.
*At least, they aren't rationally trying to prevent planes from being hijacked or interfered with; maybe they are doing a good job at other things, like making people feel warm fuzzies about security.
They don't pick on phones over other electronics. On every flight I've been on, they ask passengers to shut off "all portable electronic devices," including things that often don't even communicate over a network, like CD players.