sklarsa

There's nothing wrong with an ORM if you want to move quickly and get something up-and-running, which is the case for pretty much every startup who needs an article like this. As long as you're aware of the typical footguns (N+1 queries) and understand your ORM's lazy-loading scheme, IMO it's worth the tradeoff of developing yet another way to manage and parametrize your queries.

I'd rather spend the time building out my product than prematurely optimizing and overthinking my DB schemas at the earliest phases of a project.

In my experience as someone who started learning how to golf in their 30s, you need to be playing at least 4x a week to get good enough to start enjoying it in the first place. Unless you like shanking balls 5 yards, looking for lost balls in the woods, or picking your ball up near the green because the rest of your group has already finished the hole. Which to me, is no fun at all.

I've been using Incus containers (not VMs) for running tests against a "real" OS and it's been an absolute game changer for me. It's granted me the ability to simultaneously spin up-and-down a plethora of fresh OSes on my local dev machine, which I then use as testing targets for components of my codebase that require Docker or systemd. With traditional containers, it's tricky to mimic those capabilities as they would exist on a normal VM.

Because both my project and Incus are written in Go, orchestrating Incus resources in my test code has been pretty seamless. And with "ephemeral" containers, if things start to get out of hand, I just need to stop the container to clean it up. Much easier than a 2-step process like it usually is.

Looking forward to seeing what's to come in IncusOS!

I'm very surprised to see all of the negativity toward Cloudflare's usability and value here.

It's been relatively painless for me to set up tunnels secured by SSO to expose dashboards and other internal tools across my distributed team using the free plan. Yes, I need to get a little creative with my DNS records (to avoid nested subdomain restrictions), but this is not really much of a nuisance given all of the value they're giving me for free.

And after paying just a little bit ($10-20 per month), I'm getting geo-based routing through their load balancers to ensure that customers are getting the fastest connection to my infra. All with built-in failover in case a region goes down.

Usually I write some IaC to automate this tedium so I only have to go through the IAM setup pain once. Now if requirements change, that's an entirely different story...

Personally, I find the OSS Grafana and Loki experience to be a bit maddening; both as an end-user and admin.

From the admin side, I usually end up deploying Loki with Helm charts in k8s clusters. This makes it difficult to tweak specific settings, especially around Loki's varying deployment models and "power-user" options. Helm also makes upgrades a bit scary without rigorous testing in staging environments that have version parity with prod across all infra tools. The same goes for Grafana, which I usually deploy alongside Prometheus, tightly-coupling that entire part of my observability stack.

As for end-user experience, Loki's storage and query model seems to be designed for log aggregation across multiple microservices with structured logging and proper tagging. But sometimes, I just want to read through application logs, and batch-querying through grafana's "explore" interface doesn't make it any easier.

What are people using for log aggregation these days? The author mentions a central syslog server, and that doesn't sound like the worst idea to me...

> but a single word used in a vague enough way is enough to skew the results in a bad direction

I'm glad I'm not the only one who feels this way. It seems like these models latch on to a particular keyword somewhere in my prompt chain and throw traditional logic out the window as they try to push me down more niche paths that don't even really solve the original problem. Which just leads to higher levels of frustration and unhappiness for the human involved.

> Anecdotally, I've felt my skills quickly regressing because of AI tooling

To combat this, I've been trying to use AI to solve problems that I normally would with StackOverflow results: for small, bite-sized and clearly-defined tasks. Instead of searching "how to do X?", I now ask the model the same question and use its answer as a guide to solving the problem instead of a canonical answer.

Set up your dev environment and get the project running locally. This can take anywhere from 2-3 hours to a week. But if it does take towards the longer end of that period, you will have learned tons about the application's architecture, past design decisions, and will probably have made at least 1 git commit to a README somewhere.

I love the ending of this story, which isn't obvious from just looking at the title. The author identified key pain points around customer support, automated them, and went back to enjoying life. This is the kind of thing that gets me excited about the possibilities of technology and AI as a force multiplier, especially when working on side projects, "lifestyle" businesses, or even startups as a single founder.

Zola, GitHub and Netlify. Easy and free