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.