Fix endless list of typos in the docs

blackfireio · Jun 7, 2024 · 5899b35 · 5899b35
1 parent 0759b5f
commit 5899b35
Show file tree

Hide file tree

Showing 32 changed files with 43 additions and 43 deletions.
diff --git a/builds-cookbooks/builds-webhook.rst b/builds-cookbooks/builds-webhook.rst
@@ -17,7 +17,7 @@ For instance, you can:
 
 * Configure your continuous integration tooling to automatically test any branch
   you deployed on your testing environment (e.g. with a pull-request from
-  Github). You can then decide if the code is ready to be merged.
+  GitHub). You can then decide if the code is ready to be merged.
 
 .. _build-webhook-tokens:
 

diff --git a/continuous-profiling-cookbooks/go.rst b/continuous-profiling-cookbooks/go.rst
@@ -1,7 +1,7 @@
 Configuring Blackfire Continuous Profiler for Go [level: Production]
 =====================================================================
 
-The GO continuous profiling is currently made accross 6 dimensions:
+The GO continuous profiling is currently made across 6 dimensions:
 
 - **Allocations**: Number of objects allocated
 

diff --git a/continuous-profiling-cookbooks/index.rst b/continuous-profiling-cookbooks/index.rst
@@ -93,8 +93,8 @@ minus the combined total values of its direct children.
     :align: center
     :alt: Continuous profiling table view
 
-Read More on Continous Profiling
----------------------------------
+Read More on Continuous Profiling
+----------------------------------
 
 .. toctree::
     :maxdepth: 2

diff --git a/continuous-profiling-cookbooks/nodejs.rst b/continuous-profiling-cookbooks/nodejs.rst
@@ -1,7 +1,7 @@
 Configuring Blackfire Continuous Profiler for Node.js [level: Production]
 =========================================================================
 
-The Node.js continuous profiling is currently made accross 2 dimensions:
+The Node.js continuous profiling is currently made across 2 dimensions:
 
 - **wall-time**: elapsed time per function call
 

diff --git a/continuous-profiling-cookbooks/php.rst b/continuous-profiling-cookbooks/php.rst
@@ -1,7 +1,7 @@
 Configuring Blackfire Continuous Profiler for PHP [level: Production]
 ======================================================================
 
-The PHP continuous profiling is currently made accross 4 dimensions:
+The PHP continuous profiling is currently made across 4 dimensions:
 
 - **CPU Time**: time spent running on the CPU
 

diff --git a/continuous-profiling-cookbooks/python.rst b/continuous-profiling-cookbooks/python.rst
@@ -1,7 +1,7 @@
 Configuring Blackfire Continuous Profiler for Python [level: Production]
 =========================================================================
 
-The Python continuous profiling is currently made accross 5 dimensions:
+The Python continuous profiling is currently made across 5 dimensions:
 
 - **CPU Time**: time spent running on the CPU
 

diff --git a/continuous-profiling-cookbooks/understanding.rst b/continuous-profiling-cookbooks/understanding.rst
@@ -34,8 +34,8 @@ provides all the details on the differences and complementarity between
 Blackfire's monitoring :term:`traces <Trace>`,
 :term:`extended traces <Extended Trace>`, and :term:`profiles <Profile>`.
 
-Continuous Profiling: Probabilitic observability
-_________________________________________________
+Continuous Profiling: Probabilistic observability
+__________________________________________________
 
 **Probabilistic profiling** involves capturing data intermittently. It collects
 information at defined intervals, logging functions or services activated by any

diff --git a/go/continuous-profiling.rst b/go/continuous-profiling.rst
@@ -3,4 +3,4 @@
 Go Continuous Profiler
 =======================
 
-:doc:`Link to the Go Continous Profiler documentation </continuous-profiling-cookbooks/go>`.
+:doc:`Link to the Go Continuous Profiler documentation </continuous-profiling-cookbooks/go>`.
diff --git a/integrations/git/github.rst b/integrations/git/github.rst
@@ -30,7 +30,7 @@ The expected workflow is as follows:
 .. tip::
 
     Some PaaS, like :doc:`Platform.sh </integrations/paas/platformsh>` have
