- Implemented custom form widgets for date, time, and datetime fields with DaisyUI styling. - Created utility functions for formatting dates, times, and numbers according to user preferences. - Developed views for profile settings, API key management, and notifications, including health check endpoints. - Added URL configurations for Themis tests and main application routes. - Established test cases for custom widgets to ensure proper functionality and integration. - Defined project metadata and dependencies in pyproject.toml for package management.
96 lines
3.4 KiB
Markdown
96 lines
3.4 KiB
Markdown
## Red Panda Approval™
|
|
|
|
This project follows Red Panda Approval standards - our gold standard for Django application quality. Code must be elegant, reliable, and maintainable to earn the approval of our adorable red panda judges.
|
|
|
|
### The 5 Sacred Django Criteria
|
|
|
|
1. **Fresh Migration Test** - Clean migrations from empty database
|
|
2. **Elegant Simplicity** - No unnecessary complexity
|
|
3. **Observable & Debuggable** - Proper logging and error handling
|
|
4. **Consistent Patterns** - Follow Django conventions
|
|
5. **Actually Works** - Passes all checks and serves real user needs
|
|
|
|
### Standards
|
|
|
|
# Environment
|
|
Virtual environment: ~/env/PROJECT/bin/activate
|
|
Python version: 3.12
|
|
|
|
# Code Organization
|
|
Maximum file length: 1000 lines
|
|
CSS: External .css files only (no inline/embedded)
|
|
JS: External .js files only (no inline/embedded)
|
|
|
|
# Required Packages
|
|
- Bootstrap 5.x (no custom CSS unless absolutely necessary)
|
|
- Bootstrap Icons (no emojis)
|
|
- django-crispy-forms + crispy-bootstrap5
|
|
- django-allauth
|
|
|
|
# Testing
|
|
Framework: Django TestCase (not pytest)
|
|
Minimum coverage: XX%? (optional)
|
|
|
|
### Database Conventions
|
|
|
|
# Development vs Production
|
|
- Development: SQLite
|
|
- Production: PostgreSQL
|
|
- Use dj-database-url for configuration
|
|
|
|
# Model Naming
|
|
- Model names: singular PascalCase (User, BlogPost, OrderItem)
|
|
- Related names: plural snake_case with proper English pluralization
|
|
- user.blog_posts, order.items
|
|
- category.industries (not industrys)
|
|
- person.children (not childs)
|
|
- analysis.analyses (not analysiss)
|
|
- Through tables: describe relationship (ProjectMembership, CourseEnrollment)
|
|
|
|
# Field Naming
|
|
- Foreign keys: singular without _id suffix (author, category, parent)
|
|
- Boolean fields: use prefixes (is_active, has_permission, can_edit)
|
|
- Date fields: use suffixes (created_at, updated_at, published_on)
|
|
- Avoid abbreviations (use description, not desc)
|
|
|
|
# Required Model Fields
|
|
All models should include:
|
|
- created_at = models.DateTimeField(auto_now_add=True)
|
|
- updated_at = models.DateTimeField(auto_now=True)
|
|
|
|
Consider adding:
|
|
- id = models.UUIDField(primary_key=True) for public-facing models
|
|
- is_active = models.BooleanField(default=True) for soft deletes
|
|
|
|
# Indexing
|
|
- Add db_index=True to frequently queried fields
|
|
- Use Meta.indexes for composite indexes
|
|
- Document why each index exists
|
|
|
|
# Migrations
|
|
- Never edit migrations that have been deployed
|
|
- Use meaningful migration names: --name add_email_to_profile
|
|
- One logical change per migration when possible
|
|
- Test migrations both forward and backward
|
|
|
|
# Queries
|
|
- Use select_related() for foreign keys
|
|
- Use prefetch_related() for reverse relations and M2M
|
|
- Avoid queries in loops (N+1 problem)
|
|
- Use .only() and .defer() for large models
|
|
- Add comments explaining complex querysets
|
|
|
|
## Monitoring & Health Check Endpoints
|
|
Follow standard Kubernetes health check endpoints for container orchestration:
|
|
|
|
### /ready/ - Readiness probe checks if the application is ready to serve traffic
|
|
Validates database connectivity
|
|
Validates cache connectivity
|
|
Returns 200 if ready, 503 if dependencies are unavailable
|
|
Used by load balancers to determine if pod should receive traffic
|
|
|
|
### /live/ - Liveness probe checks if the application process is alive
|
|
Simple health check with minimal logic
|
|
Returns 200 if Django is responding to requests
|
|
Used by Kubernetes to determine if pod should be restarted
|
|
Note: For detailed metrics and monitoring, use Prometheus and Alloy integration rather than custom health endpoints. |