Fix DEV mode in all caps

quarkusio · Jun 4, 2024 · 93bab3f · 93bab3f
1 parent bc0655b
commit 93bab3f
Show file tree

Hide file tree

Showing 3 changed files with 4 additions and 4 deletions.
diff --git a/docs/src/main/asciidoc/databases-dev-services.adoc b/docs/src/main/asciidoc/databases-dev-services.adoc
@@ -166,7 +166,7 @@ quarkus.datasource.db-kind=mysql
 quarkus.datasource.devservices.volumes."/local/test/data"=/var/lib/mysql
 ----
 
-When starting Dev Services (for example, in tests or in DEV mode), you will see that the folder "/local/test/data" will be created at your file sytem and that will contain all the database data. When rerunning again the same dev services, this data will contain all the data you might have created beforehand.
+When starting Dev Services (for example, in tests or in dev mode), you will see that the folder "/local/test/data" will be created at your file sytem and that will contain all the database data. When rerunning again the same dev services, this data will contain all the data you might have created beforehand.
 
 [IMPORTANT]
 ====

diff --git a/docs/src/main/asciidoc/native-and-ssl.adoc b/docs/src/main/asciidoc/native-and-ssl.adoc
@@ -233,7 +233,7 @@ However, this comes with a few drawbacks:
 
  * If you use the same executable in all environments, and a certificate expires, the application needs to be rebuilt, and redeployed into production with the new certificate, which is an inconvenience.
  * Even worse, if a certificate gets revoked because of a security breach, all applications that embed this certificate need to be rebuilt and redeployed in a timely manner.
- * This requires also to add into the application all certificates for all environments (e.g. DEV, TEST, PROD), which means that a certificate that is required for DEV but should not be used elsewhere, will make its way anyway in production.
+ * This requires also to add into the application all certificates for all environments (e.g. `dev`, `test`, `prod`), which means that a certificate that is required for dev mode but should not be used elsewhere, will make its way anyway in production.
  * Providing all certificates at build time complicates the CI, specifically in dynamic environments such as Kubernetes where valid certificates are provided by the platform in the `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` PEM file.
  * Lastly, this does not play well with third party software that do not provide a dedicated build for each customer environment.
 

diff --git a/docs/src/main/asciidoc/security-webauthn.adoc b/docs/src/main/asciidoc/security-webauthn.adoc
@@ -67,8 +67,8 @@ Just in case you get there wondering what's the relation with https://fidoallian
 and whether we support it: sure, yes, PassKeys is a way that your authenticator devices can share and sync 
 their credentials, which you can then use with our WebAuthn authentication.
 
-NOTE: The WebAuthn specification requires `https` to be used for communication with the server, though
-some browsers allow `localhost`. If you must use `https` in `DEV` mode, you can always use the
+NOTE: The WebAuthn specification requires HTTPS to be used for communication with the server, though
+some browsers allow `localhost`. If you must use HTTPS in dev mode, you can always use the
 https://docs.quarkiverse.io/quarkus-ngrok/dev/index.html[quarkus-ngrok] extension.
 
 == Architecture