-    built-in support for automatically deploying Pull Requests and triggerring
+    built-in support for automatically deploying Pull Requests and triggering
     Blackfire scenarios.
 
 If your toolchain enables you to deploy your code automatically for each new Pull

diff --git a/integrations/paas/adobe-commerce-cloud.rst b/integrations/paas/adobe-commerce-cloud.rst
@@ -61,7 +61,7 @@ scenarios will be run for all your pull-requests.
 Git integration [level: Production]
 -----------------------------------
 
-If you are using Github, Bitbucket, or Gitlab, and if you have setup the
+If you are using GitHub, Bitbucket, or Gitlab, and if you have setup the
 synchronization with Adobe Commerce Cloud, don't forget to configure the
 :doc:`corresponding notification channel </integrations/git/index>`. That
 way, Blackfire can update the status of your pull-requests / merge-requests.

diff --git a/integrations/paas/ddev.rst b/integrations/paas/ddev.rst
@@ -43,7 +43,7 @@ To activate Blackfire after every ``ddev restart``, run the following command:
 
     ddev blackfire
 
-To activate Blackfire every time your project starts, in the ``.ddev/confiy.yml``
+To activate Blackfire every time your project starts, in the ``.ddev/config.yml``
 file of your DDEV project, define a custom `hook <https://ddev.readthedocs.io/en/stable/users/configuration/hooks/>`_
 similar to:
 

diff --git a/monitoring-cookbooks/configuration.rst b/monitoring-cookbooks/configuration.rst
@@ -76,7 +76,7 @@ With the Extended Sample Rate, you can balance:
 - the possibility for you to collect in-depth performance metrics with
   "real-world" context.
 
-.. _monitoring_span_treshold:
+.. _monitoring_span_threshold:
 
 .. note::
 

diff --git a/monitoring-cookbooks/filtering-transactions.rst b/monitoring-cookbooks/filtering-transactions.rst
@@ -19,7 +19,7 @@ Top Transactions
 .. image:: ../images/monitoring/top_transactions.gif
 
 The Monitoring Dashboard displays the list of top transactions for the selected
-timeframe. This list is primarly sorted by impact, representing the percentage
+timeframe. This list is primarily sorted by impact, representing the percentage
 of time spent processing one transaction versus all the other ones.
 
 A best practice is to optimize high impact transactions first.

diff --git a/nodejs/continuous-profiling.rst b/nodejs/continuous-profiling.rst
@@ -3,4 +3,4 @@
 Node.js Continuous Profiler
 ============================
 
-:doc:`Link to the Node.js Continous Profiler documentation </continuous-profiling-cookbooks/nodejs>`.
+:doc:`Link to the Node.js Continuous Profiler documentation </continuous-profiling-cookbooks/nodejs>`.
diff --git a/php/integrations/sdk.rst b/php/integrations/sdk.rst
@@ -118,7 +118,7 @@ This class gives you the possibility to:
 
         /**
          * Creates a sub-query string to create a new profile linked to the current one.
-         * Generated query must be set in the X-Blackire-Query HTTP header or in the BLACKFIRE_QUERY environment variable.
+         * Generated query must be set in the X-Blackfire-Query HTTP header or in the BLACKFIRE_QUERY environment variable.
          *
          * @return string|null The sub-query or null if profiling is disabled.
          */
@@ -193,7 +193,7 @@ your code:
 
     $blackfire = new \Blackfire\Client();
 
-    // false here means that we want to instrument the code ourself
+    // false here means that we want to instrument the code ourselves
     $probe = $blackfire->createProbe(null, false);
 
     // some code that won't be instrumented
@@ -506,7 +506,7 @@ Using builds and scenarios has the following benefits:
 * A scenario consolidates tests results and generates a :ref:`Report <build-report>`
 
 * A build consolidates **scenarios results** and **sends notifications**
