Write tests. Not too many. Mostly integration (2017) - <AUTHOR> https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c <comment><USER3> My rule of thumb: tests cast away fear. Whenever I get that sinking feeling that I'll break things when I change the code, I write tests until my doubts disappear. It works every time.

In response to the article: it's true that "you should very rarely have to change tests when you refactor code", however, most of the time, most coders are changing the expected behavior of the code due to changed or added requirements, which is not refactoring. Tests should change when the requirements change, of course. I am not contradicting the article, only clarifying that the quoted statement does not apply outside refactoring. (Refactoring is improving the design or performance of code without changing its required behavior.)

<comment><USER4> In my experience, a lot of unit tests are written with mocks, expectations, and way too much knowledge of the implementation details, which leads to broken tests simply by refactoring, even if the behavior does not change at all.

If you test units in isolation, while adhering to SRP which results in many smaller units depending on eachother to do a task, then simply refactoring without changing behavior screws up a considerable portion of your tests.

As for "tests cast away fear", that is definitely true. Whether or not the lack of fear is warranted is something else, and depends heavily on the quality of the unit tests. I've seen plenty of devs confident of their change because it didn't break any unit tests, only to discover that it broke something they forgot to test.

<comment><USER5> It is analogous to moral hazard. People with insurance take greater risks, and vice versa.

<comment><USER6> > It is analogous to moral hazard. People with insurance take greater risks, > and vice versa.

Programming with guard rails :)

</comment></comment></comment></comment><comment><USER7> > I've heard managers and teams mandating 100% code coverage for applications. > That's a really bad idea

I hope many managers and programmers out there don't take this the wrong way. I've been an engineer on a project that was attempting to get 100% code coverage on a piece of software I was writing. I heard constant remarks during this period that were similar to "You don't need 100% code coverage, it doesn't do anything!" These engineers who I was working with had only read articles like this and didn't stop to think about what the article was trying to say. From my experience there is no safe rule of thumb for for how many tests should be implemented for a project. There should be just enough to feel safe (as hathawsh has said). If you're recommending to engineers on your team to stop implementing tests when they say "I'm at 60% coverage and it'll take ~2 days to get to 100%" I'd really hope you take the time to understand _why_ they want 100% coverage.

The software I was working on when my coworkers started telling me to stop writing tests was code designed to trigger alarms when patient's vital signs met certain criteria set by doctors. I am very thankful that I did hit 100% coverage because between 60% and 100% there were many small edge cases that, had they caused a death, I wouldn't have been able to sleep well. Had they said I was explicitly disallowed from working on the tests I would have come in on a weekend (or taking a PTO) and implemented them then. It's our ethical responsibility to know when and where paranoia is worth the marginal time penalty.

<comment><USER8> > ...trigger alarms when patient's vital signs met certain criteria set by > doctor

Most of us aren't working on life or death code like this. My React app doesn't need 100% code coverage but you put it well when you said "There should be just enough to feel safe"

<comment><USER7> What I really want to drive home is that you should listen to the engineers who are working on the project. Testing is one of those things that is entirely subject to project needs. Like you say, a React app doesn't need 100% coverage, neither does code running a CI, something far out of the serving path, etc. But we shouldn't have a knee-jerk reaction to an engineer saying we should have 100% coverage.

</comment></comment></comment><comment><USER9> It might be obvious to some, but for reference the title (and associated tweet) is a reference to Michael Pollan's oft-quoted advice for eating healthy: "Eat food. Not too much. Mostly plants."

