This project is a personal website and blog, built using the Django web framework. It is containerized with Docker for consistent development and deployment environments. The project includes separate applications for the blog and static pages, a complete set of tests, and uses ruff for code linting and formatting.
- Backend: Django, Python
- Database: PostgreSQL
- Frontend: Django Templates, HTML, CSS
- Containerization: Docker, Docker Compose
- Dependency Management: uv,
pyproject.toml - Testing: pytest, pytest-django
- Linting & Formatting: ruff
- CI/CD: GitHub Actions
- Deployment: Gunicorn
blog/: A Django app for the blog functionality.pages/: A Django app for the static pages of the website (e.g., about, contact).mysite/: The main Django project directory, containing the settings and main URL configuration.static/: Static files such as CSS and images.templates/: Base HTML templates that are extended by the app-specific templates.tests/: Contains the tests for the different Django apps.Dockerfile: Defines the Docker image for the application, with stages for development and production.docker-compose.yml: Defines the services, networks, and volumes for the Docker application.Makefile: Provides a set of commands to simplify common tasks like running the server, testing, and managing the Docker containers.pyproject.toml: The file that contains the project metadata and dependencies foruv.
The project is designed to be run with Docker. The Makefile provides convenient commands to manage the application stack.
- Build and start the development server:
make start
- The website will be available at http://localhost:8000.
The project uses pytest for testing. You can run the test suite with the following command:
make testDependencies are managed with uv and are defined in pyproject.toml.
- To install production dependencies:
uv sync
- To install all dependencies, including development dependencies:
uv sync --all-groups
- New Libraries: All new Python libraries should be added to
pyproject.tomland installed usinguv.
The project uses ruff for code linting and formatting.
- To run the linter:
make pep8
- The project is also configured to use
pre-committo runruffautomatically before each commit.
This project prefers the use of the "early exit" pattern (also known as guard clauses) in views and other functions. This approach helps to improve readability by handling edge cases and "unhappy paths" at the beginning of a function, which reduces nesting and makes the main logic easier to follow.
For example:
def my_view(request):
if not request.user.is_authenticated:
return redirect('login')
if request.method != 'POST':
# handle GET request
return render(...)
# Main logic for POST request
...This project follows the Conventional Commits specification. This format provides a set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.
Each commit message consists of a header, a body, and a footer. The header has a special format that includes a type, a scope, and a description:
<type>(<scope>): <description>
Common types include feat (for new features) and fix (for bug fixes).
The Dockerfile includes a production stage that uses gunicorn to serve the Django application. The .github/workflows/django.yml file defines a GitHub Actions workflow for continuous integration and deployment.