If true, that would mean that a 1 year C++ project could be done in 2 hours, and a 10 year project in half a week.
1,920 karma · joined July 27, 2014
If true, that would mean that a 1 year C++ project could be done in 2 hours, and a 10 year project in half a week.
Here's more on how software collections work and what is released: https://developers.redhat.com/products/softwarecollections/o...
If a request comes in from an external system, and that request is queued, then the external system is already not directly impacted by downtime after the queue. Additional latency in processing after the queue is also hidden by the single queue. After a single queue makes the overall system async the goal should be to increase overall throughput and efficiency, and I don't believe only using queues accomplishes that.
I've seen this play out multiple times now, where the engineers decide they are "doing messaging", and use it for everything, even what could be simple request/response REST services. Tuning the overall system for performance becomes complicated, and the messaging brokers have to be scaled out to handle the multiplied load.
On a less serious note, the logistics game Factorio (https://www.factorio.com/) really drives this point home. In a distributed system/assembly line, really large buffers all over the place makes it harder to detect issues and tune throughput.
As far as microservices, one benefit is that it makes blurring the lines between domains much harder. A mediocre developer can easily go into a well designed code base and make a mess of it quickly. In a microservice setup, their mess is mostly contained to one domain at a time.
But, I would like to think that I am both good and experienced. I picked up my bad typing habits while learning to program, after all.
I think it comes down to priorities, and the fire in front of you always has higher priority. That means that onboarding and prereqs are not the priority until the consultants show up on-site and you are paying for them to find other things to do while waiting for the real project to start. Then it is a fire, and everyone starts moving with purpose.
I've spent almost the last decade involved with designing and implementing the messaging system behind PTC. Every one of these disasters makes me wish it was deployed everywhere. But for better or worse, railroads are incredibly change and risk intolerant. Everything goes through extensive testing before being rolled out into the field, which can add several years to any rollout plan.
If people changed their minds just because everyone else disagrees with them loudly and violently, how would any previous social change have come about? New thoughts and perspectives always start as minority views. So majority consensus must not be enough to change someone's mind.
Also, this really isn't about winning. We're all losing right now.
When those people watch Fox News (http://www.foxnews.com/tech/2017/08/14/twitter-users-identif...) and see what is happening to those people for their speech and actions, they are being silenced.
These are also probably the people more amenable to changing their views. It's got be pretty hard to swing someone with a tiki torch marching down the street, but someone who feels sympathetic to their views could maybe be reasoned with if they would talk about it.
If people see that people who share the same views are losing their livelihoods, they are more likely to be silent. Only the independently wealthy wouldn't consider losing their job risky.
And just to be clear, I in no way support their views, desires, or actions. But claiming the goal isn't to silence them is disingenuous.
Saying Clinton won the popular vote is just wishful thinking.
But since the proprietary software has a "no benchmarking" clause, open source projects cannot respond to the whitepaper by performing their own benchmarking. They would need the permission of the proprietary vendor!
For example, here is an IBM blog post comparing the performance of IBM MQ and Apache ActiveMQ (https://webspherecompetition.wordpress.com/2015/03/12/ibm-mq...). I've tried to find a copy of the IBM MQ EULA to link, but cannot find one anywhere. But last time I reviewed it (several years ago) I believe it also had a "no benchmark" clause.