geoffschmidt

I'm totally there with you, and my hope with DDP 1 was to make some progress on that first step: decoupling code from data, so that a standard DDP client can connect to any DDP server and pull data out of it.

In the future, I'm super excited about investigating ideas like DDP discovery (asking a DDP server what data and methods it has) and description (having a DDP server publish metadata in some standard format that explains the semantics of the other data that it's publishing in terms of microformats). I think the main place we differ is that I think that these formats should use something more like a relational model rather than a hypermedia model, or a formal knowledge representation model like RDF. Isomorphisms exist between these models, and used properly they are all equally powerful, so really this just a design decision about what will be easiest to implement and adopt. And of course I believe that it has to be server push (websockets) rather than poll (HTTP), and that it has to support server-side joins (doing 1 query rather than N+1 queries, and taking 1 roundtrip rather than 2, to retrieve your newsfeed stories plus the comments on them.) I can't tell from your comment whether you agree with that or not, but like I said, these are two of the main things that motivate DDP.

All of that said, I think that by far the hardest part of the puzzle is the product design and federation issues. In your federated Github and HN, the technical work is the first 10%, the next 90% is finding a user experience for it that makes sense to and is ergonomic for a large number of real users, and the final 90% (really should be more like 9000%) is convincing the industry (read, creating incentives to force the industry) to cooperate with the federation and to resolve all of the political squabbles about advertising, control of the data, licensing, and so on. I mean, Google pulled out of XMPP federation -- all practical evidence suggests that keeping these federation together is wicked hard.

So that's why we're just trying to build the first 10% of that first 10%, which has a very clear use case for building rich browser apps and mobile apps -- and hoping that we will be a stepstool that others such as yourself can stand on to build the full solution that everyone dreams of.

Anyway, if you are sympathetic to this line of argument, I hope you'll check out DDP and see what interesting discovery and self-description features could be built on top of it, or suggest how its semantics could be strengthened!

Doing AV right is hard! You can devote your whole career to learning how to do AV well, and I have a ton of respect for the skills of the people that choose this path. It's a lot more than plugging in a microphone.

We do try to improve AV with every Devshop, and we have recently started to bring in AV professionals to help. But honestly, pre-1.0, I think it's way more appropriate for us to be spending our time and money on advancing the framework than on super slick video presentations. In many ways it's more like the Meteor community's time and money.

Well, all of Meteor is under a MIT license, so if we think we're going to "monetize that codebase" we're pretty stupid :) I'm not a lawyer but I think that under the MIT license there's basically nothing that we can do with the code that you can't do too. Our actual plan is to sell operational tools for larger companies that have mission-critical Meteor apps in production.

The incredible amount of work that we've put into JavaScript build tools over the last two years has all been with the aim of creating a radically easier, faster developer experience, because we know that that's incredibly powerful marketing for the rest of our crazy ideas. In other words, we did it because we thought that the UX of the existing JavaScript tooling was just too janky. Seriously, try Meteor for yourself and see what you think -- maybe you think our work sucks and that we wasted our time, but if so, I wish you would just tell me that (I would genuinely love to know) instead of reading ulterior motives into what was a labor of love and a ton of hard work.

Of course there are many rough edges and it's not done (that's why it's not 1.0 yet) but from people that have actually used it for a while, we actually get the opposite feedback, which is that they want us to go much further down this path, and that's why we continue to slave away at what is by far the least fun part of building a framework.

Speaking as the protocol designer, the eventual intention for DDP is to model reactive data set publishing in a sufficiently semantic way that it can be cached by proxies. We didn't get there in pre1 and decided to not let that block Meteor 1.0, but it is the goal for the future when we have some post-1.0 breathing room (and when the Meteor community needs it.)

