DEV Community: Zabby

QuerySet Wizardry: Making Django ORM My Playground

Zabby — Mon, 04 Aug 2025 19:29:21 +0000

Why filtering data with Django is part science, part sorcery and how the ORM helps me build features that users actually care about.

From `.filter()` to `.annotate()` My Early ORM Revelations

Django's ORM felt deceptively simple at first:

Expense.objects.filter(amount__gt=100)

That gave me a list of big expenses. Cool, but the real power of QuerySets came when I learned to chain, annotate, and optimize.

My Favorite Query Patterns

1. Chained Filters

Expense.objects.filter(user=request.user).filter(date__year=2025)

Keeps the logic readable while layering constraints.

2. Using `.values()` and `.values_list()`

Expense.objects.values("name", "amount")

Perfect for lightweight API responses or debugging structured data.

3. `.annotate()` with Aggregates

from django.db.models import Sum

User.objects.annotate(total_expense=Sum("expense__amount"))

Teaching tip: Describe annotations like “attaching post-it notes to each object” computed fields without changing the database.

4. `.select_related()` and `.prefetch_related()`

Speed tricks that saved me from N+1 query hell:

Expense.objects.select_related("user")

Or for many-to-many:

User.objects.prefetch_related("groups")

I use print(connection.queries) to profile query counts. Always fun to demo performance wins with just a few lines.

When I Use Raw SQL

Sometimes the ORM can’t express a complex join or a conditional CASE statement cleanly.

I reach for:

Expense.objects.raw("SELECT * FROM myapp_expense WHERE amount > %s", [100])

But I always encapsulate raw queries behind services or helper functions never scatter them across views.

QuerySet as a Language

One moment that changed my thinking: realizing QuerySets aren't just tools they’re a language. You compose meaning through chaining, nesting, and creative logic.

Eg: Filtering by focus tag and date range in my Minimalist Inbox:

Task.objects.filter(user=request.user).filter(tag="focus").filter(date__gte=today)

That translates a user’s need into code so directly, it feels like UX at the ORM level.

For Educators and Collaborators

Document your QuerySets: Use comments that explain business logic, not just syntax
Use helper methods:

def high_value_expenses(user):
    return Expense.objects.filter(user=user, amount__gt=500)

Teach the Zen of chaining: Show how each .filter() narrows the query’s intent

Final Thoughts

Django’s ORM isn't just for data it’s a canvas for logic, insight, and intention. Whether I’m building dashboards, analytics, or just helping users find what matters, QuerySets are my language of choice.

JWT in Django Rest Framework: Building Secure Auth from Scratch

Zabby — Mon, 04 Aug 2025 18:16:21 +0000

Why I moved beyond Django’s default auth system and how JWT unlocked modular, secure, and scalable authentication.

Why Not Django’s Default Login?

Let’s face it session-based auth is fine for traditional sites, but once I started building SPAs with React, things got clunky. I needed:

Stateless auth for mobile + frontend clients
Token refresh flow
Endpoint flexibility

Enter JSON Web Tokens (JWT) my passport to modern Django authentication.

Setup with Django Rest Framework + djangorestframework-simplejwt

Installation

pip install djangorestframework djangorestframework-simplejwt

Add to `settings.py`

INSTALLED_APPS = [
    'rest_framework',
]

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),
}

Core JWT Views

DRF SimpleJWT gives you these out of the box:

from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
)

urlpatterns = [
    path("api/token/", TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path("api/token/refresh/", TokenRefreshView.as_view(), name="token_refresh"),
]

But I prefer customizing TokenObtainPairSerializer to include user data in the token response.

Custom Serializer Example

Let’s enrich token responses:

from rest_framework_simplejwt.serializers import TokenObtainPairSerializer

class CustomTokenObtainPairSerializer(TokenObtainPairSerializer):
    @classmethod
    def get_token(cls, user):
        token = super().get_token(user)
        token['username'] = user.username
        token['role'] = user.role  # assuming custom field
        return token

    def validate(self, attrs):
        data = super().validate(attrs)
        data['user'] = {
            'username': self.user.username,
            'email': self.user.email
        }
        return data

Then wire into views:

from rest_framework_simplejwt.views import TokenObtainPairView

class CustomTokenObtainPairView(TokenObtainPairView):
    serializer_class = CustomTokenObtainPairSerializer

Auth-Protected Views

Using IsAuthenticated in any DRF view:

from rest_framework.permissions import IsAuthenticated

class ProfileView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request):
        return Response({"user": request.user.username})

