1,453 karma · joined March 3, 2012
I'd add:
- Learn tailscale. It's one of those technologies that takes half a day to get used to (claude code will answer all your questions), and you'll never want to live without it in the future. SSH into your VPS, install tailscale and use `tailscale set --ssh`, and shut down `systemctl stop ssh.service`. You don't even have SSH daemon runing anymore, extra safety.
- Use a simple docker compose to run your dependencies like docker. Bind to the tailscale IP, so ports: {{ tailscale_ip_of_this_server}}:5432:5432. This way your database is not exposed to the web, but it's exposed to the tailscale. Use tailscale_ip_of_this_server in your ENV vars to rails to connect - since it's running in the same server, tailscale will route it to localhost (and with localhost latency).
- With claude, set up a second VPS, add it to the same tailscale, turn of SSHD. They can now connect directly via tailscale (try ping or sshing between them).
- Then, install claude code on this second VPS. Since postgres is bound to the tailscale IP on the main, the 'slave' can connect to it. Install postgres via docker, but have claude set up a 'streaming replication' between server MASTER and server SLAVE, using tailscale ip.
100% secure, encrypted, and now you have a postgres replication with zero data loss if something goes wrong.
In the same SLAVE, you can also install barman - claude code will help you set it up.
You then have a postgres BACKUP with point in time recovery.
There you go!
I consider my server's real IP (or load balancer IP) as a secret for that reason, and Cloudflare helps exactly with that.
Everything goes through Cloudflare, where we have rate limiters, Web firewall, challenges for China / Russian inbound requests (we are very local and have zero customers outside our country), and so on.
Countless times my requests in the AI chat just hang there for 30+ seconds more until I can retry them.
When I decided to give Claude Code a try (I thought I didn't need it because I used Claude in Cursor) I couldn't believe how faster it was, and literally 100% reliable.
EDIT: given today's release, decided to give it a go. The Composer1 model _is_ fast, but right at the second new agent I started I got this:
> Connection failed. If the problem persists, please check your internet connection or VPN
> What can go wrong with using UUIDv7 Using UUIDv7 is generally discouraged for security when the primary key is exposed to end users in external-facing applications or APIs. The main issue is that UUIDv7 incorporates a 48-bit Unix timestamp as its most significant part, meaning the identifier itself leaks the record's creation time.
> This leakage is primarily a privacy concern. Attackers can use the timing data as metadata for de-anonymization or account correlation, potentially revealing activity patterns or growth rates within an organization. While UUIDv7 still contains random data, relying on the primary key for security is considered a flawed approach. Experts recommend using UUIDv7 only for internal keys and exposing a separate, truly random UUIDv4 as an external identifier.
With one hour of experience of Codex CLI, every single prompt - even the most simple ones - are 5+ minutes of investigation before anything gets done. Unbearable and totally unnecessary.
A simple task that would have taken literally no more than 2 minutes in Claude Code is, as of now, 9m+ and still "inspecting specific directory", with an ever increasing list of read files, not a single line of code written.
I might be holding it wrong.
user.log_entries.delete_all
user.log_entries.create!(message: "User account reset")
user.log_entries #=> [], will be empty until reloaded
This is false. At least not in Rails 7+ (haven't tested earlier), user.log_entries will return exactly what you'd expect (one instance of LogEntry).Btw, nothing on the article about potential side effects.
Actually, the article isn't even about handling file uploads - it's about deliberately creating a modular admin panel for dealing with file uploads.
It's not modularity for "framework-y" sake, but to easily deploy that admin panel in other applications with literally a one-liner.
In a Rails app served with Puma, I've always had a hard time understanding what would be the canonical way for having a loop doing some periodic work.
I know Puma has plugin support but I don't see much documentation there.
Forking a process / threads is something that we're used having Rails / Puma take care for us.
Pressed for time and without having time to deep dive, we ended up settling with sidekiq-cron, and it's been serving us so nicely.
The same web app stays logged in forever in my mac and I access both of them with the same time intervals.
> The final steps included carefully lowering the satellite's orbit to decrease the risk of collisions and ensuring that all energy sources, such as fuel and batteries, are depleted to prevent the satellite from accidentally turning back on or creating debris. As Landsat 7 begins this decommissioned phase, it will drift silently in orbit for about 55 years before reentering Earth’s atmosphere.
Because this is class action level unbelievable.