An account of a serious medical emergency on a transoceanic flight - <AUTHOR> https://feminem.org/2016/09/01/doctor-on-plane/ <comment><USER2> Similar experience, although less dramatic circumstances, on a Qatar flight. I was asleep, when my wife awoke my and volunteered me to address the needs of a passenger passing out in the aisle of the plane. I asked for equipment to check his vitals. Bp was on the low side so I asked he remain supine with his legs slightly elevated. There was a lady sitting next to us who criticized my every move (she felt I wasn't getting an accurate pressure because he was laying down, but I was more concerned with maintaining his pressure than having it bottom out further). The passengers were upset he was laying in the aisle. Turns out the lady next to me was a physician as well, but she never volunteered this or assisted in any way. He eventually got better and I allowed him to return to his seat. I checked on him as we landed and left the plane. Medical services came with a wheelchair to take him off. No appreciation from the crew on this, but I guess that doesn't matter at the end of the day. barring the criticism I received for how I was handling it, the situation ended well.

<comment><USER3> Its interesting that the other doctor did not volunteer this information. I did pool lifeguard training a few years ago (in the UK) and was told that as this training is at a higher level than basic first aid training I would be legally required to notify my status and presence in an emergency, and that not doing so could leave me open to prosecution. Do doctors not have any obligations such as this laid upon them?

(My lifeguard certification has expired now)

<comment><USER4> Every medical student hears horror stories where a doctor acting as a good samaritan in less than optimal conditions results in the person who was helped suing them afterwards.

<comment><USER5> In Germany, every citizen is required to give first aid, as long as he doesn't endanger himself. If you don't help, you can get sued. And the law protects first aiders, so they can't usually get sued if they do something wrong.

