Dependencies

First off, we'll want to add :ex_doc to our dependencies. This is the library we'll be using to build our docs.

mix.exs

  defp deps do
    [
      ...
      {:ex_doc, "~> 0.30.5"},
      ...
    ]

Configuration

We'll need to generate a key pair in order to allow our repo to update its documentation branch. To do this, we can run an ssh-keygen.

Note: Remember to change the name of the id_rsa file name so that it does not overwrite an existing key pair. In this example, I used id_rsa_gh_pages as the name

> ssh-keygen

Generating public/private rsa key pair.  
Enter file in which to save the key:  id_rsa_gh_pages  

Next, let's create a Deploy Key on our repo. Copy the output of the public key.

> cat id_rsa_gh_pages.pub
# (copy output)

Navigate to Settings > Deploy keys on the repo and click Add deploy key. Paste the public key in and give it a name (something like DOCS_DEPLOY_PUBKEY will do).

Then, we'll have to add the secret key as a repository secret so that our workflow can access it. Copy the output of the private key. Do not share this key with anyone

> cat id_rsa_gh_pages
# (copy output)

Now, navigate to Settings > Secrets and variables > Actions and click New repository secret. Paste the secret key into the box and name it DOCS_DEPLOY_KEY. We'll access this secret from inside our workflow.

Once we're finished with the public/private rsa keys, we can delete them.

rm id_rsa_gh_pages.pub id_rsa_gh_pages  

GitHub Workflow

This example assumes we're using .tool-versions to manage versions for elixir and erlang. erlef/setup-beam reads the .tool-versions file to install the correct versions before running

I've taken the liberty to add a caveat in for building docs on the elixir-docs branch as well as main. That way, we can test changest to the documentation build without having to merge with main - just push these changes to the elixir-docs branch and submit a PR later.

Once the beam environment is set up, lee-dohm/generate-elixir-docs runs and generates our docs.
peaceiris/actions-gh-pages then publishes our documentation to the gh-pages branch of our project using the DOCS_DEPLOY_KEY we provided as a GitHub Secret earlier.

.github/workflows/main.yml

  ...

  elixir_docs:
    if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/elixir-docs' }}
    name: Generate project documentation
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3.5.3
      - name: Sets up an Erlang/OTP environment
        uses: erlef/setup-beam@v1
        with:
          version-file: .tool-versions
          version-type: strict
      - name: Build docs
        uses: lee-dohm/generate-elixir-docs@v1.0.1
      - name: Publish to Pages
        uses: peaceiris/actions-gh-pages@v3.9.3
        with:
          deploy_key: ${{ secrets.DOCS_DEPLOY_KEY }}
          publish_dir: ./doc
          publish_branch: gh-pages

  ...

Run the workflow and make sure it succeeds. Once it's done, our documentation should be available on the gh-pages branch.

GitHub Pages

Now that our workflow is publishing docs to the gh-pages branch, let's go ahead and configure our repo to host our Pages site...

Navigate to Settings > Pages and select Deploy from a branch under Source. Under Branch, make sure gh-pages is selected and the directory is / (root). Hit Save and it should publish the page - by default, the url will be https://[username].github.io/[project]

Make it accessible

Now comes the fun part. We can include the link to our documentation in our README.md and a link or badge - or use the project's About section to display the link.

About section

Navigate to the project's home page and find the About section (on the right side of the page). Click the gear icon and under the Website section, tick the box next to Use your GitHub Pages website.

Wrapping it up

In this tutorial, we set up our GitHub repo to host Elixir docs for our project. There are tons of extra settings we can use to fine tune our deployed docs - including setting a custom URL for our documentation.

Hopefully, this guide had enough information to get you started. Have a look around at GitHub's documentation for your specific application, and don't be afraid to leave a comment :)

When I joined the team, we didn't have a formal revision style, and thus had a lot of trouble collaborating. It was so bad at one point that one of my teammates took all of my commits in a pull request and squashed them down without asking me first; in the process, erasing loads of detail in why I did things a certain way and how I managed to fix bugs or overcome obstacles.