-  (Github, Slack, ...);
+  (GitHub, Slack, ...);
 
 * A build contains **all profiles from a profiling session** (individual profiles
   are not displayed in the dashboard anymore);
@@ -555,7 +555,7 @@ UUID). Optionally pass an array of options:
 
 * ``external_id``: A unique identifier for the build; commonly, a unique
   reference from a third party service like the Git commit sha1 related to the
-  build. It is used by some notifications (like Github);
+  build. It is used by some notifications (like GitHub);
 
 * ``external_parent_id``: The unique identifier of the parent build.
 

diff --git a/php/integrations/symfony/functional-tests.rst b/php/integrations/symfony/functional-tests.rst
@@ -314,7 +314,7 @@ The ``BlackfireTestCaseTrait`` leverages the ``setUpBeforeClass()`` and
 ``tearDownAfterClass()`` methods from the base PHPUnit ``TestCase`` class.
 
 If you already use them within a test case that you want to use with Blackfire,
-the scenario auto-start will not work, as the mentioned methods will be overriden
+the scenario auto-start will not work, as the mentioned methods will be overridden
 by the ones defined in your test case class.
 
 In this case, you need to :ref:`create the scenarios manually

diff --git a/php/training-resources/book/04-first-profile.rst b/php/training-resources/book/04-first-profile.rst
@@ -237,7 +237,7 @@ the implementation of ``countRecentCommentsForUser()``:
     }
 
 Apparently, we are getting and hydrating all the comments a user made only to
-count the most recent ones iterating over them. This is quite an unefficient way
+count the most recent ones iterating over them. This is quite an inefficient way
 of achieving our goal.
 
 To refactor this, we can add a method in the ``CommentRepository`` class,

diff --git a/php/training-resources/book/05-validating-performance-optimizations.rst b/php/training-resources/book/05-validating-performance-optimizations.rst
@@ -274,7 +274,7 @@ not just the wall time.
 Profiling Again
 ---------------
 
-57% improvement on the Fiding Bigfoot sighting page is impressive, but can we do
+57% improvement on the Finding Bigfoot sighting page is impressive, but can we do
 better? Profiling is a never-ending process. Whenever you fix a bug or add a
 new feature, you need to check the performance impact of that change.
 
@@ -366,7 +366,7 @@ of association the ``BigFootSighting`` entity has with the ``Comment`` one. Doct
 has `an EXTRA_LAZY association <https://www.doctrine-project.org/projects/doctrine-orm/en/2.13/tutorials/extra-lazy-associations.html>`_
 type which allows counting the collection without having to fully load its members.
 
-Let's refactor the ``BigFootSignthing`` Entity accordingly:
+Let's refactor the ``BigFootSighting`` Entity accordingly:
 
 .. code-block:: diff
 

diff --git a/...resources/book/12-tests-best-pratices.rst → ...esources/book/12-tests-best-practices.rst b/...resources/book/12-tests-best-pratices.rst → ...esources/book/12-tests-best-practices.rst
diff --git a/php/training-resources/book/15-unit-tests.rst b/php/training-resources/book/15-unit-tests.rst
@@ -25,7 +25,7 @@ covering the output of the method:
 But how can we test a SQL query is only executed the very first time
 ``getUserActivityText()`` is called for a specific ``User``?
 
-Have a look at the contructor and ``calculateUserActivityText()`` method
+Have a look at the constructor and ``calculateUserActivityText()`` method
 implementation and note the usage of the
 ``Symfony\Contracts\Cache\CacheInterface`` class:
 

diff --git a/php/training-resources/book/18-player.rst b/php/training-resources/book/18-player.rst
@@ -103,7 +103,7 @@ Running Assertions [level: Development/Production]
 In addition to expectations, the player can also generate profiles and run
 assertions defined in the ``.blackfire.yaml`` file. Let's begin by
 :ref:`removing time-based assertions <forget-about-time>` in the file defined
