CSA Trimester 1 Retrospective

CSA Trimester 1 Retrospective

• 8 min read

Progress (Comparison to Beginning of the Year)

  • Improved Agile/Scrum Skills:

    • Gained deeper understanding of team-based Git workflow (forks, PRs, branching).
    • Learned how to create clean, non-breaking PRs with readable, modular changes.
    • Tested teammates’ PRs using git checkout, ensuring functionality before merges.
    • Improved at code reviews — identifying logical errors, style issues, and better implementation methods.
    • Overall, stronger grasp of collaborative development and version control discipline.

  • Improved Java Knowledge (Backend):

    • Learned to use Java with Spring Boot to build and manage backend APIs.
    • Created POJOs, schemas, and database tables (e.g., user progress, grades).
    • Understood Spring’s exception handling and Java’s static typing error patterns.
    • Gained experience debugging backend logic and data flow between API and database.
    • Improved understanding of REST structure and backend design principles.

  • Improved LxD (Learning Experience Design) Knowledge:

    • Helped design and manage CSA lesson structure during Sprint 2 — focused on lesson organization, scheduling, and learning flow.
    • Studied instructional frameworks (Merrill, Gagné) and built a hybrid system customized for our class.
    • Learned what makes effective lessons (clarity, interaction, pacing) through feedback from CSP/CSSE classes.
    • Iterated on lesson design — adjusted content depth, increased interactivity, and refined flow based on feedback.

Future (What I Want to Learn in CS A)

  • Explore ML-focused projects using Spring Boot for backend integration.
  • Learn how to connect machine learning models to full-stack web apps (data pipelines, inference endpoints).
  • Focus on using Spring’s data management and API features to support dynamic, data-driven applications.
  • Build a project that combines backend engineering with applied ML — challenging, scalable, and practical.

N@TM Review

Notes

  • Comments: Got comments on how it was an interesting paradigm and methodology to be getting certificates and other tangibles in the classroom as a result of learning and how that is applicable to the real world where people are trying to get certified and learn skills. Many listeners thought it was interesting how we gave certificates for Linkedin. Beyond certificates many listeners mentioned being impressed by the backend work - the database storage - and technical concepts (CRUD, etc.) required to implement the system across the whole team.
  • Reflection: Thought it went well overall and I think as a team we did a good job presenting while abstracting the technical details for listeners until asked, and we were able to convey the purpose of our group and what we accomplished without incomprehensible language. However, that being said I think some more discussion of the technical details could have been interesting for the listener and maybe showcased the work we did better.

Future for the Project

Future Directions for the Project

  1. System Generalization

    • Expand the current system architecture to make it modular and adaptable beyond the current project scope.
    • Create a framework that can integrate seamlessly with other components of the OCS system, allowing for cross-project compatibility.
    • Refactor project-specific features into reusable modules or APIs to ensure scalability and maintainability.

  2. Enhanced Grading Component

    • Implement CSV export functionality for grading data, ensuring that the output follows defined standards for interoperability with other systems (e.g., OCS analytics or reporting tools).
    • Design the grading component to handle synergy-based grading requirements — allowing for multiple criteria, weighted scores, or collaborative assessments.
    • Consider adding audit trails or grading logs for transparency and validation.

  3. Improved Admin View and Oversight Tools

    • Expand admin capabilities to include detailed views of student progress, submissions, and engagement metrics.
    • Add functionality for admins to flag inactivity or low performance, enabling early intervention if a student is slacking.
    • Include overview dashboards with filters and search options to make navigation through user data more intuitive.
    • Implement permission-based actions (e.g., admins can override grades, send reminders, or leave notes).

  4. Expanded Analytics for Users

    • Introduce visual analytics dashboards for students to track their performance, progress trends, and time spent on tasks.
    • Include insights such as peer comparison, skill growth, or recommended next steps based on performance data.

  5. Gemini Chatbot Enhancements

    • Contextual Improvements: Expand the chatbot’s context window and data access so it can maintain a deeper understanding of user history and previous interactions.
    • Memory System: Add a persistent memory component that allows the chatbot to recall user preferences, past topics, and ongoing projects for more personalized and coherent interactions.

  6. Gemini Grading System Improvements

    • Strengthen the AI-based grading logic by introducing more diverse training examples or rule-based fallbacks for edge cases.
    • Add cross-validation mechanisms to ensure the chatbot’s grading aligns with human grading standards.
    • Integrate rubric-based feedback generation — so the chatbot not only grades but also explains why certain scores were given.
    • Develop a feedback refinement loop where user or admin corrections help the AI improve future grading accuracy.

