I had this whole theory built up about how the aliens were manifestations of the little girl's trauma and grief and everything was just happening within the town. All the stuff on the radio and TV was her using spooky kid mind powers unconsciously. That's why they were allergic to water: she has a weird thing about contaminated water glasses.

And then at the end he just hits the fucking alien with a baseball bat and the credits roll. What the actual hell.

maybe this will work

...

...

...

linting and unit tests

Source: how it went the first time

This reminds me of the time my group played a kobold campaign. We found a halfling scout and dealt with him. Then we made an improvised catapult and launched his corpse into the middle of his camp. And then we snuck in and wiped the rest of the halfling party while they were trying to figure out what was happening.

One of the guys in our party put skills in cooking and rolled a nat 20 making halfling jerky. A few sessions later a wizard or whatever granted us a wish, and we wished for our supply of nat 20 halfling jerky to never run out.

So now we're rolling around the countryside raising hell and handing out halfling jerky to everyone because it is now the most powerful diplomatic tool in our arsenal. We never told anyone what it was made out of and pretty much any NPC who didn't want to kill us on sight got a piece.

I don't remember what happened to the party. I think our GM gave up in disgust after a while. Good times.

Pretty sure One-Who-Goes-Bankrupt-Running-A-Casino is a Ferengi insult.

The final project in my instrumentation class was to tune a PID controller for a hot/cold mixing valve. I (CS/ENG) was paired up with an engineering student and a lot of it was throwing parameters in, seeing if weird shit happened, and then turning down or up based on the result. I had a programming final and something else I was supposed to be studying for, so I just started doing a binary search with the knobs. We got the thing tuned relatively fast and my partner acted like I was a wizard.

Huh. These things are a central plot point in Hercule Poirot's Christmas. I always thought Agatha Christie just made them up.

Molyneux's great sin is the inability to shut the fuck up while he's ahead. lt's hard to explain how much weight this guy carried in the 90s/very early 00s but he was the guy that did Populus, Dungeon Keeper, and Syndicate. And then he just kept over-promising and fucking up for a whole decade.

If he'd kept it reasonable he might still carry some of that weight but he cannot stop promising the moon and then delivering mediocre shit. It would be like Miyamoto releasing flappy bird with NFTs instead of the next Zelda game. God he's so frustrating.

"Captain's Log, supplemental."

Larry Ellison from Oracle had a cameo too. It was gross.

I've been a dev for 20+ years and yeah, learning a new repo is hard. Here's some stuff I've learned:

Before digging into the code:

• get the thing running and get familiar with exercising it: test happy path, edge cases, and corner cases. We're not even looking at code yet; we're just getting a feel for how it behaves.
• next up, see if there's existing documentation. That's not an end-all solution, but it's good to see what the people that wrote the thing say about it.

Digging into the code:

• grep is your very best friend. Pick a behavior or feature you want to try and search for it in the codebase. User-facing strings and log statements are a good place to start. If you're very lucky, you can trace it down to a line of code and search up and down from there. If you're unlucky, they'll take you to a localization package and you'll have to search based on that ID.
• git blame is also your very best friend. Once you've got an idea where you're working, use the blame feature on github to tie commits to PRs. This will give you a good idea of what contributing to the PR looks like, and what changes you'll have to make for an acceptable PR.
• unit tests are also a good method of stealth documentation. You can see what different areas of the code look like in isolation, what they require, and how they behave.
• keep your own documentation file with your findings. The act of writing things down reinforces those things in your mind. They'll be easier to recall and work with.
• if there's an official channel for questions / support, make use of it. Try to strike a balance here: you don't want to blow them up every five minutes, but you also don't want to churn on a thing for days if there's an easy answer. This is a good skill to develop in general: knowing when to ask for help, knowing when an answer will actually be helpful, and knowing when to dig for a few minutes first.

There's no silver bullet. Just keep acquiring information until you're comfortable.

That would be pretty easy.

return "Why are you even trying to do it this way?\n$link_to_language_spec\nThis should be closed.;