71–80 of 350 posts
I'm developing with socketstream right now, and I love it. I hope they are all successful.
This is a very uncool way to install something: $ curl install.meteor.com | /bin/sh
I am to blame for that. Here is our thinking on it: - Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it? - You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms. Curious to hear people's thoughts :)
Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER.
Your universe is ~/.meteor. Do not even think about touching anything outside that. It's taboo.
You clearly know what you're doing otherwise, so please get this one right from the start and save yourselves a lot of headache later on (cf. npm).
Install to ~/.meteor and provide the user with a small snippet to paste to their ~/.bash_profile ("source ~/.meteor/magic.sh").
This is a very uncool way to install something: $ curl install.meteor.com | /bin/sh
Earlier quoted context omitted.
insert/update/remove are actually just "newbie helper" shortcuts on top of the underlying latency-compensated RPC mechanism (which is documented under 'Meteor.methods'.) Once the auth branch lands, you'll have two choices. One options is, you can turn off the shortcuts entirely, and write a method for each scenario where the client would be allowed to write to the database. This gives you the same security model as a…
The query-validation-only approach seems scary to me. It'd be like, in rails, relying exclusively on before_save callbacks for authorization. My gut says that would be error-prone in catastrophic way. Also, not all data is public.
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.
This is a very uncool way to install something: $ curl install.meteor.com | /bin/sh
This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going. I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.
Edit: to clarify I specifically meant a front-end tool to help me leap a level in personal development skill.
There's lots of overhead on both server and client side generating everything dynamically, especially on slow mobile clients. Testing it on fast machine on localhost creates visible delay in initial DOM update. On typical content/read-heavy pages it would make sense to always serve static pages as a fast as possible and update cache and client-DOMs on database write.
It was a few years since I was "in" with the new things happening in the web-world. But how did JavaScript come to be the new "cool" language? It got some horrible problems with object oriented stuff, some really strange bugs/features, and it's slow-ish. I liked making cool stuff with JavaScript, but compared to something like ruby isn't this a step backwards? I can see the advantages of this framework, but it still…
Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think! We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!