
![Git logo](pexels-realtoughcandy-11035539.jpg)

_Photo by_ [RealToughCandy.com](https://www.pexels.com/@realtoughcandy/) _on_
[pexels.com](https://www.pexels.com/photo/person-holding-a-small-paper-11035539/)

## Table of Contents

-   [Creating a new local Git repository](#creating-a-new-local-git-repository)
    -   [Checking out into new branch called create-config-project-and-users-app](#checking-out-into-new-branch-called-create-config-project-and-users-app)
    -   [Trying to check out into main branch after committing changes in create-config-project-and-users-app](#trying-to-check-out-into-main-branch-after-committing-changes-in-create-config-project-and-users-app)
    -   [Creating a new branch called main in create-config-project-and-users-app and checking out into main all at once](#creating-a-new-branch-called-main-in-create-config-project-and-users-app-and-checking-out-into-main-all-at-once)
    -   [Creating the remote repository on GitHub and add adding remote origin](#creating-the-remote-repository-on-github-and-add-adding-remote-origin)
    -   [Merging create-config-project-and-users-app into main branch and pushing changes to remote origin](#merging-create-config-project-and-users-app-into-main-branch-and-pushing-changes-to-remote-origin)
-   [Conclusion](#conclusion)
-   [Related Resources](#related-resources)
-   [Related Posts](#related-posts)

## Creating a new local Git repository

`Recently`, I `created` a `new` local `Git` repository called
`custom-abstract-base-user-model`. `Then` I `initialized` Git `with` the
`following command`:

```shell
git init
```

### Checking out into new branch called create-config-project-and-users-app

`However`, `instead` of `immediately making` my `first commit` to a
`remote repository` on `GitHub`, I `checked out` into `a` new `branch` called
`create-config-project-and-users-app`:

```shell
git checkout -b create-config-project-and-users-app
```

### Trying to check out into main branch after committing changes in create-config-project-and-users-app

`Then`, after `adding` all the `features` I `wanted` to `add` to that `branch`
and `committing` my `changes`, I `ran` the `following command`:

```shell
git checkout main
```

Which `returned` the `following` in `Terminal`:

```shell
error: pathspec 'main' did not match any file(s) known to git
```

### Creating a new branch called main in create-config-project-and-users-app and checking out into main all at once

I `never` actually `"created"` a `main` branch, `because` I never `committed`
anything. I simply `checked out` into a `new branch`, `and` any `content` I had
`created` in `"main"`, was `checked into` the `new branch` as well. `This` was
`fine`! I `had` to `create` a `main` branch `that` I `could` check `into`, merge
`create-config-project-and-users-app` into `main`, `and` then `push` to
`remote origin` on `GitHub`. To `make` this `happen`, I `ran` the
`following command`:

```shell
git checkout -b main create-config-project-and-users-app
```

What `this` command `means` is `that` I am `creating` a `new branch` called
`main` from a `branch` called `create-config-project-and-users-app`, `and` then
`checking` out `into` the `new` main `branch`.

### Creating the remote repository on GitHub and add adding remote origin

`Then`, I `had` to `create` my `remote repository` on `GitHub`, `followed` by
`running` the `following` in `Terminal`:

```shell
 git remote add origin git@github.com:interglobalmedia/custom-abstract-base-user-model.git
```

### Merging create-config-project-and-users-app into main branch and pushing changes to remote origin

`Then` I `ran` the `following command`:

```shell
git merge create-config-project-and-users-app --no-ff
```

Which `returned`:

```shell
Already up to date.
```

`This` was `because` when I `checked` out `into` the `new` main `branch`, the
`changes` I `made` in `create-config-project-and-users-app` were "merged" into
`main`. `All` I `had` to `do` was `run` the `following command`:

```shell
git push -u origin main
```

Which `returned` the `following` in `Terminal`:

```shell
Enumerating objects: 30, done.
Counting objects: 100% (30/30), done.
Delta compression using up to 10 threads
Compressing objects: 100% (28/28), done.
Writing objects: 100% (30/30), 6.85 KiB | 3.42 MiB/s, done.
Total 30 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (4/4), done.
To github.com:interglobalmedia/custom-abstract-base-user-model.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
```

## Conclusion

`In` this `post`, `I` discussed `creating` a new `local` Git `repository`,
`checking` out `into` a `new branch` called
`create-config-project-and-users-app`, `trying` to `check` out `into` main
`branch` after `committing changes` in `create-config-project-and-users-app`,
and `after` not `succeeding`, `creating` a new `branch` called `main` in
`create-config-project-and-users-app` and `checking` out `into` main `all` at
`once`, `creating` the `remote repository` on `GitHub`, `adding` remote
`origin`, merging `create-config-project-and-users-app` into `main`, `and`
pushing `changes` to `remote origin`.

`If` you `also` ever `forget` to `make` your `first commit` in your `local` Git
`repository` and `subsequently` check `out` into a `new` feature `branch`,
`follow` the `steps` shown `here`, `and` you `will` have `no` issues
`checking out` into `your` main `branch` and `merging` your `changes` made `in`
the `feature branch`!

## Related Resources

-   [Custom abstract base user model repository on GitHub](https://github.com/interglobalmedia/custom-abstract-base-user-model):
    interglobalmedia, GitHub

## Related Posts

-   [AbstractUser vs AbstractBaseUser vs User extended profile in Django Part 1](http://localhost:3000/blog/abstractuser-vs-abstractbaseuser-vs-user-extended-profile-in-django-part-1):
    `mariadcampbell.com`


When you forget to make your first git commit to remote origin, checkout into a new branch, and then merge into main


![A yawning Carpet Python](david-clode-J_5xvghAvmc-unsplash.jpg)

_Photo by_ [David Clode](https://unsplash.com/@davidclode) _on_
[unsplash.com](https://unsplash.com/photos/a-close-up-of-a-snake-on-a-rock-J_5xvghAvmc)

## Table of Contents

-   [Reusing an app created in one Django project in another Django project](#reusing-an-app-created-in-one-django-project-in-another-django-project)
    -   [Copying an application from one Django project into another](#copying-an-application-from-one-django-project-into-another)
-   [Copying the polls app into a new top level directory called cast-votes](#copying-the-polls-app-into-a-new-top-level-directory-called-cast-votes)
-   [Configuring the polls app in cast-votes](#configuring-the-polls-app-in-cast-votes)
-   [Conclusion](#conclusion)
-   [Related Resources](#related-resources)
-   [Related Posts](#related-posts)

## Reusing an app created in one Django project in another Django project

`I` have `created` enough `Django` apps `at` this `point` that `can` be
`reusable` in other `Django` projects `other` than `the` ones `they` were
`initially` created `in`. `It` is `smart` and `efficient development` to `be`
able `to` do `so`. `Why` re-create `something` which `already` exists
`somewhere else`? This `is` a `great path` to `creating` reusable `apps` that
`others` can also `use` in their `Django` projects. `It` also `paves` a `path`
to `writing` great `documentation` for these `apps`.

### Copying an application from one Django project into another

`Following` the
["Writing your first Django app"](https://docs.djangoproject.com/en/5.1/intro/tutorial01/)
`series`, I `created` a `project` called `django_polls` inside a `top` level
`directory` called `django-polls`. This `was` all `fine`. The `app` was
`standalone`, and `that` was `great`. But `the` problems `began` when I `found`
out `about` the `Django` advanced `tutorial` called
["Advanced tutorial: How to write reusable apps"](https://docs.djangoproject.com/en/5.1/intro/reusable-apps/).
I `approached` the `django_polls` project `like` I `would` any `other` with the
`naming`. `I` did `not` know `what` was `coming` up `next`, `and` neither `was`
I `appraised` of it `beforehand`.

`In` this `post`, `I` will `discuss` how `to` avoid `as` much` as` possible
`such` naming `conflicts` while` still` naming `projects` and `reusable apps`
with `professional` sounding `names`.

## Copying the polls app into a new top level directory called cast-votes

`I` arbitrarily `named` a` new` top `level` directory `cast-votes`, and `inside`
I `created` a `new` project `called` config. `I` came `across` a `number` of
`posts` and `threads` where `Django` developers `repeatedly` called `their`
projects `"config"` so `that` there `would` be `less` of a `chance` of
`naming conflicts` when `installing` reusable `apps`. I `thought` it a
`great idea`, and `decided` to `do` the `same` for the `purpose` of this `post`.
`It` looks `like` I `might` continue `to` follow this `convention`!

`You` can `follow` the `steps` to `creating` a `new project` in my `post`
entitled
[Creating the official Django Polls app Part 1](/blog/creating-the-official-django-polls-app-part-1).
`However`, this `time`, i`nstead` of `creating` a `top` level `directory` called
`django-polls`, and `then` a `project` called `django_polls`, `create` a `top`
level `directory` called `cast-vote` and a `project` called `config` inside
`cast-vote`.

`If` you `have` already `completed` the
[Creating the official Django Polls app](https://docs.djangoproject.com/en/5.1/intro/tutorial01/)
`series` and `therefore` created an `app` called `polls`, `you` can `copy` the
`polls` app `directory` into the `root` of the `cast-votes` directory. There
`should` be no `conflicts`, `since` the `project name` does `not` contain
`"polls"` in it. `It's` as `generic` as `it` can `get`. `We` are `not` thinking
`about` creating a `package` from `polls` yet. `That` will `take place` in
`another post`. Right `now` we just `want` to `make sure` that our `polls` app
`can` be `reused` by `ourselves` on `our` local `machine`.

## Configuring the polls app in cast-votes

`Once` we `have` placed `polls` inside `the` top `level` cast-votes `directory`,
we `need` to `configure` it a bit. The `steps` are `not` dissimilar `from` those
`we` were `supposed` to `take` to `prepare` our `polls` app `package` in the
["Advanced tutorial: How to write reusable apps"](https://docs.djangoproject.com/en/5.1/intro/reusable-apps/).

`First`, `we` have `to` add `polls` to `INSTALLED_APPS` in `config/settings.py`:

```python
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "polls",
]
```

`Next`, we `have` to `configure` our `polls.urls` in `config/urls.py`:

```python
from django.contrib import admin
from django.urls import include, path # include is new

urlpatterns = [
    path("polls/", include("polls.urls")), # new
    path("admin/", admin.site.urls),
]
```

`Then`, just `make sure` that `there` isn't `anything` in your `templates` that
`does` not `belong` in `cast-votes`. I `had` a c`ouple` of `URLs` in
`templates/includes` and `templates/polls/index.html`. `Those` URLS `assumed`
that I `still` had` another` reusable `app` called `pages`, which `exists` in
the `original` django-polls `top` level `directory` along `with` the
`django_polls` project. But `since` I `haven't` added this `pages` reusable
`app` to `cast-votes`, I `had` to `make sure` to `update` them. `If`, however,
`I` did `want` to `add` that `reusable app` so `that` I `would` have a `top`
level `index page` (because right now I don't and neither should you unless you
did something different), `then` I `could` keep `those` URLs `which` were
`specific` to `django-polls/pages`. `There` were `no` other `"dependencies"` on
`django-polls`.

`If` I `were` to `package` this `app` and `publish` it, those `URLs` would
`cause` a `problem`. `The` other `question` to `ask` is, `do` we `want` to
include `templates` in our `packaged app` or `not`? `A` packaged `app` is
`going` to be `different` from a `reusable app` which `we` created `locally` on
our `machine` and `then` copied `over` to `another` Django `project`. We `have`
some `control` over its `behavior` in `relation` to the `project`, `and` in
`relation` to `other` reusable `apps` which `might` be subsequently `added`.

`According` to a `thread` on `stackoverflow` entitled
[Customize templates in a third party Django app](https://stackoverflow.com/questions/38341254/customize-templates-in-a-third-party-django-app/38725452#38725452),

> You can put the template in a separate app within your project. Django looks
> for templates in your apps in the order they are defined in INSTALLED_APPS,
> and uses the first match: The order of INSTALLED_APPS is significant! For
> example, if you want to customize the Django admin, you might choose to
> override the standard admin/base_site.html template, from
> django.contrib.admin, with your own admin/base_site.html in myproject.polls.
> You must then make sure that your myproject.polls comes before
> django.contrib.admin in INSTALLED_APPS, otherwise django.contrib.admin’s will
> be loaded first and yours will be ignored.

`This` led `me` to `the` updated `documentation` for `Django` 5.1 `entitled`
[How to override templates](https://docs.djangoproject.com/en/5.1/howto/overriding-templates/):

> In your project, you might want to override a template in another Django
> application, whether it be a third-party application or a contrib application
> such as django.contrib.admin. You can either put template overrides in your
> project’s templates directory or in an application’s templates directory.

And then:

.So create an app, called e.g. social_share_templates, and put it in
INSTALLED_APPS before django_social_share. Then add the template to this folder:

```django
{{project_root}}/social_share_templates/templates/django_social_share/templatetags/post_to_facebook.html
```

And then:

> The reason your current configuration does not work, is that your local app
> has the same name as the app in site-packages. If your local app is an actual
> python module, you won't be able to use the app in site-packages. Otherwise,
> Django just looks for the templates in the app in site-packages.

And then:

> So create an app, called e.g. social_share_templates, and put it in
> INSTALLED_APPS before django_social_share. Then add the template to this
> folder:

This `issue`(s) in `the` above `thread` is `similar` to `what` I `encountered`
when `trying` to `package` an `existing` reusable `app` following
[Creating the official Django Polls app](https://docs.djangoproject.com/en/5.1/intro/tutorial01/),
`among` other `things`.

`If` you `have` app and `project` templates `directories` that `both` contain
`overrides`, the `default` Django `template loader` will `try` to `load` the
`template` from the `project-level` directory `first`. `In` other `words`,
`DIRS` is `searched` before `APP_DIRS`.

`To` learn `more` about `this`, please visit
[How to override templates](https://docs.djangoproject.com/en/5.1/howto/overriding-templates/)
`in` the `current` Django (5.1) `documentation`.

We `choose` third `party` packages `primarily` for their
`functionality/features`. `If` we `want` to `change` the `looks` a `bit`, we
`customize` the `templates`, `following` the `steps` described in
[How to override templates](https://docs.djangoproject.com/en/5.1/howto/overriding-templates/).

`But` in my `case`, `I` just `made` a `couple` of `adjustments` to `fit` the
`app` (`module`, not `package`) `to` the `new` config `project`.

To `see` the o`riginal` django-polls `structure` containing `both` the `pages`
reusable `app` and `polls` reusable `app`, please visit
[django-polls](https://github.com/interglobalmedia/django-polls) on `Github`.

## Conclusion

`In` this `post`, I `discussed` how `I` can `reuse` an `app` created `in` one
`Django` project `in` another `project` so `that` I `don't` have to
`"re-create"` it `all` over `again` in another `project`.

## Related Resources

-   [Writing your first Django app, part 1](https://docs.djangoproject.com/en/5.1/intro/tutorial01/):
    Django documentation
-   [How to override templates](https://docs.djangoproject.com/en/5.1/howto/overriding-templates/):
    Django documentation
-   [Advanced tutorial: How to write reusable apps](https://docs.djangoproject.com/en/5.1/intro/reusable-apps/):
    Django documentation
-   [Customize templates in a third party Django app](https://stackoverflow.com/questions/38341254/customize-templates-in-a-third-party-django-app/38725452#38725452):
    stackoverflow

## Related Posts

-   [Creating the official Django Polls app table of contents](http://localhost:3000/blog/creating-the-official-django-polls-app-table-of-contents):
    `mariadcampbell.com`


How to reuse an app created in one Django project in another Django project

Adding pre-commit hooks to a Django project

Django official advanced tutorial on writing reusable apps


![Various tools on a wall](mitchell-luo-G5i9LQ7sPOw-unsplash.jpg)

_Photo by_ [Mitchell Luo](https://unsplash.com/@mitchel3uo) _on_
[unsplash.com](https://unsplash.com/photos/black-and-silver-claw-hammer-beside-red-and-black-hand-tool-G5i9LQ7sPOw)

## Table of Contents

-   [Activating the virtual environment](#activating-the-virtual-environment)
-   [Saving my current dependencies](#saving-my-current-dependencies)
-   [De-activating the virtual environment](#de-activating-the-virtual-environment)
-   [Deleting the current venv folder](#deleting-the-current-venv-folder)
-   [Creating a new venv folder](#creating-a-new-venv-folder)
-   [Re-activating the virtual environment](#re-activating-the-virtual-environment)
-   [Installing saved dependencies](#installing-saved-dependencies)
-   [Conclusion](#conclusion)
-   [Related Resources](#related-resources)
-   [Related Posts](#related-posts)

`I` was `working` on a `new project` today (the `official` Django `Polls` app
`tutorial` as a matter of fact), `and` I `noticed` that my `virtual environment`
was `using` Python `3.12`. `But` in `my project`, `I` am `using` Python
`3.13.0`. `Using` different `versions` of `Python` in the `virtual environment`
vs `in` the `code` can `create problems` and `conflicts`. I `had` to `upgrade`
my `version` of `Python` in my `venv` folder `pronto`!

## Activating the virtual environment

`First`, I `had` to `make sure` that my `virtual environment` was `activated` in
my `project`:

```shell
source venv/bin/activate
```

## Saving my current dependencies

`Next`, I `had` to `make sure` to `save` my `application`'s current
`dependencies`:

```shell
pip freeze > requirements.txt
```

## De-activating the virtual environment

`Next`, I `had` to `deactivate` the `virtual environment`:

```shell
deactivate
```

## Deleting the current venv folder

`Next`, I `had` to `delete` the `current` venv `folder`. `That` is `what` I
`call` my `virtual` environment `folder`. `You` might `call` it
`something else`!

## Creating a new venv folder

`Next`, I `had` to `create` a `new` venv `folder` using `3.13` since `that` is
`what` I `wanted` to `upgrade` to:

```shell
python3.13 -m venv venv
```

## Re-activating the virtual environment

`Next`, I `had` to `re-activate` the `virtual environment`:

```shell
source venv/bin/activate
```

## Installing saved dependencies

`Next`, I `had` to `install` my `saved dependencies`:

```shell
pip install -r requirements.txt
```

And that's it!

## Conclusion

`In` this `post`, I `showed` how to `upgrade` the `Python version` being `used`
in a `Django` application's `virtual environment`.

## Related Resources

-   [How to upgrade Python venv version](https://stackoverflow.com/questions/71106411/how-to-upgrade-python-venv-version):
    stackoverflow

## Related Posts

-   [Creating the official Django Polls app Part 8](/blog/creating-the-official-django-polls-app-part-8):
    `mariadcampbell.com`


How to upgrade the Python version in a virtual environment


![A yawning Carpet Python](david-clode-J_5xvghAvmc-unsplash.jpg)

_Photo by_ [David Clode](https://unsplash.com/@davidclode) _on_
[unsplash.com](https://unsplash.com/photos/a-close-up-of-a-snake-on-a-rock-J_5xvghAvmc)

In this series, I follow the official Django Polls application tutorial. After
refactoring an application which had been created over seven years ago, I
thought the best way to become even more familiar with the Django documentation
would be to follow their Django Polls tutorial and create a Django Polls
application.

## Series Table of Contents

1. [Creating the official Django Polls app Part 1](/blog/creating-the-official-django-polls-app-part-1):
   In this section, I create a directory to house my Django Polls application,
   check if I have Django installed, select my Python interpreter, install
   virtualenv with pip, create a virtual environment for Django Polls, activate
   and deactivate the virtual environment, install Django, upgrade Django,
   create a project in Django Polls, initialize git, start up the Django
   development server, create an app called polls, write a first view, create a
   URLconf for the index view, and configure the global URL configuration.
1. [Creating the official Django Polls app Part 2](/blog/creating-the-official-django-polls-app-part-2):
   In this section, I set up the Django Polls database, explained/set
   LANGUAGE_CODE, USE_I18N, USE_THOUSAND_SEPARATOR, NUMBER_GROUPING, USE_TZ, and
   INSTALLED_APPS, create the polls models, activate the models, play with the
   API in the interactive Python shell, discuss the Django admin interface,
   create a superuser, start the development server, register polls app in
   polls/admin.py, and discuss the Question form in the admin interface.
1. [Creating the official Django Polls app Part 3](/blog/creating-the-official-django-polls-app-part-3):
   In this section, we write our first Django app, discuss URL patterns, write
   more views in polls/views.py, write views that actually work, re-write the
   index view, create a templates directory in the polls directory, implement
   template namespacing, add Django code to index.html, update the index view to
   use the new index.html template, implement the render() shortcut, implement
   raising a 404 error in the detail view, use get_object_or_404() in the detail
   view, discuss Model's manager in Django, discuss Manager names, use template
   tags in the template engining system, remove the hardcoded URL in the
   template in polls/index.html, and namespace our URL names.
1. [Creating the official Django Polls app Part 4](/blog/creating-the-official-django-polls-app-part-4):
   In this section, we add a minimal form to our polls.detail.html template, we
   update the function based vote view, create a polls/results.html template,
   refactor our polls/urls.py to match the new generic views, and we install
   DJLint to format our Django templates.
1. [Creating the official Django Polls app Part 5](/blog/creating-the-official-django-polls-app-part-5#creating-more-comprehensive-tests-for-questionrecently-published):
   In this section, we are introduced to automated testing. We discuss what
   automated testing is, why it's important to create tests, basic testing
   strategies, write our first test to identify a bug, fix the bug, create more
   comprehensive tests for Question.recently_published(), test a view, analyze
   the tools available to us in testing, are introduced to the Django test
   client, improve our PollsIndexView, test our new PollsIndexView, test the
   PollsDetailView, and break down the refactored PollsDetailView (which
   originally contained a bug which I fixed).
1. [Creating the official Django Polls app Part 6](/blog/creating-the-official-django-polls-app-part-6):
   In this section, we add static files to our Django Polls application
   configured for local development.
1. [Creating the official Django Polls app Part 7](/blog/creating-the-official-django-polls-app-part-7):
   In this section, we customize the Question admin form, add Choice related
   objects to the admin form, customize the admin change list, add search
   capability to the admin interface, customize the admin look and feel, and
   customize our project's templates.
1. [Creating the official Django Polls app Part 8](/blog/creating-the-official-django-polls-app-part-8):
   In this section, we install the Django Debug Toolbar, configure the toolbar
   so it appears in the browser when we run our development server, learn that
   we can customize the toolbar, run our Django Polls project in the browser to
   view the toolbar, are introduced to resources where we can access other third
   party packages to use in our applications, and are provided with next steps.


Creating the official Django Polls app table of contents


![Man Holding Microphone While Talking to Another Man
and covering a story](pexels-mjlo-2872418.jpg)

**_Photo by_** [Mido Makasardi](https://www.pexels.com/@mjlo/) **_on_**
[pexels.com](https://www.pexels.com/photo/man-holding-microphone-while-talking-to-another-man-2872418/)

## Table of Contents

-   [What is test coverage in Django?](#what-is-test-coverage)
-   [Tools for measuring coverage in Django](#tools-for-measuring-coverage-in-django)
-   [Installing Coverage.py](#installing-coveragepy)
-   [The C extension](#the-c-extension)
-   [Checking for coverage's version](#checking-for-coverages-version)
-   [Running the coverage command](#running-the-coverage-command)
-   [Coverage report](#coverage-report)
-   [Coverage html](#coverage-html)
-   [Conclusion](#conclusion)
-   [Related Resources](#related-resources)
-   [Related Posts](#related-posts)

## What is test coverage in Django?

When we have `written` some `tests` for our `Django` applications, we
`might wonder` whether or `not` we `wrote` enough `tests` and `for` the
`right things`. `One way` we can `determine` this is by `measuring` the
`coverage` of our `tests`. In other words, `how thoroughly` our `tests`
encompass our `application`'s `code`.

## Tools for measuring coverage in Django

Probably the most `popular tool` _for measuring_ `coverage` in `Python` is the
[Coverage.py](https://coverage.readthedocs.io/en/7.6.1/) tool. It _monitors_
`Python` programming, noting `which parts` of the `code` have been `executed`,
then `analyzes` the `source` _to identify_ `code` that `could have` been
`executed` _but was_ `not`.

## Installing Coverage.py

To install `coverage.py`, `run` the `command` below in the `root directory` of
your `project` (in my case, the `django-boards` directory (as opposed to
`django_boards` directory)) where the `venv` directory `resides`. Also make sure
that your `virtual environment` has been `activated` _before_ `installing` the
`coverage` package.

```shell
python3 -m pip install coverage
```

## The C extension

According to
[Coverage.py](https://coverage.readthedocs.io/en/latest/install.html),

> Coverage.py includes a C extension for speed. It is strongly recommended to
> use this extension: it is much faster, and is needed to support a number of
> coverage.py features. Most of the time, the C extension will be installed
> without any special action on your part.

## Checking for coverage's version

In order to `find out` what `version` of `coverage` we have `installed`, we can
`run` the `following command` in `Terminal` inside our `Django project` with
`venv` _activated_:

```shell
coverage --version
```

When I ran `coverage --version` at the `django-boards` _root directory_, I
`got back` the `following`:

```shell
Coverage.py, version 7.6.1 with C extension
Full documentation is at https://coverage.readthedocs.io/en/7.6.1
```

My `coverage` _installation_ does `come` with the `C extension`.

## Running the coverage command

In order to _implement_ `Coverage.py`, we `run` the `following command` in the
`directory` where our `manage.py` file `resides`:

```shell
coverage run manage.py test
```

This `command` _will include_ ALL our `project` tests: _both_ in `accounts` and
`boards`.

## Coverage report

_After running_ `coverage run manage.py test`, we can `generate` a
`coverage report` with the `following command` in the _same directory_:

```shell
coverage report
```

_For me_, the `following report` was _generated_:

| Name                                                                           | Stmts   | Miss  | Cover   |
| ------------------------------------------------------------------------------ | ------- | ----- | ------- |
| `accounts/__init__.py`                                                         | 0       | 0     | 100%    |
| accounts/admin.py                                                              | 1       | 0     | 100%    |
| accounts/apps.py                                                               | 4       | 0     | 100%    |
| accounts/forms.py                                                              | 8       | 0     | 100%    |
| `accounts/migrations/__init__.py`                                              | 0       | 0     | 100%    |
| accounts/models.py                                                             | 1       | 0     | 100%    |
| `accounts/tests/__init__.py`                                                   | 0       | 0     | 100%    |
| accounts/tests/test_invalid_signup_tests.py                                    | 17      | 0     | 100%    |
| accounts/tests/test_signup_tests.py                                            | 27      | 0     | 100%    |
| accounts/tests/test_successful_signup_tests.py                                 | 20      | 0     | 100%    |
| accounts/tests/test_view_signup.py                                             | 0       | 0     | 100%    |
| accounts/views.py                                                              | 12      | 0     | 100%    |
| `boards/__init__.py`                                                           | 0       | 0     | 100%    |
| boards/admin.py                                                                | 6       | 0     | 100%    |
| boards/apps.py                                                                 | 4       | 0     | 100%    |
| boards/forms.py                                                                | 7       | 0     | 100%    |
| boards/migrations/0001_initial.py                                              | 7       | 0     | 100%    |
| boards/migrations/0002_post_post_liked_topic_topic_liked_postlike_topiclike.py | 6       | 0     | 100%    |
| boards/migrations/0003_remove_topic_topic_liked_delete_topiclike.py            | 4       | 0     | 100%    |
| boards/migrations/0004_alter_postlike_post_like_value.py                       | 4       | 0     | 100%    |
| boards/migrations/0005_alter_postlike_post_like_value.py                       | 5       | 0     | 100%    |
| boards/migrations/0006_alter_postlike_post_like_value.py                       | 4       | 0     | 100%    |
| boards/migrations/0007_remove_post_post_liked_post_post_liked_by.py            | 5       | 0     | 100%    |
| boards/migrations/0008_alter_post_post_liked_by.py                             | 5       | 0     | 100%    |
| boards/migrations/0009_alter_post_post_liked_by.py                             | 5       | 0     | 100%    |
| `boards/migrations/__init__.py`                                                | 0       | 0     | 100%    |
| boards/models.py                                                               | 34      | 5     | 85%     |
| boards/templatetags/form_tags.py                                               | 16      | 2     | 88%     |
| `boards/tests/__init__.py`                                                     | 0       | 0     | 100%    |
| boards/tests/test_board_topics_tests.py                                        | 28      | 0     | 100%    |
| boards/tests/test_index_tests.py                                               | 25      | 0     | 100%    |
| boards/tests/test_new_topic_tests.py                                           | 28      | 0     | 100%    |
| boards/tests/test_templatetags.py                                              | 24      | 0     | 100%    |
| boards/views.py                                                                | 24 0    | 100%  |
| `django_boards/__init__.py`                                                    | 0       | 0     | 100%    |
| django_boards/settings.py                                                      | 26      | 0     | 100%    |
| django_boards/urls.py                                                          | 6       | 0     | 100%    |
| manage.py                                                                      | 11      | 2     | 82%     |
| **TOTAL**                                                                      | **374** | **9** | **98%** |

## Coverage html

If I `want` to `generate` an `html document` of my `coverage report` (`produce`
annotated `HTML` listings with `coverage` results), I _can run_ `coverage html`
in `Terminal`, and the `following` is `returned`:

```shell
Wrote HTML report to htmlcov/index.html
```

I `add` the `htmlcov` directory to my `.gitignore` file, and I also `add` the
`.coverage` file that was `created` when I ran `coverage run manage.py test`.

## Conclusion

In this post, I went over the `basics` of `Coverage.py` and `how` to `determine`
the `percentage` of a `Django` application my `tests` have `covered` using the
`coverage` command. There is _much more_ to `Coverage.py`, and more
`Command Line` usage `available`, but _this_ is a _great start_.

## Related Resources

-   [Measuring Coverage](https://django-testing-docs.readthedocs.io/en/latest/coverage.html):
    **_Django testing docs_**
-   [Coverage.py installation](https://coverage.readthedocs.io/en/latest/install.html):
    **_Coverage read the docs_**
-   [Coverage.py command line usage](https://coverage.readthedocs.io/en/latest/cmd.html):
    **_Coverage read the docs_**

-   [Testing in Django](https://dev.to/ifihan/testing-in-django-26e5): **_by
    Ifihan Olusheye, dev.to_**
-   [A Beginners Guide to Unit Testing in Django](https://ctrlzblog.com/a-beginners-guide-to-unit-testing-in-django?x-host=ctrlzblog.com):
    **_by Alice Ridgway_**

-   [How to Test Django Models (with Examples)](https://ctrlzblog.com/how-to-test-django-models-with-examples?x-host=ctrlzblog.com):
    **_by Alice Ridgway_**

## Related Posts

-   [How to create a fullstack application using Django and Python Table of Contents](/blog/how-to-create-a-fullstack-application-using-django-and-python-table-of-contents)


How to measure test coverage in Django


![Trump Talks](trump-talks-nextjs.jpg)

_Trump Talks_

A `Random Quote API` application using the `What Does Trump Think?` API.

## Related Resources

-   [Trump Talks hosted on vercel.com](https://trump-talks-nextjs.vercel.app/)
-   [Trump Talks repository on Github](https://github.com/interglobalmedia/trump-talks-nextjs)


Trump Talks

How to create a fullstack application using Django and Python Table of Contents


![Example of a table in React Markdown](Screenshot-2024-09-02-at-11.25.31-PM.jpg)

_Example of a table in React Markdown_

## Table of Contents

-   [Tables not supported natively in React Markdown](#tables-not-supported-natively-in-react-markdown)

## Tables not supported natively in React Markdown

Recently I was writing an article in React Markdown, and I wanted to add a
table. However, it did not render! I didn't realize until I further researched
the issue that React Markdown does not support adding tables in Markdown
natively. According to an
[issues thread](https://github.com/remarkjs/react-markdown/issues/526) in the
React Markdown Github repository from December 22, 2020,

> Tables, and all other GFM have moved to a plugin. You can see an example of
> usage with tables here: https://github.com/remarkjs/react-markdown#use and the
> note in the release notes here:
> https://github.com/remarkjs/react-markdown/blob/main/changelog.md#500---2020-10-19
>
> The website accurately reflects that by default, react-markdown follows the
> CommonMark standard, which does not have Tables. --
> `ChristianMurphy commented on Dec 22, 2020`

I looked at the example of usage with tables, and it seemed pretty
straightforward. I followed the example and imported the `remark-gfm` npm
package into my `post-content.js file` after `installing` it. Then I added it to
the ReactMarkdown component. But it didn't work. I kept on getting
`TypeError Cannot set properties of undefined (setting 'inTable')`. I did a
Google Search and came up with a thread on stackoverflow entitled
[ReactMarkdown + remarkGfm: everything renders as expected, EXCEPT tables - typeError?](https://stackoverflow.com/questions/77138105/reactmarkdown-remarkgfm-everything-renders-as-expected-except-tables-typee/77172599#77172599).

First I found out that it was only with React Markdown 9.0 that I could use the
latest version of `remark-gfm`. I however, am using React Markdown 8.0.7.
According to the answer that solved my issue, React Markdown 8.0.7 works with
`remark-gfm` version `3.0.1`.

So I `uninstalled` my `current version` of `remark-gfm` with npm uninstall
remark-gfm (`gfm` stands for `Github Flavored Markdown`) and then re-installed
it with `npm i remark-gfm@3.0.1 -S`. Then I did the following inside my
post-content.js file which is the component that renders the markdown content of
my posts on this site:

```jsx
import remarkGfm from 'remark-gfm'
import rehypeRaw from 'rehype-raw'
;<ReactMarkdown
	components={customRenderers}
	rehypePlugins={[rehypeRaw]}
	remarkPlugins={[remarkGfm]}
	remarkRehypeOptions={{ passThrough: ['link'] }}
>
	{post.content}
</ReactMarkdown>
```

I also `installed` and `imported` the `rehype-raw` npm package, and passed
`options` to `remarkRehypeOptions` because in the same thread, another user
stated:

> Helping hand - I discovered using the remarkGfm had a knock-on effect when
> using custom components in react-markdown. Though remarkGfm fixed the table
> layout, it stripped content (e.g. class names) from html tags when used in
> markdown (which is valid). As such applying remarkRehypeOptions > passThrough
> allowed both the tables to render correctly and links to use custom
> components. -- `Chris GW Green answered Mar 13 at 13:39`

Then he `added` a `code snippet` of `how` he `added` the `two packages` to
`React Markdown`:

```jsx
<Markdown
   remarkPlugins={[remarkGfm]}
   rehypePlugins={[rehypeRaw]}
   remarkRehypeOptions={{ passThrough: ['link'] }}
    ...
```

`Basically` the `same` as the `snippet` I `shared`, and his `snippet` is `where`
I also got `guidance`.

I also `added` some `simple styling` for my `tables` in my
`post-content.module.scss` file:

```scss
/* Markdown table styling */
.content table {
	border-spacing: 0 !important;
	border-collapse: collapse !important;
	border-color: inherit !important;
	display: block !important;
	margin: 0 auto !important;
	width: 100% !important;
	max-width: 100% !important;
	overflow: auto !important;
}

.content tbody,
.content td,
.content tfoot,
.content th,
.content thead,
.content tr {
	border-color: inherit !important;
	border-style: solid !important;
	border-width: 2px !important;
	padding: 0.5rem;
}
```

if you are a `next.js` and `tailwind.css` user, I also `added` a `bit` of
`styling` for `dark mode` in my (`global`) `post-content.scss` file:

```scss
.dark .content table {
	color: $white;
}
```

This is `what` the `table` I `created` looks `like`:

![Summary of Model operations in the Python3 shell](Screenshot-2024-09-02-at-11.25.31-PM.jpg)

_Screenshot of table used in
[How to create a fullstack application using Django and Python part 7](/blog/how-to-create-a-fullstack-application-using-django-and-python-part-7)_

## Related Resources

-   [Tables not working on website #526](https://github.com/remarkjs/react-markdown/issues/526):
    **_react-markdown Github repository_**
-   [remarkjs/react-markdown example usage](https://github.com/remarkjs/react-markdown#use):
    **_remarkjs/react-markdown Github repository_**
-   [ReactMarkdown + remarkGfm: everything renders as expected, EXCEPT tables - typeError?](https://stackoverflow.com/questions/77138105/reactmarkdown-remarkgfm-everything-renders-as-expected-except-tables-typee/77172599#77172599);
    **_stackoverflow_**


How to add tables to React Markdown


![](pexels-galleryofmyeye-13169888.jpg)

**_Photo by_** [Enes Bayraktar](https://www.pexels.com/@galleryofmyeye/)
**_on_**
[pexels.com](https://www.pexels.com/photo/time-lapse-photo-of-train-on-subway-13169888/)

## Table of Contents

-   [What is the history command?](#what-is-the-history-command)
-   [history is not actually a command](#history-is-not-actually-a-command)
-   [history](#history)
-   [Removing history](#removing-history)
    -   [Deleting a command by line number](#deleting-a-command-by-line-number)
    -   [history -c](#history-c)
    -   [Manually removing the contents of .bash_history](#manually-removing-the-contents-of-bash-history)
    -   [Clearing .bash_history using the echo command](#clearing-bash-history-using-the-echo-command)
-   [bash history, privacy and security](#bash-history-privacy-and-security)
-   [Related Resources](#related-resources)

## What is the history command?

The `history` command in `Linux` (and `macOS`) stores a `list` of `commands`
that have been `used` in `Terminal` sessions, `and` it `permits` us to `reuse`
them `instead` of `retyping` them.

## history is not actually a command

If I run `which history` in `Terminal`, `nothing` is `stdout`. This `confirms`
that `history` is `not` actually a `command`. `history` is a `built-in` keyword
of our `shell` (Another example is the `cd` command. It `also` is a `builtin`
keyword and `not` a `command`). And because `history` is `written` into the
`particular shell` we are `using` at `any` given `time`, there can be a
`difference` in its `behavior` across `shells`. But since I use `bash` in
`Linux`, I will be discussing `bash-specific` history `behavior` in my
`particular` Linux `distro` (`Linux Mint`).

## history

If I run `history` in `Terminal`, I get back `428` lines, `each line` containing
a `command` I have `run` in `Terminal`. The `following` is a `sneak peak` at
`history` stdout:'

```shell
  1 ls
  2 cd Desktop
  3 ls
  4 cd cron-job-scripts/
  5 ls
  6 mailx
  7 sudo apt update
  8 sudo apt upgrade
  9 sudo apt install mailx
  ...
428 history
```

If I `wanted` to `run` a `specific command` using its `line number`, I would
`run` the `following`:

```shell
!84
```

Which would `return` the `following`:

```shell
cd desktop-backup/
```

This is the `command` at `line 84` in (`Terminal`) `history`. I `could` also
`access` and `run` this `command` by `running` the `following`:

```shell
!cd desktop-backup/
```

`Sometimes`, `as` in `this case`, we `get` back `something like` the
`following`:

```shell
cd desktop-backup/ desktop-backup/
bash cd: too many arguments
```

So I `tried` another `one` that does `not` result in any `ambiguity`:

```shell
!clear
```

It `runs` the `clear command`, `clearing` the `Terminal` window. Using `!`
before the `command itself` prompts `history` to `search` for the `last command`
that `matches` the `pattern` I `provided`. `In` this `case`, it is `clear`.

But I digress. Let's get to the task at hand.

## Removing history

There are `several ways` to `remove` some or all `commands` saved to `history`.

### Deleting a command by line number

If I `want` to `delete` a `command` saved to `history` by `line number`, I would
`run` the `following command`:

```shell
history -d 423
```

This `removes` the `command` at line `423`. This is a `great command` to `know`
in `case` if you have `mistyped` a `command`, for example, and `want` to
`remove` it from `history` because it is essentially `useless`. But it can
`also` be `used` to `remove` specific `commands` containing
`sensitive information`. Why? `What` if` you` had to use `history` or
`some other` related `tool` or `command` in a `presentation`, and you `wanted`
to `make sure` that `nothing sensitive` would `appear` on the `screen`, and you
`didn't want` to `completely remove` your `history`. This `would` be `one way`
to `do that`.

### history -c

The `history -c` command `removes` the `contents` of a specific `Terminal`
session's `history`. If I run `history -c` and then `check` to `see` if the
`contents` of my `Terminal` session's `history` was `indeed` completely
`removed`, I would run `history` again, and `something like` the `following`
would be `returned`:

```shell
1 history
```

### Manually removing the contents of .bash_history

`history` stores the `commands` run in `Terminal` in a `file` called
`.bash_history`, which is `located` in a `user`'s home `directory`. If, after
running `history -c`, I `want` to `double check` if `all` my `history` has
actually `been removed`, I can run `vim .bash_history` to `open up` the `file`
in `Vim`. And `something like` the `following` would `appear`:

```shell
# The contents of .bash_history contained 426 lines. I am truncating it.
...
which diff
diff -s secret_message.txt decrypted_super_secret.txt
sha512sum secret_message.txt
```

`history -c` only `clears` the `history` of a `specific` Terminal `session`, but
`not` the `entire contents` of `.bash_history` itself. Some articles state that
it `completely removes` all your `history`, but `it` does `not`. After running
`history -c`, your `.bash_history` still `contains` the `history` of the
`commands` you `have run` in `Terminal`.

If I `wanted` to `manually remove` the `contents` of `.bash_history`, I would
`have` to `open` the `file` and `manually delete` the `contents` of the `file`.
I could `open` the `file` using `open .bash_history` inside my `home directory`
where the `file resides`, `Control + A` the `file contents`, and then `hit` the
`delete` key and `remove` the `file contents`.

I could `also` run `vim .bash_history` and be `taken` into the `Vim interface`.
There, I would `do` the `following`:

```shell
# First I go into Vim normal mode by hitting the `esc` key
# Next, I enter command mode by hitting Shift key + : (colon)
# To Select All, I hit the Shift Key + % (5 key) after the colon (:)
# to delete everything, I then hit the D key after %
# To save my changes, I hit the esc key followed by Shift key + : (colon) and then the X key. This saves my changes and takes me out of Vim.
```

`If`, `after deleting` the `entire contents` of `.bash_history`,
`subsequent commands` are `not saved` to `.bash_history` (it remains empty),
`run` the `following command`:

```shell
history > .bash_history
```

Then `open` up `.bash_history`, and you `should see` your stored `Terminal`
history `reappear`. That is `because` you `have` redirected `history` as
`stdout` to the `.bash_history` file.

`Next`, to doubly `make sure` that `everything` is `working` as it `should`,
`run` a `few commands` in `Terminal`, and `then` re-open `.bash_history` to
`see` if those `commands` are `being saved` to `.bash_history`. `When` I
`did this` and re-opened `.bash_history`, I `saw` that `new commands` were `not`
being `added` to `.bash_history`. `Even when` I quit `Terminal` and `started` a
`new session`. So I `had` to `do` the `following` to `do` a `history` "reset":

```shell
# I ran this inside my home directory /home/maria where my .bash_history resides
rm .bash_history
touch .bash_history
```

`Once` I re-created the `.bash_history` file, I `saw` that `Terminal history`
was `saved` to `.bash_history`, but `commands` from a `Terminal` session would
`save` to the `.bash_history` file `when` I would `exit` out of a `Terminal`
session and `start` a `new one`. `But` it `worked` just `fine` and as
`expected`!

### Clearing .bash_history using the echo command

`In order` to `remove` to `complete contents` of the `~/.bash_history` file, I
`ran` the `following command`:

```shell
# I did not have to add ~/ in front of .bash_history because I ran the command inside my home directory
echo > .bash_history
```

And `when` I `opened` up `.bash_history` using `open .bash_history`, the `file`
was `completely empty`. This is the `ONLY command` that `successfully removed`
the `contents` of my `.bash_history` file!

## bash history, privacy and security

`Clearing` one's `bash history` is not `just about` keeping things `"clean"`.
it's `also` about `safeguarding` one's `privacy` and `security`. By `clearing`
our `bash history` on a `regular basis`, we can `help` protect
`sensitive information` that `we` may have `used` in a `command`, `such` as
`passwords` or other `confidential data`.

## Related Resources

-   [How to use the history command in Linux](https://opensource.com/article/18/6/history-command):
    **_by Steve Morris, opensource.com_**
-   [Select all in Vim / Vi](https://www.warp.dev/terminus/select-all-in-vim-vi):
    **_warp.dev_**
-   [Clear Bash History: Bash Shell and Command Line Guide](https://ioflood.com/blog/clear-bash-history/):
    **_I/O Flood_**
-   [How to Clear the Terminal History in Linux](https://www.geeksforgeeks.org/how-to-clear-the-terminal-history-in-linux/):
    **_Geeks for Geeks_**


Clearing Terminal history in Linux and why it is important to do on occasion


![Redirecting](pexels-isaquepereira-394377.jpg)

**_Photo by_** [Isaque Pereira](https://www.pexels.com/@isaquepereira/) **_on_**
[pexels.com](https://www.pexels.com/photo/yellow-arrow-led-signage-394377/)

## Table of Contents

-   [stdin and stdout explained](#stdin-and-stdout-explained)
-   [The output redirector operator (>)](#the-output-redirector-operator-)
-   [The input redirector operator (<)](#the-input-redirector-operator-)
-   [The output redirector append operator (>>)](#the-output-redirector-append-operator-)
-   [Related Resources](#related-resources)

## stdin and stdout explained

In order to understand what `redirect operators` do in `Linux` or `Unix`
(`macOS`), one first has to understand what `stdin` and `stdout` mean.

In the case of a personal `Linux` (or `macOS`) device, for example, **_by
default_**, `stdin` refers to a device's `keyboard`, and `stdout` refers to
`Command Line` (`Terminal`). And these `pathways` are called `streams`.

That being said, we don't always want to output `stdout` to `Command Line`,
which is not persistent by default. Perhaps we want to save it somewhere. It is
possible to change our `default input` and `output` locations. This means making
the OS to obtain information from somewhere other than the `stdin` or send
results to somewhere other than the `stdout`. This functionality is known as
`redirection`.

## The output redirector operator (>)

The default `output redirector operator` is the most popular and well known of
`redirectors`. As previously mentioned, by default, when not using
`redirection`, `stdout` is made in `Terminal`. However, this `output` is not
persistent because it is not saved to `Terminal`! If it was, we would have an
awful lot of clutter there!

In `Linux Command Line`, if I were to run the following in `Terminal`:

```shell
$HOME
```

the following would be returned in `Terminal`:

```shell
bash: /home/maria: Is a directory
```

I type `$HOME` with my `laptop keyboard`, my `stdin`, and it is output to the
`Terminal window`, my `stdout`. But it is not saved anywhere, so I can't refer
to that particular output later. But as also previously mentioned, I can
`redirect` this `output` somewhere else, and even `save` the `data` using the
`output redirector` (`>`). So let's say I run the following command instead:

```shell
printenv 'HOME' > home.txt
```

Then, if I use the `cat` command to output the contents of `home.txt`:

```shell
cat home.txt
```

It results in the following `output` in `Terminal`:

```shell
/home/maria
```

However, if I simply ran the following without using the
`output redirector operator`:

```shell
printenv 'HOME'
```

the following would be returned in `Terminal`:

```shell
/home/maria
```

And `/home/maria` would not be `redirected` and `output` to `home.txt`.

The `printenv` command prints the value of an `environment variable`, and
`$HOME` is one of them. In this case, `printenv` is printing the value of the
`global environment variable` called `'HOME'`. And since I am not appending `$`
to the beginning of `HOME`, it is not being treated as a `variable` containing a
`value` (HOME=/home/maria), but simply as the `value` of `$HOME`.

## The input redirector operator (<)

The `default input redirector` (`<`) redirects `stdin` somewhere else. For
example, if I type the following in `Terminal` followed by the `Return`
(`Enter`) key:

```shell
printenv 'HOME' < home.txt
```

this would result in the following in `Terminal`:

```shell
/home/maria
```

And if I open up `home.txt` with the `vim` command:

```shell
vim home.txt
```

The following would appear:

```shell
/home/maria
```

If I were to combine the `input` and `output` operator, for example:

```shell
printenv 'HOME' < home.txt > home2.txt
```

This command both redirects `stdin` and `stdout`, and also creates a new file
called `home2.txt` if it does not already exist, thanks to the `output operator`
(`>`).

When I run the following in `Terminal`:

```shell
cat home2.txt
```

it returns the following in `Terminal`:

```shell
/home/maria
```

When I run the following in `Terminal`:

```shell
cat home.txt
```

it returns the following:

```shell
/home/maria
```

However, because I am using the (single) `regular output operator` (`>`), it
`overwrites` the previous content of `home2.txt` with a new instance of
`/home/maria`. What if I `didn't want` to `overwrite` the contents of
`home2.txt`?

## The output redirector append operator (>>)

If I just want to `append` the `contents` of `stdin` (i.e., `home.txt`) to
`stdout` (i.e., `home2.txt`), I would run the following in `Terminal`:

```shell
printenv 'HOME' < home.txt >> home2.txt
```

Then, when I run the following command in `Terminal`:

```shell
cat home2.txt
```

it returns the following in `Terminal`:

```shell
/home/maria
/home/maria
```

And if I run the following in `Terminal`:

```shell
cat home.txt
```

it returns the following in `Terminal`:

```shell
/home/maria
```

The `contents` of `home.txt` remains the same because it is the `stdin`, but
`home2.txt` now `includes` a `second line` of `text`, which has been `appended`
to the `original` first line of `text`. `No data` was `overwritten` or `lost`.

**An important thing to note**: Usually one should use the
`output redirector append operator` (`>>`) instead of the
`output redirector operator` (`>`) so as not to lose any file data (unless there
is a specific reason to use `>`)!

## Related Resources

-   [I/O redirection](https://tldp.org/LDP/intro-linux/html/sect_05_01.html):
    **_by Machtelt Garrels, Introduction to Linux_**

-   [Five ways to use redirect operators in Bash](https://www.redhat.com/sysadmin/redirect-operators-bash):
    **_by Damon Garn, RedHat_**
