tmeasday

Yeah, weird (see reply to sibling). I have Philips Hue bulbs and I literally haven't replaced any of the ones I put in like 3-4 years ago.

Wow, something weird is going on in your house. I literally never change my light bulbs, I was just thinking about this the other day when I was looking at my extra bulbs and considering where to store them. It occurred to me it's been literally years since I changed a bulb, whereas in the old days it used to be a regular occurrence.

Also it's not hard to work out how much electricity you are saving. If you are worried about a couple of bucks, it won't take much usage of a 80W bulb to blow through that.

I'm pretty sure that's a false dichotomy. There are plenty of options in between.

Except the lens itself of course! Epistemological relativism is self refuting, I don't get how people can internalise the self-contradiction.

I think you're forgetting that Turnbull was the communications minister under Abbott. He's square to blame for this.

So then all candidates are tainted and you may as well not worry about it.

My point is discrimination exists no matter what. So try not to let it bother you.

Does it bother you if a male candidate gets a position that maybe there's a better qualified female candidate who wasn't considered because "maybe she wants to start a family" or some bullshit? Do you let that (potential) bias affect your judgment of whether the guy "deserved" it?

Biases exist. Meritocracy is an illusion. Deal with it.

Hmm, might stop the larger one from autoplaying. Better safe than sorry.

Hey, author here.

I don't think we have any scroll event handlers on our blog (not 100% sure as I didn't implement the theme). It's a WP site, perhaps that's the common element -- although I don't think WP ships any JS itself...

My best guess would perhaps it's animated gifs triggering a bug in the browser for some reason?

---

EDIT: animated gifs more likely.

Hey, partner here. I'm in Melbourne.

