skysight-inc/HackerNews huggingface dataset:
One big question I didn't discuss is how to evaluate the prospects of the employing company, and I didn't discuss it because I didn't come up with good advice. Companies differ tremendously.

In particular, I personally was spoiled working for a company where the founders are very good negotiators, apparently even better ones than the various i-bankers they dealt with. For instance, they never took any VC money, presumably under the assumption that VCs might decide to gut the company if it doesn't become profitable in a time frame which for them seemed too short. They also made sure to raise tons of money years and years before running out of already-raised money; the conventional wisdom is you're not a bank and you should only raise capital when you absolutely need it, you shouldn't have stashes of idle cash, but the problem with this approach is that you raise money when you're desperate and this diminishes your bargaining power tremendously. Raising money long before it's really needed resulted in really good deals for them.

I was also spoiled working for a company with a simple business model and pretty predictable revenues so it wasn't that hard to put a conservative lower bound on its future value.

Anyway, I only addressed the really wrong arguments that I heard a lot, that after a late-stage investor gets on board the stock "can't possibly rise any more" (meaning, the late-stage investor is at best going to not lose money but can't possibly make any, so they're much dumber than you are); and, "even if it rises, it'll just rise a little" (which neglects the arithmetic of how your capital gain is calculated.) Your argument is different and I confess that I don't have any stats to either support or refute it.
I still believe that for recent graduates looking to begin their career, there is no better option than to join an early-stage startup. Admittedly, it's like buying a lottery ticket, but if you win you can win very big and give your career a massive boost. On the other hand, if you lose you have still gained valuable career experience equal to or greater than what you could have gained at "GiantCorp". More importantly, early stage startups offer employees a broad but shallow understanding of businesses, versus GiantCorp's narrow but deep understanding. This is important for young employees who may not be 100% sure what they would like to specialize in yet.
I'm curious what your reasoning for thinking Russia and China are behind israel on this is? Surely Russia and China have put a lot more resources into this than israel even has...
Your comment about money really alleviating some issues was exactly to the point. I recently lost both of my parents and my family has a few issues. I got a raise recently and my inheritance is worth few years wages. Money does not help with the pain of loss but these 'other issues' would be considerably more stressfull with less of it.
They used to teach this exact same class to every 8th grade student -- it was called home economics. There is a very close relationship between home economics education and health. It is now called family and consumer science but political correctness put aside home economics describes it quite nicely.

The first woman to enter MIT, Ellen Swallow Richards [1], invented the field of home economics. After reading about her, I realized much of home economics is about health. Because we got rid of well defined gender roles doesn't mean we should get rid of home economics.

[1] https://en.wikipedia.org/wiki/Ellen_Swallow_Richards
On the other hand, traditional banks can easily copy all these features if they become important to customers. I'm not sure they can be long-term differentiators - unless software patents, which fortunately here in Europe are much less strong than in the US - and I don't see any network effect to give the first mover a strong advantage.
Nonsensical statement. There is no other kind of enforcement than that done in the interest of the patent owner.
Every language / framework has its tooling options but javascript has a lot and no standard/preferred ways. Like with standards, it seems that tooling problems are solved by creating new / more tools.

I have a strong Python background and I'm overwhelmed by the tools available for just building / managing javascript and making it usable. With python (for example) you don't need additional tools for managing/defining/importing modules, building/compressing/minifying code or adding additional language features.

