Testers vs. TDD - <AUTHOR> https://www.functionize.com/blog/testers-vs-tdd <comment><USER2> This title makes my eye twitch.

The times when I've seen testers and TDD come into a "vs" situation, the whole thing was invariably just senselessly tragic. The testers saw developers writing tests as an immediate threat, and responded to in a very self- defeating fashion. They would refuse to acknowledge the automated tests and insist on manually testing everything. Perhaps even, paradoxically enough, _increasing_ their manual testing load by creating manual versions of as many automated tests as possible. This would, in turn, reduce the time available for digging deep and doing the kinds of testing that aren't amenable to automation (or to automating with a typical unit testing framework), while also increasing the need for painful things like code freezes. Ultimately, ironically enough, the work they were doing became increasingly redundant, and the automated testing did, in the end, turn out to be a serious threat. Not to the interesting and highly specialized work they wanted to be doing, but to the senseless busywork they unnecessarily roped themselves into.

But not by necessity. It's so much nicer when QA can collaborate with and guide the developers' automated testing efforts. It's such an easy win-win situation: Developers get close guidance from software quality experts on how to ship higher-quality software, and testers get to spend less time stuck in a quagmire of tracking down and filing reports for a mess of silly little bugs that never should have made it onto their desks in the first place. Which should hopefully kick off a virtuous cycle of everyone helping everyone else be more productive and happier at work.

<comment><USER3> In my experience, such "tragicness" came from the fact that the company already made their decision: automate the tests, fire those other guys. So once me and my colleagues showed up, the final nail was already in coffin.

The mindset of improving the testers work, enabling those humans to do better work, is rare in big corps. I've witnessed many QA departments shutdown or being shipped overseas.

In the latter cases, you would be inclined to root for team "manual work" (i.e. at least some person gets a job somewhere), but corps are just prolonging their cultural malpractice. Just by dumping labour costs you're not improving productivity.

</comment></comment><comment><USER4> > Test-driven development was supposed to eliminate the need for independent > testing.

Who seriously makes this claim?

<comment><USER5> People without a professional background in test. Problem is everyone else thinks we have a conflict of interest.

</comment></comment><comment><USER6> It seems author misses the point of TDD: TDD is a methodology that allows you to write unit-testable code.

Writing unit tests after you write code is a very hard, an almost impossible problem (you either refactor everything, or you end up with some "lower level" of integration testing everything, or you end up mocking everything — unless you refactor, your code is unlikely to be unit-testable). Though with practice, one can learn to write mostly side-effect free unit-testable code, but to a non-TDD-enlightened person, that code will look "too convoluted" with simplistic "unneeded" functions. TDD is generally very "functional" in spirit (so for pure unit-testing, no mocks).

Production-level applications do get by with integration and system tests, and infrequently, that's good enough (other than slow test suite run times). But unit tests allow for speedy test suite on top! Unit tests, by definition, do not cover stuff that proper QA would cover: they only ensure that smallest units of work (functions/methods/classes) do what they are supposed to.

One of the common pitfalls with TDD and unit-testing is that you end up having a function that's sufficiently well covered with unit tests, but as it evolves into something more complex, you are lazy or lack the time to properly split unit tests as you split your original function. Then you end up with what I called "lower-level integration testing" above: a bunch of tests testing a single complex function instead of individual units of work.

The biggest advantage of unit tests is that you cover every integration point with only a single integration test (eg. between two classes interacting), and all the edge cases on either side with unit tests. This leads to fast test times that do not test everything for every single combination of arguments.

Replacement for QA are instead system tests. They should neither test all the combinations of system conditions, but should ensure that a couple of critical, common paths through the _system_ are working.

QA teams today, when present, are in charge of managing and writing system tests, but if they are not part of the development team, there's a lot of tension and wasted hours in keeping things up to date.

<comment><USER7> With some experience, I find it impossible to write code using TDD that is difficult to refactor. Good code, that scores well on SOLID metrics, is easy to refactor, because individual pieces are already split out into multiple classes, rather than living as a series of statements in a single method in a single class.

>One of the common pitfalls with TDD and unit-testing is that you end up having a function that's sufficiently well covered with unit tests, but as it evolves into something more complex,

A function should not evolve into something more complex. It should be split out into multiple functions, each of which is simple. In addition to being far easier to test individually, you will find that when you need to change it, only some parts will need to be discarded.

<comment><USER6> I was exactly referring to a function that's split up into multiple simple functions where tests aren't. I agree, it's not a pitfall of TDD, but rather of doing it, then not doing it.

</comment></comment></comment><comment><USER8> I don't think unit tests are even the only form of testing prescribed by TDD, although it might've been what Mr. Beck had in mind back then. It's test _driven_ development: invalidate implementations that don't implement your specification!

Unit tests are, unfortunately, not sufficient at expressing complex invariant properties and assumptions.

So try property based tests.

You can't even have _Continuous Integration_ without _integration tests_ and you shouldn't be practicing _Continuous Delivery_ without an effective testing strategy. How else can you ship dozens of delta changes to production on a heavily trafficked site without taking down the service?

Not sure what to test? System hard to describe? Try formal methods. Tools like TLA+ or Alloy are great at helping us understand systems with global or temporal properties and complex behaviors.

GUIs? There are nascent projects to add property testing to the browser [0]. There are tools to model GUIs [1]. There are books to use property based testing on GUI-driven applications. It can be done [2]. It requires effort from a _test driven development_ team.

I've seen QA Teams ruin businesses. When they act as gate keepers to the production environment releases slow to a crawl, issues run unchecked for weeks as high-level e2e test results are inefficiently communicated and the source of the problem is rarely obvious or known. Developers then have to dedicate time to helping testers investigate poorly understood test failures which requires more developers to pick up the slack. More features requires more testers. And the cycle slows down releases to the point that your horizon for even a basic new feature is a couple months at best.