I've set up more vanilla cos here in Aus, but I'm (we're) pretty confused about all the tax implications of selling eBooks to domestic and international audiences, and my accountant doesn't seem to be much more clued in.

Any advice you can provide would be highly appreciated.

It's definitely a concern, but I think it's mitigated somewhat by the oplog-tailing approach. Writes go straight into Mongo, as usual, it's just reads from the oplog that potentially tie up resources on the webserver.

Those reads are throttled, so I think the net result of too many writes is just a choked up webserver, and slow "realtime". Potentially a future architecture moves the oplog processor onto it's own server and the effect is isolated to the realtime part.

Fair question. Obviously that recommendation was supposed to be taken alongside the other recommendations about not touching too many records, so, yeah 'SELECT *' is probably not good.

What I meant here is thinking about making your publication queries simpler when designing your data models.

For instance, sometimes using denormalization you can use a simple equality selector rather than some more complex mongo selector. Mongo makes it possible to avoid the denormalization, but it might bite you as it means Meteor can't do a bunch of short-circuits that it might otherwise do on a simpler query.

There is Objective DDP (https://github.com/boundsj/ObjectiveDDP) and a Java DDP Client (https://github.com/kutrumbo/java-ddp-client) although I haven't yet seen a finished product (i.e. a native app that talks to a Meteor app).

But it's certainly possible.

Thanks!

"Now that you're not busy" ... haha I wish! (or maybe not).

I'll put it on my todo list though, sure..

It's the first reason. There's nothing built-in to Meteor right now to help you test and although some people are starting to figure out good ways to do it as we speak, we feel like the dust hasn't really settled on the best way to do testing in Meteor.

As soon as we feel we've got a good answer for it we'll include something in the book to point people in the right direction.

Very true, and a good point. I thought it was a interesting little gotcha about the whole technique though: sometimes you will actually need to go ahead and look at whole diff to be 100% sure.

Of course the problem here is that the GP can't actually be sure that every link he wanted to fix in the final step was fixed; just that the ones that _were_ fixed were fixed right!

I don't think it's quite as bad as you make out / think.

As Geoff said, in the upcoming release, it'll be trivial for a meteor package to wrap a npm package and integrate it into the 'walled garden'. If and when a client side package manager appears that everyone is using, I'm sure they'll do the same.

So, I'd expect a situation to arise which is much like that of rails + gems; a ruby library that is not completely tied to rails is usually published as a stand-alone gem, with a X-rails gem which does the railties stuff.

Perhaps it's not as clean as it could be, but I think it's unavoidable when you consider some of meteor's design decisions (synchronous APIs being the biggest one) -- debating these is of course a separate issue.

Definitely! There are things between meteor + websockets (socketstream and derby come to mind), and depending on your project, sometimes they are going to be the best choice. Just like sometimes Rails is the best choice and sometimes Sinatra is.

I was just saying that it's a rare case that going all the way down to the metal, and using websockets alone is going to be that best choice.

On the second point, I'll won't speak for the meteor team (which I'm not a part of), but here's what Geoff Schmidt recently had to say on the matter: https://github.com/meteor/meteor/pull/516#issuecomment-12919....

Well, if you use websockets, you have to wire things together yourself. Sure, you might want to decide _exactly_ what data to send to each client, when to send it, how to propagate it between clients, how to deal with merging issues, etc at a message-by-message level, you want to get down to this level.

But there's probably a good chance that (unless you are doing something very specific) you'll just end up re-implementing the built in pub/sub mechanisms of meteor collections which usually give you exactly what you need with almost no work required.

To me, that's like asking "why use rails, why not just use HTTP?". We build on layers of abstraction.

I guess it depends on what you mean. If you mean data sent from the server -> client, then no, subscriptions[1] are a lot more powerful than simple RPC calls for data.

If you are referring to data sent from the client -> server, then yes, everything is an RPC call. But it's a bit disingenuous to say "basically meteor is just an RPC", when meteor does a lot of work to set up (and secure) the RPC calls you'll do most commonly: CRUD operations on the database.[2]

That is to say, calling `posts.insert({title: 'A new post'})` in your client side JS _does_ end up calling a method called `posts/insert`; but that method is wired up for you, including checking the allow/deny rules you've specified and tracking the user who is doing the inserting for you with no plumbing work required on your part.

I wouldn't say that's something most frameworks do.

[1] http://docs.meteor.com/#publishandsubscribe [2] http://docs.meteor.com/#collections

It's a legit project.

You are correct that there's no test suite, unfortunately support for testing is still a way down the priority list for the meteor devs: https://trello.com/board/meteor-roadmap/508721606e02bb9d5700...

I think people have had some success rolling their own testing solutions for meteor projects, but it's all very ad-hoc at the moment, I guess this is the downside of working with a pre-1.0 framework.

Regarding CS: I don't think the meteor community looks at it particularly differently to the JS community in general; some people use it, some don't.

It's supported by the framework; I've used it on a few projects but now I'm moving away from it (I find the hassles of communicating with non-CS users about bugs etc outweigh the benefits it gives me). That's totally a personal opinion though.

Well, the thing about Telescope that might not be immediately obvious is that it's realtime. Sit and watch the front page for a while and you'll see posts re-ordering as other people vote on them. Hang about in the comments page for a post and you'll see new comments queue up as people make them.

Meteor makes it easy to build such features; sure you could maybe make them happen in other more traditional frameworks, but I can assure you, it would be a _lot_ more code. We wanted to make an easy to understand app in meteor as an example to help people learn their way around the frame work.

We'll be writing more about these features and how meteor made them possible; watch this space!

I'm not sure that's entirely fair on meteor. They do provide a security layer: http://meteor.com/blog/2012/10/18/meteor-050-authentication-...

Although new apps come with the autopublish package turned on (which violates a lot of the security), any real application will have this package turned off.

Hi, thanks, we appreciate that!

Meteor does have the spiderable package (http://meteor.com/blog/2012/08/09/search-engine-optimization) which means that URLs such as http://demo.telesc.pe/posts/08d0105f-0a1c-43a1-b11a-5ba8875e... will be indexed by google.

(Actually they won't because we haven't enabled spiderable in this deployment of Telescope, but it would be a one-line change to do so).

Thanks! reported: https://github.com/SachaG/Telescope/issues/39

You're right; I'm sorry, I should have given you the benefit of the doubt and parsed the sentence that way.

It is interesting about the 'bias' of doctors towards their own experience. I guess my point is that statistically this kind of 'bias' towards the most common syndromes is a net positive for society; it's an allocation of resources thing--we don't have so many doctors that we can afford them all to be running off on weird tangents investigating possible rare diseases that aren't there...

Again, sucks if you do happen to be the one in X thousand that has the rare disease. Am I being too utilitarian?

Regarding tone: apologies; I agree it was an overly flippant comment. It was more a reaction to some of the other doctor bashing that was going on in this thread that fails to see the woods for the trees. I see now that that wasn't your intention...

Yup, that's the world of academic publishing unfortunately. A tip: often you can get a 'preprint' copy of the paper from one of the authors' websites. Probably not strictly legal, but it does happen a lot.

Doctors are never going to be perfect; if you ask me following such a heuristic is probably going to work pretty well almost all of the time. As long as the doctor isn't a dick about it (with a god complex) and is willing to accept that they may be wrong..

In reference to my first comment: Mis-diagnosing "cool, rare diseases" as the flu by definition can only happen very rarely. Coupled with the fact that people are often mis-diagnosed with rare stuff, means that your original statement that "it is far more common..." is obviously untrue.

It must be frustrating if you are the person with the rare disease. But "not looking for zebras" serves the other 99.9% of people quite well..