The idea behind DDP is that HTTP got us three huge benefits: (1) shared tooling (I can write a caching proxy, and anyone with a website can use it); (2) interchangeable parts (your client and your server can be built with totally different languages and frameworks); and (3) easy APIs (I can describe my site's REST-y API to you in a page or two). These days, a lot of sites are moving away from REST/HTTP and toward ad-hoc, custom publishing schemes that run over websockets or a HTTP long-polling transport that is emulating websockets. Since they use these ad-hoc protocols to move around data rather than something like REST, they lose (1), (2), and (3). But all of these ad-hoc protocols are basically isomorphic to each other. DDP is an attempt to nail this kernel of data publishing functionality down semantically to the point that you can get those three benefits back.

As an aside, what's the pressure that's pushing these apps away from REST? The two big ones are:

- They cache data locally and need to keep the cache fresh (say they are apps that run in your browser and never reload the page, or they are native mobile apps), and they don't want to poll for updates. And/or,

- They need to do joins and they care about latency. (When you are loading the news feed, you want to fetch the feed stories, the comments, and the userpic URLs in one round trip, not first request the stories, and then only once you have them request the comments.)

Also, many modern apps have verbs that don't map well to REST (a RPC like transferBalance affects multiple objects and doesn't map well to the idea of updating the representation of an object identified by a URL), and many modern apps need to perform some form of latency compensation (predicting the outcome of a RPC and simulating it locally to update the client's display while waiting for the server's answer, but then reverting to the authoritative outcome chosen by the server.)

DDP attempts to address these needs and run over a stream transport like websockets, while recovering some of the benefits of standardization that made REST so successful.

Yes, if you're using DDP over sockjs instead of just over websockets (which Meteor currently does out of the box to support older browsers), you'll need to use a HTTP proxy with sticky session support.

This will be in the official docs at some point, but for now, Arunoda's blog post about this is a great starting point:

http://meteorhacks.com/load-balancing-your-meteor-app.html

Meteor version locking is in core now (as of 0.6.0), and the rest of Meteorite (fetching packages from Atmosphere) will be folded into core as part of 1.0 :)

Meteor is a lot more than an npm package. For example, if you type these four commands..

$ curl https://install.meteor.com | /bin/sh; meteor create myapp; cd myapp; meteor

you're up and running with a complete stack including MongoDB, node, the dozen-ish core packages that make up the Meteor pubsub and realtime templating stack, and the 'meteor' build tool (which can do things like compile coffeescript and less, generate source maps, minify your production code, and provide a realtime development environment where whenever you save a file your app updates in your browser.)

As for versioning, it's actually got a great way of doing that. Each of your Meteor projects is locked to a specific Meteor release version (similar to an Ubuntu release, it's a release-engineered snapshot of the Meteor core packages), which you can set with the `meteor update` command. And this has automatic `npm shrinkwrap` integration so that if you use npm packages alongside Meteor packages, everyone on your team is always running exactly the same versions of all of the code in your app. The Meteor tools automatically handle all the work of downloading any needed Meteor versions and keeping them installed side-by-side on your laptop, using the correct one for a given project, and notifying you of available updates.

Sure! The Meteor client and the Meteor server speak a protocol called DDP, which runs over websockets or HTTP long polling. Meteor clients can connect to any DDP server and vice versa. So you just need to implement a DDP server for Python.

DDP is pretty simple (just a few messages) and the spec for the 'pre1' version of the protocol is in Git: https://github.com/meteor/meteor/blob/devel/packages/livedat...

This is pretty close to version '1' of the protocol that will be locked down in Meteor 1.0: https://trello.com/c/kMkw800Z/53-official-ddp-specification

(1) CA is much better positioned to straighten out the land use issues. It needs to use the existing I-5 right of way, it needs to tunnel through some mountains, and it probably needs to eminent domain some additional bits of land for pylon bases where I-5 curves too sharply. No matter what, this is a project that has to pass the legislature in order to get built.

(2) A CA-sponsored bond issue must be by far the lowest cost way to finance a $7B infrastructure project that's amortized over 30 years.

Your idea is exactly the way the economy already works. People deposit their money in a bank, they receive an evidence of deposit in return (their bank balance), and then banks then lend the deposited money out to businesses (or individuals) that can use it. When people buy something (say with a credit card), the evidence of deposit is transferred to the seller's bank account electronically, so they don't have to handle paper certificates. It is true that we have cash (dollar bills) but these are mostly used as a convenient way to transport small amounts of money between bank accounts where it will reside (very few people keep any significant fraction of their cash as physical dollar bills.)

