Capitalize framework names [ci-skip]

activejob/lib/active_job/test_helper.rb

@@ -61,7 +61,7 @@ def after_teardown # :nodoc:
     #
     # Note: The adapter provided by this method must provide some additional
     # methods from those expected of a standard ActiveJob::QueueAdapter
-    # in order to be used with the active job test helpers. Refer to
+    # in order to be used with the Active Job test helpers. Refer to
     # ActiveJob::QueueAdapters::TestAdapter.
     def queue_adapter_for_test
       ActiveJob::QueueAdapters::TestAdapter.new

activerecord/lib/active_record/railtie.rb

@@ -401,7 +401,7 @@ class Railtie < Rails::Railtie # :nodoc:
       end
 
       ActiveSupport.on_load(:active_record_fixture_set) do
-        # Encrypt active record fixtures
+        # Encrypt Active Record fixtures
         if ActiveRecord::Encryption.config.encrypt_fixtures
           ActiveRecord::Fixture.prepend ActiveRecord::Encryption::EncryptedFixtures
         end

activesupport/lib/active_support/core_ext/object/json.rb

@@ -29,7 +29,7 @@
 # It should be noted that when using ::JSON.{generate,dump} directly, ActiveSupport's encoder is
 # bypassed completely. This means that as_json won't be invoked and the JSON gem will simply
 # ignore any options it does not natively understand. This also means that ::JSON.{generate,dump}
-# should give exactly the same results with or without active support.
+# should give exactly the same results with or without Active Support.
 
 module ActiveSupport
   module ToJsonWithActiveSupportEncoder # :nodoc:

guides/source/active_record_callbacks.md

@@ -500,7 +500,7 @@ Transaction Callbacks
 
 ### Dealing With Consistency
 
-There are two additional callbacks that are triggered by the completion of a database transaction: [`after_commit`][] and [`after_rollback`][]. These callbacks are very similar to the `after_save` callback except that they don't execute until after database changes have either been committed or rolled back. They are most useful when your active record models need to interact with external systems which are not part of the database transaction.
+There are two additional callbacks that are triggered by the completion of a database transaction: [`after_commit`][] and [`after_rollback`][]. These callbacks are very similar to the `after_save` callback except that they don't execute until after database changes have either been committed or rolled back. They are most useful when your Active Record models need to interact with external systems which are not part of the database transaction.
 
 Consider, for example, the previous example where the `PictureFile` model needs to delete a file after the corresponding record is destroyed. If anything raises an exception after the `after_destroy` callback is called and the transaction rolls back, the file will have been deleted and the model will be left in an inconsistent state. For example, suppose that `picture_file_2` in the code below is not valid and the `save!` method raises an error.