CS113
CS 113 Master Requirements Table
| Learning Objective | Pasted Evidence Requirement | My Completion & Code File Reference | GitHub Issue |
|---|---|---|---|
| Data Structures | |||
| Collections | Used Map collections to cache member analytics and summary data on the group dashboard | PR #780 - pagination & member analytics integration | #17 Case Study: Group Dashboard Page Refactor |
| Lists | Managed paginated member lists and message arrays across the group dashboard | PR #780 - Implement pagination and member analytics | #34 Sprint 9 Progress: Nikhil |
| Stacks/Queues | Implemented queue for bathroom pass & student management and stack-based undo/redo for messaging | PR #115 - bathroom queue integration in Spring | #25 Queues: Bathroom Pass & Student Management, #26 Stack: Undo/Redo Functionality |
| Trees | Used decision tree/ML to summarize and classify chat messages | PR #740 - Analytics API integration | #27 Trees/ML: Summarize and Classify Chat Messages |
| Sets | |||
| Dictionaries/Maps | Used Maps for caching analytics data keyed by member/group ID on the group dashboard | PR #780 - member analytics with Map caching | #17 Case Study: Group Dashboard Page Refactor |
| Graphs | Modeled user relationships and friend recommendations using graph structure | PR #822 - graph of friends on dashboard | #28 Graphs: Model User Relationships & Recommend Friends |
| Algorithms | |||
| Searching | |||
| Sorting | Implemented sorting of group chat messages | PR #630 - Groups Messaging & Dashboard | #29 Sorting: Group Chat Messages |
| Hashing | |||
| Algorithm Analysis | Tracked and visualized user engagement analytics | PR #780 - pagination & member analytics | #31 Gamification Analytics: Track and Visualize User Engagement |
| Object-Oriented Design | |||
| Abstraction | Applied OOP abstraction in Spring backend models and service layers | PR #108 - S3 groups & analytics API | #23 OOP Methods: Backend Documentation |
| Encapsulation | Encapsulated group, message, and analytics data in Spring entity/service classes | PR #90 - S3 chat messages & shared files | #23 OOP Methods: Backend Documentation |
| Inheritance | Used Spring JPA entity inheritance for shared person/group data models | PR #115 - bathroom integration with person entity | #23 OOP Methods: Backend Documentation |
| Polymorphism | Overrode Spring controller methods and API responses across multiple entity types | PR #153 - group message deletion & email API | #23 OOP Methods: Backend Documentation |
| Design Patterns | Applied SRP and documented design patterns across group dashboard refactor | PR #785 - SRP Refactor for Group Dashboard | #21 Design Patterns: Apply & Document |
| Software Development | |||
| Version Control | Managed branches, commits, and merged PRs across pages and Spring repos throughout the year | PR #822, PR #112 | #11 Trimester 3 Start Burndown |
| Testing | |||
| Build Tools | Used Makefile for Jekyll builds and Maven/pom.xml for Spring Boot | PR #1011 - JS + SASS implementation | #63 Nikhil - Final Sprint of CSA Goals |
| Debugging | Diagnosed and fixed WebSocket port and nginx config issues through iterative sprints | PR #126 - emergency WebSocket fix to port 8589 | #38 Deployment (websockets, facial stuff, etc.) |
| API Development | Built REST APIs for analytics, group messaging, S3 file sharing, and email send with Swagger docs | PR #108 - S3 groups & analytics API; PR #153 - email send + Swagger | #34 Sprint 9 Progress: Nikhil |
| Database Integration | Migrated SQLite DB and integrated Spring JPA for groups, messages, and analytics persistence | PR #108; PR #90 | #52 Technologist Role for Sqlite DB Migration |
| Deployment | |||
| Docker | Configured deployment environment including server setup on port 8589 | PR #126, PR #112 | #51 Deploy on 8589 |
| DNS Configuration | Configured DNS and server routing for WebSocket deployment on port 8589 | PR #131 - nginx + WebSocket update | #51 Deploy on 8589 |
| Nginx | Updated nginx config for WebSocket support and port routing | PR #131 - nginx update; PR #126 - nginx emergency fix | #51 Deploy on 8589 |
| CI/CD | GitHub Actions pipeline for automated Jekyll build and deployment on every push | PR #1237 - merged to OCS pages | #38 Deployment (websockets, facial stuff, etc.) |
| Documentation | |||
| Code Comments | Documented OOP methods and backend functions with inline comments and AGENTS.md conventions | PR #1052 - AGENTS.md + naming conventions | #23 OOP Methods: Backend Documentation |
| API Documentation | Added Swagger dependency and documented REST API endpoints | PR #153 - Swagger dependency added to Spring | #23 OOP Methods: Backend Documentation |
| Help System | |||
| Blog Portfolio | |||
| Personal/Social Relevance | Built gamification skill tree for OCS students turning CSSE onboarding into a progression-based game | PR #1011 - _projects JS/SASS expansion | #57 Gamify Vision |
| Project Impact | Presented at CTE Expo; deployed bathroom pass, WebSocket chat, analytics, and gamification for real OCS classrooms | PR #822 - full-stack dashboard with WebSocket, facial recognition, analytics | #66 CTE Expo Report |
| Ethical Considerations | Designed bathroom pass with bell schedule awareness and facial recognition privacy considerations | PR #115 - bathroom queue + deepface integration | #62 Bathroom Pass Bell Schedule |
Analytics
Example PR’s
Pages:
- https://github.com/Open-Coding-Society/pages/pull/1052
- https://github.com/Open-Coding-Society/pages/pull/1011
- https://github.com/Open-Coding-Society/pages/pull/785 Spring:
- https://github.com/Open-Coding-Society/spring/pull/153
- https://github.com/Open-Coding-Society/spring/pull/140
- https://github.com/Open-Coding-Society/spring/pull/108
Commits
Project Checkout: 2 Key Themes
Working in Systems
Throughout this trimester, I’ve come to appreciate that sustainable software development isn’t about building isolated, perfect features—it’s about understanding how individual pieces fit into the larger ecosystem.
No more isolation
In the past, I would often approach projects with a focus on building a single polished tool in isolation. I’d optimize locally, create elegant solutions within a narrow scope, but miss the broader picture. Working on the Pirna-pages repository has fundamentally shifted my perspective. This project isn’t just one codebase; it’s a complex system spanning multiple courses (CSSE, APCSP, APCSA), game engines, educational tools, and backend integrations.
When working on system-wide improvements, I learned to think in terms of ripple effects. Every change to a core component affects students, teachers, and future developers. This means being intentional about architecture decisions, clear about intent, and thoughtful about backwards compatibility.
Key work demonstrating this systems thinking:
- Sprint System Implementation - Orchestrating complex sprint infrastructure across multiple courses
- Calendar Integration Architecture - Building systems that sync educational calendars across platforms
- Game Framework Refactoring - Establishing patterns for consistency across multiple game projects
Each of these required understanding not just the immediate problem, but how it connected to:
- Teacher workflows
- Student learning paths
- Deployment pipelines
- Data persistence across multiple services
Learning: Scale Requires Different Thinking
The real breakthrough came when I stopped asking “What’s the most elegant solution?” and started asking “How does this change ripple through the entire system, and how can I minimize unintended consequences?”
I now understand that as systems scale, dependencies matter more than cleverness. A transparent solution that works within established patterns is better than a brilliant solution that introduces fragility or requires others to understand your creative thinking. This humbling realization has liberated me to focus on problems that matter rather than optimizing for elegance alone.
Recent commits showing this evolution:
Collaboration
Early in my coding journey, I was very individualistic. I’d work on tasks, complete them solo, and submit them without much input or discussion. This trimester, I’ve learned that soft skills matter as much as technical skills, especially in a team environment.
Shared Teamwork
The shift happened through concrete experiences:
Live-share pair programming: Working alongside collaborators like @adikatre through VS Code Live Share, I experienced real-time code co-creation. Discussing approach while building, catching each other’s blind spots, and synthesizing ideas into better solutions than either of us would create alone.
Task reviews and burndowns: Rather than working in isolation, I now pull others into my progress early. I ask for feedback before shipping, adjust course based on input, and celebrate when someone else’s suggestion leads to a better outcome. It feels less like compromise and more like synthesis.
Including others in presentations: I learned when to step back and let teammates present their work, when to amplify their contributions, and when to speak up about technical decisions that deserve discussion.
Direct Evidence: Pull Requests & Issues
Recent PRs showing collaborative effort:
- PR Contributing to Sprint Calendar Sync - Multiple touchpoints with team members
- fd999d7 - Collaborative refactoring
- bef4438 - Code review feedback integration
- 71faf14 - Collaborative problem solving
- fbffe80 - Team-aligned implementation
Learning When to Push and When to Pull Back
One of the most valuable lessons: knowing when to advocate strongly vs. when to listen is a superpower. I’ve learned to:
- Advocate fiercely for technical decisions I believe in, backed by evidence and system understanding
- Listen genuinely when others present concerns, even if I initially disagree
- Recognize that I don’t always have the best answer, and that’s okay
- Celebrate team wins as much as individual wins
- Defer to domain expertise—if someone knows more than me, I follow their lead
This mindset shift has transformed collaboration from feeling like “compromise” to “synthesis.” We create better solutions together than any of us could alone, and everyone’s fingerprints are on the final product.
Conclusion: Why These Themes Matter
Looking back at where I started, I was building features in isolation. Now I’m building systems with people.
The most satisfying moment this trimester wasn’t shipping a feature that worked perfectly—it was realizing I’d helped create infrastructure that made it easier for the entire team to do their best work. And I got there not by being the smartest person in the room, but by listening, learning, and understanding that sustainable excellence is a team sport.
In the age of AI and rapidly scaling systems, working in isolation is a liability. The engineers who thrive aren’t those who produce the most clever code—they’re those who understand systems deeply, communicate clearly, and lift others up. That’s the engineer I’m becoming, and this trimester proved it’s possible to grow these skills while shipping real code that matters.