Querying tree hierarchies can be tricky, especially when the `IN (...)` query gets large. There are some optimisations, but you can only go that far.

We decided to denormalise the hierarchy data into the issues table. Lots of research and testing went into this. Especially for the new indexes.

But on call is fantastic situation for AI tools.

Stressful moment where AI taking notes really shines.
My first on call experience with @incident.io was magical.

Unsure if the switch from Claude Code to Codex was a good idea.

I am thinking though: When could we generate typescript from the Elixir type system?

ash_typescript/rpc is THE reason to use Ash right now.

I ran into an edge case (still need to write a bug report) but 0.x version is already more stable than most "stable" NodeJS libraries I've seen recently.

I am unsure about potential compatibility issues with all the different ash packages in the future?

Policy integration is nice.

But hard to wrap my head around policies for reads. I prefer more control over the query

It feels like I can escape the declaration style, but I am not 100% sure if that's true in the end.

Not a fan of the APIs with `for_read`, `for_create` but I understand why it's needed.

Also weird that some data is wrapped in Ash Structs (Like a string value from an changeset attribute)

Warum willst du dass die creator zahlen, und nicht die LeserInnen?

bzw. hab ichs schon angefangen zu bauen. Problem sind die Cloudflare blocker beim scrapen. Aber das kann man mit der verifizierung lösen.

Hab sowas ähnliches schon mal angedacht, aber einen Schritt weiter dezentralisiert
1. Blogs sind weiterhin self hosted
2. Man baut quasi einen RSS reader, aber blogs können sich auf der Seite verifizieren
3. X EUR/Monat für den service, Geld wird dann distributed an die creator je nach subscriber

pup-e.com/goodbye-ruby... and bsky.app/profile/ruby... , and skillissue.jardo.dev/archive/ruby... is a good starting point :D

Yep, this got me excited about Ash - already prototyping. Works great so far.

Yeah, PDF rendering is hard though. Nutrient has their own rendering engine with countless of edge cases improved and tested over a decade.

pdf.js also doesn't work reliably for you?

IIRC yes, but you can try it out with a PDF www.nutrient.io/demo/hello (left corner "Open Document").

The solution is: www.nutrient.io/sdk/web/

(Full disclosure: I worked there, built the initial version of the Web SDK)

What do you think is missing to not be used for small companies? Is it an Elixir, Phoenix, or community size problem?

Only Rails things I don't like:
- ActiveRecord. Awesome DX, but easy to shoot yourself in the foot. Elixir with separation of Schema and Repo is nicer.
- Rails docs are really sparse. Ok for things we know already. But when I look at Hotwire/Kamal docs, I leave with more questions