The frontend just sends the token in the Authorization header:

Authorization: Bearer <your_jwt_token>

Teaching JWT Auth: My Favorite Metaphors

When explaining JWT to students, I use:

Passport Analogy: Token carries your identity; the server doesn’t need to remember you.
Sticker System: Each JWT is like a sticker pack with claims; don’t trade stickers with strangers.
Renewable Visa: Refresh tokens = long-term travel permits.

The goal is to demystify headers, expiry, and token rotation.

Final Thoughts

JWT turned my Django APIs into elegant, frontend-friendly systems. Stateless auth brings clarity, speed, and trust and when structured right, it’s modular, secure, and a joy to maintain.

Modularity or Madness? Structuring Django Apps for Sanity and Reuse

Zabby — Mon, 04 Aug 2025 17:59:41 +0000

Context: The Chaos of a Growing Codebase.

When I first started building with Django, I made the classic mistake: one monolithic views.py, bloated models.py, and templates spilling out like soup. As my apps grew, so did my frustration.

So I began treating my Django projects like Lego sets. Every piece should click into place and be swappable without breaking everything else.

My Modular Philosophy

Here’s the guiding approach I now use for every Django project:

1. Separate Concerns by App

Example structure for a productivity suite:

myproject/
├── users/          # handles auth & profiles
├── inbox/          # minimalist inbox assistant
├── expenses/       # expense tracking
├── jokes/          # humor module

Each app should answer ONE question. Avoid mixing views from multiple domains into one app. Think like an API designer, even if you’re building HTML.

2. Views: Break Them Down

I split views by functionality within each app:

expenses/
├── views/
│   ├── list.py
│   ├── create.py
│   ├── stats.py

Then wire them into views/__init__.py for import ease.

Why it works:

Easier to test each view file
Keeps logical flow visible
Lets me teach students incrementally.

3. Models: Keep It Clean and Thoughtful

Each model lives in models.py, but I often abstract logic out:

class Expense(models.Model):
    ...
    def formatted_amount(self):
        return f"${self.amount:.2f}"

# Or abstract to a utils file:
def format_amount(amount):
    return f"${amount:.2f}"

Rule of thumb: Business logic lives in separate helpers unless it absolutely belongs in the model.

4. Forms and Serializers Deserve Their Own Files

Organizing by type helps scaling:

expenses/
├── forms/
│   ├── expense_form.py
├── serializers/
│   ├── expense_serializer.py

It’s easier to debug or refactor without wondering where that nested validation rule lives.

5. URLs That Scale

Per-app urls.py should map clearly to views, and I often namespace them:

app_name = "expenses"

urlpatterns = [
    path("", views.list_expenses, name="list"),
    path("create/", views.create_expense, name="create"),
]

This makes reverse lookups readable and prevents collisions.

6. Apps.py and Meta Metadata

Don’t underestimate the value of apps.py and model Meta options:

class Expense(models.Model):
    class Meta:
        ordering = ['-date']

This kind of subtle config makes your apps feel polished to users even if it’s just one line.

Teaching Modularity

When I scaffold projects for students or collaborators, here’s what I do:

Prefix commits with the app name: expenses: add ExpenseForm for new entry UI.
Include README-per-app: Explain what each app does, and why it exists.
Use docstrings and comments as breadcrumbs: Guide future developers with insight, not just syntax.

Final Thoughts

