skysight-inc/HackerNews huggingface dataset:
Getting to the right answer fast is only relevant if they asked the right questions. I think the point of the article is that interviewers are not asking the right questions.
This. Making the distinction between the two is huge. Save time and money testing the right pieces of a codebase.
Become an Outstanding Developer
We're doing that in America and cases are skyrocketing.

A lot of places are starting to reinstitute lockdowns.
I had the original ZipIt, it didn’t have a color screen and it’s specs were even lower. It could still run text based Linux, with an ssh client, and it could play mp3s, but only with one optimized piece of software. I used it to go on IRC, and even wrote some very basic games that used ncurses or the framebuffer.

https://elinux.org/ZipIt
I just realized today that you can long-press the search field to add the search engine in Firefox for Android.

Not really that obvious, but there are instructions in Settings->Search.
Governments, when using threat of violence against people, at least have a responsibility to ensure that they are not committing undue harm, and certainly not before a conviction - we can argue all day about exactly how much harm is ok, but given the amount of untreated mental illness in our society they have a responsibility to ensure that what they are doing isn't overly harmful to people suffering from such.
You're right in a sense that it does not threaten the international community, but the old design acted as a deterrent against the majority of "pictures, easy browsing and quick content" users, which have since drowned the original community. Most of the people I have been asking stayed away of reddit because of the interface, which is good because it retained only the people that were interested enough in the subject to dive into text-only pages.
It is for use in reactors cooled with gas, so there is nothing to boil up and explode. And higher temperatures allow for smaller and more efficient reactors.

Smaller also means cheaper.
Decentraleyes – Local CDN Emulation
> Buyers and sellers are welcome to believe otherwise, but in the long run they will lose money.

Not if they sell it to someone else for a higher price.
Your argument boils down to: keep society shut down forever, problem solved.
And that's exactly why you need less tests in your project that uses a DB: there's no need to test the DB because it's covered by its own tests already.
This should be added as an appendix to the original story. The original has been a favorite of mine for years and I love the addition.
The benefit of 100% test coverage is that there are no more discussions on what to test and what not. When in doubt, test it. In larger groups of developers there are otherwise ongoing discussions if A needs to be tested or not. I have seen culture wars around this, from people who don't want to test and are in the eyes of others always testing not enough and vice versa. Especially with a diverse development force with different ages, seniority and cultural background.

It's often easier to just aim for 100% test coverage instead (with excluding some categories of files).

EDIT: I would not and did not start with 100% unit testing. But if there are ongoing culture wars and discussions didn't lead to a workable compromise, 100% test coverage worked for me and after some days test coverage was a non issue.
Show HN: RSS/Atom to twtxt feed aggregator
Often, these discussions go awry is when we overestimate and build upon solid seeming concepts that are actually squishy.

Marriage and prison bitch have very different connotations to us. To an alien...these are all in the sphere of coupling relationships. Ultimately, a 4th century peasant marriage, 19th century marriage, a 1950s American marriage and a modern, suburban gay marriage are all different from eachother... there's a common thread though.

The semantics tend to become the discussion.
Unit tests have their place but in my experience there are also a lot of places in most codebases where they don't deliver enough value compared to the effort put into both writing and maintaining them (they can be a huge PITA while refactoring). I agree that in many cases integration tests often are so much more useful in catching regressions.
Solaris 9/ultra 10
Kelly criteria
I'm a massive fan of unit testing, but I mostly agree with the observations. However, I (mostly) disagree with the conclusion. The problems with unit testing I've seen to come from the following anti-patterns in various combinations.

1) The use of unit tests as the exclusive automated test type. ie; No functional tests, integration, etc.

2) Test doubles for most or every dependency, even purely functional dependencies like math libraries.

3) Not using the appropriate kind of test double for the test at hand. (Dummies vs Fakes, vs Spies, vs Stubs, vs Mocks)

4) The overuse of mocking libraries.

Mocking libraries have their place, but in opinion, are used approximately a hundred, perhaps even a thousand times more often than they should be. I use them to create test doubles in exactly three scenarios:

1) A dependency that does not have an interface, usually a third party library. This usually happens in one place only, and is used for writing the wrapper code test.

2) A dependency that has an incredibly large interface and/or dependency graph where building a set of stubs or spies is simply not worth the effort.

3) I want to test weird edge cases that's not available any other way, such as theoretically unreachable code.

These should not be the majority of your unit tests!
Yeah, but high temperatures mean that if there is a problem, all these super secure grains will burst/melt/rupture doesnt it?
GNU Tools Linux Plumbers Conference 2020
Except that facebook wasn't the first social network by a long way, and Google certainly wasn't the first search engine. The phone industry laughed at the iPhone precisely because it was competing with existing phone manufacturers.

