Tomorrow your final assessment will start promptly at 9:00am. You must submit your project to Jhun, Mike, and Will in a group slack message by 4:00. Any commits after 4:00 will not be considered in your evaluation.
Periodically throughout the day we will be pulling you out of your assessment to pair with an instructor on some Fundamental JavaScript.
- This is a solo assessment. There will be no pairing of any kind. We will be available to answer questions but at the end of the day this for you to show us what you've learned this module
- You will be pushing up a commit to github every 30 minutes. This will allow us to track your progress throught the day.
- 4: Developer is able to implement solutions at the speed of a developer.
- 3: Developer is able to implement solutions at the speed of a junior developer.
- 2: Developer is able to implement solutions at the speed of an apprentice.
- 1: Developer struggles to implement solutions at the speed of an apprentice.
- 0: Developer is not able to implement basic functionality.
- 4 - Developer demonstrates complete understanding of React with appropriately separated components and exceptionally well refactored code.
- 3 - Developer appears comfortable in React. There are minor opportunities to refactor.
- 2 - Developer selected appropriate libraries and frameworks to build the app but did not use them as intended. Significant refactoring necessary.
- 1 - Developer did not make any effort to use React effectively or refactor code.
- 4: Appropriate components are wrapped in connected Redux container components. The Redux store contains all necessary application data and nothing more. All state changes are handled through Redux actions and reducers. Developer uses middleware. Actions and reducers are clean. At least one container is reused.
- 3: All state changes are handled by Redux with exeception to Controlled Forms. Actions and Reducers are simple. Containers don't hold unnecessary data.
- 2: Application state is mostly outside the control of Redux. Application did not make use of Redux actions and reducers to mutate state. Components do not demonstrate a clear understanding of stateful vs. statelessness.
- 1: Application does not make use of Redux to manage state. There are little or no connected components.
- Pass - Proptype validation is implemented for any component receiving props.
- Fail - There are components missing proptype validation.
The output from ESLint shows…
- 4 - Zero complaints
- 3 - Five or fewer complaints
- 2 - Six to ten complaints
- 1 - More than ten complaints
- 4 - Every component is tested from both a unit and acceptance standpoint, all crucial functionality is tested
- 3 - Almost all components are tested to a level that indicates developer has an understanding of testing
- 2 - A valid attempt was made to test functionality with obvious gaps where functionality is not tested
- 1 - There was little to no attempt to test this application.
-
4 - Developer(s) make many small, atomic commits that clearly document the evolution of the application and do not contain irrelevant changesets that aren't reflected by the commit message. Commit messages are concise and consistent in syntax and tense. Developer effectively use git branches and pull requests when applicable to incorporate changes into the application, and are not pushing directly to master. There are no instances where the developer(s) have committed source code that should be .gitignored. There are no instances of "dead" or commented-out code and debugger statements like console.log.
-
3 - Developer make many small, atomic commits that document the evolution of the application but sometimes contain irrelevant changesets and inconsistent commit messages. Developer use git branches and pull requests when applicable to incorporate changes into the application, and are not pushing fresh changes directly to master. Pull requests may contain little or no code review. There may be slight instances where the developer have committed source code that should be .gitignored. There may be some instances of "dead" or commented-out code and debugger statements like console.log that need to be cleaned up.
-
2 - Developer make large, inconsistent commits that contain irrelevant changesets and make it difficult to follow the evolution of the application. Developer rarely use git branches and frequently incorporate changes directly into master with little or no review process. There are instances of committed source code that should be .gitignored and instances of dead code and/or debugger statements.
-
1 - Developer make very few commits that each cover too much responsibility and aren't indicative of how the application evolved. Branches and pull requests were not used and changesets were applied directly to master. There are many instances of committed source code that should be .gitignored and many instances of dead code and/or debugger statements.
- PASS: Developer solves problems with a balance between conciseness and clarity and often extracts logical components. Developer demonstrates they have a proficient understanding of JavaScript and Array Prototypes.
- FAIL: Developer fails to demonstrate understanding of fundamental JavaScript.
- 4: Developer actively seeks collaboration both before implementing, while in motion, and when stuck
- 3: Developer lays out their thinking before attacking a problem and integrates feedback through the process
- 2: Developer asks detailed questions when progress slows or stops
- 1: Developer is able to integrate unsolicited feedback but does not really collaborate
- 0: Developer needs more than two reminders to "think out loud" or struggles to articulate their process