Highlight some code-blocks with 'console' label
Update the dracula theme styles to make 'console' highlighting more legible
This commit is contained in:
parent
791cd692c6
commit
449a41aa85
@ -25,7 +25,7 @@ System.no_halt(true)
|
|||||||
|
|
||||||
When we run this script with just `elixir` (instead of `iex`), we should still see an interactive IEx session start.
|
When we run this script with just `elixir` (instead of `iex`), we should still see an interactive IEx session start.
|
||||||
|
|
||||||
```bash
|
```console
|
||||||
$ elixir run.exs
|
$ elixir run.exs
|
||||||
Erlang/OTP 26 [erts-14.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]
|
Erlang/OTP 26 [erts-14.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]
|
||||||
|
|
||||||
|
@ -7,14 +7,14 @@ I use Docker mostly when working on software projects and I figured out how to g
|
|||||||
|
|
||||||
1. Start a container with X11 forwarding:
|
1. Start a container with X11 forwarding:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run -it --rm --net=host -e "DISPLAY" -e "NO_AT_BRIDGE=1" \
|
$ docker run -it --rm --net=host -e "DISPLAY" -e "NO_AT_BRIDGE=1" \
|
||||||
-v "$XAUTHORITY:/root/.Xauthority:rw" elixir bash
|
-v "$XAUTHORITY:/root/.Xauthority:rw" elixir bash
|
||||||
```
|
```
|
||||||
|
|
||||||
2. Build ["the recommended minimal PLT for Erlang/OTP"](https://www.erlang.org/doc/apps/dialyzer/dialyzer_chapter#the-persistent-lookup-table):
|
2. Build ["the recommended minimal PLT for Erlang/OTP"](https://www.erlang.org/doc/apps/dialyzer/dialyzer_chapter#the-persistent-lookup-table):
|
||||||
|
|
||||||
```
|
```console
|
||||||
# dialyzer --build_plt --apps erts kernel stdlib mnesia
|
# dialyzer --build_plt --apps erts kernel stdlib mnesia
|
||||||
Creating PLT /root/.cache/erlang/.dialyzer_plt ...
|
Creating PLT /root/.cache/erlang/.dialyzer_plt ...
|
||||||
...
|
...
|
||||||
@ -25,23 +25,25 @@ I use Docker mostly when working on software projects and I figured out how to g
|
|||||||
|
|
||||||
a. From the command line:
|
a. From the command line:
|
||||||
|
|
||||||
# dialyzer --gui
|
```console
|
||||||
|
# dialyzer --gui
|
||||||
|
```
|
||||||
|
|
||||||
b. From inside an IEx session:
|
b. From inside an IEx session:
|
||||||
|
|
||||||
1. Start the Dialyzer application:
|
1. Start the Dialyzer application:
|
||||||
|
|
||||||
```elixir
|
```
|
||||||
iex(1)> Application.load(:dialyzer)
|
iex(1)> Application.load(:dialyzer)
|
||||||
:ok
|
:ok
|
||||||
```
|
```
|
||||||
|
|
||||||
2. Start the Dialyzer GUI:
|
2. Start the Dialyzer GUI:
|
||||||
|
|
||||||
```elixir
|
```
|
||||||
iex(2)> :dialyzer.gui()
|
iex(2)> :dialyzer.gui()
|
||||||
```
|
```
|
||||||
|
|
||||||
You should now see the Dialyzer GUI.
|
You should now see the Dialyzer GUI.
|
||||||
|
|
||||||

|

|
||||||
|
@ -32,7 +32,7 @@ We're going to do this whole thing with containers. That means Docker is all we
|
|||||||
|
|
||||||
We use the `mix new` command to create our Elixir project. If we were using Elixir installed natively on our computer, it would just be the last part, `mix new static_site`. Since we are using Docker, the command looks like this:
|
We use the `mix new` command to create our Elixir project. If we were using Elixir installed natively on our computer, it would just be the last part, `mix new static_site`. Since we are using Docker, the command looks like this:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt -u $(id -u):$(id -u) elixir mix new static_site
|
$ docker run --rm -w /opt -v $PWD:/opt -u $(id -u):$(id -u) elixir mix new static_site
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -64,7 +64,7 @@ That might look a bit overwhelming, so let's explain each part of the command.
|
|||||||
|
|
||||||
After the command finishes, we have a new directory on our filesystem called `static_site`. Let's change into that directory and make sure we can run the tests. We don't care if the files `mix` creates in `_build` are owned by `root`, so we don't bother setting the user and group with the `-u` option when we run the command this time.
|
After the command finishes, we have a new directory on our filesystem called `static_site`. Let's change into that directory and make sure we can run the tests. We don't care if the files `mix` creates in `_build` are owned by `root`, so we don't bother setting the user and group with the `-u` option when we run the command this time.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ cd static_site
|
$ cd static_site
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt elixir mix test
|
$ docker run --rm -w /opt -v $PWD:/opt elixir mix test
|
||||||
```
|
```
|
||||||
@ -112,13 +112,13 @@ end
|
|||||||
|
|
||||||
The easiest way to test our task is to run `mix build` and then inspect the contents of `/public/index.html` with the `cat` command, but `docker run` only accepts a single command. We can combine both into one with `bash -c "mix build && cat /public/index.html"`.
|
The easiest way to test our task is to run `mix build` and then inspect the contents of `/public/index.html` with the `cat` command, but `docker run` only accepts a single command. We can combine both into one with `bash -c "mix build && cat /public/index.html"`.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix build && cat /public/index.html"
|
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix build && cat /public/index.html"
|
||||||
```
|
```
|
||||||
|
|
||||||
If all went well, our output should be:
|
If all went well, our output should be:
|
||||||
|
|
||||||
```
|
```console
|
||||||
running build task
|
running build task
|
||||||
<!DOCTYPE html>
|
<!DOCTYPE html>
|
||||||
<html>
|
<html>
|
||||||
@ -154,7 +154,7 @@ end
|
|||||||
|
|
||||||
We will also have to add a call to `mix deps.get` in our command. Again, we combine the two commands into one with `&&`:
|
We will also have to add a call to `mix deps.get` in our command. Again, we combine the two commands into one with `&&`:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build"
|
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build"
|
||||||
* creating /root/.mix/archives/hex-2.0.6
|
* creating /root/.mix/archives/hex-2.0.6
|
||||||
Resolving Hex dependencies...
|
Resolving Hex dependencies...
|
||||||
@ -176,7 +176,7 @@ There is a problem with this method, however. What if the dependencies are only
|
|||||||
|
|
||||||
We will re-run our command, but we will add a call to `mix deps` to see what dependencies our project builds.
|
We will re-run our command, but we will add a call to `mix deps` to see what dependencies our project builds.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build && mix deps"
|
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build && mix deps"
|
||||||
...
|
...
|
||||||
Compiling 2 files (.ex)
|
Compiling 2 files (.ex)
|
||||||
@ -202,7 +202,7 @@ Our `dev` environment has the dependency we added.
|
|||||||
|
|
||||||
Now, we will run the command again after we set the environment variable `MIX_ENV` to `prod`. We do this with the `-e` option:
|
Now, we will run the command again after we set the environment variable `MIX_ENV` to `prod`. We do this with the `-e` option:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get && mix build && mix deps"
|
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get && mix build && mix deps"
|
||||||
* creating /root/.mix/archives/hex-2.0.6
|
* creating /root/.mix/archives/hex-2.0.6
|
||||||
Resolving Hex dependencies...
|
Resolving Hex dependencies...
|
||||||
@ -223,7 +223,7 @@ running build task
|
|||||||
|
|
||||||
It turns out that `mix deps.get` [has an `--only` option](https://hexdocs.pm/mix/Mix.Tasks.Deps.Get.html) that can be used to fetch dependencies only for a specific environment. We try our command again with that option.
|
It turns out that `mix deps.get` [has an `--only` option](https://hexdocs.pm/mix/Mix.Tasks.Deps.Get.html) that can be used to fetch dependencies only for a specific environment. We try our command again with that option.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get --only prod && mix build && mix deps"
|
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get --only prod && mix build && mix deps"
|
||||||
* creating /root/.mix/archives/hex-2.0.6
|
* creating /root/.mix/archives/hex-2.0.6
|
||||||
All dependencies are up to date
|
All dependencies are up to date
|
||||||
@ -283,13 +283,13 @@ With that complete, we can now build an image.
|
|||||||
|
|
||||||
This first build will not have the `MIX_ENV` variable set, so we expect it to default to `dev` and to find the `plug` dependency installed.
|
This first build will not have the `MIX_ENV` variable set, so we expect it to default to `dev` and to find the `plug` dependency installed.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker build -t hw_dev .
|
$ docker build -t hw_dev .
|
||||||
```
|
```
|
||||||
|
|
||||||
Let's see what dependencies our image contains:
|
Let's see what dependencies our image contains:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm hw_dev mix deps
|
$ docker run --rm hw_dev mix deps
|
||||||
|
|
||||||
* mime 2.0.5 (Hex package) (mix)
|
* mime 2.0.5 (Hex package) (mix)
|
||||||
@ -308,7 +308,7 @@ $ docker run --rm hw_dev mix deps
|
|||||||
|
|
||||||
That looks good. And let's also check that our HTML file was written:
|
That looks good. And let's also check that our HTML file was written:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm hw_dev ls /public
|
$ docker run --rm hw_dev ls /public
|
||||||
index.html
|
index.html
|
||||||
```
|
```
|
||||||
@ -317,20 +317,20 @@ index.html
|
|||||||
|
|
||||||
Excellent. Now let's build a production image. We pass in the value to set for the `MIX_ENV` argument with the `--build-arg` option:
|
Excellent. Now let's build a production image. We pass in the value to set for the `MIX_ENV` argument with the `--build-arg` option:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker build -t hw_prod --build-arg MIX_ENV=prod .
|
$ docker build -t hw_prod --build-arg MIX_ENV=prod .
|
||||||
```
|
```
|
||||||
|
|
||||||
And now we check as before. We have to set `MIX_ENV` in the container if we want our mix command to run in that environment. We do this with the `-e` option.
|
And now we check as before. We have to set `MIX_ENV` in the container if we want our mix command to run in that environment. We do this with the `-e` option.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -e MIX_ENV=prod hw_prod mix deps
|
$ docker run --rm -e MIX_ENV=prod hw_prod mix deps
|
||||||
$
|
$
|
||||||
```
|
```
|
||||||
|
|
||||||
This shows no dependencies, as expected. And check our index.html:
|
This shows no dependencies, as expected. And check our index.html:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm hw_prod ls /public
|
$ docker run --rm hw_prod ls /public
|
||||||
index.html
|
index.html
|
||||||
```
|
```
|
||||||
@ -361,4 +361,4 @@ If we want to make changes, we can commit our updates and push the code to GitHu
|
|||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
Our Elixir-generated HTML file is live and hosted. We have completed our proof of concept. If we wanted to take advantage of DigitalOcean's platform and host an Elixir-generated static website, this is the blueprint we could follow. It's relatively simple if familiar with Docker, and once set up, deploying changes with a `git push` is simply magical. We look forward to using what we have learned in a future project.
|
Our Elixir-generated HTML file is live and hosted. We have completed our proof of concept. If we wanted to take advantage of DigitalOcean's platform and host an Elixir-generated static website, this is the blueprint we could follow. It's relatively simple if familiar with Docker, and once set up, deploying changes with a `git push` is simply magical. We look forward to using what we have learned in a future project.
|
||||||
|
@ -51,7 +51,7 @@ end
|
|||||||
|
|
||||||
Let's try running the test.
|
Let's try running the test.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||||
running build task
|
running build task
|
||||||
...
|
...
|
||||||
@ -197,7 +197,7 @@ File.write("index.html", """
|
|||||||
|
|
||||||
After running the test,
|
After running the test,
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||||
running build task
|
running build task
|
||||||
...
|
...
|
||||||
@ -207,7 +207,7 @@ Finished in 0.02 seconds (0.02s async, 0.00s sync)
|
|||||||
|
|
||||||
we have our test directory, `test/mix/tmp`,
|
we have our test directory, `test/mix/tmp`,
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ find test/mix/tmp
|
$ find test/mix/tmp
|
||||||
test/mix/tmp
|
test/mix/tmp
|
||||||
test/mix/tmp/build
|
test/mix/tmp/build
|
||||||
@ -218,7 +218,7 @@ test/mix/tmp/build/index.html
|
|||||||
|
|
||||||
and our fixture file.
|
and our fixture file.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ cat test/mix/tmp/build/index.html
|
$ cat test/mix/tmp/build/index.html
|
||||||
<!-- Auto-generated fixture -->
|
<!-- Auto-generated fixture -->
|
||||||
<!DOCTYPE html>
|
<!DOCTYPE html>
|
||||||
@ -240,7 +240,7 @@ end)
|
|||||||
|
|
||||||
Now, after we run the tests, all the files and directories created during the test run have been removed.
|
Now, after we run the tests, all the files and directories created during the test run have been removed.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ find test/mix/tmp/
|
$ find test/mix/tmp/
|
||||||
find: ‘test/mix/tmp/’: No such file or directory
|
find: ‘test/mix/tmp/’: No such file or directory
|
||||||
```
|
```
|
||||||
@ -258,7 +258,7 @@ capture_io(fn -> Mix.Tasks.Build.run([]) end)
|
|||||||
|
|
||||||
When we run our tests now, there are no more IO messages cluttering up the test results.
|
When we run our tests now, there are no more IO messages cluttering up the test results.
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||||
...
|
...
|
||||||
Finished in 0.02 seconds (0.02s async, 0.00s sync)
|
Finished in 0.02 seconds (0.02s async, 0.00s sync)
|
||||||
@ -319,4 +319,4 @@ end
|
|||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
This test seemed trivial at first, but increased in complexity quickly. We had to set some of our configuration in application environment variables, change the configuration temporarily before a test run and then change it back after, clean up test artifacts after the run, and capture IO messages that were generated during it. That's enough going on that we thought it would be a good topic for a post. Cheers and happy coding!
|
This test seemed trivial at first, but increased in complexity quickly. We had to set some of our configuration in application environment variables, change the configuration temporarily before a test run and then change it back after, clean up test artifacts after the run, and capture IO messages that were generated during it. That's enough going on that we thought it would be a good topic for a post. Cheers and happy coding!
|
||||||
|
@ -29,8 +29,11 @@ span.linenos.special { color: #50fa7b; background-color: #6272a4; padding-left:
|
|||||||
.highlight .py-gr { color: #f8f8f2 } /* Generic.Error */
|
.highlight .py-gr { color: #f8f8f2 } /* Generic.Error */
|
||||||
.highlight .py-gh { color: #f8f8f2; font-weight: bold } /* Generic.Heading */
|
.highlight .py-gh { color: #f8f8f2; font-weight: bold } /* Generic.Heading */
|
||||||
.highlight .py-gi { color: #f8f8f2; font-weight: bold } /* Generic.Inserted */
|
.highlight .py-gi { color: #f8f8f2; font-weight: bold } /* Generic.Inserted */
|
||||||
.highlight .py-go { color: #44475a } /* Generic.Output */
|
/*.highlight .py-go { color: #44475a } /* Generic.Output */
|
||||||
.highlight .py-gp { color: #f8f8f2 } /* Generic.Prompt */
|
/*.highlight .py-go { color: #6272a4; } /* Generic.Output */
|
||||||
|
.highlight .py-go { color: #f8f8f2 } /* Generic.Output */
|
||||||
|
/*.highlight .py-gp { color: #f8f8f2 } /* Generic.Prompt */
|
||||||
|
.highlight .py-gp { color: #50fa7b } /* Generic.Prompt */
|
||||||
.highlight .py-gs { color: #f8f8f2 } /* Generic.Strong */
|
.highlight .py-gs { color: #f8f8f2 } /* Generic.Strong */
|
||||||
.highlight .py-gu { color: #f8f8f2; font-weight: bold } /* Generic.Subheading */
|
.highlight .py-gu { color: #f8f8f2; font-weight: bold } /* Generic.Subheading */
|
||||||
.highlight .py-gt { color: #f8f8f2 } /* Generic.Traceback */
|
.highlight .py-gt { color: #f8f8f2 } /* Generic.Traceback */
|
||||||
|
Loading…
x
Reference in New Issue
Block a user