How to Respond to COVID-19 - <AUTHOR> https://www.gatesnotes.com/Health/How-to-respond-to-COVID-19 <comment><USER2> Here in the UK we learned the hard way that health care is national defence. It's a matter of vital national security. In WWI we were chronically short of healthy young recruits, far too many potential soldiers were too sickly or under nourished to serve. What goes for the military goes for industry too, what use is a sickly, unfit work force, especially in a crisis? This is why universal health care is not controversial in the UK. It's why lifelong conservative voters like me support universal health care, we were faced with a clear existential threat generations ago. How could we expect the population to fight for a country that didn't look after them in return? Loyalty has to go both ways. I accept we're a different case from the US because we're a much smaller country, the US can manage due to sheer numbers, but that's a pretty poor excuse. Having a fit, healthy population matters.

Now we're faced with Covid-19. This is a matter of national and international security and defence. Health care spending is national defence spending. It's just a different type of defence against different types of threats, some mundane, some exceptional.

<comment><USER3> Just because you don't want healthcare controlled by the federal government doesn't mean you're opposed to healthcare itself, and some of the countries with universal healthcare have some of the highest infection and death rates so I'm not sure how your solution relates to COVID-19.

<comment><USER4> Yeah. Italy has a universal healthcare system funded from taxes, and not only are they now a major cluster of coronavirus infection and spread, their healthcare system ended up helping to spread the virus. Supposedly their healthcare is some of the best in the world overall too.