Modularity isn’t just about clean code it’s about mental clarity, team velocity, and student empowerment. A well-structured Django repo teaches back. You build it once, but it teaches many.

From CRUD to Craft: My First Django Build.

Zabby — Mon, 04 Aug 2025 13:23:35 +0000

How Django taught me more than just CRUD and gave me a framework for thinking like a builder.

The Beginning

When I first ran django-admin startproject, I had no idea I was entering a full-blown ecosystem. I thought I’d be stitching together a few forms and models turns out I was architecting a universe.

Here’s how I got from zero to a functional Django app and why CRUD was just the appetizer.

Step-by-Step Build

1. Setting Up the Skeleton

django-admin startproject expense_tracker
cd expense_tracker
python manage.py startapp transactions

Key decisions:

I chose a project name that reflected real utility “Expense Tracker” because I wanted my learning to feel practical.
Started with a single app for clean scope.

2. Building Models First

Inside transactions/models.py:

from django.db import models

class Expense(models.Model):
    name = models.CharField(max_length=100)
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    date = models.DateField()

    def __str__(self):
        return f"{self.name}: {self.amount}"

What I learned:

Django’s ORM makes database tables feel intuitive.
Modeling isn’t just technical it’s philosophical. What does an “expense” mean in my world?

3. Migrating and Admin Setup

python manage.py makemigrations
python manage.py migrate

Then in transactions/admin.py:

from django.contrib import admin
from .models import Expense

admin.site.register(Expense)

Suddenly I had a beautiful admin panel. It felt like cheating in the best way.

4. Views, Forms, and Templates

Function-based views were my go-to:

def add_expense(request):
    if request.method == "POST":
        form = ExpenseForm(request.POST)
        if form.is_valid():
            form.save()
            return redirect("list_expenses")
    else:
        form = ExpenseForm()
    return render(request, "add.html", {"form": form})

Aha moments:

POST vs GET finally made sense once I wired them into views.
Forms gave me a crash course in validation and user experience

5. URLs and App Routing

In transactions/urls.py:

from django.urls import path
from . import views

urlpatterns = [
    path("add/", views.add_expense, name="add_expense"),
    path("", views.list_expenses, name="list_expenses"),
]

Then I included this in the main project’s urls.py:

path("expenses/", include("transactions.urls")),

Modular routing hit home here it felt like Django was teaching me how to design scalable software.

Lessons From My First Django App

The admin panel is more than a dashboard it’s a real tool for feedback and iteration.
Views and forms are where UX and logic shake hands.
Modular thinking starts early, even in urls.py.

Day 5: What MVC & MVT Finally Clicked for Me

Zabby — Tue, 01 Jul 2025 15:48:32 +0000

Today felt like solving one of those architecture riddles I kept brushing past. For the first time, I clearly understood how Django’s MVT (Model–View–Template) compares to the more commonly discussed MVC (Model–View–Controller) pattern.
Spoiler: it’s not as different as it sounds but Django definitely does things its own way.

What is MVC?

Model – Handles business logic and database structure.
View – The UI: what the user sees (HTML, CSS).
Controller – Logic that connects user input, the model, and the view

Classic, clean, and logical.

Django’s MVT — The Same but Different

Django swaps out some names and bakes a few decisions into the framework for you. Here's Django's version:

Model – Still your database structure and logic, powered by Django ORM
View – Unlike MVC, this is your Python function or class that handles requests and responses
Template – Where your HTML and front end presentation lives

In Django:

The View is the Controller

The Template is the View

And the Model stays the same

Visualizing the Architecture

Here's a side-by-side comparison I found helpful:

MVC                        Django MVT
--------------------      --------------------
Model       →  Model       (unchanged)
View        →  Template    (the UI)
Controller  →  View        (Python logic)

And here's a diagram that makes it even clearer:

This really helped me lock in Django's flow: Request → View (logic) → Model (if needed) → Template (response)

My “Aha” Moment

Here’s what made it click. I wrote this Django view:

