C -> Redis

I haven't written any C for years, but really enjoyed skimming through Redis codebase, it's so clean, easily understandable and extensible.

Also, "getRequiredSampleSize" is called twice for each variant - in the "getResult"'s loop and then inside "hasEnoughData". Same thing for "getVariant". Would you welcome a pull request?

Your project is great, I'd totally use at work. Also, it was to learn the math behind that. Thanks!

Glad you like it, happy to have you contribute :)

Feels like the "Easy to modify and maintain" part is confusing the benefits of using Node.js with benefits of good application design.

Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?

I think the article says that the API is stable unless you have access to "Alpha" and "Beta" channels.

Alpha and Beta channels only affect what client you get. All client versions talk to the same API, so it has to be very stable/backwards compatible.

Absolutely. Once you hit the wall trying to solve a problem, you better distance yourself from that problem. Otherwise you'll likely be hitting the same wall over and over again.

For me personally, quiet walk probably won't cut it, because I'd still be focusing on that same solution that failed. But switching my mind completely often helps me to stumble upon a fresh way to solve my problem that will likely work.

Thanks! Probably the best collection of SaaS related articles I've seen on the internet.

I'd say methods should be small enough so that their intent is clear. Usually it means that methods should have exactly one responsibility, otherwise they seem bloated.

Great article!

I wonder if the guys are doing code reviews for each PR along with making sure build is green. In our team, we've been doing code reviews for about three years now and can't imagine our workflow without them.

Yes, we're absolutely doing code reviews for each PR. Should have mentioned it in the post. Our general policy is to have engineers merge their own PRs, but only after at least 1-2 people have reviewed them (and obviously more for sensitive changes). The dialog that takes place in PRs helps enforce (and sometimes define) our style standards, teach engineers the idioms of a languages they may be new to, and ensure that we're always moving our codebase in the right direction. (They're also a great place to teach people how to write cleaner and less brittle tests!)