Curious how you settled on your pricing?

Gut feeling I suppose ? Pricing less felt like selling it short considering I still have quite a few features and content I want to add to the app, pricing more felt too much considering it's missing aforementioned features (:

I might bump the price to $50 in a year or so if I'm satisfied with the new content/features and feel like it deserves it (only for new users, lifetime owner will get all updates for free obviously).

Curious is there a go lib that can read the config file? I’d love to have this in some testing to make it more accessible.

That’s why Knative (Serverless on Kubernetes) accepts containers. It’s the standard packaging format that lets you lift and shift apps to many different platforms.

Lambda shifting to this model would be such a nice future. though even the lambda variants that can run containers have some painful issues.

What are the issues?

Funny to see a little go library you wrote [1] show up in a blog post years later. I need to update it now that go has iterators and generics.

Another great blog post [2] covers performance issues with go tool

[1] https://github.com/dprotaso/go-yit

[2] https://blog.howardjohn.info/posts/go-tools-command/

Is Render still using Knative?

https://render.com/blog/knative ?

Not any more. We replaced it with our own code that did exactly what we needed it to do.

What free monitoring tool do you use?

This seems timely given iOS 18 has limited contact list syncing [1]. Curious if you have a social app focus or thoughts?

[1] https://x.com/nikitabier/status/1836612494938509664

Yup! One of our targeting properties is `contacts_permission`, and it will return 'limited' with the new setting. With the SDK you could formulate a response to the change and ship it; all through JSON over-the-air update.

For example, you could detect that the user limited permissions with out targeting, and use a native banner+modal to inform them of the benefits of approving all, and deep link to settings to change it. This would only target impacted users and not everyone. Again, no new code to write or app releases -- the SDK lets you handle the unexpected.

> Splitting your operations into containers then breaks the monolith into microservice pieces and introduces all the downsides

A pattern here is to not split the monolith and use the same container for your main app and hot operations. The hot operations just need some different configuration eg. container args or env vars

https://knative.dev/ - (CloudRun API is based on this OSS project)

Curious - what are you using to power/style your docs website?

Predominantly, middleman, markdown and a splendid web designer.