You're essentially proposing to open a socially conscious bank that promises to only give loans to socially conscious organizations (and presumably gives them a lower than market interest rate, at the expense of either lower interest rates to depositors, or charging depositors higher fees.) That part's reasonable. I used to keep my money in a bank that worked sort of like that. They tend to be a hard sell because they don't have a lot of ATMs, they don't pay good interest rates, they don't have super slick online banking.. all the forces that have caused consolidation in retail banking work against them. Eventually I decided that I'd use the bank that best served my banking needs, and separately donate to whatever organizations I personally wanted to support, rather than trying to couple the two and thus do both of them inefficiently.

You also propose to charge people a punitive fee if they ever withdraw their money from your bank, for example to do business with someone that doesn't have an account at your bank (which will be most people, to start with.) I don't think anyone wants to deposit their money at a bank like that. I sure don't.

If you want to get people to use your bank, I think that at the end of the day, you're going to have to actually make your bank an attractive place to keep deposits. I think it's really going to be an uphill battle to get people to opt in to these anticompetitive/protectionist provisions that keep money in your bank, because the instant they do it, their dollars become less valuable. They'd do better to donate to a charity directly.

So, your idea stinks because if you want to do this, you should just open a bank and focus on lending to organizations you like, and do everything you can to attract depositors (and imposing a tax when they give money to someone not at your bank is probably going to hurt you more than it helps, in terms of attracting depositors.) And, it turns out a lot of people have already had this idea, and they're called credit unions. There is a clean regulatory framework around them, you will have deposit insurance (the credit union equivalent of the FDIC), and you might be surprised how easy they are to start (not trivial, but easier than banks for sure.)

Only when their sexual maturity is in doubt.

Well, it's like this -- log_2 and log_10 (and natural log) differ only by a constant multiplicative factor, so they're all the same asymptotically, and it doesn't matter which one you use inside the O(). Pretty neat right?

So Rosa Parks was the bad guy?

I agree that this is an antipattern. We don't use it in Meteor. We did use it in a project that some of us wrote together several years before Meteor -- it was our first big JS project and we were heavily influenced by Crockford's _JavaScript: The Good Parts._, which appealed to our Lispy backgrounds. Our experience was that the added hassle in debugging wasn't worth the dubious benefit of locking rogue team members out of your private methods. And as this article notes, you have to go to significant lengths to preserve basic OOP conveniences such as `instanceof` and `this`.

If you're concerned about coworkers calling your private methods, the right tool is coding standards and code review. If you can't trust your coworkers to use good judgement even in the face of those things, you have bigger problem :) On the other hand, if your goal in using this pattern was to protect your private methods from bad people on the internet, you probably need to rethink your assumption that it is possible to sandbox JavaScript without interpreter-level support.

We do use (function () { ... })() in specific situations when we need to create a new scope, but this would typically only occur in framework code rather than application code (especially once the `linker` branch lands, which lets you declare specific exports and imports at the package level, and then the `meteor` asset build tool wires them up for you so that each package gets just the global environment it asked for.)

Also for now, we prefer to use prototypal inheritance directly rather than use a class library. On the latter, our perspective is that if Meteor developers want to use a class library, they should be able to pick their favorite rather than be stuck with ours.

It's sort of a microcosm of capitalism in that respect, don't you think? It's a wonder that our system works as well as it does.

Bitcoin is not exactly a mature currency. When a new merchant starts accepting Bitcoin payments it's still front page news. So I wouldn't read too much into the lack of lending infrastructure. Evaluating creditworthiness, and going after defaulters, is a lot more work than holding cash deposits or accepting cash in return for products, and those things are still big logistical challenges in Bitcoin land.

Sounds super-useful! Could you share an example or two?

If he can't make it to SF, he could also come to a Meteor meetup group in Chicago, Minneapolis, Paris, Toronto, Vancouver, New York, Zurich, Philadelphia, Boston, The Hague, Johannesburg, Portland, LA, London, Austin, or Hong Kong.

http://meteor.com/blog/2013/02/06/meteor-devshop-0-share-kno...

Meteor CEO here. miles_matthias's got it right.

We think of it like the difference between git and GitHub. git is free and open source, both the client and the server. But many people prefer to use GitHub, which puts a nice management interface on top of the server. And if you are a company and want GitHub inside your firewall, then you can write a check and download GitHub Enterprise, which is a copy of GitHub that comes as a machine image that you start on your own hardware.

