IME you have to be willing to recalculate the summaries up to some kind of consistency window.
Yes you may be changing history and you may have a business reason not to address that revision immediately (you've already billed them?) - but the system can still learn it made a mistake and fix it (add activity from Jan 30 evening that comes in late to the Feb bill?)
I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining.
I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro`
Python is currently going through an "coloring" as the stdlib and 3rd-party libraries adapt to the explicit async/await syntax and it's honestly kind of PITA. Curious if there's any more info on how Ruby achived this.
Ambition might stand out in the same list as laziness. Plus I'd be reticent to tell programmers to "be more ambitious!" - I see greenhorns esp just trying to do too damn much at once.
In the context of "code that is going to be reviewed" maybe even "vanity" might have been closer to what he was getting at? (did you even RUN this?) Except us old neck beards obviously don't care about how WE look ;)} - just how our code reads.
I think "take pride in your work" would have substituted well; but given the options, maybe hubris was fine - he explains what he means in a couple of sentences.
I have this theory that what-about-ism as a debate technique, elevated by more readily available un-helpful "facts" (e.g. single varient evaluation of complex system), hased cause people to forget the utility of facts. When you and I have a REAL disagrement about something importand and complex the FACTS that we can both agree on and take for granted are what ENABLES us to find a new higher resolution understanding - we can get further because we can focus. I try to look out for what-about-ism disguised as refuting evidence, and approach people's belief epistemologically.
> This is by design. As long as it's profitable to exploit labor, nothing will change.
Do you by chance believe in "Intelligent Design" as an explanation for complex biological systems? It's not obvious to me that inefficient social systems (i.e. not optimized for worker/human happiness) require "design"? If we create an organism who's survival condition is "generate profit" won't it just do that as efficiently as we let it? When I think about exploitative systems as requiring "malice by design" I rarely seem to uncover a solution other than "wait for someone else to be less evil" or occasionally "live with it and treat the worst of the symptoms".
Another fun/easy-to-follow intro to basic Reed–Solomon coding
[...] by the end of this post, we will have written a complete working implementation of a simple variant of Reed–Solomon coding, not entirely unlike what is used in [OpenStack] Swift itself. No prior knowledge will be assumed except a working knowledge of high-school algebra and the Python programming language.
We are making running private cloud storage awesome. Our core product - the SwiftStack Controller - makes it easy to configure, deploy, manage and monitor your own personal Swift[1] cluster. It's a Django app, with a background task and alerting/eventing engine, a 0mq based remote execution agent to control the fleet, and statsd feeding graphite for telemetry.
But our core deliverable is OpenStack Swift. OpenStack is the open-source alternative to AWS, and Swift is Object Storage (think S3). And our team is actively driving new capabilities[2] with the open source community.
Our customers are managing distributed storage systems growing at dozens or hundreds of terabytes a month - we're literally taking on big problems - wanna help? We're primarily a python shop, actively recruiting Sr. Engineers and opinionated UX designers who have experience working with a Django team - but we've got lots of room for experience at all levels, if you're interested check us out:
We are making running private cloud storage awesome. Our core product - the SwiftStack Controller - makes it easy to configure, deploy, manage and monitor your own personal Swift[1] cluster. It's a Django app, with a background task and alerting/eventing engine, a 0mq based remote execution agent to control the fleet, and statsd feeding graphite for telemetry.
But our core deliverable is OpenStack Swift. OpenStack is the open-source alternative to AWS, and Swift is Object Storage (think S3). And our team is actively driving new capabilities[2] with the open source community.
Our customers are managing distributed storage systems growing at dozens or hundreds of terabytes a month - we're literally taking on big problems - wanna help? We're primarily a python shop, actively recruiting Sr. Engineers and opinionated UX designers who have experience working with a Django team - but we've got lots of room for experience at all levels, if you're interested check us out:
Yes you may be changing history and you may have a business reason not to address that revision immediately (you've already billed them?) - but the system can still learn it made a mistake and fix it (add activity from Jan 30 evening that comes in late to the Feb bill?)