opmac

There's a lot of inconvenient truths one needs to accept if they want to advocate for widespread nuclear energy. Specifically, there are very real nuclear proliferation concerns which cannot be ignored. Alternative clean energy sources, which are safe on the global scale, can made widely available with proper investment. That should be the future.

Thanks.

This research is nearly two years old and I haven't found any consumer devices specifically made for this purpose yet, unfortunately. I'm sort of wary of buying random LEDs advertised as 670nm on Amazon and then shining it directly into my eyes. Regardless, it's very exciting research.

Perfect succinct response. It is a 100% viable workaround.

Returning a 429 would not just to hope that the Go proxy would obey the response, but rather it would significantly reduce the workload the server has to do when it gets a request it doesn't want to serve.

> I couldn't say exactly why it got popular.

Probably because it has the backing of Google.

Analog vs digital! I feel similar to you. There's a certain feeling with analog/mechanical instruments that is hard to replicate.

That being said, I think there is something fascinating about eco-drive movements, or just plain quartz movements in general. In the eco-drive case, you're harnessing the raw energy of the sun! Right there on your wrist! And they're using piezoelectricity to accurately keep time!

It's so simple nowadays that we all take it for granted, but centuries of scientific improvements have gone into making that relatively inexpensive and accurate wristwatch accessible to everybody.

Super cool - thanks!

It is somewhat slower if you are looking up records by key. You still need an index to do that, and non-integer PKs such as UUIDs can be twice as large as the integer alternative, taking longer to search while requiring more memory.

That being said, in PostgreSQL, you are correct --- having a UUID (or something similar) as a PK is usually fine assuming you understand the implications. However I would absolutely avoid it in a DB like MySQL where PKs are clustered.

In a database like MySQL where a clustered index exists for the primary key, or even a NoSQL DB like DynamoDB, it often makes sense to expose some version of the PK to the public if your lookup pattern for that resource is going to be by PK --- versus having some other "public" primary key field like you describe.

If you look up the resource by some other field, that means that you now need to support two indexes - one for the primary key, and one for the "public" primary key. This obviously requires more storage and comes with the performance overhead of keeping the second index updated on modifications to the table. Additionally, for something like DynamoDB where you pay per index, it could be cost prohibitive.

A better pattern is to simply encrypt/decrypt the primary key before exposing it publicly, such as in a URL. This requires no additional database overhead.

The hashids documentation is pretty explicit about it not being secure. It says verbatim:

> Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids.