skysight-inc/HackerNews huggingface dataset:
The Acquisition King: Reckitt Benckiser
You often end up reimplementing the "comsumer" module for your code in order to test. This is problematic because a) extra work and b) that fixture layer probably doesn't behave exactly like the real caller code and c) now you have to keep those two implementations in sync.
Instead of Stanford as source here is an example from the FB engineering blog about migrating from HBase to MySQl for messaged in order to reach performance: https://engineering.fb.com/core-data/migrating-messenger-sto...

And yes, they certainly cache data in multiple layers using different technologies but from all I as an outsider can see MySQL still seems to be their source of truth for most services. Meaning all writes go to MySQL and at least when going deep in history or doing searches (which typically can't be served from a cache) hit MySQL.
That's a pretty cool thread.

I guess I should find friends in real life (also known as 'meatspace')

Note: that's literally what I think, I'm not trying to sound smug , neither am saying this ironically. Stupid limits of written communication, haunting me even here!
> There is no formal definition of what a unit is or how small it should be, but it’s mostly accepted that it corresponds to an individual function of a module (or method of an object).

And there-in lies the problem. Remove the idea that the unit is a single method/function.

I subscribe to the idea that a unit is a unit of functionality. Nothing to do with the code implementation.

Only mock where you're reaching out outside of your codebase (filesystem, network, operating system (time, for ex.))

You can still do unit tests for individual functions when you need to work on a complicated algorithm, but those functions should have no dependencies or side effects - pass in all the data you need
One interesting thing that is easy to notice about all of the examples of in the article is that they are absolutely infested with objects.

I don't have anything against objects, per se, but I think they tend to make unit testing much more difficult to accomplish. The closer your code resembles pure functions, the easier it is to do dependency injection and unit testing.
The reason why Vienna is so liveable is because it's the heartland of the Social Democrats. They governed the city from 1919-1934 and ever since 1945. As much as I don't like the current Social Democratic Party, their predecessors transformed Vienna into what it is today. A good place to live for everyone.
Right, you deactivated your account, but when was the last time you visited Reddit?
Typical 100% coverage metric vanity with usually no real world benefits.

> If you said that in an interview for code you'd written then I'd point to the door.

And they would be better off not having to work at a place with an intolerable environment of the kind.
Tests are insurance for refactoring which doesn't change the interface that is being tested.

Refactoring usually changes interfaces. Things are factored differently. The clue is in the name.

The higher up the stack your test is, the more insurance it gives you for refactoring. The lower downs the stack it is, the more likely it is to be thrown away or heavily rewritten after refactoring.
The difference is no accountant does accountancy in their bedroom for fun as a teenager. The software engineer who has significantly progressed their career by 27 probably started as a teenager, not as a 22 year old. It's more like being a musician than being a lawyer or an accountant.
What you just said, and the link you just linked, say two completely different things. You should watch that link again.
One car brand or toaster brand would slow down innovation and we’d end up with a much worse version of what it could be.
Well, haskell has the problem of lazyness being the default execution model, which doesn't really help.
I always argue for this and get told, “that’s not for the user. It’s adds screen bloat to the UI.” I never understand why people say that. How about we make it easier for us to help people. I mean at the core that is kind of our job.
What criteria would you use? I've met a lot of stupid people with education from well-regarded institutions and a lot of sharp people with no education past K-12, if that. Formal education seems like a poor measure.
Location: Germany

Remote: Yes

Willing to relocate: Yes

Technologies: Svelte, Web Audio API, PouchDB

Résumé/CV:

- https://8bars.app (made with Svelte and the Web Audio API)

- https://thinktype.app (made with Svelte and PouchDB)

Email: amadeuspagel@gmail.com
The flaw in thinking that once an app exists there is no point in recreating it, is assuming that everyone who would every use that app is already using it. Obviously that is false. Taken to the extreme, think about how many people are getting their very first mobile phone today?
Not sure why anyone thinks they have a hard decision, plenty of big name companies do business with mainland China as is, why hold these to a different standard?
How to opt-out of the new GitHub UI?
By whom? Compared to what?
they should have developed it from day 1 thinking it would be open sources, i.e. never adding any non-open source dependencies
you can have good experiences with unit tests or bad ones depending on the health of your codebase. Hard to test code is a smell that many people interpret as being a problem with the concept of unit testing.

Most of my experience is with React, and the majority of react devs I've seen don't unit test their code, because they don't write enough pure testable functions. As a result the community has leaned heavily on React Testing Library which is AMAZING for integration testing. Instead of checking that your function returns the right value, people will mount the component and then check to see that the right value is displayed in the rendered DOM. This obviously works, but writing the logic as a pure function and unit testing that function with a lot of different inputs gives you much more confidence.
Creating History
> It also looks like they bought a bunch of fake 5 star reviews at the end of January.

I took a look and yeah it's pretty obvious this is what happened. There are 88 reviews total, and all but three of them occurred in the 7-day period between 26-Jan and 02-Feb, of which all were 5-star reviews.

It seems like this sorry if thing should be easy for Google to flag?
> Loosely coupled code is also easier to reason about and easier to refactor.

Can you expand more on this? I think this is where the author would disagree.

E.g., how is the code easier to reason about or refactor having introduced a location service interface that has only one one implementation?
My own take on this is that it is hard to crystallise why or what a "unit" is. My cop out is it comes down to experience - once you've done this enough and solved enough problems and worked on enough teams, you'll get an intuition on this as it is more art than science.

I find it to be some mixture of importance and complexity, while always balancing against the single responsibility principle. A simple `average` function might be trivial but if it's important to your business logic you probably want to test that separately, even if it is nested within a "unit".

I find that following some iteration of "functional core imperative shell" helps here as it helps keep your core business logic to being data transformations and transformations on data are easy to test and their concerns are easy to reason about.

This then helps me reason about what is "implementation" and what is a contract/interface which should be tested robustly.

I guess really the art of writing just enough unit tests is to identify the seams and boundaries of your abstractions in your codebase, and potentially accepting that business seams in your codebase may be different from the seams of your actual software domain -- the latter being possibly more granular.
Instance vs. Semantic Segmentation: What Are the Key Differences?
> We used to make fun of the practice of hiring based on firmness of handshake

True anecdote time. A few months after starting my first full time job, I asked my boss why he chose me over the other candidates. "You had the driest handshake" was his answer.

In the man's defence, my first job was as a microbiology lab technician. His explanation was that a dry handshake was a good indication that a person would likely have a better aseptic technique, thus leading to fewer false positive results when performing the tests. Utter nonsense, of course.
Hence the reason for my original comment.
Unit Testing, yes, it can be a waste of time. Depends on what you're doing. Unit Testing fails when you sink more and more time into trying to make a test for something because 'duh, unit test everything'. Fact is some code changes a lot and some code doesn't change much. Some code is also hard to unit test and some isn't. The intersection between code that doesn't change much and code that's hard to unit test should NOT be unit tested, especially if another form of testing works better. There's just no need to sweat over a test that wont run enough to justify the work that went in to writing it.

The issue here is developers don't have a sense for economics. Diminished returns, marginal utility, and opportunity cost should be studied by ALL.
A $30M Business in 5 Years: How Wirecutter Did It (and how you can too)
Unit testing reveals latent defects, defects that can't be triggered by the system as it currently exists. Each such defect is a problem waiting to pop out in the future, as the system changes and the latent defects become exposed.
Or just do better marketing, or a better supply chain, or lower cost to manufacture. Or make it specialized and only toast bagels.
Watermark free TikTok Video Downloader
If you don't do 2 you may as well not test at all. You may do everything else and still fail your end APIs. Your users don't care about your core or mocks. They want end APIs to work

The rest just seem arbitrary. Can you make a change and be confident it works ? The last point sums up everything. "Use your best judgement"
We initially only had integration tests, because many people think they're better. I get it: itests use the real plumbing, so they're more representative of your runtime. But they're slooooow -- especially the tests that involve the DB (which is most of our itests).

So we started adding unit tests. Utesting code that wasn't written for utests is painful: you often need to choose between refactoring or just patching the hell out of it. The latter is highly undesirable, since it leads to verbose tests, failures when you move a module, and the inability to do blackbox testing.

But utests encourage our new code to be clean and readable. We've found that functional programming is much easier to test than object-oriented, and is easier for engineers to grok. We just sprinkle a little dependency injection and the whole thing works nicely.

Itests have their place, but utests lead to faster feedback and more readable code.
I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
I find the reciprocal thing useless, so I have units='units --compact --one-line', which gives just the number you want.
> In our (western civilization) societies, everyone wants to be a manager or a scrum master or at least a programmer, have a nice white collar job in the home office.

That’s a very coastal city attitude which in most parts of the US would seem utterly provincial. The man who owns the roofing company that’s redoing my roof shakes his head when he hears me talk about staring at a computer screen all day. The HVAC repairman who was at my house yesterday was horrified to find out that I need a special keyboard to prevent pain in my hands from too much typing. “Don’t you have insurance or workers comp?” he asked. He thought I was lying or mistaken when I laughed and explained that my injuries are mine to deal with on my own.

In my part of America, which is neither overly cosmopolitan nor a big city where all the wide-eyed, bushy-tailed dreamers are flocking, most people aim to work in the various trades after high school. The ambitious ones will move up in the world by owning businesses which employ tradesmen, but that’s about as far as most will go. To most HN readers this will seem like a colossal economic hole, but it’s nothing like it. Tradesmen with only a few years of experience make decent money, and business owners are enjoying conditions similar to those which HNers with “lifestyle businesses” aim to attain.

Yes, there are untold millions of Americans working menial jobs. Those jobs require no special skills or experience, which is why such workers are seen as expendable. To lump such workers and their plight together with decidedly blue-collar tradesmen is a mistake.
I'd be interested to see how current-day WASM stacks up against current-day Java. Don't suppose you've ported your crypto code to Java? Other than the maturity of the JIT compilers, are there reasons we should expect WASM to be any slower?
God that is a phenomenal explanation, it's beautifully put together.
> it's about the same distance

Distance does not matter at sea so much as prevailing conditions (winds, current) and available marine technology..
Nice analogy. Here's somethine new. Rust is not just a sports car, but an eco-friendly electric one at that.

One topic OP hasn't touched upon is the disadvantage of "pushing client side to the server". JS is terrible at handling concurrent processes. The browsers have been able to make do because they typically care about just one user.

In the server though, it's terribly important to handle thousands of users concurrently. JS engines suck at it.

To put it in plain words, if you are into SPAs and want server side rendering, among all the other issues the one sure wall you'd be hitting is scaling issues.

JS will never be able to construct and send HTML over as efficiently as Rust could. This is going to be the reason why Rust(or a similar tech) will eventually win the web.
I can’t speak for them but for me it’s hard to avoid this feeling like you invested a part of yourself. All the comments and thoughts you poured out, the interactions and revelations you had, the little funny moments. A part of me likes knowing I can go back and see any of it again even if basically never look at my history.

It just feels like some sort of weird emotional and mental investment I suppose?
As a board member of the XSF for this term and for the first time, I don't really find myself in disagreement. It seems to me the culture of change is almost nonexistent and it's hard or close to impossible to get the XSF to provoke it.
PHP is definitely not a meme, it's got a ton of actively developed frameworks, PHP 7 was a huge step forward for the language and PHP 8 is shaping up to be as well.

It's been used at every workplace I've been at, sometimes well, sometimes not so well, just like any language. No idea what the point of blanket statements like this is.
I've used an app store (or rather an 'apt store') since 1999, it's the reason I moved from redhat to debian in the first place.

I'm not sure that "desktop computers" as we know it were around in the 60s (I certainly wasn't), but in the early 90s software tended to come from floppy disks, before that it was a C90 cassette on a spectrum.
Maybe your unit's are too big.
Unit tests are tricky because it's about coming to a personal and team agreement on what a 'unit' of functionality is.

