Most of it I can see working - going faster/further does basically come down to adding more fuel or reducing payload.

The navigation and communication would be where you run into problems. I note that you have specified that as rock solid, unlike the other aspects. Over long distances, communication needs to be directional - you have to know exactly where the spacecraft is (perfect navigation) or it sends no data back and therefore isn't doing anything useful.

Interestingly, this issue doesn't apply to a manned spacecraft that can make unexpected changes without being in contact with Earth, but that doesn't fit too well with the redundant/disposable concept.

I wish him luck, though having implemented a significant part of git in JavaScript myself, I wonder how well the end result will work - JavaScript does not do well with either large downloads or processing binary data, and git involves a lot of both.

Javascript is getting better with at least the latter thanks to typed arrays - https://developer.mozilla.org/en-US/docs/JavaScript/Typed_ar...

That's a start, but it's more suited for smaller tasks I think, with the main benefit being that you don't have to clutter your code with type conversion. A string with custom (no) encoding does fairly well for holding the binary data as is.

It was actually memory/GC issues that got me to give up on the js implementation - it's very hard to prevent js from creating huge numbers of temporary variables, which then cause the system to freeze for several seconds while they are cleaned up.

is your implementation publicly available? I'd like to take a look at it

How much can you do without compiling? One of my current projects involves a painfully slow SharePoint system. Actually building and deploying takes forever, but most pieces of code that I need quick feedback on can be built outside the main project then integrated later, which is much easier.

When I do need a full build, I make sure it is a single step run from the command line so I can go get a coffee while it runs.

Sure, actually speeding up the build would be better, but sometimes that isn't an option.

Paid products aren't immune to unexpected changes or shutdowns - it just takes a little more money to exceed the direct revenue from customers.

All you can do is make sure you aren't completely reliant on something without viable competitors, and move on if you need to.

Typing isn't nearly as important as it may at first seem - how much code do you really type? Sometimes I might produce 10 lines of code in a day, all the effort going into knowing exactly what those 10 lines should be. Even the worst typist can beat 0.05wpm.

Typing isn't just coding. Even if you code a lot, you probably spend more time typing other things than code.

The importance of typing fast is not letting your typing slow you down.

The same applies there, albeit to a lesser extent - if typing slows you down, you might not have thought things through.

That said, I have been typing more than writing for many years and am now thoroughly incompetent with a pen.

Actually I spend a lot of time typing documenting my code, so that my though process at the time is clear.

Specific skills don't matter much, and you'll never be able to cover more than a tiny fraction of them anyway.

What really makes a difference is basic problem solving and logical reasoning. For just about any specific task google will give you some code samples, but if you can't form a consistent mental model of what the computer will do with that code, you won't be able to use it effectively.

Regular expressions are just an implementation detail.

Mostly good advice, but where do I find the "good recruiter" in #3? I've never met any good recruiters, merely unobtrusive ones.

Yeah, point taken. Not every company hires recruiters, let alone good ones.

Was there ever a good reason for using UDID anyway? The only examples I've seen are user tracking for ads (has privacy issues) or a horribly broken login system.

Anyone bothered by this is probably doing something wrong.

One use of UDID is verifying in-app purchase receipts. It's demonstrated in the sample code associated with Apple's article titled "In-App Purchase Receipt Validation on iOS".

See: https://developer.apple.com/library/ios/#releasenotes/StoreK...

Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though.

The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.

The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.

True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.

Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.