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.

Seiko 5 is probably the cheapest, worthwhile mechanical watch. You can always get cheap Chinese and Russian watches as well but they will be of lesser quality and reliability than the Seiko. So to answer your question directly - probably not. But I would recommend checking out Orient watches. They have a decent set of mechanical watches of all different styles, not much more expensive than the classic Seiko 5, but definitely a step up in quality. https://www.orientwatchusa.com/

Thickness is always going to be an issue with automatic watches. You can get thinner watches if they are manual wind since they don't have a rotor. Usually, the thinner they get, the more expensive they get though, so keep that in mind. You can get super thin manual wind watches but they will cost hundreds to thousands of dollars usually.

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!

I love this. As a watch enthusiast myself, it's always great to see the history of watches and how their internals came to be.

For anybody interested, there's also an awesome video from Hamilton made in the late 40s that shows a lot of the information in this article!

https://www.youtube.com/watch?v=rL0_vOw6eCc

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.

Encrypt them on the backend before exposing them to the public. Decrypt in the backed on access. See https://hashids.org/

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.

I was going to recommend this. No reason to use a special data type for the ID in your database unless you have some sort of actual constraints (like a 64 bit limit or something).

Instead just use a sequential integer (or UUID). When you need to expose it publicly, use something like hashids ^.

The main downside to straight UUIDs as primary key, is the B-tree used to store the primary key is larger if using UUIDs which are 16 bytes vs 8 for longs. In this case though the IDs are 8 bytes so this point is moot. Also the data is stored randomly on disk, which will make things like range queries slower if querying by ID (but you probably want a different index for querying anyway).

From the status page:

> This issue has also affected our ability to post updates to the Service Health Dashboard.

Just seems so ridiculous that they have trouble reporting the impaired status of their system due to... the impaired status of that same system.

K so they avoided that problem, but something similar has obviously gone wrong again, considering that Kinesis had been partially or fully down for almost an hour before the status page got their first update.

And the fact remains that currently an outage of AWS's own infrastructure is impacting AWS's ability to status updates on its own status dashboard. It's just seems so... amateurish.

It is kind of perplexing that AWS dogfoods its own status page. I remember during the massive S3 outage a few years ago that their status page remained green almost the entire time because the red/green/blue icons for the status was stored in... wait for it... S3.

You'd think they would have learned from that.

Did you even read the article? I feel like you just repeated like 90% of what it said.

Hardware is defined by physics. I can write code that is logically the same no matter what hardware it's running on. Of course, some software has to take the hardware it is intended to run on into account, but this is not a fundamental property of software as a whole.

I would say logistics is outside the realm of the software itself, but rather with the organization. It's a valid point, but somewhat tangential to what Fowler is trying to say here. That is, software is not inherently complex, but rather becomes complex through our own doing, and it takes good architecture to attempt to prevent this.

I'm not sure how this relates to Teams whatsoever and why you're drawing the comparison. Teams is for organizations who have Office 365. Duo is person to person chat... think Apple Facetime.

I can't call up my Mom on Teams. I can with Duo.

Copyright 2018?

In my experience, yes, but it depends on the company. Most tech leads I've interacted with (including myself) write some code from time to time.

Which has its own problems but that's another story.

The latest versions of Kotlin support multiplatform programming (and hence native compilation) and this feature is actively under development. The JVM is not necessarily needed if you go that route.

https://kotlinlang.org/docs/reference/multiplatform.html

YAGNI - learn to embrace it.

Seriously I read that bug report and I would say the same thing to OP... especially since the issue was largely a duplicate of an already existing issue. He also was hardly lectured.

Also not sure why he feels the constant need to bring up their $50M endowment... OP is no question entitled.

> 6) 300 CHF is still 6x what I pay for healthcare per month. I currently pay 46 USD per month for (from what I can tell is excellent) healthcare, vision, and dental.

You are the exception here, not the rule. 46 USD for Healthcare is pretty rare in the US. It's not uncommon for people to spend 500 USD per month, so 300 CHF would look good to many people.

There is also the potential argument that the Swiss healthcare system is better overall than the US system, but that could be a complete debate in itself.