I find the same issue in throwing away tests when I'm writing small scale integration tests with junit. Usually I'm mocking out the DB and a few web service calls. So those tests become more volatile because their surface is exposed more. But smaller level, function and class level tests can have a really good ROI and they do push you design for testing which makes everything a bit better imo.
I found this post from my RSS feed, I didn't understand at first :/
Who is replacing Intel servers ? AMD ?
Which standard function in Ruby is a single letter?
What are the best quantitative resources on learning negotiation?
You Don't Need Permission
I discovered https://fraidyc.at/ and I'm using this since.
Compared to integration testing and end-to-end testing.
International students not allowed to be in US for Fall 2020 online classes
'units' was new to me too. The version I have on my Mac wouldn't accept 'millilightseconds' but it would take 'milli-c-seconds' - presumably the units.lib database is a little different from one in the original article.
Systems Administrator Salary: Skills and Certifications to Boost It
The fundamental value of a stock is the net present value of future cashflows that stock entitles you to. Buyers and sellers are welcome to believe otherwise, but in the long run they will lose money.
Show HN: Herbl- a Recommendation Engine for Cannabis
I made this for first time smokers help find a jumping off point trying cannabis for the first time. I currently have a database of 1000+ strains and am recommending based on a survey and your history. Would love any feedback!

