Project 2 Evaluation

Technical Requirements 2

0. 0 Models, or partial CRUD on at least 1 model.
1. At least 1 model incorporates GET, POST, PUT, and DELETE routes, but no associations.
2. The app contains 2 models, with at least 1 association. At least 1 model is full CRUD.
3. Includes many well-structured models, and advanced functionality such as authorization, 3rd-party API integration, or other technology not covered in class

Models, Migrations, & Associations

• 2 models, day and month with Create, Read, Update, Delete for day

Routes

• Uses resourceful routes and limits appropriately. Index and Show for Months, all routes for days.
• The root: key here is out of place (you want root to: 'months#index') and causing an error

Controllers & Actions

• Creative definition of destroy as to not mess up the calendar.

Views

• Good use of partials and only including necessary views (no utility of a day show page)

Misc

• You had mentioned considering supporting arbitrary numbers of events per day rather than the four. Do you have a sense of how you'd go about implementing an event entity?

Creativity and Interface 2.5

0. Zero or Minimal custom styles or interface. Evidence of scaffolded code
1. The app is styled and has an interface of value to the end user: it is not just a nav bar and an index page
2. The app displays a personal spin or creative element through its written language, functionality, purpose, and/or CSS.
3. The app is fully responsive, incorporates outside technologies such as Flexbox. App incorporates modern UI themes, and adds unique flair.

• Clearly a ton of time went into getting everything styled properly and creating an app like experience across page refreshes. Good use of flexbox and psuedo selectors.

Code Quality 2

0. Minimal functional code is present
1. Code lacks proper formatting, includes commented out, non-functional code, or otherwise contains major issues of quality (DRY, naming, etc)
2. Code is well-formatted, well-named, and contains few style / quality issues
3. No major code quality issues, makes use of Ruby best practices appropriately, and follows techniques such as separation of concerns, abstraction, and encapsulation

• Everything seems tidy and conforming to best practices.
  Good use of partials for the day form.

Deployment and Functionality 1.5

0. Application contains minimal functionality
1. Application contains minimal functionality and contains major errors when used
2. Application contains no major errors and is deployed
3. App has advanced functionality that works with minimal errors, and may make use of advanced tools such as APIs, plugins, etc

• App contains expected functionality but the deployed app doesn't seem to be up on heroku (link goes to a page saying the app doesn't exits).
  Think you demonstrated the deployed app so might be that it was deleted.
  You'll want that up to include in your portfolio.

Planning / Process / Submission 2

0. No submission received, or submission does not contain basic documentation of planning (ERD, wireframes, commit history, etc)
1. App is submitted, with basic evidence of planning. Documentation exists, but lacks common areas such as setup instructions, description of application functionality
2. Submission contains clear evidence of planning, adequate documentation, include all from previous category, as well as additional information such as unsolved issues.
3. Submission includes everything in previous category, as well as evidence of planning tools, such as Trello, and, incorporates workflows such as feature branching, code review, github issue / user story tracking, and justification of technical decisions.

Planning materials are present. The commit history is clean and reasonable navigable.