It's fair to point out they also sued after they issued a warning shot, in the form of a C & D.

I like your analogy of the site being forked. I don't believe for a 2nd that the companies scraping the CL data and putting a pretty UX on it were doing it out of any sense of altruism.

Or, they "dumped" free classified listings into the market, killing off competitors (newspapers), giving CL a monopoly.

Of course they "manage to beat" competitors, that's not hard for a monopolist. But it doesn't equate to "doing something right."

The whole suit is ridiculous from the consumer/society perspective. You can't argue that scraping Google to get CL listings harms CL in any way whatsoever. So the only TRUE reason to sue 3Taps (or their customers) is to retain the monopoly, plain and simple.

I'm starting to think that, on balance, CL may no longer be a net benefit to society.

I don't think that temporary part fabrication for critical assembly lines qualifies as overhyping 3d printing. That seems super reasonable :) A 3d printer in every house, completely removing the need for centralized manufacture or distribution, a bit moreso.

Would this actually be a pretty bad application of 3-d printing? I thought the metals were generally or exclusively done through sintering, and and for some reason (may be incorrect) it didn't do as well with tensile & deformation stress. Not to mention porosity. Seems like something a casted product would be better for.

Don't forget agriculture, aerospace/defense, banking. Hard to get bent out of shape when someone gets a slice of the pie that is trying to improve things.

"Those fears were not in the slightest irrational. People had really really bad reactions to the regular pertussis to the point that people routinely advised new parents not to get it for their children."

Simply not true. You can easily find my citations (including CDC). Please provide yours.

"So what's better a vaccine that doesn't work as well, that people are willing to take? Or a vaccine that works well, but far fewer people are willing to take it?"

The risk from Pertussis is greater than that of DTAP by a lot. This is like suggesting we take away seat belts because some people believe they'll trap them in a burning vehicle.

He asked for data and citation. Your claims should be easily documentable since companies did switch and presumably did so for a reason.

So, provide the citation or shut up.

Why do you guys get so angry at anything vaguely anti-any vaccine?

Why do anti-vaccine people get so upset when told to produce factual evidence?

The problem is that anti-vaccine sentiment is NOT harmless.

Anti-vaccine sentiment means we now have diseases killing children that were effectively eradicated 20 years ago.

Anti-vaccine sentiment means that we don't have a Lyme disease vaccination because the cost of fighting anti-vaxxers exceeds the profit from selling the vaccine.

So, if we look at the balance, anti-vaccination causes real, demonstrable problems while pro-vaccination has yet to have any demonstrated factual downside.

So, yeah, we now have preventable diseases running amok because the logical community was tolerant about anti-vaccination instead of stomping the anti-vaxxers into the ground like they so richly deserved.

Now does the vitriol make sense?

The attitude seems a bit out of place but I understand your position more now. Thank you.

>The attitude seems a bit out of place

Not if you have children.

That is apples and oranges. He's talking about a tacit understanding, and not necessarily in the context of upward movement. You're talking about explicitly telling management that you are actively looking. They'd have to be idiots to promote you under those circumstances.

>They'd have to be idiots to promote you under those circumstances.

Why would they have to be idiots? Doesn't this just create a crummy atmosphere where promotions only go to people unwilling or unable to leave the organization?

> Why would they have to be idiots?

Because when the employee was asked what they wanted to be doing in their career, their answer amounted to "be working somewhere else".

> Doesn't this just create a crummy atmosphere where promotions only go to people unwilling or unable to leave the organization?

There's a difference between "people who are willing to leave the company if it cannot provide them what they want" and "people whose desires appear to center around leaving the company".

>their answer amounted to "be working somewhere else".

It does not amount to that. In many, many, cases people start looking for jobs wishing they could stay at their current job.

> It does not amount to that.

Assuming no relevant facts were omitted from the description of events, it does, in the context of the question it was offered in response to.

> In many, many, cases people start looking for jobs wishing they could stay at their current job.

Sure, they do. But the answer to the question "Where do you want to be in your career?" in those cases would focus on the things that they wanted to enable themselves to stay in and love the job with their current employer, not the fact that they are looking for outside opportunities (the latter might be mentioned in the context of specific desires and the fact that certain outside opportunities seemed to be the only way to realize them, but even then the looking for outside opportunities would be secondary to the main answer about desired job features, not the main answer to the question.)

Just because you are willing/able to leave a company doesn't mean you advertise it. Hence "explicit" vs "tacit" in my comment. What a person says about being loyal is irrelevant, you can't assume anyone will stay long term (kind of the point). But if they go out of their way to say they're looking, then they don't want to be there and you shouldn't waste the time & resources training them up.

> He didn't "advertise" it -- he just gave a honest answer when questioned.

"I am actively looking for jobs at other firms" is not an answer to the question of "where do you want to be in your career", except insofar as it can be read to imply an answer of "not here".

So, it was honest, but not really (except indirectly) an answer to the question asked, and quite likely, in any case, not the most productive and relevant honest answer.

If the reason other opportunities were being sought is that those opportunities offered features X, Y, and Z that the employee's current position didn't, an honest but more direct and relevant answer would be "I'd like to be doing more of things like X, Y, and Z". That would directly answer the question, and provide something positively actionable by the employer, and be no less honest than "I've got my resume out and am actively looking at outside opportunities".

There's two possibilities (based on the scenario as described): either the employee was fed up with the company and really wanted out, and then the answer given was not only honest but reasonably relevant (if somewhat, perhaps diplomatically, indirect), or the employee had particular things they wanted in their career that they weren't currently getting, and failed to give the most relevant perfectly honest answer to the question asked, and instead gave an incomplete, tangentially relevant non-answer which implied an unfortunate and inaccurate answer to the question actually asked.