Minor Fixes / Technical Improvements

  1. URL Protections for Admin Submodule (Submodule 3)

    • Strengthen access control mechanisms to prevent unauthorized access or bypass attempts to admin routes.
    • Implement proper role-based authentication and session validation for all admin-related URLs.
    • Add security middleware to validate requests and prevent manual URL entry from exposing admin panels.
    • Consider adding logging for any unauthorized access attempts for security auditing.

Future Learning

Analytics

  • Almost 500 commits for the year.

  • Shows major contributions to Pages (100+ commits)

  • Numerous PRs to pages with changes, tools, etc.

  • Shows collaboration within the team (50+ PRs)

MCQ

Notes:

  • Need to review using Objects and Methods (Object Oriented Syntax in Java - i.e private, public, static, etc.) and other OOPs related concepts in Java. Main handicap is syntax as it is distinct from Python but it should not be hard to learn as the base concepts remain the same with a few exceptions.
  • Also need to work on Data Collection (which is related to mentally simulating the code block) - this is just some practice.

Corrections (top 5 questions):

Question 3: The original selection (B) was incorrect because the only available constructor in the Painting class is defined as public Painting(int y, String a), meaning it requires exactly two arguments: an integer for the year, followed by a String for the artist. Option (B), Painting p = new Painting(1939, “Frida Kahlo”, “Self Portrait”);, provides three arguments, which does not match the constructor’s signature. The correct code segment is (D), which is Painting p = new Painting(1939, “Frida Kahlo”);, as it correctly provides the two required arguments in the correct order: the integer 1939 followed by the string “Frida Kahlo”.

Question 8: The code first sets two variables, w to 2.0 and x to 5.0. Then it calculates two more variables, y and z, in slightly different ways. For y, the code changes w from 2.0 to 2 (an integer) before dividing it by x. Since x is still a decimal (5.0), Java automatically converts the 2 back into 2.0 to perform decimal division. This gives a result of 0.4 for y. For z, the code first divides w by x, which gives 0.4, and then converts that result into an integer. Converting a decimal to an integer removes the decimal part, leaving 0. So when the code prints y and z, it shows 0.4, 0.0.

Question 9: The original answer, which suggests the error is related to accessing the private variables feet and inches inside toInches(), is incorrect. Those variables are accessible because they are being used within their own class, Measurement. The actual compilation error occurs because the toInches() method itself is declared as private within the Measurement class. The compare method in the separate Calculations class attempts to call this method using m1.toInches() and m2.toInches(). Since the private access modifier restricts the method’s use to the internal workings of the Measurement class only, it cannot be called from an external class like Calculations. Therefore, the correct explanation for the error is (C) The toInches method cannot be accessed from a class other than Measurement.

Question 14: The problem asks for a statement that means the same thing as saying “it is not true that the number is both even and positive, but it is prime.” Using the logic rule called De Morgan’s Law, saying “it is not true that something is both even and positive” is the same as saying “the number is not even or it is not positive.” Putting that together, the full statement becomes “the number is not even or it is not positive, and it is prime.” The correct answer is the one that matches this wording. The other choice was wrong because it said “the number is not even and it is not positive,” which changes the meaning.

Question 28: The code looks through the string “abbcdddeff” and counts how many times two of the same letters appear next to each other. It checks each character and compares it to the one right after it. There are four times where two characters in a row are the same:

‘b’ at positions 1 and 2

‘d’ at positions 4 and 5

‘d’ at positions 5 and 6

‘f’ at positions 8 and 9

Because of these four pairs, the program increases the counter four times. So, when it runs, it prints 4.