I believe the commit history is an extremely powerful tool in a small development team’s arsenal for tracing and fixing bugs. I use it on a daily basis to compensate for our propensity to occasionally make short-sighted decisions; after all developers are only human, we are far from perfect. I like to get things right the first time as much as possible but overall, it’s much better to make a mistake and go back and fix it than to have fear of mistakes be a limiting factor on progress.

Due to the fact that the “squasher” teammate was the project lead, I went along with his direction for a while. After he left the company, I took charge and switched the team over to using a Pull Request and Merge based collaboration style. My intent was to preserve the commit history and to preserve the information contained in the branches between commits. I explained how branching would encourage us to work on features as units and lead to a more readable history than squash and rebase. I personally even use sub-branches, since I work best by breaking down tasks into the smallest units possible, and I merge them back into my own branch as I complete a feature. I’ve heard that Gerrit has the ability to squash and rebase while maintaining commit history, but I haven’t tried it out yet. It might be something worth looking into if the scope of work relates to how developers collaborate.

I’m always on the lookout for best practices and I love sharing what I find with my team. At the beginning of my DevOps experience, I discovered Heroku’s 12-Factor best practices and have been sticking to them ever since; making sure that all of the projects I work on are easily and dependably deployable. Any time I'm setting up ops for a new project, I re-visit the manifesto.

Epochtalk was the first project I converted to comply with 12-Factor. From consolidating configuration files and routines, to containerizing all the pieces, exposing configurations through the environment, locking down specific dependency versions, implementing automated versioning for internal dependencies, learning about linked containers and debugging their connections, automating builds in CI for testing and deployment, persisting data across restarts, unifying testing staging and production environments to ensure consistency, exposing administration functionality through cli, the list goes on and on.

In the end, it was not such an easy task, but each project since then has gone a lot smoother; especially now that I’ve established some good standards. Each conversion step has its own challenges, and Epochtalk's case required restructuring the project as a whole, touching nearly every file. However, as the Factors were put to work, the project started feeling a lot more polished for deployment - and promoted better development practices as well!

Once all of the pieces were using containers and container networking instead of bare metal deploys, the next step was to create a SAAS deployment strategy. I tried using Kubernetes, but it was still in its early stages of development (they were not directly associated with Docker yet) and documentation was a bit lacking at the time. I contacted Kubernetes’ dev team and joined their Slack, but it was a big headache and in the end I decided that I should build with Ansible instead.

Through some good old shell scripting, and a lot of trial and error, I was able to write playbooks to provision AWS resources (EC2, S3, Route53, RDS, CloudWatch), configure new virtual machines, and run our Dockerized project - all using customer information to create deployment namespaces and DNS entries. It was a bit of a clunky implementation, but it got the job done. On the bright side, I learned a lot about what it takes to get a production deployment up and running.
Additionally, having done all of this through scripting, I feel like I have a deeper understanding of how it all works. I am, however, very much looking forward to using more standardized tools like Kubernetes and Terraform.

Automation is at the core of good testing. If tests aren’t automatic, they are not going to get run. The way I’ve set up all of the projects I’ve had a hand in at our company is to add testing to the Continuous Integration pipeline. Whether it’s as simple as making sure everything compiles and the bare server code runs properly, or API tests that ensure expected input and output are achieved, to simulated browser tests with tools like Selenium, all of these get run every single time someone submits code to a branch. Branches are blocked from being merged until all tests have passed and the code has undergone peer review.

One thing that I wish I had done earlier, but haven’t been able to get around to for Epochtalk is documentation-based API tests. Since we’ve got documentation generators based on code comments, it would be really nice to have a hard, almost mathematical, link from what API docs say the API call will do and what it actually does. The overall idea there is to minimize chances for human error to cause a discrepancy between. In any case where a human error can be made, that’s a potential for a bug to be generated and that in turn is a potential for hours to be spent fixing instead of implementing.

QA