def home(request):
    return render(request, 'home.html', {'msg': 'Welcome to Day 5!'})

Then connected it to home.html, where I rendered that msg variable. That’s when it hit me:

The View here is controlling the flow it’s the Controller.
The Template is responsible only for display just like MVC's View.

Suddenly, MVT made total sense.

Why This Mattered for Me

I used to misplace logic doing too much in templates or confusing Django’s terminology. Now:

I know where business logic belongs (views and models)
I respect Django’s separation of concerns
I debug faster, because I understand what each layer is responsible for

What I Built on Day 5

Created function-based views with context data
Connected views to templates using urls.py
Explored class-based views (will dive deeper soon)

This laid the groundwork for understanding more advanced patterns like mixins, CBVs, and reusable components.

Final Thought

🔍 View the source code on GitHub

“MVT helped me understand MVC more clearly.”

Funny how Django’s unique naming convention challenged me then clarified everything I’d half-learned in other frameworks.

If you’re new to Django or architecture in general, don’t stress. Let the code teach you. The more you build, the clearer it becomes.

Day 4: Building My First Django Project with Linked Apps (And Making It Look Good Too)

Zabby — Mon, 30 Jun 2025 16:37:35 +0000

As part of my 20 Days of Django journey, I tackled the challenge of building a project with two interconnected apps library and members and styled it up using Bootstrap. Here's how I structured it, step by step.

Todays Task

Use Django’s project + app architecture
Link two apps: library and members
Display templates for each

✅ Step 1: Installed virtualenv (if not already there) using the command

sudo apt install python3-venv

✅ Step 2: Created a virtual environment in my project folder

python3 -m venv venv

This created a venv/ folder containing an isolated Python environment complete with its own pip, python, and site-packages.

✅ Step 3: Activated the virtual environment

source venv/bin/activate

Once activated, my terminal prompt changed (it showed (venv)), and any packages I installed from that point forward were isolated to the project.
To deactivate it run the command: deactivate

To Install Django you run the command:

python -m pip install django

📁 Step One: Starting the Django Project.

django-admin startproject community
cd community

I saw this structure:

community/
    manage.py
    my_project/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py

📁 Step 2: Created Django Apps

Installed the required django apps i went with library & members.

python manage.py startapp library
python manage.py startapp members

Step 3: Creating Models That Talk to Each Other

`library/models.py`

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.CharField(max_length=100)

`members/models.py`:

from library.models import Book

class Member(models.Model):
    name = models.CharField(max_length=100)
    borrowed_book = models.ForeignKey(Book, on_delete=models.CASCADE)

I ran migrations to apply these changes:

python manage.py makemigrations
python manage.py migrate

🧠 Step 4: Simple Views

Each app got its own view to send data to the templates.

`library/views.py`:

def book_list(request):
    books = Book.objects.all()
    return render(request, 'library/books.html', {'books': books})

`members/views.py`:

def member_list(request):
    members = Member.objects.all()
    return render(request, 'members/members.html', {'members': members})

🖼️ Step 5: Linking Templates with Style

Both apps got their own templates directory. I used Bootstrap and a light CSS gradient background to make them feel cleaner and more polished.

Here’s a peek at books.html:

<body style="background: linear-gradient(to bottom right, #f2f2f2, #e6f7ff);">
  <div class="container mt-5 bg-white p-4 rounded shadow">
    <h2>📚 Library Books</h2>
    <ul>
      {% for book in books %}
        <li>{{ book.title }} by {{ book.author }}</li>
      {% endfor %}
    </ul>
    <a href="/members/">View Members</a>
  </div>
</body>

Same idea applied to members.html, with a flipped color scheme to visually separate them.

🌐 Step 6: URLs That Connect It All

Each app got its own urls.py, which I included in the main community/urls.py:

urlpatterns = [
    path('library/', include('library.urls')),
    path('members/', include('members.urls')),
]

Now I could browse:

/library/ to see the books

/members/ to view who borrowed what

Here is the output for the 2 apps