I also have an iOS app and Chrome extension

https://apps.apple.com/us/app/id1522237298

https://chrome.google.com/webstore/detail/herblrx-strain-fin...
They are cheap per unit, but if you test a lot of units, it adds up.

There is a set of bugs that only higher-level testing will catch. There is another set of bugs that both higher and unit-level testing will catch. Then there is the set that only unit-level testing will catch.

How important is that last set? If a unit test fails and there is no user interaction to trigger that failure, is it really a bug?

Unit tests can be valuable if they help you during development of a unit, but most units are not that complex and should not require unit tests.
In no particular order:

1. Boredom. Yeah, plenty of food, whatever; what should I do all day, shake coconut trees? BORING!

2. Prestige. Growing a family is not cool. Do you know what’s cool? Finding a new island and coming back a chief.

3. Conflict. Damn, the chief is a pain in the ass, males me shake coconut trees all day. I’m going to get my own island, with hookers and blackjack.

4. Curiosity. I want to see what’s beyond. Maybe I’ll meet the gods, that would be great!

5. Swagger. I am the best sailor in the tribe, the sea is my bitch, and I’ll show you.

6. Duty and tradition. Our culture is defined by expansion, it is my duty to do what our ancestors did.

7. Redemption. I screwed up, my life in this tribe is over, I have nothing to lose trying to start again beyond the sea.
This proves humans are not animals. We're not that smart ;)
Step 1: Get capital on board with your plan. Good luck!
Yup, this is very true. As long as you return something deterministic, unit testing is easy.