<comment><USER5> Also: China has (near) universal health care. ([https://www.internations.org/go/moving-to- china/healthcare#h...](https://www.internations.org/go/moving-to- china/healthcare#how-does-the-healthcare-system-work-in-china), [https://www.sciencedirect.com/science/article/pii/S016885101...](https://www.sciencedirect.com/science/article/pii/S0168851015001864))

With universal health insurance, you're at the mercy of the government. If the government chooses not to cover your issue, or if the government tells you "you're not sick so stop telling people you are," that's too bad. The same thing happens in private insurance, to be sure (minus the "if you say bad things about us we'll put you in jail" part), since people get denied. With government run health care, you have fewer alternatives though. You can't try some other doctor to see if that one will work financially (since it's the same entity footing the bill ultimately). There's no alternate system or provider to go to (you can't do much to get better health coverage for next time).

</comment></comment></comment></comment><comment><USER6> From a business perspective, be prepared for an extended period working from home, and be prepared for productivity to drop. Prioritize and set expectations accordingly.

I have colleagues in China who are facing down their fifth week working from home. At the beginning, they tried to maintain their normal (and excellent) level of output. But the stress of quarantine is starting to show.

Disruptions to normal routines, such as kids stuck at home and reduced/no access to childcare, are the non-newsworthy but most challenging issues for a large number of folks.

<comment><USER7> ... until they realized that working from home and closeness to kids and family was really a wonderful thing?

<comment><USER8> Can confirm. I'm in Beijing and it's wonderful indeed, I'm not with my family though.

I already worked from home for a month as a developer, and we have confirmed we'll WFH for the next 2 weeks at least.

There's no sign of productivity dropping for now according to our regular analytics. We have similar velocity as in previous months, where the estimation was done before the Chinese new year (just to clarify).

</comment></comment></comment><comment><USER9> > The data so far suggests that the virus has a case fatality risk around 1%; > this rate would make it several times more severe than typical seasonal > influenza and would put it somewhere between the 1957 influenza pandemic > (0.6%) and the 1918 influenza pandemic (2%).

That was a little shocking to read. I had no idea the 1918 influenza pandemic was only 2%. I lost relatives to it, assumed it was a larger percentage than 2%.

<comment><USER10> And I think its important to note that 2% is the mortality rate _in a hospital_ where they have respirators, etc. The mortality rate outside of a hospital (e.g. in a quarantine wharehouse) is something like 20%. (I wish I could remember the source for this, will look and edit but it may have been The Atlantic).

It also seems like some survivors come out of this with pretty severe damage to their organs, especially lungs, because the persons immune system goes overboard and attacks healthy tissue. So, some fraction of people will live, but be disabled.

<comment><USER11> A 20% death rate is highly unlikely.The Italian researchers who sequenced the Italian strain believe that the virus has been circulating widely in Italy since January, even before Italy banned direct air flight to China. This seems to be confirmed by the fact that almost all the new cases in Europe are originating from big Italian cities. If the death rate was 20% we should start to see a lot of death in Italy and it doesn't seem to be the case. Iran and Egypt also seems to be largely hit, as many tourist back from Egypt have been infected. Now getting the real death rate is going to be a very complicated game, especially if many infected patient remain without symptom. I tend to believe the virus is already highly circulating in a high number of place of the planet where the health system is bad, and lacking testing capabilities. We are even starting to see untraceable cases in the USA.

<comment><USER12> Caveat: some of the "untraceable" cases are kind of "semi-traceable" in practice. The American government (against the advice of its own CDC) flew back American patients who had been on the Japanese cruise ship, infected and uninfected alike, and sent in HHS employees to interact with them, with inadequate training and hazard protections (i.e., no bunny suits).

This heightened infection risk for the uninfected cruise ship patients and the HHS employees, as well as anybody who knew them.

This plane landed at Travis Air Force Base in Solano County, California. Which is where the first "untraceable" case in the United States occurred.

<comment><USER4> You're mixing up two different evacuations. The whistleblower complaint about HHS employees with inadequate training processing evacuees was about the Wuhan evacuation, not the Diamond Princess one. Only about three of the Wuhan evacuees ever ended up testing positive for the virus, there's no reason to believe they were even infectious when flown back and none of the staff involved have shown signs of COVID-19. It's certainly possible that one of the people involved in the quarantine didn't follow precautions and was infected, even with full training, but I don't think there's any evidence tying the California case to it.

<comment><USER12> OK — I did conflate Wuhan and Diamond Princess, so thanks for correcting me there, but according to both Time and the Washington Post, HHS employees were sent (without proper training or protection) to meet with evacuees in each case:

[https://www.washingtonpost.com/health/2020/02/27/us- workers-...](https://www.washingtonpost.com/health/2020/02/27/us-workers- without-protective-gear-assisted-coronavirus-evacuees-hhs-whistleblower-says/)

[https://time.com/5792135/coronavirus-whistleblower-hhs- emplo...](https://time.com/5792135/coronavirus-whistleblower-hhs-employees/)

</comment></comment></comment></comment></comment></comment><comment><USER13> Marc Lipsitch, a Harvard epidemiologist, estimates that 40-70% of the adult world-wide population will be infected. [0]

Assuming a conservative 1% mortality rate, that would mean 30-50M deaths, a tragically huge number.

[0] [https://news.harvard.edu/gazette/story/2020/02/key- coronavir...](https://news.harvard.edu/gazette/story/2020/02/key-coronavirus- question-how-are-children-affected/)

<comment><USER14> Most cases with mild symptoms are not even reported or noticed by those infected so the real number is lower than 1 percent in all likelihood.

<comment><USER15> > _Most cases with mild symptoms are not even reported_

This is outdated. Dr. Bruce Aylward said in a WHO conference this week that the Chinese tested 320,000 samples in Guangdong and they are not seeing huge transmission beyond cases found clinically. It's at 47 mins in this video: [https://youtu.be/-o0q1XMRKYM?t=2810](https://youtu.be/-o0q1XMRKYM?t=2810)

> _so the real number is lower than 1 percent in all likelihood._

I disagree. When we calculate the SARS-CoV-2 CFR properly using

CFR = deaths / (deaths + recovered)

using the latest data we get

2,924 / (2,924 + 39,605) = 7% CFR

That's much more in line with the original SARS CFR of around 9%.

<comment><USER16> "The claim was quickly challenged by an infectious diseases expert who serves on a committee that advises the WHO's health emergencies program.

Gary Kobinger, director of the Infectious Disease Research Center at Laval University in Quebec, said it would be highly unusual for there not to be mild or symptom-free cases that are being missed. He pointed to the fact that outbreaks have popped up in countries far from China — including Iran and Italy — because people with mild infections were not detected and traveled to other places.

'There are mild cases that are undetected. This is why it's spreading. Otherwise it would not be spreading because we would know where those cases are and they would be contained and that would be the end of it,' said Kobinger, who insisted that mild, undetected infections cannot be ruled out until people who haven't been diagnosed with the illness can be tested for antibodies to the virus.

'As long as we do not have good serology data, I think that it is completely speculative to say that there are no undetected cases,' Kobinger said."

What Dr. Aylward says makes no sense and reads more like a PR fluff piece designed to praise China to keep them happy, and as Kobinger points out he's probably wrong. From the same press conference he says this "If I had COVID-19, I'd want to be treated in China."

Which is obviously bullshit.

As the specifics of the 320,000 cases. It wasn't a serum antibody test, so it wouldn't show people with low viral loads or people who recovered.

Also this is in Guangdong where the infection was potentially quickly contained, and if you'll notice the death rate is much lower in Guangdong.

<comment><USER17> "If I had COVID-19, I'd want to be treated in China."

China probably knows how to best treat this, but as a patient you could either get that treatment, or get turned away or even get welded in your apartment apparently.

</comment></comment></comment></comment></comment><comment><USER18> Does anyone know where the 2% death rate for 1918 flu comes from? I've seen it quoted multiple times, but Wikipedia says:

 _It infected 500 million people around the world... The death toll is estimated to have been 40 million to 50 million, and possibly as high as 100 million_

But later

 _The World Health Organization estimates that 2–3% of those who were infected died (case-fatality ratio). It is estimated that approximately 30 million were killed by the flu, or about 1.7% of the world population died. Other estimates range from 17 to 55 million fatalities_ [1]

[1] [https://en.wikipedia.org/wiki/Spanish_flu](https://en.wikipedia.org/wiki/Spanish_flu)

<comment><USER19> I'm really surprised by this as well. From what I can tell, the estimate that was named is "above 2.5%". This could be simply by calculating how many people died compared to total population in the world. If 2.5% of total world population died, assuming everyone was infected, it is at least 2.5% case fatality rate and depending on how many people were not infected case fatality rate will go down.

<comment><USER20> Wouldn't case fatality rate go up the more people were not infected?

<comment><USER19> Yes. But if you do not have a lower bound for number of infected, you can with certainty only say "above 2.5%".

</comment></comment></comment></comment><comment><USER21> "Global health experts have been saying for years that another pandemic rivalling the speed and severity of the 1918 influenza epidemic wasn't a matter of if but when."

Short-term-ism is the real epidemic in America. We seem paralyzed in taking preparedness steps in a host of issues that are a matter of "not if, but when." From Climate Change, to infectious disease.

On individual level, we share some of the blame. I'll admit that even in earthquake and fire prone California that prior to this current crisis, I've never kept more than a few days worth of food on hand. Even faced with a real risk, there's inertia there — but ultimately realizing that being prepared as a household is the root of resilience for a neighborhood and community. It's not a selfish act — it's the responsible thing to do.

But at a leadership level, we seem to be waiting for some shoe to drop in this current situation rather than take proactive steps. We seem two steps behind this thing in the US.

</comment><comment><USER22> Are you legally prepared? Do you have a will, an advanced medical directive, and other important documents? If not, take this as a cue to get that done today. Pandemic or no pandemic, you should have these.

Without these documents, you may very likely not receive the medical treatment you would wish to have should you become incapacitated. Also, your worldly possessions will likely not be dealt with as you would wish, and you'll be leaving a mess behind for your loved ones.

So, get your affairs in order.

<comment><USER23> _> you'll be leaving a mess behind for your loved ones._

I don't have any loved ones.

 _> advanced medical directive_

My country doesn't honor those.

Yup, I'm about as prepared as I can be.

</comment></comment><comment><USER24> How about investing in "low- and middle-income" Americans and providing them healthcare? In addition how about providing required paid sick leave that can be taken without fear of losing one's job? These are actual things we could do to help people respond and deal with COVID-19. Yes, working on vaccines is important but testing and avoiding spreading the virus as much as possible are even more important. Right now, we have no hope of doing either in an effective manner. People will go to work sick, including with COVID-19 because they have no choice, because our government has left them no choice. They won't be able to get tested because they have no choice due to not having health insurance--another choice removed by our ineffective policies. I don't see any coherent plan by the government at this moment to address any of these issues and given the current situation, I would not be surprised if we have one of the worst outcomes of any developed country, possibly including China. The only hope is that the virus mutates into something less contagious or harmful and that should not be something we rely on.

</comment><comment><USER25> I wonder if there will be a more general cultural change. For instance, will it become commonplace to have disinfectant dispensers in public places, like you might have drinking fountains and public bathrooms? Will workplaces and stadiums install these? I can't judge the advice on this, but it seems to be that disinfectants work.

Also, will people be told to stay home when they're even slightly ill? Currently people know that sick people spread disease, but we leave it to their own judgement as to whether to show up. What about a law that says you can't be paid as a contractor if you show up and you're ill? Could/should that happen?

<comment><USER26> " What about a law that says you can't be paid as a contractor if you show up and you're ill?"

To my european ears that's a very strange thought.

This is what paid sick leave was invented for. If we do as you proposed that strongly incentivises people to judge themselves not sick. Obviously the most intense cases will be found out, and according to your law sent home without pay, but by then the damage is done.

<comment><USER25> I mean contractors though. A lot of people in finance get paid per day they show up. I even have friends who will go to work while terribly ill because they get paid £1000 for it.

Paid sick leave is fairly normal for people on standard employee contracts.

</comment></comment></comment><comment><USER27> For those who are interested in how to improve your own immune system function I recommend to watch a couple of videos of Dr Bergman and Dr Axe

</comment><comment><USER28> who is still excited about pair programming? I think this will come to an end very abruptly. keyboards are disgusting.

<comment><USER29> I mean, it's pretty easy to do pair programming with separate keyboards or even computers..

</comment></comment><comment><USER30> It's easy to raise the billions required to fight this. It's peanuts for governments and even larger companies hoarding tens of billions that have a lot to lose because of such pandemics.

<comment> rm_-rf_slash Raise the billions to do what though? Pay for pharmaceuticals that can't reach sick people because there aren't enough people to work the production lines, the docks, the ships, the trains, the trucks, and the hospitals?

</comment></comment><comment><USER10> In a perfect world, Trump would appoint Gates to lead the Department of Health and Human Services, Gates would accept, the Senate would quickly confirm, and Trump would actually listen and defer to him on this.

It's interesting that this is directed to policy makers and other leaders, rather than individuals on the ground - e.g. it's about resource allocation, not personal preperation. (It was amusing to see the large-scale analogue to hoarding referred to as "lists of supplies to be stockpiled or redirected in an emergency." This presumes, of course, that governments will act as a force of mediating reason on people's irrational impulses; and we all know that sometimes it's the opposite).

<comment><USER31> Wait I thought Gates was in on this with the Chinese and released this as population control? Have I been getting my news from the wrong source?</comment></comment>


Everything you ever wanted to know about building a secure password reset (2012) - <AUTHOR> https://www.troyhunt.com/everything-you-ever-wanted-to-know/ <comment><USER2> Fuck "secret questions."

I don't remember if i answered "88 Oldsmobile Cutlass Supreme," "1988 Oldsmobile Cutlass Supreme," Cutlass Supreme," "'88 Cutlass Supreme," "cutlass supreme," "1988 Cutlass Supreme," "Oldsmobile" or any other variation or misspelling. I don't remember if i had to tweek my answer to fulfill your dumb requirements (my favorite teacher has a special character in her name! Or the answer is 3 characters long and you have a minimum of four! My elementary school is numbered) I remember what street I lived on in middle school NOW, but I'll probably forget it in five years, I routinely forget much more relevant things. On top of that maybe I just don't want to tell every website I use who my childhood crush was. There's also the problem of most "secret questions" that are available being irrelevant for X% of the population. (ex. loners and people who didn't have a stable home life... they rarely include stuff like "who was your foster mom when you were 8?" Even the international crowd could have trouble with most questions.)

I'm old enough and have enough online accounts (I have 246 accounts saved in my password manager) that i now just write "fuck you" for all the answers and put 'all answers fuck you' in my password manager. Because these questions stress me out way too much and I'm constantly bombarded with them. Answering them becomes a major pain point when everyone wants them. I've completely lost it with the damn "[not so] secret questions."

<comment><USER3> Even worse are websites/services that impose ridiculous character requirements (you must include 2 symbols, 3 numbers, 5 letters, 2.5 of which must be upper case and positioned at the prime number indices, oh and you have to change your password every 6 months) and then limit your password to 8-12 characters.

The way I remember passwords is by stringing together random English words with random special characters inserted throughout. This means most of them are 30-40 characters. I find these far easier to remember than my PayPal password, which is arbitrarily limited to a random collection of special characters that must be of length less than 12 (or whatever their ridiculously short limit is.)

If you truly care about the security of my account _don 't impose character limits_.

<comment><USER4> I spent 20 minutes trying to come up with a password for chase.com recently because of insane rules like, you can use more than two characters in ascending or descending order, can't use the same character more than twice. Using a random password generator above about 20 characters, and it's guaranteed to break one of there inane rules; let alone if you want to use a pronounceable passphrase that's simply long. It's really aggravating that big companies are some of the worst at this security stuff.

<comment><USER5> I use Bitlocker and I can set limits/conditions on pwd generation which is then saved under a master pwd.

<comment><USER6> Which Bitlocker is that? I'm only familiar with drive encryption by Microsoft. Do you mean Bitwarden?

<comment><USER5> Opps you're right....BitWarden

</comment></comment></comment></comment></comment></comment><comment><USER7> I sure wish my brokerage would allow me to turn off all online password reset options. They have an office near to me. If I forget my password, I would like to have to go to the office with my passport to reset it. This person should be high level and well trained so that social engineering is unlikely to work on them. I would be happy to do this and would prefer if they charged me $100 to reset my password this way. I don't day trade so I don't need a way to instantly reset my password. Many years ago I reset my brokerage password online and it was way to easy to do.

The amount of money I have in the account is small enough that I have not seriously looked into other options yet. How do people with $5 million in a retirement account deal with the fact that someone could really screw you over by getting into the account?

It might be somewhat difficult to get money out of the account, but if you are just trying to hurt someone, that should not be too hard. Log in. Use a million dollars to buy a bunch of a penny stock and the price will skyrocket as you buy. Then start to sell and keep selling as the price plummets.

<comment><USER8> I've actually wondered the opposite. If someone is charming enough, and has done some preliminary research on the bank's in-person screening, could they bypass security with something as little as a fake ID?

Overall, I don't know if there is a perfect solution. Perhaps for banks we should pee-in-a-cup DNA test in addition to other tests. For a porn site we can do a poor mans email reset.

<comment><USER9> I believe that DNA tests fail the same reason that eye scanners and fingerprints do: they are not private. Almost anyone can get access to any of those 3, and then they just need to figure out a way to use it on the system.

<comment><USER10> Is it really that easy to forge someone else's DNA and bring it to a testing facility?

<comment><USER11> DNA is a replicator molecule. You don't need to forge it, just get a tiny sample and it will make as much as you could ever need with gear found in any high school lab.

</comment></comment></comment></comment></comment><comment><USER12> I disagree with the section titled "Username enumeration and the impact on anonymity".

The author is trying to make the point that you shouldn't tell users that their username is invalid in a password reset flow. The author then goes further and recommends obscuring error messages during the login flow as well.

I find this behaviour to be user hostile and not particularly effective at concealing anonymity. Under the same threat model, a suitably motivated third party can simply attempt to sign up with the same username, and you'll definitely have an error message if the user is already signed up (and that's besides the point that just because a username exists doesn't mean the person behind that identifier actually signed up, anyone could've done it).

The author tries to justify their position by calling it a "slight usability tax" and "a small trade-off for an infrequent process", but my very short experience building a consumer oriented SaaS is that:

1\. Password requests are frequent, even with ~5k users

2\. Lots of people have more than one email address, and frequently forget which one they used for your service.

3\. The support burden simply isn't worth the pseudo-anonymity.

<comment><USER13> I built a password reset system that didn't tell the requestor whether they gave an unregistered email address. It just said, "look in your mailbox." Because, avoid telling cybercreeps anything useful.

But my tech support team screamed about it. So, I changed it to send an email to the unregistered address saying

"somebody asked for a password reset to be sent to this email address. But we don't have an account associated with this address. If you need help please hit URL or call PHONE. "

A cybercreep still can't tell from the password-reset page whether the email was correct.

This ruse solved my support team's problem.

<comment><USER14> > This ruse solved my support team's problem.

Having places where I don't recall if I have an account, and if I do, which of my email accounts it was registered to - this solution would actually make me happy. I recall running into it once or twice in the wild and was always just as happy to get the "we don't have an account with this email message" in either email or immediate feedback. That said, I agree with the poster that sees the actual security of hiding usernames as marginal at best, outside of sites where the mere presence of a user is indicative. ("Johnny, why do you have an account on "ILikeLeadingCommas.com"?!")

</comment></comment></comment><comment><USER15> I really think secret questions are garbage. They grant minimal extra security for the cost of a huge hassle for customers. But the worst part about them is requesting and storing a significant amount of highly personal data. The likelihood of this data being breached and used against you is probably much greater than the security improvements it grants. Requiring many pieces of personal data to sign up for every fly-by-night web application is short- sighted and inconsiderate.

<comment><USER16> I agree completely.

The article above is pretty dated (which is noted in the post), and so leaves out some better options for security that are available today, such as authenticator apps for 2fa. In the context of when it was published, it was an excellent and important stepping stone in security awareness, but working with the tools of the time.

Now, we have better options and Troy Hunt (among others) has covered many of them in separate posts over the years.

</comment></comment><comment><USER17> Another criterion for a good security question: make sure everyone actually has an answer. I use a website that forces me to answer the following question: in what month was your first child born? It boggles my mind that someone at this company could fail to consider the possibility that a user of their site might not have children.

<comment><USER8> That's kinda funny to me. For people like me (and likely a lot of others that browse this site) the answer to how many children you have, is clearly "@#T%FGDw34dsd$"

<comment><USER18> Giving answers like this over the phone to customer services reps is always a good laugh.

CSR: " _Wait, what's your favorite city?_ "

Me: "jeogusbw378fnsbwxwobp"

CSR: " _Is that in Europe?_ "

</comment></comment></comment><comment><USER19> This is really good stuff. I think the only thing I'd add is that, if you're building a login system anew, you _should_ do 2-factor, and you _should not_ use SMS codes. Use phone authenticator apps (time-based OTP's), FIDO U2F, heck, even Smartcards if you're paranoid.

The best implementations I see are the ones that allow both phone authenticator apps for the people who don't want to carry a keyfob around or need to log in via their phones, and U2F for people who want their physical factor separate from their phone.

<comment><USER11> OTPs are phishable. If you worry about SMS codes, you shouldn't accept OTP either, bad guys are just going to socially engineer your user into giving them a valid code.

FIDO is the way forward, but having run into Microsoft's hapless first attempt (since they managed to get it to not work in anything except Edge on specific builds of Windows they also made it optional, so it actually can't make your security better. Brilliant) I have less confidence it'll ever be useful to the ordinary person... Still, it does protect my Google account.

<comment><USER19> Phone based TOTP's are vulnerable to real-time phishing, but they still require you to sit there and enter the number on your phone. It still has to be _your phone_. That's not ideal, but that's substantially better than SMS where someone can take your phone number and your second factor is gone. No real-time requirement.

That makes phone based TOTP the most secure second factor that is pretty much universally accessible to lay users (i.e. not buying a dedicated second factor device, and most people have smartphones).

FIDO U2F isn't quite there yet in terms of universal support, but its design is definitely promising from a usability perspective. It's one technology I'm willing to hold my breath for.

</comment></comment></comment><comment><USER20> I've been wondering how even having a password at all might be an antiquated feature.

Most sites/applications today require you to have an email address (whether alongside a username or, increasingly, as the only identifier), and fully pass all verification to your email provider (by providing a password reset). In that situation, having a separate password for that site (and, presumably, one for each new one) seems a bit superfluous -- it should be enough to, instead, just enter your email and receive a unique one-time URL that will log you in if opened within, say, 15 minutes.

Would this system be any more insecure than the present model of email + password + reset link?

<comment><USER21> How would you get that to work simply in a mobile app login flow?

<comment><USER22> IIRC, slack does (or did, ~3 years ago) exactly that. Either the email link is structured to cause the mobile OS to open the app, or the link leads to a page that then presents a link that opens in the app. In either case the link(s) contain a token that's valid for one use.

</comment></comment></comment><comment><USER23> My current approach is to send an email with a temporary password which works for a single login and can be used to change the password. Original password still works. Temp password expires in 1 hour.

It is basically a reset token but allows logins instead of loading up a reset form. One less thing to implement.

<comment><USER24> Firstly, does your approach still invalidate the original password? If not that's really counter-intuitive. If I click a reset password button I want my password reset.

Secondly, it sounds like you just give auth based on this token so you can re- use your password change screen, but if your password reset screen doesn't ask for the current password it really ought to do so to prevent the risk of left over sessions being used to hijack accounts (e.g. not logged out public machines, stolen cookies, etc).

<comment><USER23> Well the idea is that you do not click a reset password button. You click on a forgot password button so this gives you a temporary one to use.

Your second point is spot on and I do ask for the current password. The temp password also works there. This is counter intuitive but not a security issue as you mentioned. I guess I can just skip asking the old password in case this particular session uses a temp password.

I like reusing the password change form. But there is something more to this. Our logs show that if a user needs a password reset, they tend to need it more than once. So, there is a pattern that some of our users simply keep forgetting their password. It might be the nature of what we work on though, most of our users log in a once or twice a month. That pattern gave me the idea that if they are gonna keep forgetting it, maybe I should not force them to reset. Let them use a temp password every single time.

It's like what Slack does with "magic login link" stuff where you can elect to receive a login link via email instead of using your password during login. I guess branding it like Slack does might be better though.

</comment></comment></comment><comment><USER25> Good, extensive write up. Note that correctly hashing passwords is a topic in itself and the short answer IMO is: use bcrypt.

It should also mention that after a user changes their password, all login sessions should be invalidated. This lets a user who thinks their account/password may have been compromised prevent an attacker from using prior stolen sessions.

This is accomplished by including a nonce (a "number used once" which is basically just a large random number) in the user record that is also included in the auth session, and verified on each request. It gets set to a new value on password reset, and thus invalidates existing sessions. (The active session issuing the password change should ideally have its value updated to the new value automatically, though.)

<comment><USER26> Or execute sql "update active_sessions set expired_at = now() where user_id = $1"

Expiring all sessions should definitely be a critical point on anyone's checklist when building a password reset system.

Spotify didn't have this for the longest time and it was insane. Someone could buy a hacked account for $1 and get pretty much unlimited access. Though a special sort of infuriating softwaregore because you had to listen to what they were listening to.

<comment><USER23> If you do not have a server side session store, only option is to use a nonce of some sort though.

<comment> ben-schaaf Or use a access/refresh token pair

</comment></comment></comment></comment><comment><USER8> There are some slight enhancement that could be made, but would require gathering some additional info about your users:

Start collecting IP addresses that the user has typically connected through. It's not OK to block that user from doing a password reset on an account with a new IP, but you could at least do some more internal alerts and secondary human checks (even if after the fact). Do all the other things in the article, but this would save some people.

Another one would be to record in session storage or cookie storage, some randomly generated key, that is permanently recorded on the server. If a browser with any of those keys come back and initiates the forgot password script, again, you can lower the weapons a little after they get in.

</comment><comment><USER27> Password storage (hashes only): PBKDF such as argon2i and salted.

Limit the rate of both reset and reset re-email attempts (X within Y).

Email the link that should expire on first use and set an expirable token param to complete the reset.

Required login again to make sure people know their password.

Form POST.

Platform-Agnostic Security Tokens (PAST), not JSON Web Tokens (JWT) for headless API calls.

CSRF (form hidden) token.

Always https. Disable http.

</comment><comment><USER28> Please don't use security questions: [http://lucb1e.com/?p=post&id=65](http://lucb1e.com/?p=post&id=65) (coincidentally also from 2012)

It's really weird to see this being advised. I thought we all agreed security questions are bad for lots of reasons.

</comment><comment><USER29> The fluffy bunny option does not work for me, in either Firefox or Chrome on my Mac. Instead of replacing the image on the page, it just reloads the whole page with the boring humans.

If you want to see the bunnies, it works to go the page at archive.org [1] and click the link there.

[1] [https://web.archive.org/web/20170819153353/https://www.troyh...](https://web.archive.org/web/20170819153353/https://www.troyhunt.com/everything- you-ever-wanted-to-know/)

</comment><comment><USER30> Nobody said the answers to test questions have to be truthful or make semantic or syntactic sense.

My mother's maiden name was trick cheese lobster

</comment><comment><USER31> > the password is hopefully accompanied by a salt, each of which sit in their > own columns

Question: there's no real reason for the hash to be in a _separate_ column, correct? Just that it's different per record?

<comment><USER32> Correct. Many hashing functions designed for password hashing build the salt directly into the output string, in order to make it difficult to accidentally hash passwords without using a salt. On the other hand, if you're just using a bare hash function, you may find it convenient to store the salt in a separate column, if only to save yourself having to split on a separator character / character length in your application logic.

<comment><USER31> Yeah, that's what I was I thinking. Bcrypt does that, or at least the implementation I'm familiar with seeing in Rails. The sentence threw me off there for a second. Thanks for the clarification.

</comment></comment></comment><comment><USER33> A good article but needs "(2012)" in the title.

<comment><USER34> Good catch!

Discussion from back then: [https://news.ycombinator.com/item?id=4280440](https://news.ycombinator.com/item?id=4280440)

<comment><USER35> Maybe a feature request to save you some work. On submission, based on url, the site automatically lets the submitter know of prior submissions and if they choose to submit anyway, then (if they do) the first comment is an auto comment with links to previous discussions. Could also add a year to the lookup and have that gets auto added to the title if not already present.

</comment></comment></comment><comment><USER36> Everything you need to know about building a secure password reset: Cryptographically secure universally unique id -> email.</comment>


Flappy Bird in Swift - <AUTHOR> https://github.com/fullstackio/FlappySwift

<comment><USER2> As a C# developer, I can read and understand the code without any issues. That's a good thing for Apple. I'm sure Objective-C is great but it's too foreign for me and didn't want to toy with it for fun, not worth the effort. But I can write an app or two with this one.

<comment><USER3> I get where you're coming from - but in my experience, the barrier is totally psychological. Objective C isn't that unusual a language - the syntax is a bit foreign, but nothing that takes more than a couple of days to wrap your head around.

You'll spend far more time getting to grips with Cocoa/Cocoa Touch.

<comment><USER4> _the barrier is totally psychological_

Of course it is. It's certainly not a physical barrier. But psychological or not, other languages don't have a similar barrier.

<comment><USER5> > other languages don't have a similar barrier

Lisps have the RPN psychological barrier. Python has the significant whitespace psychological barrier. etc. Any language can present _someone_ with _some_ psychological barrier.

I think the OP's strongest point was, Objective-C the language is pretty trivial to learn quickly (after all, it's just C with message passing). You'll spend far longer trying to learn the Cocoa APIs than you will spend learning Objective-C-the-language.

For instance, I decided to try to learn swift and SpriteKit at the same time. I spent far longer looking up methods on SKSpriteNode than I did looking up language constructs. (i.e. I assumed "let" was the same as in ES6 and couldn't figure out why the compiler was mad.)

</comment></comment></comment></comment><comment><USER6> I just started exploring the Book: The Swift Programming Language by Apple Inc.

Link: [https://itunes.apple.com/us/book/the-swift-programming- langu...](https://itunes.apple.com/us/book/the-swift-programming- language/id881256329?mt=11)

Hope it helps.

<comment><USER7> And the same, in HTML form: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/index.html#//apple_ref/doc/uid/TP40014097-CH3-XID_0)

<comment><USER8> Note that near the top of "A Swift Tour" there is a link to the playground which you can download and open in Xcode 6.

<comment><USER9> Wow, that is cool. Learning Swift is going to be fun.

Direct link to the playground file: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.playground.zip)

</comment></comment></comment></comment><comment><USER10> I guess Flappy Bird is now a tier 2 "hello world" :)

<comment><USER11> I was disappointed that they didn't use it as "The simplest possible game" in the WWDC presentation

<comment><USER12> Copyright...

<comment><USER13> Is it really copyrighted though?

<comment><USER14> yes. IANAL but... copyright law in the US is such that, in essence, everything is copyrighted (to some degree) the moment it is created unless you explicitly state otherwise.

When dealing with anything legally distributed / created in the US there are many questions, but "is it copywritten" should be one of the last ones, because the answer is always YES.

</comment></comment></comment></comment></comment><comment><USER15> Author here - I didn't expect to see this here this morning. I'd intended to write a longer post :)

In any case, here's a few things I learned about swift yesterday building this. Please note that I have about 4 hours swift experience, so feel free to correct anything I say that's wrong.

1\. To make properties on a class you simply declare the variable on the class e.g.:

        class GameScene: SKScene {
          var bird = SKSpriteNode()
          // ...
        }

2\. The APIs generally have shorter names and it's really nice. E.g.

        SKTexture* birdTexture1 = [SKTexture textureWithImageNamed:@"Bird1"];

becomes

        var birdTexture1 = SKTexture(imageNamed: "Bird1")

If I understand it correctly, any overloading `inits` basically look like calling the constructor on the class, whereas any class functions will be called like this:

        var flap = SKAction.repeatActionForever(animation)

3\. You can put inline blocks and it's great

        var spawn = SKAction.runBlock({() in self.spawnPipes()})

4\. The typing is really strong - this takes some getting used to. For instance, `arc4random()` returns a 32 bit unsigned integer. This means before you can use any operators on it you have to make sure you're using compatible types. e.g.

        var quarter = UInt32( self.frame.size.height / 4 )
        var y = arc4random() % quarter + quarter;

If we didn't use `UInt32` to convert `quarter` we'd get an error. After you get the hang of this, it's actually really nice.

5\. I use `var` everywhere and I'm pretty sure I should be using `let` a lot more. I haven't worked with Swift enough to have a strong intuition about when to use either.

I should also mention that my code is just converted from Matthias Gall's code [1].

I also want to put in a shameless plug that the point of making this was to advertise the "Making Games with Swift" class that auser and I are building. If you're interested, put in your email here: [https://fullstackedu.com](https://fullstackedu.com)

I intend to redo this more fully with Playgrounds. I've been looking for a way to teach kids programming for a while now (if you recall, auser and I built Choc [2] a few months back). I think Playgrounds in Swift are finally the tool we've been waiting for.

[1] [http://digitalbreed.com/2014/how-to-build-a-game-like- flappy...](http://digitalbreed.com/2014/how-to-build-a-game-like-flappy-bird- with-xcode-and-sprite-kit)

[2] [http://www.fullstack.io/choc/](http://www.fullstack.io/choc/)

EDIT: added choc

<comment><USER16> I think just the fact that you were able to build a game with just 4 hours of learning a new language speaks volumes about Swift's barrier to entry. Well done!

<comment><USER17> Any up-to-date C# developer already knows Swift.

<comment><USER18> Any up-to-date Java developer already knows Swift :)

<comment><USER19> Any up-to-date Swift developer already knows Swift :-p

</comment></comment></comment></comment></comment><comment><USER3> Good work. I'll have to do 2048 instead, I guess :)

I'm quite impressed so far. Having been an Objective C and Ruby engineer, so far Swift seems to offer the best of both.

That said, OpenGL support doesn't appear to be finished yet.

</comment><comment><USER20> If you're new to functional programming styles this swift project might be more relevant: [https://github.com/maxpow4h/swiftz](https://github.com/maxpow4h/swiftz)

</comment><comment><USER21> I got mixed feelings about the language at first sight. I guess my mammalian brain recognizes languages based on the particular combination of the following naming decisions.

* func, function, fun, defun fu, funct

* CamelCase vs snake_case

* whitespace, semicolon or comma usage

* var, int/integer/uint64/Integer/

* choice of (), {}, [] or better (){a[]}

* import/include/require, class/class, override, self vs this, new vs Class()

PS: next time you design a new language just make a random unique combination of the above.

<comment><USER22> > PS: next time you design a new language just make a random unique > combination of the above.

That's my impression whenever I see a new programming language too. Why would someone switch to your language if the syntax is just the same boring old syntax they've been using in another language?

<comment><USER23> Because in this case, it's an alternative to a language (Objective C) with a not so boring esoteric syntax.

<comment><USER24> Not boring at all - but I'm not sure this helps adoption any. :)

</comment></comment></comment></comment><comment><USER25> Always had a problem with Objective C, could never read it (Android Dev) but this right here is pretty impressive. I like the mixture of language features. But my only question, are you still locked to using an mac to develop for iOS. I guess since the language is closed source it depends on some osx libs at compile time.

<comment><USER26> Yes, you still need a Mac to develop for iOS. Come to the dark side! :)

<comment><USER27> Android developer here with a Macbook Pro. I'm honestly thinking about taking the leap and getting an iPhone, depending on how the 6 looks like. But Swift enticed me very much.

<comment><USER28> You won't regret it

</comment></comment></comment></comment><comment><USER29> From the GIF in the readme, it looks like collision detection is broken.

<comment><USER15> I'm terrible at flappy bird - I can /sometimes/ get through the first pipe. Rarely.

I didn't build the collision detection yet just b/c I actually think it's more fun to play this way.

That said, we'll add it before too long.

</comment></comment><comment><USER30> This being the only code sample of swift I've seen, my overriding takeaway is that for the basic stuff it's remarkably similar to Objective-C with a lick of paint.

If people really take to swift, it'll be interesting to see if that's because it creates a shift in programming style, or because people really are just afraid of small syntactical differences.

<comment><USER31> Readability matters - maybe the Objective-C verbiage melts away once you're up to speed, but it certainly puts you off wanting to get there.

<comment><USER32> I find obj-c super readable, other people don't? I mean, take two hours to get used to the bracket syntax for message sending and it's super readable although a bit verbose?

<comment><USER33> Same here.

All you have to do is get over named parameters, square bracket message passing, and overall verbosity, and you know enough to read/understand Objective-C code.

If you can get past those three differences, Objective-C is remarkably similar to Java and other OOP languages.

Personally, I love the verbosity. The code pretty much just explains itself.

Swift is a welcomed change though. I'm very optimistic and excited about the future of iOS going forward.

<comment><USER31> Please take this in good humour but I couldn't resist:

> All you have to do is get over named parameters, square bracket message > passing, and overall verbosity

Translation: "All you have to do is get over it's poor readability and it's quite readable!"

> Objective-C is remarkably similar to Java and other OOP languages.

Translation: "Objective-C is as readable as several other unreadable languages".

;-)

Readability isn't about familiarity as much as it's about clarity and a lack of boilerplate. Verbosity is in most cases the antithesis if readability. I think there can be exceptions (maybe some verbose DSLs that manage to map cleanly from your brain to the code on the page) but if the verbosity comes from boilerplate or visual clutter then verbosity is a strong point against.

</comment></comment></comment></comment></comment><comment><USER34> I am really intrigued by the obj-c interop capability of swift, namely interactions between blocks and closures / anonymous functions.

I can see my AFNetworking code becoming much, much more readable now, without the need to @weakify/@strongify self on both sides of the block, but just add a blanket '[unowned self] in' inside the closure.

</comment><comment><USER35> Swift is a new programming language. Does this implementation also use Metal? What is the Scene Kit relation to Metal?

<comment><USER36> SpriteKit and SceneKit is targeting casual games. Metal is an API that is close to GPU and is meant to replace OpenGL for console level games.

</comment></comment><comment> k-mcgrady This may be a stupid question but is the language in some way tailored to game programming? Apple's examples at WWDC were game companies, their coding demo was a game, and this is the first project I've seen written in it - and it's a game.

<comment><USER30> Games make easy examples because you can do a simple render loop and input. Most people understand the concept of sprites and basic animation.

Apple's UI frameworks are all MVC based, which means multiple classes and apple specific UI terminology.

<comment><USER37> Additionally, they're a quick route between code and something visual. If the demo yesterday had been "look how easy I can make a tableview", no one would have cared much, but the circus scene had motion, lights, and barely any code. People love spectacle.

That reads a lot more sarcastic than it should have, but it's unfortunately true. Swift was announced in front of a room of people who needed to be convinced to start migrating from something they all know (ObjC) in favor of something new, so you have to win them over quick.

</comment></comment></comment><comment><USER38> Flappy Bird in Racket | [https://github.com/soegaard/flappy- bird](https://github.com/soegaard/flappy-bird)

<comment><USER39> Man, apparently dr racket format looks like a hot mess.

<comment><USER40> A normal Racket file is a straight forward text file.

In Flappy Bird I used inline images, as in (define bird <the-bird-image-here> ) This makes it simple to distribute the source and images as a single file, but unfortunately the resulting file is not pretty.

In short: to see the source open it in DrRacket.

</comment></comment></comment><comment><USER41> pretty neat! I am not an iOS developer but if i understand correctly this uses the new Sprite Kit stuff included in iOS8 for 2d rendering right ? Is this a threat to existing 2d/game engines ? Not sure where SpriteKit integrates into the existing stack for making a game.

<comment><USER42> Looks like a good way for Apple to lock the developers to their platform. In past glory days people used to make games for iOS first and consider porting to Android much later. These days developers think cross-platform from the start, esp. since it's much easier to test waters and iterate on Android. I guess that SpriteKit is an attempt to stop this trend. Smart move by Apple IMHO, but perhaps a little bit too late.

<comment><USER43> I see your polite, critical, level-headed opinion has been down voted into gray dust, despite my meager support. I entreat those who pass by here to drink in my own following opinion: I think you're operating from the democratic ideal that "all people will opine equally about all topics at all times."

The departure from this ideal, I've discovered, is that there is a "Practical Crowd" who will swoop through when questions of practicality, such as cross- platform compatibility come up. Their opinions will be nearly absolute and they will be all but intolerant of the "weak" who claim that merely targeting Windows, Linux and OSX is "enough." They will justify with numerous cherry- picked examples from history, starkly, if not carefully, considered arguments toward the future, and with evidence of grit on their fingers from the present, in which the particular ideal is espoused. At that time, they will down vote anyone deviant enough to cheer for Swift.

Yet, currently my friend, the Apple Crowd has the floor. Any practical concerns are scheduled after the celebration. Think of this when you read the next cross-platform thread and see the Apple fans trying to get a point in edgewise amongst The Practical. There is very little global reality, mainly local basins of morality.

</comment></comment></comment><comment><USER44> Well that didn't take long...

</comment><comment><USER45> If Swift has namespaces why are classes still prefixed? "SKScene" for example.

<comment><USER46> Objective-C interop.

</comment></comment><comment><USER47> Does this need IOS8 to run?

Is there a way to get that without being a signed up dev with Apple?

<comment><USER48> Apple has stated that Swift apps can target iOS 7/8 and Mavericks/Yosemite. You do need access to the dev program in order to get access to the Xcode 6 beta.

</comment></comment><comment><USER49> Someone needs to add Swift to the linguist gem

</comment><comment><USER50> OK, that was fast!

</comment><comment><USER51> 2k+ Github stars in less than 24h? OMG

</comment><comment><USER52> Swift looks fine, the only thing I don't like its that is for Apple only products... that kinda defeats the purpose of having a programming language.

<comment><USER53> Good luck compiling Objective-C on Windows :)

<comment><USER3> Here you go: [http://www.gnustep.org/experience/Windows.html](http://www.gnustep.org/experience/Windows.html)

<comment><USER53> Ye-es, except:

      "Apple has recently added new functionality to their runtime, including built-in exception handling, etc. Hopefully these will be ported to the GNU runtime in the future."

My general point is that programming languages don't _have_ to be cross platform to be useful. Certainly handy from a developer's point of view, but just a convenience.

</comment></comment></comment></comment><comment><USER54> FAST AS HELL! :P Thanks a lot!

</comment><comment><USER55> Why.

</comment><comment><USER56> I was curious when I saw a tests folders, but it was just auto-generated files with no actual tests. =(

<comment><USER26> Swift hasn't even been out for 24 hours yet, give the guy a break! ;)

</comment></comment><comment><USER57> Share the latest about Swift here! Be part of the biggest page for the language. Looking for admins. [https://www.facebook.com/swiftofficial](https://www.facebook.com/swiftofficial)</comment>


USCIS Will Remove "Nation of Immigrants" from Mission Statement - <AUTHOR> https://theintercept.com/2018/02/22/u-s-citizenship-and-immigration-services-will-remove-nation-of-immigrants-from-mission-statement/ <comment><USER2> I wish that we, the people of the USA, had a voice in how our government thinks it should represent itself. The fact that the word 'customers' is removed is just a distraction from having removed "nation of immigrants". This country is becoming less of an immigrant nation.

What are the implications of this besides a change in words? Does the department now get to make claims about not having to assume certain responsibilities because of the altered mission statement?

<comment><USER3> I can tell that USCIS has not been doing well lately. Look at how far behind they are in terms of issuing Employment authorization cards. You can look far back in the thread and see how fast it was in previous years. Now it's full of complaints.

[https://www.immihelp.com/experience/view-2-6-ead_work_permit...](https://www.immihelp.com/experience/view-2-6-ead_work_permit.html)

</comment></comment><comment><USER4> Isn't this a meaningless statement to begin with? Every nation is a nation of immigrants if you go back far enough.

<comment><USER5> Not really. Unlike other nations, the idea of modern american nation was born from the hard work of european "immigrant" pioneers going back only a few centuries and that of other immigrants thereafter. This just seems more like closing the door behind me.

<comment><USER4> This is what happens with all nations. Germany for example, being settled by the Volkswanderung (migration) in the 8th Century, which displaced the previous inhabitants. Every nation starts as a nation of immigrants and then stops being so once it has an established population.</comment></comment></comment>


Former Magento CTO/Co-Founder: eBay Doesn't Understand The Meaning Of Open - <AUTHOR> http://techcrunch.com/2012/04/12/recently-departed-magento-cto-and-co-founder-ebay-doesnt-understand-the-meaning-of-open/

<comment><AUTHOR> This does not look good for the future of Magento.</comment>


Is a shared database in microservices actually an anti-pattern? - <AUTHOR> https://hackernoon.com/is-shared-database-in-microservices-actually-anti-pattern-8cc2536adfe4 <comment><USER3> There's a bit of an emperor's clothes problem with microservices. If microservices are never combined together, they are essentially monoliths under a cooler name. But as soon as you combine them, you run into the same problems that are solved by traditional shared database systems. Here are two: cross-microservice referential integrity, and cross-microservice transaction coordination, but there are plenty more.

Take the Orders/Customers example of the article. Assume the Customers microservice has some notion of identity, and that the Orders microservice contains a "foreign" reference to Customers identity. If the microservices are truly independent and autonomous, then the Customer microservice should be able to change its scheme for Customer identities, or a delete a Customer. But then what happens to the Orders that reference that now old and outdated Customer identity? If changing the Customer microservice breaks the Orders microservice, then what's the point of the separate encapsulation? Traditional shared database systems have ways to deal with this kind of referential integrity. As far as I can tell, this issue is ignored by microservice architectures. As is the larger issue of cross-microservice constraints (of which referential integrity is just one instance).

The thing that really gets my goat is the lack of cross-microservice transaction coordination. In its place, we get all sorts of hand-waving about "eventual consistency" and "compensating transactions". Growl. Eventual consistency has a meaning that's related to distributed/replicated storage and the CAP theorem. Maybe its principles can apply to microservices, but the onus is on the microservice proponents to actually connect those dots. And most importantly, eventual consistency is implemented and supported by the DBMS, not by application developers. The thought that each microservice will independently implement the transactional guarantees of consistency and isolation should fill everyone with dread. That job should belong to the overarching system, not to individual microservices. It's too hard to get right.

So for now, shared database in microservicew is _not_ an anti-pattern. It may be the only workable pattern. When microservice frameworks grow up and offer the capabilities of shared database systems to microservice developers, then we can talk about anti-patterns.

<comment><USER4> If you back your microservice architecture with a shared RDBMS and expect transactional and referential integrity, you've only scaled some parts of your system. Instead you should think about if A: you really need that scale ability, and B: the real implications of it.

So, in this customers / orders example what if you delete a customer? Ideally you don't, you keep the customer as long as you need the orders. You could perhaps anonymize it. And you define what happens if you cannot find the customer. Perhaps the orders should just be deleted? You could have a service running nightly that prune orders from customers that does not exist anymore. A cleanup service that checks for external dependencies and prune them as needed (note, this can be rather dangerous if done wrong).

For people that have formal education in distributed systems, or work with them, this seems very familiar, because it's some of the same things that make distributed systems hard. And that is what a microservice architecture is - <USER2> distributed system, which is why it scales well when done right.

This is also a problem we've mostly solved with CQRS and event sourcing, but it requires a lot of manual work and orchestration. It's hard and I can only say - you probably do not need a microservice architecture, and if you do, hire people with real experience in distributed system architecture. They're expensive, and if you can't afford it you do not need microservices.

<comment><USER5> The system can simply mark the "deleted" customer as a former customer and add records of their dismissal without any referential integrity problems. "Deleting" an entity doesn't mean that it should immediately vanish without a trace from the database, leaving a wake of destruction. It's only a business- level change: we won't accept further orders from deleted customers, there might be something nasty to do to their outstanding orders, and so on.

<comment><USER4> Doesn't address the problem of a customer somehow vanishing from the system without notifying dependent services. With at least once message delivery we know that the order service will know at some point, but we need to handle the case in the mean time.

It could also be a possibility that we need to delete customer records pr. GDPR, but need to keep the order records due to other laws, perhaps in an anonymized form.

<comment><USER5> Are you advocating sending and processing notifications about customer changes so that the order component can maintain redundant stale copies of customer data? Why would one do that instead of an appropriate and selective query when e.g. a new order is being entered?

<comment><USER4> For a MSA system, yes it should maintain just enough knowledge about customers to work, not everything. For instance it does not need to know the customers name, just the id. Systems that query the orders can query the customer component for additional data.

The denormalization and distribution of redundant data is required for it to scale. If you make the order component query the customer component, you haven't solved the problem from the other way around, and suddenly you have a hard coupling where a transient failure in one component automatically fails the other.

It might not be a tradeoff you're willing to make, but then you probably do not need the scaling - at least not along that vector.

</comment></comment></comment></comment></comment></comment><comment><USER6> Yes, shared database is an anti-pattern in micro services architecture.

If one shared database can serve your system well then you don't need microservices. You should build a monolith instead.

The main reason for using microservices is scale. First ability to scale development teams and secondly ability to scale the infrastructure. With microservices you get vertical sharding out of the box. Yes it means dealing with eventual consistency for at least a few usecases. But any system that wants to serve millions of concurrent users needs to deal with eventual consistency as some sort of vertical or horizontal sharding is necessary at that scale anyways.

<comment><USER7> How many services actually have millions of concurrent users? That's 100k req sec or so, which is a crapton.

<comment><USER8> Probably less than 1% of corporations deploying microservices actually have a load that justifies microservices.

</comment></comment></comment><comment><USER9> My understanding is that the point of microservices isn't to just move what would have been a relational join in SQL to an equivalent join in the service layer, which is what the author is implying. Instead, the order service should already have the subset of user data it needs to perform its function. If a user name changes, for example, that would trigger an event that gets consumed by a handler in the order domain. You embrace some denormalization and duplication of data in order for each service to have as much of what it needs to perform its function without a ton of other dependencies.

I'm not saying this is necessarily the way to go, I'm just saying that this is my reading of the microservices design pattern.

<comment><USER10> Yeah, microservices and event sourcing go hand in hand.

Each microservice maintains its own database, with a model that is tailored to its own domain. This is called a projection, to illustrate that it is really the service's own view on the world, often with redundancy of data.

The service sources just the events it needs, and stores only the data it needs, to maintain this projection. It handles domain object lifecycle events in the way that makes sense for that particular service.

<comment><USER11> > Each microservice maintains its own database, with a model that is tailored > to its own domain. This is called a projection

In DDD land this is referred to as bounded context.

</comment></comment></comment><comment><USER12> If your problem could be solved with buy rather than build, for services that you buy (e.g. could conceivably exist via AWS in your perfect world), then microservices may be a smart idea - if you can fork off a team to own that ideal service, you can eat the integration costs because you don't need to deal with the complexities of keeping that service running, it doesn't add to the total cost of ownership of getting your code running in production, it's just another remote API with an SLA.

In that situation, the other services sharing your database is madness. Of course they shouldn't use your database. If they did, it would mean you're responsible for their load; you'd need to balance your needs with their needs. When your database goes down, their service and its clients (that you don't need to know about) would also go down. No good at all. Don't do that.

And if you're not in a situation where different teams are responsible for different microservices, you probably shouldn't be using microservices.

</comment><comment><USER13> Completely agree with the article. If each piece of code has its own data store, you lose all the advantages of the DBMS: you have to handwrite your joins, your transaction system and get all sorts of problems with cache invalidation, data inconsistencies and n+1 fetching. Encapsulation is important, but there are better ways to do it, such as using the authorization system of your DBMS.

<comment><USER14> The only thing that needs a relational data store are reports. Operational data stores should only be concerned with their own domain and expose behaviors and events. There are exceptions, but if you're building a complex system, monolithic architectures have a known lifetime while MSA's tend to mitigate long term coderot.

It's hard to see this until you've built domain driven micro service based systems properly.

<comment><USER12> The trouble is, if you push state into different services behind APIs, you end up reinventing 50 to 80% of RDBMS anyhow. You need transactions, replication, indexing, integrity, backups etc. etc. You can use an event stream (a substitute for a commit log) but then you need to migrate your event stream, be able to undo events in the stream, etc. It's complexity you really ought to avoid unless you need it for serious business reasons.

Monolithic architectures have tended to last for decades in mature industries. I don't think we have a good handle on the lifetime of microservice architectures yet - typically, when they come into being out of necessity rather than fashion, they're part of a startup that hit a major hockey-stick and needed multiple teams working concurrently without stepping on each other, and microservices serve an organizational purpose rather than an architecture purpose.

I will second what other people say: the database tends to stick around. Code may rot, but the data is reused by the next generation.

<comment><USER15> > multiple teams working concurrently without stepping on each other, and > microservices serve an organizational purpose rather than an architecture > purpose.

I so hard agree with this.

</comment></comment></comment></comment><comment><USER16> This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bulletproof either but I've seen it helps reduce this occurrence a lot. Pardon the poor examples

<comment><USER17> This is the most important point when making microservices. There's lots of talk about bounded contexts but very little about how to draw the boundaries. Most are superficial and repeat bad examples like OrderService (order is both a verb and boun, OrderingService sounds ok). Using two part service names (ContentComposition, MessageDelivery) usually works out well.

As to the shared db aspect, while spitting a miniservice into micro ones I had this situation. All the code was split first and the db changes being the most difficult to was done last as a point.of we don't expect to revert this.choice. We weren't at a performance limit so that was fine, any schema changes had to be clearly communicated and coordinated. In all not too bad. I don't think I'd want to leave it in that state as a normal state. The point of micro is Independence and isolation of changes and sharing a db leaves a sensitive area. Don't let that stop you if it's only a temporary state. Just get commitment as to how temporary that is, since in absolute terms everything's temporary.

<comment><USER18> Why would you make Miniservices?

<comment><USER17> We never had the intention to make miniservices. Some were microservices that acquired abilities that grew to become separate microservices. On other projects they were prototypes that lasted long enough and became small monoliths to get split up.

</comment></comment></comment></comment><comment><USER19> From my expirience, at some scale (system and organization) it became a easier to solve technical issues of having multiple DBs than dealing with bottlenecks on 1 shared DB. We had a fleet mucroservices that used 3 semishared DBs (1 for 1 domain, 1 for another domain and 1 shared). It worked ok for a year and now we run 40 DBs. It is harder to maintain and harder to develop against, but we are not constantly stuck in redeploying half of the stack because scheme just changed.

So, no silver bullet. You need to use something that makes sense, not what is fancy today.

</comment><comment><USER5> I don't understand the problem. If the report needs order details and user details, and current data isn't available because some piece of the system has a problem, there's going to be no report today regardless of what the database is like and what concerns are separated or not. C'est la vie.

Moreover, the real dependency is from the report to the orders and the users; the article takes for granted that the report is shoehorned into the orders component, but it's clearly arbitrary.

</comment><comment><USER20> "Then it sends request to users service to get missing information about users" What information would an order need to know about the user except for its ID? Shipping address? That could have been stored in the order db. Usually there is an orchestration layer above these services such as graphql, that merges all the data together for presenting to the UI. Somewhere there needs to be a defined contract between service boundaries so that internals can be changed without affecting all dependent systems. The db is not a good place for this contract.

</comment><comment><USER21> A shared database offers the allure of transactions and persistent state management. But using a traditional RDBMS is not very scalable. Schema changes have hurt us many times. And then what of foreign keys and such. It is nice to be able to consistently open a single transaction and get an answer from the one true source of truth but it quickly becomes the single biggest bottleneck. I prefer the database per service model and leaving a global transaction manager to be implemented if needed. I think it adds much more in flexibility and scalability.

</comment><comment><USER22> Don't ask if X is an "anti-pattern". Ask if X makes sense for YOUR project in YOUR context.

</comment><comment><USER23> Microservices are an anti-pattern.

<comment><USER24> I'd say microservices for the sake of microservices is an anti pattern. Microservices does have their usages.

</comment></comment><comment><USER14> I'll take the hit on my karma and just suggest readers of this thread read the comments of the original post on hackernoon.

There's a clear demonstration that MSA and domain oriented data stores are based on a decade of service oriented architecture design and development.

</comment><comment><USER18> If you don't even need to split out the database you probably don't need Microservices.

</comment><comment><USER25> If you can't split your databases then maybe you don't have a correctly established domain? There is no point of doing microservices when you still have tightly coupled data and you don't know how to split them efficiently. Monolith is not bad if it is well structured, tested and maintainable. Otherwise, you'll have to change multiple services for adding a new field of data.

</comment><comment><USER26> One pattern is to subscribe to an event bus and retain a read-only replica of your dependency's data. So the CustomerService publishes a CustomerModify operation which is picked up by the OrderService which then knows the new value of the customer's shipping address. If CustomerService wants to make backwards incompatible changes to its schema it should be handled by versioning so the CustomerService has to broadcast both versions of its message until such a time as all subscribers are using the updated version and then it can 'deprecate' the old message version. Ideally OrderService is using a library provided by CustomerService to handle applying CustomerModify messages so the next time OrderService is deployed (which should be continuously right?) it automatically picks up the new schema so this is a painless and automatic affair.

</comment><comment><USER27> Looks like author does not know you can split business domain without making microservices...

</comment><comment><USER28> > Is a shared database in microservices actually an anti-pattern?

No, unless you dont want (or care about having) a single source of truth. If state is distributed its harder to backup/restore/rewind or even query atomically and reproducibly.

You could still make the single database sharded and duplicated though, but still: in most cases its still one shared database. Even storing Files outside of a DB is just sharding, important thing is the DB refers to the file and still is the single source of truth.

And when you want vertical segmentation see designs like multi-tenant, but its still not a database per microsevice: quite the opposite.

When you dont want a single source of truth you could do without it ofcourse.

</comment><comment><USER29> The real answer: It depends.

But since most of the devs and architects fail to identify when you are allowed to do it, the rule of thumb is to not do it as it is a safer option.

</comment><comment><USER30> My take is yes. Shared infrastructure is always a risk. It seems to encourage other bad choices.

Yes, you can design around it. Good discipline around libraries with schemas, and such. These are almost always more code than letting a service own all communication with an infrastructure.

</comment><comment><USER31> If you have database that can scale its QPS linearly with number of machines in the cluster, maybe it stops being a bad idea?

That is basically what is happening when using a service such as S3 or many distributed databases...

</comment><comment><USER32> Database is just another service which does not speak protobuf. Use it as a dependency or use multiple ones depending on your context.

</comment><comment><USER33> TLDR: How to get all of the disadvantages of microservices and none of the benefits

</comment><comment><USER34> Shared database is an antipattern.

Microservices can be an antipattern by themselves, btw.

</comment><comment><USER35> Yes, yes it is.

</comment><comment><USER36> Yes, because any artificial linkage that prevents one service from scaling independently from another violates the separation of concerns principal.

</comment><comment><USER37> What if microservices are actually an anti-pattern?

<comment><USER38> Anti-pattern is strong but I'd go with premature optimization because most developers grossly overestimate their ability to create the correct architecture ahead of time and underestimate the performance, maintenance, reliability, and security costs. Most of the times I've seen a $$$ app struggle to match 90s single-server app performance it's been because the team was struggling under the weight of unnecessary architecture.</comment></comment>


Ask HN: Rust – does it get better? - <AUTHOR> I've started learning Rust in my spare time. Like most people, it's been an uphill struggle getting used to thinking in terms of ownership and borrowing.<p>Obviously this will get better with time. What I'm wondering is, how much? Once you really master the borrow checker, are you able to move as fast in Rust as you can in other languages, or is there always overhead in the form of added concerns to think about and work through? Does borrowing become second-nature, or does it remain a tradeoff? <comment><USER2> Yes and no. Once you've got some practice under your belt, you'll be able to decide what the ownership structures will look like ahead of time. You'll either avoid circular ownership entirely, or you'll decide ahead of time that you're just going to have to bite the bullet and use runtime bookkeeping of some kind (Rc/Arc/etc). A lot of this is domain-specific knowledge though; if you've gotten really good at writing a game using ECS then the specifics of that might not help you much if you start writing a line of business app or a web page. The ownership and borrowing rules are the same though, so it's not a complete loss.

</comment><comment><USER3> In my experience it does get better, but for most of the people to expect to be productive as they would in Golang, Python, etc would be unrealistic. Rust changed my thought process permanently because it forces you to think a lot of things upfront. Also, this "skill" is transferable to other languages which makes learning Rust worth it at the first place.

</comment><comment><USER4> If I am not missing libraries, I'm faster in Rust. I spend way less time debugging and writing tests. YMMV.

The borrow checker doesn't cause thinking, it removes it. I just write code, the compiler checks my work and tells me how to fix things when it messes up.</comment>


Nallex Software Professional Network - <AUTHOR> https://www.nallex.com

<comment><AUTHOR> We recently launched this website for software developers. Come and check it out.</comment>


Heaps – Haxe game engine by the language's creator - <AUTHOR> https://heaps.io <comment><USER2> Awesome! I would like to point out that two of the example gifs are from the game Dead Cells[1] which is a _fantastic_ action rogue-like with super tight combat and controls.

So if anyone's wondering if this engine can handle "AAA" game requirements, it already is!

[1] [https://dead-cells.com/](https://dead-cells.com/)

<comment><USER3> Thanks for that tidbit, I was wondering if 'anyone' was using it.

Though, I don't think that's what understood generally as an _AAA_ game:

[https://en.m.wikipedia.org/wiki/AAA_(video_game_industry)](https://en.m.wikipedia.org/wiki/AAA_\(video_game_industry\))

I think Dead Cells was made by 11 guys, so more like indie than AAA scale.

</comment></comment><comment><USER4> Heaps is more of a game framework than engine. Though it is very high level. It gives you flexibility. The problem is that it lacks in documentation, real world examples etc.

</comment><comment><USER5> I'm tired of "game engines" that aren't. There's more to game development than exposing a load-update-draw loop and providing bindings to libraries. The most frequent example of this is a game framework when accurately marketed.

But I've come to call tech like this a "game software suite" when sufficiently advanced. Further, software like Unity and Unreal Engine are also just game software suites. They aren't true engines, because you _still_ have to write everything yourself.

Imagine someone provided you the metal and engineering concepts to build an engine, but never supplied the engine itself. That's consistently, time and time again, what the games industry on the hobbyist side has provided.

Well, thanks for providing bindings I guess. Any sufficiently advanced language with an FFI can automatically do most of that work for me.

But it isn't a game engine in the same respect as any of the Quake, Source, IW engine, or derivative engines.

Where's my console? Where's my UI layer? Where's my map loading and format? Where's my multiplayer? No server browser protocol or architecture? No matchmaking? Where's my key and controller binding system? Oh, there isn't one?

It's not an engine. It's a collection of library interfaces.

Library => Framework => Engine. What's missed almost every single time is that to build an engine, you actually need a framework to dictate how a game loop performs behaviors, schedules, tasks, entity dispatch, sound emitters, and how all of these things should be networked and how they should work over split- screen or on difference devices.

If you see something exposing load-update-draw, it's at best a framework. Like the XNA of yesteryear or the LÖVE of today, that's what it is.

But a true game engine doesn't have you building your own console variable and replication system. It should come out of the box. That's the point.

That's the entire point. And if you're not working on nearly exclusively game logic, you're probably not working on a game engine. Or you're sure as hell doing both engine and game development with a half-baked game software suite.

</comment><comment><USER6> What counts as a capable/modern GPU for this?

</comment><comment><USER7> No Physics system?</comment>


Falcon 9 rocket lands, then falls over and explodes - <AUTHOR> http://www.theguardian.com/science/video/2016/jan/18/spacexs-falcon-9-rocket-lands-then-falls-over-and-explodes-video <comment><USER2> A hopeful explosion, considering the circumstances! This particular failure would have happened even with a dry-land landing, and future flights will be using the upgraded landing leg design that landed successfully back in December rather than the older one used on this flight (for scheduling reasons). The good news is that, for the first time, they managed to do a soft landing on the barge -- and they did it in nasty weather, with huge waves. Looks like whatever improvements they've been making to their control software are working well.</comment>


Broadening Node.js Contributions - <AUTHOR> http://www.joyent.com/blog/broadening-node-js-contributions

<comment><USER2> Bryan Cantril (the writer of the article) is an interesting and ebullient dude. If you haven't seen him talk take a look: here's his talk on corporate anti-patterns (as referenced in the article) [http://www.youtube.com/watch?v=NhgXQFk9noI](http://www.youtube.com/watch?v=NhgXQFk9noI)

</comment><comment><USER3> Great! Now if they'd commit to not publicly crucify those contributors over overblown scandals, I might consider giving node.js another look.

<comment><USER4> Funnily, Bryan's the same person who also showed contempt in crucifying one node's largest OSS contributors in public is now seeking to attract more contributors to the same project?

The 2 character pull-request that took down libuv's largest and one of node's largest ever contributors: [https://github.com/joyent/libuv/pull/1015](https://github.com/joyent/libuv/pull/1015)

Bryan's public Crucifixion of Ben: [http://www.joyent.com/blog/the-power-of-a- pronoun](http://www.joyent.com/blog/the-power-of-a-pronoun)

Ben Noordhuis's Response: [https://github.com/joyent/libuv/pull/1015#issuecomment-29568...](https://github.com/joyent/libuv/pull/1015#issuecomment-29568172)

and HN Story of his Departure: [https://news.ycombinator.com/item?id=6845286](https://news.ycombinator.com/item?id=6845286)

No thanks, I can't see myself ever touching or recommending Joyent's services as a result.

<comment><USER5> Good luck finding a community of any significant size that hasn't had some drama in the past.

Ruby, Python, and NodeJS have all had their fair share of issues. Even GitHub had a fracas.

Nobody gets a free pass, but mistakes will be made. At what point do you call those problems resolved?

<comment><USER4> Name me another that's shown this much contempt to a core contributor?

Joyent has never apologized to Ben or thanked him for his years of efforts (despite many from the node community and other contributors having done so).

<comment><USER5> There's been lots of douchebaggery going on in other language communities. That it hasn't exploded into a giant fiasco is something of a small miracle.

</comment></comment></comment></comment></comment><comment><USER6> When the startup I previously worked for was acquired, a Google CLA I had signed while at the startup was the source of much contention between the startup's and acquirer's lawyers, and caused much last minute stress for the startup's CEO.

AIUI, acquirer's lawyers contended the CLA might grant Google leverage over the acquirer's patents.</comment>


Cuil Whipped. Cuil has dropped to almost zero usage share. - <AUTHOR> http://marketshare.hitslink.com/report.aspx?sample=18&qprid=38&qpcustom=Cuil&qpsp=3497&qpnp=34&qptimeframe=D

<comment><USER2> This is sort of silly. Cuil _never_ got above "almost zero" usage share. There was a horribly ill-timed splash during launch which resulted in a lot of visits for a week or two--they were obviously way too early, since most Cuil searches are disappointments. So, none of those user stuck around.

Cuil was stillborn...it hasn't "dropped", because there was no room at the bottom for it to go lower. The chart just shows a spike like the one that happens to every new startup that gets some press.</comment>


Norway's sovereign wealth fund said it had lost $124B this year - <AUTHOR> https://www.reuters.com/article/us-health-coronavirus-norway-swf-markets/hedge-fund-manager-to-lead-norway-sovereign-fund-after-124-billion-loss-idUSKBN21D1H4 <comment><USER2> >Its investment portfolio dropped 16.2%, all but erasing the 20% gains made last year

When pretty much all major stock indices drop by 30% this is a remarkable win. I'm impressed they it's such a small percentage of the fund that was lost in this climate.

Also how the hell did they make 20% last year. I guess it's true that the big funds like this are simply way ahead of what any individual could ever hope to achieve. Consistently smaller losses and bigger wins year on year.

<comment><USER3> They largely divested from fossil fuel for both environmental and diversification purposes which certainly helped their returns.

<comment><USER4> I could see that over the long term, but in one year? If divesting from fossil fuels worked that fast, wouldn't everyone have done it already?

<comment><USER5> They timed it well. In other years, divesting from fossil fuels would have meant underperforming the market (which they would probably have been fine with) but they chose a good year to do it.

</comment></comment></comment></comment><comment><USER6> Can we change the title to something less click-baity? They are still up for the year.

Not to mention that it's incredible the wealth fund has done so well in relation to such a tremendous bear market.

</comment><comment><USER7> Most fund managers would probably be happy that their portfolio only dropped 16%, with a gain of 20% one year before...</comment>


Google Brain's Quoc Le explains 'deep learning' in a minute - <AUTHOR> http://www.bbc.com/news/world-asia-35888482 <comment><USER2> I didn't see too much of an explanation on deep learning. It was more of just Quoc introducing himself.

</comment><comment><USER3> No, this video doesn't explain deep learning in a minute.

</comment><comment><USER4> Government funded website and HTML5 video is too much technology for their budget?</comment>


Ask HN: I just got fired from a startup. What now? - <AUTHOR> I've been working at a tech startup for a year as a software engineer. It was great - I learned more in days than I ever could by myself in weeks, and I looked forward to every single day.
But today, I was fired for the first time in my life (without any notice). The company's running out of runway and they can't afford everyone.
I understand where they're coming from, but I still feel a little betrayed. What should I do? Should I pursue an education (I never went to college)? What kind of company should I apply to next? Can anyone from HN give their input from a similar situation? <comment><USER2> "Fired" can imply that you were dismissed for misconduct, inefficiency, or some other individualized cause. If the reason was instead your employer's lack of money, you should say that you were "laid off," even if no one else was let go today. That's not unusual in startup companies.

The difference is important, not only for prospective employers, but also because it may affect your eligibility for unemployment benefits.

</comment><comment><USER3> 1\. Ask if they would feel comfortable recommending you. 2\. Apply at a better run startup. 3\. ??? 4\. PROFIT!!

Seriously, I get the best recommendations and referrals from former colleagues at failed startups. We were in the trenches together. It forms a special bond—even if you don't always win.

<comment><USER4> > Ask if they would feel comfortable recommending you

great suggestion.

@op -- if you can cool down from feelings of betrayal, contact your former manager / the company in a polite and professional manner and ask if they are comfortable recommending you / being a referee for your job applications.

there's a good chance your manager is genuinely unhappy to have to lay you off, and would prefer to keep you on if not for running low on cash. it doesn't cost your manager much to provide you with a strong reference, provided they're comfortable doing so.

re: op's comment

> I understand where they're coming from, but I still feel a little betrayed.

maybe think of this as a useful (but harsh) lesson -- when you are an employee, your relationship with your employer is a business relationship, that can be terminated by either party at any time (subject to terms in the employment contract & applicable laws ...). your employer isn't your friend, your employer isn't your family, it's just business.

> Should I pursue an education (I never went to college)?

if you're at a point in your career where you can get paid a liveable wage (or better, a good wage) to learn a bunch of useful and valuable stuff on the job in a role that you largely enjoy, why not keep on working?

> What kind of company should I apply to next?

personally i suspect that the value of working at a startup as a humble employee is over-valued . consider applying for more established and profitable businesses that value software development. personally i find small companies more enjoyable (provided there's a good fit with the team) but larger companies may be able to offer better pay & benefits, have more opportunities for advancement, along with more politics and frustration.

</comment></comment><comment><USER5> How much professional experience do you have? If it's more than 10 years, the degree probably won't get you much at this point. If it's less than 5 years, a degree could be a huge boost to your career.

</comment><comment><USER6> Apply for unemployment, look for a new job.

</comment><comment><USER7> There's plenty of fish in the sea. Apply!

<comment><USER8> i agree</comment></comment>