wmfiv

Not getting into which solution is better, but Capture One is at least 50% more expensive than Lightroom. It's a material difference.

Venezuela has reserves. Relative to the gulf it doesn't produce any meaningful amount of oil from those reserves.

BCBS CA revenue is approximately $25B. The total of above is $25.6M. That's 0.1%.

You may view those salaries as appropriate for leading companies of this size or immoral and outrageous. But either way executive comp is not the big problem with US healthcare costs.

Work jobs in the order they were submitted within a partition key. This selects the next partition key that isn't locked. You could make it smarter to select a subset of the jobs checking for partition keys where all of the rows are still unlocked.

  SELECT
  * 
  FROM jobs 
  WHERE partition_key = (
    SELECT partition_key 
    FROM jobs 
    ORDER BY partition_key 
    LIMIT 1
    SKIP LOCKED
  )
  ORDER BY submitted_at
  FOR UPDATE SKIP LOCKED;

I think all your points are valid, but I've also had good results using workspaces for environments. Here's generally how I structure my terraform primarily targeting AWS.

- 1 Terraform workspace per environment (dev, test, prod, etc.).

- Managing changes to workspaces / environments is done with whatever approach you use for everything else (releasing master using some kind of CICD pipeline or release branches). The Terraform is preferably in the same git repositories as your code but can be separate.

- The CICD tool injects an environment variable into the build to select the appropriate workspace and somehow supplies credentials granting access to a role that can be assumed in the appropriate account.

- A region module / folder that defines the resources you want in each region. This is your "main" module that specifies everything you want.

- Minimal top level terraform that instantiates multiple AWS providers (one for each region) and uses them to create region modules. Any cross region or global resources are also defined here.

- The region module uses submodules to create the actual resources (RDS, VPCs, etc.) as needed.

This approach assumes you want to deploy to all your regions in one go. That may not be the case.

Maybe there aren't too many itches left to scratch?

Between Dynamodb, Cassandra, and Scylla seems like that problem set is somewhat a solved problem? I know those products continue to move forward, but they all work really well at this point and solve the fundamental problem to a good degree.

I've found actors (Akka specifically) to be a great model when you have concurrent access to fine grained shared state. It provides such a simple mental model of how to serialize that access. I'm not a fan as a general programming model or even as a general purpose concurrent programming model.

Makes sense as a theoretical problem. Have you ever seen data that suggests it's a practical problem? Seems like one could identify "should be cached forever but wasn't" using etag data in logs.

This has been the common/best practice for so long I don't understand why TFA is proposing something different.

More than highlight they'll do schema validation against inline SQL strings also.

With due respect, I think you've misunderstood the single-table design pattern.

Because you've introduced static hash keys ("user", "email", etc) you've had to manually partition which DDB should do for you automatically. And while you covered the partition size limit you're also likely to have write performance issues because you're not distributing writes to the "user" and "email" hash keys.

Single-table design should distribute writes and minimize roundtrips to the database. user#12345 as a hash key and range keys of 'User', 'Email#[email protected]', 'Email#[email protected]', etc achieve those goals. If you need to query and/or sort on a large number of attributes it's going to be easier, faster, and probably cheaper to stream data into Elasticsearch or similar to support those queries.

Please look at your individual situation and don't take this suggestion blindly. If you've already contributed significantly to your deductible or out-of-pocket maximum it can definitely make sense to continue with COBRA.

Also you can game the COBRA enrollment window. You have 60 days from your loss of coverage to elect COBRA and once you elect COBRA you have another 45 days to submit payment. You can elect on the 59th/60th day and then pay 45 days later if you ended up needing the coverage. If you don't need the coverage don't pay.

I see Manifold as a huge leap past previous tools Immutables or Lombok. I understand there's a use case where you want to add these language features to an existing code base. But for the most part if you want the language features on the JVM, you should probably just use Scala. That gives you a set of established patterns, best practices, libraries, and a community of users.

If you want type safe SQL in particular, you can pry JOOQ out of my cold dead hands.