Minor Content Updates for 2023

I've done a review of the entire book and this PR includes a series of minor changes for (mostly) non-technical things that have changed over time.

* Change from master to main (the repo has already been changed)
* Fix a few minor typos and spelling mistakes
* Use gender-neutral terms
* Use more up to date terminology
* Update for Rails being more than 15 years old
* Updates for the book now being freely available and the GitHub repo being public
* Minor wording changes for the book to be present tense instead of future tense

LATESTRELEASE.md

@@ -2,14 +2,14 @@
 
 The quickest way to start reading right now is to view the PDF version here:
 
-<https://github.com/thoughtbot/ruby-science/raw/master/release/ruby-science.pdf>
+<https://github.com/thoughtbot/ruby-science/raw/main/release/ruby-science.pdf>
 
 _Ruby Science_ is currently available in the following formats:
 
-* PDF: [release/ruby-science.pdf](https://github.com/thoughtbot/ruby-science/raw/master/release/ruby-science.pdf)
-* Single-page HTML: [release/ruby-science.html](https://github.com/thoughtbot/ruby-science/raw/master/release/ruby-science.html)
-* Epub (iPad, Nook): [release/ruby-science.epub](https://github.com/thoughtbot/ruby-science/raw/master/release/ruby-science.epub)
-* Mobi (Kindle): [release/ruby-science.mobi](https://github.com/thoughtbot/ruby-science/raw/master/release/ruby-science.mobi)
+* PDF: [release/ruby-science.pdf](https://github.com/thoughtbot/ruby-science/raw/main/release/ruby-science.pdf)
+* Single-page HTML: [release/ruby-science.html](https://github.com/thoughtbot/ruby-science/raw/main/release/ruby-science.html)
+* Epub (iPad, Nook): [release/ruby-science.epub](https://github.com/thoughtbot/ruby-science/raw/main/release/ruby-science.epub)
+* Mobi (Kindle): [release/ruby-science.mobi](https://github.com/thoughtbot/ruby-science/raw/main/release/ruby-science.mobi)
 
 For the HTML version, clone the repository and look at the HTML to ensure that images
 and other assets are properly loaded.
@@ -20,4 +20,4 @@ and other assets are properly loaded.
 
 The computer setup and instructions for generating this book can be found here:
 
-<https://github.com/thoughtbot/ruby-science/blob/master/CONTRIBUTING.md>
+<https://github.com/thoughtbot/ruby-science/blob/main/CONTRIBUTING.md>

book/code_smells/case_statement.md

@@ -41,7 +41,7 @@ the type of question.
 \clearpage
 
 Note that many applications replicate the same `case` statement, which is a more
-serious offence. This view duplicates the `case` logic from `Question#summary`,
+serious offense. This view duplicates the `case` logic from `Question#summary`,
 this time in the form of multiple `if` statements:
 
 ` app/views/questions/_question.html.erb@a53319f:5,25

book/code_smells/smells_intro.md

@@ -5,7 +5,7 @@ they are easy to see—sometimes easier than the root cause of a problem.
 
 When you review code, watch for smells. Consider whether refactoring the code to
 remove the smell would result in better code. If you're reviewing a teammate's
-feature branch, share your best refactoring ideas with him or her.
+feature branch, share your best refactoring ideas with them.
 
 Smells are associated with one or more refactorings (example: remove the Long Method
 smell using the Extract Method refactoring). Learn these associations in order
@@ -24,7 +24,7 @@ other smells slip through the cracks without extra help.
 Duplication is one of the hardest problems to find by hand. If you're using
 diffs during code reviews, it will be invisible when you copy and paste
 existing methods. The original method will be unchanged and won't show up in the
-diff, so unless the reviewer knows and remembers that the original existed, he or she
+diff, so unless the reviewer knows and remembers that the original existed, they
 won't notice that the copied method isn't just a new addition. Every duplicated
 piece of code is a bug waiting to happen.
 

book/introduction/code_review.md

@@ -15,9 +15,10 @@ features to examine code before you commit. Read more about these features using
 `git help add` and `git help commit`.
 
 If you're working on a team, push your feature branch and invite your teammates
-to review the changes via `git diff origin/master..HEAD`.
+to review the changes via `git diff origin/main..HEAD`.
 
-Team review reveals how understandable code is to someone other than the author. Your team members' understanding now is a good indicator of your understanding
+Team review reveals how understandable code is to someone other than the author.
+Your team members' understanding now is a good indicator of your understanding
 in the future.
 
-However, what should you and your teammates look for during review?
+However, what should you and your teammates look for during review?

book/introduction/example_application.md

@@ -1,10 +1,9 @@
 ## Example Application
 
 This book comes with a bundled example application, which you can find [on
-GitHub]. Make sure that you sign into GitHub before attempting to view example
-application and commit links, or you'll receive a 404 error.
+GitHub].
 
-[on GitHub]:  https://github.com/thoughtbot/ruby-science/tree/master/example_app
+[on GitHub]:  https://github.com/thoughtbot/ruby-science/tree/main/example_app
 
 Most of the code samples included in the book come directly from commits in the
 example application. Several chapters link to the full commits for related
@@ -18,4 +17,4 @@ in the example commits, including tests.
 Make sure to take a look at the application's [README], as it contains a summary
 of the application and instructions for setting it up.
 
-[README]: https://github.com/thoughtbot/ruby-science/blob/master/example_app/README.md
+[README]: https://github.com/thoughtbot/ruby-science/blob/main/example_app/README.md

book/introduction/introduction.md

@@ -1,15 +1,15 @@
 # Introduction
 
-Ruby on Rails is almost a decade old, and its community has developed a number
+Ruby on Rails is more than 15 years old and its community has developed a number
 of principles for building applications that are fast, fun and easy to change:
-Don't repeat yourself, keep your views dumb, keep your controllers skinny, and
-keep business logic in your models. These principles carry most applications to
-their first release or beyond.
+Don't repeat yourself, keep logic out of your views, don't overload your
+controllers, and keep business logic in your models. These principles carry most
+applications to their first release or beyond.
 
 However, these principles only get you so far. After a few releases, most
-applications begin to suffer. Models become fat, classes become few and large,
-tests become slow and changes become painful. In many applications, there
-comes a day when the developers realize that there's no going back; the
+applications begin to suffer. Models become overloaded, classes become few and
+large, tests become slow, and changes become painful. In many applications,
+there comes a day when the developers realize that there's no going back; the
 application is a twisted mess and the only way out is a rewrite or a new job.
 
 Fortunately, it doesn't have to be this way. Developers have been using
@@ -18,5 +18,5 @@ knowledge out there that still applies to developing applications today. We can
 use the lessons learned by these developers to write good Rails applications by
 applying good object-oriented programming.
 
-Ruby Science will outline a process for detecting emerging problems in code and
-will dive into the solutions, old and new.
+Ruby Science outlines a process for detecting emerging problems in code and
+dives into the solutions, old and new.

book/introduction/resistance.md

@@ -16,11 +16,11 @@ Each change should be easy to introduce. If it's not, refactor.
 
 When you are making your changes, you will be in a feature branch. Try to make
 your change without refactoring. If you meet resistance, make a "work in
-progress" commit, check out master and create a new refactoring branch:
+progress" commit, check out main and create a new refactoring branch:
 
     git commit -m 'wip: new feature'
     git push
-    git checkout master
+    git checkout main
     git checkout -b refactoring-for-new-feature
 
 Refactor until you fix the resistance you met on your feature branch. Then

book/principles/composition_over_inheritance.md

@@ -51,7 +51,7 @@ public methods like `body` on the shared class.
 ### Dynamic vs. Static
 
 Although the two implementations are fairly similar, one difference between them
-is that, in the inheritance model, the components are assembled statically. The composition model, on the other hand, assembles the components dynamically.
+is that in the inheritance model the components are assembled statically. The composition model, on the other hand, assembles the components dynamically.
 
 Ruby is not a compiled language and everything is evaluated at run-time, so
 claiming that anything is assembled statically may sound like nonsense.

book/solutions/inline_class.md

@@ -25,14 +25,13 @@ or two consumer classes.
 * Eliminates [feature envy](#feature-envy) when the envied class can be inlined
   into the envious class.
 
-
 ### Example
 
 In our example application, users can create surveys and invite other users to
 answer them. Users are invited by listing email addresses to invite.
 
 Any email addresses that match up with existing users are sent using a private
-message that the user will see the next time he or she signs in. Invitations to
+message that the user will see the next time they sign in. Invitations to
 unrecognized addresses are sent using email messages.
 
 The `Invitation` model delegates to a different strategy class based on whether

book/solutions/introduce_form_object.md

@@ -29,7 +29,7 @@ It performs a number of tasks:
 By introducing a form object, we can move the concerns of data validation,
 invitation creation and notifications to the new model `SurveyInviter`.
 
-Including [ActiveModel::Model](https://github.com/rails/rails/blob/master/activemodel/lib/active_model/model.rb)
+Including [ActiveModel::Model](https://github.com/rails/rails/blob/main/activemodel/lib/active_model/model.rb)
 allows us to leverage the familiar
 [active record validation](http://guides.rubyonrails.org/active_record_validations_callbacks.html)
 syntax.

book/solutions/replace_subclasses_with_strategies.md

@@ -96,7 +96,7 @@ app](https://github.com/thoughtbot/ruby-science/commit/7747366a12b3f6f21d0008063
 
 At this point, we've introduced a parallel inheritance hierarchy. During a
 longer refactor, things may get worse before they get better. This is one of
-several reasons that it's always best to refactor on a branch, separately from
+several reasons that it's always best to refactor in a branch, separately from
 any feature work. We'll make sure that the parallel inheritance hierarchy is
 removed before merging.
 

book/solutions/solutions_intro.md

@@ -1,6 +1,6 @@
 # Solutions
 
-Solutions are changes or refactorings that can fix one or more smell.  Each
+Solutions are changes or refactorings that can fix one or more smell. Each
 solution explains which problems it addresses and potential problems that can be
 introduced, along with the related principles.