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#jo@email.com', 'Email#joe@email.com', 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.

It does. But if you're concerend about this (and many of the other items mentioned), you can control access to those features using IAM.

https://docs.aws.amazon.com/service-authorization/latest/ref...

The condition keys specifically are here and you can see keys to control access to storage class, tagging, etc.

https://docs.aws.amazon.com/service-authorization/latest/ref...

https://www.jobrunr.io//en/ seems to be popular at the moment.

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.

For sure. Virtually every Jepsen test has found bugs even with extremely mature products like Postgres. But fundamentally Cassandra (and Scylla) and most other databases tested have fixed those bugs and improved their documentation with many incorporating Jepsen tests into their ongoing process.

That's different from how Raven has just wildly mistated their capabilities.

It's not better because it doesn't actually work.

If you're not interested in a science experiment, Cassandra (or Scylla) are the multi-master databases that are mainstream and proven to work and scale. They're not fun or sexy and their feature set is much smaller but they do what they say and they work. Or AWS/GCP/Azure will happily give you an API for one.

Right. And I think the point is that Redux is a godsend for some small percentage of products but for the vast majority the cure is worse than the disease. Simple and slightly verbose is just "better" as a general solution than the powerful but complex solutions you get with Redux.

One challenge a bundler and transpiler introduce is they enable an unconstrained set of solutions.

If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.

I've not seem them claim to have broken CAP. AWS is quite an academic organization I think it'd be quite unlikely for them to say something like that.

They do actually provide quite a lot of detail about Aurora storage this works. This 2019 reinvent talk gets pretty deep into the weeds.

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

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_...

Yeah agreed. It's about tradeoffs. If you want scale to zero with low latency DynamoDB already exists and provides that. The tradeoff is you give up all the nice features of a RDMS.

I don't have any first hand experience but there is an integration with AWS EventBridge.

https://aws.amazon.com/blogs/compute/building-salesforce-int...

I know even less about Azure, but it looks like Azure Data Factory (?) provides some kind of similar functionality?

https://learn.microsoft.com/en-us/azure/data-factory/connect...

Was this intended as satire? I honestly can't tell.

Yeah. This works both ways. At small scale or early stage you should try like hell to work backwards from pre-existing components so that everything does exactly what you need them to do by definition. Eventually you outgrow that and it makes sense to build things that do exactly what you want because the incremental value is worth it.

To add on to the comment about Keycloak, the comparison to AWS Cognito has a couple issues as well.

- The comparison suggest Cognito is more expensive. Cognito pricing starts at 50,000 MAUs for free. That's 10x the size of the SuperTokens free tier. It then tiers from $0.0055 down to $0.0025. That's 1/3 to almost 1/10 of the SuperTokens hosted open source option. MAUs who use SAML or OIDC are another $0.015. That's still equal to or less than the SuperTokens hosted open source version where SAML isn't even available.

- Multi-tenancy is a complex topic. But a common pattern using Cognito is to create a User Pool per tenant which provides a lot of flexibility depending on the number of tenants you anticipate.

Source IP is an IAM global condition so it's available for all requests.

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p...

Is your spend 2% of revenue? 5%? 50%? Saving 50% of 2% is almost certainly not worth the risk. The bigger your the percent and your revenue the more likely you should do it. Dropbox again is a good example.

Dropbox (from the a16z article) to me is the exception that proves the point.

What percentage of COGS is your cloud/infstracture spend? If your products don't look like cloud infrastructure (aka Dropbox), it better be very small. If you think cloud is costing you 1000% what it would cost on-premise, that's almost certainly a spend and architectural discipline problem, not a cloud problem.

This is the price sheet for Oracle's commercial Java distribution. You're almost certainly not using this and instead using an open source distribution of OpenJDK provided by Eclipse, Amazon, Azul, etc.

I'm struggling with the idea that React is a primitive used to build a Web Framework.