I haven’t worked on a team that uses a formal QA process for a while, but from what I remember from my previous job, the QA team does the hard work of making sure everything works as it’s supposed to. It was a lot of repetitive tasks and generating “bad input”, which is part of the bug spotting process. If we can give the QA team a way to generate input, whether it’s algorithmically or through templating, it reduces wear-and-tear on them and gives them a way to consistently do a good job and find new bugs quicker. The overarching idea here is that tests are hard to write as an afterthought, but an entire suite of them is easy to obtain if they’re written in tandem with development. When I was assigned to write tests for an existing untested monolithic project at my previous job, it was such a daunting task - not an experience I’d recommend!

Cooperation between QA and developers is difficult to achieve. There can be a lot of friction due to the fact that QA might think developers are incompetent because of the errant dumb mistakes we can make, and similarly, developers might think QA is incompetent because they might lack the technical expertise required to explain an issue well. One solution I can think of to aid in the cycle between QA and developers is to allow QA to create behavior driven tests. If they find a bug and create a test for it that assumes it’s fixed, they can then push that branch as a “fix” branch. That branch containing the test can only be merged once the tests pass and the bug is fixed. That doesn’t quite solve the mutually implied incompetence issue, but it does give both of them common ground to work off of.

Triage

How does triage work? It’s at the intersection of testing and QA, and it’s a problem that every dev team has. What do we fix first? How do we tell what’s the most important and what can be worked on later? What about all of these less important tasks that have been lying around for months? As a developer on an open source project using open source technologies, I’ve seen so many different solutions. One team in particular caught my eye; they immediately closed all submitted issues (strange to me, as it reduces visibility, but understandable) and had a voting system for closed issues that would tally up how many people had the issue. They would use the voting information to decide on task importance, and whether to work on them or not.

I’ve used so many triage/tasking tools in my career including Jira (plus Atlassian suite), Kanban, Clickup, GitHub Issues and a plethora of others I can’t even recall at this point. My favorite for our small team so far has been Kanban. I liked the style of tasks with columns and no hard deadlines. It gave me a sense of satisfaction to be able to drag a task over to the next column and watch it go from in-queue to in progress to review and finally completed. I personally believe that deadlines stunt creative growth and stifle innovation by restricting perspective and reducing an individual’s propensity to be intrinsically motivated.

In terms of intrinsic motivation, I want to add a little piece of opinion; food for thought perhaps… I’ll tie it back in to triage at the end:

Supervisors and managers tend to get in that position by being micromanagers. Being able to demand set deadlines for a feature or bug fix is of utmost importance to them, even when those tasks are not critically important. They see micromanaging as being productive and helping, but it can have quite the opposite effect. My ideal strategy, aligning with best practices of the new era of creatives, involves nurturing people's intrinsic motivation to maximize their potential for creative solutions.

This means relaxing supervision and looking at the results rather than the progress; a bit like the analogy of watching a pot of water boil. If you hire diligent, creative people who enjoy what they do, the job will get done; and if you want solid results, take care of them and they’ll take care of you. Psychologists and business analysts have all but proved it time and time again, the new workforce is about creativity and not labor. You can make a laborer work faster by “whipping” them for slow progress or rewarding them for good results, but you can’t make someone think harder or be more artistic by doing the same thing. If you’ve ever tried to force yourself to think, you'll know that it doesn’t work that way.

To tie it back in, I’ll talk about my experiences with task delegation and deadlines, which are key vulnerabilities to micromanagement. It’s my opinion that, if a feature or bug is not important or blocking, it can wait a while. I’m not claiming that this is correct, but I think it is a key factor in reaching a team’s full potential. With task picking, developers can choose what to do. When we’re allowed to work on what we feel is important, we can put more dedication into it. Speaking from a small team perspective, when tasks and deadlines are dictated by someone who lacks a perspective of the overall picture, that can greatly reduce motivation to get things done. I’ve been forcefully moved from critically important tasks to ones that should have taken a back seat, and the effect is so jarring.