[https://www.nytimes.com/2007/01/28/magazine/28nutritionism.t...](https://www.nytimes.com/2007/01/28/magazine/28nutritionism.t.html)

<comment><USER10> Does this have a name? Like the overuse of "X considered harmful" after Dijkstra, or the annoying increase of "X Y and where/how to Z them" after JK Rowling?

<comment><USER9> Snowclone is a popular term for it:

[https://en.wikipedia.org/wiki/Snowclone](https://en.wikipedia.org/wiki/Snowclone)

</comment></comment></comment><comment><USER11> I think one mental model for tests is that they're simply another kind of automation.

The fundamental question of automation is: _will I repeat this task enough such that the amortized saving outweighs the cost of writing a script to do it?_

Whenever you're thinking of adding a test X, quickly consider how often you and your team are likely to need to manually test X if you don't. Also factor in the cost of writing test X (though that's tricky because sometimes you need to build test architecture Y, which lowers the costs of writing many tests...).

If it's a piece of code that's buggy, changing frequently, brittle, or important, then you're likely to need to validate its behavior again and again. It's probably worth writing a unit test for it.

If it's an end user experience that involves a lot of services maintained by different teams and tends to fall apart often, it's probably worth writing an integration test instead of having to keep manually testing every time the app goes down.

If it's an API with lots of important users using it for all sorts of weird edge cases and you don't want to have to manually repro each of the existing weird edge cases any time you add a new one, it's probably worth writing some black box tests for it.

But if it's code that's simple, boring, stable, short-lived, or unimportant, your time may be better spent elsewhere.

Another model is that your tests represent the codified understanding of what the system _is_. This can be very helpful if you have a lot of team churn. How do you make sure a new person doesn't break something when "something" isn't well-defined somewhere? Tests are a great way to pin that down. If this is a priority, then it becomes more important to write tests for things where the test actually very rarely fails. It's more executable system specification than it is automation.

<comment><USER12> I agree with the idea that we're _mostly_ automating manual work.

The really nice thing about automated tests is that they can also go much further than I would ever bother to manually. For example, I might manually check that a couple of product pages are showing, with an image, price and description. With automated testing I can check _all_ product pages, every time. It can also test a tedious amount of interactions, e.g. various interleavings of "add to cart", "remove from cart", "checkout", "press back button", etc.

Manual testing still gives me confidence that automated tests can't, e.g. that an "unknown unknown" hasn't taken things down. Yet that's _all_ I need to check manually; if pages are loading and look right, I don't feel a need to manually check all of the ecommerce arithmetic, permission logic, etc.

</comment></comment><comment><USER13> I _so_ agree with this. I've been fighting this exact battle at work lately. People on my team have decided to take testing seriously, which is fantastic, but many team members' understanding of what that means is still at the "watch unit-test coverage numbers go up" stage. So let me be very clear where I stand.

 __* 100% unit-test coverage is a garbage goal. __*

I don't hate unit tests. They can have enormous value shaking out edge cases in a self contained piece of code - usually a "leaf" in the module dependency graph - and making it future proof. Love it. However, unit tests don't tell you anything about whether the module's behavior in combination with others leads to a correct result. It's possible to chain a bunch of unit tests each with 100% coverage together, and still have the combination fail spectacularly. In operations, a lot of bugs live in the interstices between modules.

Even worse, 100% line coverage means a lot less than people seem to think. Let's say one line to compute an expression will compute the wrong value for some inputs. You might have a zillion unit tests that cause that line to be counted as covered, but still be missing the test that reveals the error case. I see this particularly with ASSERT or CHECK types of macros, which get counted toward 100% coverage even though no test ever exercises the failure case.

Striving too hard for 100% unit test coverage often means a lot of work - <USER2> of our unit tests have 3x more tricky mock code than actual test code - to get a thoroughly artificial and thus useless result. The cost:benefit ratio is abominable. By all means write thorough unit tests for those modules that have a good ratio, but _in general_ I agree with the admonition to focus more effort on functional/integration tests. In my 30+ years of professional program, that has _always_ been a way to find more bugs with less effort.

<comment><USER14> Before you battle too hard, let me introduce you to another way of thinking. It may not be to your liking, but I hope you'll find it interesting nonetheless. I'll try to keep it as short as I can. Usually when I type this same post, it takes me a while, but I'm getting better at it.

Imagine that the word "test" is a misnomer, when talking about unit tests. Often people think about testing as a way of checking whether or not the code works properly. This is _great_ for what is known as "acceptance testing". However, as you no doubt agree, it's not so great with "unit testing".

For some reason, people hang on hard to the words "unit" and "test" and come to the conclusion that you should take a piece of code (usually a class), isolate it and show that the class does was it is supposed to. This is a completely reasonable supposition, however in practice it doesn't work that well (I will skip the discussion, because I think you're already in agreement with me on that front).

Instead, imagine that "unit" refers to any piece of code (at any level) that has an interface. Next imagine that "test" means that we will simply document what it does. We don't necessarily worry ourselves about whether it is correct or not (though we wish it to be correct). We just write code that asserts, "When I do X, the result is Y".

At the macro level, we still need to see if the code works. We do this either with automated acceptance tests, or manual testing. Both are fine. When the code works to our level of satisfaction, you can imagine that the "unit tests" (that are only documenting what the code at various levels is doing) are also correct. It is possible that there is some incorrect code that isn't used (which we should delete), or that there are some software errors that cancel each other out (which will be rare). However, once the code is working on a macro scale, in general, it is also working on a micro scale.

Let's say we change the code now. The acceptance tests _may_ fail, but some of the "unit tests" will almost certainly fail (assuming we have full "unit test" coverage). If they don't there is a problem because "unit tests" are describing what the code is doing (the behaviour) and if we change the behaviour, the tests should fail.

For some types of unit testing styles (heavily mocked), often the unit tests will _not_ fail when we change the behaviour. This means the tests, as a long lasting artefact are not particularly useful. It might have been useful for helping you write the code initially, but if the test doesn't fail when you change the behaviour, it's lost utility. Let's make a rule: if the test doesn't fail when the behaviour fail, it's a "bad" test. We need to remove it or replace it with a test that _does_ fail.

The other problem you often run into is that when you change one line of code, 200 tests fail. This means that you spend _more_ time fixing the tests than you gained from being informed that the test failed. Most of the time you _know_ you are changing the behaviour, and so you want to have very little overhead in updating the tests. Let's make another rule: Unit tests must be specific. When you change specific behaviour only a few (on the order of 1) tests should fail.

This last one is really tricky because it means that you have to think hard about the way you write your code. Let's say you have a large function with many branch points in it. If you give it some input, then there are many possible outputs. You write a lot of unit tests. If you then change how one of the branch points are handled, a whole _class_ of tests will fail. This is bad for our rule.

The result of this is that you need to refactor that code so that your functions have a minimum number of branch points (ideally 0 or 1). Additionally, if you split apart that function so that it is now several function, you have to make each of the functions available to your test suite. This _exposes_ rather than _hides_ these interfaces.

The end result is that you decouple the operation of your code. When you hear about TDD being "Test Driven _Design_ ", this is what it means. This is especially true for things like global variables (or near global instance variables in large classes). You can't get away with it because if your functions depend on a lot of global state, you end up having tests that depend on that (near) global state. When you change the operation surrounding that state, a whole whack of tests fail.

Committing to writing high coverage unit tests which also have high specificity forces you to write decoupled code that doesn't rely on hidden state. And because it doesn't depend on hidden state, you have to be able to explicitly set up the state in your tests, which force you to write code where the dependencies on the objects are clear and uncomplicated.

You mentioned code coverage. I'm going to say that I almost check code coverage when I'm doing TDD. That's because if you are writing tests that cover all the behaviour, you will have 100% code coverage and 100% branch coverage. However, as you correctly point out, the opposite is _not_ the case. The test for the coverage of your code is _not_ a code coverage tool, it's changing the behaviour of the code and noting that the tests fail.

Most people are familiar with the idea of "Test First" and often equate that with "Test Driven". "Test First" is a great way to learn "Test Driven", but it is not the only way to go. When you have full test coverage, you can easily modify the code and observe how the tests fail. The tests and the production code are two sides of the same coin. When you change one, you must change the other. It's like double entry accounting. By modifying the production code and seeing how the tests fail, you can information on what this code is related to. You no longer need to keep it in you head!

When I have a well tested piece of code and somebody asks me , "How hard is to to do X", I just sketch up some code that grossly does X and take a look to see where the tests fail. This tells me roughly what I'll need to do to accomplish X.

I see I've failed (once again) to keep this post small. Let me leave you with just one more idea. You will recall that earlier I mentioned that in order to have "full coverage" of unit tests with specificity, you need to factor your code into very small pieces and also expose all of the interfaces. You then have a series of "tests" that show you the input for those functions with the corresponding outputs. The inputs represent the initial state of the program and the outputs represents the resultant state. It's a bit like being in the middle of a debugging session and saving that state. When you run the tests, it's like bringing that debugging session back to life. The expectations are simply watch points in the debugger.

When I'm debugging a program with a good suite of unit tests, I never use a debugger. It is dramatically faster to set up the scenario in the tests and see what happens. Often I don't have to do that. I often _already_ have tests that show me the scenario I'm interested in. For example, "Is it possible for this function to return null -- no. OK, my problem isn't here".

Richard Stallman once said that the secret to fixing bugs quickly is to only debug the code that is broken. "Unit tests" allow you to reason about your code. If you have so called unit tests that are unreadable, then you are giving up at least 50% of the value of the test. When I have problems, I spend _more time_ looking at the tests than the production code -- because it helps me reason about the production code more easily.

I will leave you with one (probably not so small caveat). Good "unit testing" and "good TDD" is not for everyone. I talked about ruthlessly decoupling code, simplifying functions to contain single branch points, exposing state, exposing interfaces (privacy is a code smell). There are people for which this is terrible. They like highly coupled code (because it often comes with high cohesion). They like code that depends on global state (because explicitly handling state means having to think hard about how you pass data around). They like large functions with lots of branch points (because it's easier to understand the code as a whole when you have the context together -- i.e. cohesion). Good unit tests and TDD work against that. If you want to write code like the above, I don't think unit tests will work for you.

I personally like this style of programming and I think it is dramatically more productive that many other styles of programming. Not everybody is going to agree. I hope it gives you some insight as to why some people find unit testing and TDD to be very productive, though.

<comment><USER13> Great response. :) I don't actually see anything there to disagree with. Maybe we have a difference of ... perspective? style? ... on some points, but no actual disagreement. I rather think the two rants are quite complementary. Thanks!

<comment><USER14> My pleasure. Actually, someone a few seconds ago posted "Keep trying" with respect to my trying to keep it small and then I guess thought better of it and deleted the post. I'm a little sad about that because I really think it was completely on the ball. This stuff is _so_ subtle and it's super hard say something that has any meaning without burning though a ton of trees. But the downside is that it requires a _lot_ of effort to follow the discussion. I think there is a simple message in there somewhere, but I've yet to find a way to express it.

But I agree completely on the issue of style. I think it really comes down to that. Conflicting styles is one of the hardest things to combat on a team and you often end up with some bizarre hybrid that doesn't work at all.

<comment><USER15> That person might have been banned, deservedly so. If you want to enjoy the internet you either lurk, or you learn to ignore the haters.

FWIW I liked to read you post. Especially your point about balancing cohesion vs unit testing, as this is something that the TDD evangelists never bother to mention.

</comment></comment></comment></comment></comment><comment><USER16> The current version of Unit Testing came out of the Chrysler C3 project, which was written using VisualWorks Smalltalk. (Eventually sparking Extreme Programming and SUnit, which was the ancestor of JUnit in Java land.) Here's the thing about Unit Testing in an environment like that. The best way to code and refactor code would also automatically refactor all of the Unit Tests. In an environment like that, Unit Tests are pretty nimble. There are no long waits for compile times. The entire test suite can run at the press of a button from a widget integrated in your standard development environment. Though, from what I read, the entire Unit Test suite would take an entire 10 minutes to run. However, you could easily just run the tests for the classes you were working on at the time, and reserve the whole suite for checkin time.

So what happens when you move the practice away from this particular kind of Smalltalk environment? Refactorings in most languages are slower without the Refactoring Browser, and often your Unit Tests effectively double the amount of work involved. The velocity of change slows down. Unit Tests might be less nimble to run. A long compile time might be involved. Given those changes, it makes perfect sense that a larger granularity of tests and fewer tests might be more convenient.

<comment><USER17> it may been born in the smalltalk world, but it really was worked fleshed out and challenged and hashed and rehashed in the world of java ( and mirrored in other languages like C++, C#, and ruby ). The XP forum was very active in building what it meant to unit test and how to do test first development, it was highly motivated by the idea of being able to robustly respond to change with quick feedback loops. What became apparent is that the smalltalk world of small modular highly composable designs is kind of critical and much of the C++ / Java world struggled to achieve that, but there was a lot of advice on design techniques. Over time what's been left is more of an emphasis on test than design when talking about that pros and cons of unit testing. So we now want to validate our software works more than we want techniques to quickly evolve our designs and adapt to change in a robust way. Both achieve the idea of working software. So unit testing as a technique to test your software works may not be as good as integration testing and E2E testing, but that wasn't its sole goal, adaptable design was. Not that design has been left behind, if anything we are seeing quite a lot of focus on things like functional programming and new design ideas for putting software together. The key thing is not really the dogma of practices but the ideas of working software and adapting to change and that the idea of robustness and good design is embraced in the core of what you do.

<comment><USER16> _What became apparent is that the smalltalk world of small modular highly composable designs is kind of critical_

All of the cost/benefit tradeoffs of Smalltalk point towards small granularity. You had "everything is an object" to a very high extent. This meant that objects and lambdas had to be super nimble, because literally everything (with just a literal handful of exceptions) was made out of them.

When these pieces get less nimble, the cost/benefit changes, and the granularity at which you operate changes as well.

 _if anything we are seeing quite a lot of focus on things like functional programming_

Some of that is also suitable for small granularity.

Right now, I'm trying to figure out how the above applies to Golang.

</comment></comment></comment><comment><USER18> I believe that contrary to the conventional wisdom one should write tests from top down. First integration tests, then move down to testing individual functions if necessary. Not the other way around.

On my current project, for the first time in my long career, I have 100% code coverage. How I achieved it? By ignoring best practices on what constitutes a unit test. My "unit" tests talk to the databases, read and write files etc. I'll take 100% coverage over unit test purity any day of the week.

<comment><USER19> 100% coverage doesn't mean much if you aren't testing that the low-level code is doing the right thing.

For example, imagine you're testing a calculator app. Your integration tests make sure that it never crashes, the UI works, basic math is working, etc, but maybe the sin() function is only accurate to two decimal places.

Edit: I do not mean to imply that you, specifically, are missing things. Rather, it is possible to write tests that have 100% code coverage while missing many possible bugs, and I think those risks are increased without the presence of unit tests.

<comment><USER18> > 100% coverage doesn't mean much

That's absolutely right. 100% coverage doesn't say much. In fact, by itself it's a pretty meaningless measure of code quality. But the top-down idea still holds. In practice bugs are more likely to happen at the seams between components, and therefore it's where one should test first, not last. It of course depends on the type of the project but I believe it's true for the majority of projects out there.

<comment><USER20> 100% means nothing, but 30% means something is wrong. Coverage tells you nothing, but the absence of coverage is interesting and useful.

</comment></comment></comment></comment><comment><USER21> The number of times I've said "oh I bet this works" just to be wrong when I wrote the tests is countless. For me it's more about having small well-defined interfaces with very strong tests

Moreover, tests that don't break are useless

<comment> munk-a Though brittle tests are also useless, we have some snapshot result tests (take a large set of assumptions, push it through the pipes, get a large result set - in our case it's a webpage, but this holds for other settings) and almost every change to code covered by one of those tests breaks it, then the developer updates the test to work again, was their change logically correct - it can be hard to tell if 500 lines of a 2k expected result changed in minor ways.

So a too-brittle test can be valueless.

</comment></comment><comment><USER22> Integration tests really are the best bang for the buck. So many times people think they tested their code by mocking something like the database layer and are surprised when the application in production breaks. Everything can be tested in isolation and work perfectly, but often it's how the components work together that determines if the system works at all.

Integration test what you can. Unit test core pieces of logic. Avoid mocks.

<comment><USER23> Fully agree. The majority of us are writing code with has to talk to a lot of other systems which we didn't write and don't control. These interface areas between systems are huge gathering places for bugs.

Also, mocks are self-deception at best and lies at worst.

</comment></comment><comment><USER24> In general automated tests are used mostly to save time as the earlier you find the bug the more savings you have when fixing it. When your testers find it, they need to create and fill the ticket, assign it to developer, then developer needs to reproduce, fix it and assign it back and tester needs to retest it. And it's much more expensive if it happens in production! Integration/unit tests can catch a lot of those. There are some diminishing returns so 100% coverage is not needed and integration tests are more effective in catching bugs so I agree with the article's idea. Use unit tests for some real units - algorithms, calculations etc, and don't just test mocking framework. With additional layer of end to end tests and manual testing system should be able to achieve pretty good quality without spending unreasonable amount of time for it.

</comment><comment><USER25> This is pretty similar to my approach. In the context of developing an API I use integration tests more than unit tests. It is straightforward to spin up an application server against a test database with some test data. Run some example requests against it and verify the results.

I frequently have Test classes which contain a full scenario related to a specific resource or action. For example:

* create resource * lookup resource * modify resource * list all resources * delete resource

The JSON files for the integration tests are then used as examples in the API documentation.

Unit tests are reserved mostly for verifying business logic components. There is no need to setup a complex ControllerTest with mocked out Services or Repositories as you don't care about the internals anyway. Just the input vs output and the integration tests cover those already.

</comment><comment><USER26> My comment from the original post verbatim:

I agree with the part that you should write tests, but I definitely disagree with the part that most of your tests should be integration tests.

As you pointed out the testing pyramid suggests that you should write more unit tests. Why? Because if you have ever tried TDD you know that unit tests make you write good (or at least acceptable) code. The reason for this is that testing bad code is hard. By writing mostly integration tests you lose one of the advantages of unit testing and you sidestep the bad code checking part.

The other reason is that unit tests are easy to write. If you have interfaces for your units of code then mocking is also easy. I recommend stubbing though, I think that if you have to use mocks it is a code smell.

Also the .gif with the man in pieces is a straw man. Just because you have to write at least 1 integration test to check whether the man has not fallen apart is not a valid reason to write mostly integration tests! You can't test your codebase reliably with them and they are also very costly to write, run and maintain!

The testing pyramid exists for a reason. It is a product of countless hours of research, testing and head scratching. You should introspect your own methods instead and you might arrive at the conclusion that the codebase you are working on is bad and it is hard to unit test, that's why you have chosen to write mostly integration tests.

</comment><comment><USER27> Maybe but do you think 100% coverage is such a bad experience to have at all ? This can be a rich exercise, and a rite of passage to know what tests matters, which should be automated (fuzzers, dbunit etc), which can wait, etc... and how to get to 90% with the effort of doing doing only 30.

Integration tests should write themselves. It depends on the projects, but personally i use to get 65% of coverage for the price of 5%. For example you want to test a bunch of commands, then you can make a function like autotest('some command', 'some_fixture.txt'): call "some command", capture the output, and write some_fixture.txt with the captured output, and fail complaining that it had to create some_fixture.txt. The next run it will find some_fixture.txt and compare the output and fail only if it differs.

Unit tests should of course be hand written, but to cover everything that matters like for bugs, or for what you want to refactor in TDD. Of course any line that's not covered can potentially break when upgrading versions, but this kind of breaks are likely to be revealed by the 90% of coverage that I think you can get with minimal effort by applying this recipe. Then, you can afford 0day updates when underlying libraries upstream make a new release candidate.

</comment><comment><USER28> 100% coverage doesn't prove the code is fully tested, just like having unit/integration/acceptance/smoke and other types of tests doesn't prove that application works. But this doesn't mean we stop adding tests to our suite, so why stopping adding more coverage?

I totally agree with "just stop mocking so much stuff". Most of the time we can use real implementation and by doing this, we'll also increase coverage.

</comment><comment><USER29> 100% unit test code coverage is just Uncle Bob BS and it is infeasible for the most part

And while it will give some warranties about correctness, it will not fundamentally guarantee the application does what is supposed to do.

Integration tests are certainly better

I can only see the headline being a "great wisdom" to people who have accepted Uncle Bob and TDD crap for too long and without questioning it. Because it is obvious.

Why it is obvious? _Because that 's how things were done most of the time_

When you had 640k of RAM and a C compiler writing unit tests was not impossible, but pretty hard. Testing that your app reacted to inputs and acted correctly was doable and easily automatable. And what wasn't automatable would be tested manually.

Now here comes the "holy highnesses" of testing gurus, gaslighting developers and saying that code with no tests (which tests? automated? unit? the definition is purposefully vague) doesn't work or that the only blessed code is the one that is produced through TDD onanism? No thank you

</comment><comment><USER30> Counterpoint: _Integrated Tests are a Scam_

[https://blog.thecodewhisperer.com/permalink/integrated- tests...](https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a- scam)

I found that argument more convincing, and it also aligns better with my experience.

The point about 100% coverage not being a good goal is pretty solid.

<comment><USER31> For the benefit of others, it's also worth pointing out that the author isn't talking about "integration tests" but "integrated tests" (as he defines it).

Integration tests = testing individual software modules as a group/combination.

Integrated tests = instead of testing one behavior at a time, multiple behaviors are tested simultaneously. (or in the author's words: "any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trivial behavior.")

Integration tests are very important.

<comment><USER30> It is also worth pointing out that the author used to use the term "integration tests" in this post, and only changed to "integrated tests" after writing.

So a claim that these are completely distinct/disjoint ideas is not really supportable.

As far as I can tell, he doesn't explain the name change, but having watched the talk before he changed the name, it looks like "integrated" is a somewhat more general term.

Specifically: if you are "testing individual software modules as a group/combination", how are you going to do that without "depending on the correctness of the implementation of more than one piece of non-trivial behavior."

I see exactly one way: your "integration" tests have to be trivial, really more akin to characterisation tests. "When I hit this external API with this value, do I get this reaction?"

As far as I can tell, he doesn't talk about this in the post, but he does in the talk/video. These are interface/boundary tests. So you test each unit in isolation, and you test the boundaries. If your unit tests are sufficient and your boundary tests are sufficient, plugging things together will work.

So no integrated/integration tests.

Now I am actually not that strict, I let my boundary tests leak a little towards integration/integrated tests, because it is possible to just not hook up the components right. So you want to check that with some smoke tests. However, once they are hooked up, the more complex behaviours Just Work™.

</comment></comment></comment><comment><USER32> I agree with the writer about the statement that you don't need a 100% test coverage but you still need to check your coverage. I mean you need to run coverage and go through your code and see if there is any gap in your testing. That said I don't agree with the statement "mostly integration" the reason is that he don't take into an account the ROI of a test, he only take into account the outcome. I mean e2e tests are the best to catch bugs but they are harder to achieve harder to debug and harder to maintain. Same go for integration test they are harder to debug, maintain and perform than unit test. Developpers forget that their time is money and that if they spend time on a test just because it make them feel safe that mean that the project will cost more money. The general rule I use is simple. When you test, test behavior not code and do your test at the lowest level possible.

</comment><comment><USER33> The thing that changed my approach to testing, at least in OO languages, was being shown that use cases/tasks/"things the system can do" should be first class objects in the model. At that point, you have a single layer that exposes everything of real value in the application, giving you a really simple test surface. Underneath that surface you can refactor to your heart's delight, without worrying about having to maintain lots of pointless unit tests for trivial behaviours on each object - all that matters is maintaining the end to end functionality. So yes, I agree integration tests are the key, and you can architect your application to make this easier. Not over-testing your underlying model is just good old fashioned information-hiding. Testing the UI on top I leave as a matter of taste.

</comment><comment><USER34> >> Write tests. Not too many. Mostly integration.

If a group of reputable programmers got together and published a book about programming which had a single page which only contained this line in a large font, it would be the most useful and valuable programming book ever written.

<comment><USER26> Definitely not. See my comment on the parent.

</comment></comment><comment><USER35> Even at 100% code coverage it is possible to have missed many code paths that involve nonlocal control flow. The most common issue here would be exceptions in languages that support it. In most operating systems there are various interrupts that a program can also encounter (e.g., a lovely SEGFAULT in many *nix type operating systems) and other operating system and hardware level issues (like OOM killer in Linux or an NMI or ECC memory error in embedded systems).

So, 100% code coverage may not even be enough for some applications as was discussed in another too level thread (medical device) or other hard to fix (spacecraft) or life-threatening situations.

</comment><comment><USER36> We have a new guy at work who loves unit tests. Yammers about them constantly.

If he's working on a feature that needs changes to classes A, B and C then his workflow is: make all the changes to class A, along with lots of unit tests. Then do the same for class B. Finally, do the same for class C. And then, after days of work during which the application doesn't even compile, he runs the integration tests and discovers that the application is broken.

Then someone comes over and rewrites his code so it works.

<comment> munk-a So... that rewrite of his code is pretty quick and easy because the components you're integrating are well covered by tests at that point?

Unless the tests on A, B and C are ineffective I think this comment isn't really about tests - some hired developers just aren't great at writing software but if they all used vim that wouldn't mean the cause of their errors was the fact that they used vim.

<comment><USER36> The tests are ineffective. That's because, as the article notes, unit tests - tests of single functions, with dependencies mocked - give very little confidence that code actually works. Problems usually appear in the relationships between parts.

And because they're tightly bound to the internal implementation of the code they test the tests often have to be rewritten when the code is rewritten.

Does this mean unit tests are bad? No. They way they're frequently used I believe they are bad, but you're correct that that wasn't the point I was making. I'm really commenting on the way that common wisdom pushes gimmicky methodologies but doesn't talk about the fundamentals of how to make code changes in an effective way.

<comment> munk-a I agree with you then - there is nothing inherently beneficial from the quantity of unit or integration tests you have, the quality of the tests to accurately target specific edge/error cases is what makes them valuable.

As an aside I find TDD a particularly bad trend for these sorts of bad habits, TDD is a great idea in theory, but you'll often see TDD unit tests come out mimicking the code under test, i.e. "How to test if this function containing `return n + n ^ 2` is correct... well, let's generate some random numbers and then see if the output is equal to that random number plus it's square! That's like full coverage!" Having tests that duplicate the code under test is a pretty easy trap to fall into with micro-tests and it should make you suspicious of any test that covers a very small unit of code.

This is similar to a statistical problem involving over-fitted trend lines, you can construct a mathematical formula that can go through any number of arbitrary (X,Y) points, leading to an average deviance of 0, but this formula will probably break as soon as you take another sample.

</comment></comment></comment></comment><comment><USER37> Discussed at the time: [https://news.ycombinator.com/item?id=15565875](https://news.ycombinator.com/item?id=15565875)

</comment><comment><USER38> > you find yourself spending time testing things that really don't need to be > tested

The thing with 100% code coverage is not that one should write more tests, but that you should refactor everything that isn't business logic (and, thus, nothing that would be part of the functionality of the application to test) into third party libraries, if it doesn't already come from third party libraries, which it probably should.

</comment><comment><USER39> As a counter point to this opinion of Kent's, who I respect greatly, I'd like to propose J. B. Rainsberger's article:

"Integrated Tests Are A Scam" with presentation of the same name.[0]

[0] [https://blog.thecodewhisperer.com/permalink/integrated- tests...](https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a- scam)

</comment><comment><USER40> I think the root of many testing problems is that people write code and continuously test manually until they think it works correctly. Then, they start writing some automated tests.

What I think is much more effective is to write test _instead of_ manual testing while developing. That is, what you would do by hand just implement in a test. And only at the very end, double-check manually.

<comment><USER41> Isn't that just TDD?

<comment><USER40> Similar to it, but not as strict. TDD implies that you write tests first, which also leads the designing of your application code. What I'm describing is more general, where testing happens alternatingly with writing domain code, "roughly" at the same time.

</comment></comment></comment><comment><USER42> I'm not so sure I agree. Often isolated TDD can lead to much cleaner code and succinct solutions. There is also a benefit of quicker test execution. I've seen a noticeable difference in the quality of software delivered to my clients with this approach. Gary Bernhardt covers these topics in great depth and highly recommend to anyone interested.

</comment><comment><USER43> I know this is off topic but why is it that people who, presumably, want us to read their words of wisdom put such a pile of crap at the top of the page that I have to hit the page down key five times before I get to the article?

</comment><comment><USER44> Yeah this is article comes out and says that it's based on gut, not science. So speaking for anecdotal evidence, unit tests that don't break and frequent deploys are way better than finessing one more Gherkin test.

</comment><comment><USER45> Those sticky banners and elements injected by Medium are ridiculous. They make a good article hardly readable on HD desktop monitor. Sad state of things, I remember how once upon a time it was a great platform to be at.

</comment><comment><USER46> At work, the unit tests and data are locked, even the webserver.

Every change of data or requirements causes them to fail or fail because of human error.

At home, I do integration testing and it seems to work much cleaner and more complete.

</comment><comment><USER47> It's confusing with Rails, because integration tests are now system tests, and the kind of integration tests described in this article are named controller and requests tests.

</comment><comment><USER48> This is good. But russian translation is terrible (were translations some marketing move?). Please ignore translation. Read original only

</comment><comment><USER49> have to disagree here...

not writing unit tests means architecture change will break your integration tests. hence, you don't have coverage left during an architecture change.

typing information on a unit (class or function) is nice, except it doesn't find all bugs. If it were to find all bugs about a unit, it would be a complete type checker ( which usually comes in a system like [https://en.wikipedia.org/wiki/Isabelle_(proof_assistant)](https://en.wikipedia.org/wiki/Isabelle_\(proof_assistant\)), etc, which is a pain to use... )

thus the only "efficient way" to cover the gap between type information and a full blown type checking system are unit-tests.

integration test run slower, hence, you are also wasting more time.

integration test are more difficult to understand by other people, especially if they break.

integration test are generally less stable than unit-test because they involve more units.

integration tests usually don't cover all (error) scenerios of the involved particular units. you do that in unit-test to get the branch coverage to 100%.

his issue regarding mocking potentially can be solved differently. change your interfaces and code architecture such that you minimize mocking and make unit- testing easy. i.e. experiment moving the boundary between units.

</comment><comment><USER50> I would say mostly unit and very few integration, if the app codebase is designed well, anyway

</comment><comment><USER51> Maybe the author of Socket.io and Zeit.co just happens to work on integration problems?

</comment><comment><USER52> Wow honestly maybe rethink your upsells here.. literally had to scroll half way through the page to get to the actual article. And what's the purpose of having a full screen splash image of a pineapple with sunglasses..

<comment><USER53> Does Medium force unrelated images into headers? I've never written on it but I can't remember the last time I saw a relevant header image.

<comment><USER54> You don't have to add a header image, but doing it no matter what seems to be the general thinking on Medium, presumably to get people's attention. See freeCodeCamp's guide on writing for them: [https://medium.freecodecamp.org/how-to-get-published-in- the-...](https://medium.freecodecamp.org/how-to-get-published-in-the- freecodecamp-medium-publication-9b342a22400e#590c)

"Medium will automatically make the first image in your article its featured image. This means your article's og-image meta property will be this image. This image will serve as your story's ambassador everywhere: social media news feeds, Reddit, Google News — even RSS readers."

"Start considering images early in the writing process. And never publish without at least one image. Otherwise your story will be all but invisible in news feeds."

I agree the header images are rarely relevant, and I wish they weren't considered must haves.

</comment></comment></comment><comment><USER55> > Well, when you strive for 100% all the time, you find yourself spending time > testing things that really don't need to be tested

I noticed people skip testing what is hard to test and just test what it's easy...

Not what really matters</comment>


Virgin America ditches Flash on its site - <AUTHOR> http://www.macworld.com/article/146820/2010/03/virgin_site.html

<comment><USER2> Quite Frankly Virgin America's website probably never should have been using flash in the first place. It wasn't adding value in this case. (I'm pro flash in the right context, this wasn't one of them)

<comment><USER3> Definitely. I love Flash, but Virgin America's use of it was very obtrusive and made no sense.

<comment><USER4> Most non-game use of Flash is obtrusive and makes no sense...

<comment><USER5> Flash still makes sense for RIAs (Rich Internet Applications) as well. There are admittedly few of them out there though.

</comment></comment></comment></comment><comment><USER6> While it's great to see this stuff get more exposure, I'm kind of tired of seeing it framed as an Apple vs Adobe battle instead of just people with taste vs Adobe. You don't have to have an iPhone to want a site that works well without that horrible plugin.

</comment><comment><USER7> Their interactive route map still requires Flash:

[http://www.virginamerica.com/va/travelInfo.do?pageName=route...](http://www.virginamerica.com/va/travelInfo.do?pageName=routemap&rightBar=routemap_right_bar)

</comment><comment><USER8> obviously this is still very fresh.. try cntrl+click on the slideshow on the home page...

<comment><USER9> good catch!

</comment></comment><comment><USER10> Good for them. Flash has its uses but I feel like at some point in the last 2 or 3 years web developers for many sites realized that writing something in Flash offered better job security and more billable hours than using plain ole' web standards. The other day I went to a site that used Flash for a store locator page and after you filled out the form, in Flash, it simply went to a new HTML page with an embedded HTML map quest object. There was absolutely no reason for this to be in Flash.

<comment><USER11> Doubtful. jQuery, CSS, HTML, JS or Flash? Flash is quicker development time hands down.

<comment><USER12> that's a broad brush, in many cases i would absolutely disagree. really depends on what you building and how well you are building it, particularly when you want flash to work with old plugin version and on mobile devices. and maintaining flash can be a royal pain in the ass, certainly can't just ssh in to the server and poke around with your images and code on a flash site.

but yeah you can bang out some fancy stuff pretty fast in flash.

</comment></comment></comment><comment><USER13> While a lot of media outlets have been playing this up as some sort of tech holy war, it really comes down to the conversions and compatibility. Build a nice standardized site, and you can cut some (but not all) costs when trying to reach out for mobile users. Virgin's not taking sides, they're trying to make a profit.

</comment><comment><USER14> What's amazing is that this is a news story at all. "Websites uses open standards, like most other web sites".

</comment><comment><USER15> Why did they do it?

From the CTO: "Flash eliminates iPhone users."

Point to Apple.

<comment><USER4> Point to all mobiles - Flash sucks up CPU badly enough on desktops, there is as of yet no implementation of Flash I'd consider _good_ on any mobile platform.

</comment></comment><comment><USER16> Adobe should have had a class action lawsuit filed against it for the amount of daily mass suffering it has caused with flash.</comment>


Are Smart Locks Secure, or Just Dumb? - <AUTHOR> http://gizmodo.com/are-smart-locks-secure-or-just-dumb-511093690 <comment><USER2> First thing that popped into my mind: "let's just fuzz the poor thing over BT and see if we can get it to fail"; the device inside doesn't seem particularly robust, as far as electronics are concerned. Oh, and I wonder what a directed EMP (which is as low-tech as it gets) would do to the lock - fail-open? fail- safe? fail-closed? Who knows...and never mind the circuit breaker box located conveniently outside. No juice - now what happens?

<comment><AUTHOR> That's a good point, but as mentioned, if one really wants to get in, there are easier ways than to hack the door. A crossbar to the door is cheaper and demands less effort.

The EMP is a nice thought, I think it would render the electronic boards completely useless as it do to any other digital device. Actually there are/were studies of EMP bombs to be blown over cities that would wreck every single electronic device, even cars. I believe the major problem would be pranksters, either online or offline. Someone might be able to hack into their servers and unlock all doors just because he can.

Anyway, regular old-fashioned keys are something that needed improvement for a long time. Afterall the technology hasn't changed much in over 300 years, so I think it's nice to see some fresh thoughts on this subject.

<comment><USER2> I wasn't thinking anything large-scale: a small EMP device can apparently be built from off-the-shelf parts, yielding a pulse which would only harm electronics in close proximity - I was thinking of burglars instead of pranksters. You are indeed quite correct: the lock isn't always the weakest link, but may be the one that's easiest to break without attracting much attention - breaking through a door tends to be very noisy, and hard to conceal; a broken lock may not be apparent to casual inspection.</comment></comment></comment>


Someone is building a new country focused on digital governance - <AUTHOR> https://promatia.com <comment><AUTHOR> They're building a fully digital government platform for identity, which links with their proposed banking system, citizenship, education, business and more</comment>


New Facebook Ads May Make Money, Upset Users - <AUTHOR> http://www.webpronews.com/topnews/2007/08/23/targeted-facebook-ads-may-make-money-upset-users <comment><USER2> This is a really tough one. Google are already taking serious heat over privacy and other concerns because of the amount of data they hold on users. Facebook will face the same challenges unless they allow users ways to opt- out, even if that means deleting your whole profile.

It's once they start actually selling the data though, that's when we need to _really_ worry.</comment>


Review my startup: TheWP.Co - WordPress / Frontend Dev - <AUTHOR> http://thewp.co So I've recently launched http://thewp.co, which has been my current project for a few months, and I've finally got it launched. I've assembled a few developers, and got a site launched, and this is the result :-).<p>Would love to know your thoughts / feedback. <comment><USER2> Looks great, really nice clean design.

Be more specific about your target audience - guessing it's agencies and designers? You'd work really well with agencies who are primarily designers, who need WP help.

What differentiates you from commodity services like htmlburger/random oDesk freelancers? You're not mentioning price so my assumption is that you're a premium service. Do you offer additional custom development that the commodity slicing services don't?

If you're going for the premium/relationship model, put your picture up, tell your story, tell me where you're located, why will I like working with you and where do you provide value over and above a commodity service?

The faceless corporate look works for commodity services where I want to put PSDs in and get HTML out at the lowest price/hassle possible as part of my business process. If I'm looking for a consultant who will add value to projects (and get paid in proportion) I want to work with people I feel like I already know and like before I even make contact.

Need more specific metrics - it's nice that you guarantee you'll do the work, but do you have a specific turnaround time? Money back guarantee if the work's no good? How much do I need to add onto my client project estimates to afford you?

There's no hook to your offer that will make me think in a few months, when I have a WP project, "Hey what about those guys that promised [X], I should look them up". I already have a number of people on the list in my mind "that do Wordpress stuff". You need to position yourself to be the fastest/cheapest/most W3C compliant/most community supporting/that sort of thing.

Hope this helps... don't take my advice as gospel, it's just the first stuff that came to mind. Most of the above may be worthless :)

<comment><AUTHOR> Wow, thanks for all the feedback. It's agencies, designers, and startups. Basically we do everything from front-end to WordPress (I should probably get a new domain!).

We're a premium service, yes. You want a picture of me? Or the team? You think talking about us being located in Australia will be of benefit? So you're looking for a lot more personality to come through? How would you suggest I add that.

I'll add the specific metrics. Where would you like to see those?

Thanks so, so much.

</comment></comment><comment><AUTHOR> So I've recently launched <http://thewp.co>, which has been my current project for a few months, and I've finally got it launched. I've assembled a few developers, and got a site launched, and this is the result :-).

Would love to know your thoughts / feedback.

Edit: If anyone from HackerNews needs WordPress work, or simply front-end html/css/js, mention that you're coming from here and I'll give you a nice discount.

<comment><USER3> It looks really nice but I'm afraid I don't like the headers font ('Podkova' I think?) - it has really strange serifs that make it a bit jarring to read.

It doesn't detract from the overall impression of the site though, that the core front end competencies for creating decent, clean themes are there :) Good luck!

</comment></comment><comment><USER4> Very nice, I love the design and the fact you simplify the order process for something like this with the tick boxes. Just makes me more likely to use you.

</comment><comment><USER5> Looks very nice and clean, good job! One minor item: <http://thewp.co/get- started/> I would rename the "Place order now" button. "Place order now" sounds very final and commital. Even though it says "Submit your request" under it. I would maybe even take it out altogether and leave only "Submit your request"

<comment><AUTHOR> Agreed, I'll change that now. It's more an enquiry / request anyway.

</comment></comment><comment><USER6> Typo on the order page:

W'll create an enticing store-front for your products. We'll even polish the window for you.</comment>


Cool Algorithm - Fast text search using BWT - <AUTHOR> http://blog.avadis-ngs.com/2012/04/elegant-exact-string-match-using-bwt-2/

<comment><USER2> BWT is a really neat trick, I first came across it in Andrew Tridgell's thesis on rsync, which is worth a read (<http://www.samba.org/~tridge/phd_thesis.pdf>). I changed PMD's copy-paste detector (CPD) to use it, which at the time was a massive improvement over its brute-force approach: [http://onjava.com/pub/a/onjava/2003/03/12/pmd_cpd.html?page=...](http://onjava.com/pub/a/onjava/2003/03/12/pmd_cpd.html?page=last&x-maxdepth=0) ...fairly obviously, the sorted permutations of BWT allow you just to read off duplicates; I was using permutations of tokens not characters.

CPD now uses Rabin-Karp searching, which is faster still. However, writing a copy-paste detector with BWT is fairly trivial and I still keep that script in my head for languages CPD can't handle.

</comment><comment><USER3> As far as I can tell, author is talking about FM-Index. It compresses the search data into a much smaller index memory footprint. I tried using it few times, but never figured out how to use it as a key-value data store. If anybody is interested, here is the code: [http://pizzachili.di.unipi.it/indexes/FM- indexV2/fmindexV2.t...](http://pizzachili.di.unipi.it/indexes/FM- indexV2/fmindexV2.tgz)

<comment><USER4> I guess FM index is just not the right thing to use when you need a key-value data store. It's a _full text_ index -- a data structure, which allows _fast_ substring queries over a _fixed_ text corpus.

<comment><USER5> Perhaps if you want to store (tag) sub-strings with stored data then it might make sense?

<comment><USER4> Yup, that might work, but still, this is a weird idea for a key-value store, maybe a DAWG or a radix tree would do better.

</comment></comment></comment></comment><comment><USER6> Also see Alex Bowe's blog for a description of this:

       http://www.alexbowe.com/tag/datastructures

He describes how you can store the FM-index in less space than the original text.

</comment><comment><USER7> This is awesome!</comment>


Mac users are pre-ordering $699 Eve V crowd developed computer on Indiegogo - <AUTHOR> http://venturebeat.com/2016/11/23/some-mac-users-are-pre-ordering-699-eve-v-convertible-windows-tablets-on-indiegogo/ <comment><USER2> I ve sold mine. Couldn't bare port dropping madness!</comment>


Teaching children coding is a waste of time, OECD chief says - <AUTHOR> https://www.telegraph.co.uk/education/2019/02/21/teaching-children-coding-waste-time-oecd-chief-says/ <comment><USER2> I remember having heard this same idea in the 80s

<comment><USER3> And in the 90's, vis a vis cursive writing and reading analog clocks.</comment></comment>


Canada designs new visa for immigrant entrepreneurs - <AUTHOR> http://www.theglobeandmail.com/report-on-business/small-business/starting-out/canada-designs-new-visa-for-immigrant-entrepreneurs/article4537339/

<comment><AUTHOR> As someone who came to Canada, then moved to the US because of visa restrictions... this is very interesting news. It sounds very much like the Startup Visa that has been proposed in the US but has never been enacted because of the insanity of the US government process right now.

For my fellow H1B-ers in the US and frustrated about the process of starting a company, this could be a very viable option. By weird co-incidence I was back in Vancouver just this weekend, and reflecting on how much I miss that city.</comment>


'fuck' command which corrects your previous console command - <AUTHOR> https://www.github.com/nvbn/thefuck <comment><USER2> Related: [https://nvbn.github.io/2015/10/08/how-thefuck- works/](https://nvbn.github.io/2015/10/08/how-thefuck-works/)</comment>


Worms with three sexes discovered in Mono Lake - <AUTHOR> https://phys.org/news/2019-09-otherworldly-worms-sexes-mono-lake.html <comment><USER2> The paper has nothing to do with their sex but rather about their resistance to arsenic.

Nematodes often exhibit hermaphroditism, which isn't exactly a third sex since hermaphrodites have both male and female gonads they still have binary sexual reproduction just with themselves and when reproducing with a male or a female sexually they would act as a female or a male respectively during reproduction.

As far as sexual reproduction goes this isn't 3 sexes that require each other to reproduce or 3 distinct sexes that can reproduce with each other individually.

</comment><comment><USER3> Not a biologist, but there's nothing that novel about 3 sexes as such. Some fungi have thousands of sexes[1] for example. The way I heard it explained is from an evolutionary point of view there is selection pressure towards either 2 or very large numbers of sexes.

Very large numbers of sexes means it's very likely that when 2 individuals meet they can sexually reproduce (whereas if you have only 2 sexes half the time they cannot). Say there are 100 sex types of a species it might well be that 80% of random couples could sexually reproduce together because there are far more compatible combinations.

On the other hand, evolutionary pressure towards 2 sex types comes from specialisation. It's very helpful for the gamete to either be large and full of food for the developing embryo or to be small and fast to win the race to fertilize. Once the process of specialisation starts, the largest "foodie" gamete and smallest "fast" gamete tend to beat out all the others so you end up with 2 sexes one of which produces eggs and the other sperm.

[1] [https://earthsky.org/earth/fungus-sexes-chromosomes- thousand...](https://earthsky.org/earth/fungus-sexes-chromosomes-thousands)

</comment><comment><USER4> Paper: [https://www.cell.com/current- biology/fulltext/S0960-9822(19)...](https://www.cell.com/current- biology/fulltext/S0960-9822\(19\)31040-1)

Spoiler alert about the three sex:

> _Auanema sp. shares features, such as possessing three sexes: hermaphrodite, > male, and female (Figures S3H–S3Q), with its closest relatives, A. rhodensis > and A. freiburgensis [12]._

It doesn't seam to be so unusual for nematodes [https://en.wikipedia.org/wiki/Nematode#Reproduction](https://en.wikipedia.org/wiki/Nematode#Reproduction)

</comment><comment><USER5> "and carries its young inside its body like a kangaroo"

is fascinating for works.

</comment><comment><USER6> How do I block submissions from phys.org?

<comment><USER4> I've seen a lot of linkbait from phys.org (and other press release reposter). It's usually better to try to explain why the title (or the whole article) is wrong than just complaining. [Someone will downvote you anyway.]

<comment><USER6> I was genuinely curious, you're right about the downvotes. A Chrome ext or a feature like (hide) but site level on HN would be desirable. While at it why not throw in a user level block too? I feel like a lot of people who like phys.org may be downvoting me anyway.</comment></comment></comment>


Self Programming Language - <AUTHOR> http://www.selflanguage.org/ <comment><USER2> Is there a good resource that shows the ideal use of prototypal inheritance? I imagine that the ideal use is not mimicking class-based inheritance, or is it?

I mean if you have an array of things and you want a new instance of such things, it's too unnatural to take one from the array, clone it and change it. It seems more natural to have something class-like: An "empty" prototype and a constructor function.

I guess what I'm wondering is what idioms and patterns are unique to prototypal-inheritance OOP languages.

<comment><USER3> For me, what really made it click and think about how different it is from class-based inheritance was an old Steve Yegge post: [http://steve- yegge.blogspot.com/2008/10/universal-design-pat...](http://steve- yegge.blogspot.com/2008/10/universal-design-pattern.html)

It is a really long post and heavily references Godel, Escher, Bach but this section I think explains the difference really well:

 _Hofstadter offers several supporting examples for this thesis, but I 'll paraphrase one of my all-time favorites. It goes more or less as follows._

 _Imagine you 're listening to announcers commenting on an NFL (American football) game. They're talking about a new rookie player that you don't know anything about. At this point, the rookie – let's say his name is L.T. – is just an instance of the class "football player" with no differentiation._

 _The announcers mention that L.T. is a running back: a bit like Emmitt Smith in that he has great speed and balance, and he 's great at finding holes in the defense._

 _At this point, L.T. is basically an "instance" of (or a clone of) Emmitt Smith: he just inherited all of Emmitt's properties, at least the ones that you're familiar with._

 _Then the announcers add that L.T. is also great at catching the ball, so he 's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs like Walter Payton. And so on._

 _As the announcers add distinguishing attributes, L.T. the Rookie gradually takes shape as a particular entity that relies less and less on the parent class of "football player". He's become a very, very specific football player._

 _But here 's the rub: even though he's a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player._

 _This is called prototype-based modeling: Emmitt Smith was a prototype for L.T., and L.T. became a prototype for Joe, who in turn can serve as the prototype for someone else._

<comment><USER4> That's a helpful explanation.

How would a type system work in that context? Or is there no such thing?

<comment><USER3> Hah that's a good question. I haven't really thought about that or explored type systems that would interact with this pattern. Would be really interested in reading about it though!

<comment><USER4> It seems like the answer is "not well, and it's not recommended": [https://softwareengineering.stackexchange.com/questions/9512...](https://softwareengineering.stackexchange.com/questions/95126/how- does-a-static-type-system-affect-the-design-of-a-prototype-based-language)

<comment><USER2> It's not just about static type systems, though. nerdponx was asking about type systems in general. It's a tricky question even for dynamic type systems. Javascript keeps reference to the constructor and the prototype, so you can determine the "type" that way, but that's not the only way a prototype-based OOP language can work. A language can work without keeping such references and instead simply copying each property on cloning. How do you determine the type of an object then? Is the type based on the presence of certain properties? Does it include the equality of the values of such properties or does just their presence suffice? Does having additional properties change the type? There seem to be many questions with arbitrary answers in making such a dynamic type system.

<comment><USER4> I made both comments!

I think I had static type systems in mind when I asked the question, but that was helpful all the same. It seems in the case of Self it does in fact keep the reference around.

I suppose the whole point of a static type system is moot with a fully prototype-based language. Instead maybe you can enforce compile-time checks (contracts?) on the messages an object is expected to receive.

<comment><USER2> > I made both comments!

Ha! I did not notice! XP

> I suppose the whole point of a static type system is moot with a fully > prototype-based language. Instead maybe you can enforce compile-time checks > (contracts?) on the messages an object is expected to receive.

I think if you can do the latter, you can probably do the former. By that I mean you can probably do neither.

If cloning is something you do in runtime, how can you enforce compile-time checks on the messages they're supposed to receive? Such messages are defined at runtime.

<comment><USER4> Does it have to be at runtime? Is there any point to an ahead-of-time compiled prototype language?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Thread from 2017 ('Can we ever get away from the misnomer of "prototype-based OO"?'): [https://news.ycombinator.com/item?id=14409088](https://news.ycombinator.com/item?id=14409088).

2014: [https://news.ycombinator.com/item?id=7047953](https://news.ycombinator.com/item?id=7047953)

2010: [https://news.ycombinator.com/item?id=1957511](https://news.ycombinator.com/item?id=1957511) and [https://news.ycombinator.com/item?id=1520246](https://news.ycombinator.com/item?id=1520246)

Surely there have been others?

</comment><comment><USER6> note that Lars Bak went onto v8(js) and then Dart [https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)](https://en.wikipedia.org/wiki/Lars_Bak_\(computer_programmer\))

<comment><AUTHOR> He is currently (together with Kasper Lund et al) working on a new language and runtime for IoT use cases.

a recent talk from Curry On 2019 [https://www.curry-on.org/2019/sessions/the- making-of-a-secur...](https://www.curry-on.org/2019/sessions/the-making-of-a- secure-and-robust-iot-development-platform.html)

</comment></comment><comment><USER7> I was super obsessed with Self about 15 years ago. JavaScript's prototypal inheritance was influenced by Self. I was more interested in Self's graphical environment at the time, though.

<comment><USER8> > JavaScript's prototypal inheritance was influenced by Self.

Sadly more as a shortcut to getting an "object system" up and running quickly than as a design principle though, most of the interesting bits of Self were left by the wayside in the process (possibly in part to provide something which feels more like Java).

Not to mention the subtle (and not necessarily sensible) terminological swaps e.g. in Self a prototype is a "blueprint" instance, which is already set up with all relevant traits & mixins, and gets copied and modified to get the proper instance.

<comment><USER9> I thought NewtonScript was a much more interesting descendent of Self than JavaScript. The concept of frames, dual inheritance hierarchy, and the Soup object database really set it apart. The papers on NewtonScript are still interesting reading.

<comment><USER7> I completely forgot about NewtonScript! I wonder if NewtonScript's containment inheritance was influenced by HyperTalk. Seems likely.

<comment><USER9> I think it was more self. The UI paper is informative: [https://cdn.preterhuman.net/texts/computing/apple/newton/Pro...](https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype- Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf)

</comment></comment></comment></comment></comment><comment><USER4> This was a fun watch: [https://www.youtube.com/watch?v=Ox5P7QyL774](https://www.youtube.com/watch?v=Ox5P7QyL774)

<comment><USER10> Not only fun, educational, too. For example, I learned that Self had multiple code generators, just as modern JavaScript engines have "give me decent code, fast", and "give me fast code; may take some time" engines.

</comment></comment><comment><USER11> This language also inspired LambdaMOO (created by another Xerox Parc employee) which is another early example of a prototype based language, with its own built in environment, but it's all text based. I'd heard about self in a talk, but hadn't read the docs until now. Super cool reading about it now. Good slice of history.

</comment><comment><USER12> I don't understand why languages like these are not mainstream. Why are we stuck with blindly editing text files and waiting for compilation that restarts the whole world? Why state of the art is a REPL where immediate feedback is limited to printed text with all the actual values barely reachable?

<comment><USER2> > Why are we stuck with blindly editing text files

It's inherently more portable and composable.

> waiting for compilation

There are many languages that are interpreted that are mainstream.

> that restarts the whole world

You can program in mainstream languages without restarting the world. See skewer-mode[1] for example, for programming in javascript without restarting/refreshing. You can change top-level definitions and send them to override the previous definitions. You can do this with any language that allows overriding functions at runtime, IOW late-binding languages with an eval function, like python and ruby. This way of programming is probably very non-mainstream, though. The reason why it's not more popular is probably because most of us are working with programs that take little to no time to restart and get to the same state. Restarting ensures that whatever state we see in the program is reachable with the current state of the source code.

> Why state of the art is a REPL where immediate feedback is limited to > printed text with all the actual values barely reachable?

Again, because that's inherently more portable and composable. What do you mean they "actual values [are] barely reachable"? You can access anything via any REPL I can think of.

[1] [https://github.com/skeeto/skewer-mode](https://github.com/skeeto/skewer- mode)

</comment></comment><comment><USER2> The handbook seems down. Here's The Internet Archive's copy:

[https://web.archive.org/web/20190417013701/http://handbook.s...](https://web.archive.org/web/20190417013701/http://handbook.selflanguage.org/)

</comment><comment><USER13> The interface builder I hope one day to design, was design 30 years ago ... gloups ;)</comment>


"The End of Silicon Valley" Is Nonsense - <AUTHOR> http://blog.eladgil.com/2012/09/enough-with-this-end-of-silicon-valley.html

<comment><USER2> "Personal financial stability and past experience can go a long way for people to take big bets."

Really liked that quote. One of the benefits silicon valley gets when it mints a few hundred or so millionaires is that those people now go out a bit more fearless.

Tom Lyon who is a serial entrepreneur once told me that you really needed three wins, the first was you joined a company that taught you about what being a tech company entailed, the second was a startup where you made enough out of it that you could do a third where you could better control the economics and the vision. There may be a number of attempts in that thread but its really true.

A number of people I know seem to have various milestones for fearlessness, but they roughly correlate to;

1) they own their house free and clear,

2) they have enough money set aside for their kids educations,

3) they have enough money set aside to keep them in Ramen indefinitely[1].

Each level brings its own level of fearlessness.

[1] generally the 'retirement' calculators ask you to predict when you're going to die. So you take that number, the cost of paying taxes/insurance on your house and your own health + ramen and that is your 'ramen retirement' number. Note that you leave behind a giant asset (the house) so many folks assume selling the house and moving to a smaller/cheaper place in that number.

<comment><USER3> This is a great post and a real eye opener.

Translation: In maths for SF

1) $1-2 million, minimum for a house for 4

2) $250K per kid x 2 = $500k, assuming public high school

3) Min $1 million per head, 50k pre tak 30-40k post tax

total: $3.5 million to $4.5 million, NAV ~= 5% pretax of $100m exit

Sorta-back-of-the-envelope

This is why you need N exits, not just 1

<comment><USER4> Or just don't live in the SF / Bay Area. If you want to have a crazy runway for your startup work towards paying off a 250k (or less) house with solar on it just about anywhere else in the US. The counter-argument to this is that being in SF,NY,etc gives you connections, opportunities, etc. but Id rather just not have to worry about coming up with a sizable chunk just to make sure my family has a roof over their heads.

<comment><USER3> Good post too, but this is only a ~21% reduction in the total (2.75 vs 3.5). You're still looking at ~80% of the cost base. The neutral decision point is only @ 25% increase in exit/success neede to make the switch to metro (80 to 100).

<comment><USER4> That is true - there is no math to this one but I do know from observation that if you have a decent roof over your head, running water and electricity, decent transportation, an internet connection and a computer all "paid off"... the rest of life can be lived well and paid for very very cheaply.

May be an entrepreneurial way to think about for those that are prone to being a cheap ass like me

<comment><USER3> _various milestones for fearlessness_

Yes, some are only in mind-- including ability to overcome fear, in general

</comment></comment></comment></comment></comment></comment><comment><USER5> No, it's really not nonsense at all. I honestly couldn't think of a worse place to start a company than Silicon Valley, other than potentially a third world country with no internet. Extremely high costs of living, constant talent warfare, and absolutely terrible traffic at peak hours. Unless you're venture backed, stay the hell away from the bay.

<comment><USER6> Care to name a few better places?

<comment><USER7> I'll just throw this out there: Kansas City?

I am actually wondering if the Google Fiber initiative there will cause a startup boom.

<comment><USER6> Is fast personal internet really that much of a driver?

SV has the money, it has the talent, it has the beautiful weather. Yeah the rent sucks, but that's the only downside I know.

<comment><USER8> I hate SF weather. Foggy and cold year round. Not that it matters, startup people never see the outdoors.

<comment><USER9> SF != SV

<comment><USER8> I'd rather live in a bad city than a nice suburb.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Very well said.

I've been planning a blog post for some time on "hidden principles of Silicon Valley"; basically the unsaid assumptions that the top investors seem to follow but the startup peanut gallery don't grasp. Just little tidbits I've gained from the writings of Peter Thiel, Paul Graham, Marc Andreesen, Mark Suster, Ben Horowitz, etc.

One example: lots of people decry the trend for valley startups to burn cash to grow market share. Silly startups, why can't they bootstrap? Why is LinkedIn trading at a 300+ P/E ratio? But the hidden assumption (which may be wrong) is that the winners of today's tech game will be around for a long time, generating billion-dollar cashflows for decades.

Peter Thiel explained it better than I can:

"PayPal is illustrative. 27 months in, its growth rate was 100%. Everybody knew that rate would decelerate, but figured that it would still be higher than the discount rate. The plan was that most of the value would come around 2011. Even that long-term thinking turned out to undershoot; the discount rate has been lower than ex- pected, and the growth rate is still at a healthy 15%. Now, it looks like most of PayPal's value won't come until in 2020.

LinkedIn is another good example of the importance of the long- term. Its market cap is currently around around $10B and it's trading at a (very high) P/E of about 850. But discounted cash flow analysis makes LinkedIn's valuation make sense; it's expected to create around $2B in value between 2012 and 2019, while the other $8B reflects ex- pectations about 2020 and beyond. LinkedIn's valuation, in other words, only makes sense if there's durability, i.e. if it's around to cre- ate all that value in the decades to come."

It never fails to amuse me that the mean HN poster is actually quite cynical about startups -- I think this is partly due to cynical people posting more.

<comment><USER3> So, how does this relate to PG's article: _Black Swan Farming_? There is a huge difference in profiting from a stochasitic-but-diversified portfolio with massive variance and extrapolating from the outlier data. The properties of the outlier data, by definition, are not charachteristic of the data-set as a whole. The properties of the outlier data are useful for talking about the potential of future outliers and possible portfolio variance.

 _'The sink or swim strategy was successful for all 1% of the successes'_? [1]

Its easy to overgeneralize.

__________

[1] 'The sink or swim strategy was _not_ successful for all 99x1% of the non- successes.'

<comment><USER11> >" _The properties of the outlier data, by definition, are not charachteristic of the data-set as a whole_ "

Graham's statement about three-quarters of the value of YC's $10 billion portfolio being comprised of Dropbox and Airbnb counters this. It's the difference between the probability density function and the aggregated cumulative distribution function.

This is actually part of the founding logic of modern portfolio theory: let's suppose all start-ups have a 1% chance of making it to a billion and a 99% chance of going bust. From the start-ups' perspectives, the $1 billion exit outcome is an outlier scenario. If I put a few hundred of these guys in a portfolio, however, it would be _improbable_ for not one of them to Instagram.

This oversimplifies as it assumes simple distributions and pre-known probability densities, but it illustrates one of the un-intuitive effects of the way variances combine mathematically.

<comment><USER3> The counter-argument is that black swan is not a regular _gaussian_ style outlier from a known distribution. Its better thought of a datapoint from an <Uncertain> process, being mixed into your run of the mill vanilla <stochasitic> one. Thats the issue -- I appreciate your comment making it more clear. So, if we take the black swans and put them into a group, its not clear what we have. Though it seems a stretch that they would be representative of the vanilla process per-se.

</comment></comment></comment></comment><comment><USER12> A better title would be "The End of software startups in Silicon Valley Is Nonsense". There are plenty of companies in the SV that will still be there when the software startups are gone.

Also, behind the strawman arguments there are some hidden truths but they have to be rephrased to be interesting, e.g. software isn't easy but it appears to be easy so lots of people enter the field that shouldn't. Also, people should be working on harder things but not for the reasons discussed in the article.

<comment><USER13> Are there any good websites that cover non-software startups? As a physical scientist/engineer in training, I am more interested in the "physics or advanced materials" type of startups mentioned in the article.</comment></comment>


Launch HN: Anima  App (YC S18) – Sketch to Code Toolkit - <AUTHOR> Hi HN,
We are Avishay, Michal and Or, founders of Anima App (https://www.animaapp.com).
We let designers create UIs in Sketch and then export HTML and CSS.
One the biggest pain points that we've experienced working in the software development industry, like so many before us, is the process of taking design to production. Designers today use tools like Sketch to design websites, web apps, or mobile apps, but these tools are limited and static. After experiencing the pain first-hand for over a decade, we resigned ourselves to try to make any kind of improvement we could.
We started by building our own fully-featured design studio software that allowed users to design iOS apps and export Swift code. But we quickly learned that although people were excited about it and tried it out, after about a week they went back to using Sketch. We realized that while writing algorithms for a layout engine is hard, getting adoption for your new product is harder!
Luckily one of our users pointed us in the right direction when they said that out of everything we've built, they were only really excited about our Auto-Layout engine. And so we decided to yank out our Auto-Layout solution and release it as a Sketch plugin. That was the turning point for us. Auto-Layout became very popular (100k users) and to this day is a main engine of growth for us.
In the past year and a half we shipped three products:

  • Auto-Layout - Responsive Design for Sketch[1]
  • Launchpad - Export Sketch to HTML[2]
  • Timeline - Interaction Design for Sketch[3]
 The team consists of Michal, our co-founder/designer and 2 technical founders, myself (Avishay) and Or (previously founded the Yo app).
Of course we are dogfooding our products and have built our websites using our own tools.
We're sure that Hacker News readers will have a ton of experience in this space, and would love to hear about your experiences and ideas!
[1] https://medium.com/sketch-app-sources/introducing-auto-layou...
[2] https://launchpad.animaapp.com
[3] https://timeline.animaapp.com <comment><USER2> I run a design studio and some of our designers are big fans. We've unfortunately had to disable Anima across the team due to compatibility issues between designers who have created UIs with the help of your Sketch plugin and those who don't have the plugin installed.

The latter group often spend quite a bit of time fixing broken alignments etc when picking up a Sketch file that's used Anima. This means everyone is forced to install the plugin. The other issue then is when pushing to Zeplin, many elements aren't aligned as designed regardless of whether we've got your plugin enabled or not.

It doesn't happen every time, but it's happened enough times to warrant a studio-wide disabling of the plugin. I don't know if it's possible to easily solve this dependency issue in a future release, but if you can, we'll certainly start using it again.

<comment><USER3> The way our Auto-Layout plugin works is by hooking into the internals of Sketch and enforcing layout rules in real-time (i.e when the mouse moves). If someone doesn't have the plugin installed, the Sketch file can still be opened but they won't have the code that enforces the layout rules, so yes it will look and behave differently.

So while using Auto-Layout can save an enormous amount of time creating UI, it definitely needs to be used by all designers that work on the file.

In terms of exporting to other parties such as Zeplin, we have a feature that turns off all the layout rules just before exporting. If you have tried it out here it is: [https://animaapp.github.io/docs/v1/launchpad/faq.html#Export...](https://animaapp.github.io/docs/v1/launchpad/faq.html#Export- to-other-plugins)

And thank you for the kind words!

<comment><USER2> Thanks for the insight - that's good to know. If I remember correctly, the last time we looked into it, the solution for exporting was to detach all symbols. I wasn't aware of the feature you've mentioned. Will definitely give that a try!

</comment></comment></comment><comment><USER4> If this works well, I could see it reducing a huge amount of drudgery in the industry. But it could also reduce billable hours for less experienced developers who take on this sort of work. I have been wondering for a while why such a tool didn't already exist given its obvious utility.

<comment><USER3> You definitely have a point.

This type of solution has obvious upside. The truth is that it has been tried many times before (Flash, Frontpage, Adobe Muse). The hard thing here is to being adopted both by the designers who start the process and at the same time generate code that developers will agree to work with.

The way we tackle this is by giving designers tools to express what they want in ways that were not available before, and then use the output to generate code. For example, one popular feature is Stacks[1] which is basically CSS Flexbox for Sketch. When designers use Stacks, we can then use that data and generate an actual CSS Flexbox from it.

Designers are adopting this approach but in terms of code generation, we still have a lot of room for improvement. The code works great, but it's not always optimal in the way that a good human developer would write it.

We have an internal goal, which is to pass the "Turing Test", where a developer will not be able to recognize whether our algorithms or by a fellow human developer.

[1] [https://medium.com/sketch-app-sources/auto-layout- introducin...](https://medium.com/sketch-app-sources/auto-layout-introducing- stacks-flexbox-for-sketch-c8a11422c7b5)

<comment><USER5> For a proper development shop, the developers wouldn't use the generated code. It would require so much rework to fit their framework that you might as well just write it from scratch. I have worked with tools like yours, Adobe has an enterprise product that is a bit ahead of yours.

Writing HTML and CSS is not the hard part of front-end development. A modest developer can put this together quickly. The hard part is using javascript or someone other tech to piece it all together.

I would encourage you _not_ to chase your internal goal. Instead, focus on making designers better instead of trying to turn designers into developers. W3C will release a new CSS/HTML spec, or some fancy new JS framework will come out and you'll be left scrambling to re-engineer.

<comment><USER3> We get this a lot and I do understand where you're coming from. Replacing human engineers will not happen any day now, but we project our vision years ahead.

For the time being, even if developers don't use the generated code, but rather just inspect it is better then guessing how a component should work by staring at a static image or a GIF.

If you take for example this elaborate interactive component: [https://handoff.animaapp.com/#/timeline/XKHmOQP5Hcuipv/anima...](https://handoff.animaapp.com/#/timeline/XKHmOQP5Hcuipv/animated- designer-developer)

It was made completely by Michal, our co-founder/designer in Sketch with Anima. No code was manually written. Trying to convey this today usually involves hand-waving or for advanced teams, a GIF. By handing off functional code, a developer can interact and see the values that make this work. Even if not using the actual generated code.

Does that make sense? What do you think?

<comment><USER6> So it becomes a medium of communication rather than an actual usuable code. That is interesting...

</comment></comment></comment></comment></comment><comment><USER7> This reminds me of [https://pagedraw.io/](https://pagedraw.io/)

</comment><comment><USER8> Congrats on all the new products! Somehow I missed a year of your releases -- my loss. I remember how transformative auto-layout was for my team when it came out. For the first time designers could, for themselves, grapple with the tradeoffs of different layout / resizing rules pre handoff. I think the unrecognized impact of tools like yours is that they give designers a playground to think about some problems in a more developer-like way. Regardless of how much of the code makes it into production I think that's a win for designers and their teams. Looks like timeline has the potential to do the same thing for interactions and animations.

You guys helped invent this space not too long ago and I'm curious where you all see things going long term?

<comment><USER3> Thank you.

Today the tools we provide force designers to think in a more structured way. A great example of this is Stacks, which forces a layout to be consistent. Unstructured design, or in other words, floating layers corresponds to CSS's absolute position. Stacks, however, corresponds to CSS's Flexbox.

By enforcing designs to adhere to concepts which are borrowed from the development world, we can actually convert design to code.

In the long-term, we see that not only layout will be structured and translated, but all aspects of a user interface.

</comment></comment><comment><USER9> The textboxes on your website homepage are not aligned but offset to the bottom right. (iOS, chrome, iPhone 6s). Kind of a immediate turndown for a site that proclaims to be a designer end-2-end tool. Would probably fix that (was the site made with your tool?).

Finally, this is very hard to do correctly but as always great risks have huge payoffs if you manage to get it right. I wish you luck. Back-and-forth is where the future is.

P.s. not sure if you have it but also make a code-2-designer. Can't count the times we had our devs fix issues in the design only to have a turnaround time of weeks before design handed over the new templates.

How to call this new breed of designers though? We have had devops for the new ops* which has a nice ring to it. But this?

*Semi-ops depending on your company and company size.

</comment><comment><USER10> For those curious, checkout FOSS Pix2Code

[https://github.com/tonybeltramelli/pix2code](https://github.com/tonybeltramelli/pix2code)

</comment><comment><USER11> I remember using Autolayout, but I think Sketch now natively supports it. But Sketch is 2016 - Figma is the future :)

Seriously, you guys should start aligning with Figma & Atomic...

<comment><USER3> Yes. We're definitely planning to expand to more platforms. Stay tuned :)

</comment></comment><comment><USER12> Show a demo on the landing page. Will drive more sales

<comment><AUTHOR> Until we have a new one: [https://www.youtube.com/watch?v=1gnxY6eC_78](https://www.youtube.com/watch?v=1gnxY6eC_78)</comment></comment>


What Makes Extraordinary Science Extraordinary - <AUTHOR> http://www.preposterousuniverse.com/blog/ <comment><USER2> This may be a better link:

[http://www.preposterousuniverse.com/blog/2018/01/29/guest- po...](http://www.preposterousuniverse.com/blog/2018/01/29/guest-post-nicole- yunger-halpern-on-what-makes-extraordinary-science-extraordinary/)</comment>


Vladimir Putin's Stasi ID Card Found in German Archives - <AUTHOR> https://edition.cnn.com/2018/12/12/europe/putin-stasi-id-card-grm-scli-intl/index.html <comment><USER2> In 1991 the Germans distributed the Stasi Archives to appropriate countries. In Scandinavian countries the information was immediately either destroyed or hidden in the archives of the secret police. The rumor is that almost every member of the ruling leftist or social-democrat parties were connected with Stasi.</comment>


Sonos Alternative (Preferably HIFI and FOSS Friendly) - <AUTHOR> SONOS is phasing out speakers by no longer offering software updates after May 2020. Even worse, all SONOS networks containing even one such phased-out speaker will no longer be updated.<p>I would appreciate recommendations for alternative systems, preferably high quality, connected speakers with open APIs and FOSS friendly. Any ideas? <comment><USER2> I am mostly happy with my Denon HEOS system. The API is pretty easy to work with, and it's got the big advantage that it works with A/V receivers which will give you much better sound than others.</comment>