DEV Community: David

Building Spokane Tech: Part 9

David — Sat, 01 Nov 2025 00:30:00 +0000

Building Spokane Tech: Part 9

Welcome to part 9 of the "Building Spokane Tech" series! In this article, we'll optimize our Docker file for size and efficiency.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Optimizing Your Django Docker Images: The Power of Multi-Stage Builds

At SpokaneTech.org, we're always looking for ways to improve our development and deployment processes. A cornerstone of modern web application deployment is containerization, and for that, we rely on Docker. Docker allows us to package our Django application with all of its dependencies into a single, portable container.

However, as applications grow, so can the complexity and size of their Docker images. A bloated Docker image can lead to slower deployment times, increased storage costs, and a larger attack surface. Today, we'll explore how we optimized our Docker workflow for our Django project by transitioning from a single-stage to a multi-stage Dockerfile.

The Starting Point: A Single-Stage Dockerfile

When you first start Dockerizing a project, you'll likely begin with a single-stage Dockerfile. It's straightforward and gets the job done. Here’s what our initial Dockerfile looked like:

FROM python:3.12-slim

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

# Set the working directory
WORKDIR /app

# Install system dependencies
RUN apt-get update && apt-get install -y \
    libglib2.0-0 \
    libnss3 \
    libx11-xcb1 \
    libxcomposite1 \
    libxrandr2 \
    libxdamage1 \
    libgbm1 \
    libasound2 \
    libpangocairo-1.0-0 \
    netcat-openbsd \
    && rm -rf /var/lib/apt/lists/*

COPY pyproject.toml /app/
COPY src/django_project /app/

RUN chmod +x /app/entrypoint.sh
RUN pip install --upgrade pip pip-tools
RUN pip install .[docker]
RUN playwright install --with-deps

# Expose the port that the app runs on
EXPOSE 8000

CMD ["gunicorn", "core.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "3"]

This Dockerfile works, but it has some significant drawbacks. It installs all our Python dependencies, including development and testing libraries like pip-tools and playwright, directly into the final image. It also includes the system dependencies required to install Playwright's browsers, not just run them. The result is a larger-than-necessary image that contains tools we don't need in a production environment.

The Solution: Embracing Multi-Stage Builds

A multi-stage build is a powerful feature in Docker that allows you to use multiple FROM statements in a single Dockerfile. Each FROM instruction begins a new "stage" of the build. You can selectively copy artifacts—like compiled code or installed packages—from one stage to another, leaving behind everything you don't need.

Let's look at our new and improved multi-stage Dockerfile:

# ====================
# Stage 1: Builder
# ====================
FROM python:3.12-slim AS builder

WORKDIR /app

# Install system dependencies needed for building and running Chromium
RUN apt-get update && apt-get install -y --no-install-recommends \
    libglib2.0-0 libnss3 libx11-xcb1 libxcomposite1 libxrandr2 \
    libxdamage1 libgbm1 libasound2 libpangocairo-1.0-0 \
    libatk-bridge2.0-0 libgtk-3-0 fonts-liberation libxshmfence1 \
    libxcb1 xdg-utils netcat-openbsd \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

# Install uv (fast dependency resolver) and create virtualenv
RUN pip install --no-cache-dir uv \
    && python -m venv /venv

ENV PATH="/venv/bin:$PATH"

# Copy project dependency definition
COPY pyproject.toml /app/

# Install Python dependencies (including Playwright and its deps)
RUN uv pip install .[docker] --prerelease=allow \
    && playwright install chromium --with-deps

# ====================
# Stage 2: Runtime
# ====================
FROM python:3.12-slim

WORKDIR /app

# Install only necessary system dependencies for Chromium to run
RUN apt-get update && apt-get install -y --no-install-recommends \
    libglib2.0-0 libnss3 libx11-xcb1 libxcomposite1 libxrandr2 \
    libxdamage1 libgbm1 libasound2 libpangocairo-1.0-0 \
    libatk-bridge2.0-0 libgtk-3-0 fonts-liberation libxshmfence1 \
    libxcb1 xdg-utils netcat-openbsd \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

# Environment settings
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV PATH="/venv/bin:$PATH"
ENV PLAYWRIGHT_BROWSERS_PATH=/root/.cache/ms-playwright

# Copy the virtual environment and browser binaries from the builder
COPY --from=builder /venv /venv
COPY --from=builder /root/.cache/ms-playwright /root/.cache/ms-playwright

# Copy Django app code
COPY src/django_project /app/

# Make sure entrypoint script is executable
RUN chmod +x /app/entrypoint.sh

# Expose app port
EXPOSE 8000

# Entrypoint handles DB wait, migrations, and server start
CMD ["./entrypoint.sh"]

This Dockerfile is split into two distinct stages:

The builder Stage: This first stage is where the heavy lifting happens. We install all the necessary build tools and system libraries. We use the speedy uv installer to create a virtual environment and install all our Python dependencies. We also download and set up the Playwright browser binaries. This stage is a complete development and build environment.
The runtime Stage: This is the stage that will become our final production image. It starts from a fresh, clean python:3.12-slim image. Notice what we copy from the builder stage using the --from=builder flag:

- The entire Python virtual environment (/venv).

- The installed Playwright browser (/root/.cache/ms-playwright).

We then copy in our application code. The final image contains only our Python environment, browser binaries, our code, and the minimal system dependencies needed to run them—nothing else.

The Key Benefits of Going Multi-Stage

So, what have we gained from this approach?

Dramatically Smaller Image Sizes: By excluding build tools, -dev packages, and other intermediate files, the final image is significantly smaller. This means faster push/pull times from our container registry, quicker deployments, and reduced storage costs.
Enhanced Security: A smaller image has a smaller attack surface. By not shipping our build tools, compilers, or development dependencies, we remove potential vulnerabilities that could be exploited in a production environment.
Improved Caching and Faster Builds: Docker is smart about caching layers. In our multi-stage setup, if we only change our application code (src/django_project), Docker can use the cached builder stage without re-installing all the dependencies, speeding up subsequent builds.
Cleaner and More Maintainable Dockerfiles: Separating the build and runtime concerns makes the Dockerfile more organized and easier to understand. It clearly communicates what is needed to build the application versus what is needed to run it.

Conclusion

While a single-stage Dockerfile is a great way to get started, adopting a multi-stage build process is a crucial step toward creating professional, production-ready container images. For SpokaneTech.org, this switch has resulted in a more efficient, secure, and streamlined deployment pipeline for our Django application. If you're not already using multi-stage builds, we highly recommend giving them a try!

Building Spokane Tech: Part 8

David — Fri, 22 Aug 2025 22:42:14 +0000

Building Spokane Tech: Part 8

Welcome to part 8 of the "Building Spokane Tech" series! In this article, we'll discuss adding Docker and Docker Compose for running components of our service in containers.

Containerization has become an essential tool for modern web development, and Docker is at the forefront of this revolution. When developing a Django-based web application like ours, using Docker ensures consistency across development and deployed environments. By leveraging Docker Compose, we can efficiently manage multiple services required by our application.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Docker Compose

Docker Compose is a tool that allows you to define and manage multi-container Docker applications using a simple YAML file (docker-compose.yaml). It enables developers to run interconnected services, such as a web application, database, and message broker, with a single command. The Docker Compose basic concepts include:

Key Docker Compose Configuration Options

version: Defines the Compose file format version. In our case, we use "3.9", which is one of the latest stable versions.
services: Lists all the containers that make up the application. Each service runs in its own container.

Service Configuration Keys

image: Specifies the Docker image to use for the container. If the image is not found locally, Docker will pull it from a registry like Docker Hub.
build: Defines how to build the image from a Dockerfile. It usually includes:
- context: The directory containing the Dockerfile.
- dockerfile: The path to the specific Dockerfile used to build the image.
container_name: Gives a custom name to the container instead of a randomly generated one.
command: Overrides the default command specified in the Dockerfile, allowing you to run specific commands when the container starts.
env_file: Loads environment variables from an external .env file.
ports: Maps ports between the container and the host.
depends_on: Specifies service dependencies. A container will not start until its dependencies are up and running.

Volumes

Volumes store persistent data outside the container filesystem, ensuring data is not lost when containers are restarted or removed.

Our Services

Let's review the components in our system, each of these will be a service in our docker-compose.yaml file.

Django (Web Application) – The core application running on Gunicorn or the Django development server
PostgreSQL (Database) – Stores application data
Redis (Message Broker) – Used by Celery for task queuing
Celery Worker – Executes asynchronous tasks
Celery Beat – Handles scheduled tasks
Celery Flower – Provides a web UI for monitoring Celery tasks

Our docker-compose.yaml file

version: '3.9'

services:
  django:
    image: spokanetech-django:latest
    container_name: django
    env_file:
      - .env.compose
    build:
      context: ../..
      dockerfile: src/docker/Dockerfile
    command: ./entrypoint.sh
    ports:
      - "8080:8000"
    depends_on:
      - db
      - redis

  db:
    image: postgres:17
    container_name: postgres_db
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    env_file:
      - .env.compose

  redis:
    image: redis:7.2-alpine
    container_name: redis
    restart: unless-stopped
    ports:
      - "6379:6379"

  worker:
    image: spokanetech-django:latest
    container_name: worker
    env_file:
      - .env.compose
    build:
      context: ../..
      dockerfile: src/docker/Dockerfile
    command: celery -A core worker -l info
    depends_on:
      - redis
      - db

  beat:
    image: spokanetech-django:latest
    container_name: beat
    env_file:
      - .env.compose
    build:
      context: ../..
      dockerfile: src/docker/Dockerfile
    command: celery -A core beat -l info --scheduler django_celery_beat.schedulers:DatabaseScheduler
    depends_on:
      - redis
      - db

  flower:
    image: spokanetech-django:latest
    container_name: flower
    env_file:
      - .env.compose
    command: ["celery", "-A", "core", "--config=flowerconfig.py", "flower"]
    ports:
      - "5555:5555"
    depends_on:
      - redis
      - db

volumes:
  postgres_data:
  static_volume:

Running the Application

Docker Compose provides several commands to manage services. Here are the basics:

Building containers

To build the containers run:

docker-compose build

This builds images for the services defined in docker-compose.yaml using the specified Dockerfile. If an image already exists, it will only rebuild if changes are detected.

Starting containers

To start the containers run:

docker-compose up

This starts all services defined in docker-compose.yaml. It also automatically builds missing images if they are not found.

To run the containers in detached mode use:

docker-compose up -d

This runs containers in the background and allows applications to run persistently.

Stopping containers

To stop the containers use:

docker-compose down

This stops and removes all containers, networks, and volumes (if specified); it does not remove built images.

Rebuild and restart containers

To build the container when running, use:

docker-compose up --build

This rebuilds images before starting containers and ensures the latest changes in the Dockerfile are applied.

Accessing Services

All of our components are available on localhost on various their applicable ports:

Django App: http://localhost:8080
Celery Flower UI: http://localhost:5555
PostgreSQL: Connect via localhost:5432
Redis: Available on localhost:6379

Building Spokane Tech: Part 7

David — Sun, 13 Jul 2025 21:32:55 +0000

Building Spokane Tech: Part 7

Welcome to part 7 of the "Building Spokane Tech" series! In this article, we'll explore integrating Celery for scheduling tasks, executing work asynchronously, and monitoring task statuses.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Django Tasks and Celery

In a Django project, tasks.py is typically used to define background tasks that are executed asynchronously. This is common in applications where long-running or scheduled operations (such as sending emails, processing files, or performing API calls) should not block the main request-response cycle.

Celery is a distributed task queue that integrates well with Django to handle background jobs asynchronously. It allows you to schedule and execute tasks efficiently.

Creating Tasks

In our service we'll use tasks defined in the tasks.py file to perform data ingestion from eventbrite and meetup. We have a few different tasks defined, namely a 'parent' launcher task, and a separate 'child' task for performing the bulk of the work.

Parent Tasks

The parent task approach allows us to enable some basic control over what work gets queued for execution. For example, to run event ingestion for eventbrite groups we can first get a list of groups from our database, then launch individual jobs for each. Each job can succeed or fail independently of other jobs, and we'll have separate outputs and results.

Here's an example of a parent task:

@shared_task(time_limit=900, max_retries=0, name="web.launch_eventbrite_event_ingestion")
def launch_eventbrite_event_ingestion():
    """parent task for ingesting future events for tech groups on Eventbrite"""
    tech_group_list = TechGroup.objects.filter(enabled=True, platform__name="Eventbrite")
    for group in tech_group_list:
        job = ingest_future_eventbrite_events.s(group.pk)
        job.apply_async()

In the code above, the


 is a queryset of groups that are enabled and on the eventbrite platform. The

 ```ingest_future_eventbrite_events```

 is the task to be executed, and

 ```job.apply_async()```

 is the code to put the job on the queue for a background worker to consume.


## **Scheduling Tasks**

***Django Celery Beat***

Django Celery Beat is an extension for Celery that enables scheduling periodic 
tasks in a cron-like manner using the Django Admin panel. It allows you to manage scheduled tasks dynamically without modifying code.

In our service we use this to automatically run the parent tasks at regularly scheduled intervals, for example, every eight hours.


## **Monitoring Tasks**

***Celery Flower***

Celery Flower is a real-time web-based monitoring tool for Celery. It provides insights into task execution, workers, queues, and performance. Key features include:

Dashboard Overview
- Displays task statistics (Succeeded, Failed, Pending, etc.)
- Shows real-time execution of Celery tasks

Workers Monitoring
- Lists all active workers
- Shows worker status, uptime, and queue load

Task Monitoring
- Provides details of each task (Arguments, Status, Runtime, etc.)
- Allows you to retry failed tasks

Queues & Broker Inspection
- Displays Celery queues and their task load
- Shows messages in Redis or RabbitMQ queues

Building Spokane Tech: Part 6

David — Thu, 10 Jul 2025 04:00:50 +0000

Building Spokane Tech: Part 6

Welcome to part 6 of the "Building Spokane Tech" series! In this article, we'll look at how to scrape group and event data from meetup.com and eventbrite.com and populate our database accordingly.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Source Data

There are a couple platforms that tech groups are currently utilizing, with the majority being on meetup.com and eventbrite.com. We'll focus on collecting group and event data from those two platforms and address data sourcing from additional platforms as future needs dictate.

Getting data from these platforms from their sites into ours involves a couple steps, including capturing the data, parsing the data, and storing it in our database for use on the website.

Data Collection

Data collection for eventbrite and meetup will vary as eventbrite includes an API we can utilize for free, but meetup only has API access available for a fee. Do to this, we'll be web scraping.

The first step is to actually capture HTML from a page. In some cases this can be as simple as using the requests library like so:

html_content = requests.get("www.some_url.com")

This works okay for some pages, but not of others, where a timeout occurs or the expected html content is not found. This could be due to rate limiting, bot detection, or other server side measures. To make web capture more reliable, we're utilizing Playwright, an automation library for controlling websites. Playwright creates a browser instance for a more real-life interaction with data on a website. It also provides some more advance tools like network waits, and detection of html elements. This provides a more reliable means of collecting data, but is slower and requires a number of heavier dependencies.

Data Parsing

Once we've captured html content from a web page we'll need to parse out specific pieces of data. To accomplish this we're using BeautifulSoup, a Python library for pulling data out of HTML files.

For events on meetup we perform two capture and parse steps, one to get the list of events from the group page where links to future events are listed, and another to open and capture data from the detail page of each individual event.

Code/Utilities

Under the web app we have a utilities subdirectory with scrapper files for eventbrite and meetup. Utilities for additional platforms may be added in the future. There's also a html_utils file that contains code to capture html content with requests and playwright.
The directory structure looks like this:

.
├── src
│   ├── django_project
│   │   ├── core
│   │   │   └── ...
│   │   ├── tests
│   │   │   └── ...
│   │   ├── web
│   │   │   ├── utilities
│   │   │   │     └── scrapers
│   │   │   │         ├── eventbrite.py
│   │   │   │         └── meetup.py
│   │   │   ├── html_utils.py
│   │   │   └── ...

Building Spokane Tech: Part 5

David — Sat, 05 Jul 2025 19:55:11 +0000

Building Spokane Tech: Part 5

Welcome to part 5 of the "Building Spokane Tech" series! In this article, we'll explore the django views and templates used to server web pages in the initial web app.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Pages

The initial release of spokanetech.org includes a small set of pages, including the landing page, an about page, a calendar page, and event and group pages. Here is a brief description of each page:

Index: Home page of spokanetech.org

About: Informational page for spokanetech.org

Calendar: Monthly Calendar listing all events per month

Group List: Page listing all tech groups

Event List: Page listing all upcoming events

Group Detail: Page detailing a specific tech group

Event Detail: Page detailing a specific event

Views

The views are designed to support both htmx and non-htmx requests. A different template will be used accordingly when the "template_name" and "htmx_template_name" parameters are provided. Selection of the template is handled by the base class.

For our main entities we have a detail, list, and modal views to present data as applicable on web pages. Below is a snapshot of the tech group views. See github for the latest and complete code.


class TechGroupView(HtmxOptionDetailView):
    """Render detail page for a TechGroup instance"""
    model = TechGroup
    htmx_template_name = "web/partials/detail/group.htm"
    template_name = "web/full/detail/group.html"


class TechGroupsView(HtmxOptionMultiFilterView):
    """Render a list of TechGroup instances"""
    htmx_list_template_name = "web/partials/list/groups.htm"
    htmx_list_wrapper_template_name = "web/partials/list/wrapper_list.htm"
    htmx_template_name = "web/partials/marquee/groups.htm"
    queryset = TechGroup.objects.filter(enabled=True)
    template_name = "web/full/list/groups.html"


class TechGroupModalView(ModelDetailBootstrapModalView):
    """Render Bootstrap 5 modal displaying get details of a TechGroup instance"""
    modal_button_submit = None
    modal_size = "modal-lg"
    modal_template = "web/partials/modal/group_information.htm"
    modal_title = "Group Info"
    model = TechGroup

Templates

Templates are split into to sections, full and partials. Templates in the full subdirectory hold the template that extend the django base template and are used when the request to the page is not htmx. Templates in the partials subdirectory are used by htmx requests. We use a filename convention where full pages have the .html extension and partials have the .htm extension.

Here is the directory structure of the templates directories:

.
├── src
│   ├── django_project
│   │   ├── core
│   │   │   └── templates
│   │   │       └── base.htm
│   │   ├── web
│   │   │   └── templates
│   │   │       └── web
│   │   │           ├──  full
│   │   │           │    ├──  custom
│   │   │           │    │    ├──  about.html
│   │   │           │    │    ├──  calendar.html
│   │   │           │    │    └──  index.html
│   │   │           │    ├──  detail
│   │   │           │    │    ├──  event.html
│   │   │           │    │    └──  group.html
│   │   │           │    └──  list
│   │   │           │         ├──  events.html
│   │   │           │         └──  groups.html
│   │   │           │
│   │   │           └──  partials
│   │   │                ├──  custom
│   │   │                │    ├──  about.htm
│   │   │                │    ├──  calendar.htm
│   │   │                │    └──  index.htm
│   │   │                ├──  detail
│   │   │                │    ├──  event.htm
│   │   │                │    └──  group.htm
│   │   │                ├──  list
│   │   │                │    ├──  events.htm
│   │   │                │    └──  groups.htm
│   │   │                ├──  marquee
│   │   │                │    ├──  events.htm
│   │   │                │    └──  groups.htm
│   │   │                └──  modal
│   │   │                     ├──  event.htm
│   │   │                     └──  group.htm
│   │   └── ...

Building Spokane Tech: Part 4

David — Fri, 04 Jul 2025 01:29:14 +0000

Building Spokane Tech: Part 4

Welcome to part 4 of the "Building Spokane Tech" series! In this article, we look at the initial modeling for the web app.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Initial Django Models

The initial release of spokanetech.org will include five models in the web application: Event, Link, SocialPlatform, Tag, and TechGroup. Let's breakdown the role of each.

Event: A tech event hosted by a TechGroup

Link: A link associated with a TechGroup, such as the group home page

SocialPlatform: The platform hosting the event, such as Meetup or EventBright

Tag: An attributes of a Event or a TechGroup

TechGroup: A local tech group that organizes events

Each of these models use the HandyHelperBaseModel which includes created_at and updated_at datetime fields and a model manager that provides a number of useful methods.

Model Code

Below is a snapshot of the model code. See github for the latest and complete model code.

Event

class Event(HandyHelperBaseModel):
    """An event on a specific day and time"""
    name = models.CharField(max_length=255)
    description = models.TextField(blank=True)
    start_datetime = models.DateTimeField(
        auto_now=False, auto_now_add=False, help_text="date and time the event starts"
    )
    end_datetime = models.DateTimeField(
        auto_now=False, auto_now_add=False, null=True, help_text="date and time the event ends"
    )
    location_name = models.CharField(
        max_length=64,
        blank=True,
        help_text="name of location where this event is being hosted",
    )
    location_address = models.CharField(
        max_length=256,
        blank=True,
        help_text="address of location where this event is being hosted",
    )
    map_link = models.URLField(
        blank=True,
        help_text="link to a map showing the location of the event",
    )
    url = models.URLField(
        blank=True,
        help_text="URL to the event details",
    )
    social_platform_id = models.CharField(
        max_length=128,
        blank=True,
        help_text="unique identifier provided by the social platform hosting the event",
    )
    group = models.ForeignKey("TechGroup", blank=True, null=True, on_delete=models.SET_NULL)
    tags = models.ManyToManyField("Tag", blank=True)
    image = models.ImageField(upload_to="tech_events/", blank=True, null=True)

Link

class Link(HandyHelperBaseModel):
    """A link to a resource associated with a TechGroup or Event"""
    name = models.CharField(max_length=64, blank=True)
    description = models.CharField(max_length=255, blank=True)
    url = models.URLField()

SocialPlatform

class SocialPlatform(HandyHelperBaseModel):
    """The social platform (such as Meetup) that hosts the group and events"""
    name = models.CharField(max_length=64, unique=True, help_text="service where this tech group is hosted")
    enabled = models.BooleanField(default=True)
    base_url = models.URLField(blank=True, help_text="base url of provider")

Tag

class Tag(HandyHelperBaseModel):
    """A Tag that describes attributes of a Event"""
    value = models.CharField(max_length=64, unique=True, null=False)

TechGroup

class TechGroup(HandyHelperBaseModel):
    """A group that organizes events"""
    name = models.CharField(max_length=128, unique=True)
    description = models.TextField(blank=True)
    enabled = models.BooleanField(default=True)
    platform = models.ForeignKey("SocialPlatform", on_delete=models.CASCADE)
    icon = models.CharField(
        max_length=255,
        blank=True,
        help_text="Font Awesome CSS icon class(es) to represent the group.",
    )
    tags = models.ManyToManyField("Tag", blank=True)
    links = models.ManyToManyField("Link", blank=True)
    image = models.ImageField(upload_to="techgroups/", blank=True, null=True)

Building Spokane Tech: Part 3

David — Thu, 03 Jul 2025 03:52:27 +0000

Building Spokane Tech: Part 3

Welcome to part 3 of the "Building Spokane Tech" series! In this article, we go through steps to get the web app running locally on your machine or environment.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Prerequisites

git installed on system
python installed on system (3.10+ recommended)
access to the SpokaneTechWeb github repo: https://github.com/SpokaneTech/SpokaneTechWeb

Local Setup

Cloning the Repo

git clone git@github.com:SpokaneTech/SpokaneTechWeb.git

cd into the repo directory

cd SpokaneTechWeb

Create a python virtual environment

python -m venv venv

Activate the python virtual environment

for linux, mac, or wsl:

source venv/bin/activate

for powershell:

venv\Scripts\activate

Install the python dependencies

pip install .[dev]

** mac users may need to quote the pip install like so:

pip install '.[dev]'

Install playwright dependencies

Playwright is used for scraping web data from meetup.com

playwright install --with-deps

Create an .env.local file from the .env.template file and update contents as applicable

cp src/envs/.env.template src/envs/.env.local

cd to the django_project directory

cd src/django_project

Create a local database by running django migrations

python ./manage.py migrate

Create a local admin user

This command creates a superuser superuser in your database and adds the user to the admin group. The username is 'admin' and the password is 'admin'

python ./manage.py add_superuser --group admin

Populate some local test data

This command populates your local database with SocialPlatform and TechGroup data:

python ./manage.py runscript initialize_data

If you'd like to ingest some actual future events data from Eventbrite and Meetup, run this command:

python ./manage.py runscript ingest_events

Start the local demo server

python ./manage.py runserver

Explore the site

open a browser and navigate to http://127.0.0.1:8000

** you can stop the local demo server anytime via

ctrl + c

** you can login to the django admin page (at http://127.0.0.1:8000) using admin/admin

Enable Git Hooks (optional)

git config

To enable pre-commit code quality checks, update the location of git hooks with the following command:

git config core.hooksPath .github/hooks

Note: to make a commit with the precommit hooks temporarily disabled, run the following:

git commit --no-verify

Building Spokane Tech: Part 2

David — Wed, 02 Jul 2025 04:41:22 +0000

Building Spokane Tech: Part 2

Welcome to part 2 of the "Building Spokane Tech" series! In this article, we walk though the layout of the repository and detail what code lives where.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Repository Structure

Below is an overview of the repository structure.

.
├── src
│   ├── django_project
│   │   ├── core
│   │   │   └── ...
│   │   ├── tests
│   │   │   ├── integration
│   │   │   │   └── ...
│   │   │   ├── regression
│   │   │   │   └── ...
│   │   │   └── unit
│   │   │       └── ...
│   │   ├── web
│   │   │   └── ...
│   │   └── manage.py
│   ├── docker
│   │   └── Dockerfile
│   └── envs
│       └── .env.template
├── .dockerignore
├── .gitignore
├── LICENSE
├── README.md
└── pyproject.toml

File and Directory Descriptions

The Root Directory

Our root directory is lean and clean, with only the standard files for a git repo, including a .gitignore, a LICENSE file, a README.md file, and a pyproject.toml.
The pyproject.toml file contains our dependencies and tool configurations. This eliminates the need for additional configurations and requirements files.

The src Directory

All of our actual code lives under the src directory. The are subdirectories for the django code, docker files, and our environment files.

django_project

The django_project directory has core, the django project level directory, web, the django app directory, and tests, the location of all django unittests, with further subdirectories for test categories. Having tests at this level helps keep tests organized and allows for running tests by various scopes like for the entire project, for a specific django app, or specific area like models or apis.

docker

The docker directory will have applicable docker related files such as the Dockerfile, docker-compose.yaml, and .dockerignore.

envs

Any applicable .env files live here. There is a .env.template, .env.local, and other .env files as needed. Note, most .env files will not be checked into source control.

Building Spokane Tech: Part 1

David — Wed, 02 Jul 2025 04:01:07 +0000

Building Spokane Tech: Part 1

Welcome to the first part of the "Building Spokane Tech" series! In this article, we explore the tech stack, and design decisions.

See the live site at: https://www.spokanetech.org

See the latest code on: github

Requirements

For the first phase of our project we want to identify all the tech related community groups in the Spokane area, gather data about them and ingest and present events they host in one location. To make this happen we'll need a couple things.

web interface for displaying groups and events
a database to store the groups, event, and associated information
code that can gather data from applicable event sites
a means to execute that code on a regular cadence

Tech Stack

Our tech stack will be comprised of the follow technologies (accompanied with a brief description of each):

Python

Role: Primary programming language

Responsibility: Powers the application backend, providing a robust, readable, and flexible foundation for building web functionality and handling logic.

Django

Role: Web framework

Responsibility: Facilitates rapid development of secure and maintainable websites, handling URL routing, views, models, forms, and authentication. It integrates well with databases and supports REST API development.

Gunicorn

Role: WSGI HTTP server

Responsibility: Serves as the bridge between your Django application and the web server (e.g., Nginx). It efficiently handles multiple requests concurrently and scales well for production.

Redis

Role: In-memory data store

Responsibility: Used as a message broker for Celery tasks, caching, and real-time features like notifications or session management.

Postgres

Role: Database

Responsibility: Provides a reliable, scalable, and feature-rich relational database for storing application data, such as user information, product records, and transaction logs.

Celery

Role: Task queue

Responsibility: Manages asynchronous tasks (e.g., sending emails, processing files) by offloading time-consuming operations to background workers, improving responsiveness.

Celery Beat

Role: Scheduler for Celery tasks
Responsibility: Executes periodic tasks by scheduling them at specific intervals (e.g., daily reports or regular database cleanup).

HTMX

Role: Frontend interaction library

Responsibility: Enhances user experience by enabling server-side rendered dynamic content updates without full page reloads. Simplifies AJAX requests, WebSockets, and DOM updates.

Bootstrap 5

Role: CSS framework

Responsibility: Simplifies frontend design with a responsive, mobile-first grid system and pre-designed components such as buttons, modals, and navigation bars. Speeds up development and ensures a consistent, modern UI.

Building SpokaneTech.org

David — Tue, 01 Jul 2025 04:52:15 +0000

About the Spokane Tech Project

The Spokane Tech website is a project for the community made by the community. The aim of the project is to deliver a community resource for all things tech in the Inland Northwest while providing an opportunity for contributes to gain real-world experience in a shared open source project.

Why are we doing this?

Reason 1:

There is a thriving tech community in Spokane, but many members of our community are disconnected. With multiple tech groups on different platforms, such as meetup and eventbright, there are often events of interest happening that many tech enthusiasts are not aware of. The intent is to have a single resource that includes local tech groups and the events they host.

Reason 2:

Many developers in our community, especially those earlier in their career, have skills and drive, but haven't had the opportunity to work on a project in a real professional environment. For example, a developer could have great knowledge in coding, but hasn't yet had the first professional job or participated in project with milestones, project planning, code reviews, etc. The Spokane Tech project aims to provide this and give contributes a project they can reference for career development, personal portfolios, interviews, etc.

Initial Vision

What our project (and webapp) becomes will ultimately be dictated by members of the project and will likely evolve over time. Below are some details of the initial vision.

Phase One:

Have a web site that houses groups and events. Events may be manually or automatically added to our site. We will have views that list all the groups and events, as well as detail pages for each group and event. Ideally we'll also have a calendar view that can list all events and perhaps be filterable.

Phase Two:

Have event requests and suggestions capabilities. Here members can post a suggested events they want to give or have someone else give, and others can up/down vote the event (think reddit or stackoverflow). This can be used to prioritize events base on community interest. This can also serve as a living backlog of event ideas. Add labels to events, such as technical areas (frontend, scripting, ML, etc.) and topic levels (beginner/intermediate/etc.). With labels people can filter event based on interest and other criteria.

Phase Three:

Build member profiles. With profiles, we can have some basic metrics on things like career level, geographic location, interested and expertise. This data can help provide viability into the overall tech presence in Spokane and help drive event topics and location. This could also be a future resource to make available to local businesses and the community for things like contract work, etc. (There has been some outside interest in this type of resource)

Future goals:

The Spokane Tech project was started mostly by members of the Spokane Python User Group (SPUG), so naturally the first version of the website is based on python. In the future the project may be re-created in other languages/frameworks/etc. (such as Golang or Rust) as member interest dictates. This is intended to foster growth, knowledge-sharing, and exposure to different tech stacks and methodologies.

Interested in participating? Great! Read on...

Here are a few things you can do to get started.

Go to the site and explore. It's live at https://www.spokanetech.org
Look through the open issues and find one that interests you (issues tagged "good first issue" could be great candidates) on github
Read our blog to learn more about the project, follow development and design decisions, and step through the process of building the site.
Clone the repo to you machine and run locally, explore the code, break things, fix things, have fun. Step by step instructions are in the CONTRIBUTION doc on github.
Have a feature idea or found a bug? Create an issue on github.

Need more help or direction?

Join the Discord channel (best option)

or post a question on github

New to python, django, git, webdev? Reach out in the Discord channel and suggest a virtual meet. We'll schedule these on occasion, or as interest dictates. This can be used as q&a sessions, code paring, shared code reviews, or just follow along as a member works on an issue.