Add Themis application with custom widgets, views, and utilities
- 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.
This commit is contained in:
96
docs/Red Panda Django.md
Normal file
96
docs/Red Panda Django.md
Normal file
@@ -0,0 +1,96 @@
|
||||
## 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.
|
||||
Reference in New Issue
Block a user