Yeah agree, the devex has room for improvement as well. I use it perfectly fine for simpler apps but it could be better.

Big love for cloudflare though - all my apps are hosted with it. Their components and generous free tier have been able to let me ship so many random things.

I've been building out my portfolio at https://verdient.co.uk/ and writing more blog posts about applied maths on my blog at https://tom-dickson.com/

Most recently I've been having fun extending the functionality on a website I use to host tools that help me structure and plan workouts - https://ironvolume.com/

This looks interesting but I’m trying to understand it in more layman’s terms. Is it more about providing abstractions for llms to work within to do things?

It’s actually a CI/CD as code tool, where some pieces can be LLM agents.

But, the marketing heavily focuses on LLM stuff to the point of making everyone confused.

I've never tried it. My first impression based purely on reading the homepage is it adds complexity to something I can already do with a Dockerfile and bash. What can it do that I can't already do more simply?

It does a pretty good job of caching and that does help speed up builds. I also run all of my end to end tests from it because I can coordinate secrets and clusters of containers through it.

Instead of YAML workflows you write code, and there is an analog of the Github Actions Marketplace (the Daggerverse).

what sort of prod apps are you running from it? keen to learn by what other people are doing

The most substantial one is a local business directory. It's exactly the right level of medium complexity where Pocketbase shines. It's all the standard stuff:

- User signups and auth

- Stripe subscriptions using different subscription levels

- Business listings with image galleries, editable images

- Map with markers for business locations, tags, filterable business categories & tags

I'd say that the way Pocketbase handles collections, you probably don't want data that is too nested (even though there's a JSON type field, which then allows much deeper nesting).

If you're coming from Firebase, you might be used to infinitely nestable collections, but that's not how it works in Pocketbase. So you could either have a ton of collections or use nested data.

But, if for example, you had multiple clients which then need to hold a bunch of nested data, you couldn't have a 'clients' collections which then holds a bunch of collections within it. It's just one level of 'collections' within which each item then has fields.

This works well at medium complexity, but could get complicated if you had, say, a CMS where you'd want a few levels of nesting.

There has got to be opportunities here for abstracting over regulation to make it easier to comply with and prove compliance so that risk owners/govt can enact change faster. Now to figure out who would pay for that.

I feel like articles like this need to come with a diagram like this to put it in the context of relevant tradeoffs.

                       High Scale/Revenue
                              │
                              │
      Managed Services        │      Self-hosted K8s
      (Overpaying but         │       (article is
      no choice)              │       pitched here)
                              │
  ────────────────────────────┼────────────────────────────
      Low capacity            │         High capacity
                              │
                              │
      Managed Services        │      Managed Services
      (Right choice -         │      (Wasting money on
      focus on product)       │       platform team)
                              │
                        Low Scale/Revenue

Or something like that. Maybe as a function of time as well but that might be harder to do in 2d.

Sure I can absolutely manage my own k8s, but there is no doubt it's easier for me to spin up postgres and ship faster on my own. At enterprise scale it's definitely a lot easier to do everything in k8s and be able to manage as many aspects as possible. I have experience of both.

Looking at an ancient game called Trias/Ternii Lapilli and learning/using maths to figure out if it can be solved https://tom-dickson.com/blog/trias-game-investigation/

It’s similar to tic-tac-toe but slightly different of course.

Found it a great opportunity to learn about new areas of maths. Trying to figure out where to go next with it.

Life is easy when you don't want to think about scale or security. Until you have to, that is.

Yeah the author is broadly talking about the difference between IaaS vs PaaS where in the latter the vendor is also your DevOps team. The cost being a more opinionated setup you have less control over.

A trade worth making oftentimes but it doesn't make the complexity go away.

this is a really interesting talk - thank you for sharing!

Via Gleam's discord:

https://discord.gg/Fm8Pwmy

There's some good stuff there

I ported my personal website from Jekyll to Astro a few weeks back and I really liked it. Astro is much easier to build and extend for me (and that is a personal preference point - I (and by I mostly mean claude) - and it's cool to add react components in to create more interactive points (but I haven't deployed that element yet).

Speed is probably the same as jekyll - but relative to my react vite and nextjs apps it's about 10 times faster.

I would definitely use Astro for more complicated websites than content driven - but would probably return to nextjs or more hefty full stack solutions for complicated web apps.

Do you have an intuition of when something becomes hefty and complicated, and would require a full stack solution like Next.js?

I do not but I think I'm growing one!

Potentially the heuristics would be about the level of user state management - e.g. if you're needing to do various workflows vs just presenting content.