You will be building on top of a pre-existing Rails app used for hosting educational programming videos, found here.
Why? Up until now you have been building Rails apps from scratch, frequently referred to as greenfield projects. Most Turing grads go on to work on existing code bases, or brownfield projects. Building on top of existing code presents a different set of challenges. Technical debt and the decisions of the past frequently present unanticipated challenges. Understanding how your decisions impact a team is an important part of learning how to write maintainable software. You also rarely have time for a complete rewrite so deciding what to care about and when becomes as important a skill as being able to write code.
- Learn to consume a JSON API
- Build an app that authenticates using OAuth
- Make API calls to an authenticated API
- Build on top of brownfield code
- Empathy for developers facing deadlines
- Empathy for teammates that might work with your code in the future (or future you!)
- Prioritize what code is relevant to your immediate task (and ignore the rest)
- Send email from a Rails application
View the README on Github.
Developer Empathy and Technical Debt
- 1: Meets less than three of the requirements below.
- 2: Meets 3 of the requirements below.
- 3: Meets all of the criteria below.
- 4: Meets all of the criteria below and went above and beyond to clean up and prevent technical debt.
Empathy and Technical debt criteria
- Points out areas where they have created technical debt.
- Points out areas where they have added to technical debt.
- Can explain how they could have prevented adding to technical debt.
- Can explain how the previous developers could have written their code to be more maintainable.
- 1: More than 5 cards are incomplete.
- 2: Five cards are incomplete.
- 3: All user stories not labeled “extension” are complete. (You can negotiate with your instructor to set the requirements for a passing project, but this requires communication early on.)
- 4: All user stories complete and at least one extension.
- 1: Project uses 1 or fewer testing techniques listed below and/or overall test coverage is below 85%.
- 2: Project uses 2 testing techniques listed below and/or overall test coverage is above 85%.
- 3: Project uses 3 testing techniques listed below, overall test coverage is above 90%, and unit testing is above 90%.
- 4: Project uses all testing techniques listed below, overall test coverage is above 95%, and unit testing is above 90%.
Project should use RuboCop to measure code quality.
- 1: Team can demonstrate how API consumption portions of the project demonstrate 1 of the pillars listed below, or RuboCop complains about 5 or more violations.
- 2: Team can demonstrate how API consumption portions of the project demonstrate 2 of pillars listed below, and RuboCop complains about 4 or less violations.
- 3: Team can demonstrate how API consumption portions of the project demonstrate 2 of pillars listed below, and RuboCop complains about 3 or less violations.
- 4: Team can demonstrate how API consumption portions of the project demonstrate all of the four pillars listed below and RuboCop has no complaints.
4 Pillars of OO
- Project uses polymorphism
- Project uses encapsulation
- Project uses abstraction
- Project uses inheritance