snappy173

>Strictly interpreted, the 3rd amendment prevents the government from being able to force homeowners to quarter soldiers. If you think about the real intent of the bill though, it's obvious that the mindset is "you are free to use your own house without government interference."

that's a real stretch. that would nullify all zoning ...

>Clinton's staff was told that "use [of the BlackBerry] expanded to an unmanageable number of users from a security perspective

if you don't provide a secure way to get shit done, motivated individuals will figure out how to get shit done, security be damned. happens every time. that's what happened here.

The reason you require licensing for insurance sales is because it's very difficult to track all of the individual instances of malfeasance. So, the answer to your question is, "I don't know."

But just because I don't have particular instances of harm, doesn't mean this isn't an problem. If you let anybody sell health insurance, you end up with con artists selling sham insurance, and by the time you track down the conman, real people are hurt. Sure you can fine the shysters, or maybe even put them in jail (but probably not), but in the meantime, families savings are wiped out to pay the medical bills, or worse, people get sick and die because they can't get treatment.

Even then, you probably haven't solved the problem. A big reason that these products are structured as "startups" rather than within bigger companies is to limit the liability if they fail catastrophically or get caught breaking laws.

Investors keep pouring gasoline on the fire; the message is "GROW GROW GROW" ... but if the fire burns out of control, it's somebody else's problem.

sorry if that came off harsh, but that is actually the feedback, and it's valid. whether or not javascript/node is better or worse than python, it's pretty clear that bringing a python style approach to nodejs is going to cause problems, especially with error handling and async stuff.

>async/await

in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.

the feedback is: stop expecting javascript to act like python

> I'd like to add one more: Admitting when you don't know the answer

I'll +1 this, but with a slight caveat. Some interviewers don't get it, and will ding you for this. Those are the companies to avoid.

graph sounds complicated. what about a web?

i find it downright scary. that such insane scale is a prerequisite for success leads to companies taking greater and greater risks. to achieve monopoly scale requires it. ignoring local laws and regulations becomes rational in this environment, as we have seen.

it's a matter of risk.

when you're trying to be a billion dollar company, you have to take big risks. in that context, the risk of getting caught for breaking the law becomes palatable.

when you're trying to create a stable, profitable, but more modest sized company, that risk becomes a threat to your business.

it's a big problem when these types of risks start to make sense from a business perspective, because it's the public, not the people that create this environment, that end up suffering.

I just stuck with d3, and used the react lifecycle methods to trigger redraws and such.

http://bl.ocks.org/cpapazian/6228888157c39be85e9c

The D3Component wrapper lets you put a d3-style reusable component inside of a react dom tree, using react props to pass parameters and event handlers to the d3 chart.

I made a react wrapper component for using d3 style components within react apps. It uses the react lifecycle methods instead of render ...

http://bl.ocks.org/cpapazian/6228888157c39be85e9c

Scroll to the bottom for the wrapper class. Please excuse the coffeescript.

on the other hand, es6 classes encourage named methods ...

In that case, you can have a redux state reducer look for navigation actions, and set current thread. Either way works well with the flux/redux mental model. And in either case, you'll have to implement logic for mapping route -> current thread and vice versa ...

well, when you use redux to manage the router state, you get the best of both worlds.

"current thread" doesn't need to be stored in the state in an explicit way. rather, you just need to be able to derive the "current thread" (or whatever) from the state.

so, your state contains the current route, and you use that to derive the "current thread" and then if redux has any state corresponding to that thread (or whatever) you can get that, too.

what if said company spends millions applying political pressure to oppose that?

"regulate the behavior"

what if the behavior is already regulated, but is difficult to enforce?

sticky notes!

>that's generally a sign that your tests and your code are too tightly coupled.

I think that's the point. These are tests written specifically to help with the transition from the old to the new code. They are pretty tightly coupled to both versions in that sense. Once the old code is gone, they are really only testing the new code, so you throw them away.

"Also, Coke has been around as an ingredient for a long time in BBQ because BBQ sauce has to have... sugar."

and acidity. it's kind of perfect.

"that people need and deserve more income."

for some, income is just a means to an end.

airbnb isn't providing this extra income for free. it expects hosts to provide a service, which requires work, which requires time and energy.

if that extra income is just offsetting the rise in housing costs, then quality of life is decreasing ...

No. The concern is that it makes it easier for the wrong type of people to get there ... from Oakland, etc.

It's ironic ... The NIMBY's didn't want the BART to go through their neighborhoods, but having two stops in Mission is part of why it's so attractive now.

easier said than done. every system has its own perspective of the patient, but you can't simply share that. there has to be a canonical format that works in multiple contexts, but all of the so called standards have been horrible.

just consider the case of drug records. most standard vocabularies are based around the pharmacy's view of the data, which does not work for prescribing meds. and then there's the problem of importing data ... you're usually downloading a prescription history, but what the doctor almost always wants is a record of meds the patient is currently on ... not prescriptions from years ago. and then there's privacy issues when it comes to certain specialties that make it difficult to share prescription data freely. and this doesn't even get into all of the units problems that lazy software developers can't ever get right!

well, 'saison' is french for 'season'.

it's very much not XML. it's closest to javascript.

baseball, as with all sports, has a long and storied history with using various performance enhancing drugs to cope with injury and fatigue. amphetamines were commonplace in ball four ... bouton casually discusses greenies, players' coffee vs. regular coffee, etc. there was a sporting news snippet from the 1910's (that i can't find right now) that discussed pitchers dealing with arm fatigue ... the takeaway was that some pitchers preferred cocaine injections, while others preferred morphine. and then there was the steroid era ... lots of attention of course to creating cartoonishly large players, but most of these drugs were to shorten recovery from workouts ... you don't magically get huge from taking steroids.

"I actually think its a really good reason why it often goes wrong in the sense that most governmental agencies always think they need to somehow customize to their unique needs."

yup! and it's the agency needs, not the needs of the actual user that are unique and special and require customization.

a big reason that GDS in the UK is having success is that the user need always comes first.

I think pg forgot that he is in the privileged position to be handing out large sums of money to these people.