cballard

OK Cupid also has questions covering:

- Evolution.

- Whether or not dinosaurs were a thing.

- If the Moon landing happened.

- The relative size of the Earth and the Sun.

- If Astrology is scientifically accurate.

... among others, all of which I had marked, with the correct answer set as "mandatory". If someone answered enough of these with the wrong answer, you won't even see them (if you do, you'll have a high "enemy" percentage), so you won't waste your time talking to them.

Maybe this is not really an issue for homosexual couples, but I would never have considered Tinder because unlike OK Cupid, there's no way to filter out Republican-hates-the-gays-hates-abortions types. The question/answer filtering and profile text was the most important part of online dating to me.

C# and Java optionals aren't very useful, since they would be reference types themselves, and thus could be null!

I would submit Rust and Swift as "decent" type systems, if Haskell is the standard for "good". They do nullability correctly, but lack HKTs.

"Decent" is being very kind to any language that has a type system where every reference type is implicitly a Maybe (okay, Scala exists).

GitX is my favorite, despite being quite buggy, because the others I've seen are all way too complicated.

I really just want visual log and visual add -p and GitX nails that.

The author of NSHipster works for Apple now and typically, Apple employees don't blog about work - possibly a policy?

If you call 311, TLC will slap a $300 fine on them, so taking out your phone and doing that will instantly fix the machine.

It's really not an issue in New York. 311/TLC doesn't mess around with this.

There are so many cabs that I don't really see the need for this, and most cabs take Apple Pay now, so I've never really seen the point of this and the other one (is there another one? I think there is?).

If I was somewhere where there aren't a lot of cabs I'd probably just use Uber, it's cheaper and cleaner anyways.

Small PRs are an issue because PRs are dependent on other users and can't be dependent on a prior PR.

Let's say we're adding an interface/typeclass/protocol and a concrete implementation. I'd say these should be two separate commits, as they're adding two different things. An interface doesn't require a provided implementation to work. But, if we were to create those as two separate pull requests, it would be more work for the project maintainers, and the initiator wouldn't be able to create the PR for the concrete implementation until the interface PR was merged - the concrete PR can't be added as a dependent PR of the interface one, or something to that effect.

Since you can "compare" almost anything on Github, small commits aren't really an issue, just view a larger-scope comparison to get an idea of the whole PR.

Another way to put this might be that commits are for individual code changes that build up to a pull request, which is a conceptual change?

This is a bad idea masquerading as a good idea. Before making a pull request (or doing any sort of merge), you should rebase against upstream master (or whatever you're going to push to). However, keeping distinct atomic commits that change one and only one small thing, when possible, is much preferable if bisect or blame is used. If you have broken or poorly written commits, use fixup, reword, squash, etc. in rebase -i.

Using fast-forward (and possibly only allowing fast-forward) is a good idea. Squashing entire pull requests that may change multiple things into a single commit is a very bad idea.