💡 What I Learned

🔍 View the source code on GitHub

Django's app structure scales cleanly even for a beginner
Connecting models across apps is smooth once you understand ForeignKey
Styling with Bootstrap + gradients makes Django feel like more than just a backend toy
Always create urls.py for each app before including them in project/urls.py (yes, I hit that error 😅)

This was my first time combining multiple Django apps into a meaningful, linked experience and styling it to be user-friendly. Now I’m thinking about adding forms for borrowing books, filtering members by book, and maybe even connecting it all to the admin panel with some customization. Day 4 wrapped with a big win, and I'm already hyped for Day 5.

Demystifying Django: How I Learned the Project Structure (Through My Own Debugging Lens)

Zabby — Mon, 30 Jun 2025 10:48:25 +0000

🧪 Setting Up My Virtual Playground: Virtual Environments on Kali

Before diving deep into Django, I knew I needed to isolate my Python dependencies. I didn’t want one project to break another just because they used different versions of a package. So I set up a virtual environment, which felt like creating a clean slate for Django to thrive.

Here’s exactly what I did on Kali Linux:

✅ Step 1: Installed virtualenv (if not already there) using the command

sudo apt install python3-venv

🗂️ Step 2: Created a virtual environment in my project folder

python3 -m venv venv

This created a venv/ folder containing an isolated Python environment complete with its own pip, python, and site-packages.

🚀 Step 3: Activated the virtual environment

source venv/bin/activate

Once activated, my terminal prompt changed (it showed (venv)), and any packages I installed from that point forward were isolated to the project.
To deactivate it run the command: deactivate

To Install Django you run the command:

python -m pip install django

📁 Step One: The Curious Case of the Double Folder

When I ran:

django-admin startproject my_project

I saw this structure:

my_project/
    manage.py
    my_project/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py

At first glance, the repetition felt like a mistake. But then I realized it’s deliberate:

The outer folder is your project root.
The inner folder contains your actual configuration files it's the heart of the system. Understanding this helped me navigate imports, app registration, and even deployment configurations more confidently.

🧠 The Brains of the Operation: `settings.py` and Friends

Inside the inner my_project/ folder, I found:
settings.py: The holy grail of configuration. Middleware, installed apps, static files you name it.

urls.py: Like Django’s GPS. Every route begins here.

asgi.py and wsgi.py: I saw them as protocol translators; one for async, one for traditional web servers.

Once I edited settings.py to connect my app and saw my static files load correctly, the structure felt alive—not abstract anymore.

⚙️ `manage.py`: My Swiss Army Knife

I underestimated manage.py at first. It looked like a throwaway script until I used it to:

Start the development server.
Create apps (startapp).
Run migrations.
Open the Django shell.

Now, I think of it as Django’s command-line gateway to everything project-related.

🧩 Apps: Where the Magic (Actually) Happens

When I ran:

python manage.py startapp blog

I got folders for:
models.py: My database design sandbox.
views.py: Where I learned request and response cycles the hard way.
admin.py: One of Django's most underrated features—customizing the admin interface became a fun side mission.

Having multiple apps that plug into a single project showed me how Django scales gracefully without becoming a monolith.

🎨 Templates, Static, and Media: The Visual Layer

It finally clicked that templates aren't just HTML they're Django-aware, with {% %} and {{ }} blocks for logic and data. Static files gave me some CSS headaches at first, but once I correctly configured STATICFILES_DIRS, things smoothed out. And media? It’s where user uploads go. Simple, but essential for anything dynamic.

🔚 Final Thoughts
Learning Django’s project structure wasn’t just about reading docs—it was about navigating errors, debugging misconfigured paths, and rewriting what I misunderstood the first time. Now, when I open a fresh Django project, it feels less like an unknown directory tree and more like a well-organized toolkit.

If you’re just starting with Django, don’t just copy and paste. Walk through the structure, question everything, and let the architecture teach you how Django thinks.

DAY 2: Learning All About Git & Github.