No they go to the people who threaten to leave as a means of retaining them. That's an even worse environment to work in.

Not a PuTTY fan. I generally install Fedora or Linux vms on personal Windows systems (where they are mandatory/heavily advantageous and where security policies permit) in large part to have openssh-client, and then use vmhgfs shares to move files between them as necessary. Among other reasons.

Test driven development usually refers to unit testing or integration testing. It would be interesting to know if you went beyond that and the nature of contract work you were doing (testing for an internal service with a RESTful API being very different from a mobile app, or a website).

TDD, in my view, starts from the outermost layer -- the end user -- and moves inwards progressively to the unit tests.

John Lakos differs from you. In his book "Large Scale C++ Software Development" he advocates starting at the lowest level of your own code, that is, subroutines that only make system calls or call libraries that are provided by the system.

Then you unit test the second level - subroutines that only call that first level, or that call the system or libraries.

main() sits at the top level.

Not every program is straightforward to levelize. His point is that one should do so.

Also the unit tests for any one level should focus on what is new on that specific level, with the assumption that all the lower levels are flawless. In general they won't really be but when that's the case you write a unit test for the lower level.

This keeps the LOC on the tests about the same as the LOC in the deliverable.

It is unfortunate that his book focusses on C++; really he should have written a separate book on testing that was language-agnostic. There is very little of that section that's really specific to C++.

In addition to unit tests I do integration tests. If there's a file format involved I create lots of input files that contain various edge cases.

With the caveat I haven't read Lakos' book, there's a pretty big backlash going on in the industry against hyper-granular unit testing. Comes down to people realizing that when their implementation needs to change, they often have to change a bunch of unit tests that were written to the implementation.

One problem is that modularity should let you change implementation without friction; that's the whole point of modularity to begin with. So there's not much profit in writing a bunch of client code (tests) that intentionally break modularity and put friction back on the process. It's not quite as bad as just random breakage, because at least you know where it all is, but it's still painful.

Another problem is that if you're not careful, you end up with a set of tests that don't tell you when something works as expected or not, it just tells you when something changed. Having a test that tells you something isn't coded as expected anymore is pretty useless. You know you changed it.

And still another problem is that the testing itself has become too invasive. We're architecting things for dependency injection that would never really need it if it weren't for invasive tests. It's fine and well to drop some testing hooks in, but if you're having to completely invert control in your code to do it and that makes things significantly more complex, that may not be great.

I think there were some fairly recent Martin Fowler posts on this, but I believe his point was that we're very possibly doing it wrong: if the point is to guarantee an interface then tests should be to the interface. And maybe injecting test doubles is good in some cases but too invasive in others--especially when it's done to test an implementation--and so forth.

So not sure where Lakos is on the scale there, but what you describe about putting in layers upon granular layers of tests strikes me as setting yourself up for these issues. I'm a pretty big believer in testing to the interface, and do try to draw a line between functions that are there to serve a particular implementation and functions that describe something more abstract. I test to the latter.

Modularity is the key to maintenance; the biggest benefit of this type of testing to me is to validate your modularity, even more than validating the code within the modules.

Outstanding answer - thanks for the pointer to the Lakos book.

1) Experts in all fields are always wrong sometimes. The nonexperts are wrong more frequently on average and people are less interested in proving them wrong.

2) Saying that implementing your own cryptography usually implies a production environment. I think it's generally assumed that nobody cares what people do with their own time/personal projects.

3) Trite sounds bites don't work in science either, and expert -/-> celebrity.

Ad 2) most groundbreaking projects you know originated as messy ad-hoc personal projects and not in production-sanitized environments (look even at GPG, embarrassingly for crypto community with one almost bankrupt developer). Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact. The crypto requires such an enormous amount of talent that it is bright individuals, not companies, that make things move there, and quite often the more people involved, the worse results.

> someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down

I'm sorry, but this is essentially never the case. This is no different than in other fields, for instance math or physics, where complete novices come in every day believing they've had a completely novel idea that will revolutionize the field. 999,999 times out of a million they haven't, and in the one remaining case they've come up with a solution in search of a problem.

"Oh, you've come up with a new cipher? Congratulations. Assuming it is secure, why should we use it ? Is it faster than existing ones? Simpler and more likely to be implemented correctly? Resistant to timing attacks? Resistant to CPU power analysis? Resistant to differential cryptanalysis? Suitable for low-CPU and low-memory embedded devices? Oh, none of these things? Gee, how interesting."

I'm reminded of http://www.scottaaronson.com/blog/?p=304

> Crypto-logy/graphy is an art, someone has a bright idea while lacking in other dimensions; the crypto community instead of embracing this idea and helping this person to bring something excellent to the world, shoots them instead down and point to obvious flaws that can be fixed in minutes by someone experienced, while keeping the new idea intact.

Crypto is an environment where a single mistake can get people killed. The stakes are very high. We're not talking about a slight rendering error in CSS here. This is not an appropriate place to be universally warm, fuzzy, encouraging, and forgiving of mistakes. This is incredibly serious stuff that must be treated appropriately seriously - and everyone attempting to touch the field needs to understand that.

In addition, stouset is right. The frequency with which apparently novel ideas are actually novel is much, much, much smaller than a naive guess would lead one to expect. I've watched people attempt to introduce ideas that strike them as novel, only to discover that they're just creating exploitable weaknesses, right here on Hacker News.