"I'll get to trying this out some day, maybe." — Jeff Casimir
"Finally, a place where I can keep track of my burning hatred for so many people." — Louisa Barrett
"This app is for me. I use it every day. It's critical to my workflow." — Jhun de Andres
finished around 10:40, which is about 3.5 hours after submission time:
I slipped a disk this past Sunday. To heal...
I took a couple 30 minute breaks throughout the day to make sure I am walking around and moving my spine (1hr)
I went to the gym from 4:00 - 5:30 and did my own physical therapy, stretching, hot tub, etc. (1.5hr)
I took another 30 minute break to lay down at home and ate dinner with my fiance (1 hr)
Total: ~3.5 hours for self-care, since I could barely walk Sunday and Monday.
The only way to truly understand any front-end framework is to build a to-do list—an Idea Box, if you will. But we're not going to build just any to-do list, we're going to build a list that keeps track of the people (and, I use that term loosely) who have wronged us.
##Rules
You may not have any commits in the repo from before 10:15am (i.e. you can reference a starter kit but the code in the repo must be your own)
You may not solicit questions on the specific code from cohort-mates, mentors, etc. You may not pair with anyone on this assignment. Instructors will answer questions at their discretion (i.e. feel free to ask us, we probably won’t answer but if you’re really in the weeds on something crazy we will).
Last commit must be in before 7:15. Exceptions for job/life events should be documented in the submission. You may add that time on to the 7:15 deadline. i.e. code interview at 2:00pm - took 30 minutes to prep - code interview was an hour long - added 1 hour and 30 mins to 7:15 deadline.
Application must be deployed prior to Friday a.m. eval.
You're welcome to choose whatever other technologies you want. That said, I'd read the requirements carefully before you make a technology decision. You will also need some way to persist grudges between sessions. If the user closes the tab and reopens it, they should still see all of the people who have crossed them in the past.
The model will need the following:
- An
id(Integer) - The name of the person who wrong you (String)
- The offense that caused them to be dead to you (String)
- Whether or not you've forgiven (but not forgotten) them (Boolean)
- Date of offense
At a minimum, all grudge data should be persisted in app.locals on a Node/Express server.
- Users should be able to add a new person who has wronged them to the list.
- They should be able to include the reason why that person is welcomed to go fly a kite.
- By default, the person is not forgiven, so you don't need a field in the form.
- The list should show the following data:
- The names of the jackals on the list.
- A count of the total number of people on this list.
- A count of the number of people who remain unforgiven.
- A count of the number of people have successfully redeemed themselves.
- The list can sort grudges by either the jackal's name or the date of their horrid act.
- User should be able to navigate to a particular person by clicking their name on the list. On this page, the user should see the following:
- The name of the particular slimeball.
- The hateful thing that they did.
- A button or other option to forgive the monster.
Can you display the jackals in a way, using color and style, that dynamically shows a clear difference between those who have recently wronged you, those whose foul deeds are in the not so distant past and legacy grudges?
Get weird with it.
- If a task is added in one window, the application will push the new task to all other open windows using a WebSocket connection.
- If a task is updated or removed in one window, the application will update all other open windows using a WebSocket connection.
The Node server can be shut down and all of the data is not lost. This would involve storing the data in a database. Alternatively, if you built a progressive web application then you get this functionality for free.
In order to pass the assessment, students must achieve a 3 or above on all rubric points.
- 4: The application consists of one page with all of the major functionality being provided. No approach was taken that is counter to the spirit of the project and its learning goals. There are no features missing from above that make the application feel incomplete or hard to use. Application is in production and at least one extension is completed.
- 3: The application is in a usable state, but is missing 1 or more of the features outlined in the specification above. Application is in production.
- 2: The application is missing 3 or more smaller features or 1 major feature essential to having a complete application. Application is in production but not working.
- 1 points: The application is unusable and not in production.
- 4: Developer uses elegant and idiomatic Javascript with vast majority of function 5 lines or shorter. Demonstrates solid understanding of single responsibility principle. Developer can speak to choices made in the code and knows what every line of code is doing.
- 3: Developer writes solid Javascript code using common patterns and idioms. Code is organized appropriately within objects and functions. Developer can speak to choices made in the code and knows what every line of code is doing.
- 2: Developer can accomplish basic tasks with Javascript but implementation is largely copy/pasted or non-idiomatic. Developer is not confident in what every line of the code is doing or cannot speak to the choices made.
- 1: Developer can manipulate Javascript syntax but implementation is buggy or inconsistent.
- 4: Developer excels at taking small steps and using the tests for both design and verification. Developer uses integration tests and unit tests extensively across the entire application.
- 3: Developer writes tests that are effective validation of functionality, but don't drive the design. Developer uses integration tests and a few unit tests where appropriate.
- 2: Developer uses tests to guide development, but implements more functionality than the tests cover. Application is missing tests at the integration and unit level that cover major functionality.
- 1: Developer is able to write tests, but they're written after or in the middle of implementation.
CSS is graded on quality, not quantity. You don't need a lot of CSS to have a pleasant interface
- 4: Application has exceptionally well-factored CSS with little or no duplication and all styles separated out into logical stylesheets. There are zero instances where an instructor would recommend taking a different approach.
- 3: Application is thoughtfully put together with some duplication and no major bugs. Developer can speak to choices made in the code and knows what every line of CSS is doing.
- 2: Your application has some duplication and minor bugs. Developer can speak to most choices made in the code and knows what every line is doing.
- 1: Your application has a significant amount of duplication and one or more major bugs. Developer cannot speak to most choices and does not know what every line of CSS is doing. Developer writes code with unnecessary selectors or tags which do not increase clarity.
- 4: The application is pleasant, logical, and easy to use. The interface is aesthetically pleasing to the evaluator. There is good use color and whitespace. There is no point where the instructor cannot figure out how to use the application without guidance from the developer.
- 3: The application has many strong pages/interactions, but a few holes in lesser-used functionality
- 2: The application shows effort in the interface, but the result is not effective
- 1: The application is confusing or difficult to use
- 4: The developer effectively uses Git branches and many small, atomic commits that document the evolution of their application.
- 3: The developer makes a series of small, atomic commits that document the evolution of their application. There are no formatting issues in the code base.
- 2: The developer makes large commits covering multiple features that make it difficult for the evaluator to determine the evolution of the application.
- 1: The developer commited the code to version control in only a few commits. The evaluator cannot determine the evolution of the application.