Source (only in German): [https://de.wikipedia.org/wiki/Erste_Hilfe#Rechtliche_Situati...](https://de.wikipedia.org/wiki/Erste_Hilfe#Rechtliche_Situation)

<comment><USER6> In the US and probably the rest of the English speaking countries, typically only medical professionals and first responders are required to render aid, but the law does protect "good samaritans" from legal culpability if they do help.

<comment><USER7> There have been recent situations here in Canada where very ill people were literally on the doorstep of the ER asking for help but were refused any help.

In nearly all the situations the staff in the building told the sick people outside to call 911 to get transported inside two feet inside the door.

The hospital workers and by that I mean nurses and doctors were unwilling to help even though the people outside were very ill.

<comment><USER8> So the problem was that those people couldn't get inside the ER by themselves and the nurses and doctors refused to move them?

I ask because I once walked my relative into an ER and they were attended to, no problem.

<comment><USER7> Yes sometimes it's a person literally on the doorstep of the ER in front of the doors. One time a news report said the person was in a passenger seat of a car. But usually right there at the ER in some state of distress.

I can understand some concerns of staff but to flat out refuse seems to go against the ethics of being in the medical trade.

I also suspect it's government bureaucracy and union rules, paperwork trumps life I guess.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> In contrast to this story, my wife (a doctor) did attend to an ailing passenger on a transoceanic flight. The attendants were more than helpful, and my wife expressed surprise at how well stocked their medical kit was (drugs etc).

After the flight, the airline gave her some duty free goodies on the spot, and a few days later, a one-way business class ticket (I guess to make up for the fact that she sat with this ailing passenger for most of that transoceanic flight).

The article didn't mention what airline. We were flying Singapore Airlines. Service does make a difference.

<comment><USER10> I usually fly with Singapore Airlines. The service is always exceptional. One time (out of about a dozen trips) the flight was cancelled due to engine issues. After explaining I had a conference to attend and the next flight would mean missing one out of three days, they booked me an United ticket and offered me some points as an apology for the "inferior service". It was.

<comment><USER11> I'm not sure what the conditions are, but the airlines are required to do that by law under certain circumstances. Maybe someone more knowledgable could chime in?

<comment><USER12> For flights to/from EU member countries, Regulation 261/2004 is applicable. I guess Rule 240 would be the US equivalent.

It can be tricky to get the airline to comply when they deny responsibility. So there are intermediary agencies that do the claim paperwork (and take the legal actions if necessary), taking a small percentage of the reward only if successful.

With the help of an intermediary, I successfully invoked Regulation 261/2004 against KLM after a flight was cancelled due to mechanical failure. The correct reward was ultimately transferred approximately one year after the original flight.

[https://www.airhelp.com/en/know-your-rights](https://www.airhelp.com/en/know- your-rights)

<comment><USER13> I got €400 compensation from Ukraine International Airways under the EU regulations after simply sending them a letter requesting it, after a 30 hour delay.

</comment></comment></comment></comment></comment><comment><USER14> As an emergency physician, the first thing I would say if I ever met the doc would be 'well done' for volunteering - it's a hard thing to do. I'm also very glad that it seems the patient did ok.

However, in these kind of situations, I don't think it's in the patient's best interests to avoid diversion. The algorithm should be: 1) sick vs not sick - this person was clearly sick (when an ER docs say someone is 'sick', they usually mean there is a non-trivial probability that they could die in the next 24 hours) 2) _Could_ a delay in critical care treatment lead to a worse outcome for the patient? If so, I would argue that you _have_ to advise diversion to the nearest airport with the required standard of medical care.

That means that it might be ok to advise taking one hour to get to a major city, rather than taking 10 minutes to land at a rural airfield with a tiny hospital nearby - that's a judgement call. The only reason not to divert that I can think of is the cost to the airline, and passenger inconvenience: both of those looks like really bad reasons if the guys gets worse again and dies on the plane, when they might easily have been saved if they had diverted to a nearer airport + hospital.

I agree with another comment regarding the difficulty of IV's, particularly in shocked patient. Ideally, the airline kits would stock intra-osseous needles (needles with a screw that are screwed into the bone of the shin or upper arm using an electric dril). It sounds brutal,but is probably not much more painful than an IV, and takes seconds to do with training. The crew could be trained to use them as part of their first-aid training - the training takes less than an hour, and it would probably make more difference to patient outcome than having adrenaline on board would.

I totally agree about speaking to the pilot in person when you have a critically ill patient - they know (or can figure out) flight times to the various possible diversion airports, you (probably) know better what kind of care the patient needs, and the chances of finding that kind of care in a given city.

<comment><USER15> In a flight that long that you arent that far into, landing early for a diversion requires dumping fuel (for up to an hour on larger aircraft) or risking the lives of the other passengers because the plane is over maximum landing weight.

So it very much is a case by case analysis of balancing the urgency for one passenger with the damage to the environment (dumped fuel) + risk to other passengers for a heavy landing + risks to other passengers from imposing a delay (e.g. Another passenger flying to a surgery).

<comment><USER16> I just read the wiki about fuel dumping. Based on that it seems less likely that most of the passenger flights have fuel dumping capabilities. Nice read though.

<comment><USER17> You can always dump it the hard way... fly slow, with the aircraft in a high drag configuration (e.g. flaps out, possibly gear down as well if the speeds allow it) and lots of throttle.

</comment></comment></comment></comment><comment><USER18> With regards to the kit which was not aboard the plane, I have a few quick questions from anyone in the know.

Missing were:

\- Aspirin

\- Nitroglycerin

\- Masks

\- Fluid cleanup kits

\- Airways

I'm assuming the latter three are one-time-use. I'm assuming the former two have expiration dates. Does anyone have info on how often these items might be used aboard flights and/or actually reach their expiration dates?

I'm asking specifically to see how much money is saved by not stocking up and simply assuming that the resulting lawsuits and fines are cheaper than keeping kit stocked. I simply can't attribute this kind of neglect to human error. Someone has to have done the math on this.

<comment><USER19> I doubt this is the result of any conscious optimization process. If it were, it would have been turned into a profit center - eg aspirin billed at $100/pill to the passenger who "requested" it. Who wouldn't want to get in on the hospitals' racket?

<comment><USER20> IIRC, passengers don't get to request anything. The kit stays closed, except for medical professionals. For good reasons - handing out meds likely entails liabilities, and no airline wants that.

<comment><USER19> That's why I put "request" in quotes. The patient is unable to request anything; the doctor is doing it on their behalf.

</comment></comment></comment></comment><comment><USER21> Interesting discussion on the medical particulars on /r/medicine:

[https://www.reddit.com/r/medicine/comments/50q4fa/yes_there_...](https://www.reddit.com/r/medicine/comments/50q4fa/yes_there_is_a_doctor_on_the_plane_what_i_learned/)

<comment><USER22> An incredible anecdote about a different incident from that thread:

> I'm going to share this story passed on to me by an anesthesiologist. He was > on a trip from Canada to to Europe to visit family. He doesn't enjoy flying > very much, even less so without anyone he knows to keep him distracted. So > he purposefully got a late flight so he could sleep through it. Before > boarding he took a few sleeping pills and downed a shot. He's an > anesthesiologist, please don't try this at home. He boarded the plane almost > last, did up his seat belt, and went nearly straight to sleep. Somewhere > over the ocean he was half awake, in a lovely daze of drugs when he heard > over the PA. "If there is a doctor on board the plane can they please > identify themselves to the flight crew." He thinks about it for a minute, > debating what to do and hoping someone else will say something before he has > to. Finally he feels like he has no choice. He hits the call button on his > seat arm and shortly after, a flight attendant comes to his row. He explains > he's a Doctor and he'd like to help if possible. The flight attendant looks > at him and says, "Sir, we called the Doctor for you, We've been unable to > wake you for the past two hours, and we had to re-seat the passenger beside > you because you were drooling on them."

<comment><USER23> Anesthesiologists are definitely a different breed. That approach (a few sleeping pills and a shot) definitely jives with my encounters with a few of them. Epic.

<comment><USER24> When I fly commercial, I fly Delta.

Once, on an SD to NYC red eye in which I take a prescription sleeping pill, the person behind me took the same one and two shots. Scared me but I guess not fatal for him.

</comment></comment></comment></comment><comment><USER25> My wife ( a doctor ) had to attend to a patient who had a medical episode on Singapore Airways (might have been the a Sydney to Singapore or a Singapore to London flight ). According to her, things went well, the air crew were professional and helpful, equipment was available.

There was another doctor on the flight who volunteered his help. The two doctors liased and decided that my wife's training and skills were more relevant to the situation.

My wife was thanked and given symbolic remuneration ( which she will probably never bother to cash in ). She felt valued and will probably be willing to help again if in a similar situation with Singapore Airlines.

</comment><comment><USER26> Always been curious about what occurs "behind the scenes" in situations like this. Strange how airlines (and the flight attendants!) aren't held more accountable. Would have assumed the FAA would want to look into any in-flight medical emergency.

<comment><USER27> I'm going to guess the FAA is, like a bunch of other regulatory agencies, struggling to meet its obligations with the insufficient funds funneled into it.

<comment><USER28> This article was linked on HN last fall I believe: [http://www.vanityfair.com/news/2015/11/airplane- maintenance-...](http://www.vanityfair.com/news/2015/11/airplane-maintenance- disturbing-truth) Basically the airlines are outsourcing maintenance to places like El Salvador, Mexico, and China. The FAA has very little capacity for providing the same level of oversight previously conducted in US-based maintenance facilities. Scary.

<comment><USER27> Yikes. Horrifying stuff. If you've ever read the book "Poorly Made in China" it's kind of frightening to imagine the same techniques being applied to airplane maintenance.

</comment></comment></comment></comment><comment><USER29> I had a good experience on American Airlines. Volunteered when the announcement was made and had flight attendants that were attentive, helpful, and appreciative of my help. I didn't ask for anything but they thanked me as I left the plane - to my suprise, a couple of days later I got an email saying I was credited 25k points on my frequent flier account. I was quite far away from my seat and didn't realize they kept track of who I was. Was very pleasantly suprised and thought things went well.

</comment><comment><USER30> My friend (who is an ER Doctor) had a medical emergency (man had a stroke) on her flight from Pittsburg to Miami when she came to visit my family a few months ago. She actually told me afterwards that she thought that the bag was extremely well stocked and that she had the ability to perform whatever she needed. They used the Airphone to validate her medical license, gave her the med bag, and told her that if she needed anything to drink, to just call.

I've had similar experiences on US Airways (Pre-American); I'm a paramedic and someone had an MI -- they airphoned me to a doctor on the ground and he and I diagnosed the patient together, and he gave me orders to push drugs.

On my friend's flight, the Flight Attendant gave her many many small bottles of bourbon to say "Thank you" and American Airlines gave her 25,000 bonus miles as a "thanks," and they upgraded me to first class for my trip home as a way to say thanks for me.

</comment><comment><USER31> "Don't expect so much as a thank you from the airline."

Lufthansa at least has a formal program to identify doctors between their passengers: [http://www.lufthansa.com/us/en/Doctor-on- board](http://www.lufthansa.com/us/en/Doctor-on-board)

</comment><comment><USER32> I'd like to know what airline this was so I can never fly them.

1) This obviously physically incapable person was sitting in exit row initially

2) The F/A of negative utility (the physician probably should have escalated to the pilot, or at least the purser.) That has to be a combination of training and personal incompetence. (Actually, she sounds like the lead flight attendant, which means she should just be fired.)

3) The medical kit. wtf.

Ah -- appears to be Delta, which I'd never fly on a 17h international flight anyway.

<comment><USER33> The only way for the stewardess to check if a customer can sit in the exit row is to ask, "Are you willing and able to help passengers in the event of an emergency?" If the customer has no obvious outward appearance that might cause an issue, there's no way to know. The person in question in the exit row had a syncopal episode; syncope is defined on Wikipedia as, "Syncope, also known as fainting, is defined as a short loss of consciousness and muscle strength, characterized by a fast onset, short duration, and spontaneous recovery." Having diabetes doesn't disqualify you from being an in exit row.

Your other critiques are warranted; the lead FA shouldn't have acted the way the story portrays her to, and the medical kit was woefully understocked.

As an aside, do you think that because it's Delta it makes it worse? Why would American or United or Southwest or Allegiant or Silver or any other airline be intrinsically better? This was a lapse in judgement for not having the medical kit stocked, possibly a large one, but one particular organization isn't necessarily worse than any other.

<comment><USER32> The training lapses and other personnel issues which put a flight attendant in the lead role on a top international route (so, one of their most senior/experienced; likely 50+ years old and with 20-30 years in the job...international routes are pretty highly coveted) are an independent issue from the stocking issue, and do come down on the airline as well.

</comment></comment></comment><comment><USER34> Experience varies - I got very sick on a short haul flight with a low-cost airline in Europe. There was no doctor on board, but the emergency services at the airport came to help as soon as we landed. They determined I can't be moved from the airplane, and that I needed an ambulance to take me to the hospital; and nobody in the crew had any problem waiting for over 2 hours for the ambulance to arrive, even turning on the airplane engines to keep the heat up for me, burning heaven knows how much fuel, and serving the airport emergency staff with water and snacks.

Totally unexpected for a budget airline, but highly appreciated. Kudos on this one, Wizz !

</comment><comment><USER35> I really want to know what was going on in the one flight attendant's head. I mean, I'd actually like to hear it from her. It's possible that she's actually a horrible, soulless bureaucrat by nature, but I'd like to think that something else--fatigue, life circumstances--was messing with her and causing her to make really stupid decisions just then.

<comment><USER36> That latter assumption, save with the stress of the situation rather than "something else", is pretty much encapsulated in the physician's choice of "decompensated" to describe her. That's an interesting word! I'm glad I had cause to look it up.

</comment></comment><comment><USER37> Delta is either incompetent when it comes to preparation, or maybe the FAA has no actual way to force compliance with its rules so things like this get ignored. No matter what the rules are on an airline there is no excuse for putting people's lives secondary to them.

</comment><comment><USER38> Given that this was a 17 hour flight I would bet that this was probably the jnb to atl flight (Johannesburg to Atlanta). I fly that route frequently and this does not surprise me.

<comment><USER39> More _longest flights_ here [https://en.wikipedia.org/wiki/Non- stop_flight#Longest_flight...](https://en.wikipedia.org/wiki/Non- stop_flight#Longest_flights)

</comment></comment><comment><USER40> Flying to Australia on Delta isn't advised in any circumstance. I know they're cheaper than Qantas or Air New Zealand but you get what you pay for. Just don't do it.

<comment><USER41> I've given up trying to save money when flying. There's a list of airlines I trust, and I buy at whatever price their tickets are. The trip is either worth that much, or not worth going at all.

<comment><USER42> I'm curious--which do you find good (and bad!)?

<comment><USER41> I'm in Australia, so my good list is Qantas, Emirates and Singapore Airlines for any flight longer then about 2 hours.

</comment></comment></comment></comment><comment><USER43> I'm writing this 2 hours into a 14.5 hour flight from Shanghai to New York [0], and I'd just like to thank all physicians everywhere who have answered the ding.

[0] [https://flightaware.com/live/flight/UAL87](https://flightaware.com/live/flight/UAL87)

<comment><USER44> I'm not sure EWR counts as New York ;-)

</comment></comment><comment><USER45> I'm curious what the worst profession to hear when they ask "is there an x on board" is. Sure, "is there a doctor on board" is scary but usually ends fine.

"Is there a herpetologist on board" could get interesting, a la Snakes on a Plane.

"Is there an electrical engineer on board" would be scary, and "is there a computer scientist on board" would be downright terrifying.

Maybe "is there an infectious disease specialist"?

<comment><USER46> "Is there a pilot on board ?"

<comment><USER47> That actually happened fairly recently with a United Airlines 737:

[http://www.af.mil/News/ArticleDisplay/tabid/223/Article/4851...](http://www.af.mil/News/ArticleDisplay/tabid/223/Article/485155/af- pilot-helps-in-airline-emergency.aspx)

<comment> nommm-nommm > "are there any non-revenue pilots on board, please ring your call button."

May be a stupid question but what is a "non-revenue" pilot?

<comment><USER48> A pilot flying as a passenger to get to another flight they're scheduled to work, or who's taking advantage of an employee benefit (free/cheap flights). Why they would use language that excludes a military pilot or someone from a different airline altogether, I don't know.

Might just be an industry-insider code phrase to keep from alarming the passengers with the obvious request ("Uh, does anyone onboard know how to fly a Boeing 737?")

</comment></comment></comment></comment></comment><comment><USER49> What if the flight attendant did cause serious injury or death? Who would be liable?

<comment><USER50> In the US, I might guess the airline could be held civilly liable for negligence or wrongful death.

Not sure about the jurisdictional issues given that it was an international flight.

Postscript: [https://en.wikipedia.org/wiki/Wrongful_death_claim](https://en.wikipedia.org/wiki/Wrongful_death_claim)

</comment></comment><comment><USER51> In 2015, I was on flight EY23 that was first stranded on the the tarmac in Abu Dhabi because of fog for 13 hours and then diverted to Vienna because a passenger had a heart attack inflight. So a short 7 hour flight turned into 30 hours of horror. ([http://www.thenational.ae/uae/elderly-passenger-dies-on- boar...](http://www.thenational.ae/uae/elderly-passenger-dies-on-board- delayed-etihad-flight))

It seems that some airlines have a very strict protocol. There were at least 4 doctors on board but they were not allowed to help the crew with CPR or help much more than with checking the blood pressure.

Interesting enough, the crew was always connected to a company that has emergency-medicine specialists on the ground, so the crew became their remote hands.

</comment><comment><USER52> > The AED indicated a normal cardiac rhythm.

That's not something AEDs can do... An AED can tell you whether or not the patient is in one of two very specific rhythms or not. If the heart is in ventricular fibrillation or ventricular tachycardia, the AED will advise a shock is necessary, otherwise it will report "no shock advised". There are all sorts of nasty cardiac rhythms that an AED will no shock, and there is way to differentiate that.

<comment><USER35> There's a thread on the r/medicine discussion where someone asserts that some AEDs with a monitoring display can be manipulated to get at least some indication of the cardiac rhythm. I'm definitely not qualified to say if they're correct. [https://www.reddit.com/r/medicine/comments/50q4fa/yes_there_...](https://www.reddit.com/r/medicine/comments/50q4fa/yes_there_is_a_doctor_on_the_plane_what_i_learned/d76f2g2)

</comment></comment><comment><USER53> Should he have been allowed to sit in an exit row with all that going on? I mean they knew he had these conditions before hand.

<comment><USER54> The requirements are the ability to understand English and lift 50 pounds. No lifting required for a modern widebody anyway. Open the door and get out, that's your only job when you're sitting in the exit row.

<comment><USER13> Or not open the door -- for instance, if there is water or fire on the other side.

Hence needing to understand English.

</comment></comment></comment><comment> nommm-nommm Doctors are great. Always going above and beyond the call of duty.

When I was side swiped by an SUV in front of a shopping plaza a doctor was eating dinner in the red lobster inside the plaza. Upon hearing the sound of a car crash she left her dinner and ran to the scene to render aid if needed. Thankfully there were no injuries.

</comment><comment><USER55> Watching the side discussion(s) going on between clinicians, it's surprising to see how much disagreement/debate there is about equipment and procedures for dealing with medical emergencies on flights. I don't know why, but I took for granted that it would be a bit less controversial.

<comment><USER56> That's why we published the article. To help push consistency on flights, not to flame this particular airline. All experiences are variable.

</comment></comment><comment><USER57> I think I´m able to give some perspective and tips here. I'm commercial pilot flying long haul and I´ve had some medical incidents during my flights, including a recent suicidal lady cutting her wrists while arriving to JFK airport in NY, or a possible heart attack while in the middle of the Sahara. Also my wife is a doctor who had to help in 3 flights already.

If you are a physician:

-The cabin crew MUST help you in all the things you require, that is:

           ·Providing food, liquids, blankets (for free of course).

           ·Providing the mandatory medical kit (that can only be opened by qualified persons never by the crew on their own).

           ·move the passenger wherever you find appropriate (galley, the aisle, laying in several seats, etc...).

           ·Don't accept any excuse regarding the medical kit, some pursers are willing to avoid the paperwork involved after opening it (this happened to my wife in an Easy Jet flight, unfortunately I was in another row taking care of the kids and didn't know about it till the end of the flight). It must be fully stocked when opened (usually they are closed with a lock), if it's not the company was breaking the regulations. The medical kit is a no go item (it must be present and in perfect conditions for a flight to begin).

           ·Request the cabin crew to keep other passengers away. People loves a good show, and is able of disgusting behaviour (like taking photos of a semi-nude patient to "share", looking over the doctor's shoulder, etc..)

           ·Most cabin crew are super professional and will help to the best of their capabilities, but you can always find an idiot. Don't let them intimidate you.

-The pilots are waiting for the instructions of the experts. From the first moment we know there is a medical emergency, we are planing for a diversion to the nearest airport, usually we'll listen to their opinion regarding the need of an immediate hospitalization of the passenger. Although the captain has the last word, no pilot I know is willing to risk avoiding the recommendations of a doctor and face police charges for letting a passenger die for not following instructions.

-What I mean is if it's clear to you that it's a heart attack for example, and the patient needs an hospital, tell the pilot ASAP. We are flying at 8 Nautical Miles per minute, and 10-20 minutes flying away from an airport can mean up to an hour more than necessary till you are in the ground. We take the decision based on the instruction of the doctors and nurses onboard.

-That said, be careful to ask what city is the captain willing to land at, and what kind of medical facilities it has. If you are flying over the sea or desert, just expect up to 3-4 hours till able to land in a city with a good enough Hospital. I had a discussion with a captain cause he wanted to land in Tamanrasset, a small city in the middle of the Algerian Sahara. We had a passenger with a possible heart attack, and he wanted to land there. I told him that we needed 45 minutes to land, and then wait at 3am till we were able to disembark, an ambulance to arrive and the patient be carried to the local Hospital, that as you may imagine is less than stellar. The purser just confirmed my suspicions, as he just had the exact same case. The patient took more than 3 hours to arrive to the Tamanrasset hospital, and there was nothing there to treat him of his heart attack. So a private flight was called from Italy to evacuate him. It was much simpler and safe to wait till Malaga in Spain, just 2 and a half hours of flight away with a medialized ambulance waiting for you at the parking.

-The FAA list of mandatory medical kit onboard [http://www.faa.gov/documentLibrary/media/Advisory_Circular/A...](http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC121-33B.pdf)

-You also can find that the passenger has no need of immediate hospitalization, but needs medical help once landed. The crew is able to call emergency teams to be ready once the doors open (EMTs and police)

-Some companies have a remote medical service available by radio or satellite phone, they are there to help with the diagnosis and treatment if necessary. But they are not infallible and they could recommend you to land in an airport that has a unsuitable Hospital(it has happened). Right now I'm not aware of any international list with the medical facilities available close to big airports.

-Just a recommendation, IANAL but if unfortunately a passenger dies in flight, I would not declare the decease (we are talking strictly medical causes, no aggressions, killings, etc..), keep trying to reanimate, let the EMT take care of the patient once you've landed and they come onboard. Depending the country a declared decease onboard means a judicial investigation, police reports, etc... that will surely take all day once you land (or more).

-Most usual medical emergencies onboard are faints, suffered by people with previous medical conditions. Also people drink too much or take some kind of drugs to endure the fear of flying. Also some kind of digestive problems and heart attacks happen but are less common than faints (based on my personal and friends anecdote)

</comment><comment><USER58> The specific airline protocols makes all the difference... which isn't specified in the article. Also something as simple as all the medication being in a foreign language can be a stumblimg block on an international flight.

<comment><USER59> Don't all international pilots speak English as a requirement for talking with air traffic control? I would assume that if English is standard for pilots it would also be standard for emergency equipment (in addition to any other languages)

<comment><USER60> I just hope that the "English speakers" on planes are better than the ones nominally fulfilling the same requirement on merchant vessels.

</comment></comment></comment><comment><USER61> I've been through a similar experience that unfortunately ended up quite badly. Here's my account, I hope it helps the discussion.

I was on a 2 hour flight, we had left maybe 15 minutes before when the passenger sitting right in front of me started feeling unwell. He was travelling alone, so the passenger sitting next to him notified the flight attendant. The flight attendant asked whether he had a history of diabetes, but he was in such pain that he could barely articulate a word. He would only say "it hurts". Believing it was an episode of hypoglycemic shock (not sure based on what, but well, IANAD), the flight attendant brought him a glass of soda and, maybe five minutes later, seeing no improvement, shouted the usual "is there a doctor on board?" question. There was indeed a doctor on board (two, actually), who immediately proceeded to examine the person (he even had a stethoscope). He asked for the emergency kit as well, which proved to be quite minimal. As the flight attendant debriefed the doctor (who at this point, still believing the thesis of hypoglycemic shock, tried to measure the heart rate in parallel), the patient collapsed. It was then clear to everyone that he was experiencing cardiac arrest. The doctor quickly put together, with his other colleague, a small group of people that manage to lay the person down on the aisle floor. In the meantime, the pilot was informed of the situation and diverted the plane to the closest airport en route. By then, at least 20 minutes had passed since the start of episode. CPR was at first successful, but the patient lost his senses again after a few minutes. A second attempt at CPR proved unsuccessful. We landed maybe 30 minutes after the pilot got to know about it. The ground medical team hopelessly tried reanimation with a defibrillator (there was none on board, BTW), nothing. It was pretty sad, especially because I have the feeling that if that person had been on the ground he would have almost for sure survived (IANAD, once again, so, it's just a feeling).

Anyway, things that went awfully wrong and are a danger to airline passengers:

* As I've said before the first aid kit was pretty basic and, according to the doctors, lacked some essential material; * Most commercial planes aren't equipped with a defibrillator. They're not mandatory, at least not in Europe. * Airline crews know nothing about first-aid. They're just not prepared. They cannot recognize the simplest symptoms of a heart-attack. * They clearly didn't know what the first aid kit had or hadn't. They couldn't name the contents. To be fair, the crew was french-speaking while the doctor was not, so maybe they just didn't know the names of things in English. Still, crews on international flights are supposed to have a good level of English. * Most flight attendants behave like robots in stressful situations. They have such a respect for protocol and rules that they will be reluctant to break them even if that means saving a life. For instance, as the doctors were applying the last round of CPR, they considered improvising a tracheotomy using a pen (desperate measure, but who knows whether it would have worked?) By then the plane had started descending and was maybe 10 minutes away from landing. As the doctors asked for a pen, the crew remained still in their seats.

Bottom line: if I ever have a heart attack (which I hope I won't), I'd better not be on a plane.

<comment><USER62> > because I have the feeling that if that person had been on the ground he > would have almost for sure survived (IANAD, once again, so, it's just a > feeling).

Sadly, most people who need CPR will die.

        How successful is resuscitation through CPR?

        Diagnosis                      Success Rate for CPR
        Head injury                    7.2%
        Acute renal failure            2.7%
        Survival after 24 hours        9.2%
        Survival to hospital discharge 8.3%

(That's from a Google instant answer).

[https://www.resus.org.uk/faqs/faqs-cpr/](https://www.resus.org.uk/faqs/faqs- cpr/)

> 9\. How many people survive a cardiac arrest?

> In the UK fewer than 10% of all the people in whom a resuscitation attempt > is made outside hospital survive. Improving this figure is a major priority > for the RC (UK), the Department of Health, ambulance services and voluntary > aid organisations.

It's a bit of a problem when films and tv shows depict CPR as almost always being successful.

<comment><USER61> Well, I guess if an ambulance manages to reach you quickly chances increase? I don't know. Anyway, I guess they do increase dramatically if there's a defibrillator available, right? At least that's what this suggests:

[http://www.health.harvard.edu/press_releases/aed- cpr](http://www.health.harvard.edu/press_releases/aed-cpr)

<comment><USER63> Ventricular fibrilation, (vfib) "an electrical disorder of the heart", is among the _most_ survivable conditions, _if_ there's a defibrilator available which can be applied _within five minutes_.

The problem is entirely within the heart's signalling, it's not a blockage, obstruction, aneurism, or other blood-vessel defect. And the treatment isn't counterindicated for most other possible similar conditions.

Short answer: rapid appropriate response can result in total recovery, but it's very dependent on the underlying etiology.

<comment><USER64> The prognosis depends on the circumstances leading to the vfib. If it is a response to a sudden 100% blockage in the left anterior descending coronary artery, that is a widowmaker. No amount of defib will "fix" that until the blockage is cleared, and there is only a window of a very few minutes to clear it by going in surgically, or a hail mary measure to dissolve it fast.

If the vfib is "just" a result of chemical imbalance or a less major blockage, the outlook with vfib is much better, and it has even been known to spontaneously self-clear.

<comment><USER63> Again: electrical problem, 100% resolvable in virtually all cases.

An arterial blockage != an electrical problem.

</comment></comment></comment></comment></comment></comment><comment><USER65> Along with not stocking medical equipment, didn't Delta's data center just go down?

<comment><USER63> You're being dinged for this as I write, but that's an interesting observation and a sign of failure-to-manage-complexity on Delta's part.

Though information-system-related service failures are generally increasing among carriers, if I'm recalling the coverage of Delta's outage correctly.

Still remains a good flag to raise.

</comment></comment><comment><USER66> Interesting story and I can partially confirm. I have responded to a few on- flight emergencies on international flights and experience varies according to the airline.

Lufthansa has a _really_ great kit to deal with agitated passengers, but nothing to deal with pain. Air Canada's kit is pretty worthless. Most airlines fall in between.

That being said, I find the doctor's requirement a bit unrealistic.

Airways ? Common, good luck placing an airway in the cramped flight conditions. A BVM [1] would be more useful.

IVs ... Completely useless, too. First, unless you have a good nurse on board, you wont be able to open up a good vein. Second, you cannot expect airways companies to store enough of IV fluids to make a difference either way. Third, fluids don't save lives unless you have other medications coming in the next few minutes.

The lack of nitro might be a good thing too. Rarely useful, and most likely to result in the passenger passing out/dying than helping anyone.

<comment><USER67> What an odd reply. I have placed airways in helicopters and Piper twin-engine aircraft that were serving as air ambulances. Those are far more cramped than a commercial airliner. Control of the airway can make all the difference when things go bad in a hurry.

IV fluids are critical in dehydration--no drugs to follow.

Oh. I wrote the foregoing and then I re-read the part about "a good nurse...open up a good vein" and I realized you are a troll with no medical experience or qualifications. Good one.

<comment><USER52> > IV fluids are critical in dehydration--no drugs to follow.

If someone was able to walk on a plane, it's unlikely they are severely dehydrated... Plenty of other reasons to carry fluids though.

<comment><USER47> Actually, being at 30,000+ feet the air is extremely dry. Getting severely dehydrated during the flight is quite possible. More so if alcohol is involved.

</comment></comment></comment></comment><comment><USER68> What a sad, disheartening tale.

<comment><USER69> Well, the patient survived, the plane got to destination, I'd call it a shitty situation that ended well.

<comment><USER68> True. Still makes me sad and angry when incompetent people interfere with competent people working to save lives.

</comment></comment></comment><comment><USER70> Of course OP will not be able to get his emergency kit through security check... :(

<comment> nommm-nommm The author of this article is a woman.

</comment></comment><comment><USER71> I am sure there are horror stories for every airline so it seems unfair to gang up on Delta.

Actually, no. That isn't what I meant. I flew Delta a month ago and won't be doing so again. Free TV shows and new planes don't compensate for being late or having unfriendly staff members. Never mind this tale...

</comment><comment><USER72> After reading the article I am very angry at that flight attendant.

</comment><comment><USER73> what do they do (with the body) if someone dies on a long haul flight and it's still many many hours to land

<comment><USER74> [https://www.theguardian.com/business/2004/may/11/theairlinei...](https://www.theguardian.com/business/2004/may/11/theairlineindustry.travelnews)

</comment></comment><comment><USER75> I really hope to see a follow-up story of the FAA giving Delta a serious scolding.

</comment><comment><USER76> On a tangent, not all doctors are suitable for emergency work. I used to work with a paediatric neurologist, who was excellent in her field and a respected specialist, and she told the story of the call going out on a plane for a man who was having a heart attack. She hesitated about it - she hadn't "done hearts" since medical school twenty years earlier. Just as she was about to volunteer, however, another doctor put his hand up... and he was a cardiologist.

<comment><USER77> If it were me unconscious on the floor, I'd take a pediatric neurologist that "hasn't done hearts" for 20 years over a flight attendant with 8 hours of "first aid" training.

<comment><USER78> Heck - I'd settle even for a vet... any day...

<comment><USER79> I fear the day I have to call upon my experience birthing livestock to help deliver a human baby.

</comment></comment></comment></comment><comment><USER80> Why was this post renamed?

</comment><comment><USER81> Oh, yeah. Delta again...</comment>


Nowadays, You're Hiring People to Think - <AUTHOR> http://blog.idonethis.com/post/49856263563/nowadays-youre-hiring-people-to-think

<comment><USER2> When you're hiring people based on their ability to sell, you are hiring them to sell. When you're hiring people based on how much they pretend to love your company, you're hiring them to lick your boots. When you're hiring people based on how much you like them, you are paying them to be your friend. These probably account for a lot more real-life hiring than we want to think.

<comment><USER3> Actually, your comment is more valuable than the article itself.

</comment></comment><comment><USER4> Great quote: "When everyone's rowing together toward the same objective, it's extremely powerful."</comment>


Ask HN: Fixed Point Programming References? - <AUTHOR>

Does anyone know any good books or tutorials for fixed-point programming? Something that would be suitable for a beginner, but also cover more advanced subjects. Thanks! <comment><USER2> This is very focused on the basics of fixed-point arithmetic, but it's been helpful to me in the past when working through fixed-point filter design and related topics.

<http://www.digitalsignallabs.com/fp.pdf>

<comment><AUTHOR> Thank you. This looks very helpful.</comment></comment>


Why I Don't Use React Router - <AUTHOR> http://jkk.github.io/dependencies-your-problem <comment><USER2> Justin I think you are conflating a couple issues here:

      1). OSS critiques should be more polite

      2). People are stupid for not doing due diligence

First, I agree criticism should be constructive. Yet there is nothing wrong with 100 people saying here they don't like React Router and in fact such feedback is crucial for the authors and the community. Maybe you agree; but ironically the tone of your post seemed have a bit of the scorn and derision that you are asking people to avoid.

Secondly, it's already obvious people are responsible for their own projects. The motivation for stating the obvious seems to be to emphasize people should seek to blame themselves before criticizing others. Wrong. These things are orthogonal - Regardless of one's due diligence, it's perfectly acceptable, indeed beneficial, to critique OSS, when done in a productive way.

<comment><AUTHOR> Yeah maybe. To me it feels like many in the community complain and shirk responsibility, and some stern words were needed to counterbalance that position. If the community wants stability in its projects, it needs to learn what it takes to achieve that.

<comment><AUTHOR> Further thoughts: choosing an unstable library and then criticizing it for being unstable seems silly. There are two sides: library authors need to value things like careful design, real world testing, and backwards compatibility. Library consumers need to advocate for the same things, plus learn how to identify risk (semver isn't going to save you), and take ownership of their choices.

<comment><USER3> > Further thoughts: choosing an unstable library and then criticizing it for > being unstable seems silly.

If so many people (apparently) missed the "expect this to be unstable" bit, I wonder if it's just a question of not being signaled effectively enough on Router's home page. Which I can understand since no developer actually expects, let's say, their v3 to actually be completely revamped into a v4. If they knew ahead of time, they'd presumably just have chosen the v4 design.

I guess it's kind of catch-22. Maybe the right thing here is to explicitly say "we currently fully _expect_ this to be stable for the foreseeable future, but cannot predict the future, and _are_ prepared to break everything if a better design is discovered"?

EDIT: I suppose another way to alleviate the problems would be to pledge support for the previous version for a period of time... but no developer working in their spare time really wants to do that. (For very understandable reasons.)

</comment></comment></comment></comment><comment><USER4> If you're looking to jump ship and your projects use Redux, you might find [https://github.com/FormidableLabs/redux-little- router](https://github.com/FormidableLabs/redux-little-router) to be a nice alternative. RRv4 still hoards URL state within a component, while Little Router just puts it in the store. This makes deriving most of your app from URL state a reality.

Check out [https://formidable.com/blog/2016/07/11/let-the-url-do-the- ta...](https://formidable.com/blog/2016/07/11/let-the-url-do-the-talking- part-1-the-pain-of-react-router-in-redux/) for more on how we differentiate from the RR philosophy.

<comment><USER5> There's also Navigo, a minimal router - [https://github.com/krasimir/navigo](https://github.com/krasimir/navigo)

</comment></comment><comment> brian-armstrong It's great to someone express this point. Though it's hard to beat the convenience of dropping someone else's library into your codebase, each new dependency adds more security surface area and bloat to your application. I wish people considered this balance more carefully.

In general I think a littlw NIH is a good thing. Even if there exists a library that does what you want, it might also include much more that you don't need, and perhaps the kernel of what you want fits into a small function you can write and vet yourself.

<comment><USER6> An idea of open source is that it's very likely that your own implementation is buggier, slower, and more poorly specified than the existing state of the art open source implementation.

[https://en.wikipedia.org/wiki/Wisdom_of_the_crowd](https://en.wikipedia.org/wiki/Wisdom_of_the_crowd) [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

<comment><USER7> Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities?

I'm dealing with a bunch of people now who did something like that. At the time they made these decisions they might have had good reasons, but now they're doing other stuff and the custom things they wrote are a huge liability.

Don't write it unless you intend to own it.

<comment><USER8> _Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities?_

If someone was able to produce better code in some way before, despite any OSS alternatives available at the time, why would anyone assume they could not also maintain and develop that code more effectively than the same OSS community and projects in the future? That makes no sense.

A lot of developers seem to make dubious assumptions today about the quality of something they could import compared to the quality of what they could build in-house. There's little reason or evidence to support a lot of those assumptions, but people continue to make them regardless, because hype and inexperience are things.

If you're talking about a huge OSS project with many contributors, quite a few experts involved, well-established infrastructure and funding, and so on, then sure, it's a tough thing to beat. I couldn't set up and maintain a new operating system with the same capabilities as something like Debian or FreeBSD, and neither could any other small team.

But most OSS isn't like that. Lots of OSS projects have only a single main developer, or maybe a small team of contributors, and those people may or may not be as skilled, experienced, dedicated or simply available as your in-house team. Lots of OSS projects effectively get abandoned, sometimes even well- known ones with lots of contributors, major commercial backing and a large user base. Lots of OSS projects are highly unstable, and if you depend on one that needs constant updates to keep it working, that's an overhead of its own. There is precious little evidence that OSS quality is better _in general_ than something a good team could have built in-house.

And even if none of those things were true, your own in-house development would still be focussed on your specific needs and priorities, instead of trying to be a generic tool with potentially a lot of functionality (and risk) you don't need, and potentially being steered in a future development direction than doesn't meet your needs as effectively.

 _Don 't write it unless you intend to own it._

The flip side of that is that if you do want to own it, writing it in-house may well be a better option.

Obviously there has to be a balance, and reinventing the wheel (or a sports car) for every project isn't necessarily a good use of time and resources. Bringing in a good external tool or library that solves a problem for your project effectively can be a huge win, particularly if it's in an area that isn't a core part of your own project.

However, I believe the current culture in some parts of our industry is _crazily_ biased towards bringing in external libraries to do every little thing. That is a very dangerous trend that we must challenge, because we're writing an awful lot of awful software as a result.

<comment><USER9> True, but Javascript libraries tend to be pretty small and deal with well- known concepts. Many experienced dev's have seen a router 10x by the time they've come to React-Router, and the entirety of the source code can be read in a single day.

If you both (a) have experience and (b) have read and understood the entirety of a library, then you are in the best position to claim that you can do it better in house.

The prevelance of libraries doing the same thing in Javascript shows that alot of people have different ideas, and due to culture decide to open source it instead of keeping it in-house.

Other communities do the reverse. There are probably a million homebaked Java frameworks that will never see the light of day because people in Java land don't think that MVC is so extra ordinary that they need to release their in- house needs specialized framework.

<comment><USER10> One of the weaknesses of Javascript is its absolutely terrible standard library. In comparison to languages with solid, comprehensive, "batteries- included" standard libraries, you spend a lot of time re-implementing basic functionality. Or you import jQuery, or LoDash, or underscore, or use pieces of Ember or Angular, or React, etc, etc. Or some bastard abomination of all of those.

<comment><USER6> I'd argue that's a strength. Note how scala is modularizing its standard lib in Dotty, and TypeScript is doing that same for stdlib typings.

Standard libs are great, but they need to be modular. If they're modular then they are versioned separately from the language, and at that point there's no difference between a well specified and maintained lib (eg lodash) and a stdlib.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I recently started working seriously with node.js (I've tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for.

I found a package on npm that sounded like it did everything I wanted (plus a few extra things, but I figured I could ignore those). It took longer than I expected to install...so, I did a little digging. It had installed over 53,000 files, and the resulting directory was 110 MB in size!

I was absolutely flabbergasted. I couldn't believe installing one package, for something seemingly simple, could balloon up that large. I won't name names, as I did a little more poking around, and realized that _most_ npm installations pull in thousands of files via automatic dependency resolution, though this one was a particularly egregious example. I've gotten to where I only install stuff via npm when I'm on a free connection; I normally work on mobile broadband, which is very expensive (and adds up to almost $300/month even before I started playing with npm).

Now, to be fair, it was pulling in a web framework...maybe Express or Hapi, I don't remember which, and all of _its_ dependencies, so it was actually a lot more than just the login module. The kind of annoying bit was I already had a global installation of both of those frameworks from following tutorials, but it still seemed to insist on pulling in its own preferred versions of stuff, and putting them into the project directory.

I come from the Perl world, where if you don't spend at least half your time looking for and evaluating libraries _before_ you start writing code, you're not being very productive. I'm, frankly, overwhelmed by how big and unfiltered the npm ecosystem is. I've found myself relieved to start tinkering with more "all in one" libraries and frameworks, because I don't have the time or knowledge to evaluate libs on my own. I ordinarily prefer a more a la carte approach, where you just pull in what you need, and so big libraries and frameworks don't fit that. But, I can't make sense out of the ecosystem without some guidance. There are over 70,000 npm packages! Curation really has turned out to be one of the big problems in computer science.

<comment><USER12> > I've gotten to where I only install stuff via npm when I'm on a free > connection; I normally work on mobile broadband, which is very expensive

You could always use this:

[https://www.npmjs.com/package/npm-proxy- cache](https://www.npmjs.com/package/npm-proxy-cache)

It caches the package listings _and_ the packages that you download. It will act as a pass through that with a limited TTL on the cache, but there is an option to fallback to the cache if you can't connect to upstream.

Granted, you have to have already installed something for it to work as an offline cache.

Also, part of the problem with _all_ those files is that npm allows packages to installed pinned dependency versions. If package-a requires lodash 2.x and package-b requires lodash 3.x, then _both_ will be installed within the respective package's directory. For example let's dive into the node_modules/ in one of my projects.

      $ ls node_modules/**/lodash.js
      node_modules/cordova-lib/node_modules/lodash/chain/lodash.js
      node_modules/findup-sync/node_modules/lodash/dist/lodash.js
      node_modules/findup-sync/node_modules/lodash/lodash.js
      node_modules/globule/node_modules/lodash/dist/lodash.js
      node_modules/grunt-contrib-less/node_modules/lodash/dist/lodash.js
      node_modules/grunt-contrib-less/node_modules/lodash/lodash.js
      node_modules/grunt-contrib-watch/node_modules/lodash/dist/lodash.js
      node_modules/grunt-contrib-watch/node_modules/lodash/lodash.js
      node_modules/grunt-curl/node_modules/lodash/dist/lodash.js
      node_modules/grunt-curl/node_modules/lodash/lodash.js
      node_modules/grunt-legacy-log-utils/node_modules/lodash/dist/lodash.js
      node_modules/grunt-legacy-log-utils/node_modules/lodash/lodash.js
      node_modules/grunt-legacy-log/node_modules/lodash/dist/lodash.js
      node_modules/grunt-legacy-log/node_modules/lodash/lodash.js
      node_modules/grunt-legacy-util/node_modules/lodash/lodash.js
      node_modules/grunt-ng-constant/node_modules/lodash/dist/lodash.js
      node_modules/grunt-ng-constant/node_modules/lodash/lodash.js
      node_modules/grunt-protractor-runner/node_modules/lodash/lodash.js
      node_modules/grunt/node_modules/lodash/lodash.js
      node_modules/jshint/node_modules/lodash/chain/lodash.js
      node_modules/lodash/chain/lodash.js
      node_modules/phantomjs-prebuilt/node_modules/lodash/lodash.js
      node_modules/preprocess/node_modules/lodash/lodash.js
      node_modules/protractor/node_modules/lodash/lodash.js

That's 24 copies of lodash.js installed that could _all_ be a unique version of lodash used only by said module.

<comment><USER13> You're being unfair. You're obviously using npm 2.x, we've since moved to 3 for a very long time now where the dependency tree is flattened and this issue is avoided.

<comment><USER14> It's better but it's still an issue when multiple version of a module are needed.

</comment></comment></comment></comment><comment><USER15> I really need to get my blog up and running so that I can write about things like this.

My view is that dependencies are someone else's solution to my problem of technical debt.

I'd be a straight-up liar if I claimed to be proud of every line of code I've written, either for an employer or for myself. Sometimes you just have to hammer a square peg into a round hole and be done with it because deadlines. Or lazy. Or boredom. Or whatever this project is going nowhere anyway, so wtf? Hack the shit out of it.

I always tell myself I'm going to get back to that later and clean it up, but I often don't because, well, moar deadlines.

Dependency updates--particularly breaking ones--are things I love to hear about. Dependency updates give me an excuse, both professionally and for my side projects, to revisit stuff that I knew was janky and crappy and broke when I wrote it, but have since come to accept.

Security updates are absolute gold in this game of not wanting to suck but still having to meet deadlines.

"Sorry boss, but there's a vulnerability in lib x. We have to update. But it's breaking. So now we have to refactor. Two weeks, at least. Maybe more."

I just got rid of a crap-ton of bad code while I was updating for that dependency. Oops.

<comment><USER16> I didn't get my blog up and running until I a) started keeping a journal on 750words.com and b) started writing in a spiral-bound notebook every spare half-hour.

Those two habits and [https://blot.im](https://blot.im) made blogging nigh- effortless. Like dandruff, I get it for free.

<comment><USER15> Oh my problem isn't that at all. I have no problem writing endless amounts of crap that no one will ever read. It's just that I really care about my writing, and I want it to have a perfect home. So I'm constantly writing and rewriting blog engines.

In this case, the perfect is the enemy of no one. A blog engine is the one side-project that I don't just hack. It's my one and only place for writing pure, elegant code.

And I won't let myself write at length again on someone else's platform until I get this exactly right.

Everyone wins: I don't clutter the internet with inane crap; you aren't tempted to read it.

If I ever decide to start publishing my writing, the best part of it will be the code that presents it.

<comment><USER17> I was(am?) in the same boat as you. I don't like using other platforms because they don't do exactly what I want. I go through the same decision points while trying to maintain a todo list. I guess that is the drawback of being a developer, you know you can do better(for your usecase) job of developing a great application and eventually, writing a blog or maintaining a todo list becomes an excercise in yak shaving ([http://www.dailymotion.com/video/x2est2c_yak- shaving_fun](http://www.dailymotion.com/video/x2est2c_yak-shaving_fun) ).

I am trying to get over this habit. Any advice/suggestions would be appreciated.

</comment></comment></comment></comment><comment><USER18> As the person who wrote the top comment in the thread that you link to, I will admit: You are right for the most part. The choice to use an unproven library is my fault as it was my choice and it is also my responsibility to deal with the consequences and costs of the instability. This is why I will be removing React Router from my project as soon as I can find a stable and suitable replacement.

Recognizing the responsibility for your own actions does not preclude you from being frustrated and at times outright angry at the outcomes of those actions. In this case I (wrongly) assumed that after a 1.0 release the library would be relatively stable and have been repeatedly duped into believing that this time the major version release would be the stable one. I don't really see anywhere that people were issuing an outcry for V4, so I am still confused as to why it was so urgent to release it. It wasn't perfect but it was fine. Unfortunately in my frustration and confusion I chose to write a very strongly worded comment that apparently some people did not like.

> To be clear: developers that release libraries and then iterate the API in > public do not deserve personal scorn for doing so

I have never gotten the impression that react-router was someone's personal library, rather it is a community project that is maintained by notable members of the javascript community and it is my belief that delivering half- baked stuff to the people who counted on them, and who they led to believe could count on them, is not a fair thing to do. I don't believe it is unreasonable to be frustrated with fickle leadership from people who stepped up to lead the project. If they can't deal with the criticism or don't have the time/effort/inclination/whatever to lead in a way that is agreeable to most of the community then perhaps someone else could lead. When projects have thousands of stars on github, making rapid successions of breaking changes throws all of those people for a loop.

If you do in fact view the repo as your personal project and want to make huge changes all the time, like every 6 months, I don't think that the version with thousands of stars is really the place to do that. Why not just do it on your own where it isn't going to affect so many people.

Note: Neither this, nor my original comment should be taken as personal attacks on the maintainers although I am aware that both are probably over stated. I'm sure they are all extremely talented developers and kind people.

<comment><AUTHOR> Thanks for the thoughtful reply! I don't have a problem with strong opinions and harsh words when warranted, with the understanding that we're all learning.

What I wrote wasn't entirely in response to the HN thread. Similar thoughts about the JS community have been brewing for a while and the discussion prompted me to speak my mind.

</comment></comment><comment><USER19> We use React Router on our project. Looks like 4.0 does break pretty much everything.

My thoughts on the upgrade are pretty much:

\- Do we actually need to upgrade? Old react router works fine.

\- If we do need to upgrade - how long will it take? If it's just a few hours to shift some code around, maybe it's not that bad. Especially if it's moving to a cleaner more "react" API.

At the end of the day, we could write our own routing class, or another. We'll probably stick with react-router though - but save the upgrade for a day where we've got nothing else to do, or if an engineer has some free time.

<comment><USER20> > but save the upgrade for a day where we've got nothing else to do, or if an > engineer has some free time.

Or when you stumble on a show-stopping bug right before a deadline, that is only fixed in supported newer versions.

<comment><USER21> Is that more or less likely with an older version of something like React Router, or a fairly new release?

</comment></comment></comment><comment><USER22> I'm reminded of [https://medium.freecodecamp.com/you-might-not-need-react- rou...](https://medium.freecodecamp.com/you-might-not-need-react- router-38673620f3d#.6i54dhtjb) which discusses how to write your own such functionality from scratch. I often find that before adopting third party code you really have to consider it and perhaps even leave it out and feel the pain before accepting that it's necessary and adopting it. And even once you do, you should be open to maintaining or replacing it. There's a cost to roll- your-own though, you might need to write additional documentation. For routing though, it's usually one function and easy enough to grok on its own.

</comment><comment><USER23> Don't get it. It's FOSS. npm install the version you want. A new version released you don't like? Keep using the old version. Don't like the old version? Write your own. Fork it. It's free and awesome global collaboration!

</comment><comment><USER24> I might be missing something (after reading the article twice) but the author says nothing about why he doesn't use React Router...

The only mention I can find is "But the API smelled funny to me, and had not settled, so I continued to wait" that hints that the API is changing and looks weird. But other than that, there is no constructive criticism here.

I'm all for being able to write freely about software we find bad, but without any concrete examples or even pointers to what is bad, I don't think this article have any merit (except that it's good to make sure you understand the dependencies you have).

<comment><AUTHOR> It looked like a risky dependency, simple as that. Despite the HN title, the point of the article was not to talk about React Router.

EDIT: Additionally, I'm not saying React Router is bad per se, just that it's not fully baked. I'm glad to see people working on the problem. I look forward to leveraging the fruits of their labor in the future (in fact, I already do - I use the history library on which RR is built).

<comment><USER24> I still feel that you're not giving reasons of _why_ it's a risky dependency or fully baked. And probably we/you should rename the title if it doesn't convey the article body...

Not that I am defending or even using React Router myself, I'm just saying that it's usually better for everyone if the feedback is better explained than just "It's bad" or "It's risky to use".

</comment></comment></comment><comment><USER25> If anyone is wondering what leads to a Not Invented Here mindset, this probably would be a good example of it. Sure, it's not the fault of the open source library author that you depended on their work. However, when OSS fails to deliver or we criticize others for counting on it, we only discourage the dependability of OSS and push others away from the community. If we care about the continued adoption and growth of OSS then we'll need to have higher standards as well.

</comment><comment><USER20> This is a very important dimension to consider when making technical decisions. I've never been able to find an easy way to assess this risk, beyond hearsay and word-of-mouth.

Is anyone aware of an easier way to assess these longer-term risks of a piece of technology? Things like API stability, community strength and responsiveness, backwards compatibility, upgrade paths, etc.

<comment><USER26> A large margin of safety / margin for error / margin for refactoring is the correct way to deal with uncertainty of any kind.

Humans are very poor at reasoning about low probability events that have serious consequences, i.e. large earthquakes with very long return periods.

For this reason, it's difficult to assess the 'risk' of external code because risk management processes don't work very well when high uncertainty is involved.

If you decide to use external code that has a high degree of uncertainty, just make sure to have a generous allowance of time/money/effort for future problems.

</comment></comment><comment><USER27> Yep, this is a thing I push with my team all the time. Always vet your deps. In the long run is is WAY worth it. In the short run the cost is rather minimal unless you have devs that cannot actually deliver on the needs the dependency covers.

<comment><USER28> > unless you have devs that cannot actually deliver on the needs the > dependency covers.

You say this off-handedly like its not a big deal. No single person or company understands all the dependencies from the app all the way down to the electricity. That's the real reason we use dependencies - for things that aren't core to our business, that we don't want to have to understand.

<comment><USER27> I guess I just assumed everyone understands that no team will have the ability to cover all your needs. So you actually need to judge when your team cant deliver, then pick the dependency to pull in.

</comment></comment></comment><comment><USER28> I just wanted to say that the clojure ecosystem is littered with the carcases of half baked libraries. Including some of my own. Its not a JS problem, its the beauty of open source & low friction sharing.

<comment><AUTHOR> You're not wrong. But it feels worse in JS. In both cases lib authors would do well to set proper expectations - if your lib is half baked, be up front about it.

</comment></comment><comment><USER29> I generally agree. I've been using RR for a while, and I'm not the biggest fan of their APIs. Nothing wrong with it, it just doesn't do what I want it to do; or rather... It does too much stuff, most of which I don't use. Just my opinion.

With that being said, they claim you'll be able to migrate slowly to v4, so hopefully it's not so bad. If they just broke backwards compatibility without a migration strategy, I'd certainly feel much more frustrated. I went with RR largely because it's widely used. I also don't think it's an unreasonable expectation for a widely used library to provide a migration strategy. Not that they're under any obligation to do so, of course.

My personal bar for adding dependencies is asking myself: would I feel comfortable debugging and fixing this? I recognize that it's not a free ride.

</comment><comment><USER30> That's why they call it angular 2. It's finally out and ready to be used. Works really well with routers. Although you don't get the constant updating but you do get codeless directives that are really easy to understand.

</comment><comment><USER31> Every ecosystem is full of "half-baked" libraries. JS has more as the ecosystem is bigger and the barrier to entry is very low. It's the nature of open source, it's also the nature of open source to evaluate dependencies.</comment>


Stock and portfolio tracker: beta coming this month - <AUTHOR> http://wealthtrack.io/ <comment><AUTHOR> User friendly and helpful stock and portfolio tracker in your phone. We plan to integrate brokers inside the app, so you'll be able to trade & track no matter what brokerage company you use. Any suggestions are highly appreciated.</comment>


Even more readable code without if-else - <AUTHOR> https://blog.frankel.ch/even-more-readable-code-without-if-else/ <comment><USER2> I think when you have a mapping of keys to values you really need to have an understanding of what keys are possible (so you don't have an exception accessing the map).

Java enum classes work well for enumerating those, so I end up creating those. These work great so if I use the enum in an if-else sequence the compiler knows if I covered all possible values.

For mappings I instead add a constructor to my enum class so that I can setup the mapping as an instance variable.</comment>


Two stars will merge in 2022 and explode into red fury - <AUTHOR> http://www.astronomy.com/news/2017/01/2022-red-nova <comment><USER2> It's already happened.</comment>


Startup Quote: Ben Huh, Founder, Cheezburger Network - <AUTHOR> http://startupquote.com/post/8195288306

<comment><AUTHOR> We tell ourselves we're here to be flexible and to be nimble, and not necessarily to stick to a master plan.

\- Ben Huh (@benhuh)

<http://startupquote.com/post/8195288306></comment>


Celebrating the Open Container Initiative Image Specification - <AUTHOR> https://coreos.com/blog/oci-image-specification.html <comment><USER2> CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes.

The future of containers just keeps getting brighter and brighter.

<comment><USER3> Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

<comment><USER4> Not necessarily. You need a platform which supports Linux syscalls, but you don't need Linux per se. Unlike VMs, containers sit above the kernel so you're tied to its interface but not its implementation. For example, see Solaris' LX Branded Zones.

<comment><USER5> At Joyent, our Triton cloud stack is built on illumos (nee Solaris) LX branded zones. We also have a Docker-compatible remote API, so not only can you run unmodified Linux binaries in containers, you can do so using the regular Docker client CLI!

</comment></comment></comment></comment><comment><USER6> Wait, they don't use hashes? Why???

        Image ID
            Each layer is given an ID upon its creation. It is     represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be  globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptographic hash of image contents as the result is considered indistinguishable from random. The choice is left up to implementors.

<comment><USER7> Maybe don't paste into a horizontal scrollbox so that you may see the whole thing?

It says:

>an image ID may be derived as a cryptographic hash of image contents

<comment><USER8> Using the crypto hash is something that we should probably fix up and enforce. Could you file a bug?

We just started the project last week and imported the original Docker v2.2, which this text is from, a few days ago. So, there is language that will change and improve before the initial v0.1.0 release.

</comment></comment></comment><comment><USER9> I thought that's what AppC was supposed to be? Does that mean AppC is moribund?

<comment><USER8> No, appc isn't moribund; the appc community continues to maintain the spec[1][2]. Our hope is that the best parts of the appc will be added into the OCI for a shared industry standard. And today I am optimistic the OCI will do that.

The OCI membership includes important parties in the ecosystem from container engine implementers to public providers with container registries: Google, Microsoft, Amazon, Docker, CoreOS, Red Hat, and many others. This means that we have good a organizational setup to get a single industry standard. It is worth the additional effort to obtain that goal for the industry.

tl;dr appc is a source of inspiration for the OCI work and will continue to be maintained and available in rkt, Quay, and others. We have a good shot at an industry standard for container images. And we want to make that successful even if it requires some initial duplicated effort.

[1] [https://github.com/opencontainers/image- spec#faq](https://github.com/opencontainers/image-spec#faq)

[2] [https://coreos.com/blog/making-sense-of- standards.html](https://coreos.com/blog/making-sense-of-standards.html)

(CTO of CoreOS, OCI Technical Oversight Board member)

<comment><USER10> Your first link says this:

>>Q: What happens to AppC or Docker Image Formats?

>>A: Existing formats can continue to be a proving ground for technologies, as needed...

Sounds pretty moribund to me. It exists only if it wants to be a proving ground, "as needed".

<comment><USER11> That depends on what happens with OCI.

</comment></comment></comment></comment><comment><USER12> If only Blue Origin & SpaceX can behave this way too...

</comment><comment><USER12> Weren't containers supposed to solve the whole "one interface for everything" nonsense? Now we have a standard interface for the standard interface?

<comment><USER13> This is a community standard for how image artifacts should look. Right now, everyone is building systems against the Docker image specification which is problematic because Docker can and should be able to modify and extend it however they please. By agreeing on a common image spec, support for features can be more consistently available as they appear while Docker and others can extend and innovate for customers that want those specific features.

As an comparative example, we have common CSS specs which provide consistent support for most features as they are included, but Chrome, Mozilla, and WebKit are still able to experiment with new features.</comment></comment>


EPA's proposed new rule would allow it to ignore the best available science - <AUTHOR> https://blogs.scientificamerican.com/observations/trumps-epa-puts-our-health-at-risk/ <comment><USER2> Here is the actual document for anyone curious:

[https://www.federalregister.gov/documents/2018/04/30/2018-09...](https://www.federalregister.gov/documents/2018/04/30/2018-09078/strengthening- transparency-in-regulatory-science)

I think it sounds great. Reproducability and verifiability are extremely import in scientific research. Unlike what this article and some people here claim, it does make provisions for protecting the privacy of users. I also don't see anything hinting that it will affect past studies retroactively.

My only complaint is that it targets the EPA specifically, which is pretty suspicious with the current political situation. It would be great if this affected all studies which receive public funding.

<comment><USER3> The burden seems to be flipped here. You can't release a medical product until you have reproducible and verifiable results proving your product is safe and effective. When it comes to the environment you can release something until it's proven that it's not safe and effective. They're increasing the burden under the nomenclature of science, when in reality it's a cost/benefit between a company's profits and the quality of life of everyone.

I don't mean to sound anti-corprate, but environmental regulations only exist because companies externalize costs onto society and this increases the burden for balancing exposing that cost.

</comment></comment><comment><USER4> Have you technical geniuses figured out that lawyers can write restrictions in a way that sounds reasonable (to get them to pass) and then go on to enforce policy in quite a different way, much later ? Is it not obvious that 'environmental protection' costs money and may prevent some company from making more money ? The US EPA is a number-one target for decades, for these reasons. Many US lawyers are paid very, very well to represent the interests of their commercial employers, which likely does not include any consideration of actual long-term harm.

<comment><USER5> So it sounds like you're saying the new policy is reasonable but may be abused?

If so I don't disagree.

I disagree with this article stating that raw data needs to be kept secret. It's pure bullshit and anti-science.

</comment></comment><comment><USER6> searching the page for the word "rule" hits 13 occurrences. The only real "meat" if you can call it that surrounding what that rule is was this: Next week (July 17), EPA will hold its only public hearing on the proposed rule called "Strengthening Transparency in Regulatory Science."

As far as I can see that's the only immediate information this article bothered to speak about the rule itself. Anybody see a summary on this rule to share with the crowd? Or did I miss something?

<comment><USER7> From the article:

EPA is proposing to eliminate consideration of scientific studies unless the raw study data are made publicly available — possibly including participants' personal, confidential, and private information — _data that may be subject to legal, ethical, and human subject research protections_.

This requirement would _eliminate human health studies that use integral medical, lifestyle, and geographic data, as well as studies that include confidential business information, such as information from studies conducted by industry to demonstrate safety of a pesticide or other toxic chemical_. It could also eliminate consideration of _older studies for which data are no longer available or accessible_ , even if the data have been reanalyzed and the studies have been validated, replicated, reproduced, and undergone rigorous and independent peer review.

Far from using the best available science for EPA decision-making, the proposal would severely limit the studies and scientific evidence the agency would use to fulfill is statutory mission to protect human health and the environment. This is not a new idea. It is the result of a decades-long campaign to undercut reliance on groundbreaking research...

<comment><USER5> Instead of quoting the article, how about we quote the actual proposed regulation?

 _The proposed regulation provides that when EPA develops regulations, including regulations for which the public is likely to bear the cost of compliance, with regard to those scientific studies that are pivotal to the action being taken, EPA should ensure that the data underlying those are publicly available in a manner sufficient for independent validation._ [1]

Seem eminently reasonable to me. And seems aligned with the "open science" movement to me.

And in terms of privacy...

 _EPA believes that concerns about access to confidential or private information can, in many cases, be addressed through the application of solutions commonly in use across some parts of the Federal government. Nothing in the proposed rule compels the disclosure of any confidential or private information in a manner that violates applicable legal and ethical protections._

[1] [https://www.federalregister.gov/documents/2018/04/30/2018-09...](https://www.federalregister.gov/documents/2018/04/30/2018-09078/strengthening- transparency-in-regulatory-science)

<comment><USER8> > Nothing in the proposed rule compels the disclosure

This is blatant disingenuousness. What they are saying is "you need not disclose private information, but we won't use your study if you don't".

<comment><USER5> No they aren't. They are saying "we already have ways of sharing data and not violating privacy".

<comment><USER8> Yes, they are. Do you have any familiarity with studies conducted under a human study IRB permission? Please cite one that would permit sufficient sharing with the public of the detailed information needed to replicate the study. Even just sharing one personal detail, such as gender, or age, is almost always completely forbidden.

Also, please don't be so credulous. This rule has been promulgated, invented, and proagandized by people who are trying to hamstring the EPA from using scientific studies to regulate industry. It's not new, it's just newly empowered.

You appear to be falling for the plausible cover story, which is disinformation. People are really bad at being able to discern the intent behind "plausibly good" organizations and movements.

<comment><USER5> There are plenty of published human studies where raw, anonymized patient level data is shared.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> This article seems really alarmist. It seems like the argument they are making is "raw data for some of the best science needs to be kept secret".

Considering one of the tenants of the scientific method is reproducibility, how can you reproduce something if the raw data is unavailable?

<comment><USER9> It's alarmist because people will die because of this rule.

If you get cancer because of a chemical spill do you want all of your personal information released to help prove that the chemicals spilled poisoned you? No. You want your personal data protected.

<comment><USER5> There is no requirement for personal data to be released. Plenty of environmental studies have been done with anonymized data.

Sounds like a red herring to me.

<comment><USER10> Your confidentiality agreement with a study can preclude them from even releasing the anonymized raw data, invaliding a study in the eyes of the EPA.

It also mandates reproducibility. It isn't exactly easy or even possible to reproduce a 70-year long study or a study of victims of a disaster which is the point of the American College of Obstetricians and Gynecologists and The American Academy of Pediatrics.

[https://www.regulations.gov/document?D=EPA-HQ- OA-2018-0259-2...](https://www.regulations.gov/document?D=EPA-HQ- OA-2018-0259-2425)

<comment><USER5> Reproducibility in science means enough information is disclosed, such that the data can be reproduced. It does not mean it has to be repeated to be believed.

Reproducibility is a key part of the scientific method. I'm surprised people are so willing to toss it aside.

<comment><USER11> Reproducibility doesn't require the original data set to be present, only that the method of conducting that particular study reproducible. There are huge differences.

<comment><USER5> If you want to reproduce the analysis, you sure as heck do need original data.

I probably sound like a broken record, but this is standard across scientific disciplines. No raw data and people call bullshit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> It always stuns me that people still internalize the "both parties" arguments. One party in particular seems significantly more determined and certain to drag American living standards down.

</comment><comment><USER7> Is it really _Trump's_ EPA that is the problem? Or is the underlying problem the party that backs him and supplies EPA officials?

[https://www.vox.com/science-and- health/2017/3/10/14871696/sc...](https://www.vox.com/science-and- health/2017/3/10/14871696/scott-pruitt-climate-denial)

 _Scott Pruitt denies basic climate science. But most of the outrage is missing the point. ... It's not about Pruitt and it's not about facts._ (from 2017)

 _[Complaints] are all about what Pruitt believes. And in the end, who cares what he believes? He is a functionary, chosen in part to dismantle EPA regulations on greenhouse gases. If it weren't him, it would be some other functionary._

 _The goal is to block or reverse any policy that would negatively affect [conservative] donors and supporters, who are drawn disproportionately from carbon-intensive industries and regions. That is the North Star — to protect those constituencies. That means, effectively, blocking any efficacious climate policy (which, almost by definition, will diminish fossil fuels)_

</comment><comment><USER13> Am I the only one worried about the path the world is on? Fascism (or all-out nazism in Europe) on the rise, anti-intellectual and anti-press movements stirring, world leaders shunning science. It feels like we're well on our way into a new dark age.

<comment><USER14> The world was approxiately 100 trillion times more bleak in the 1930s and 1940s. We weren't on our way to a new dark age then either. This is an extraordinary golden age by comparison. There are no world powers currently trying to kill each other, the biggest disputes are mostly between richer nations and about trade, and those disputes are trivial compared to the past. War is rare, famine is rare, food is relatively plentiful, as is global aid, vaccines, etc. Progress across nearly all fields of science and technology continues, rapidly so.

<comment><USER15> Every category you purport to be causes for celebration are presently reversing themselves the world over due to ignorant, nationalist, neo-fascist governments like the one systematically dismantling the EPA discussed in the article.

</comment></comment></comment><comment><USER16> Our health is at risk because the EPA is choosing not to take scientific publications at face value with not even the most basic way to check work?

Have the authors of this article actually confirmed that this would include non-anonymized data unfit for public consumption?

Added: The actual document does not specify "raw data", it is much more specific about what data they expect.

> _The proposed regulation provides that, for the science pivotal to its > significant regulatory actions, EPA will ensure that the data and models > underlying the science is publicly available in a manner sufficient for > validation and analysis._

"A manner sufficient for validation and analysis" is a completely different standard than "all the data the study produced".</comment>