Zabby — Thu, 26 Jun 2025 07:24:31 +0000

🚀 1. Forking a Repository

Navigate to the repository you want to contribute to on GitHub.

Click the “Fork” button in the top right corner—this creates a copy under your account.

Clone your forked repo with git clone <your-forked-url>.

Work on it locally, then push your changes back to your fork.

🤝 2. Collaborating on GitHub

Create issues or comments to discuss tasks or bugs.

Assign roles or tasks (especially in teams).

Push branches and create pull requests to contribute your code.

Review PRs and resolve feedback collaboratively.

Keep communication transparent through comments and commit messages.

🔁 3. Creating a Pull Request (PR)

Create a new branch: git checkout -b feature-branch.

Make your changes and commit them: git add . and git commit -m "describe changes".

Push the branch: git push origin feature-branch.

Go to GitHub and click “Compare & pull request”.

Add a meaningful title and description, then submit it for review.

⚔️ 4. Resolving Merge Conflicts

Pull the latest changes: git pull origin main.

If conflicts appear, open the affected files they’ll be marked with <<<<<<< HEAD.

Manually resolve which code to keep or merge.

Add and commit the resolved files.

Push your branch again: git push.

🧪 5. Doing a Code Review

Go to the pull request, click “Files Changed”.

Review the code—check for clarity, performance, security, and readability.

Leave inline comments or approve/request changes.

Be respectful and specific—help make the code better, not just different.

📋 6. Managing GitHub Issues

Open an issue: title + detailed description.

Label it (bug, enhancement, etc.).

Assign it to contributors or yourself.

Comment updates or progress.

Close the issue once resolved or linked to a merged PR.

🧠 7. Core Git Commands I Learned

git init # Start version control in a folder.

git clone <url> # Copy a repo to your local machine.

git status # Check current changes.

git add . # Stage all changes.

git commit -m "message" # Save staged changes.

git pull # Get the latest code from a remote.

git push # Upload your commits to GitHub.

git checkout -b branch # Create/switch to a new branch.

git merge branch # Merge another branch into the one you're on.

📦 8. Pushing Changes to GitHub

Make sure your local branch is up to date: git pull origin main.

Add and commit your changes: git commit -m "message".

Push to the branch: git push origin your-branch.

Open or update a pull request with context about your changes.

DAY 1: Set Up Python, Git, Docker, VS Code & Configure Git with GitHub SSH on Kali Linux

Zabby — Wed, 25 Jun 2025 05:59:01 +0000

1. Install Python 3.12

Kali usually ships with Python preinstalled, but I have verified using the following command

python3.12 --version

2. Install Git 2.47

Here’s how to compile Git 2.47:

Installed dependencies:

sudo apt install -y make libssl-dev libghc-zlib-dev libcurl4-gnutls-dev libexpat1-dev gettext unzip

Download and build Git:

cd /usr/src
sudo curl -O https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.47.2.tar.gz
sudo tar -xvzf git-2.47.2.tar.gz
cd git-2.47.2
sudo make prefix=/usr/local all
sudo make prefix=/usr/local install

Verified Installation using:

git --version

3. Install Visual Studio Code

VS Code offers a .deb package for Debian-based distros like Kali so i downloaded it from the official website using the link "https://code.visualstudio.com/download".

Installed it using the command"

cd Downloads
sudo apt install ./code_1.101.1-1750254731_amd64.deb

& Lanched it using

code

then added a few extensions to better suit it for my python development.

4. Install Docker on Kali Linux

Kali already has a package named docker, but it’s not the container engine. You’ll want to install docker.io instead:

sudo apt install -y docker.io

Enable and start Docker

sudo systemctl enable docker --now

Then I Tested Installation:

docker --version

5. Configure Git with GitHub SSH

Generate Your SSH Key

ssh-keygen -t ed25519 -C "email"

Replace "email" with the email linked to your GitHub account.
When prompted, just press Enter to accept the default file location.
You can add a passphrase for extra security.