-:ref:`previoulsy <final-blackfire-yaml>`:
+:ref:`previously <final-blackfire-yaml>`:
 
 .. code-block:: yaml
 

diff --git a/php/training-resources/book/index.rst b/php/training-resources/book/index.rst
@@ -24,7 +24,7 @@ Ready? Start reading `chapter 1 » <01-introduction>`_.
     09-call-graphs-galore
     10-environments
     11-writing-assertions
-    12-tests-best-pratices
+    12-tests-best-practices
     13-code-behavior
     14-consumers-daemons
     15-unit-tests

diff --git a/profiling-cookbooks/understanding-http-requests.rst b/profiling-cookbooks/understanding-http-requests.rst
@@ -46,11 +46,11 @@ The Metadata may contain:
     host (or proxy) was completed. When a redirect is followed, the time from
     each request is added together;
 
-  * Pre-Transfert Time: time from the request start until the file transfer is
+  * Pre-Transfer Time: time from the request start until the file transfer is
     about to begin. When a redirect is followed, the time from each request is
     added together;
 
-  * Start-Transfert Time: time from the request start until the first byte is
+  * Start-Transfer Time: time from the request start until the first byte is
     received. When a redirect is followed, the time from each request is
     added together;
 

diff --git a/python/integrations/wsgi.rst b/python/integrations/wsgi.rst
@@ -47,7 +47,7 @@ A ``get_view_name`` method must be defined to have the requests of your WSGI-bas
 application be instrumented by :doc:`Blackfire Monitoring</monitoring-cookbooks/index>`.
 
 This function is required only for the monitoring of your application. Its
-definition can be omited if you are not considering it.
+definition can be omitted if you are not considering it.
 
 The ``get_view_name`` method retrieves the view name executing or handling the
 HTTP request. Blackfire Monitoring relies on this information to :doc:`group
@@ -81,7 +81,7 @@ Builds [level: Production]
 A ``build_blackfire_yml_response`` method must be defined to be able to use
 :doc:`Blackfire Builds</builds-cookbooks/index>`.
 
-This function is required only by Blackfire Build. Its definition can be omited if
+This function is required only by Blackfire Build. Its definition can be omitted if
 you are not considering the Synthetic Monitoring of your application.
 
 This function is called to handle Blackfire builds. When a build ``POST``
@@ -105,10 +105,10 @@ The function receives 4 parameters:
 The ``build_blackfire_yml_response`` function should return a framework specific
 HTTP response.
 
-In the example below, the function returns an instance of ``werkzeug.wrappers.Reponse``.
+In the example below, the function returns an instance of ``werkzeug.wrappers.Response``.
 
 In the `Django middleware <https://github.com/blackfireio/blackfire.io/blob/master/languages/python/src/sdk/hooks/django/middleware.py>`_,
-it returns an instance of ``django.http.HttpResonse``.
+it returns an instance of ``django.http.HttpResponse``.
 
 .. code-block:: python
 

diff --git a/recommendations/php/emails-should-be-sent-asynchronously-during-a-web-request.rst b/recommendations/php/emails-should-be-sent-asynchronously-during-a-web-request.rst
@@ -36,7 +36,7 @@ emails. Read the `How to Spool Emails`_ tutorial in the Symfony documentation to
 learn more about this command.
 
 In Laravel applications this technique is called *"queueing mail"*. First you
-must configure a queue and then use the ``queue()`` method of the ``Mail`` façade:
+must configure a queue and then use the ``queue()`` method of the ``Mail`` facade:
 
 .. code-block:: php
 

diff --git a/recommendations/php/opcache-validate-timestamps-should-be-enabled.rst b/recommendations/php/opcache-validate-timestamps-should-be-enabled.rst
@@ -6,7 +6,7 @@ While it may seem counter intuitive to enable the
 through PHP's realpath cache. This means that the check is usually really fast as
 it doesn't hit the (slow) file system.
 
