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.
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.
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.
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.
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.
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.
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.
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.
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.