The pinnacle of triage to me, to be philosophical for a bit, is the ability to let go. Some tasks are simply not worth doing; they will take much more time and effort than they will return in terms of benefit. Talking to friends in the medical field, in a dire situation the goal is to save as many people as possible, but also to prioritize those who can be saved. As much as it hurts to say “no” to a task, sometimes it’s the right call. Of course, medical situations and software development differ in urgency, so it follows that the perspective shifts accordingly.

Communication and understanding are key; to make the right decisions, we need the big picture as well as the small details. The overall point I’m trying to make is that there is no one solution to triage. It’s a constant effort of balance and rebalance, and the team has to work together on it. Those who understand this and are able to communicate well with all parties involved should be the ones making the call on what to do next.

Of course, you can create a cron job to schedule automatic renewal of certificates, but what if you also want to run Certbot's Docker container and use a web server like Nginx in Docker as well?

I've come up with a scheme that will incorporate all of these features, and I've packaged them into a format that allows anyone on my team to deploy Certbot for *any web service!

(*Updates will be made to handle services that don't fit well into the scheme.)

The Premise

The previous examples I've seen that use Certbot and Docker are a bit kludgy to say the least. The most useful one I've read was by @pentacent on Medium: Nginx and Let’s Encrypt with Docker in Less Than 5 Minutes

I had an idea to improve on this scheme. One of the major pain points with automating Certbot's HTTP-01 in tandem with Nginx is that Nginx needs to host the challenge file, but the certificates specified in its config must exist in order Nginx to even start. @pentacent's solution was to create fake certificates, start Nginx, delete the fake certs, then get real ones with Certbot.

Basically, this strategy ended up hinging on executing a script that does all of this for you. This is, of course, all good - presuming that everything works; but I wondered if I could omit the script step altogether? An interesting challenge.

My solution was to create two Dockerfiles and run one initially with Nginx set up to only host the /.well-known/acme_challenge file. Once that was done, I could theoretically add anything else to the Nginx config after the fact, as long as the containers all mount the same directory that holds the certificates.

Implementing the solution

As mentioned, I created two separate Dockerfiles to solve this issue. The two are nearly identical, except that the first runs certbot certonly and the other runs certbot renew. Additionally, for convenience, I created two sets of nginx/conf.d directories to mount. They can technically use the same directories, but I also checked in the Nginx configurations for different projects into their respective branches. By keeping a /init-data/nginx/conf.d separately, I can leave just the webroot configuration (acme_challenge) while having any additional configurations checked in to the repo under /data/nginx/conf.d.

Certbot will request certificates and store them in a mounted directory, which is read by the Nginx machine. Once the entire system is up and running, you can just call docker-compose up certbot-renew again at any time to update the certs.

Instead of changing the entrypoint script for the Certbot container, I added a crontab generator that starts up the stopped certbot-renew container, which runs again and checks if any certificates need to be renewed. This ensures that the container only runs when it needs to; a good way to improve efficiency. Once the renew script completes, the next step in the crontab script is to restart Nginx service (to reload with new certs).

To make use of all of this, the end user (whomever is setting up a new web server) pulls my base project, writes an Nginx config in the /data/nginx/conf.d directory, and modifies the docker-compose.yml file to include their project, making sure to add a depends_on line to the Nginx docker-compose spec to make sure their container is linked properly. This way, we can refer to the new service by name in places like the Nginx configuration.

Once that's done, they start the services with docker-compose up -d and execute the crontab generator.

Caveats of interest

Mounting /etc/nginx/conf.d

Why mount only the /etc/nginx/conf.d directory for Nginx and not the entire /etc/nginx directory? The reason is actually not very apparent; it deals with how Docker handles mounted directories. If something is already there, it doesn't get deleted, it just gets hidden under the new mount (ie, it exists, but is inaccessible to the filesystem). This is good because you can recover what was there before, but it's also not quite intuitive...

If you expected Nginx to work when mounting /etc/nginx and adding your own files, you'll find that there are a bunch of files missing! These files were previously in /etc/nginx but were hidden when you told Docker to mount. Luckily, the installed configuration for Nginx's Docker image includes all configurations in /etc/nginx/conf.d! Therefore, you can safely mount conf.d and add all of your custom configurations there :)