[0] [https://webcheck.tools/](https://webcheck.tools/) [1] [https://sketch.systems/](https://sketch.systems/) [2] [https://leanpub.com/property-based-testing-in-a- screencast-e...](https://leanpub.com/property-based-testing-in-a-screencast- editor)

<comment><USER9> >Unit tests are, unfortunately, not sufficient at expressing complex invariant properties and assumptions.

They're also insufficient at clearly articulating most specifications. Unit tests allow you to express clearly specifications in the form of code APIs that don't have complex side effects. They suck at _everything_ else (that's about 90% of all real code).

Good luck converting that user mock up into a unit test.

TDD is technically _possible_ with UAT - it just requires sophisticated tooling that is, most of the time, more expensive to build and maintain than your actual app. It also requires love/investment to make it _fast_ enough.

Its not worth it most of the time and TDD with unit tests is an insufficient salve. Hence QA teams and developers who have a feedback loop that involves running the code and clicking stuff.

</comment></comment><comment><USER10> I think the most important point that I'm not sure the article emphasises prominently enough is the purpose of both is completely different, which is why of course one doesn't replace the need for the other.

Testers' work is focused around the user. User input in, user outcome out. Tests pass to the extent the user has a satisfactory outcome. How that outcome was achieved with code is of no concern whatsoever.

TDD is a tool for engineers to have confidence in code. Function calls in, function return values out. Tests pass when code behaves as expected. How that code is then used as part of a wider system, and the outcomes of that, is of no concern whatsoever.

</comment><comment><USER11> As a former dedicated tester and now developer, I feel that dedicated QA may not be as useful in the way software is developed these days. I like to view TDD as "requirement-driven development". If you think of it that way, if you're not testing your logic completely, then you have incomplete requirements.

Having other developers peer review seems to be a better improvement on the legacy process of dedicated QA. This means that you can't just throw commodity developers at a project; you do need people with expertise. To round it out, you do need UAT and acceptance testing but those are still variants of requirement-driven development.

<comment><USER12> the only requirement driving my unit tests are things that id like to be independently testable and there could be 100s of those when implementing a feature.. or if i know the code will be throw away, maybe 0

</comment></comment><comment><USER13> I checked OP's product page ([https://www.functionize.com/](https://www.functionize.com/)) and it got me very interested.

However, unfortunately, there's no pricing information in sight.

If Space X can display their pricing upfront for launching an orbital rocket, why do I have to talk to sales to know how much a product like this costs?

Anyways, I took the time to come here complain about this, but didn't bother to take the time to fill up their "contact sales" form because it would be too much of a hassle. Go figure.

</comment><comment><USER14> The article is wrong on so many levels. First, there is no such thing as "TDD developers" :D and yes, developers should write end-to-end tests. Also, developers should test code manually! at the time of writing to make sure they completed the job... Also knowing the product you are working on is a very sensible thing to do (although I hate doing it, because I find it boring), so developers should also do the kind of "exploratory testing" occasionally.

There are a lot of problems separating these roles (blame game, unnecessary work, conflicts, cost), when you bring those tasks closer to developers, there are no need for testers. They should develop software and write tests too!

Security? You are in big trouble when security is just an afterthought and only testers think about it... Security is a mindset, constant vigilance and learning. Sorry, but some process or tool won't solve that for you.

<comment><USER15> >First, there is no such thing as "TDD developers" :D and yes, developers should write end-to-end tests. Also, developers should test code manually!

In principle I'm a fan of TDD. In practice, most environments are "agile" and require so many and such frequent fundamental design changes that even well developed tests become irrelevant/incompatible and only create a hindrance to development, including interacting with the testing infrastructure as well (as if developers didn't have enough to do already, they're often also taking care of devops, QA, product owner, and project management).

Quick and dirty frequent manual testing on whatever you're developing is typically often the best you can get away with.

</comment></comment><comment><USER16> Funny thing is, the less a tester knows about testing, the better they are. At least this was my experience.

This is both good and bad.

Good because you can give basically anyone a testing protocol and let them work through it. The new ones always find new bugs or inconsistencies.

Bad because testers have a half-life. If they do the job for too long, they will miss regressions.

<comment><USER5> You have to rotate manual testers aggressively between areas to avoid that.

For exploratory, my take is rotating every release is usually OK. You need the area expertise for good exploratory but don't want them to get jaded. Since they roll their own experiments it doesn't happen as fast.

But scripted is far different. Using manual testers for scripted regression is a bad idea for all kinds of reasons, but you honestly should never use them more than once in a row in the same area. We're just too hardwired to autopilot or cut corners when doing scripts once they're learned. But once is OK, so it's novel, and when they forget later it can be OK again until they learn the script again. It's why crowdsourcing has actually worked pretty well in that area.

But really, just don't use scripted manual. It doesn't work. Put people on exploratory, put scripts in automation, don't pretend either can do it alone.

I don't think it's a function of career length, though, and that threatens to be a bit ageist to be frank. I'm quite sure I found more and better bugs the length of my primary-QA career, so long as I cared about the job and didn't have to recite a script. Burnout times were different, but those aren't age- bound.

<comment><USER16> Your suggestions sound reasonable, but didn't work for various reasons.

There was just one UI, so we couldn't rotate.

Automated UI tests were too brittle so we had do use testers for the scripts.

<comment><USER5> I'm going to assume you're not talking one simple single page utility, otherwise what I'm saying here is absolutely overkill and it's a little weird you'd have big enough testing problems to matter. But assuming you mean something close to a modern production system with a UI, i.e. multiple screens or tabs or panes or functions:

Re: UI, you typically decompose it into parts (the main menu is useful here, or a use case/requirements tree) so that it can be tested in parallel by multiple people. You'd rotate those assignments. If you weren't doing functional decomposition of your UI, you were probably already well off best practices.

Re: scripted manual UI tests, that's pretty much describing hosing your QA. That's no reason at all, it's Antipattern #1 to avoid.

Brittle UI scripts happen when people who don't understand Page/Object Model and other techniques around architecting and selecting UI tests build them. UI scripts are natually more _fragile_ but if you're finding them _brittle_ (i.e., the scripts actually do break enough to get a reputation and kill confidence) you're either trying to E2E stuff that you shouldn't be or you're writing them wrong and haven't mitigated their fragility according to best practice around abstracting the UI under test.

There is no excuse in the world for leaving a brittle UI script in place, and the mitigation for not covering with a UI script isn't manual scripted regression testing, it's unscripted exploratory testing, preferably guided. All that brittleness in the automation script is also confidence-killing in your manual script because it represents environmental unknowns or non- deterministic operations that were critical enough to break the script. The human has those too, so now they're not on the script you thought you wrote anymore. They make less noise and do their best but it's like an unconditional exception handler. Nothing likely got fixed, just covered up.

With exploratory, you acknowledge up front that they can use discretion, so you're not tempted to pretend it's a day over day regression test and build false confidence. It's not a valid regression strategy because people aren't that consistent, but it's an excellent new-bug finding strategy because you look at new features immediately, and approach old features in new ways to break your own boredom. You're probably doing "unintended exploratory" right now if you're trying manual scripted. That's a bad thing, has all the "not valid regression" and all the "false confidence" issues.

Best thing about moving away from manual scripted, you save a _ton_ of money not trying to maintain a library of Step/Verify scripts that break Single Point of Truth by repeating the same flows all over the place and therefore don't maintain worth a damn. Instead you test against the docs, so you get to dogfood those too.

My strong suggestion, were you to consult with me for QA/automation, would very likely be to take 20% of your time and build better scripts to dig yourself out, assuming this is a process you're keeping around. I can't say that for sure because I don't know your company or product, of course, but around the time you have testing pain is around the time to do this.

Were I to use my typical strategy for resetting UI test it'd be:

1\. Start by cutting all the non-P0 cases. Most systems end up with basically one P0 case per major advertised feature, almost always happy path, so that's usually less than ten things where if they don't work, you can't ship the app at all, no matter how much time it takes to debug. Automate those scenarios. That's now your core UI acceptance suite. If you make it very small and limit only to things that can never, ever break you may be able to even use it in CI.

On another note, while they aren't common at all anymore, record/replay UI automation systems are actually useful for this. With so few test cases you can scrap and re-record throughout the cycle if you need to. Just don't try to keep them past initial bringup, they're unmaintainable. At some point write them programmatically for long-term ownership.

2\. Only introduce P1 UI automation if you can justify extra cost over P0 after letting it ride for a release cycle--P0 should be near-zero cost if you're past alpha, or you did them wrong and need to revise those first before multiplying the design errors. If you do introduce UI P1s, tag or suite them differently. They're your extended UI acceptance suite. Don't block builds with it, you can't fix the tests fast enough. Run them nightly (and no record/replay here).

3\. Don't even bother with UI automating (or manual scripting) P2 and P3 stuff unless you do not have anything else to do and you want more test maintenance. For most it's a simple decision: you do, and you don't, respectively, so don't test those E2E.

4\. Don't script negative tests outside simple partitions like boundaries/numbers/character types/etc. Domain-specific negative tests usually only test one narrow scenario. Chances are overwhelming that even if you have a defect they miss it, and if it's not in docced flow they don't tend to get fixed fast. Those are naturally P2/P3 unless they're app-market-killers.

5\. Only script people for one-offs and short-term crutches, otherwise let them use their brains. Look up and implement guided exploratory and write up mission targets to cover the other areas manually rather than with scripts. Rotate those testers between different missions at least once per release, if not more often.

Edit: I will say that I have a soft spot for crowdsourced UI testing services if you _have_ to script, because of the novelty guaranteed by a gig system and that they present to your process basically as meat automation. But generally, no, you're not better off with manual scripted. You'd be better off to skip entirely so you can be properly nervous about your lack of effective testing and weigh the need accurately.

TL;DR: You should review your processes, you're hinting at the exact mistakes people make that has had QA relegated to an expensive cost center in most companies. Yours sounds a little broken and you may have normalized that.

<comment><USER16> Thanks for that extensive explanation. I'm not working there anymore.

First we had no test and everything was crap.

Then we did scripted tests and things got pretty good.

Then things got worse, because of the regressions, when one person did the tests for too long.

In the end we settled for students for a semester each, because they were really cheap and didn't want to do that job for long anyway.

<comment><USER5> It was interesting to put words down at any rate, so thanks for the opportunity.

Yeah, it really doesn't take manual scripted testers long to get jaded and cut corners.

</comment></comment></comment></comment></comment></comment><comment><USER17> Testing is so much more than helping write perfect functions. It's benchmarking, it's ensuring the right software is written, it's helping developers feel confident with their releases when working under tight deadlines, it's exploratory testing across entire systems when developers might only focus on a subsystem.

<comment><USER6> All of that can be done with automated tests, though agreed, they would not be (called) unit-tests (which are only used to prove how we've got our "perfect functions").

Of course, some of them could be unit-tests too (I've written small performance integration tests before, doing things like ensuring a function only ever emits a single SQL query, or timing execution and ensuring it scales in an O(1) manner, or ensuring data is passed by reference instead of being copied... where performance was a critical property of a "perfect function").

</comment></comment><comment><USER18> Testers are very useful for political purposes, So I would not scrap them even if they are kind off pointless after dev testing, unit testing, automated functional testing, reviews, automated coverage checks etc. Most testers aren't really automation specialists. Nor are they hackers (sorry, penetration testers). Most of them have pretty light technical backgrounds. They just check and sign off on a particular piece of functionality. Acting as a lightning rod for the boss' anger when stuff goes south down the line.

</comment><comment><USER19> > TDD developers rarely write end-to-end integration tests.

The only coherent definition I can find for a "TDD developer" is someone whose productivity is so closely tied to starting any development by writing an automated test that it might be wise make it part of their identity.

I'm projecting: Due mostly to inattentive-subtype ADHD, this describes me.

...but why I wouldn't I want to _start_ by writing integration test scripts? And why wouldn't I want to pair with a test engineer to do it?

</comment><comment><USER20> > The biggest benefit of TDD is that it removes the fear of breaking your > code.

This isn't true at all. TDD forces you to write unit testable code, which will have lower cyclomatic complexity, looser coupling, and generally be easier to maintain.

Writing tests second always leads to a suite that is more expensive to maintain than provided value.

And unit tests suck for catching bugs anyway, it's really about writing better code up front, which will have lower bugs and higher confidence by definition

</comment><comment><USER21> Can someone address the argument of:

Writing tests for everything (or almost everything) as proposed by TDD results in... more code to maintain.

This is the argument most teams have had that I've observed which resulted in little to no tests added.

I've seen above in both small teams (startups), and large orgs,

<comment><USER22> Yes, more automated tests (TDD or not) do imply more code. The question is whether building and maintaining that code is cheaper than the fallout from the bugs that get through to the customer. And the answer to that is, after the team or product grows past a certain size, that equation always tilts in favor of having the tests.

</comment></comment><comment><USER7> >Test-driven development was supposed to eliminate the need for independent testing.

Citation needed.

On the contrary, it frees up QA humans from writing "test for code bugs" and gives them more time to evaluate "but does it do what customers want?"

</comment><comment><USER23> What about a 3rd option of having many e2e automated testing (with puppeteer or such)?

<comment><USER5> You can find a lot of bugs with e2e but they're frequently not actionable because you can't figure out which part of your stack is causing them. Being non-actionable is one of the least-understood reasons to skip testing, and ironically the most important one for keeping focus. They also require very high maintenance, if they're going to be sensitive enough to be useful, as any stack change potentially means re-validating them.

Read up on test pyramid for more. E2E are the least useful during dev stage, more useful for exercising canary P0 use cases that can never be compromised by any stack bug or it's a stop-ship until you find it. They aren't diagnostic or robust enough for dev, but for a canary role their fragility is a plus.

<comment><USER9> >you can't figure out which part of your stack is causing them

If your debugging tools are halfway decent you certainly can.

<comment><USER5> On a multi-collaborator large system with half the behavior off in AWS?

You're either dreaming, or haven't worked on anything complex enough to see it yet. E2E means system test, whether or not you think it is, including back end. In almost any real software in 2020 that means multiple debuggers, monitors, logs, god knows what.

But if you're testing a monolith, sure. Your system is one unit, so unit test your monolith and enjoy your debugger.

If you're testing a monolith outside of something like embedded or basic app testing, quit, because the company you're working for built a monolith.

Inactionable doesn't mean "not possible", it means "more trouble than it's worth." That's why it's advisable to do E2E on P0 cases and not really advisable to do it for P3 cases. You can do tooling work to move the bar for how much trouble you have to put in, but "try harder" misses the point.

<comment><USER9> In such a system there's typically two kinds of E2E. E2E for the team's service and end to end for the entire system.

If you can't write the former without acceptable debugging tools your tests suck and you should rewrite them.

If you are a team writing a micro service in an ecosystem of micro services, you need to write E2E tests that mock systems external to yours and have very clear agreements/contracts about how they interact as _well_ as a QA team to test the system as a whole coz otherwise each bug that crosses a layer degenerates into an orgy of finger pointing. Ideally debugging at that scale should be rare and done with multiple members from multiple teams.

<comment><USER5> In almost every org I've been in, E2E meant full thickness UI to datastore and back tests. That's where I was coming from.

I've never considered the single service tests E2E, more either a component test suite or a public API unit test suite (same thing).

I agree you'd want those with collaborators mocked, and it's where I'd lean the bulk of my test strategy for a system like that from a QA POV (as well as promoting internal API unit testing from a dev POV).

</comment></comment></comment></comment></comment></comment><comment><USER24> TDD kills creativity.

<comment><USER6> Please elaborate!

I'd really love to learn how a method for creating a particular code structure leads to less creativity! I mean sure, it doesn't really allow you to be creative with eg. using global variables, but I am assuming you mean the end result (product and product ideas), so I am genuinely curious.

<comment><USER24> Software development is a very creative endeavor.

It's the interplay of data structures and algorithms that brings a program to life.

Often times, you know what needs to be solved, that you have to get from point A to B. But you don't really know how to get there. So you break down your problem even further. And A to B, gets split up into 5 more pieces. And each piece gets split up into another 5 pieces. So in the end, you may have 25 or so individual pieces.

Now, how do you TDD this?

There is no way that you can know what all those little pieces are, ahead of time. And if you do, then maybe your program is not really that difficult. Or maybe it was already a solved problem, that you can use an existing example to learn from.

However, you can do functional unit testing, to ensure that those individual pieces does exactly what it was expected to do.

TDD, or Test Driven Development, puts the cart before the horse. It requires you to build all this testing scaffolding for something that might not work. Granted, it may work, but it add a tremendous amount of overhead work to solving something.

You still need Functional Unit Testing of course. This is the magic that keeps software reliable, and humming along.

<comment><USER6> That's exactly how TDD does not work.

You work against requirements (A to B), and you solve the problem incrementally.

The main mantra of TDD is refactor constantly. That means that you are never writing tests for things you do not know you need, but that you are building up your solution from small parts that get turned into more complex parts (and get refactored) as you go.

And with just a little bit of practice, that refactoring effort becomes a second nature and means no overhead at all: you are just expressing your iterative, creative process through code.

</comment></comment></comment></comment><comment><USER25> Wait, what?!

Writing tests before you code was supposed to require less testing than writing the tests after you code?

Also a large red flag: are testers supposed to make your program secure? How would that even work?

I ought to give up on clicking on TDD articles at some point. People pushing it seem to come from some parallel universe completely different from here.

<comment><USER26> Security analysis is uses framed as finding bugs. There's a few main ways of doing this when searching for bugs in C/C++ code:

* Design consultations early in development to address insecure or risky designs.

* Reading risky parts of the code line by line hunting for buffer overflows and many other things. If you don't have access to the source, you can read the disassembly too, and people find a lot of bugs doing that!

* Fuzzing. Basically hooking up the program to a harness which throws random data at its attack surface until the program crashes, although it can get a lot more nuanced than that.

* Running static analysis tools to search for problematic code patterns.

The C/C++ code which powers all major operating systems and web browsers is rife with security issues. There are also whole other sub-disciplines auditing websites, corporate networks, and cryptography implementations, which generally use analogous techniques.

</comment></comment><comment><USER27> This person is giving way too much credit to QA. At least in enterprise software, which I was working on for 20 years, QA were mostly useless. In SAAS, having developers own their entire code including unit tests all through to deployment in my experience has yielded the best code quality that I've seen. Also, I don't consider security to be QA, that is a specialty in my opinion, similar to the article.

The normal development cycle in enterprise shrinkwrap software is that you would take a 12-18 month release cycle, and then plan out X features. QA would come back and say "We can only test 6 of those features", so the feature list gets cut. Then as you develop the features and finish them, you don't hear back from QA because their cycles are different from developers, except maybe a few weeks before the end of the release cycle, and then you get hit with a flurry of bugs, because that's when the QA is testing most of the code. Then more features get cut because of the high bug count, and then even more features get cut and you end up with 2 out of 10 features. This is how most development occurred all the way up until I left enterprise software about 10 years ago.

The best way is to cut QA entirely out and kill it as a career path. Give developers the entire burden of coding and testing, including end-to-end. I personally dislike TDD and would never join a company that developed using TDD but that's just my opinion. Obviously a SAAS vs shinkwrapped software is different, but overall, the best code quality I've seen is at my latest company where the developers owned everything. The buck stopped with you, and it behooves you to write good quality unit tests and integration tests. Cutting out QA forces developers to own their code and doesn't have a wall where developers would code, write some small tests, and then throw it over to the QA and not look at their feature for weeks or months.

<comment><USER28> That sounds like a particularly toxic relationship with QA. I've had quite a few positions where QA was very helpful.

In those cases, QA interfaced with users/customers and had a great level of knowledge of how people actually _use_ the product, and often had a more holistic view of how the entire suite of features works together, compared to developers who had more specialized knowledge of various specific bits.

Now, I would agree that _ideally_ developers should get lots of hands-on experience with how customers actually use the software.

And I would also agree that _ideally_ developers should have a holistic view of the entire suite of software features, rather than being silo'd.

I definitely aim for those things as much as possible, but it's not always practical. Both of the things I listed above add up to a fulltime job, or multiple fulltime jobs if the product is large enough. Usually engineers are in short supply and working mad hours already.

I would also like to point out that QA engineers are really vital when it comes to developing games. I do not work in the game industry, but I have a friend who is a QA engineer lead. Games are complex realtime systems and it can take a LOT of work for those folks to find and come up with reproducible cases for bugs.</comment></comment>


AeroSlider Concept (Tubeless Hyperloop) - <AUTHOR> https://manyone.com/case/exploration-aeroslider/ <comment><USER2> "Tubeless Hyperloop"

You mean a traditional maglev train?

"The incorporation of helium reservoirs within the capsule reduces the effective weight by about 10%, reducing the energy necessary for its propulsion."

This does not instill me with confidence in the engineering acumen of the designers.</comment>


Ask HN: Advice for self-publishing books - <AUTHOR> What are your recommended software, apps, monetization strategies, and resources on self-publishing books? <comment><USER2> I recommend putting your e-book on an established selling platform, like Leanpub. This is crucial especially when you don't have an established following.

Make a dedicated e-book selling website as well.

Regarding monetization, there are many tricks. Make different price brackets, include extras in pricier packages. For example, if your book is a programming tutorial, offer team licences. In your book content, try to up-sell your other products if you have them. Create many micro launches every time you update your book. Collect e-mails by providing a free book sample. You can read more on this matter in a blogpost I have written: [http://codeandtechno.com/posts/tips-for-writing-an-indie- ebo...](http://codeandtechno.com/posts/tips-for-writing-an-indie-ebook/)

</comment><comment><USER3> Leanpub is a great platform for self-publishing: [https://leanpub.com](https://leanpub.com) It has multiple input (.doc, GitHub, ...) and output sources (PDF, EPUB, MOBI). In the end, you can publish the book on their platform or simply use the files for your own platform or Amazon.

</comment><comment><USER4> Friend of mine used Lulu for self-publishing his Lisp book. Nathan Barry has a good ebook on writing your own ebook called Authority.

</comment><comment><USER5> I write for a small publisher and they use gumroad and mailinglists filled with contacts they gathered via squeeze pages.</comment>


A Lot of Websites Are Going to Start Loading Way Faster - <AUTHOR> http://www.slate.com/blogs/future_tense/2015/12/04/cloudflare_is_defaulting_all_of_its_users_to_http_2_today.html <comment><USER2> While http/2 is faster than https/1.1, it's still slower than http/1.1 due to the overhead of encryption.

<comment><USER3> Mmh I thought http2 was unencrypted by default like http, are you sure?

<comment><USER2> Yes, I'm sure:

[https://en.wikipedia.org/wiki/HTTP/2#Encryption_2](https://en.wikipedia.org/wiki/HTTP/2#Encryption_2)

"Working Group finally did not reach consensus over the mandatory encryption,[22] although most client implementations require it, which makes encryption a de facto requirement."

You can also test for yourself: when you access any http/2 website using http (assuming it doesn't redirect you to https), you'll see it's using the http/1.1 protocol.</comment></comment></comment>


$500,000 game dev comp by Epic Games and Wellcome: Developing Beyond - <AUTHOR> http://developingbeyond.com/ <comment><AUTHOR> Gamasutra - Epic Games launches $500,000 year-long game dev contest [http://www.gamasutra.com/view/news/290011/Epic_Games_launche...](http://www.gamasutra.com/view/news/290011/Epic_Games_launches_500000_yearlong_game_dev_contest.php)</comment>


Symantec tells customers to disable pcAnywhere after source code theft - <AUTHOR> http://www.reuters.com/article/2012/01/25/us-symantec-hacking-idUSTRE80O1UY20120125?feedType=RSS&feedName=technologyNews&utm_source=dlvr.it&utm_medium=twitter&dlvrit=56505 <comment><USER2> Working mainly in open-source as I do, it's easy to forget that this kind of thing can happen.</comment>


Rosetta Code - <AUTHOR> https://rosettacode.org/wiki/Rosetta_Code <comment><USER2> Because of the "idioms" page which lifted the code samples from rosetta? ;)

<comment><AUTHOR> You got it. It's been around for much longer, I like it, and it's better quality as well as more extensive.</comment></comment>


SIGGRAPH 2018 Papers: Machine Learning, Graphics, and Rendering - <AUTHOR> https://medium.com/@jcowles/siggraph-2018-papers-ee2bb1be9050 <comment><USER2> No mention of Real Time Live [1]? That was the most exciting session in SIGGRAPH this year! The combination of insane real time rendering and real time capture is going to make for some amazing graphics experiences in the near future.

[1] [https://www.youtube.com/watch?v=rPam5CHFQMQ](https://www.youtube.com/watch?v=rPam5CHFQMQ)

</comment><comment><USER3> Here is the full list of papers with links to preprints for the papers presented at SIGGRAPH 2018:

[http://kesen.realtimerendering.com/sig2018.html](http://kesen.realtimerendering.com/sig2018.html)

</comment><comment><USER4> Here [1] is an overall video overview over some selected papers in this years SIGGRAPH

[1] [https://www.youtube.com/watch?v=t952yS8tcg8](https://www.youtube.com/watch?v=t952yS8tcg8)

<comment><USER5> And here's [1] Stephen Hill's list of links for 2018:

[1] [http://blog.selfshadow.com/2018/08/16/siggraph-2018-links/](http://blog.selfshadow.com/2018/08/16/siggraph-2018-links/)

</comment></comment><comment><USER6> FTA : Deep Convolutional Priors for Indoor Scene Synthesis.

Anybody think of a huge improvement to NetHack, DwarFortress and other generated worlds ?

</comment><comment><USER7> One of the siggraph papers is titled 'FontCode: Embedding Information in Text Documents using Glyph Perturbation'. This is a type of steganography where the shape of the font is perturbed in a way to encode information. Basically, you make a key value store (a code book in their jargon) of input letters mapped to subtle variations of the same letter of a specific font. My confusion arises from how you get Microsoft word to use these variations. Since the font file on your pc contains only one glyph for each letter, how do you get a text editor to use bastardized glyphs that are not in the OS?

<comment><USER8> The authors are assuming that they are allowed to use custom fonts. So if they need eight different variants of any particular glyph, they can just create eight different custom fonts where each glyph has the desired appearance.

And yes, if you received a Word document with custom fonts, you might be suspicious of hidden information, but the authors are further assuming that the document is only distributed in a format where the use of custom fonts is not readily apparent. This is why they talk about extracting the information from "an encoded document stored as a vector graphic or pixel image, or even on a printed paper".

</comment></comment><comment><USER9> Wow. The GAN texture synth is so accurate. And only requires ~2 hours training time on Nvidia Titan GPU (~$1600) ;)

PyTorch code here:

[http://vcc.szu.edu.cn/research/2018/TexSyn](http://vcc.szu.edu.cn/research/2018/TexSyn)

</comment><comment><USER10> AR/VR is getting pretty hot these days. What happened to those old recommendations of sitting 8 ft from a television? Now we put the VR screens 1 inch from our eyes lol.

<comment><USER11> Modern displays don't use cathode ray tubes, and in VR the optics between the display and the eyes focuses the latter as if the display was a lot more distant that it really is, so these recommendations are less relevant here.

<comment><USER12> OLEDs are a step above even LCDs in emulating natural light and preventing the glare that makes staring at cathode ray tube monitors less than a good idea.</comment></comment></comment>


Clay Shirky - Where do people find the time (on the cognitive surplus, video) - <AUTHOR> http://www.youtube.com/watch?v=AyoNHIl-QLQ

<comment><AUTHOR> 'Here's what four year olds know. A screen that ships without a mouse ships broken.'</comment>


Apple's jaw-dropping 'spaceship' campus is open – take a look from above - <AUTHOR> http://www.businessinsider.com/apple-park-drone-flyover-video-2017-11/#heres-apple-park-and-the-distinctive-circular-spaceship-building-situated-in-cupertino-california-1 <comment><USER2> The one no one wants to work at because it's all open seating?</comment>


What Is Your Product Vision Statement? - <AUTHOR> https://startinfinity.com/product-management-framework/product-strategy/defining-product-vision <comment><AUTHOR> 'How is this Product going to help people?'

\- Is this the question that all successful large companies ask themselves, constantly reminding them of their Product Vision Statement? Here are only some:

Instagram: To capture and share the world's moments.

Google: To provide access to the world's information with one click.

Would like to start a thread where you'll share yours.</comment>


Titan City: Created Using Minecraft [video] - <AUTHOR> https://www.youtube.com/watch?v=vPaVQ4BcgVI

<comment><USER2> thisa is really neat. i have been currently working on a titan tunnel, hollowing out an entire world, starting last october with my kid. it really started out with attempting to drain an oceanfront, from there it spiraled into a really big pit with completely unnecessary load bearing walls (i computed nearly 600,000 removed blocks just for the pit), then a tunnel. Battling lava is the real big challenge, as well as glitch spots that cause me to run up against invisible blocks that cant be dug or bypassed.</comment>


HIV virus used to turn white blood cells into cancer serial killers - <AUTHOR> http://www.geek.com/articles/geek-pick/hiv-virus-used-to-turn-white-blood-cells-into-cancer-serial-killers-20110811/

<comment><USER2> To clarify, the modified HIV virus in this case was used as a vector to deliver an antibody specific to the cancer onto a T-cell. The T-cell then goes on to destroy the cancer. HIV is one of the most efficient vectors for genes.

<http://en.wikipedia.org/wiki/Viral_vector>

<http://en.wikipedia.org/wiki/Lentivirus>

<http://en.wikipedia.org/wiki/Chimeric_antigen_receptor>

<http://www.nejm.org/doi/full/10.1056/NEJMoa1103849>

EDIT: Also note that the HIV vector is used to modify the T-cell _before_ it is inserted into the human. The HIV is never actually inserted into the human (in this case).

<comment><USER3> Such viral vectors are routinely used in the lab to knock in a variety of genes in the cell. Vector is really the packaging. What was important in the study was the actual antigen which has packaged in the vector.

<comment><USER2> Without a doubt. I was only commenting on the HIV vector because there are so many that say, "What the hell?" when they hear "HIV."

<comment><USER4> I know I did, until I read further into the article.

</comment></comment></comment></comment><comment><USER5> This is incredibly good news. So many researchers have been looking for a way to alter the inmmune system to target cancer, and it's surprising (but also makes sense) that the solution seems to be around HIV. It's this kind of out of the box thinking that pushes forward.

And this: "this small trial involving just three patients was lucky to go ahead at all. The study was rejected by pharamceutical companies and the National Cancer Institute.".

There's a very good talk on TEDMed from David Agus, about proteomics and cancer research. He bubbles up a similar concern about limitations of clinical trials.

[http://www.ted.com/talks/david_agus_a_new_strategy_in_the_wa...](http://www.ted.com/talks/david_agus_a_new_strategy_in_the_war_on_cancer.html)

<comment><USER6> His graph with heart disease, etc. is misleading; if we have made all those reductions in those areas and cancer deaths have remained the same, we have obviously made progress in cancer as well: since less people are dying of the other stuff, they have a greater chance of eventually contracting cancer.

<comment><USER5> I agree you could argue that. But rather than crunching numbers, I think his point was to illustrate the state of some cancer treatments today. How despite of everything and all advances in medicine,we still need to make HUGE improvements in cancer.

For example, pancreatic cancer. Prognosis is 20% 1 year survival and five-year rate is 4%. The best approved treatment so far is Gemzar, which was introduced in the early 80's. It's improve rate over other chemos was that it works in 23% of the patients, and improves the median survival to 5.65 months compared to 4.41 months with 5-flu chemo.

Over 20 years and some of the best we got is +1.2 months and for only 23% of the patients. That's what he's pushing for and I support,improving this rates.

In the end It's not about crunching numbers and making one disease or other look better tackled. It's about having hope for all this people and know something can be done, instead of staring at such a grim prognosis.

</comment></comment></comment><comment><USER7> It's awesome to see one shitty thing in life being used to get rid of another shitty thing in life.

<comment><USER8> gold.

</comment></comment><comment><USER9> More comments here <http://news.ycombinator.com/item?id=2873604>

</comment><comment><USER10> This is very exciting. Anyone have any thoughts on the extensibility of this to treating other cancers?

<comment><USER11> The main issue is that for this to work, you need to know specifically what antigen you're targeting on the tumor cells. Think of the antigen as a unique tag that the immune system can use to differentiate cells (a "natural key" if you will). In the majority of cancers we haven't got a clue as to what we should use as for an antigen (though it's not an insurmountable probelem). However, with leukemia they can use CD-19 which is found exclusively on the surface of normal and cancerous B-cells. The last thing you want is an antigen that "looks" like something common, so CD-19 apparently fits the bill there as well. If you choose something non-specific, then the immune system can go after all kinds of other tissue that you don't want it to which could very likely kill the patient.

All that being said, targeted therapy like this is probably the future of cancer treatment, but it's going to take tremendous effort to work out all the kinks. The immune system is ferociously complex, and is still poorly understood. However, it does have the advantage of being battle tested throughout evolution.

<comment><USER10> Thanks for the reply. Just while you're here, I was wondering if I could ask another question. Am I right in thinking that they used the HIV virus to 'program' the white blood cells? And if so, in the future might it be possible to reprogram the cancer cells themselves? Perhaps the virus could 'patch' the broken/missing DNA?

As you can tell, I'm horrifically ignorant on the topic but I would be grateful if you could indulge me :)

<comment><USER12> While it may be possible in theory to patch/fix the cancer cells, you'd need a virus that can target them specifically. In the case of using HIV here, it's because it's so efficient at getting into the immune system that it can be used as a vector to reprogram it. I've got to imagine that other "super viruses" could be used in a similar manner if they also target things so well.

</comment></comment></comment></comment><comment><USER13> > has been experimenting with using a harmless version of the HIV virus

I wasn't aware such a thing exists. Anyone care to elaborate? Is it harmless or probably harmless?

<comment><USER14> It's very harmless. Obviously there's a good number more technical details in here, but the gist of it is we take the parts of the HIV virus that makes it so good at proliferating, take out the genetic material that makes it harmful to our cells, and put in our own genetic information for the HIV-derived virus to inject into our target cells (known as a viral vector).

Contrary to the mental connotation, it's a very harmless procedure that's often used even in BSL-2 labs. It's not to say that there aren't risks involved, but chances are you're not going to end up with AIDs.

HIV-derived lentiviruses have been in use for a long time now and are a proven research tool. Coincidentally I just grew and harvested a new batch of lentiviruses this past Tuesday to treat cancer cells with shRNA.

</comment></comment><comment><USER15> The results of this sound amazing, but the article is frustratingly vague about what role the HIV virus plays. The interviews in the video don't mention it at all. I think most people will assume the patient is being infected with some variation of the virus, which seems rather scary, but it doesn't sound like that's the case.

Since the emphasis is on genetically modifying white blood cells and injecting them back into the patient, which doesn't seem to need a virus as a delivery mechanism, I'm guessing the HIV's role is somewhere in the genetic modification?

<comment><USER12> From what I've seen in other places what was done is, they took some of the patients T-Cells, and altered them. They did this by taking the RNA out of some HIVs and replaced it instead with a sequence to look for a specific antigen on the cancer cells. Then they took the HIVs and introduced them to the T-Cells and let them get infected. Since the original nasty RNA wasn't present, it won't replicate, but it will make some T-Cells that target the antigen on the cancer cells. After reintroducing to the patient, their immune systems then pick up from other signals that we don't full understand that some T-Cells are attacking this antigen, so it should make more of them.

</comment></comment><comment><USER16> Also discussed at great length over here:

<http://news.ycombinator.com/item?id=2873604>

This is a good example of the same story, not cross-connected, getting split discussions.

</comment><comment><USER17> I'm the first to notice (or care)... "HIV virus"? Department of Redundancy Department?

<comment><USER18> Like GPS System? The acronym takes on a life of it's own as a 'word'.

<comment><USER19> Is GPS System common? That looks and sounds weird to me.

<comment><USER18> Sure, I've heard it said more than seen it written. Especially on news stories: "the car was tracked using the GPS system", etc.

</comment></comment></comment></comment><comment><USER20> I love the idea of disarming one virus and brainwashing it to kill another. I wonder how long it is before cancer is eradicated.

<comment><USER21> Forever: cancers are not eradicable unless evolution and mutation and gene expression from adverse environments and ... are all eradicable.

That's a different thing than assessing if a certain instance of cancer is itself curable in a certain afflicted host. Perhaps it is worth hoping for that.

</comment></comment><comment><USER22> "Good news, we found a way to treat your cancer."

"Great! What is it?"

"We're going to give you AIDS."

"..."

<comment><USER23> You didn't read the article, did you?</comment></comment>


Ask HN: Simplest JavaScript Testing Setup? - <AUTHOR> In 2019, what's the simplest setup for single-command local testing of a brand new Javascript library?<p>The goal is to minimize the NPM and Webpack (et al) yaks that need to be shaved in order to focus on the code first, while including test coverage from the outset. <comment><USER2> Since you asked for simplest…

In a.js:

        module.exports = (arg) => {
            return arg * 3;
        };

In a.test.js:

        // require module to test
        const testedFunction = require('./a.js');

        // testing
        console.log("Default export", "should multiply argument by two:", true &&
            testedFunction(3) === 3 * 2
        );

In package.json:

        "scripts": {
          "test": "for file in *test*; do node ${file}; done"
        }

In your shell:

        $ npm run test

A few things to note:

* Node.js has console.assert() but it is really noisy.

* console.group() could be used to… group assertions and indent output.

* This works for ES6 modules, too, with --experimental-modules and .mjs extensions.

If you want something serious but still lightweight, there's always [https://github.com/MithrilJS/mithril.js/tree/next/ospec](https://github.com/MithrilJS/mithril.js/tree/next/ospec).

</comment><comment><USER3> test/a-test.js

      const assert = require('assert')

      exports.example = () =>
        assert.fail('implement me')

test/index.js

      // Creates a giant array of test functions from multiple
      // "suites"/vanilla node modules and executes them.
      const test = suites =>
        suites
          .map(Object.values)
          .reduce((all, tests) => all.concat(tests), [])
          .forEach(test => test())

      test([
        require('./a-test')
      ])

package.json

      ...
      "scripts": {
        "test": "node test/"
      }
      ...</comment>


Effeckt.css – Performant CSS transitions and animations - <AUTHOR> http://h5bp.github.io/Effeckt.css/ <comment><USER2> This project hasn't been updated for almost a year, is not fast, and the issues suggest that it's dead. Why post it?

<comment><USER3> I agree.

What's the recently updated, fast, actively developed alternative in this space?

</comment></comment><comment><USER4> This library has been "not ready for prime time" for at least 2 years now... :-/

</comment><comment><USER5> These are all really nice looking, but the android radio buttons seem very user-unfriendly. I'm usually pretty good at sorting out indecipherable buttons and whatnot but they've got me stumped.

</comment><comment><USER6> I guess some of these would be fancy on mobile, but the latency between action and the ultimate feedback is remarkably high. (as with any animation)

This would not work well in a product that end users use day in and out, often with keyboard savvy shortcuts to save time.

</comment><comment><USER7> Macbook 2014, Chrome and it's super slow.

<comment><USER8> They aren't slow on my macbook/chrome (which is a bit older than that). Are you speaking of the actual timing of the animation, or the framerate? If it is the timing, that can be adjusted. For instance, in the css you'll find things like:

transition: -webkit-transform 500ms;

transition: transform 500ms;

Just change that 500ms to 200ms and it will take less time. The effects will be more subtle (so maybe not as good for "showing off" as in the demo), but probably a better experience.

</comment></comment><comment><USER9> Most of them are not really smooth (Chrome 49 on Macbook)

</comment><comment><USER10> It appears the project is all but dead: [https://github.com/h5bp/Effeckt.css/graphs/code- frequency](https://github.com/h5bp/Effeckt.css/graphs/code-frequency)

</comment><comment><USER11> I didn't get performant from this demo, but I did come across another lib that I starred on github [https://github.com/daneden/animate.css](https://github.com/daneden/animate.css) it may do some of the same things and seems to be pretty active

</comment><comment><USER12> Looks nice, but most of these show significant frame drops on my phone (Galaxy S6).

</comment><comment><USER13> "Performant" :P

<comment><USER14> Not exactly sure what you mean, but the funny thing is that there seems to be no single-word translation from the German "performant" ("with high performance") to English. Or is it?

<comment><USER15> He means animations on that page are slow as hell.

</comment></comment></comment><comment><USER16> This is really slick. I am amazed at what people are doing with CSS these days.

HTML 5 + JS + CSS is slowly becoming the best way to build UIs native or otherwise.</comment>


Microsoft Launches Drag-And-Drop App Builder Popfly - <AUTHOR> http://www.techcrunch.com/2007/10/18/microsoft-launches-drag-and-drop-app-builder-popfly/

<comment><USER2> I don't know. I signed in and was...unexcited.</comment>


Kalamazoo: the largest gathering of medievalists on earth - <AUTHOR> http://thepointmag.com/2016/examined-life/kalamazoo <comment><USER2> My wife is a medievalist and has been an attendee and session organizer at Kalamazoo multiple times. She has always enjoyed the variety at the conference, with academic topics during the day, and more "fun" topics in the evenings (constructing a medieval sextant, discussions on the language of Elvish etc).

</comment><comment><USER3> I spoke at Kalamazoo 10 years ago. Medievalists are a quirky bunch, and having them all together in one place makes for a fabulously quirky conference. There are plenty of folks there for whom Kalamazoo is the highlight of the year.

</comment><comment><USER4> While I've never been, I was close friends with a professor of English who used to go to Kalamazoo every year. I love history myself so I enjoyed hearing about his work when I would visit him.</comment>


Deployment That Just Works - <AUTHOR> http://blog.heroku.com/archives/2009/3/3/deployment_that_just_works/

<comment><USER2> I'm curious to find out what the pricing model will look like with heroku. For me, it needs to beat (or be comparable to) EC2 on price, not just ease of deployment. Setting up EC2/mod_rails/cap myself offers more flexibility and is close enough to instant deployment that cost becomes the determining factor.

<comment><USER3> I highly doubt that it will beat EC2 on price. The fact is that there's still a lot of value that can be added on top of what EC2 offers.

For example, Heroku I'm sure will offer monitoring, backups, high-availability setup for webheads and databases, etc. That has added value to it and with EC2 you'd have to have several boxes to achieve that.

Plus, one thing that is oft-overlooked is burstability. With Heroku, you might have a pool that averages out to the capacity of 1 EC2 instance, but bursts higher. That's important. That means that you don't have to plan for peak capacity as much since their system will auto-adapt to handle it.

You could make a similar setup, but it wouldn't be cheap as you'd need multiple EC2 instances to handle what Heroku is giving you in terms of high- availability. Heroku isn't for everyone and it'll probably be a premium, but when you're a business that wants to stay up (vs. something where it doesn't matter if your reliability is a little lower) it's probably going to be a nice service.

It costs a lot of money to move from 99.5% to 99.9% or 99.99%. At 99.5%, you can just run one box and fire up a new instance when you realize that it went down. To get to 4 nines, you need monitoring, hot failovers, etc.</comment></comment>


Möbius loop music box - <AUTHOR> http://vihart.com/musicbox/

<comment><USER2> Okay, the engineer in me wants to add a timing track and run this with motors, I get an RSI just watching them crank those things.

</comment><comment><USER3> Submitted seven months ago - <http://news.ycombinator.com/item?id=1290367> \- and sank without trace. Will it fare better this time?

<comment><AUTHOR> I hope so, I really enjoyed the idea. Many interesting things get lost on hacker news ...

</comment></comment><comment><USER4> This is pretty neat. There's also a nice video of Bach's Canon #1 from the Musical Offering on a Möbius Strip: (around 1:45)

<http://www.youtube.com/watch?v=xUHQ2ybTejU>

</comment><comment><USER5> That is really great. As a musician, and a programmer, I would like to how you would make that. Seems like you would go through a ton of Mobius strips getting the arrangement just right.</comment>


2 ways to deal with big features - <AUTHOR> http://blog.arkency.com/2014/02/from-feature-vision-to-stories/

<comment><USER2> _" We don't want to assign one programmer for 3 weeks to work on a separate branch in a complete isolation from the rest of the team."_

Do people really consider something that can be completed in three weeks of effort by a single person to be a "big feature"?</comment>


The body is the missing link for truly intelligent machines - <AUTHOR> https://sinapticas.com/2019/08/21/the-body-is-the-missing-link-for-truly-intelligent-machines/ <comment><USER2> I feel that virtual or real embodiment is probably a good way to acquire sensory grounding of language and common sense. But I don't believe it's the only way to acquire it or necessary for the distribution or use of all of this knowledge.

What is necessary is a way to encode spatial-temporal information at different levels of abstraction. Maybe the best way we have to do that is neural networks. Or maybe something like networks of networks.

But it's a bit of a leap from the idea that training on text only is inadequate (which seems obviously true to me) to the conclusion that embodiment is necessary.

The next step might be to train on captioned video.</comment>


Things a UX/UI Designer Should Know - <AUTHOR> https://learnui.design/blog/100-things-ux-ui-designer-know.html <comment><USER2> 101\. Use appropriate HTML elements, like <details>. [https://developer.mozilla.org/en- US/docs/Web/HTML/Element/de...](https://developer.mozilla.org/en- US/docs/Web/HTML/Element/details)</comment>


Alleged Assassins Caught on Dubai Surveillance Tape - <AUTHOR> http://www.wired.com/threatlevel/2010/02/alleged-assassins-caught-on-tape/ <comment><USER2> The amount of effort that would need to go into creating that video and the facts that the article asserts is just impressive:

-figuring out the group of people

-how everyone entered the country

-all of their phone communication while they were in the country, including finding out their numbers

-how they spent money inside the country

-their motions inside the country

-where they went after they left the country

<comment><USER3> They probably got it from the secret service? Those likely have most of this information in a database and can get it with the the press of a button.

<comment><USER4> That would be a pretty impressive database.

</comment></comment></comment><comment><USER5> Of the two methods currently being used to deal with the militant Islamic fanatics, the 'War On Terror' has only really achieved in causing mass terror amongst our own people and imprison hundreds of innocent people because our government's criteria for 'wrong place and wrong time' were basically Afghanistan and post-invasion.

However the allegedly Israeli approach causes virtually no terror to our own people (in fact it appears to instill the exact opposite of terror), it has no collateral damage and only a minor amount of innocents get caught in the cross hairs.

What I'm wondering is if the 'Israeli' approach to militant Islamiscs the better approach? IE is it getting the job done at a better tax-payer cost and a better ethical cost (less young soldiers dead, less innocents wrongly imprisoned and less collateral damage vs. a wrong target).

<comment><USER6> The thing is who decides who gets killed and who not. You could argue that Bush caused the massacre of thousands of Iraqis, or something similar for past Israeli leaders. Does that mean that we can assassinate them? W/out even a fair trial? Once you go through that path, things get scaringly fuzzy.

It reminds me of the idea -popular in Latin America- that there are bad dictators and good dictators (pro markets, etc.). I've seen people that supposedly like freedom and democracy take a very pragmatic approach, being happy under the rule of Pinochet/Fujimori/etc.

<comment><USER7> Good/bad dictators is a well known debate. "King" is an old term for "[military] dictator".

One bad problem is that most every king/dictator made certain to put his own relatives in positions of power. That means that the leadership competence in future generations will be very varied.

From history studies, somewhere between 25%-75% of my country's royalty were total asshats. When you have a fixed incompetent leadership that is very hard to change, then employees/citizens/etc will _suffer_.

There are more problems, like that you just can't tell an absolute ruler, which has been brought up for the job, all the things he needs to hear. [Edit: A dictator can be said to have an alternative version of "Kill your darlings", when someone complains about his worst ideas...]

Edit: To sum, I'm with Churchill on this: "... democracy is the worst form of government except all those other forms that have been tried from time to time."

Edit: Some points of grammar.

<comment><USER8> Interesting HN comment about that Churchill quote:

<http://news.ycombinator.com/item?id=571797>

<comment><USER7> I've read about that discussion but lacked the energy. :-)

(Anyway, your link might have a point in that the inherited dictators might on average be less actively evil than those that crawl to the top of the heap. That seems like arguing that some cancer form has a little bit less mortality than lung cancer. It might be true, but the practical/emotional impact is low.)

</comment></comment></comment></comment></comment><comment><USER9> The Mossad Kidon (it's assassination branch) is rumoured to only have about 50 or so operatives. Which means they potentially compromised almost 20% of their resources to take out this one target.

<comment><USER10> This was almost certainly not Mossad, for precisely that reason. Mossad is not known for sloppy work, and this was nothing if not sloppy. The passports were bad fakes; several of them were duplicates of real innocent Israeli lookalikes; 11 people to kill one guy with no security detail, all of them with their faces on camera? Yeah, pretty sure this wasn't Mossad.

</comment></comment><comment><USER8> They went to a lot of trouble to make the death look like a heart attack, even somehow having the door locked from the inside as they left.

But it seems like it was immediately obvious to the police that this was a murder, so what was the point of going to all that trouble?

<comment><USER11> I'd say just to save time and face. If he was found with a bullet through his head or something like that it is not unreasonable that all airports and roads would be closed for a while, but if it looked just like a heart attack the murderers have a bit of extra time to leave the country.

</comment></comment><comment><USER12> I love that there was a guy whose whole job was to show up at the hotel, pay for the room across the hall from the target, hand off the key, and then immediately leave the country.

</comment><comment><USER13> Flagged. What's this Mossad PR stunt doing on HN?

<comment><USER14> I'm hoping for someone to discuss the implications as they relate to technology, PR, security, and privacy.

What technology is necessary to gather that much video so quickly? Is that video feeding into a central hub? This is Dubai, a relatively tiny country. Did they build this technology themselves or did they license it.

PR. What's to gain from releasing this? It's fascinating but long. It's definitely not put together as a soundbite, in fact it has no sound.

What are the security implications of releasing this information? Will it make future assassins think twice?

What about the privacy implications? If you were incorrectly identified as a lookout what would you do to clear your name? The story includes some Israelis who share names with the assassination team who are freaked out right now.

<comment><USER15> _What technology is necessary to gather that much video so quickly? Is that video feeding into a central hub? This is Dubai, a relatively tiny country. Did they build this technology themselves or did they license it._

The technology is CCTV <http://en.wikipedia.org/wiki/Closed- circuit_television>. It is imported from all over the place and is probably not feeding into a central hub. In most countries UAE included it is found in all hotels, airports and Shopping Centers. The assassins for sure knew about it but because of their modus operandi did not worry about it. If you notice the end of the video says the hotel staff opened the room 17 hours later and that the latch was locked from the _inside_. They made the murder appear as a heart attack (other reports at the time) reported it as electrocution - probably killed him by inducing a heart attack via electrocution.

The team scattered to different places and all the names and nationalities mentioned are probably false. They also probably had multiple passports and on leaving Dubai appeared in another country with a different name.

<comment><USER16> Accounts from previous Mossad agents have explained one technique they have employed for this kind of murder: They give the victim hardly traceable anesthetic and fever inducing drugs, then, when his body temperature is exceedingly high, he is submerged in icey water (f.ex. in a bathtub). Apparently this causes heart attack in the victim and is very difficult to distinguish from a natural cardiac arrest.

</comment></comment></comment></comment><comment><USER17> This reminds me about the movie "Munich".</comment>


From Harvard to Goldman to the Valley, Networker Extraordinaire - <AUTHOR> https://www.wsj.com/articles/from-harvard-to-goldman-to-the-valley-vc-scott-stanford-is-networker-extraordinaire-1499445965 <comment><USER2> Article without WSJ paywall > [http://www.cetusnews.com/business/From-Harvard- to-Goldman-to...](http://www.cetusnews.com/business/From-Harvard-to-Goldman- to-the-Valley--VC-Scott-Stanford-Is-Networker-Extraordinaire.HJmRAR46E-.html)</comment>


Data Trends to Watch in 2020 - <AUTHOR> https://medium.com/memory-leak/4-data-trends-to-watch-in-2020-491707902c09 <comment><USER2> Let us know if you have any questions or feedback.</comment>


Ask HN: Do I have too low of an IQ to be a successful engineer? - <AUTHOR> I'm currently a software engineer at a big tech company. One thing that has always bothered me is that I always do poorly on standardized tests, such as the SAT (~2200, but with a 700 Math, lower than anyone I know). I didn't go to a top school and usually do poorly in coding interviews if I haven't seen the problem before (failed Google, Facebook, Microsoft).<p>I feel like I'm at an impasse in my career - what is the minimum intelligence required to be successful as a software engineer? Or is it more useful for a lower intelligence individual like me to pick a different career path? <comment><USER2> I guess there's some context here that isn't in your description?

While test scores might be indicative of your aptitudes at different types of problems, unless you're actually struggling with your work, it mightn't be a problem.

There's _plenty_ of successful software engineers who've interviewed/tested unsuccessfully at Google/Facebook/Microsoft/etc, and gone on to have rewarding and fulfilling careers. Some people are just bad at interviews. And some interviews are just looking for a particular type of person, and not everyone who's a good engineer is going to fit that profile.

Do you enjoy your work? Is it stimulating and challenging and sometimes even fun?

Do you feel like you understand the tradeoffs in making the choices you make while coding? And if not, it that because you find them just baffling? Or because you understand it, but don't have the experience or knowledge to really make a clear decision yet?

The VAST majority of coding has basically nothing to do with maths. You need to be able to think logically, break things down from high level goals to low level steps, and be tenacious in working through design issues and coding bugs.

And, having said of all that, not everyone has to be a genius coder either. The other 99% of software engineers do a decent job, nothing too stellar (but hopefully nothing too crap either). It's ok to not be the best in the world.

</comment><comment><USER3> 700 is NOT a disappointing math SAT score, even for a software engineer, and there are plenty of people with those scores who attended Ivy League schools.

My advice would be to stop worrying about scores (IQ, SAT, whatever) — you're not in high school any more. And stop comparing yourself to other people.

Are you meeting expectations at work? Getting solid reviews from your manager? That's what matters.

So you don't test well? So you didn't get into the big name companies that have famously grueling interview processes and reject the vast, vast majority of candidates? So what?

There are plenty of other companies out there that need your skills. Badly.

Yes, a bunch of them cargo cult the same ridiculous interview processes as the FAANGs. But not all of them do.

Find the ones that don't. Find the ones that instead send you a small take- home that mirrors the type of work you'll be doing daily. Show them that even if you may not be good at solving algorithmic puzzles under pressure, you're good at writing software.

That's what matters.

<comment><AUTHOR> I think I get OK reviews (it's pretty opaque at my company).

My lower IQ makes me concerned about weathering a downturn or making more money though. The only better offer I got was at a Hedge fund and that was a severe lowball (likely due to interview performance).

</comment></comment><comment><USER4> I would not worry about test scores. Test scores have routinely been show to not correlate with actual job performance.

For coding interviews, to do well, work through all of the hackerrank.com or the equivalent problem sets in your preferred language. At some point you will see the "algorithmic" or "data structure" patterns in the problem sets and you will be able to go forth. I am not sure these even predict job performance though but they are the price you have to pay to "get in".

Also I think the average engineer at a FAANGM company takes 2-3 interviews to actually get in as well. So look at it as a challenge and learning opportunity rather.

<comment><AUTHOR> I've done like ~250 leetcode problems since undergrad (including redos) and I still fare poorly to get into FB/G. I've probably done 3-4 at the FANGs by now outside of my current one but failed all of them, so I'm definitely below the average.

<comment><USER4> Ok well if you've done the work then maybe google isn't for you. But there is for sure another technology company out there who needs your skills and would love to have you as an employee. Also do you even want to work for google if they place such a high value on leetcode interviews? What are you looking for in a job that Google is the answer?

<comment><AUTHOR> I want society to see me as valued, as measured in compensation and treatment. Currently people think of me as lesser for where I work.

I get the same number of massage credits (0) at my current job as does an electrician.

<comment><USER4> How do you know people think lesser of you? Have you asked people that? Is it really true? Why is what other people think important to you?

<comment><AUTHOR> People are never impressed when they find out where I work but always are impressed at the perks and prestige of other companies. It feels like a "normal" job, not an elite one.

And yes I have asked others...it's important because I agree with their thought process on this.

<comment><USER4> Do these other people actually think less of you as a person because of where you work? I get the disconnect between compensation and skill. I think it happens all the time regardless of the companies involved and that your pay is not a function of your actual skill or value but a function of leverage. There is a lot of virtue signaling in leetcode style interviews but the research shows that these types of interviews do not predict job success or even happiness. There is tons of academic research on this. You even see it in the NBA, the NFL, and the MLB.

However these signals are highly leveraged because they map to a compensation measure. Also people with the best offers tend to have the most leverage, meaning they've got multiple offers from equivalents. In fact this was a big problem earlier that the FAANG companies minus Netflix all conspired to suppress wages. Netflix did not because they were small at the time and were definitely not considered elite. Netflix then used mega pay packages to recruit and the rest is history...

So if the probability of getting a job at Google and Facebook is each 0.2%. Then the probability of having multiple offers is 0.0004% .. You mentioned you had a hedge fund offer. That is also pretty good in my opinion. I think all you are missing is leverage and this has nothing to do with IQ. I think your IQ is probably good enough. I also think that IQ is a floor to entry and not a measure of specific success.

So I don't think less of you. You say in another post that you already work at a FAANG! That is quite the achievement.

<comment><AUTHOR> Yes, I think people do. I don't get European vacations or work trips in first. I don't get Hawaiian off sites or bonuses or a free phone or a massage. If I'm lucky I get two free drinks at the Christmas party.

Googlers know this and look down on me for being dumber accordingly.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Might be a good idea to first get an actual IQ measurement first before making a major career decision based on said IQ. A proper IQ test administered by a psychologist or MD, not an SAT test or an online one.

For what it's worth, I'm QA and I've got a measured IQ in the mid 80's. Thus far I've had no complaints from anyone about it.

</comment><comment><USER6> Nothing in your post leads me to believe you actually have a low IQ.

Actual posts from people with low IQ read more like 3+ replies deep in the comments section on a controversial political video on YouTube.

You sound like you have testing anxiety, insecurities, self-confidence issues, self-esteem issues, and self-doubt. The word choice of your post and the way you explain what is going on suggests you have sufficient intelligence. It seems like the biggest blocks to being successful in this field you have are believing in yourself and judging yourself. You keep thinking you should be further along and working at a "better" company. You keep comparing yourself to others and their path.

Stop.

Your life is your own, your path is your own. Your background is your own. Your challenges and dreams are your own. Don't expect your experience to be like everyone else's. There are a wide variety of successful developers from hugely different backgrounds. Some people could only go to a local collage or state university. Some people don't even have a CS degree and are still successful. I know some people with only high school-level education that can debug applications with with a time-travel trace looking at the assembly language level. Many of the people who created the popular frameworks and programming languages don't have the background you would expect. And honestly there are even a few positions at some really well known companies where even below average intelligence people can be successful. There are successful developers who have never worked at a FAANG company and probably never will.

Work on confidence, self-esteem, self-worth, and believing in yourself. Stop judging yourself.

Don't let getting into a FAANG company be your measuring stick of what success is, make that a goal instead. Plenty of people found that when they actually got to a FAANG company, they didn't actually like it, or didn't end up staying very long.

I would ask yourself these questions to see if you are successful:

Are you enjoying your current job?

Are you learning at your current job? / Does your current job prepare you for future jobs?

Are you being paid well at your current job?

Do the benefits of your current job meet your needs?

If you can consistently answer yes to these questions, then you are successful. These are also a good barometer of when to ask for a raise or look for a new job.

<comment><AUTHOR> I do work at a FANG company right now, but it's the one people think is not full of smart engineers (as measured by labor market value)

1) I don't hate it but I don't love it. I don't think it prepares me for future jobs.

2) I make about 80% of what folks down the street from me make at competing tech firms, and even with the next level promotion I'd still be at 95% or less.

3) they are fine, but not "good". I feel like I'm not valued based on how I'm treated.

</comment></comment><comment><USER7> Strengthen your weakness by learning in great depth in those areas - that will buttress those areas. Persistence:- You can beat a smart engineer who sits on his ass - doggedly complete all you are tasked to do.</comment>


Iceland commemorates first glacier lost to climate change - <AUTHOR> https://phys.org/news/2019-08-iceland-commemorates-glacier-lost-climate.html <comment><USER2> And with the worldwide loss of ice and snow, less sunlight is reflected, leading to more warming. And yet no country is doing what's necessary to prevent catastrophe.

<comment><USER3> It's naive to say a 'country' is responsible for this. In the end, people like you and me have to decide what the future is going to look like.

But who has time or integrity to stand up against things like climate change, right?

<comment><USER4> The only people who have enough power to solve the problem are the leaders of a handful of countries.

So, while obviously only people can solve the problem, it's only a select few people that actually can do anything about it. You or I have no more power than that which democracy affords us.

<comment><USER5> In the end, it will be the individual who makes the final decision. And we are going to decide to be comfortable now, rather than save the current state of the planet for future generations.

I am a pick-up-the-litter kind of guy, but I am not going to do without air conditioning.

Leanardo DiCaprio feels passionately about climate change, but he's not giving up his private jet flights.

Barack Obama feels strongly too, but he's not going to give up yacht vacations.

Human nature dictates the final result. Perhaps we'd better devote our energies towards ways to deal with the inevitable. Because nobody's going to voluntarily live 100 years in the past for the benefit of those 100 years in the future.

<comment><USER4> Only 100 companies are responsible for 71% of global emissions[1]. Individual decisions have such a vanishingly small impact on the environment that it's actually counter-productive to make this type of argument.

People have a limited amount of time to spend on different aspects of their lives. If you dedicate all of your "saving the planet" time to minor personal changes, you won't have the time to do what is actually necessary -- push for political change which will actually address the problem. Yes, you aren't saying "don't try to solve the bigger problem (lack of action by governments)" but you are saying "focus on the smaller problems (what type of laundry liquid you use)" \-- which would inevitably result in the bigger problems being neglected by most people.

[1]: [https://www.theguardian.com/sustainable- business/2017/jul/10...](https://www.theguardian.com/sustainable- business/2017/jul/10/100-fossil-fuel-companies-investors- responsible-71-global-emissions-cdp-study-climate-change)

<comment><USER5> The 100 companies include Shell, BP, Chevron, etc.

They are only producing the means for abusing the environment-- it's the end users that are doing the damage.

I suppose you could argue that if we outlawed petroleum production that it wouldn't allow the abusers anything to work with, but it would also deny the world of most of the progress made in the last 150 years.

</comment></comment></comment></comment></comment></comment><comment><USER6> A different perspective:

"Björnsson describes how Ok shrank rapidly during the 20th century, as shown by its area on various maps: 38 sq. Km. in 1901, 15 in 1910, 5 in 1945, and under one Km. in 2016. Most of this was before anthropogenic warming became the dominant cause of warming. [...] If Ok died during the Medieval Warm Period, it was born again during the Little Ice Age. It may have lived and died countless times during its long life. Its latest death is another example of weather converted into propaganda."

[https://fabiusmaximus.com/2019/07/24/we-killed- okjokull/](https://fabiusmaximus.com/2019/07/24/we-killed-okjokull/)

<comment><USER7> Shrinking is not a linear process that would have continued indefinitely at 1910 temperature levels.

</comment></comment><comment><USER8> Suppose we manage to stop increasing the greenhouse gas levels in the atmosphere, and then even manage to lower them back to, say mid 20th century levels.

Will the glaciers come back? Or does forming glaciers, as opposed to just maintaining them once formed, require another ice age?

</comment><comment><USER9> This topic is to HN what bees was to Reddit. An endless stream of karma- grabbing comments that don't really add anything new to the conversation.

</comment><comment><USER10> Our thoughts and prayers are with this former patch of ice on the harsh island of Iceland.

</comment><comment><USER11> > Sigurdsson said he feared "that nothing can be done to stop it."

I've seen this claim a lot in the last few years.

Good news everyone! We don't need to stop global warming anymore.

<comment><USER12> That basically what the Trump administration is now saying.</comment></comment>


Replacing dep with go mod for Golang dependency management - <AUTHOR> https://d53dev.net/2019/05/17/migrating-a-standalone-go-project-from-dep-to-go-mod/ <comment><AUTHOR> Op here: I realize this is a very, very small, even simplistic, example and it possibly misses all the important details. It was, in any case, a quick and easy process that I wanted to share.</comment>


Show HN: ElemX – Native Web Components Using MobX with Vue-Like Template Syntax - <AUTHOR> https://github.com/agquick/elemx.js <comment><USER2> Looks very nice!

FYI, we've been able to get MobX to work very nicely while still keeping binding expressions as actual JavaScript with ${} expressions.

The benefits there are that you get syntax-highlighting and some type-checking of the expressions for free without extra tooling that understands your template syntax. You could still keep the Vue-like syntax for the rest of the templates. Might be something to look into.

<comment><AUTHOR> Thanks for taking a look! That's actually a great idea. It's always a trade off with bindings in html templates, you lose the things you just mentioned. Right now the bindings are passed to the mobx reactions tied to the element, I'd be curious how that could still be maintained with the proper scoping.</comment></comment>


YC was nominated for a Crunchie, but please vote for Ron Conway instead. - <AUTHOR> http://ycombinator.posterous.com/yc-was-nominated-for-a-crunchie-but-please-vo

<comment><USER3> Just a side note; what's the need for using an url shortener in a non character count restricted environment? I really don't like clicking a link I don't know the real destination for.

If I'm not the only one who feels like this there is, in this case, unfortunately a risk that Ron has already "lost" two or more votes.

<comment><AUTHOR> They're the only links I have. This is the way TechCrunch gives out the links for voting. Probably they do it to encourage people to use them in tweets.

<comment><USER4> With bit.ly (and j.mp) you can take

<http://bit.ly/3Bxd>

and turn it into

<http://bit.ly/3Bxd+>

and it'll give you the long link.

<comment><USER5> more importantly, it will give you a hell of a lot of data about the clicks on the link

</comment></comment></comment></comment><comment><USER6> Of note, Ron Conway invested in YC (albeit somewhat indirectly) earlier in the year.

[http://www.techcrunch.com/2009/03/16/y-combinator-gets- the-s...](http://www.techcrunch.com/2009/03/16/y-combinator-gets-the-sequoia- capital-seal-of-approval/)

</comment><comment> brown9-2 _Three YC-funded startups were also nominated for Crunchies this year. Please help them out by voting below_

Looks like Posterous was also nominated for "Best Internet Application" - <USER2> reason why they're not called out too?

<comment><AUTHOR> Oops, will fix.

Edit: fixed.

</comment></comment><comment><USER5> This move makes me want to vote for YC. Dilemma!

</comment><comment> n-named YC funded companies winning a crunchie will have a much greater impact than YC winning a crunchie, YC is already on the map. Very nice way to concede the YC vote in order to get HN readership to vote for the YC startups.

<comment><USER7> YC is not competing with their fundees (different categories), they _are_ competing with Ron Conway, to whom PG would like to yield his support.

</comment></comment><comment><USER8> What's the deal with recommending Dropbox to be voted best in internet, but Posterous not? I like em both, though Dropbox is a bit better imho.

<comment><AUTHOR> See reply to other q asking this

</comment></comment><comment><USER9> Wow, that's an incredibly classy gesture. Thanks to everyone on the YC team and in the YC family - it's a great culture you've built. Lots of great discussion on HN, communication, writing, and great companies. Cheers and happy holidays.

</comment><comment><USER10> Why is the Nook on the list and not the Kindle2/DX both of which went on sale in 2009?</comment>


Why Simplicity is BS. - <AUTHOR> http://dhfromkorea.com/why-keep-it-simple-is-bs

<comment><USER2> I think he is onto something here. Indeed, the simplicity should not be a goal itself. What is important in capturing the essential. If simplicity helps then go for it.

But more often than not, simple things are better. But there is a line you can cross and the simple works against you. Things become like children toolboxes - you can't do anything with them.</comment>


Undercover restorers fix Paris landmark's clock - <AUTHOR> https://www.theguardian.com/world/2007/nov/26/france.artnews <comment><USER2> Pantheon, user's guide [2009]:

[https://vimeo.com/51365068](https://vimeo.com/51365068)

        Original title: "Panthéon, mode d'emploi"

        Executive producer: RUHE PRODUCTION © 2009

        Produced by:
        UX films
        Zone-Tour

        In association with:
        La Mexicaine De Perforation
        The Untergunther
        The Mouse House

// previously on HN, Feb 2015: [https://news.ycombinator.com/item?id=9052160](https://news.ycombinator.com/item?id=9052160)

// Wired, Jan 2012: [http://www.wired.com/2012/01/ff_ux/all/1](http://www.wired.com/2012/01/ff_ux/all/1)</comment>


Massago – RMT Massage - <AUTHOR> http://massago.ca <comment><AUTHOR> Massago - the Uber of registered massage - is changing the way Canadians experience therapeutic massage. It's the on-demand mobile app that brings the therapist to them – at their home, office or hotel – within the same day, and often within the same hour. Massago was built on the idea that busy people can't always take the time to go to the spa or clinic to get a therapeutic massage. Rather than having to book days in advance for an appointment, they can get treatment from Massago when they need it most – on short notice. When their massage is over, they can relax where they are instead of battling traffic or transit to make their way home.</comment>


How we fine-tuned HAProxy to achieve 2M concurrent SSL connections (2017) - <AUTHOR> https://medium.freecodecamp.org/how-we-fine-tuned-haproxy-to-achieve-2-000-000-concurrent-ssl-connections-d017e61a4d27 <comment><USER3> I have a stupid question, there are at most 65536 ports and some are not usable. There is also a file descriptor limitation. How to have that many concurrent connections?

[https://unix.stackexchange.com/questions/84227/limits-on- the...](https://unix.stackexchange.com/questions/84227/limits-on-the-number- of-file-descriptors)

<comment><USER4> There are at most 65536 ports _per remote IP_.

TCP connections are basically identified with an _(ip, port)_ tuple.

Also you can set the file descriptor limits to whatever you want.

<comment><USER5> Aren't TCP connections more accurately identified by (srcip, srcport, dstip, dstport) tuple? This is somewhat significant as you can easily have tons of IPs in a single box.

<comment><USER6> Yes, but after the initial syn/ack, the daemon will allocate an _outgoing_ port number for the connection. So if you have a single IP address and a burst with hundred of thousands of requests, you will run into problems..

</comment></comment></comment></comment><comment><USER7> One quibble I would make with the article is that you are not actually limited to ~65k connections from a client. It is only ~65k per IP address on the client (given that they're all talking to a single remote port)

You can add NICs or virtual IPs and bind your client instances to specific IP addresses instead of INADDR_ANY.

<comment><USER8> It is addressed in the previous article of the serie.

</comment></comment><comment><USER9> hot damn!

I really appreciate the walk through of the apache bench (ab) results and learning process even though it didn't get them to their objective - I've been thinking about using ab myself, and these are great things to know.

I took down a few notes while reading the article:

\- mentions use of apache bench ( ab ) command for load testing

\- mentions use of ganglia tool

\- mentions configuring HAProxy for multi-core using nbproc setting

\- mentions the 'parallel' tool for running commands in parallel

\- simulate long run requests by having the server delay a little vs client (work around for ab deficiencies )

\- have the server also send different response lengths back simulating varying load

\- pdsh tool to remote parallel shell (ssh) sessions

\- vegeta tool - that got them to their scalability / tipping point objective

\- nodejs (used for their backends) had a default request timeout of 2 mins

\- used dmesg to learn that haproxy was running out of mem (at around 1.2mm conns)

\- pdsh to run vegeta tool on multiple machines (acting as clients) - <USER2> included in article

\- mentions haproxy maxconn setting - and verification by checking proc fs limits for the haproxy pid</comment>