Add the Key to the SSH Agent & your private key

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Add Your Public Key to GitHub

cat ~/.ssh/id_ed25519.pub

Copy the entire output.
Paste your key and save.

Test your Setup

ssh -T git@github.com

Configure Git Settings

git config --global user.name "Your Full Name"
git config --global user.email "your_email@example.com"

At the end you should have installed

Python.
Git( & Configured it with GitHub SSH).
Docker Engine.
VS Code.

Enjoy!!

DEV Community: Zabby

QuerySet Wizardry: Making Django ORM My Playground

From .filter() to .annotate() My Early ORM Revelations

My Favorite Query Patterns

1. Chained Filters

2. Using .values() and .values_list()

3. .annotate() with Aggregates

4. .select_related() and .prefetch_related()

When I Use Raw SQL

QuerySet as a Language

For Educators and Collaborators

Final Thoughts

JWT in Django Rest Framework: Building Secure Auth from Scratch

Why Not Django’s Default Login?

Setup with Django Rest Framework + djangorestframework-simplejwt

Installation

Add to settings.py

Core JWT Views

Custom Serializer Example

Auth-Protected Views

Teaching JWT Auth: My Favorite Metaphors

Final Thoughts

Modularity or Madness? Structuring Django Apps for Sanity and Reuse

Context: The Chaos of a Growing Codebase.

My Modular Philosophy

1. Separate Concerns by App

2. Views: Break Them Down

3. Models: Keep It Clean and Thoughtful

4. Forms and Serializers Deserve Their Own Files

5. URLs That Scale

6. Apps.py and Meta Metadata

Teaching Modularity

Final Thoughts

From CRUD to Craft: My First Django Build.

How Django taught me more than just CRUD and gave me a framework for thinking like a builder.

The Beginning

Step-by-Step Build

1. Setting Up the Skeleton

2. Building Models First

3. Migrating and Admin Setup

4. Views, Forms, and Templates

5. URLs and App Routing

Lessons From My First Django App

Day 5: What MVC & MVT Finally Clicked for Me

What is MVC?

Django’s MVT — The Same but Different

Visualizing the Architecture

My “Aha” Moment

Why This Mattered for Me

What I Built on Day 5

Final Thought

Day 4: Building My First Django Project with Linked Apps (And Making It Look Good Too)

Todays Task

To Install Django you run the command:

📁 Step One: Starting the Django Project.

📁 Step 2: Created Django Apps

Step 3: Creating Models That Talk to Each Other

library/models.py

members/models.py:

I ran migrations to apply these changes:

🧠 Step 4: Simple Views

library/views.py:

members/views.py:

🖼️ Step 5: Linking Templates with Style

🌐 Step 6: URLs That Connect It All

Demystifying Django: How I Learned the Project Structure (Through My Own Debugging Lens)

🧪 Setting Up My Virtual Playground: Virtual Environments on Kali

To Install Django you run the command:

📁 Step One: The Curious Case of the Double Folder

🧠 The Brains of the Operation: settings.py and Friends

⚙️ manage.py: My Swiss Army Knife

🧩 Apps: Where the Magic (Actually) Happens

🎨 Templates, Static, and Media: The Visual Layer

DAY 2: Learning All About Git & Github.

🚀 1. Forking a Repository

🤝 2. Collaborating on GitHub

🔁 3. Creating a Pull Request (PR)

⚔️ 4. Resolving Merge Conflicts

🧪 5. Doing a Code Review

📋 6. Managing GitHub Issues

From `.filter()` to `.annotate()` My Early ORM Revelations

2. Using `.values()` and `.values_list()`

3. `.annotate()` with Aggregates

4. `.select_related()` and `.prefetch_related()`

Add to `settings.py`

`library/models.py`

`members/models.py`:

`library/views.py`:

`members/views.py`:

🧠 The Brains of the Operation: `settings.py` and Friends

⚙️ `manage.py`: My Swiss Army Knife