• 4 Posts
  • 110 Comments
Joined 2 years ago
cake
Cake day: June 4th, 2023

help-circle

  • One of the prime rules of storytelling is that the hero has to have a flaw.

    Superman is super. He can’t lose. That’s why the writers introduced Kryptonite. Captain America is a super-soldier, but is still mortal. Thor is a god, but can lose his hammer and his powers.

    The problem with Superhero movies is that they all got so much power they became invincible, and boring.

    Good, classic storytelling beats VFX 10/10.



















  • Ed is getting good at lobbing these darts at hype bubbles.

    The thing that this writeup ignores is that the object isn’t to show short-term revenue, but to put all competitors out of business, be the last one standing, and create a monopoly. Either that or get bought out so the investors can move on to the next thing. But at $150B valuation, only MSFT or Nvidia can afford to buy them outright.

    Google, Meta, and Amazon burned through cash for years, but they eventually outran all competition and then monetized the users who had nowhere else to go.



  • fubarx@lemmy.mltoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    4 months ago

    OK, you wanted a conversation… :-)

    I did read the post, but I assumed it was the starting point of a system or mechanism, not the end-point. Wanting to just run “docker compose up” is fine, but there is more to developing and deploying to production (and continuing post-launch).

    That’s why I mentioned the CLI. It lets you go from a simple local app (Django on sqlite) to a Docker one (postgres, celery, redis, etc.), to all the way out to the cloud (ECS/EKS/serverless lambda/RDS), without having to remember what commands do what or managing lots of separate docker-compose files.

    I can see we are VERY far apart on how docker should be used in moving toward a production-ready system.

    For one thing, recommending putting secrets inside docker-compose is an instantly disqualifying piece of advice. There’s a whole ‘secrets’ section of docker compose that is there to prevent people from inadvertently including those in cleartext and baking them into images: https://docs.docker.com/compose/how-tos/use-secrets/.

    Github itself has a secret scanning mechanism to prevent leakage: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning. For gitlab, there’s also Blackbox or HashiCorp vault. Putting AWS key/secret inside a repo can be VERY expensive and open one to legal liability if the account is misused. Repeated infractions could lead to AWS banning one’s account.

    I really recommend you take down that part of your post, instead of proliferating bad practices.

    As for the rest, to each their own.