Just watched the video, and Martin reps are claiming the parachute system will start functioning in just a few meters. As Ellis mentioned below, this obviously must mean they're ejecting and inflating the parachute via some sort of mortar, and as such, it probably starts working almost instantly.

I wouldn't be surprised if the parachute was automatically triggered, as it's pretty simple to detect freefall acceleration or a catastrophic engine failure, although this is just my sceculation. So, in this case, human reaction time is also not a factor, which would be significant at low flight levels.

Also, that thing can fly at 1km in the air and ascend faster than a typical helicopter. It's actually more of a personal VTOL aircraft than a jetpack IMO.

Sorry, I need to correct myself. I typed "turbofan", which is not what the summary or article said. A turbofan is a type of jet, of course, but I believe these are simply using normal ducted fans. So I guess it's not actually a jet, strictly speaking.

I think it's a lot more accurate to call this a single-person VTOL aircraft than a "jetpack", but that doesn't sound nearly as sexy I guess.

It's a little sad to see people fighting so hard for the cause of ignorance... not that it's so rare, I guess. It's almost more depressing if you consider that some of them are probably sincere, instead of simply wanting either payola or publicity.

Design by committee often fails, in my experience, if you have a group of equals on the committee and no one is empowered to make the final decision, or is not willing to make the final decision when it needs to be made.

In this sort of programming environment, I'd think it would be critical to have at least one person with the authority to make a final decision on any matters of disagreement or contention - likely the senior programmer when it comes to technical issues, or the feature/product owner when it comes to decisions related to functionality. Likewise, when part of a group dynamic, members need to learn the skill of knowing which battles are important enough to fight, and when it's best to just shrug and disagree. Otherwise, nothing would ever get done.

Keep in mind that human beings are pretty good at creating a shared mental context of their conversation, and programmers would also have a lot of shared knowledge, both of the problem at hand as well as more generalized knowledge that most programmers (should) know.

For instance, if I said "We should use a proxy object here to create a streamlined interface and minimize coupling between these various systems"... how much information did that convey? If you're a programmer, that probably said a quite a bit in a very few words, because you understand a deeper meaning behind all those words.

I guess you can consider shared knowledge to be a highly effective form of compression for personally-transmitted information (spoken communication is only part of it, remember).

I'm guessing it works for solving some sorts of problems fairly well. But there are some problems I've run into that require some silent contemplation over quite a bit of time to come up with a solution. I have a hard time envisioning that working with pair programming (which I've done only in very brief amounts) or with mob programming (never tried, probably like most). There are also some problems so technically difficult that I need maximum concentration to keep everything straight while implementing or debugging it. Having a group of programmers surrounding me seems distracting to that end.

I could see how it might help in some situations... you're essentially programming while having a constant design and review meeting, so I can see how the quality of code would improve. You're unlikely to simply accept a sub-par solution, because you've got a couple other programmers to readily suggest solutions you haven't thought of yet. The fact that it improves quality but not productivity should really come as no surprise, as you're essentially multiplying the brain-power focused on a single problem, but five programmers can't necessarily solve a problem five times faster.

An interesting concept. I don't think I'd want to *always* program that way (nor pair programming), but I could see it being helpful at times. At the moment, I either work on my own projects or as a remote contract programmer, so I'm largely in the position of *having* to solve everything myself, and it's often fairly difficult to not have immediate access to other programmers for advice or assistance.

Specifically designed low-altitude parachutes are effective at a few hundred feet. No, it won't save you at extreme low altitudes and velocities, but it's certainly better than nothing. The phrase "Perfect is the enemy of the good" comes to mind.

From the article:

I wouldn't use it without a parachute either. With an emergency parachute... um.... probably. After a few other brave souls try it first.

Also, 30 minutes is waaay better than the versions we've seen previously, which could only operate for a few minutes at a time. And... I guess we're still calling it a "jetpack" even though it's just using turbofans? I guess there's no other commonly-known term to describe it?

And for bonus points, like Disney or Edison, have your old white guys being laid off train your brand new brown imported slaves.

Are companies hiring H1B's in droves or are they discriminating against brown-skinned people with accents?

Now if we stop talking about mice and start talking about people we can look at what the science has always shown. There are things called diseases of modern culture. As in indigenous people who don't eat like western cultures have low cancer and mental illness rates and no heart attacks.

Except that science has never shown that. Atherosclerosis has been found in mummies (not just from Egypt but also Peru, the southwest America, and the Aleutian Islands), and the idea that modern Inuit have low rates of heart disease was never evidence-based

Fats and proteins don't spike the blood sugar.

But protein does spike insulin.

What science actually shows is what it's always shown: a diet based around whole plant foods, high in fiber and moderate to low in fat and protein, is the most healthful for primates, including those weird bald ones.

I'm guessing "personality test" simply means you're trying to screen people out who have horrible personalities that won't work well with others. If you've had the misfortune of working with people like that before, you might understand the reasoning behind that sort of test.

I can't personally conceive of how such a test might work, short of just getting a few members of the team together to chat casually with the interviewee for a while, and even then, most antisocial people probably know how to behave properly for a short time.

And 8 of the 10 Windows vulnerabilities were related to the Adobe Type Manager Font Driver (ATMFD.DLL). I don't know how much of ATMFD was written by whom, but according to Wikipedia, "Adobe licensed to Microsoft the core code." That makes Adobe responsible for 13 of the 15 vulnerabilities, including all 9 of the most dangerous.

The Year of the Lexus Hoverboard!

Yeah, of course, not a real, practical hoverboard, but a pretty cool gimmick nonetheless.

I left Foxit behind when they started pushing crapware installs, and more critically, when it had some problems rendering some fairly basic PDFs correctly. Back to Adobe Reader for me as well.

It's like that with MS Word docs as well. The damn things are so complicated that only the original code has a prayer of rendering it correctly, and even then not always.