Ramiro's comments

Very cool! This is a great example of how ephemeral environments can help for a lot more than just fast inner loops or manual verification.

XMPP was supposed to be this. There was a boom in the early to mid-2010s (I worked at HipChat back then, and it was built on top of XMPP). IMO, it works well; it scales, but none of the commercial solutions picked up for whatever reason. In the end, as you say, proprietary protocols like WhatsApp or Slack won the market.

I've heard great things about Matrix. Peeble's founder, Eric, was building Beeper, a chat app with a similar purpose to what you describe (it recently got acquired by Wordpress). I believe that the core was built on top of Matrix, so you might be up to something there.

I'd highly discourage you from using SMS; it's very insecure. I'd go as far as to recommend you not to implement your own auth and instead use something like Auth0, WorkOS, SuperToken, or SSOReady (https://github.com/ssoready/ssoready), among others.

Building auth stacks is not trivial and is not what will make your SaaS successful. The more you can leverage experts to focus on what makes your SaaS special, the better.

I second this, the SF Public Libraries are a great place to work. I used to work out of the Potrero Hill branch a lot.

The main library (the one by the Civic Center) closes way later than the rest. Good spot if you're working alone.

I love reading these "reports from the field"; I always pick up a thing or two. Thanks for sharing @ianvonseggern!

Every time I read about Nomad, I wonder the same. I swear I'm not trolling here, I honestly don't get how running Nomad is simpler than Kubernetes. Especially considering that there are substantially more resources and help on Kubernetes than Nomad.

I agree with @metaltyphoon on this. Even for small teams, a managed version of Kubernetes takes away most of the pain. I've used both ECS+Fargate and Kubernetes, but these days, I prefer Kubernetes mainly because the ecosystem is way bigger, both vendor and open source. Most of the problems we run into are always one search or open source project away.

I really like the "remote"/ "on-site" / "hybrid" filter. Good job!

The most significant value I get from Costco is that the quality is consistently high and the options are well curated. I like not having to go through 100s of brands of basic staples like yogurt, toilet paper, milk, etc...

I agree is early, but the same thought around WASM crossed my mind. Interesting approach though

@blakesterz what kind of pain are you feeling when developing with containers on a Mac vs using your Linux box? I know perf is worse, but are you hitting other things?

This is very cool. Running tests on browsers has always being a pain. Is this something that could be run from within a container?

I think this something that people miss a lot when trying to optimize their Docker builds. Is the whole optimizing for most of your builds vs optimizing for a specific build. Not easy.

I never really thought about this, it's a good point. What do you suggest it's used instead of ["npm", "run", "start"]?

Distroless are tiny, but sometimes the fact that don't have anything on them other than the application binary makes them harder to interact with, specially when troubleshooting or profiling. We recently moved a lot of our stuff back to vanilla debian for this reason. We figured that the extra 100MB wouldn't make that big of a difference when pulling for our Kubernetes clusters. YMMV.

Fig's integration for Makefiles makes my life so much easier!

I've played with shell autocompletion before, but this way easier to use. Good luck!

Not yet. We are trying different approaches to curb this since we do want to keep our free tier.

We have the same problem in Okteto. We've been investing a lot on building tech to prevent this (I gave a talk on this during the last eBPF community days -> https://www.youtube.com/watch?v=tplv3Hjjv2Q), but it's tough. We spend a LOT of resources fighting it.

There's a couple of approaches we've tried:

1. Register each dev env with the provider. Dev Envs can have predictable URLs (e.g in okteto cloud it's the name + namespace + domain), so you can directly register it. This works well with self-service webhooks like Github.

2. Have a proxy that routes to the right dev env. This works if there's a key you can use for the routing, like a user ID or the subscription.

3. Have a proxy that duplicates traffic and send it to all the dev envs.

I'm curious wow do you solve this on the DTAP env. Are you registering a single endpoint with the webhook? Then how does it reach the separate dev envs? (or do you have a single, shared dev env?)

For debuggers, we wrote a few guides like this one: https://okteto.com/blog/how-to-develop-node-apps-in-kubernet....

> We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options

Yes, you should. This is something you can do in the 'okteto.yml' file. You can specify different environment variables, different commands and even a different image (e.g. an image with your dev tools and debugger, which you don't need in prod).

> Latency

This can be a challenge, for sure, specially if you have a bad network connection. In our experience, debuggers and incremental file sync don't require too much bandwidth.

> Don't leave your debugger paused for too long

This has happened a lot to me. In the latest version we introduced a switch to disable healthchecks during dev time so avoid this.

> And forget about trying to debug something that happens on application boot

This is the trickiest definitely. I've had luck by pausing the debugger on attach (on go and node you can do this), but it's not the most optimal.