Two Scoops of Django Study Session 3

Continuing from last time, we went through Chapters 4-5 of Two Scoops of Django together to organize the basics of Django app design and settings management. Chapter 4 focused on the principle that apps should be kept small and clearly defined, while Chapter 5 covered how to separate settings and requirements with production environments in mind.

In Django App Design, we emphasized that each app should focus only on its own responsibility, and that apps within a project should be treated like feature-level libraries. App names should be as short as possible, consider the plural form of the core model, and take URL and PEP8 import conventions into account as well.

While internal app structure tends to look similar across most projects, we covered a common setup that includes the following modules:

• admin.py
• forms.py
• management/
• migrations/
• models.py
• templatetags/
• tests/
• urls.py
• views.py

In Settings Management, we noted that local settings should not go unversioned, and that sensitive information such as SECRET_KEY and various API keys must be kept separate from the repository. To achieve this, we introduced an approach of splitting settings into multiple environment-specific files under a settings/ directory, such as base.py, local.py, staging.py, test.py, and production.py.

As a way to separate configuration from code, we recommended using environment variables, and mentioned file-based alternatives like JSON, Config, YAML, and XML for cases where environment variables aren't available. We also covered splitting requirements files into multiple files, and noted that paths should not be hardcoded but instead handled relative to BASE_DIR.

In the deep-dive portion, we compared the pros and cons based on real company cases, and discussed the issues that arise when Secret Keys differ across servers, as well as the risks of a Secret Key leak. Through presentations and Q&A, the discussion extended into more realistic security and operational concerns.

After the study session, groups gathered to kick off a book management service project. Each group was structured around the same topic to make it easy to exchange feedback, and this time they completed repository creation, basic setup, and project naming.

• Team 1: ramen-prop
• Team 2: abook
• Team 3: booki3rd

In the next stage, each team will build on the same topic by adding features to develop their project further.