bchallenor

Others make the point about calling costs, but if you want data only (say for a tablet/laptop/mifi) an any-network roaming SIM would be very attractive. For example my current network is great in London, but has no signal at all in my hometown. It would also be handy for use on the train, where coverage on all networks is patchy.

Various countries have dividend imputation for that:

> it reduces or eliminates the tax disadvantages of distributing dividends to shareholders by only requiring them to pay the difference between the corporate rate and their marginal rate.

http://en.wikipedia.org/wiki/Dividend_imputation

Returning my Nexus 4 was a traumatic experience. It took over a month, with far too many emails and phone calls. Sadly, the customer support staff are probably trying their best, but the information and systems they have are completely inadequate.

I'm pretty sure that the 88 people [1] who want to go from "MEL to Perth UK" actually want to go the other Perth. Interestingly only 3 have signed up for "MEL to Perth AU" - perhaps you could add some heuristics to your autocomplete?

Similarly for "Auckland NZ to Christchurch UK" - people might be getting more than they bargained for there. :)

[1] http://adioso.com/following/missing_routes

To support schema evolution. Of course it's up to you to write code that can actually handle missing fields, but once you have a required field in a message, you can never remove it.

From the docs:

"You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead. Some engineers at Google have come to the conclusion that using required does more harm than good; they prefer to use only optional and repeated. However, this view is not universal."

https://developers.google.com/protocol-buffers/docs/proto

There wouldn't be much point in doing that.

Encrypted data is indistinguishable from random data, so it is incompressible. The chances of finding anything significant to deduplicate are so low that it's not worth trying.

Have you considered carrying an EPIRB too?

True, though the factory's owners (its shareholders) assume that the factory will beat the return of the market as a whole, and the rate of any loans they have. Otherwise they'd just invest in the market, e.g. via an index tracker. So for them at least the opportunity cost is a little higher.

I have also done RtK (book one). It took about 4-6 months over the course of two years (I lost my way a bit in the middle). Anki says I have done 34,000 reviews over 174 hours.

I agree that eventually the stories should be forgotten, but initially, they are significantly better than my normal memory.

In fact I am starting to forget the stories of the kanji that I am exposed to regularly. However, some of the general use characters appear pretty infrequently, and for those the stories are still invaluable. I like Greg's training wheels analogy below.

Another advantage is that the stories provide a check for characters I also know visually. So if I'm writing a character from my visual memory I might be reasonably confident that I'm writing it correctly, but if I can also remember the story then I am sure.

Of course doing RtK doesn't teach you any Japanese, but since I did it I find Japanese vocab acquisition much easier. Maybe it's like learning English when you already know Greek and Latin.

Read http://www.mrmoneymustache.com. An inspiring blog by a couple of ex-engineers.

What a nice surprise! I started using Backbone this week, and this fixes six real issues I had with it:

- collection.fetch() now correctly calls model.parse() (I patched Backbone.Collection.prototype.parse(), but their fix is nicer)

- 'add' and 'remove' events now include the index (I had to work it out from scratch with sortedIndex())

- event 'bind' is now called 'on' (sensible as _.bind is already used for partial application)

- confusion over this.el and $()-wrapping is now cleared up

- events hash can now include functions (I like to avoid reflection where possible - even in JS)

- collection.create() now fires 'add' before the server replies (this makes writing a responsive UI much easier)

The last one is quite a significant change! Luckily my app is easy to fix, as I've only spent a few days on it.

That's what (N)Hibernate calls the hilo algorithm. Compared with GUIDs, it has the advantage that IDs are somewhat sequential. (Random keys are terrible for index fragmentation.)

http://stackoverflow.com/questions/282099/whats-the-hi-lo-al...

I raised an issue on GitHub.

https://github.com/rstacruz/js2coffee/issues/81

It appears that it doesn't like CRLF. Maybe the author didn't test it on Windows. ;)

The Rust language (by Mozilla) is putting statically verifiable state machines in the type system:

http://lambda-the-ultimate.org/node/4009

It's based on Typestate, a really good 1986 paper:

http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestat...

I hope this idea catches on in other programming languages.