-By enabling this setting, your PHP engine behaves in a more predictible way, and
+By enabling this setting, your PHP engine behaves in a more predictable way, and
 allows enabling the `opcache.enable_file_override`_ ini setting.
 
 .. _`opcache.validate_timestamps`: https://www.php.net/manual/opcache.configuration.php#ini.opcache.validate-timestamps

diff --git a/recommendations/php/the-magento-1-block-html-cache-should-be-enabled.rst b/recommendations/php/the-magento-1-block-html-cache-should-be-enabled.rst
@@ -10,7 +10,7 @@ includes tens of layout files for its themes, modules and components.
 
 Rendering all the blocks included in a page consumes lots of resources.
 For that reason, Magento includes a special cache to store the
-processed blocks. Some blocks are cachable, some are not.
+processed blocks. Some blocks are cacheable, some are not.
 
 It is highly recommended to enable the cache of these blocks to improve the
 page rendering performance.

diff --git a/recommendations/php/the-magento-2-block-html-cache-should-be-enabled.rst b/recommendations/php/the-magento-2-block-html-cache-should-be-enabled.rst
@@ -10,7 +10,7 @@ includes tens of layout files for its themes, modules and components.
 
 Rendering all the blocks included in a page consumes lots of resources.
 For that reason, Magento includes a special cache to store the
-processed blocks. Some blocks are cachable, some are not.
+processed blocks. Some blocks are cacheable, some are not.
 
 It is highly recommended to enable the cache of these blocks to improve the
 page rendering performance.

diff --git a/recommendations/python/django-cached-sessions-should-be-enabled-on-production.rst b/recommendations/python/django-cached-sessions-should-be-enabled-on-production.rst
@@ -4,8 +4,8 @@ Django Cached Sessions Should Be Enabled On Production
 Using a cache-based session backend improves performance so it is advised to use
 cached sessions on production.
 
-A local-memory cache backend doesn't retain data long enough to be a good choice 
-for caching session. More details on selecting appropiate cache backend for 
+A local-memory cache backend doesn't retain data long enough to be a good choice
+for caching session. More details on selecting appropriate cache backend for
 sessions can be found in `Using cached sessions`_ documentation.
 
 See `Deployment Checklist for sessions`_ for more details.

diff --git a/testing-cookbooks/assertions.rst b/testing-cookbooks/assertions.rst
@@ -31,7 +31,7 @@ explicitly to override default units <units>`.
 
     Whenever possible, **we recommend you write assertions that do not
     depend on time**. The main reason is that :doc:`time is always a consequence
-    </php/training-resources/book/12-tests-best-pratices>`, a symptom of a deeper issue.
+    </php/training-resources/book/12-tests-best-practices>`, a symptom of a deeper issue.
 
 Comparison Assertions
 ---------------------
@@ -197,7 +197,7 @@ Assertions' Description
 -----------------------
 
 An optional description can be added to an assertion. This could provide a
-context or an educational note left for the other delevopers of your team.
+context or an educational note left for the other developers of your team.
 
 This note can help understand the
 performance challenges of some parts of the application.

diff --git a/up-and-running/agent-upgrade.rst b/up-and-running/agent-upgrade.rst
@@ -37,7 +37,7 @@ Docker
 ------
 
 We provide a new ``2`` tag for the ``blackfire/blackfire`` Docker image that
-points to the lastest version of the image.
+points to the latest version of the image.
 
 There is also a ``1`` tag alongside the existing ``latest`` tag that points to
 the previous version of the image for backward compatibility.

diff --git a/up-and-running/reverse-proxies.rst b/up-and-running/reverse-proxies.rst
@@ -20,7 +20,7 @@ HTTP Headers
 
 In order to successfully profile your application, several HTTP headers are
 processed by the client. These headers are required to pass through to and
-from your application (and the Blacfkire probe).
+from your application (and the Blackfire probe).
 
 Request Headers
 ~~~~~~~~~~~~~~~