ramanathanrv

If I am not wrong, this is what both Facebook and Apple trying to do. Both these platforms can sell individual articles but they choose not to do so due to high overhead in the payments infrastructure.

The problem in such a model is that the negotiating power of the publishers is much lower. And hence, they are always at the mercy of these aggregators. And I believe that will be the natural tendency of the aggregators, since they control the distribution.

Platforms like Scroll & Magzter are still in early times while Facebook and Apple are way ahead. All of them will invest in algorithms to surface personalised recommendations for users. They can easily tweak the algorithms to lean the way they wish to & the motivations will not always be clear since customers don't have visibility into their recommendation algorithms. And this will have a great impact on the Publisher since their revenue depends greatly on these recommendations favouring their content.

This is indeed a huge problem. In the current form, it quickly become unsustainable (in terms of both time and money) for customers to work with so many subscriptions. Maybe the end state is Netflix/Prime like platform for digital news wherein the platform can share the subscription revenue across all the participating media companies depending on the usage. The argument against that is - these platforms now control what is produced, their price and distribution. Such an arrangement will eventually subvert democracy.

Our team is working on creating a micro payments platform called ana.money.

We don't see this as micropayments vs subscriptions. But micropayments & subscriptions. Media outlets (text/audio/video) will benefit from offering both these forms of payments to let customers access their content.

Our goal is to build an infrastructure that supports this worldview. We will make it incredibly easy for publishers to sell both individual articles and subscriptions: taking care of user identity, invoicing, taxation, cross border/multi-currency, etc..

Best wishes to Stripe. They deserve to succeed. I speculate that the biggest competition for Stripe is going to be Amazon which will use AWS to rollout payments API.

For small setups, it is better to stay away from Kubernetes until it reaches a good level of stability. We jumped early on in the K8S bandwagon (before AWS EKS) and paid a steep price for that. We continue to pay. Our AWS cost has doubled since the time we transitioned to K8S from AWS Elastic Beanstalk.

I really wish I could say what would be a good time to embrace K8S, but your mileage might vary. When we made the switch, our service was at about 80TPS during regular load and would go up to 300TPS during peak load.

Regarding `avoid side-effects`, the amount of side-effects that are required for a typical real problem solving code base is quite reasonably measurable. For example, the number of network calls, DB calls, FileSystem read/writes are are measurable. Have you been able to reduce the `side-effects` significantly or have just become more aware of it?

When we started using ExpressJS (coming away from Java), there was a tremendous change. As soon as you begin to code in Javascript (say from Java/Ruby/Python world), async hits you. There is no escaping it. And the programmer faces a tax (every time when implementing async/await or generators), his/her awareness about side-effects (deliberately generalizing IO as side-effects) and they tend to be more careful with it.

Well deserved!

I remember that before BootStrap came to the scene, we used to work with BluePrint CSS. BluePrint gave a nice canvas and concealed all the IE6 related issues. However, once Google Chrome became mainstream, it was time to move up to the next level. BootStrap emerged to the scene and completely won over so many hearts. The world is a better place because of BootStrap! Many many thanks for the team that put this together.

The article is postulating only a theory. We have seen the opposite true in credit card forms where users have to input card expiry date. No matter what sort of formatting we did, users always typed expiry wrong and our JS would point it out. We finally had to abandon input text boxes in favor of select boxes for card expiry month & year. We measured the eventual success rate and that turned out to be higher as well.

My guess is that since the scope is so narrow (1 out of 12 choices for month) and selection is very obvious, perhaps people made lesser mistakes here. Select boxes are more effective in mobiles as typing takes more effort than tapping.

I was expecting this for a while now. But the pricing part isn't very clear. Is it $149 per instance or for the solution itself? Could be better if the article elaborates more on this.

High availability is the main requirement. Since we are running our hosts in AWS, we are sure that the host(s) running influx would go down certainly few times a year.

Will look more into Cassandra. Since it scales really well, it could well be worth investing time and money.