There are plenty of ways to compete with existing products, especially if they haven't achieved market dominance. The key thing is can you offer anything they don't. Quality, cost, features, ease of use, etc. What part of the market does their product not address, preferably in a way it's hard for their product to be adapted for.
> There isn't pure functions the moment you touch any kind of IO.

You can get pretty far with good abstractions and dependency injection. Go's io::Reader and io::Writer interfaces are a great example of this. The resulting functions aren't pure in a technical sense, but they're pretty easy to unit test none the less.

> Plus the same problem arises with modules instead of objects, which traditionally are even harder to customize.

Maybe you could elaborate. I really don't understand what you mean here.

From what I understand, modules just scope names, they don't maintain state. I don't see how they have the same problems as objects.
if it is worth rewriting the code it's worth rewriting the tests.
TBH

SQLite is suitable for 100% coverage.

A lot of application code or workflow style code is hard to reach 100% coverage as they are rarely triggered.
If all the insightful comments are gone, there's more chance people looking for insightful content will leave too.
I work in academia in a STEM field. I've never seen or heard of a reviewer asking for access to the raw data used to produce a paper. Reviewers typically operate under the assumption that you're not trying to deliberately mislead them about how you collected and evaluated your data (and I think they have to, at least with how the system currently works).

What often happens is that, although the time they get to spend on a single paper is limited, reviewers still come up with important criticisms that end up leading to substantial changes (sometimes multiple rounds of them) or even an outright rejection.
HN has jumped the shark, these days you want to be on Lobsters.
+1

Striving to make your code testable is almost always worth it. Someone might ask this guy to add some error handling to his code for example. :)
Then he will find out that by writing code, however simple, that a "works on my machine" I.e. is proven to work in a single happy path context is painful to change. Writing code that runs in multiple contexts (composed as an app or decomposed for testing) is intrinsically more easy to work with and change.
> I frequently find myself throwing away all the unit tests after a significant refactoring

Good, this time you can get it right.
Market competition will force prices down long-term. If they're not, that's a problem and there's probably an anti-trust suit somewhere that needs implementing. Also - investing in stock isn't a bad thing, because it's redistributing capital to entrepreneurs who are taking risks to make things better for everyone.
That’s all well and good until you need to upgrade some massive project to a new JDK or your Rails app from one major version to another. Then you will be wishing you had significant coverage.
Ajit Pai is making lots of enemies on the road to 5G
I read this complementary one the other day, and one thing that is readily apparent to me is that a lot of people have a lot of different opinions about testing (move to system tests! more unit tests! regression tests!), but many are not asking the zillion dollar question:

What are you testing for?

This is critical because it basically gives you immediately what you should and should not test, and how. While mindless, dogmatic, metric oriented testing is a waste, testing with higher intent and purpose is extremely useful.

An example: test that something working on current vX also works on vA to vW, and when vZ is out, have the answer readily. Or that a biz feature fulfills the requirements. Or that someone not as well versed on intricate details of your piece of ownership will be confident in that piece still working after a simple fix when you’re on vacation. It can be one, some, but probably not all.

With that in mind, what to test, what doesn’t make sense to test, and what to test against becomes more clear: should I mock this? or should I run it against some staging environment? Should I perform (yikes? not!) manual testing?

The answers are highly dependent on the piece of code being tested.

Tests are here to help you answer a question, if you aren’t sure what the question is then your tests will miss the point.

https://flak.tedunangst.com/post/against-testing
Dell XPS are beautiful, but not robust. Many battery problems that Dell refuses to fix.

A battery should not bloat and warp the entire device immediately after the warranty expires.
of course it doesn't actively store history. it doesn't wipe the storage medium so may leave a trace, but that's different. if a browser says it is wiping then there should be proof of this, instead of the "just trust us" stance which the article rightly highlights as dangerous
We had a bad user who we kept banning for harassing other users. He would come back over and over again, using different pictures, IPs, even throwaway phone numbers or FB accounts etc. We ended up stopping him by involving a lawyer who drafted a letter invoking the CFAA. But it revolved around him violating our terms of service (eg no harassment, banned users are banned forever etc.)

Anybody know: Would CFAA still apply here if EFF wins this case? Or are there any other laws which would cover this kind of unauthorized access?

Thanks!
The problem is not so much the system as how it's presented: the media presents "peer-reviewed study" as a gold standard, practically synonymous with correct. And unfortunately academia absolutely encourages this practice.

The message that peer review is largely meaningless hasn't really been made by academia, for obvious reasons, and thus stupid papers getting accepted by journals will continue to be interesting and news-worthy until people get the message that peer review doesn't mean much.