Our plan is to build nice management tools for Meteor deployments, and make money primarily by selling an enterprise-ready version of those tools to companies that are large enough to need them, analogous to GitHub Enterprise.

Ultimately the big idea behind the company is to improve the developer experience of the entire application lifecycle, from writing your app, to testing it, to deploying it, to monitoring and scaling it. I think that modern frameworks need a story for all of these pieces.

If you send me enough good pull requests then I might do that!

Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install.

Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes.

- When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?)

- OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time.

- OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?)

- No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?)

There's really two separate issues here:

- Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad.

- Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust.

Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools.

Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)

There's another side though. Do you want to see pseudoscience stem cell "therapies" sold on late night infomercials as a panacea? A balance has to be struck between the number of people that could potentially be helped and the number of people that could potentially be harmed. We can debate how this balance should be struck without assuming bad faith on the part of those that disagree with us.

On the internet, when startups overpromise, misrepresent, and take risks, the worst that usually happens is that a few million people lose their data or get their embarrassing photos shared with their coworkers. In health care the consequences of an overhyped technology are far more grave.

Stress and anxiety are understandable. You legitimately don't know what's going to happen, it could be awesome or it could suck, you've got a lot invested in it, and it will affect your life and the lives of those around you. Paradoxically, I've found that acknowledging and accepting these things tends to decrease my level of stress and anxiety.

Also, commit to doing your best (sounds like you have no problems there), and then you can just remind yourself: "My best will be good enough." You may or may not succeed, but if you remember that you did your honest (and self-examined) best, then you will always be able to be comfortable with yourself.

And finally, a motto: "Clarify by action."

Also dramatically less advertising (though even today Paris doesn't have that much.)

It's explained higher up on the page:

"I mined the Stack Overflow (and related sites) data dumps to extract the social networking accounts of the top users. Each list includes only the users who have social networking links in their profile ..."

This turns out to be a key component of Clay Christensen's original theory of "disruptive technology" (before it became a buzzword.) The theory is that the disruption comes in part because existing producers ignore the new technology, since initially it is only of use to a tiny niche in the market that doesn't care about performance. The niche is left to bit players, but it turns out to provide them enough oxygen that they can invest in R&D and improve the technology, eventually to the point that it's the best choice for all but the highest-end applications.

http://www.amazon.com/Innovators-Dilemma-Revolutionary-Chang...

Why is it necessarily the case that "stars would compress into this material rather than into black holes"?

For example, why can't it be the case that there are two kinds of matter, one that can be used to build infinitely strong wire, and one that can't, with stars being made of the latter? Or why can't it be the case that the crushing process doesn't take matter through the infinitely strong configuration on the way to black hole configuration?

Meteor (the company) uses Hackpad extensively and I don't know what we'd do without it. We do almost of our systems and API design in collaborative Hackpad documents.

[meteor dev here] We actually have a great realtime test system that we use to test the framework itself. Whenever you save a file, your browser test console automatically updates to show which tests are passing and failing. It's great for TDD. We also have a script that runs a set of tests in the cloud, simultaneously on all supported browsers. I'm hoping we'll get that integrated directly into the test console eventually, so you get feedback on IE breakage in realtime. The current system's API (tinytest) is sort of janky, and before we bless something as the officially recommended testing system for 1.0 I'd like to see more experience with the framework and broader community input, which is why we've held off.

Where we are weakest is on tests that are driven by UI scripting. I was really impressed with the system we had for that at Asana and I'd like to do something similar in Meteor. But right now our priorities are opening up the package system and doing a round of server scalability work.

You're jumping to conclusions and it's insulting. I posted it because I thought it worthy of discussion. Here are some of the reasons:

1: It's gotten use, and you can look at the leaderboard to see where. I'm certainly not proud to see MIT at position #2, but I also wonder about the 99 jackets donated by students at a Roman Catholic seminary.

2: I think it is interesting to trace the author's moral development, which you can do at http://hobojacket.tk/story.html

3: Previously in history, an explicit purpose of the educational system was to develop an individual's moral sense. On HN many commenters seem to think of school as a place to learn technical skills, or as something to be skipped altogether if one is ambitious. Don't you think it's worthwhile to discuss the consequences of that attitude?