From bbfa321004a2729ce8fdfa921696f7c8be5b0e20 Mon Sep 17 00:00:00 2001 From: charlotte <71281295+chaarlottte@users.noreply.github.com> Date: Mon, 30 Oct 2023 10:17:09 -0400 Subject: [PATCH] fix: typos in README files --- README.md | 6 +++--- load_tests/README.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index eee431cc..56c6d64c 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ To start your Phoenix app: 4. Optionally install plugins for load testing: - Run `asdf plugin-add python` to add Python plugin - Run `asdf plugin-add poetry` to add Poetry plugin - 4. Run `asdf install` to install plugin versions speicifed in `.tool-versions` file + 4. Run `asdf install` to install plugin versions specified in `.tool-versions` file 2. Install dependencies with `mix deps.get` 3. Setup `apps/api_accounts` following directions in `apps/api_accounts/README.md` (on [GitHub](apps/api_accounts/README.md#setting-up-dynamodb-local) or [ExDoc](api_accounts-readme.html#setting-up-dynamodb-local)) 4. Start Phoenix endpoint with `mix phx.server` @@ -28,7 +28,7 @@ In addition to the Elixir config files, the V3 API allows runtime configuration | `MBTA_GTFS_URL` | `https://cdn.mbta.com/MBTA_GTFS.zip` | URL for the GTFS .zip file. | | `ALERT_URL` | `https://cdn.mbta.com/realtime/Alerts_enhanced.json` | URL for the Alerts. Can be either a JSON or Protobuf file. | `MBTA_TRIP_SOURCE` | `https://cdn.mbta.com/realtime/TripUpdates_enhanced.json` | URL for the TripUpdates. Can be either a JSON or Protobuf file. | -| `MBTA_VEHICLE_SOURCE ` | `https://cdn.mbta.com/realtime/VehiclePositions_enhanced.json` | URL for the VehiclePositions. Can be either a JSON or Protobuf file. | +| `MBTA_VEHICLE_SOURCE` | `https://cdn.mbta.com/realtime/VehiclePositions_enhanced.json` | URL for the VehiclePositions. Can be either a JSON or Protobuf file. | | `FETCH_FILETAP_S3_BUCKET` | undefined | S3 bucket to which we write files we fetched. | ## Documentation @@ -64,4 +64,4 @@ $ mix test --exclude test --include integration The MBTA Customer Technology team is working to transform how people get around the Boston area. We’re a small but mighty team of designers, engineers and content specialists charged with bringing novel ideas, modern standards and a user-centered approach to technology on the T. As the MBTA works to reinvent itself, we have a rare opportunity to shape the future of transportation for Boston and communities all around Eastern Massachusetts, as well as blaze a trail for other transit agencies around the country. -We’re always looking for people to join the team who are passionate about improving the daily transportation experience for our 400 million annual riders. Does this sound like you? Check our our open positions at https://jobs.lever.co/mbta/. +We’re always looking for people to join the team who are passionate about improving the daily transportation experience for our 400 million annual riders. Does this sound like you? Check out our open positions at https://jobs.lever.co/mbta/. diff --git a/load_tests/README.md b/load_tests/README.md index b478f954..58760240 100644 --- a/load_tests/README.md +++ b/load_tests/README.md @@ -31,4 +31,4 @@ A full list of Locust configuration options can be found in the [Locust document ## Caveats -The "tasks" that Locust runs are based on the 25 most frequently run—and most time-intensive to handle—queries on the production API. As such, this configuration is not meant to simulate regular load on the production API application, but is instead designed to generate a relatively high amount of load on in order to test the application's resposiveness and trigger auto scaling events. Whereas the production application can normally handle many hundreds of queries per second, only a few queries from Locust (around 5 per second per application instance) are required to generate a high load on the application. +The "tasks" that Locust runs are based on the 25 most frequently run—and most time-intensive to handle—queries on the production API. As such, this configuration is not meant to simulate regular load on the production API application, but is instead designed to generate a relatively high amount of load on in order to test the application's responsiveness and trigger auto scaling events. Whereas the production application can normally handle many hundreds of queries per second, only a few queries from Locust (around 5 per second per application instance) are required to generate a high load on the application.