The world will then move on to "replicated" as a gold standard. This will be better but not by much. Just a few weeks ago Imperial College London published a press release claiming their Report 9 results from their COVID-19 simulator program had been replicated. Worth a press release because after it was open sourced it was discovered to be filled with non-deterministic behaviour, even with fixed RNG seeds.

Unfortunately the press release was fraudulent. The report they cited as evidence of replication was by a friendly academic. He said he was able to replicate the results, then admitted every number he got out was different, some by 10%-25% different. This is the output of a computer simulation so the allowable difference is 0%. Despite this, Nature and other outlets proceeded to report that ICL's COVID model was "replicated".

In the end, academia is strongly incentivised to appear credible, not actually be so. Being credible requires you can reliably turn your findings into something useful, as when in the realm of pure theory you can never be sure your findings actually hold up in reality. Corporate research has this attribute (eventually), academic research doesn't, as academics are rewarded for writing clever sounding papers not being correct.
> Part of the myth is that it is skill, not health risks, that should be well paid.

It's hard and expensive to turn somebody into a programmer, and you can't scale it up as you wish. It's easy in comparison to have more people who can do dangerous jobs: you just need more children and wait 20 years.

For management and similar roles, I agree somewhat (it's much harder to pinpoint the skills required, and they often have less direct influence in the success of the company/project), but for the actual jobs, like software development and engineering? Yeah, they are high skill.

> Remuneration, price of different types of labor, also depends on cultural factors.

I don't think so. Unless you include religion and royalty where you can't just get into some career, the ones that are easy, low-risk and high-pay/high-power will always be attractive and you will be able to predict movements pretty well with market models.
and most people just do the time
I'd suggest that someone who thinks that UTs are over-rated are over-rating their ability. I'd also suggest that those people are the exact people that should have extra testing done on their code.
There are plenty of cases where programmers only start programming for real at a post-college job. The majority case, even.

That said, sure. There are differences in substance, history, everything. Those might be the reason for differences between professions, but the question is "how much?"

I think we overemphasize legible, logical reasons for culture, but often it's incidental reasons path dependence, demographics, etc.
The Effort to Make India’s First Covid-19 Test
Writing ten articles a week for the last three years
Then there's the Halfbakery, where you can share your ideas so you don't have to half-bake them yourself!

http://www.halfbakery.com/
The same could be said of nvidia. I don’t think their future is assured by any means.
This [1] is from a MOOC on programming high-performance dense linear algebra, which is part of a series [2] of MOOCs on linear algebra. It's nice because there are free online books, videos, and code. Also it's self-paced and you don't have to register.

[1] http://www.cs.utexas.edu/users/flame/laff/pfhp/week2-optimiz...

[2] http://ulaff.net/
Nowadays the fundamental value of a stock is more what you can convince others to pay for it.
You mean (SHOCK!) that the company that sells Redis thinks their product is better than a competitor!? Color me shocked!

I'd like to see actual independent feature and performance comparisons before I come to any actual conclusions.
I read most of the article and I am not convinced. I'll stick with the unit tests. In my experience they improve code quality, maintainability and reduce bugs.
Rust's type safety and error handling are helpful tools to have in your belt when gluing together the pieces needed for a web api. I have been working on a new product at my day job that has needed to change a lot as we learn and grow and I am happy with how Rust has been reliable in the face of that change.
> It's hard and expensive to turn somebody into a programmer, and you can't scale it up as you wish.

Is it? We work in one of the few industries where self-taught may actually be the norm (or at least, a significant minority).
Very true. I knew a C++ developer who knew the language inside and out, incredible skill, 100% on a written test where most people get hired with a score of 60%+. He offered very little to the company other than optimising the build to run faster. He just wasn't motivated to solve the problems the company needed solving or engage in the product. Unsurprisingly he wanted to play with C++ all day long.

I also knew a developer who came from a coding bootcamp, adequate CS fundamentals and basic knowledge of JavaScript and Java. He was the most productive developer I've ever worked with. Laser like focus and great social skills. He occasionally needed guidance from more technical developers but he knew when to ask for help and he got the job done.
Seems to defeat the point of the tests. At least partially.
Mocking networked services is something very much worth doing because you can then check you’ve set timeouts correctly, handling incomplete or junk responses gracefully etc. Those are the kind of hidden problems that can bite you on production deployments.
The article would be more informative if it contained a description of the reasons for blacklisting.
I agree with you and that‘s most times also my observation: Unit tests tend to show how decoupled and re-usable your code is. Is a function gets hard to test with a unit test, this points usually towards an architectural issue.
Most of the time investment was setting up the prerequisites for the various tools. Notable requirements were python, node+npm, Microsoft Build Tools, and Google's Brotli.

I used glyphhanger[1] to apply the actual subsetting. Use the --spider flag to find a list of unicode ranges used on your site. Then you can generate files with something like:

glyphhanger --whitelist="U+20,U+21,U+26-29,U+2C-3B,U+3F-57,U+59,U+61-7A,U+2013,U+2019,U+201C,U+201D,U+2026" --subset=SourceSansPro-Regular.ttf --formats=woff2,woff --css

Then you would add that same unicode-range to your CSS.

I haven't tried this on icon fonts. I tend towards SVGs instead.

[1] https://github.com/filamentgroup/glyphhanger
Maybe this is an US-only meme?
The German village where coal is still king
You can indeed avoid most of the js overhead if you use a particular subset of the language. In fact, that's how asmjs started, but:

- it's not JavaScript anymore, you'll lose most idioms you're used to work with, and it's a nightmare to maintain because it's pretty low level.

- it won't be as fast as it could unless the runtime is aware of the fact that you are using that subset (that's why asmjs used some annotation to run on a special engine on Firefox, and part of the reason why browsers moved to wasm).
>There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/

