My AI Skeptic Friends Are All Nuts

According to the author, AI skeptics are not making good arguments. AI is useful. Its not perfect, but that is not the point. It can help developers deliver value quicker.

And it’s not just Chat. Agentic AI is a game changer. I’ve been using it for a couple of weeks, and it’s already changing how I code. It’s not perfect. But still useful.

This. Is. Changing. So. Fast.

Thrive In Obscurity

The gist is that you should focus on what interests you, and write (or code about that). Be happy no because people follow you, but because what you are producing is interesting to you. Maybe the world will agree. More than likely it will not, but that should not be your goal.

I’ve managed to blog consistently since 2012. 13 years. I’ve amassed a lot of content. Nothing has gone viral. I don’t care. It has helped me become a better writer. Maybe find a job (but maybe not). It has helped me think, by making some ideas concrete and publishing them. Even if it’s only for the robots to crawl.

The secret to perfectly calculate Rails database connection pool size

Ben Sheldon argues that the maximum number of connections in your rails DB pool should be… set to infinite! That should not be the limiting factor. If you have too many, than we should limit threads or something else. Interesting.

The magic of software

Part of the author’s point is that there is a feedback loop in what we can build with software: Discovering what is possible, informs what we can build, and building things allows us to discover what is possible.

Since we understand everything about the computer and don’t need to discover its workings, software seems much more straightforward. With nothing to discover, we might say that software is the engineering practice of combining and assembling what is available from the complex system of computing in order to manifest a given vision.

But we don’t understand everything about the computer. Yes, humans designed computers, but that doesn’t mean that we understand their behavior completely, and less so when we start thinking about how different software algorithms react to each other (network traffic for example). Then we have emergent behavior.

The Deathbed Fallacy

This is a bit different, because it’s not related to software, what I usually post about.

Someone on their “deathbed” doesn’t necessarily have a perfect perspective about their past selves. And in any case, even if it did, folks on their deathbed might have 20/20 hindsight about their own preferences. That is not necessarily good advise for others. Some of that has to do that a 20 year old today is living in a world 50 years different than his grandpa: Does he really have useful advise?

by David Bryan Copeland

Working on Ruby on Rails apps can be a joyful experience. As application get larger, it is often the case that productivity nose-dives and it becomes harder to ship new features or change existing behavior. It doesn’t have to be. This book focuses on opinionated strategies to keep Rails applications maintainable.

The overarching theme is that keeping things maintainable means investing in keeping them that way every day: Agreeing with team members on standards and sticking to them. Automate when possible. Make it easy to know the “right” way to add new code. Avoid surprising or magic behavior. I think of this as resisting entropy.

The book goes into a lot of details: Application setup, and bin/ scripts, where to put the business logic, routing, HTML templates, helpers, css, javascript, models, database, controllers, jobs, and more. Throughout, the example show the recommended code and how to test it.

Of course, I don’t agree with every single piece of advise that Copeland makes. Every engineer develops their own scars based on their past experiences, and try to protect against different future pain. Sometimes there are trade-offs, and reasonable people can disagree on what to optimize for.

Overall, I got a lot of ideas on how to improve maintainability of the apps I am currently working on, and expect that most folks would too.

Links:

• Author’s Website

Conway’s Law

A good explanation why Conway’s law makes sense as a response to real communication problems. The solution to those problems is to minimize the communication paths to avoid being bogged down. Of course, less communication paths also means less collaboration and silos. There is no silver bullet, but knowing about the phenomena makes it easier to organize towards goals.

Ruby might be faster than you think

Like the a not-for-polite-company adage says, everyone has a benchmark. A recent project made the rounds adding support for using crystal to speed up Ruby very easily. The author of this post shows, that a bit of work on what is actually benchmarked makes it so the Ruby-only version performs faster than the Crystal version. Well, that is interesting. Which benchmark should you trust? The one that is appropriate for your use case, naturally 😄.

An unfair advantage: multi-tenant queues in Postgres

I didn’t look very closely at the algorithm, but the idea is that if you distribute jobs at write time, you save work at read-time, making the dequeuing faster, and avoids doing coordination work when you read. I’ve seen this too in production systems that have very “hot” queues.

I often need to write some scripts for my Rails applications. These are sometimes intended to be run in development or production environments, and require that the Rails application is loaded. The most common way I’ve seen of doing this is with a rake task:

namespace :import do
  desc "Import people. Requires a file name as argument"
  task :people, %i[file_path] => :environment do |_t, args|
    puts "Importing people from #{args[:file_path]}"
    People::Import.new(args[:file_path]).perform
    puts "Done"
  end
end

rake tasks have their benefits, but the argument handling is not like most other unix programs. They are passed as an array at the end of the task name:

bash-5.2$ rake import:people[people.csv]
Importing people from people.csv
Done

Even more troubling, is that if you use zsh (and I am!), the [ and ] need to be escaped, or the whole argument to rake quoted:

$ rake import:people\[people.csv\]

# OR

rake "import:people[people.csv]"

Rails runner

You can use rails runner to run any ruby file in the context of the rails application:

# import.rb

puts "Importing people from #{ARGV.first}"
People::Import.new(ARGV.first).perform
puts "Done"

And run it by passing your file as the first argument:

$ rails runner import.rb people.csv

But you can also use rails runner as a shebang line.

#!/usr/bin/env rails runner
# bin/import
puts "Importing people from #{ARGV.first}"
People::Import.new(ARGV.first).perform
puts "Done"

And now you can invoke that directly:

$ chmod +x bin/import

$ bin/import people.csv

The shebang line allows your script to be directly executable. Now, you can make it more ergonomic, and build up a unix-like command:

#!/usr/bin/env rails runner
# bin/import

options = {}
OptionParser.new do |parser|
  parser.banner = "Usage: rails runner example.rb [options]"

  parser.on("-f", "--file FILE", "Import from FILE") do |file|
    options[:file] = file
  end

  parser.on("-h", "--help", "Prints this help") do
    puts parser
    exit
  end
end.tap(&:parse!)

puts "Importing people from #{options[:file]}"
# ...

$ bin/import --file people.csv
# ...

$ bin/import -h
Usage: rails runner example.rb [options]
    -f, --file FILE                  Import from FILE
    -h, --help                       Prints this help

Conclusion

Using rails runner as a shebang allows full access to the Rails environment in your script, without having to sacrifice command-line ergonomics.