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.

I’ll go one step further and say: Developers working from home have better jobs than their managers. The work/life balance, responsibility, and ratio of all that to salary, are practically off the chart compared to how most managers operate. It’s a handful of meetings a day, with hours of uninterrupted creative work, and enough leeway to do chores and errands without impacting productivity. It’s the ultimate perk.

Meanwhile, management via remote is practically no different than in-person, since virtual meetings and in-person meetings take the same time out of your day. Often, you can’t get away from your home office since you don’t get enough time between meetings to go do other stuff. And for people that are hot garbage at video conferencing and email, they tend to perform worse than in-person.

So what we’re seeing here is professional envy, twisted around as a correcting action of a sort. Keeping everyone in-office means their workday is just as fucked up as their managers.

I think it’s worthwhile mentioning that not only did Microsoft buy a superior solution, Skype, but let it languish and ultimately threw it away in favor of Teams.

In that scenario, we’ve already said goodbye to sadness. Regret, anxiety, self-loathing, and severe-bowel-discomfort just pulled up and are joining the party uninvited.

Go back far enough, and you uncover dishes with wonderful names like Farts of Portingale.

Thanks!

I was thinking the same thing. I feel kind of bad now.

Also: this is what it would look like if Linus wrote a CPM kernel instead.

That’s kind of where my head was going. I also had a good chuckle when I imagined a bright turquoise baby-bag with “Makita” on the side. Then again, that’s exactly how you get a refrigerated compartment for milk.

I agree. To me, this is just an amusing fashion choice. If you’re gonna need the gear, so you may as well have fun with it.

Honestly, when it comes to any accessory or tool, it’s going to have an aesthetic. Who cares what that is (as long as it’s not offensive). There’s also a tendency to consider terms like ‘fashion’ to be emasculating, but that’s what this is: fashion. Plus, kiddo isn’t going to care about logos and any gender representation; the only shit they’re giving is in their pants.

Other fashion choices for diaper bags that could be explored:

• Metal (leather/pleather, spikes, denim, band patches)
• Goth (like above, but with less denim and more ankhs and crosses)
• Gamer (cosplay appropriate bags, pokemon that’s also a bag, D&D mimic on a shoulder strap)
• Sports (tons of practical and team-branded merch options here)
• Office (suit material, inoffensive beige, briefcase handles and leather)
• Handyman/tradesman (toolbag or toolbelt aesthetic, tool manufacturer branding)
• EMT/firefighter (first-aid compartment, red/white aesthetic, cheeky “diaper emergency kit” on outside)
• Outdoorsman (gore-tex, tent material, typical REI brands, lots of straps for different carry options)

Edit: not a dad. Some of these may already exist. Point being: it’s all a matter of taste.

Eh, it depends on circumstances and the people involved. In all cases, the original couple now has a beef, so that’s where we agree.

Where things get subtle is whether or not the other girlfriend here knew that the boyfriend was cheating or not. If that’s established beyond doubt, then yeah, I can see how a confrontation would make sense. It’s still not a good idea though; they’ve demonstrated a skewed moral compass already so that could go poorly and for probably little gain in the end.

Even murkier is how different people practice non-monogamy. Some folks are free to have multiple partners without them ever meeting each other face-to-face. Others prefer to interactively collaborate and vet partners instead. Even then there’s all kinds of variations, agreements, limitations, and so on. Which is to say if someone is up front and vocal about being one of those situations, do you really know that’s true? And, if on that trust you wind up accidentally crossing a boundary with someone, how would anyone parse out the truth?

So, yeah, probably don’t start a beef with the third party just to be safe, unless you’re absolutely, positively, 100% sure that’s not going to blow up on you.

There’s also diffusing responsibility across the organization. It’s easy to achieve unethical things, when the individual’s part of the job hardly seems “bad” at all.

We tried this though. “C” stopped being an average grade and therefore “okay”, a long time ago.

Writing the tests first, or at least in tandem with your code, is the only way to fly. It’s like publishing a proof along with your code.

it sounds trite: make the tests fit the code. Yes, it’s a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.

I agree. Rather each one of those is rather substantial on its own. Plus the churn of going from framework to framework makes it less useful to compress and bundle all this stuff into fixed versions on a slower schedule (e.g. like Ubuntu packages do). I think that all contributes to bloat.

Kind of. They do center on code generation, at the end of the day. That’s where the similarities end. You can’t insert macros into your code arbitrarily, nor can you generate arbitrary text as an output. Rust macros take parsed tokens as input, and generated (valid) code as output. They must also be used as annotations or similar to function calls, depending on how they’re written. The limitations can be frustrating at times, but you also never have to deal with brain-breaking #define shenanigans either.

That said, I’ve seen some brilliant stuff. A useful pattern is to have a macro span a swath of code, where the macro adds new/additional capabilities to vanilla Rust code. For example, here’s a parser expression grammar (PEG) implemented that way: https://github.com/kevinmehall/rust-peg

You say that, but I’ve watched the JS community move from one framework and tool suite to the next quite rapidly. By my recollection, I’ve seen a wholesale change in popular tooling at least four times in the last decade. Granted, that’s not every developer’s trajectory through all this, but (IMO) that’s still a lot.

I used to struggle with this, until I realized what’s really going on. To do conventional web development, you have to download a zillion node modules so you can:

• Build one or more “transpilers” (e.g. Typescript, Sass support, JSX)
• Build linters and other SAST/DAST tooling
• Build packaging tools, to bundle, tree-shake, and minify your code
• Use shims/glue to hold all that together
• Use libraries that support the end product (e.g. React)
• Furnish multiple versions of dependencies in order for each tool to have its own (stable) graph

All this dwarfs any code you’re going to write by multiple orders of magnitude. I once had a node_modules tree that clocked in at over 1.5GB of sourcecode. What I was writing would have fit on a floppy-disk.

That said, it’s kind of insane. The problem is that there’s no binary releases, nor fully-vendored/bundled packages. The entire toolchain source, except nodejs and npm, is downloaded in its entirety, on every such project you run.

In contrast, if you made C++ or Rust developers rebuild their entire toolchain from source on every project, they’d riot. Or, they would re-invent binary releases that weekend.

Rust […] could use a higher level scripting language, or integrate an existing one, I guess.

One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it’s tough to implement a macro without side effects and enough compile-time feedback that you’d expect from a DSL.

Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.

It’s been a hot minute, but here’s what I recall.

Take a look under /etc/systemd/system/ This is a good place to put custom system files.

You’ll want to add your new foobar.service file here, then run systemctl daemon-reload or systemctl reload foobar to make systemd load the new config file. Then you can run systemctl start foobar and so on.

The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running systemctl status <servicename> and to look at the Loaded: line. Most of the packaged stuff is hanging out under /lib/systemd/system.

I appreciate that. And don’t count yourself as less advanced - a lot of folks would consider using a CM tool like Ansible to be pretty wizardly stuff.