The solution for me was to switch from Angular (where I had to make all choices myself, which I wasn't capable to do) to Ember(-cli) that is making the choices for me. And the lack of such a tight integrated supported set of tools is what is and will keep me from moving to other frameworks in the forseable future.
Agree with that attitude, you'll never have enough neurons to follow all the things released. The key is to pick only the minimum you need and forget about the rest. Anyway, as Knuth says, premature optimization is the root of all evils.
I agree with your standpoint (first two paragraphs).

> Intercooler.js

Why not '<a data-action="/click">' (HTML5 data-* attributes feature!) instead of the non-standard '<a ic-post-to="/click">' ? http://caniuse.com/#feat=dataset
"software patents (which have merits)". There are none.
One MS place I worked were adamant that 3 tier meant physical separation as well; e.g. frontend servers, BL/middle-tier servers and database and duct-tape everything together with webservices or binary serialization. Thats when you know you are /really/ wearing your big boy pants to work.
No, I'm disbelieving the claim that it's broken.

Same thing that saying you don't believe in god does not mean you believe there is no god.

In both cases, I'm just saying not enough evidence has been brought to support the claim (that the system is broken and that god exists).
This article is blogspam of https://theintercept.com/2015/12/23/juniper-firewalls-succes.... Submitters: when an article is just a rip of a more original story, please submit the original story instead, as the HN guidelines ask.

We've buried this submission because it is a dupe of https://news.ycombinator.com/item?id=10784595.
The guys have also done a presentation on this in Hamburg a couple of days ago: https://events.ccc.de/congress/2015/Fahrplan/events/7368.htm...

Cannot find a recording yet
Trouble is, I know a lot of people who used this extreme approximation to their detriment.

In general, there's a huge difference between "worthless" and "cheap". If it's cheap, you might want to get more of it - and then it's valuable. If it's truly worthless, getting more does not help. That's how multiplication works with small numbers and with zero. Zero is a special small number.

So I claim that "equity is cheaper than they make it sound" is absolutely the right thing to say to yourself (not to the employer), while "equity is worthless" is a terrible thing to say to yourself if you then stay at the place. (It's potentially a sensible thing to say to yourself if you intend to leave, and especially if you're leaving for something that looks both good and not that risky.)
Not technical, but I thought it was interesting that it tags files with a record of every computer they have been on, even if it was not accessed. Or that privileged access is only really available to the government, and the operating system guards against many kinds of customizations that we think of as legitimate user actions.
FWIW, I believe people have said that Juniper was always using non-standard EC DBRG parameters. The backdoor changed those parameters to something else. So the NSA wouldn't have already had the parameters they wanted.
Exactly.

The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."
Information startups have the highest failure rate, but the capital requirements are lower than, say, mining.
Google Announcement – HTTPS Pages to Be Indexed First Before HTTP Pages
>The question is will they reach for a coke or a pepsi?

How about plain old cold water? Is a Cola much better at quenching thirst than plain cold water?

EDIT for clarity: The point is, the first question is not "Will they reach for a coke or pepsi", but "Will they reach for a bottle of cold water or a cola", then only the question of choosing between pepsi or coke comes.

So you first need to convince people that you should drink a cola when you are thirsty. This is where the "evil" part comes from.
The problem they are trying to solve will only really budge when we get an improved crowdsourced-based approach.
Webpack isn't really plumbing like a task runner, it's primarily a dependency wrangler. If you have a page template, which declares dependencies on various partials, each of which declares dependencies on images and JS modules and CSS partials, then Webpack can grok all those dependencies and do things like bundling the images/JS/CSS needed for this or that subset of pages (along with hot loading, source maps, etc.).

Of course, it can also do stuff like minification and transpilation while it does this, so it tends to get compared to grunt/etc. But the magic of webpack isn't the bundling, it's that you can build highly modular pieces of web content and leave webpack to work out what needs bundling.
It is, but there are simple ways around it:

- It helps if you can identify small, local "clusters" of stars. E.g. even in a very dark sky where you can see stars you never remember seeing, Orion's belt is very easy to recognize, because three collinear stars so close together are a fairly rare sight. Same for the North Star -- it's not too bright, but it's related to two very recognizable constellations and you can find the North based on other clues as well, so you know where to look. Once you've identified one constellation, it's pretty easy to find the other ones.

- It also helps if you're familiar with how the sky looks in various seasons. This way, you have a pretty good idea about what should be where. Granted, this probably doesn't work well if you have to travel a lot. My home country is pretty small; in its northernmost point, the sky looks pretty much the same as in its southernmost. If I suddenly found myself transported from Maine to Texas, I imagine I'd be in some difficulty.
> The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO...

False. React can be rendered on the server and sent in the initial request using ReactDOM.renderToString.

> You hate maintaining an entire application in Javascript...

No I don't. I'd rather write an entire application in JS than write an application (backend and frontend) in two different languages, or write a frontend as a series of ad-hock JS scripts. If I hated maintaining an entire app in JS, why would I maintain it using JS? I use JS for everything because I prefer it to the alternatives.

> a simple CRUD application for which client side rendering is unnecessary.

No one needs to do an SPA. The world got by just fine without it. For me, the reasons to do an SPA with ES2015 modules had to do with simplifying my frontend architecture. JQuery is easier to get wrong compared to the render-everything mindset of React.

> Google doesn't use AngularJS for Gmail.

Good for them. Angular sucks IMHO. That being said, Gmail came long before Angular, and why migrate when you have a working product?

> Facebook doesn't use ReactJS for Facebook.

Facebook doesn't use ReactJS for --everything-- on Facebook. The fact that React can be gradually migrated into an existing application is one of React's greatest strengths.

Facebook do, however, use React for Instagram. They even use webpack for this.

> Twitter doesn't use client side rendering.

Define client side rendering. When I scroll down on the page and new items magically appear, I would say that is client side rendered. The time to first see the content, using React, could be done by first rendering React on the backend. But why migrate when you got a working product?

> People are building a mountain of abstractions and investing so much time to over-engineer everything in Javascript. WHY?!

Is it over-engineering when it solves a problem and does nothing more than it has to? React renders views, that's it. You can render on the frontend, backend or both. React is easier to use than having many different JQuery-based scripts.

In short. React does one thing. It does it well, and it simplifies my UI code. How is this over-engineering? I could say the same for gulp (for me, easier than bash scripts), webpack (easier than makefiles), ( node+express (waaaaay easier than Java or C#), Immutable.js (makes things easier to reason about) and the rest of my pure JS-stack.
>Clojurescript is, let's be honest, never going to be natively supported in Google Chrome.

Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support.

But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm not sure what exactly you are referring to.
I love neither Windows nor MS Office, but I paid handsomely for these. Also, I don't know people who particularly love to integrate an ARM core into their chip, and I doubt that Apple, Qualcomm, NVIDIA etc. etc. love to pay $30M for an ARM architecture license which gives them the privilege to then reimplement the core themselves, but they all pay up.

On the other hand, I love independent animation, but I don't pay that much to creators and the average independent animation lover might pay less than me. I also love vim (perverse, I know) but I wouldn't pay for it what I pay for Office (Office opens documents that nothing else does and that I must open, while text files can be edited in endless free programs.)

This goes to show that love and money don't always go hand in hand, and is an example of the more general problem with picking winner companies: they're all very different. That's why I didn't say much about it: it's very hard to give good, general advice on this. (And if I could give such advice, I'd be off investing in companies with no time left for blogging.) That said, someone contemplating to work for a specific company might research that company and come up with specific reasons to like it; a bit like how you can prove that a given program terminates even though you can't generalize your strategy for an arbitrary program.
It's still on the curriculum in England [1], though the class is called something like "Food Technology". I don't know how well it is taught though — do most children still actually cook themselves for this lesson? It seems the curriculum requires that.

[1] https://www.gov.uk/government/publications/national-curricul...
Yes. That is what he said. He didn't claim a cause, he didn't say that it was broken or that the existing system is the reason that we are ahead.

It is undeniable that the US is successful and innovative. The burden of proof is on the people claiming the system is broken, because the end result does not support that claim. If you want to say that the US is succeeding despite a broken system, you have to prove that the system is broken because the success is already self-evident.
The Star Wars Saga: Introducing the Machete Order (2011)
New Year Resolutioners: Before you go ahead and buy that gym membership
The researchers put the tools they used and decompiled code on-line: https://github.com/takeshixx/redstar-tools
Wouldn't that considerably increase bloat?
There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?
Agreed, refactoring and functional changes should certainly be in separate commits, and ideally in separate pull requests. jacquesm can still have her/his rule to only change code involved in the course of functional changes; it's just that the refactoring and functional-change PRs will come in close succession and the refactoring PR exists only because the functional-change PR does also.
The JavaScript "community" feels like more a large country.
Ok, we changed the URL to that from https://www.rt.com/news/327161-credit-card-protocal-vulnerab....
I'm glad you bring this up.

That's according to Paul Graham, and I respectfully (and strongly) disagree with that definition; nor do i believe it to be the hacker news definition, as that is subject to the collective opinion despite whatever official stances may be taken.

But I recognize that ycombinator is certainly focused on that type of startup, and that they obviously have influence on HN.

But it is silly, and unhealthy, to solely focus on this narrow definition; which is why i often find myself highlighting it when it presents itself in a HN link.
You are so right!

I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast.

But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.
Too bad one can't donate karma here. You deserve a boatload.
"The company’s in-house lender, Vanderbilt Mortgage, charges minority borrowers substantially higher rates, on average, than their white counterparts. In fact, federal data shows that Vanderbilt typically charges black people who make over $75,000 a year slightly more than white people who make only $35,000."

Huh? This is not clearly an example of that.
That's not enough - that's just removing the current working directory. But unfortunately, the issue here is that DLLs are put into the same directory as the executable to be run.

You can't remove loading DLLs from the same directory as the executable on the OS level because many applications rely on this feature. This can only be fixed on a per-executable basis.
Dynamic module loading means that it would only increase disk usage. You could always package the modules separately if disk space comes at a premium.
What we need is Shadow DOM support: http://caniuse.com/#feat=shadowdom
The fat vs thin client cycle has been happening for far longer than web dev. It's been going pretty much since we have interactive computers. Neither strategy is really the right one, it depends on the context of what you're trying to do. If only all young programmers could be taught a history of programming class where they analyze old deprecated technologies that used to be popular, and form an understanding why they rose to prominence and why they faded away. Maybe we could avoid new generations making the same mistakes over and over again with different technologies.
I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant...). Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7c...) to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html
Ah, now I get it. I thought the "deleted" was a result of detaching that post.
Learn to Code, It's harder than you Think
There is no way to avoid all and any risks - you just can't have 100% safety and reliability. What you could do is push for increasing the safety (at the cost of something else, obviously). What you're looking for is preventing avoidable mistakes, and minimizing damage if Something Really Bad happens.
You'll probably find that they're targeting one of Linodes customers rather than the actual Hosting company.

