Forem: obonyodorice

Building a Basic Django App: A Hands-On MVT Example with Attachee Data

obonyodorice — Wed, 02 Jul 2025 14:31:23 +0000

As a developer, one of the most rewarding experiences is seeing your data come to life on a web page. Recently, I set out to build a simple Django application to demonstrate the fundamental concepts of the Model-View-Template (MVT) architecture. My goal was straightforward: define a model for student attachee, populate it with some data, retrieve that data using a Django view, and then elegantly display it in an HTML table using Django's templating engine. This exercise perfectly illustrates how Django structures web applications and handles the flow of data from the database to the user's browser.

Let's break down each step of the process.

1. The Model: Defining Our Data Structure (The 'M' in MVT)
The 'M' in MVT stands for Model. In Django, a Model is a Python class that inherits from django.db.models.Model. It defines the structure of your data, essentially mapping to a table in your database. Each attribute of the Model class represents a field (a column) in that database table.

For our attachés application, I needed to store information such as their name, email, phone number, the department they are attached to, and their university. Here's how I defined the Attachee model in first_app/models.py:

from django.db import models

class Attache(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField(unique=True) 
    phone = models.CharField(max_length=20, blank=True, null=True) 
    department = models.CharField(max_length=100)
    university = models.CharField(max_length=100)
    date_added = models.DateTimeField(auto_now_add=True)

    def __str__(self):

        return f"{self.name} from {self.university}"

After defining the model, I ran the standard Django commands to create the database table:

python manage.py makemigrations
python manage.py migrate

These commands translate the Python model definition into database schema changes and apply them. Then, I accessed the Django admin (after creating a superuser) to quickly add a few sample Attachee records to the database for testing.

2. The View: Retrieving and Preparing Data (The 'V' in MVT)
The 'V' in MVT refers to the View. In Django's context, the View is a Python function or class that receives a web request, interacts with the Model to fetch or manipulate data, and then prepares a context dictionary (data) to be passed to a template. It's the brain that orchestrates what data is needed and how it's presented.

My goal was to display all attachés. So, my view needed to query the Attachee model and retrieve every record.

from django.shortcuts import render
from .models import Attachee

def attache_list(request):
    all_attachees = Attachee.objects.all()

    context = {
        'attachees': all_attachees,
        'page_title': 'List of All Attachees' 
    }

    return render(request, 'myapp/attache_list.html', context)

3. The Template: Presenting the Data (The 'T' in MVT)
The 'T' in MVT stands for Template. This is the presentation layer, typically an HTML file with Django's powerful template language embedded within it. Its job is to display the data received from the view in a user-friendly format. I chose a simple HTML table to showcase the attaché data.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ page_title }} - Attache Management</title>
    <style>
        body { font-family: Arial, sans-serif; margin: 20px; }
        table { width: 100%; border-collapse: collapse; margin-top: 20px; }
        th, td { border: 1px solid #ddd; padding: 8px; text-align: left; }
        th { background-color: #f2f2f2; }
        h1 { color: #333; }
        .no-data { text-align: center; color: #888; margin-top: 30px; }
    </style>
</head>
<body>
    <h1>{{ page_title }}</h1>

    {% if attaches %} 
    <table>
        <thead>
            <tr>
                <th>Name</th>
                <th>Email</th>
                <th>Phone</th>
                <th>Department</th>
                <th>University</th>
                <th>Date Added</th>
            </tr>
        </thead>
        <tbody>
            {% for attachee in attachees %}
            <tr>
                <td>{{ attachee.name }}</td> {# Accessing attributes of the current 'attache' object #}
                <td>{{ attachee.email }}</td>
                <td>{{ attachee.phone|default:"N/A" }}</td> 
                <td>{{ attachee.department }}</td>
                <td>{{ attachee.university }}</td>
                <td>{{ attachee.date_added|date:"F d, Y P" }}</td> 
            </tr>
            {% endfor %}
        </tbody>
    </table>
    {% else %} 
        <p class="no-data">No attachee records found.</p>
    {% endif %}

</body>
</html>

4. The URL: Mapping Requests to Views (The Router)
The URL configuration, or URLconf, acts as the router for our application. It's responsible for mapping specific URL patterns to the correct view functions or classes.

Since I had configured the project's main urls.py to include the URLs from my myapp:

Next, I defined the specific URL pattern within first_app/urls.py to point to our attachee_list view:

from django.urls import path
from . import views 

urlpatterns = [
    path('attachee_list/', views.attachee_list, name='attachee_list'),
]

The Final Result: Data on Display
With these pieces in place, when I navigated my browser to http://127.0.0.1:8000/first_app/attachee_list/ (assuming Django's development server is running), the following happened:

The browser sent an HTTP GET request to /first_app/attachee/.

Django's URL dispatcher in my_project/urls.py matched first_app/attachee/ and directed the request to first_app.urls.

In first_app/urls.py, the path('attachee_list/') pattern matched the remaining empty string and called the attachee_list view function.

The attachee_list view queried the database (Attachee.objects.all()) to fetch all attaché records.

It then rendered the first_app/attachee_list.html template, passing the all_attachee data in the context.

The template engine iterated over the attachee data, populated the HTML table rows, and applied any specified filters.

Finally, the rendered HTML was sent back to the browser, displaying a clean, organized table of all our attachee data.

This simple example perfectly encapsulates the power and elegance of Django's MVT architecture. The clear separation of concerns—data definition in the Model, business logic and data preparation in the View, and presentation in the Template—makes the application easy to understand, maintain, and extend. It's a foundational concept that every Django developer masters, paving the way for building more complex and dynamic web applications.

Building a Multi-App Django Project: A Tech Attachee's Journey

obonyodorice — Mon, 30 Jun 2025 15:01:32 +0000

As a tech attachee, understanding modern web development frameworks is crucial. One of the most powerful and versatile is Django, a high-level Python web framework that encourages rapid development and clean, pragmatic design. My recent task was to demonstrate Django's modularity by creating a single project with two distinct applications, each serving its own unique web page. This article outlines the step-by-step process I followed to achieve this.

The Vision: Modularity and Clarity

The core idea behind this exercise was to showcase how Django projects can be broken down into smaller, manageable applications. This approach promotes reusability, simplifies maintenance, and allows different functionalities to live in their own self-contained environments. My goal was to build a my_project that housed a first_app and a second_app, each with a dedicated browser page.

Phase 1: Setting the Foundation
The journey began with the fundamental steps of any Django project:

Installing Django: First, ensuring Django was installed in my environment was paramount. A simple pip install django got the framework ready.

Project Initialization:With Django installed, I created the main project directory using django-admin startproject my_project. This command laid out the essential project structure, including the core settings.pyand urls.pyfiles.

my_project/
├── my_project/
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py  
│   ├── urls.py      
│   └── wsgi.py
└── manage.py

Navigating into the Project:I then cd my_project to move into the newly created project root, ready for the next steps.

Phase 2: Crafting the Applications
The next crucial step was to generate the individual applications within my main project. Django's startapp command makes this straightforward:

Creating first_app: I executed python manage.py startapp first_app. This command generated the basic directory structure and files for my first independent application.

Creating second_app**: **Following the same pattern, python manage.py startapp second_app brought my second application into existence. At this point, my project directory began to take shape, clearly showing the core folder alongside the first_app and second_app directories, all within the main MY_PROJECT root.

my_project/
├── my_project/
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── first_app/
│   ├── migrations/
│   ├── templates/
│   │   └── first_app/
│   │       └── index.html
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── second_app/
│   ├── migrations/
│   ├── templates/
│   │   └── second_app/
│   │       └── home.html
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
└── manage.py

NOTE:
So, while the name my_project is repeated, they represent two different things: one is the top-level directory, and the other is the actual Python package that contains your project's main configuration.

To avoid the repetition in the folder name, when you initially create a Django project, you can use a slightly different command:

django-admin startproject config .

(You can name that inner folder anything that is a valid Python package name. Common alternatives you'll see in the Django community include:

core: Often used for central or core project settings and utilities.

project: A straightforward name indicating it holds the project-level files.

main: Another simple and descriptive option.)

If you run this command from an empty directory, it will create the manage.py and the config (inner project folder) directly inside your current directory, avoiding the outer my_project folder name. However, the default django-admin startproject my_project is very common and usually doesn't cause issues once you understand the distinction.

Phase 3: Connecting the Pieces (Configuration)
A raw project and applications don't work together automatically. They need to be configured:

Registering Apps in settings.py: I opened my_project/my_project/settings.py. Under the INSTALLED_APPS list, I added 'first_app' and 'second_app'. This tells Django to recognize and load these applications within the project. I also verified APP_DIRS: True was set in the TEMPLATES configuration, ensuring Django would look for templates inside each app's templates folder.

Routing URLs in Project urls.py: The my_project/my_project/urls.py file is the project's central traffic controller. I modified it to include the URL patterns of my new applications:

# my_project/core/urls.py
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('first-app/', include('first_app.urls')),
    path('second-app/', include('second_app.urls')),
]

This setup ensures that any request starting with /first-app/ is directed to first_app's own URL patterns, and similarly for /second-app/.

Phase 4: Building App-Specific Pages
Each application needed its own view and template to display a unique page:

first_app Logic and Display:

I created my_project/first_app/urls.py to define the specific URL for this app (e.g., path('', views.index, name='index')).

In my_project/first_app/views.py, I wrote a simple index function that renders a template: return render(request, 'first_app/index.html').

Finally, I created the index.htmlfile inside my_project/first_app/templates/first_app/. This HTML included a welcoming message.

second_app Logic and Display:

I followed the same pattern, creating my_project/second_app/urls.py with a path('', views.home, name='home').

The my_project/second_app/views.py contained a home function to render its template: return render(request, 'second_app/home.html')

The home.html file was placed in my_project/second_app/templates/second_app/, similar to the first app, ensuring clear separation and containing a link back to the first app.

Phase 5: Bringing it All to Life
With all the code in place, the final steps were to get the server running:

Database Migrations: Running python manage.py makemigrations and python manage.py migrate ensured Django's built-in database setup was complete, even though my apps didn't use models yet.

Starting the Development Server:From the my_project root, python manage.py runserver launched Django's development server.

The Outcome: Two Live Applications!

Upon navigating to http://127.0.0.1:8000/first-app/ and http://127.0.0.1:8000/second-app/ in my browser, I was greeted with two distinct web pages, each served by its respective Django application. The navigation links between them worked , confirming the successful integration of components within a single Django project.

This exercise solidified my understanding of Django's project structure, URL routing(How web addresses work), view logic, and template rendering(how different parts of a website can show their own pages) – essential skills for any aspiring tech attaché. It highlighted how Django empowers developers to build scalable and organized web applications by embracing a modular design.

My Dive into Version Control: Git & GitHub for Collaborative Coding Author: Dorice

obonyodorice — Thu, 26 Jun 2025 11:48:13 +0000

Unlocking Teamwork: My Journey from Code Chaos to Collaborative Confidence with Git & GitHub

Hey there, future coders! Have you ever tried to save your code and ended up with file names like "my_project_final_final_really_final.py"? Or maybe you've worked on a project with a friend and accidentally messed up their work? Yeah, I've been there!

Learning to manage my code was a huge step for me. That's when I found Git and GitHub. These tools have made my coding life so much easier, whether I'm working alone or with a team. They're like a superhero sidekick for your code!

In this article, I'm going to explain exactly what I learned about Git and GitHub, and how these cool features like sharing code, fixing mistakes, and working together help me. Let's make your coding smoother!

Understanding the Backbone: What is Version Control?(and Why Git is So Cool)

Think of Version Control like a magic journal for your code. Every time you make a change, it writes it down. This means you can:

- See all changes:
Exactly what changed, who changed it, and when.
- Go back in time:
If you break something, you can easily go back to an older version that worked.
- Work together:
Multiple people can work on the same project without messing each other up.
Before Git, I used to just save many copies of my files, which got super confusing. Git is special because it's "Distributed." This means everyone working on the project gets a full copy of the entire code history on their own computer. So, if the internet goes out or the main project server has a problem, I still have everything on my laptop! It's like having your own personal backup system for every change.

GitHub: Where My Code Projects Live Online

Git helps me track my code on my computer, but GitHub is the website where I put my code online. It's like a big online home for all my Git projects.

GitHub is where I:

Store my projects so I can access them from any computer.

Find and help with other people's open-source code (code that anyone can use and improve).

Connect with other coders around the world.

Cool Git & GitHub Tricks I Use Every Day

Here's how I use some of the best features of Git and GitHub in my coding projects:

1. Forking: Making My Own Copy of a Project

- What I learned:
"Forking" a project on GitHub means I make my own exact copy of it. This copy lives in my own GitHub account and is completely separate from the original.
- How I use it:
If I see a cool project online that I want to try improving, or if I want to contribute to someone else's code without touching their main work, I fork it. This gives me a safe space to play around and make my own changes.

git clone https://github.com/Dorice/your-forked-project.git

2. Teamwork: Coding Together Without Chaos

- What I learned:
Git and GitHub make it super easy for many people to work on the same code at the same time without causing problems. They keep track of who changed what and help bring all the different changes together.
- How I use it:
In a team, everyone works on their own separate "branches" (like separate roads leading to the same destination). Git keeps track of everyone's changes, and GitHub helps us combine them smoothly. It's much better than accidentally overwriting someone else's work!

3. Pull Requests (PRs): "Hey, Check Out My Work!"

- What I learned:
A "Pull Request" is basically me telling the main project owner, "Hey, I've made some changes, and I think they're good! Can you please 'pull' them into the main project?"
- How I use it:
After I finish making my changes on my local computer and send them to my GitHub copy, I go to GitHub and create a Pull Request. This isn't just a message! It's a place where:

I describe what I changed and why.

I ask others to look at my code (this is called "code review").

After you've saved your changes locally and sent them to GitHub:

git push origin my-new-feature

Then, go to GitHub to create the Pull Request!

4. Code Review: Getting Helpful Advice

- What I learned:
"Code review" is when other smart people look at my code in a Pull Request. They check it for mistakes, suggest better ways to do things, and make sure it fits the project's style.
- How I use it:
This part is awesome for learning! Before my code officially becomes part of the main project, my teammates give me feedback. They might:

Ask me to explain parts of my code.

Suggest a simpler way to write something.

Even spot tiny errors I missed. This helps me write much better code!

5. Merge Conflicts: When Two Changes Collide (and How I Fix Them)

- What I learned:
A "merge conflict" happens when two different people change the exact same lines in the same file at the same time. Git gets confused because it doesn't know which change to keep.
- How I handle them:
When I run into a merge conflict (and trust me, it happens to everyone!), Git will show me which files have problems. I open these files in my code editor (VS Code has built-in tools that really help here!). The editor shows me clearly where the different changes are. I then decide which changes to keep, or I combine them myself. After I fix it, I tell Git I'm done: git add the file, and then git commit the fix. It's a common problem, but easy to learn how to solve!

6. GitHub Issues: My To-Do List & Bug Tracker

- What I learned:
"GitHub Issues" are like digital sticky notes or a to-do list for your project. They're great for keeping track of tasks, bugs, or new ideas.
- How I use them:
For every project, I use Issues to:

Report bugs:Explain any problems I find.
Suggest features: Write down ideas for new things the project could do.
Assign tasks: Give tasks to myself or other team members.
Keep organized: Use labels (like bug, new feature, urgent) to sort them.
Track progress: I can link my Pull Requests to an Issue, so when my code is added, the Issue automatically closes, showing that task is done!

7. Basic Git Commands: My Everyday Tools

These are the simple commands I type into my terminal almost every day:

git clone [website-address]: This downloads a copy of a project from GitHub to my computer.

git status: Shows me what changes I've made on my computer, what's ready to be saved, and what's new.

git add [file-name] or git add .: This prepares my changes (a specific file or all changes) to be saved.

git commit -m "A short message about my changes": This saves the prepared changes to my project's history on my computer. I always write a clear message so I remember what I did!

git branch [new-branch-name]: Makes a new separate line of work for me.

git checkout [branch-name]: Switches me to a different line of work.

git pull origin [branch-name]: Gets the latest changes from the online project (GitHub) and brings them to my computer. Important: I always do this before starting new work!

git push origin [branch-name]: This sends my saved changes from my computer up to the online project (GitHub).

8. Pushing Changes to GitHub: Sending My Work Online

- What I learned
: The git push command is how I send all the changes I've saved on my computer up to my project on GitHub.
- How I use it:
Once I'm happy with my changes (after adding and committing them), I type git push origin my-feature-branch to upload them. This makes my work visible to my team and also acts as a safe backup online.

git push origin my-new-feature-branch

Wrapping Up: Your Path to Super Coding!

Learning Git and GitHub might seem like a lot at first, but trust me, it's totally worth it! It's given me a clean, safe, and super easy way to manage my coding projects and work with others. From making sure my code is always backed up to easily sharing new features and fixing bugs, these tools are now a must-have for me.

Don't be scared of things like merge conflicts – they're just little puzzles you'll learn to solve!

If you want to practice, the GitHub Skills website is an amazing place to start. They have fun, hands-on lessons that will help you learn by doing.

Go out there, build awesome stuff, and code with confidence! Happy coding!

My Journey to a Seamless Python Dev Environment (and How You Can Too!) Author:"DevDorice"

obonyodorice — Tue, 24 Jun 2025 20:37:12 +0000

Introduction

Hey everyone! I recently went through the process of setting up my Python development environment, and honestly, it can feel a bit overwhelming with all the tools out there. But I've found a flow that really works for me, integrating Git, Docker, WSL (since I'm on Windows), and a super-smooth SSH connection to GitHub. I want to share exactly how I did it, step-by-step, so you can set up your own efficient workspace too!.

Prerequisites
Before we dive in, here's what you'll need:

- A Computer:

Running Windows 10 or higher (for WSL instructions) or a macOS/Linux distribution

- An Internet Connection:

To download the necessary software.

- Basic Computer Skills:

Familiarity with navigating your operating system and using a terminal or command prompt.

- A GitHub Account (Optional but Recommended):

If you plan to host your code on GitHub. You can sign up for free at https://github.com/join.

Let's dive into how I got everything configured.
1. Picking My Tools: Editor, Python, & Git

Code Editor

Choose one and install it.

PyCharm Community Edition(Recommended for Python):
Download from:

https://www.jetbrains.com/pycharm/download/,

VS Code (Versatile):
Download from:

https://code.visualstudio.com/download.

I chose VS Code and Downloaded. Sometimes I need something lighter or for other languages, and that's where VS Code shines. It's incredibly versatile and customizable.

Install Git for version control.

I Downloaded Git:

https://git-scm.com/downloads

Follow the installer instructions.
Verify Installation: Open the terminal and run:
git --version

Installing Python 3.10+: My Language of Choice

Download Python: I downloaded the latest Python from

https://www.python.org/downloads/

During installation, I ensure I check the "Add Python to PATH" option.

Verify Installation in the terminal with python --version and git --version.

4. Setting Up WSL: My Linux Playground on Windows

How I installed it:

I opened PowerShell as Administrator.
Execute the installation command: wsl --install
My computer needed a restart after that, so I let it do its thing.
After restart, I follow the prompts to set up the Linux username and password.
I then set up the Linux environment.

5.Installing Docker Desktop:

How I installed it:

I downloaded Docker Desktop from

docker.com.

It uses WSL2 for great performance.

After installation, I opened my terminal (or my WSL terminal) and ran: docker --version to check it was ready.

6. Configuring Git with GitHub SSH:

Checking for existing keys:

I first checked if I already had SSH keys lying around. I ran:
ls -al ~/.ssh.

If I saw files like id_ed25519.pub or id_rsa.pub, I would have skipped to next step. But, I generated a new one for a fresh setup.

Generating a new SSH key (if I didn't have one):

This command creates a new, strong SSH key. I made sure to replace "your_email@example.com" with the email linked to my GitHub account.
ie... ssh-keygen -t ed25519 -C "your_email@example.com"

When it asked for a file location, I just pressed Enter to accept the default (~/.ssh/id_ed25519).

Copying my public SSH key:

I needed to get my public key so I could paste it into GitHub. I displayed it with:
cat ~/.ssh/id_ed25519.pub

Then, I carefully copied the entire output (starting from ssh-ed25519 or ssh-rsa all the way to my email address)

Adding the SSH key to my GitHub account:

I went to [https://github.com/settings/keys] and logged into my GitHub account.

I clicked on the "New SSH key" (or "Add SSH key") button.
I gave it a meaningful Title.
Then, I pasted my copied public key into the "Key" field.

Finally, I clicked "Add SSH key". GitHub might ask for password one last time to confirm.

Conclusion

That's the rundown of how I set up my Python development environment! It might seem like a few steps, but each one contributes to a smoother and more efficient coding experience. With your chosen editor, Python ready to go, Git for version control, WSL and Docker for consistent environments, and secure SSH access to GitHub, you're well-equipped to tackle any Python project. ~~Happy ~~coding!