There's no evidence proving the opposite either. We can't say anything beyond that the existing studies don't really show anything.
I think it's pretty obvious that the limit of static typing reduces logic bugs (since it can actually be used to prove statements about the logic), but beyond that everything is kind of up in the air.

>Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.

There's nothing to support that that this is 'pretty likely'. As far as we know, it could very well be that statically typed languages push you in the direction of handling it the right way. Or hell, it could be that a team using a dynamic language is more cautious and conscious of edge cases.
Coin master free spins – Daily spin links 2020 [July]
Bestselling Holocaust memoir by Denis Avey should be withdrawn from publication
An economy is the net result of individual and collective (social) behaviours. You could, indeed, argue that other species such as other primates or even ants behave in a way that bears resemblance to an economy with a due stretch of imagination. Even so, you have to be mindful about projection bias when you make such assertions.

The difference is that humans have this unique ability: self awareness. Humans are able to see themselves as a separate entity, as opposed to other humans. This also us to reflect on our own needs and desires, but also about the desires and needs of other individuals. It's this ability that has led to the emergence of language, culture and technology.

A human economy is an extension of the behaviours you'd see in other species. It just so happens that humans are able to steer that behaviour. The trouble is that we aren't that good at gauging the extent to which we get to control individual as well as collective and emergent behaviour.

So, reality is layered. On an abstract level, a human economy is seemingly based off a complex set of artificial social constructs used by humans to describe and handle that reality; but on a much lower level, a human economy is the net result of emergent individual and social behavioural patterns which, in themselves, have a clear overlap with other species. The fallacy then is to try and draw a clear border between those two levels.
Two fronts with big challenges:
Losing Appple as a customer
AMD already stealing market share on desktop, mobile, and server, with lots of improvements on the way in the short term. (smaller transistors, better memory controllers) While intel has really nothing in the pipeline.
The claim is not that anyone should be immune to public shaming. The claim is that as a culture, we are reaching for public shaming far more often than we should.

Imagine there are two college campuses. On campus A, when students disagree, the students in the majority say they felt unsafe, demand that the students in the minority be expelled, and on occasion succeed. On campus B, when students disagree, they... talk about the issue at hand with each other.

There is free speech on both campuses - after all, the government isn't involved here. Yet I think it's safe to say that orthodox thought (whatever it happens to be at the time of lock-in) is more secure at campus A than campus B. And I think it's reasonable to talk about the difference between the cultures, and advocate for one over the other.
Would you say public shaming is en evolutionary adaption? I don't have a problem with your argument. I am curious about your thoughts though.
Applications where software "literally prints money" are the best possible carve-out to require commercial licensing.
No, it is not overrated. The author is just using a not-so-handy definition of 'unit'. When a 'unit' is a single method/class/function 'unit' testing is not in general a very wise thing to do. In most cases it is better to unit test a set of related classes/methods/functions as a whole because the communication between these things also needs to be tested. In that case it is quite impossible to overrate the importance of unit testing. I also don't think the definition the author uses is the original definition of 'unit'......
I've seen this concept called by many names including CQS[0] and Functional Core, Imperative Shell[1]. I'm just leaving this comment here for those that are interested in reading more.

[0] https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...
[1] https://www.destroyallsoftware.com/screencasts/catalog/funct...
People don't know how to test well. It's that simple.
> they can be a huge PITA while refactoring

I see that as an useful feature: This shows you the cost of refactoring and the fact that this cost includes re-testing everything.