As for the reason, it's normally trying to get money out of them, or just to take a website offline for a while (e.g. the DDoS is from a competitor).

Most attacks will continue until you can prove that your no longer affected by them and can clean out the dirty traffic, this is quite expensive to do though.
I have no problem with the "investing too much in exploration" part of his argument. But avoiding overinvestment is not what unleashes the tsunami of cash he's talking about. It's asset sales that should bring on that tsunami of cash.

What is the break even of oil companies' proven reserves after not overspending on investment? That is the all important question. If that break even is below future long term oil prices, as he seems to suggest, then these assets are worth exactly $0.
They talk about Javascript in the book:

http://www.fullstackpython.com/javascript.html
How much does music licensing cost for commercial use?
Hey, I was wondering if it is alright to play commercial music at Cafes and Restaurants without any licensing. I read about BMI and other licensing companies and found out that they charge for music licensing (being non profit themselves). If any of you happen to be involved in the music industry or have done something related to it, it would be great if you can walk me through the licensing process and also about the fees.

P.S. : Let's say I own a chain of cafes and I want to play commercial music.

Thanks! :)
Your 300k people/day metric conveys little information if we don't get an idea of the workload each user entails?
maybe the most insightful recommendation w/r/t the developer interview process i've read (approx. 3/4 through the post):

"A technical discussion makes a much better place to start an interview. One isn’t under pressure to perform. Instead, one gets the opportunity to talk, correct previous mistakes, listen, react, and, generally learn about the person. Communication is the most important thing we do as developers. All computer problems are people problems. Let’s interview like that’s the case. One walks out of a technical discussion usually feeling pretty good. Interviewees like to spout reckons. Interviewers like to hear and react to those reckons. We get to work out if we can work together based on how reasonable our reactions are, whether we’re willing to give ground where we’re wrong, and, generally demonstrate how we like to work."
For awhile, I kept seeing job posts at Theranos, which is how I know the name. I didn't know whether they were expanding or just had high employee turnover. The WSJ articles and the strange Glassdoor reviews (either totally love the company and CEO or extremely negative about the company and its ethics) leads me to believe that the WSJ is correct. The latest article with the video interview of the CEO, makes me think that she is incredibly smooth at spouting the BS, to the point of being a pathological liar. This company will be VERY interesting to watch during the coming year.