It's where you need to handle mutable state with objects that things get trickier.

Unfortunately, these are exactly the places where you most need tests.

I'm a big fan of constantly returning things rather than holding state in objects, for specifically this reason.
It’s a BBC site, so maybe it tests your localisation or maybe there’s a paywall after a certain number of visit.

Sorry about that .
>One side effect of this is that it thoroughly forecloses on the dream of a General AI. Societies whose primary industry is digging through rubble for canned goods while drinking your own urine to survive do not make fundamental AI breakthroughs.

I find this deeply resonating.
I tend to mentally divide code into roughly two types: "computational" and "plumbing".

Computational code handles your business logic. This is usually in the minority in a typical codebase. What it does is quite well defined and usually benefits a lot from unit tests ("is this doing what we intended"). Happily, it changes less often than plumbing code, so unit tests tend to stay valuable and need little modification.

Plumbing code is everything else, and mainly involves moving information from place to place. This includes database access, moving data between components, conveying information from the end user, and so on. Unit tests here are next to useless because a) you'd have to mock everything out b) this type of code seems to change frequently and c) it has a less clearly defined behaviour.

What you really want to test with plumbing code is "does it work", which is handled by integration and system tests.
Helpful content!!
I never understood why a small company wants a completely in-house developed platform. Wouldn't it be more economical to directly use Cloud offerings? Or in case you need on-prem wouldn't it be wiser to just pay for offerings like OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes?
"don't mock"

How are you meant to write a unit test for a class without mocking out external dependencies? Wouldn't that make it an integration test?
Yes, the new EPYC cpus offer very good performance and value.
Emerging spectrum of Covid-19 neurology: clinical, radiological and lab findings
The example is a straw man. He refers to a doubling in code size, but that's just because he's got hardly any code. In a real class, you still have one method (or two! or three!) on the interface but you've probably got 300 lines in the implementation. The only thing being "duplicated" is the external interface.

Might as well retitle this "Why I don't like the Interface Segregation Principle".
Yes but discovering those hypothetical defects is usually less important than discovering the actual, currently present defects.
Reckitt Benckinser or RB as we know it today owes a great amount of its growth to the outstanding acquisitions that it had done in the past. The author has listed many such acquisitions and the resulting product line that has helped RB enhance its portfolio of products.
Agree. To add to this, many unit tests that you might have to do become obsolete with a strongly typed functional language. At that point you’re basically only integration testing the API boundaries / external interfaces.
It's because it also has expressiveness features that Java and Go don't.

* Better handling of "null"-ness

* Sum types

* Stricter/different error-handling

* Move semantics, which can actually be nice for some APIs outside of any performance considerations

Kotlin checks a couple of these boxes, but then is also GC'd, so also gets rid of a lot of "noise" that would be in the equivalent Rust code.

For typical backend junk, I'd be Kotlin first, but I'd definitely consider Rust if performance (non-IO) was a concern.
> Striving for 100% test coverage is nonsense

Tell that to SQLite guy.
> Other people ... say ...

If that happened to be online, and you happen to have a link, it'd be interesting to read
I still use Facebook via Tor quite often, even though it's barely usable - loading anything takes between 3 and infinite seconds (i.e. never loads, requiring multiple refreshes). I use it to let them know that people still use it, with the hopes that they don't even remove it. I don't have this problem with other Tor sites, so it leads me to believe they want to be able to advertise it as "we offer this because we care" while making it nearly unusable to the point that nobody will use it. It's very similar to the secure chat feature, which they continually move deeper and deeper into menus, each move progressively more difficult to find. They just yesterday enabled the new "layout", and I can't even find the secure chat feature anymore, they either buried it so deep or removed it entirely?
Productivize
That's pretty scary
Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly.

The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?