From 5899b351acc1c5fc6f02885ddc855a3e1a3f291a Mon Sep 17 00:00:00 2001 From: Thomas di Luccio Date: Fri, 7 Jun 2024 07:23:36 +0000 Subject: [PATCH] Fix endless list of typos in the docs --- builds-cookbooks/builds-webhook.rst | 2 +- continuous-profiling-cookbooks/go.rst | 2 +- continuous-profiling-cookbooks/index.rst | 4 ++-- continuous-profiling-cookbooks/nodejs.rst | 2 +- continuous-profiling-cookbooks/php.rst | 2 +- continuous-profiling-cookbooks/python.rst | 2 +- continuous-profiling-cookbooks/understanding.rst | 4 ++-- go/continuous-profiling.rst | 2 +- integrations/git/github.rst | 2 +- integrations/paas/adobe-commerce-cloud.rst | 2 +- integrations/paas/ddev.rst | 2 +- monitoring-cookbooks/configuration.rst | 2 +- monitoring-cookbooks/filtering-transactions.rst | 2 +- nodejs/continuous-profiling.rst | 2 +- php/integrations/sdk.rst | 8 ++++---- php/integrations/symfony/functional-tests.rst | 2 +- php/training-resources/book/04-first-profile.rst | 2 +- .../book/05-validating-performance-optimizations.rst | 4 ++-- ...ests-best-pratices.rst => 12-tests-best-practices.rst} | 0 php/training-resources/book/15-unit-tests.rst | 2 +- php/training-resources/book/18-player.rst | 2 +- php/training-resources/book/index.rst | 2 +- profiling-cookbooks/understanding-http-requests.rst | 4 ++-- python/integrations/wsgi.rst | 8 ++++---- ...should-be-sent-asynchronously-during-a-web-request.rst | 2 +- .../php/opcache-validate-timestamps-should-be-enabled.rst | 2 +- .../the-magento-1-block-html-cache-should-be-enabled.rst | 2 +- .../the-magento-2-block-html-cache-should-be-enabled.rst | 2 +- ...go-cached-sessions-should-be-enabled-on-production.rst | 4 ++-- testing-cookbooks/assertions.rst | 4 ++-- up-and-running/agent-upgrade.rst | 2 +- up-and-running/reverse-proxies.rst | 2 +- 32 files changed, 43 insertions(+), 43 deletions(-) rename php/training-resources/book/{12-tests-best-pratices.rst => 12-tests-best-practices.rst} (100%) diff --git a/builds-cookbooks/builds-webhook.rst b/builds-cookbooks/builds-webhook.rst index 25badc4..146357d 100644 --- 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 index 36ac070..acc083c 100644 --- 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 index 83f3010..1f2ac03 100644 --- 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 index 03c6286..01b1c4e 100644 --- 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 index 381c688..3e15249 100644 --- 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 index c141d55..24f45d5 100644 --- 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 index 4fd5a95..0a98a7b 100644 --- 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 `, :term:`extended traces `, and :term:`profiles `. -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 index 3ebbcf7..616ab64 100644 --- 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 `. +:doc:`Link to the Go Continuous Profiler documentation `. diff --git a/integrations/git/github.rst b/integrations/git/github.rst index 0b3dbc0..e20a602 100644 --- 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 ` 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 index 8fd099c..a320c3b 100644 --- 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 `. 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 index a7eda6a..d097e35 100644 --- 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 `_ similar to: diff --git a/monitoring-cookbooks/configuration.rst b/monitoring-cookbooks/configuration.rst index b9ca922..7338a56 100644 --- 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 index 55d7492..8064b5d 100644 --- 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 index ebc94a6..4ff5787 100644 --- 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 `. +:doc:`Link to the Node.js Continuous Profiler documentation `. diff --git a/php/integrations/sdk.rst b/php/integrations/sdk.rst index 87a89d1..10e3c7a 100644 --- 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 ` * 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 index 66a9c22..45dfcee 100644 --- 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 index 5d0d07f..30f7a27 100644 --- 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 index eec633e..a643948 100644 --- 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 `_ 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/php/training-resources/book/12-tests-best-pratices.rst b/php/training-resources/book/12-tests-best-practices.rst similarity index 100% rename from php/training-resources/book/12-tests-best-pratices.rst rename to php/training-resources/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 index bc2b122..6ea39b4 100644 --- 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 index 9d0a6f4..c399ae7 100644 --- 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 ` in the file defined -:ref:`previoulsy `: +:ref:`previously `: .. code-block:: yaml diff --git a/php/training-resources/book/index.rst b/php/training-resources/book/index.rst index 1a0a147..9aab9a7 100644 --- 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 index a302fdd..f589d2c 100644 --- 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 index 7417fc6..1d76dd4 100644 --- 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`. 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`. -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 `_, -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 index 73e9f87..7f1e083 100644 --- 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 index c1b5104..bba6305 100644 --- 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 index 9fa66b7..aed0e8d 100644 --- 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 index 916bace..5501110 100644 --- 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 index 6a61fef..8f2430c 100644 --- 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 index ffdc481..0380731 100644 --- a/testing-cookbooks/assertions.rst +++ b/testing-cookbooks/assertions.rst @@ -31,7 +31,7 @@ explicitly to override default 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 - `, a symptom of a deeper issue. + `, 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 index 4b5a116..c3efee8 100644 --- 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 index 0bb8355..8597420 100644 --- 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 ~~~~~~~~~~~~~~~