name_of_person: a frozen Ruby gem that renders a name in nine forms

One string in, a dozen shapes out

name_of_person is a Ruby gem that presents names of people in full, familiar, abbreviated and initialized forms, without titulation. Its stated scope is narrow and the README says so up front: it is for English-language applications where a basic model of first and last name or names combined is sufficient, and it is not meant to cover all possible naming cases, deal with other languages, or even handle titulations.

The interface is a mixin. A model that has a first_name and a last_name column opts in:

# Relies on Person having a schema with first_name and last_name columns.
class Person < ApplicationRecord
  has_person_name
end

From there, the name object exposes the forms:

person.name.full        # => "David Heinemeier Hansson"
person.name.first       # => "David"
person.name.last        # => "Heinemeier Hansson"
person.name.initials    # => "DHH"
person.name.familiar    # => "David H."
person.name.abbreviated # => "D. Heinemeier Hansson"
person.name.sorted      # => "Heinemeier Hansson, David"
person.name.mentionable # => "davidh"

That list is the whole feature set, and it is worth reading closely because each form encodes a decision. Initials take the first letter of every token, so Heinemeier Hansson contributes two letters. Familiar shortens to the first name and the initial of the last name. Abbreviated does the opposite, keeping the first initial and the full last name. Sorted is the library order used in indexes and citations, with the family name first. Mentionable is a handle-style slug taken from the first and last names.

The gem can also be used without a model, by calling into it directly:

# Use directly
name = NameOfPerson::PersonName.full("David Heinemeier Hansson")
name.first # => "David"

Possessives are the fiddly part

The possessive forms are where the complexity shows, and the reason is that a possessive has to be built from whichever form you are actually using.

person.name.possessive  # => "David Heinemeier Hansson's"
person.name.possessive(:first)  # => "David's"
person.name.possessive(:last)  # => "Hansson's"
person.name.possessive(:initials)  # => "DHH's"
person.name.possessive(:sorted)  # => "Heinemeier Hansson, David's"
person.name.possessive(:abbreviated)  # => "D. Heinemeier Hansson's"

Calling possessive with no argument gives the full form, and the other symbols select the corresponding shape. The sorted case is the interesting one, because the comma placement makes the possessive read differently from the others.

This is the part of the library that a hand-rolled helper usually gets wrong, and it is the clearest argument for using the gem rather than writing your own. A view that wants to say David's Team, the DHH Foundation or Heinemeier Hansson's company has three different shapes to build, and each has the apostrophe in a different place.

The scope of that support is exactly the forms listed. There is no irregular plural handling, no locale awareness, and the README's own framing is that this is the basics. For an English-language application that stores names as a single string, that covers the common cases.

Installation inside and outside Rails

The gem goes into a Gemfile the usual way:

# Gemfile
gem 'name_of_person'

And if you use it outside Rails, there is one extra step. The README says that if you are using this outside of Rails, you should make sure ActiveRecord and ActiveModel are manually required:

require 'active_record'
# and/or
require 'active_model'

The and/or is meaningful rather than decorative. The library sits on ActiveModel for the mixin behaviour and on ActiveRecord for the persistence side, so a plain Ruby script that only wants to format a name may need one and not the other, while a Rails application gets both for free through the framework.

The repository is minimal in the way a mature small gem tends to be. The top level holds a Gemfile, a Gemfile.lock, an MIT-LICENSE, the README, a Rakefile, the name_of_person.gemspec, a lib directory and a test directory. There is no CI configuration, no documentation site and no changelog, which is consistent with a project that has stopped moving.

The last release was v1.1.3 on 2024-01-30, and the last push to the repository was on 2026-06-23. The gem is MIT licensed.

The gem is frozen and says so

The README has a section titled No further development is going to happen, and the paragraph under it is unusually blunt. The gem is described as essentially frozen, because the developers have decided to only deal with full names going forward in their applications. It then invites you to fork the work, brand it under a new name and continue development.

That is a more useful statement than a deprecation notice, because it tells you what the maintainers think of the problem. Their applications have moved on to models with structured name data, which is what the mixin's own comment implies, since it says the schema needs first_name and last_name columns. A gem that parses a display string into parts is a stopgap for a codebase that has not yet normalised its data, and Basecamp appears to have normalised theirs.

There is a real design consequence for an adopter. If your data model also keeps a single full name column, the gem gives you instant consistency. If you are part way through normalising, the gem will become redundant exactly when you finish, and the migration will mean replacing calls like name.familiar with something derived from the structured fields. Forking, as the README suggests, is a reasonable way to keep the formatting logic while you migrate.

The test directory in the repository is the practical thing to look at before you depend on it, since the behaviour you are relying on is the behaviour the tests pin down.

What the name model deliberately leaves out

The README is explicit that the approach is not meant to cover all possible naming cases, other languages, or titulations, and those exclusions are where the complexity of names actually lives.

A name with a title, a suffix, a two-word family name, a particle surname or a hyphenated given name will not be handled by a token split. The initials form, which takes the first letter of each token, produces a different result for Heinemeier Hansson than for a person whose family name genuinely has two words, and there is no way to tell the difference from the string alone. A person with a two-word given name gets two initials in the middle rather than one, and the abbreviated form puts its period after the first token regardless.

For an English-language application where a first name and one or more last name tokens are the norm, that is fine. For a product with international users, it is a limitation you would be encoding into your data, not merely a display quirk, because the parse result is what you would store and reuse.

The mentionable form deserves a separate word. It is a handle-style slug derived from the first and last names, which is convenient, but it is a derivation, not a unique identifier, and two people named David Heinemeier Hansson would produce the same one. If you are using it as a key rather than as a display default, that is a decision to make deliberately.

Where name_of_person is the wrong choice

The first and most common reason to skip it is that you do not need it. If your model already stores first_name and last_name as separate columns, which is what the mixin's own precondition says, then the parsing step is unnecessary and you can format directly from the fields. The gem exists to serve the case where the name is one string, and a lot of applications that reach for it have already solved that problem.

The second is the freeze. A gem that will not receive changes is a fine dependency for a display helper and a poor one for anything load-bearing, because a bug found in it will not be fixed upstream and a security or correctness issue has no release to wait for. Forking costs you a maintenance burden that is invisible until someone has to maintain the fork.

The third is scope against need. If your users include people with compound surnames, particle names, multiple given names or non-English naming conventions, the string-splitting model will produce results that look plausible and are wrong, and the cost of discovering that is in production rather than in review. Structured name fields with an explicit representation of each part are more work up front and correct by construction.

What this gem still does well is narrow and real: one place that decides what David Heinemeier Hansson looks like in a list, in a byline, in a mention and in a possessive, with the edge cases tested in one repository. If that is your problem, it solves it in a few lines, and the fact that the maintainers froze it rather than breaking it means the behaviour you depend on today will not change under you.

Editorial conclusion

name_of_person fits a Rails application that stores a full name in one column and needs it displayed in several shapes across a user interface, and that would rather have one tested implementation than a name parsing helper copied between views. It does not fit a project with structured first and last name columns already, a product that needs titles, suffixes or multi-part family names handled by locale, or anyone expecting the library to be maintained. Before depending on it, read the examples to see whether the token split matches the names your users actually have, remember that outside Rails you must require ActiveRecord and ActiveModel yourself, and plan on vendoring or forking rather than waiting for changes, since the README states that no further development is going to happen.

Frequently asked questions

Official sources

1. basecamp/name_of_person on GitHub
2. Issues
3. License: MIT
4. README
5. Releases