Restarting Nginx

My implementation restarts the entire Nginx container using a docker-compose command. Why not just restart the service inside the container? This one's pretty simple!

When the Nginx container starts, its entrypoint is the Nginx server command itself. If that command finishes (in this case, it is terminated in order to do the restart), then Docker will consider the task "complete" and terminate the container. Because of this a service restart will end up in container termination! Better to just use docker-compose to restart the container in the first place ;]

These notes will probably be most helpful for anyone getting started with implementing distributed systems using Elixir. If you have questions or opinions as well as fixes I should include, please leave a comment below!

Supervision

• Hex docs: Task

  • Good for running some code that doesn't need supervision

  • Tasks generally don't interact with other processes, and we don't care about the return value

• Hex docs: Task.Supervisor

  • Dynamically supervise Tasks

  • Good for keeping a handle on running a Task without orphaning it (<- my opinion)

• Hex docs: Supervisor

  • Good for supervision of known processes (created at server start)

  • Children are defined in the code and started when Supervisor.start_link is called

  • Not conventional for supervising processes created at runtime (deprecated in favor of Dynamic Supervisor)

• Hex docs: Dynamic Supervisor

  • Good for supervising processes started at runtime

  • Starts with no children, and spawns new children with DynamicSupervisor.start_child

  • Note that children should have unique identifiers (:name) - see Process Registration section

Process Registration

• Name Registration (via GenServer)

  • Used by Supervisor, Dynamic Supervisor, GenServer

  • __MODULE__ uses this module's own name

    • Can only have one instance registered when using __MODULE__

  • :(atom) registers via Process.register with the atom as the name

    • Again, you can only have one instance registered since the name is not unique

  • {:global, term} registers via "the functions in the :global module", where term can be basically anything

    • Register any number of processes!

    • Find processes by name using GenServer.whereis

    • Must define the names such that they don't collide

  • {:via, module, term} use a custom module to define a registry. Explained well in Brian Storti's Blog on Process Registry

• Hex docs: Registry

  • Registry module

• Custom Process Registry (blog; Brian Storti)

  • Custom local implementation using a Map in the registry's state

• gproc

  • Noted in Brian Storti blog; uses "central server and an ordered-set ets table"

• Elixir forum: Agent vs Registry

Distributed Supervision/Registration

Horde (medium@derek.kraan2)

The Premise

I recently ran into a situation where I used a GenServer to prototype some functionality before implementing it in a larger project. It worked excellently and implementing the server (which handles and stores the state of TCP connections, and accepts GenServer calls - note on call/cast) went without a hitch. Great!

However, when I went to back integrate this feature, there was a bit of an issue. Instead of
implementing a GenServer, the original code uses a listen loop to spawn TCP socket-handling functions and hands them off to a Task Supervisor.

At this point, my approach is to just implement calls in the original code and modify the internals to match the desired behaviour. However, my coworker was bothered by this, as there's a difference between Task Supervisor and GenServer. His idea was that we should implement the manager from scratch using GenServer, but is that the best way to do it? Maybe. I'm not really sure yet. I'll be updating this document to reflect what I learn. You better hope OP delivers!

Call/Cast notes

As far as I have seen, the general consensus is that you should start by using call and only use cast after careful algorithmic analysis, and if you're sure it's the right choice. Check out this great Medium article by @adammokan for a better explanation.

(Tags: GenServer, Gen Server, Task.Supervisor, Task Supervisor, Elixir, Erlang)

We've all been there! What's your favorite just developer thing?

If I think of more, I'll try to remember to write them here :D

Onion is a paradise built from ruin. A combination bakery and cafe that has taken what appears to be a rundown house or apartment building, and freshened it up just a bit with enough decor to give it a comfortable feeling.

The architectural designer has ingeniously converted the space into a brightly lit coffee shop and bakery by removing the doors and shutters from the walls and windows; letting in as much natural light as possible.

An (easily) acquired taste

The shop appears to be a bit unkempt at first sight, but as you spend your time lounging here, you start to realize how amazing it really is. The owners have kept the original parts of the building, choosing to blend the furniture and decor in with the existing crumbling bits of brick, cement block, and reinforcement. Dirty, broken walls and windows become the perfect backdrop for photos that will cause your Instagram followers to practically ooze jealousy.

The building’s various stairways lead to the second floor, where you can find an open air upper deck with a fairly decent view of the area. It’s by no means the tallest building in the area, so you won’t be able to see too far. Right now, the sky is clear and bright, the birds are chirping, the sunlight is warm, and the breeze is cool. You couldn’t ask for much more in a spot to have a pastry and a spot of espresso… except that all the electrical outlets are indoors.

Heading inside, the space is a bit of a labyrinth - but excitingly so. Upon turning each corner, you’re greeted by views of other patrons; sometimes through glass windows, sometimes through just a hole in the wall. Wherever you decide to sit inside, there are outlets in the center of just about every table. However, most of the seats are pretty uncomfortable if you’re looking to do several hours of work on a laptop. My recommendation? If you’re planning to be here for a while, set yourself up next to the seat you think would be the most comfortable to lounge at, because that spot is most likely taken. When the current occupants get up and go, swoop in for the prize and feast on the succulent view of envious faces as they watch you scoop it up.

The foyer out back neatly tucks away a long community table; accompanied by a few small trees and crumbling bits of brick that must have been part of the old building there. The interior of the connecting room, separated by a giant pane glass window, contains a similarly shaped table, giving it the appearance of extending out from the room into the foyer outside, and providing an ultra spacious feel.

I can’t stress enough how well the original materials fit into the theme of the shop itself. It’s as if you are a part of the bakery, frozen in time to allow you to sit, dine, and get some work done. In my honest opinion, it’s #rusticAF.

And the food?...

The pastries from the bakery are amazing, and the coffee is, well, coffee. Enough said. I don’t drink a latte and I usually end up getting an espresso everywhere I go, so I wouldn’t trust myself with reviewing the frothier drinks. I decided on the avocado toasted bread and some kind of powdered sugar mountain that I saw everyone else walking around with. They were both excellent, and both very messy. To be considerate, I ate outside before heading in to work. The birds were in a veritable frenzy due to the continuous eruption of crumbs as I struggled to cut the delicious confections with my plastic fork and knife. Anyhow, I’m sure you’ll enjoy whatever you end up choosing to get here.

Cozy, at twilight

That’s about it for now. Come here, get some cafe food goodness, and get some work done. I promise it will be worthwhile.

Here is an interesting tidbit about your local Git repo. You can push to it and pull/fetch from it. Anything you can do with a remote repo, you can do it with your local repo.

How do I do this?

Just specify . where you would normally specify a remote repo.

git push origin [local src]:[dest] would push your local branch at local src to the remote origin branch dest.

git push . [local src]:[local dest] would "push" your local branch at local src to the local branch local dest

Of course, you can replace local src with a commit hash as well...

Why does this matter?

I'm glad you asked. This is actually an incredible resource; for the simple fact that you can push, pull, and fetch branches that you are not currently on. In essence, this allows you to manipulate other branches without checking them out.

If you are like me, and need to update tons of branches while you have uncommitted code (Why though? Because reasons!), being able to do so without changing your current HEAD is a lifesaver. Just imagine you are pushing code to update remote branches, and again, replace the remote name with . and you're good to go!

Who in their right mind would even...?

Actually, if you use Git a lot and become interested in maintaining a good record of the history of code you have written (the lines in your git tree), you'll eventually want to be able to manipulate branches with precision.

If you're juggling changes that aren't checked in or committed, you could use a shit ton of git stash commands - which I have done on many occasions. But that gets pretty messy and you have to mentally keep track of what's going on and where all of your code is. If you can master this paradigm of "local repo as a remote repo", you won't have to dick around with the stash when you want to manipulate other branches. Save stashing for testing code in other branches ;)

# circle.yml
version: 2  
jobs:  
  build:
    ...
    steps:
      ...
      - run:
          name: Start docker resources
          command: |
            set -e
            docker-compose -f circleci-docker-compose.yml up -d (service)
            ...
      - run:
          name: run test
          ...

Here's the problem though: there was a problem happening in one of the services I'm running, but there's no way to debug it the way it is written because I can't see the console output of the docker containers run with the -d option.

At first, I tried creating a log artifact by piping the docker-compose log output to a file, then using - store_artifacts to save those files as CircleCI artifacts. I could see the logs, but it turned out to be a huge pain in the ass to actually view the log files...

To view them, you have to click on the artifacts section in the build summary window and then download the file. This is pretty obscure, and it is also not apparent to someone viewing the output, trying to understand why a test failed.

I fixed this by writing the output of the container log to the console! A much better solution, but I found out about it in a really roundabout way. It turns out that - run steps have an optional field called when, which default to on_success, ensuring that the step is only run if the previous steps succeed. Setting the value to on_fail or always tells Circle to run the step even if previous steps failed. You can use this to output the Docker container logs if the build/test fails:

# circle.yml
version: 2  
jobs:  
  build:
    ...
    steps:
      ...
      - run:
          name: Start docker resources
          command: |
            set -e
            docker-compose -f circleci-docker-compose.yml up -d (service)
            ...
      - run:
          name: run test
          ...
      - run:
          name: "Failure: output container logs to console"
          command: |
            docker-compose -f circleci-docker-compose.yml logs (service)
          when: on_fail

Viola. You can now view the Docker logs in the regular view, making it much simpler to debug.

Overlook falls into a peculiar category of words which already have a name (several actually), but which I will now call ambinyms. These words can have opposite meanings depending on their usage.

Overlook word can mean either to fail to notice something or to have a view of something (from above). This stems mainly from the word over having the usages describing something that is stationed above, as well as something that is passing by above.

For a few more examples and a bit of etymological insight, check out this other blog. In fact, that blog has also listed oversee as an ambinym - a nearly identical word, which still does have different meanings.

Quite peculiar, indeed.

Editing

Raw image

Optimized for Instagram (Increased brightness and color)

35mm Film

Access Denied from url: unenglishable.com. Please use the url configured in config.js

I popped open the Chrome developer console and found that I was getting redirected from www.unenglishable.com to unenglishable.com. My config.js url was set to https://www.unenglishable.com, but my certificate is only valid for unenglishable.com, so Chrome was redirecting to where the certificate was valid for. (I recently switched to Let's Encrypt's SSL service, Certbot)

I fixed this issue by changing my nginx config to point both unencrypted http://www.unenglishable.com and http://unenglishable.com to SSL-encrypted https://unenglishable.com via reverse proxy. I then updated my config.js to have url: 'https://unenglishable.com. With redirect, I can now visit either www or non www and everything works just fine.

Hope this helps!

Resolves:
Access Denied from url: [url]. Please use the url configured in config.js

But what about your local machine!!?!?!? How do we keep the homegrounds nice and clean?

To remove the tracking branches (origin/whatever) after you've merged and deleted them use:
git fetch --prune

This fetching command will get the latest changes from your remote repository, while "pruning" your tree of deleted (origin/whatever) branches.

As for the merged local branches, use:
git diff --merged | grep -v master | xargs git branch -d

This command deletes your local branches that have been merged remotely. The grep -v filters out master so that you don't delete your local master branch if it's up to date with origin/master.

I just deleted about 50 excess branches with those two commands. So, needless to say, these are quite useful for me.

As a caution:

Only use those if your team is okay with deleting unused branches. My team isn't okay with that, but for personal projects, I like to keep my branch count to a minimum.

Cheers!