- Prioritize student learning effectiveness over context switching
- Define three-tier architecture: Inline → Module → Integration
- Emphasize comprehensive inline testing with educational context
- Maintain professional module tests for grading
- Preserve flow state by keeping students in notebooks
- Provide immediate, encouraging feedback with visual indicators
- Define clear goals for each testing tier: Unit → Module → Integration → System
- Implement mock-based module testing to avoid dependency cascades
- Provide comprehensive examples for each testing level
- Establish clear interface contracts through visible mocks
- Enable independent module development and grading
- Ensure realistic integration testing with vetted solutions
- Remove unnecessary module_paths.txt file for cleaner architecture
- Update export command to discover modules dynamically from modules/source/
- Simplify nbdev command to support --all and module-specific exports
- Use single source of truth: nbdev settings.ini for module paths
- Clean up import structure in setup module for proper nbdev export
- Maintain clean separation between module discovery and export logic
This implements a proper software engineering approach with:
- Single source of truth (settings.ini)
- Dynamic discovery (no hardcoded paths)
- Clean CLI interface (tito package nbdev --export [--all|module])
- Robust error handling with helpful feedback
- Remove 5 outdated development guides that contradicted clean NBGrader/nbdev architecture
- Update all documentation to reflect assignments/ directory structure
- Remove references to deprecated #| hide approach and old command patterns
- Ensure clean separation: NBGrader for assignments, nbdev for package export
- Update README, Student Guide, and Instructor Guide with current workflows
- Remove outdated documentation files (cli-reorganization, command-cleanup-summary, module-metadata-system, testing-separation)
- Update all CLI commands to use current hierarchical structure (tito system/module/package)
- Align documentation with simplified metadata system
- Update student project guide with current module structure
- Modernize development guides and quick reference
- Remove references to removed features (py_to_notebook, complex metadata)
- Ensure all documentation reflects current system state
Documentation now focuses on:
- Current CLI structure and commands
- Simplified module development workflow
- Real data and production patterns
- Clean educational progression
- Add system, module, and package command groups for clear subsystem separation
- Create SystemCommand, ModuleCommand, and PackageCommand classes
- Maintain backward compatibility with existing flat commands
- Enhanced help system with contextual guidance at each level
- Updated main CLI to show organized command groups
- Added comprehensive documentation for CLI reorganization
New structure:
- tito system (info, doctor, jupyter)
- tito module (status, test, notebooks)
- tito package (sync, reset, nbdev)
Benefits:
- Clear subsystem separation
- Intuitive command discovery
- Better extensibility for future commands
- Reduced cognitive load for users
- Add module.yaml files for setup, tensor, activations, layers, and autograd modules
- Enhanced tito status command with --metadata flag for rich information display
- Created metadata schema with learning objectives, dependencies, components, and more
- Added metadata generation script (bin/generate_module_metadata.py)
- Comprehensive documentation in docs/development/module-metadata-system.md
- Status command now shows module status, difficulty, time estimates, and detailed metadata
- Supports dependency tracking, component-level status, and educational information
- Enables rich CLI experience with structured module information
Introduces documentation for TinyTorch module development, including guides for developers and AI assistants.
Provides comprehensive resources for creating high-quality, educational modules, focusing on real-world applications and systems thinking.
- Updated pedagogical principles with refined engagement patterns:
- Build → Use → Reflect (design & systems thinking)
- Build → Use → Analyze (technical depth & debugging)
- Build → Use → Optimize (systems iteration & performance)
- Added pattern selection guide for module developers
- Updated development workflow to choose pattern first
- Created specific module assignments for each pattern
- Enhanced quick reference with pattern-specific activities
This evolution moves beyond passive 'understanding' to active,
specific engagement that matches professional ML engineering skills.
- Add template section to tensor, layers, activations, and cnn modules
- Create docs/development/module-template.md for future reference
- Clarify learning vs building structure consistently
- Show students where their code will live in the final package
- Decouple learning modules from production organization
- Moved tools/py_to_notebook.py to bin/py_to_notebook.py
- Updated tito.py to reference the new location
- Made py_to_notebook.py executable for direct invocation
- Removed empty tools/ directory
- Updated documentation to reflect new location
- All tools now consolidated in bin/ directory for consistency
Benefits:
- Conventional organization (bin/ for executables)
- Can invoke tools directly: ./bin/py_to_notebook.py
- Cleaner project structure
- Consistent with other tools (tito.py, generate_student_notebooks.py)
- Restored tools/py_to_notebook.py as a focused, standalone tool
- Updated tito notebooks command to use subprocess to call the separate tool
- Maintains clean separation of concerns: tito.py for CLI orchestration, py_to_notebook.py for conversion logic
- Updated documentation to use 'tito notebooks' command instead of direct tool calls
- Benefits: easier debugging, better maintainability, focused single-responsibility modules
- Move all documentation to docs/ directory with clear organization
- Use lowercase-with-dashes naming convention (modern standard)
- Organize by audience: students/, development/, pedagogy/
- Create comprehensive docs/README.md index
- Clean up root directory (only README.md and quickstart.md remain)
Structure:
docs/
├── pedagogy/ # Educational philosophy
├── development/ # Module development guides
├── students/ # Student-facing documentation
└── README.md # Documentation index
This makes the project more professional and easier to navigate.
