Hacker Newsnew | comments | show | ask | jobs | submit | pyronicide's comments login

Would anyone know if there's audio/video of these lectures? I keep seeing amazing classes like this and wishing that everyone could enjoy them instead of just the local students.

-----


The reason that cross-domain requests are disallowed has to do almost entirely with cookies. The concern is that since almost everyone uses cookies for identity, it is possible (without the cross-domain barrier) for a random web page to tell the browser to go fetch all their secret data and then return it to the malicious page.

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 not done much profiling/performance (especially on older browsers) yet. My use case for the whole thing was to do a fire and forget POST to a separate domain.

Honestly, flash might be the best solution for something like you're talking about. I was just going for something with almost no dependencies that was stupidly simple.

-----


The one browser that I didn't test in, gah! Let's see what I can do about that ...

edit: It's fixed now, that's what I get for not reading the removeEventListener docs.

-----


Whoa, that was pretty quick. Thanks!

-----


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 actually ended up being surprised by how backbone changed what I do with javascript. With backbone, you can create views that are really just widgets. For example, if you have a list item, you can create a view specific to that list item. Then, all the events and state for that list item are encapsulated right there. No need to store state in the DOM, you can just fetch it from the model when it happens. This then allows you to bubble events up through the parent views to change the entire page's state. Because of the separation, you really end up having little pieces of javascript that only know about themselves and the whole picture ends up being considerably less fragile and easier to debug.

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.

-----


Could you share how you implemented unit testing your backbone controllers' javascript code?

-----


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.

Thanks, Leena

-----


I'd suggest not actually using a bug tracking system. They tend to be separate from actual planning and the fact that they're separate means that planning is harder.

Take a look at http://www.pivotaltracker.com/

The whole system is crazy simple/easy to use and it pretty much lets you do all your project management in one place.

-----


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.

-----


Pivotal Tracker is fantastic. Free, extremely easy to use, productive, and they just re-did their user interface.

-----


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!)

-----


I've been using mixpanel's platform for a couple weeks now and have been super pleased with it overall. Being able to deliver stats to my end users has been a big success.

-----


what's up? :P

-----


Totally agreed. Underscore has quickly become the one js library that I cannot live without, no matter what.

-----


Mythbusters did a great show on this problem. Here's a link to the results of the show:

http://mythbustersresults.com/episode49

-----


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.

-----


That is a foolish conclusion.

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.

-----


it's (vaguely, remotely) possible that some new phone released yesterday is dangerous,

That's no greater a possibility than for my netbook, or my wristwatch, for that matter. Why pick on phones over other electronics?

(I suppose the answer is to see your previous paragraph regarding rationality)

-----


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.

-----


Ok, so help me with this. Let's shield the airplane. Now, how useful is your cell phone?

-----


This is awsome, I was looking for something exactly like this last weekend! No more scraping for me =)

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: