Forem: Dropseed

Dynamic page titles in Django

Dave Gaeddert — Mon, 14 Mar 2022 19:57:57 +0000

It's easy to forget about the HTML <title> element when building a Django app.
You put one in your base.html when you start the project,
but forget to actually change the title when making your individual views and templates.

<!doctype html>
<html lang="en">
<head>
    <title>Forge</title>
</head>

But good page titles are incredibly useful!

Forgetting them can hurt both SEO and user experience.

There are two ways we recommend implementing HTML page titles in Django:

Using template blocks (simpler)
Using class-based views (more powerful)

Django page titles using template blocks

Template blocks can be used for small pieces of content just like they can be used for entire headers/bodies/footers.

In your base.html, use a standard template block inside the <title> tag:

<!doctype html>
<html lang="en">
<head>
    <title>{% block title %}{% endblock %}</title>
</head>

When you extend your template,
simply use the {% block title %} to set the page title:

{% extends "base.html" %}

{% block title %}Billing{% endblock %}

{% block content %}
...
{% endblock %}

You can use context variables just like any other template blocks:

{% extends "base.html" %}

{% block title %}{{ obj.name }} billing{% endblock %}

{% block content %}
...
{% endblock %}

That's all there is to it!
If you don't know where to start then give this a try.
But if you find yourself needing more control then consider moving the logic to your Django views instead...

Django page titles using class-based views

In Forge, we strongly prefer class-based views over function-based views.
One reason is because it's much easier to share logic across your views, often across your entire app.
Generating page titles is a good example of how this can be useful.

Let's create a view mixin with a page title feature that injects a title variable into the template context:

class PageTitleViewMixin:
    title = ""

    def get_title(self):
        """
        Return the class title attr by default,
        but you can override this method to further customize
        """
        return self.title

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["title"] = self.get_title()
        return context

Then use {{ title }} in your base.html:

<!doctype html>
<html lang="en">
<head>
    <title>{{ title }}</title>
</head>

By using both a title class attribute and a get_title method,
it will be easy to set a "static" title for a view:

class BillingView(PageTitleViewMixin, TemplateView):
    template_name = "billing.html"
    title = "Billing"

But also do something more dynamic:

class ProjectView(PageTitleViewMixin, DetailView):
    def get_title(self):
        return self.object.name

You could further extend this to add a suffix to the title automatically:

class PageTitleViewMixin:
    ...

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        context["title"] = self.get_title() + " - My App"
        return context

Bonus! You could also raise an exception on empty titles,
so you don't forget to set the title for every view:

class PageTitleViewMixin:
    ...

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)

        title = self.get_title()

        if not title:
            raise ValueError("Page title should not be empty")

        context["title"] = title + " - My App"

        return context

Diagrams for documentation

Dave Gaeddert — Fri, 19 Mar 2021 22:49:42 +0000

Simple flowcharts or drawings are a good way to explain concepts without a ton of words.

Technical documentation is a lot more interesting (and helpful) when you mix in some visuals.

One of my favorite ways to do this is to use Excalidraw.
Excalidraw is an open-source whiteboard that strikes a balance between hand-drawn and professional.

No login required
Limited fonts and colors (a good thing!)
Arrows automatically connect to other elements
Works pretty well on iPad
Drawings can be saved and shared with a link

I used to draw these kinds of things on my iPad, but my handwriting sucks and there aren't very clean ways to save and revise drawings in the future, especially for someone besides myself. Figma is another option here, but for simple diagrams that often gives me too many options which pull me into "high-fidelity" mode and then I get stuck.

The limitations of Excalidraw are a feature, not a bug.

Here's an example that I used on dropseed/deps:

And here it is being used on the README:

The best part? There's a link to the drawing itself, commented out in the markdown:

<!-- Edit in Excalidraw: https://excalidraw.com/#json=6195990008692736,unm4UYeUzdmbXTk_xcvIdQ -->
![deps overview flowchart](https://user-images.githubusercontent.com/649496/111809843-675b1000-88a3-11eb-8b5c-d85d71cb5a25.png)

Anybody can open that Excalidraw link (including me), edit the drawing and contribute a new version to the README. No complicated software or design tools, and limited choices in fonts, colors, and style.

GitHub code review assignment with PullApprove

Dave Gaeddert — Fri, 12 Mar 2021 23:04:43 +0000

GitHub provides some great, basic features around code review assignment and requirements. But if your team needs more options, you don't have to build it yourself.

PullApprove was designed to give you all the flexibility of a custom tool, without the need to build or maintain one. You design your ideal code review process, and we'll do everything else.

Here's an example

Let's say our team wants to do four kinds of code review:

Frontend - anything touching the interface should be reviewed by our "designers who code"
Interns - John manages our interns directly, so we ask him to look over every PR they open
Security - we have a security specialist to pull in as-needed
General - each PR needs to be approved by two people, doesn't matter who

In PullApprove, we would codify these rules into a .pullapprove.yml, which is kept at the top of the repo.

For each type of review, we'll define a new group:

version: 3

groups:
  frontend: ...
  interns: ...
  security: ...
  general: ...

Frontend review

For the frontend group, we want them to review any JS change but we also have a label for when someone is concerned that the frontend might be affected. We can write this out as a "condition":

  frontend:
    conditions:
    - "'*.js' in files or 'frontend-review' in labels"

The frontend is important, so we want two people to get a review request notification and approve each PR (not the entire team):

  frontend:
    conditions:
    - "'*.html' in files or 'frontend-review' in labels"
    reviewers:
      teams: [frontend]
    reviews:
      request: 2
      required: 2
      request_order: random

Interns review

The conditions syntax gives us access to any metadata about the PR, including who authored it. So we'll ask John to review anything the interns open:

  intern:
    conditions:
    - "author in ['internA', 'internB']"
    reviewers:
      users: [john]

Security review

In React, we have some specific red flags we can look for such as dangerouslySetInnerHTML. We'll require a security review if someone adds a line that includes "dangerouslySetInnerHTML" (line starts with a "+" in the git diff).

  security:
    conditions:
    - "contains_regex(files.patches, '(?m)^\+.*dangerouslySetInnerHTML.*')"
    reviewers:
      users: [josh, jeff]
    reviews:
      request: 1
      required: 1

General code review

Finally, we want to make sure that every PR is approved by at least two people.

We'll put the entire company into this group, which means approvals could overlap from the other groups. In some cases we will already have enough approvals from the other groups, but if not then this will ensure someone else is requested.

  general:
    reviewers:
      teams:
      - developers
      - designers
      - admins
    reviews:
      request: 2
      required: 2

Putting it all together

When we're finished, we have a .pullapprove.yml that looks like this:

version: 3

groups:
  frontend:
    conditions:
    - "'*.html' in files or 'frontend-review' in labels"
    reviewers:
      teams: [frontend]
    reviews:
      request: 2
      required: 2
      request_order: random

  intern:
    conditions:
    - "author in ["internA", "internB"]"
    reviewers:
      users: [john]

  security:
    conditions:
    - "contains_regex(files.patches, '(?m)^\+.*dangerouslySetInnerHTML.*')"
    reviewers:
      users: [josh, jeff]
    reviews:
      request: 1
      required: 1

  general:
    reviewers:
      teams:
      - developers
      - designers
      - admins
    reviews:
      request: 2
      required: 2

Now we just need to commit this to the repo and install PullApprove! Review requests will be sent out automatically, and you can set "pullapprove" to be a required status check on the repo. Check out the docs to learn about the other advanced features not shown here.

Quickly changing directories in your terminal

Dave Gaeddert — Wed, 12 Aug 2020 18:46:02 +0000

If you spend a lot of time on the command line, eventually you'll want to know some quick ways to cd around.

There are a lot of tricks and tools you can find, but these are the two I use.

Z - "jump around"

Z is fast, one-character, and becomes second nature.

To use it, type a few characters and it will cd straight to the most "frecent" directory that you use.

~/Development
❯ z pul

~/Development/dropseed/pullapprove master ⇣
❯

Technically this should be a regular expression, and there are more advanced ways to use z, but usually just hitting the first few characters (or the most unique ones) will get you where you intend to go.

An easy way to install it is with Homebrew:

❯ brew install z

Learn more on the GitHub repo →

Aliases for cd

If you're using Bash, there are couple of aliases you can add to your ~/.bashrc to make it easier to navigate back up the directory tree.

alias ..="cd .."
alias ...="cd ../.."
alias ....="cd ../../.."

Now when you need to jump back a directory or two, you can simply do:

~/Development/dropseed/pullapprove master ⇣
❯ ...

~/Development
❯

Instead of:

~/Development/dropseed/pullapprove master ⇣
❯ cd ../..

~/Development
❯

It's a small thing, but when you realize how often you do it, you'll be happy to save the keystrokes.

Note that if you are using zsh, you can get this same functionality by enabling autocd (or using oh-my-zsh).

You can also throw in a few very specific cd aliases. These are two that I use regularly:

alias dl="cd $HOME/Downloads"
alias dev="cd $HOME/Development"