| Blogs at | https://blog.julik.nl |
| Code | https://github.com/julik |
The new LLM world is very exciting, and I try to experiment with the new tools when I can. This includes building agentic applications, one of which is my personal accounting and invoicing tool - that I wrote about previously As part of that effort I started experimenting with RubyLLM to have some view into items in my system. And while I have used a neat pattern for referencing objects in the application from the tool calls - the Rails Global ID system - it turned out to be quite treacherous. So, let’s have a look at where GlobalID may bite you, and examine alternatives and tweaks we can do. What are Rails GIDs? The Rails global IDs (“GIDs”) are string handles to a particular model in a Rails application. Think of it like a model URL. They usually have the form of gid://awesome-app/Post/32. That comprises: The name of your app (roughly what you passed in when doing rails new) The class name of the model The primary key of the model You can grab a model in your application and get a global ID for it: moneymaker(dev):001> Invoice.last.to_global_id Invoice Load (0.3ms) SELECT "invoices".* FROM "invoices" ORDER BY "invoices"."id" DESC LIMIT 1 /*application='Moneymaker'*/ => #<GlobalID:0x00000001415978a0 @uri=#<URI::GID gid://moneymaker/Invoice/161>> Rails uses those GIDs primarily in ActiveJob serialization. When you do DebitFundsJob.perform_later(customer) where the customer is your Customer model object which is stored in the DB, ActiveJob won’t serialize its attributes but instead serialize it as a “handle” - the global ID. When your job gets deserialized from the queue, the global ID is going to get resolved into a SELECT and your perform method will get the resulting Customer model as argument. All very neat. And dangerous, sometimes - once LLMs become involved.
We get attached to code - sometimes to a fault. Old migrations are exactly that. They’re digital hoarding at its finest, cluttering up your codebase with files that serve absolutely no purpose other than to make you feel like you’re preserving some kind of historical record. But here’s the brutal truth: your old migrations are utterly useless. They’re worse than useless - they’re actively harmful. They’re taking up space, they are confusing (both for you and new developers on the project), and they give you a false sense of security about your database’s evolution. If your database is out-of-sync with schema.rb you need to solve that problem anyway, and - if anything - the migrations make that problem worse.
My previous article about timezones turned out to be useful for quite a few folks, which makes me happy. One candle lights another. Ben Sheldon asked about then actually doing something with those converted times. How do you actually send a newsletter every morning on every working day, regardless of what the user’s time zone is? There are a number of approaches to this - once you know the UTC time of the delivery. I will cover a few of them, including the one I prefer. Let’s wind the clocks!
Sometimes, after a few pints in a respectable gathering of Rubyists, someone will ask me “what is the most undervalued module in the Ruby standard library?” There are many possible answers, of course, and some favoritism is to be expected. Piotr Szotkowski, who untimely passed away this summer, did a wonderful talk on the topic a wee while back. My personal answer to that question, however, would be Random. To me, Random is a unsung hero of a very large slice of the work we need to do in web application, especially so when we need things to be deterministic and testable. So, let’s examine this little jewel a bit closer.
I assume Ruby Central will read everything sent to their "Community Feedback Box" and possibly even discuss internally what if anything to do about feedback they receive.
That said, their recent track record reflects a lack of transparency that is wildly inappropriate for being in an official stewardship role over the infrastructure of an entire open source ecosystem.
To that end, I've set up a repository where people can submit their questions in public as well, here:
https://github.com/community-research-on-ruby-governance/questions-for-ruby-central
Anil Dash
Steve Troughton-Smith
André Arko
Gregory Brown
jcoglan