Hang in There API Evaluations

Back to Hang in There API Home

Presentation

For the project evaluation, each project pair should prepare a presentation. Your presentation should cover the following points:

  • Demonstration of functionality via Postman suites
  • Technical quality and organization of the code, identifying code that should be refactored and how it would be refactored
  • Running your application’s test suite and a discussion of test coverage
  • Identifying the area(s) of code of which you are most proud, and an area where you would like specific feedback

All team members are expected to participate equally in the presentation. Students should focus on practicing technical communication that is succinct and utilizes appropriate technical vocabulary.

Slides are not required, but encouraged as a way to facilitate the presentation along with sharing specific code examples.

Rubric

Your project will be evaluated based on the following rubric:

Feature Delivery

  • Exceeds Expectations: Project completes all requirements and extensions.
  • Meets Expectations: Project completes all requirements
  • Approaching Expectations: Project fails to complete 1 - 2 required endpoints
  • Below Expectations: Project fails to complete more than 3 or more endpoints

Test Driven Development

  • Exceeds Expectations: Project achieves 100% test coverage at the unit and integration levels. A gem that enhances testing effectiveness is implemented (orderly, factorybot, faker, etc) throughout tests.
  • Meets Expectations: Project achieves greater than 90% test coverage
  • Approaching Expectations: Project achieves greater than 80% test coverage
  • Below Expectations: Project does not have 80% test coverage.

Rails

  • Exceeds Expectations: Project demonstrates exceptionally well factored code. Students implement strategies not discussed in class and can defend their design decisions (callbacks, scopes, etc)
  • Meets Expectations: Students use the principles of MVC to effectively organize code with only 1 - 2 infractions. Routes and Actions mostly follow RESTful conventions. Serializers are used for formatting JSON responses.
  • Approaching Expectations: Students use the principles of MVC to effectively organize code, but may have more than 2 infractions. Some routes and actions are not RESTful, and student cannot defend those decisions.
  • Below Expectations: Project demonstrates poor factoring and/or understanding of MVC.

ActiveRecord/SQL

  • Exceeds Expectations: Code is DRY with no duplicate queries.
  • Meets Expectations: ActiveRecord helpers are utilized whenever possible. ActiveRecord is used in a clear and effective way to read/write data. No Ruby is used to process data. All queries functional and accurately implemented.
  • Approaching Expectations: Ruby is used to process data that could use ActiveRecord instead. Some instances where ActiveRecord helpers are not utilized. Some queries not accurately implemented.
  • Below Expectations: Ruby is used to process data more often than ActiveRecord. Many cases where ActiveRecord helpers are not utilized.

Project Management

  • Exceeds Expectations: GitHub Project board is fully up to date in all checkins and the evaluation. Students create custom cards on the project board to track tasks in addition to user stories.
  • Meets Expectations: Student uses GitHub Project to track all user stories. Project board is mostly up to date in all checkins. Project board is fully up to date at the evaluation.
  • Approaching Expectations: GitHub Project board is not utilized during one of the checkins. Project board is not fully up to date during evaluation.
  • Below Expectations: GitHub projects is not utilized.

Lesson Search Results

Showing top 10 results