ashinybrowncoat

Define poor. I would call poor anything less than a 11 figure income so the definition of poor is subjective in and of itself. The relative difference in wealth should not so great so throwing a bone to the poors is only using a band-aid to triage a gaping wound that has been bleeding for a very long time. When I say "tax the rich" I am not talking about using current our current tax system. Whaty I am really saying is "make the people who exploit others pay for the exploitation." Watching rich get richer while poors get poorer is sickening and defending the rich is also sickening to hear.

So throw a couple extra bones to the poors and maybe the race thing will solve itself? Why tax the fucking rich? Academics and politicians need to change the message to simply that: tax the rich. You can't fix one extreme without addressing the opposite extreme, in this case. Tax the rich and less tax for the poor (everyone else).

Sorry, I meant product owner, not manager. At least I got the abbreviated version correct, though.

This sounds actually quite possible but wouldn't this also eliminate the need for having a scrum master and/or product manager? All those SM/PO people would have to find a new job and then, on top of that, the entire sector of businesses selling scrum master certifications for $250 (or whatever they go for this year) could also potentially go belly up, too. I really like this idea!

This seems to be a lost author looking at socialist media platforms, not capitalistic social media. Things that actually have a cost should not necessarily be provided for free, even if one does not understand said cost (such as the author of this story). Providing an API is an add-on and not actually required of any social media platform but it does cost money to maintain the storage of the content as well as to not just build said API but also to maintain it (including keeping it secure and scalable). This author seems to be thinking of some kind of socialist media platforms, not the current capitalist social media platforms we have now. Even so, I would definitely welcome the idea of socialistic media platforms although I am not even sure how one could be built and/or managed. This sounds about the same as "McDonald's should be free" and I don't really see a big difference other than the actual consumption of said good/service.

My name would be a moot point considering your company likely couldn't afford to hire me. It is also likely that if I met someone like you during the intervieww process that I would end the interview. I have better things to do.

Seriously? Social creatures? That BS again? Not all of us are. Don't be so shortsighted. I don't need nor do I want any added socialization. Spare me any water cooler talk, overheard gossip, and any anecdotal opinion on the weather because I really, really don't care. I would much rather do what I am hired to do. When I want to socialize, I'll do that on my own time and on my own terms without being forced or coerced into something that is "good for everyone" even when it clearly is not. I am NOT a social creature and I am NOT the only one.

"Google needs to be innovative, build new products and invest in them."

What has Google really built? Seems to me they try, fail ,and then buy something when their attempts fail (when something is available to buy). Nest? Android? Google is not innovative and they never really were, nor are they actually capable of building any viable new products.

Bottom line: SoC doesn't always mean you need to use microservices. I have worked with people that think that SoC IS microservices architecture but it is just one possible, not always practical, solution. In my experience with these kinds of people, they also tend to be the ones that overuse things like the DRY principal.

We use a mix of SQL and NoSQL databases for different and specific purposes. Your suggestion is to do the data manipulation outside of the database which typically means pulling data sets out, doing something with them, and then putting them back in. That will never be more efficient than just doing it in the database. Our SQL databases are actually scaled horizontally using read replicas since writes are much less frequent than reads and we can easily add/remove instances as demand grows and shrinks. IMO, it wasn't any more difficult to scale out our databases than it would have been to implement any other K8 (application or DB).

You missed the word maintain and is a very important point. If I can only maintain the data through an app and not directly in the database then the database is nothing more than a card file. Why not use the database features it was intended to provide? The app will be gone long before the data. Always. The next app will need to reproduce the previous apps logic. What if that was already done? It is better to have a mixz used judiciously, than to just consider the database only for storing and retrieving of data. What a wate of resources to not use those things!

So don't use the database for what it is intended because...it might be harder? I very much disagree with this article. It is not so simple to just declare no business logic in the DB when the DB schema itself IS a BIG part of the business logic. When working with data, the best place to work with the data is where it is stored, not pulled out and put back in. And your app is more likely to be replaced long before the data and/or database is. Stop treating the database like a black box and use it for what it is intended.