Thanks. I bought your book since the B1.0 version and I recommend it.

Awesome, thanks for plugging this here! Exactly the kind of material I was looking for :)

It's also an extra point of failure, an extra account to manage, etc. I have seen plenty of low-traffic Rails (and other) apps where neither hosting cost nor performance would be significantly improved by adding a CDN.

I'll add cache invalidation to the list of reasons not to use a CDN. Its a solvable problem, but I've more than once seen irritating issues caused by something getting cached in the CDN layer and loading the wrong resources.

Or simpler, why do you need a CDN? It's rarely worth the additional work (setup + deployment) when most websites are not limited by bandwidth for assets.

If the boolean values are not 50%/50% but skewed like 1%/99% then there can be a big advantage in using a partial index

CREATE INDEX index_accounts_balance ON accounts (id) WHERE boolean_flag;

I like how the PostgreSQL docs use the term “profitable” for whether an index helps.

The purpose of the index often is to lower the “cost” (greater profit), by providing more values the query is accessing (filtering, ordering, selecting) within the index entries, for faster retrieval.

When users have the skills to generate query plans and review whether an index supports a query, verifying that the index is picked by the planner, and indeed lowers the cost, then they can answer this question for their own unique combination of hardware, data distribution, queries, and indexes.

As generic advice, I think more often than not the index won’t be used for Boolean columns. But it’s generic advice and it does depend.

As you suggested, users must check their own system.

My book also covers the 2 and 3 value variations (nulls allowed) for Boolean columns.

For readers wanting to build these skills themselves, here’s more info:

https://news.ycombinator.com/item?id=38407585

Good nudge that it depends!

This got me to take a look at the Rails site and go through the Getting Started tutorial. It's really well-written and is probably amongst the best documentation I've seen out there. I would love to do more projects in Rails now.

This particular is easy to pick up and remember.

Also, a proficient developer looks at the SQL logs anyway as they develop a given feature.

Rails' flavor of ORM is particularly composable and transparent - you can easily mix/match it with vanilla SQL.

I tend to agree as a SQL enthusiast. However I have yet to see a Rails team that doesn’t use Active Record or writes much SQL directly, or by default, across 100s of apps. I’m sure it happens but in my experience it’s rare.

This is a place where I think tools like Rubocop help. They can be configured to point out method swaps like this (size over count) automatically which is a relatively low effort task to change the code.

With those rules/linting in place, you aren’t throwing out the benefits of AR (ORM), and hopefully leveraging their useful methods like these that help avoid unnecessary queries.

Please, please don't mix up ORMs with ActiveRecords. ActiveRecords are one way to implement an ORM, but it's not the only way. I think many say they hate ORMs when they actually mean ActiveRecords. For bigger projects ActiveRecords suck, yes. But also you need to have some database layer logic which most likely does some Object & Relation Mapping (ORM).

I don't want to live in a world where I can't pop into a Rails console and run something like `Foo.joins(:bars).any?`.

More concretely, performance is on my list of "good problems to have". Businesses die in the time it takes to write raw SQL.

That's correct. If i run `User.limit(5).pluck(:id)` the query it runs is `SELECT "users"."id" FROM "users" LIMIT $1 [["LIMIT", 5]]` and returns an array, not an ActiveRecord association

Looks completely fine and legible. Maybe something is wrong with your settings or screen?