DZittersteyn

Looks like they did a bit of premature rounding:

the difference between 38℃ and 94℃ is 100.8Δ℉ rather than the 100Δ℉ that was probably there in the original markings. It's the closest you can come to the correct values though, 93℃ is off by 1Δ℉

They then assumed 100Δ℉ = 56Δ℃, and applied that to the rest of the dial.

That means the values on the dial are off a bit, and should be: 38, 93, 149, 204, 260, 316, 371, 427

My guess would be that a screen that can stop a rat from going up a toilet, would also prevent other things from going down a toilet

It makes sense to me that the weekend comes at the end of the week, but then again, I don't know what came first, the term "weekend" or the convention of Sunday being the start of the week in some countries

I also used to have this impression, I think I got this from Rails and Django docs, maybe you read something similar?

> Rails comes with built-in support for SQLite, which is a lightweight serverless database application. While a busy production environment may overload SQLite, it works well for development and testing. Rails defaults to using a SQLite database when creating a new project, but you can always change it later.

> By default, the configuration uses SQLite. If you’re new to databases, or you’re just interested in trying Django, this is the easiest choice. SQLite is included in Python, so you won’t need to install anything else to support your database. When starting your first real project, however, you may want to use a more scalable database like PostgreSQL, to avoid database-switching headaches down the road.

I think you mean Fyre festival, if so the documentary you're referring to is probably "Fyre: The Greatest Party That Never Happened"

just set the timezone of your devices to UTC, and you're done! Actually getting other people to schedule meetings with you in UTC is going to be a bit trickier though.

Looking at the reports, the UUID's are xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, so V4 UUID's, which should be pretty hard to guess (barring bad PRNG, but that's a whole different problem)

You could ofc. erode with a smaller element, and open with a larger one, but that might be just as parameter-tweaky as this approach ;)

Is there a reason to be doing doing a closing, and then a sequence of erosions, followed by dilations?

Since closing(image, str.elem.) == erode(dilate(image, str.elem), str.elem), it feels like you could better use an erosion (remove noise) followed by a closing (to fill up the empty spaces) instead of the other way around?

This is answering the question: "Does tihs email address exist?", which is nice, but usually not the question being asked. The more common question is "Is this the email address of the user", which can only be answered by a confirmation email.

You could use this method as a first-line validation though, to give the user some feedback (similar to not implementing the full RFC regex, but simply checking /.+@.+\..+/)