I have scrolled through the website to learn this was released on February 27, 2024: several months before the release of Inside Out 2. Please, no pitchforks beyond this point.

Probably they find net zero (minus cost of hiring musicians) preferred over paying out a moderate income to actual artists. Capitalism at its finest.

Does it count if I give a proof reducing the entire universe down to a 2-dimensional construct?

That sounds super interesting! Can't read it until I get home (am on vacation at Disneyland right now) but in about a week's time I hope you don't mind if I reply with my updated understanding, and maybe a question or two.

I made a comment a while back (on my alt account) about how the origin of the universe can be expressed as a simple formula: https://sopuli.xyz/comment/3303086

So, I'm curious if that viewpoint will shift at all with a better understanding of electron positron interactions. It kind of makes sense to me that the universe and the antiverse are stacked on top of each other but with time pointing in opposite directions. But I'm sure I'm oversimplifying Feynman's theory and I'll have to read his reasoning to really understand.

~240,000 micro & nanoplastic pieces in one liter of plastic-bottled water.

Mfw I read this while drinking a liter of plastic-bottled water: 😮‍💨

Ok now I'm invested. What happened to up to? That's supposed to be their excuse, that there's some sacrificial lamb out there, which knocks a quarter of the price off for subscribers, this one just wasn't it. Now you locate the rare holofoil "no up to" Amazon listing and you don't get the 25%? Tyranny I say! We must overthrow! We demand up to 100% of the means of production!

In short, transitioned from a company with mostly state-level contracts to one with mostly federal-level contracts, which requires a higher level of clearance and more knowledge about security.

More specifically, the company I used to work for is a foreign conglomerate with many thousands of employees and a high turnover rate due to low pay. We would hire inexperienced people, train them up on complicated systems, and they'd leave for higher pay elsewhere, forcing us to start over. I begged HR, not to raise my pay, but to raise the pay of everyone under me because we were losing so many people. They refused. The VPs refused. I think they were under orders from overseas not to give a dime more than they had to. In the long run, it cost us millions in training. Our technical debt was through the roof. And I finally got sick of it.

My new job isn't much more complicated than my old one, but all of the people are better, the culture is way better. Less than 100 employees. Less work to do on weekends, no on call. No outages because we follow proper DevOps practices, whereas I had to forcibly drag my previous employer into modern times.

If I have one suggestion, it's to read The DevOps Handbook (2nd edition). Or listen to it, the audiobook is very good. It goes into great detail about how companies become like the one I left and how to implement practices that will prevent that kind of decay. Let me know if you have any questions. 😊

B for Bush.

If you've been working as a SRE since 2011, I'd say now is a good time to refresh your knowledge on Ops. A lot has changed since then in terms of best practices.

I would recommend reading the DevOps Handbook. The audiobook version is quite easy to digest. There are many case studies about DevOps transformations in this book as well, including Etsy's—the development techniques they used are quite interesting.

DevOps has introduced a swath of methodologies for increasing the stability and maneuverability of large technology companies. Ignoring or remaining ignorant of these standards puts companies at a steep disadvantage. CI/CD and IaC techniques allow technology companies to develop stable code efficiently without accruing technical debt.

I've worked in places where these principles were not followed and had to take on somewhat of a SRE role myself because of how many failures we were having. DevOps practices would have saved us, had we only had the knowledge and foresight to use them throughout the organization. I highly recommend increasing your awareness of these standards, regardless of what direction you want to take with your career.

As I understand, when you're working with an object-relational mapper (ORM), the default is to refer to persistent objects which cannot have their types changed at runtime. If an object goes through some kind of transformation, introducing new attributes, the best practice in OOP is to create a new object with those attributes so you don't leave nullable attributes in the original object's class definition. But this would cause the ORM to be unaware of your new object unless you create custom code to swap the references out, which is messy. In functional programming, you create a new object and DB reference by default, so no custom code is needed.

Alternately, in OOP, you could create smaller objects to contain the attributes which are expected to change through the lifetime of the controlling object, and give the outer object an attribute which refers to the smaller object. This way, the contained object may change entirely, but the owner object's type remains static in the ORM and always has a non-nullable attribute pointing to the mutable attributes (contained in objects which are swapped out functionally). It still means you have to tell the ORM when the smaller objects are swapped out, which is still messy, but at least it standardizes the process. That's my understanding of this issue, in any case.