Hook that up to digital auto-pay and you pretty much have what OP had before the policy change.

Yes. You basically have to keep eating that way and your gut flora adjust to compensate. It’s still a pretty windy diet since you rely on those gut-bugs to break down a lot of the sugars in beans.

My gums hurt just looking at this.

Exactly. Sure, China gets shit done. But it comes with not giving a fuck about a lot of their own people, a lot of the time.

This is why I’m mostly okay with hunting deer, here in the US. We displaced their predators so it’s on us to make up the balance. I say “mostly” since, like others are saying in this thread about taking habitat away from kangaroos, the better answer is to give them an actual functional ecosystem to live in.

The trick is to find the right message and tone for the moment. I also think change like this is necessarily incremental. It’s possible that with enough doom-and-gloom around a pending “market correcting event”, that helping everyone reduce grocery bills by eating vegetarian a few nights a week, would be the right message.

Yup. Learned that one back in the 3rd grade. This stuff is hard if you’re not experienced enough to know how people work.

On the upside, I learned that one cannot buy their way into other’s good graces, especially if they’re going to require you to modify your behavior to get there; they’re lying and that was never the issue. On the downside: holy shit that hurts once it goes wrong the first time.

As an adult I can also appreciate that there are situations where you can “buy your way in” to a club or status of some sort. IMO, those situations are generally not worth it to begin with, requiring an never-ending stream of cash to keep up appearances. Plus, it surrounds you with other people that also believe, and are invested, in the program. It’s a recipe for elitism at best, and a big 'ol grift at worst. Better friends and relationships can be had for $0 everywhere else.

Snake, this is a sneaking mission. You are not here to assassinate anyone’s work.

Did they conduct this test in Japan? I ask since we could be losing something in translation. AFAIK, the Japanese people have a habit of being overly polite and not conveying strong emotion publicly, which might explain Kojima’s reaction. If he wanted to provoke a strong reaction in people, they’d say very different things.

Now if we could just talk to some EU internet satellites…

Bias. Good 'ol plain bias.

Unless you’re very self-aware, one requires actual training and practiced mindfulness to break free from that in all endeavors. There’s also some lack-of-the-outside-world going on too - one would need to have at least thought about world experiences apart from one’s own, to consider alternative possibilities.

Agreed, although it’s wise to have a backup option for this. It’s entirely possible that you have two solid Portal players go at this, which should be a really fun romp. However, in my experience, any skill gap between the players usually turns every stage into “how do I carry my friend through this puzzle?” An extreme version of this can be seen in Game Grumps’ playthrough.

I never played this game; is it really so good that fans were clamoring for a re-release? What am I missing if anything?

Also, I may be misremembering when this was launched but isn’t it a bit early for a re-master on this one?

Why am I suddenly staring at the sun?

Thank you!

I firmly believe this is how we wound up with tabs as a feature in the first place.

Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so “printf debugging” like this is truly your best bet.

To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

Heisenbugs are the worst. My condolences for being tasked with diagnosing one.

Last time I did anything on the job with C++ was about 8 years ago. Here’s what I learned. It may still be relevant.

• C++14 was alright, but still wasn’t everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
• C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. “RAII” is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there’s no other way to enforce them or check for their absence.
• I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn’t exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode¹. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
• A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two “C++ programmers” possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
• Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
• At some point you will need valgrind or at least a really good IDE that’s dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team’s ability to fix serious problems.
• C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
• Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go’s book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
• Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).

1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it’s just more data, after all.