Several times in a row
2,604 karma · joined March 24, 2011
My email address is geoff (symbol) geoffschmidt (symbol) com. The first symbol is '@' and the second symbol is '.'.
And a lot of the unimportant stuff I want to at least glance at, if I have a spare minute.
You'd have to be really clueless to read it and then make the same mistake that they did. For better or worse, public ridicule is an incredibly effective tool for changing behavior. It changes the behavior not just of the person who was ridiculed, but of everyone who saw it happen.
So yes, I think it is totally realistic to change people's behavior today, "by getting mad at them when they say something out of line." It's unpleasant for everyone concerned, but it works.
Your "better long-term solution" sure is "easier" for us men, but it's not easier for the women...
Also, fundamentally what you are doing is excusing sexist behavior. You're saying "these people, in some sense, aren't fully in control of their actions; it's not their fault that they didn't get the appropriate training as children; it's too hard for them to change." I think that that is a harmful idea to advance. First of all, it gives people cover when they behave inappropriately. Second, it's disempowering -- nobody wants to be thought of as a helpless case that can't change.
I couldn't disagree more. Sexism will end when we (1) educate people about what constitutes sexism, (2) stop tolerating it.
Everyone can help with (1) to some degree. Not every one is in a position to do (2), but those that can, such as the many startup founders that read HN, should.
It seems to me that in your post you are doing the opposite of both. You are arguing that we should stop talking about it, and that we should tolerate it.
If the "autopublish" package is added to your project, which it is by default, then the entire dataset is sent to the client. That's good for learning and prototyping, but isn't any good for production use. The Leaderboard example uses autopublish.
Once you app works and you're ready to lock it down and scale it up -- and only then -- you remove the autopublish package. Now, it's up to you to define what's sent to the client. Use Meteor.publish() on the server to set up different datasets that clients are allowed to subscribe to, and use Meteor.subscribe() on the client to turn on/off a particular dataset. The Todos example demonstrates this -- it retrieves just the items for the todo list you're looking at, plus the list of lists. It's just a couple of lines of code, like 5 or 10, and not tricky ones either.
This thread isn't a good place for it, but we'll get something out soon.
When you do a write, it also does a RPC to the server to ask the server to do the same write. The server can accept the request, reject it, or do something totally different. Whatever ends up happening, the client cache is patched to reflect the results.
For the business logic that needs to be secure, you put it on the server using Meteor.methods() and Meteor.call(). You still get all the Meteor features like automatic distributed page updates and latency compensation.
EDIT: sorry, didn't catch the "is/will be"
Sensitive code runs in a privileged environment: Write all of your code in JavaScript (if you want.) The user interface runs in your browser. The sensitive functions run in a privileged server environment.
In the docs, Meteor usually tries to use the word "reactive" or sometimes "automatic," thought "realtime" does seem to have slipped in in some places.
I used to work at Asana, where I worked with Luna, which is Asana's inhouse framework and is a distributed FRP system very much like a future-alien-technology version of Flapjax.
One minor quibble.. I like to think of Meteor as an "application platform" rather than a framework, because we're trying to take on some problems that web frameworks don't always tackle, like packaging and deployment. Also, we don't require you to use a particular strategy for generating HTML. For example, it makes sense to use backbone.js with Meteor, if that's your thing. At the end of the day, Meteor is about how you make all of the pieces fit together in a distributed cloud application. (For better or worse, that's what websites have morphed into, when you think about all of the APIs and services they use.)
Firebase is a realtime database that you could use with Meteor. The database we use in the Meteor video is MongoDB with Meteor's 'mongo-livedata' package, which adds some realtime glue to Mongo. But there are many potential advantages to using a database that is designed from the ground up to be realtime, and we're very excited that the smart guys at Firebase are taking this on. We predicted that this would happen eventually, but we had no idea it would be so soon.
(If you don't like the word realtime, please s/realtime/reactive/)
Interestingly, most of the core Meteor team has worked on systems that you might consider "actually" realtime: I wrote machine vision software that watches a few dozen cameras and tracks objects moving between them, Nick wrote software defined radio code that runs inside rural cell towers, Matt wrote kernel drivers for high performance IO interconnects.
Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed.
In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release.
But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database.
http://stackoverflow.com/questions/10115042/how-do-you-secur...
If you don't want it in /usr/local, you can check it out anywhere you like and just run the 'meteor' in the top directory of the checkout, and it'll work great. This is mentioned in the README/on Github, and it's how we have been developing Meteor. You can have as many copies of Meteor on your system as you like, and they can even coexist with a copy at /usr/local. So for me, I type '~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself to run the latest official release.
You can either build the binary dependencies (node, etc) yourself by running an included script, or if you do not, the first time you run meteor it will automatically fetch a prebuilt binary kit for your convenience. All of the binary dependencies are kept in a directory in the checkout and managed by meteor, meaning that each meteor install on your system can have its own version of node.
Finally, to your last point, 'meteor bundle' does exactly that :P In fact, right now on our deploy servers, we have live apps running that were deployed with a variety of historical versions of meteor, all coexisting side by side.
I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger and more complicated -- when all of the packages do not fit in a 'packages' directory, and when there are more binary dependencies than node and mongo. But I hope that this helps to persuade you that we're not totally nuts, despite how sleep deprived I was when we recorded that screencast.
If you thought this was a helpful answer, could you repost the question on Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my HN profile?) That way I could repost this answer there in case it might be helpful to other people.
And yes a second time: to package a sql database, you would ideally have a 'minisql', a client-side cache with a sql-compatible interface. It's not strictly necessary though. There's no reason a DDP[1] dataset couldn't use a different database API on the client and the server (say, sql on the server, mongo on the client), but if you did this and you wanted latency compensation, you'd have to write all of your methods twice, once against each API.
I am really excited about having sql support, but we tried really hard to defer anything that wasn't absolutely necessary for release :)
[1] DDP is the protocol that livedata speaks between the client and the server. In Meteor, the client and the server mostly keep themselves at arm's length. The client doesn't know that the server is made with Meteor, just that it speaks DDP, and vice versa.
There's a bit more in the FAQ. Our approach is based on rendering the template as a string (it doesn't require building a DOM tree on the server and then serializing it.)
Anyway, thanks much for the support :)
We couldn't go into everything in the video (it was already too long!), but the piece you're missing is Meteor.methods(). This lets you define methods, which are functions that the client can invoke on the server by calling Meteor.call(). If you choose to also ship the code for these methods to the client (it's optional) then you'll get full latency compensation like we talk about in the video. (This means that Meteor can latency-compensate arbitrarily complex functions, like "read this record, then add 2 to X if this field is false, else create a new record Y.")
In fact, every Meteor app already has an API :) Your Meteor client can connect to any other Meteor server by calling Meteor.connect(), and can then subscribe to any realtime datasets that that server is publishing, or invoke any methods available on that server. This is done with a protocol called DDP, but we could map DDP to REST fairly easily.
At this stage, we want to give people a choice and see what they do.
Reads are handled in a totally different. You explicitly define what data a given client is allowed to synchronize down to their local cache (by using Meteor.publish to define certain database queries that are available for client subscriptions.) The client can run whatever queries they want against their cache, but the only stuff there is the stuff you explicitly let them subscribe to, so it's OK.