livingcoder

That's an interesting take. I didn't know that the tool screen even existed, so I had no idea that it would be nice to have in my toolbelt for future needs. A README also helps those that may already know a lot about screen and want to know the differences between screen and their implementation.

There is nothing better in open source than a thorough, well-written README at the root of the project. Wanting others who don't understand the source of the inspiration to be completely clueless is unfriendly (at best).

The README helped a lot, thanks. Just wanted to point out a minor typo, I think the second word under the "Client" section is meant to be the word "client".

Thanks for the explanation and README. I'll check it out.

I don't know anything about screen. I think it would be great if you included a nice README.md file in the root of your repo for explaining what screen is and what your repo does both differently and the same. Please let me know if you do that. I'll come and check out the repo at that point - kinda hard for me to want to jump directly into the code at the moment.

I've had mine on vibrate for years. Texting doesn't trigger it, only calls. It's been great. I look at my phone only when I'm ready to look at it.

When I see it in a movie I'm watching, I'll just talk to the TV "So, you're not going to get on the radio and call for help? You just saw a guy get pulled away into the darkness. No? Wait, you're going to slowly walk into the darkness? You are the main character after all, so I guess you just want me to see what's in there. Thanks, I guess."

I love riffing on bad movies. When the character is finally around other people I'll say "Oooh, guys... she has a secret! It's pretty important. Probably something that will kill everyone in the station. I would tell you guys, but I think she wouldn't want me to share it."

3000...

I prefer to just throw the state into a database. Each table has their own "repository" type that knows how to save/load models and then I have "manager" types that use "repository" types to compose larger, feature-specific domain models.

I usually just use Sqlite for it's simplicity but I'm not opposed to Postgres via Docker.

When your management judges teams by lines-of-code written.

I'm just going to start pronouncing it "The Gulf of MEH-he-co", really laying on a heavy Spanish accent for clarity.

I'm surprised this doesn't already exist.