For this module, knowing that we would be getting into several back-end technologies, I wanted to make sure that while I absorbed this new information, that I wouldn't let the skills I've learned from the past 3 mods lose any of their sharpness. The instructors really helped with this, by incorporating more CSS challenges and javascript practice into the curriculum. I also wanted to make sure that I maintained my stress levels by not getting too absorbed in the job hunting until I graduate, as I do not have an immediate need to find work, and am hoping the patience will allow me to land a position where I can grow with that company for several years.
- A: Individual Final Assessment: 3
- B: Individual Work & Projects: 3
- C: Group Work & Projects: 3
- D: Professional Skills: 2
- E: Feedback & Community Participation: 2
- PASS
50 points: (50 possible points)
- Looks like all the features are there (no extensions)
15 points: (20 possible points)
- The form is roughly styled and hard to follow
- The colors could use up more real estate; they are pretty small, which is a little frustrating for the user since the colors are the central purpose of the site
- Good job have a
There are no saved palettes.as a placeholder
20 points: (20 possible points)
- Schema looks good with one-to-many relationship using primary/foreign key
- I haven't used the json column type before, I wonder how that worked out, any issues?
17 points: (20 possible points)
- Good job with the before and beforeEach blocks
- This test is very thorough, I'm wondering if it's too thorough; is the first request really necessary if you trust your seed file is running (and you don't modify your seed data - either way the test is fragile)
- Watch out for typos
- Would want to see a sad path test for this route for when you try to delete an item that does not exist in the DB
8 points: (10 possible points)
- Want to see some more specificity in terminology, for instance the reasoning behind the specific body parser settings here
15 points: (20 possible points)
- Helpful error handling here
- Status 201 here for an error?
- This is brutal in terms of readability - needs refactoring
- Instead of using the name of a project as an ID attribute in your HTML, you can use the data HTML attribute to store data information about an element, an ID is traditionally used for styling and targeting specific elements for JS hooks
- Are you really accepting all content types? Your implementation seems to depend on getting JSON back as a response
- Seems like you could tie these classes together into one "locked" class, and then just toggle it
17 points: (20 possible points)
- Try for some smaller commits along the way, overall pretty good _ nice job adding .gitignore right off the bat
The following set of points are distributed at the discretion of the instructor.
10 points: The README includes documentation for all available endpoints and how to use them. Instructor can easily follow the documentation for using the API.
60 points: (60 possible points) Developer has implemented all 10 endpoints, 4 are secured via JWTs and one is a custom endpoint that filters data based on query params. The database is seeded with at least two tables and one relationship.
34 points: (40 possible points) Project has a running test suite that covers all happy and sad paths for the appropriate endpoints. Error handling is informative and helpful for the end-user. The project has a linting configuration that passes with no errors.
-
Your error handling is nice and thorough, but it's also quite repetitive. I'd break out error handling like this into a helper function so it can be re-used among endpoints.
-
You should be able to add variables like this into a 'globals' object in your eslint config instead of doing these line-by-line comments to turn those warnings/errors off.
-
I'd rather you set the environment as an environment variable in your test script of your package.json rather than hardcoding it directly in the file. It just maintains the consistency and familiarity of seeing
process.env.NODE_ENV || 'fallback'. There's also a possibility that a CI environment name might diverge from 'test' and you'd want to still be able to capture that with an environment variable. -
Curious about the strategy here and why you're making these GET requests in a
beforeEachblock. Probably not a huge deal in this scenario, but doing this much before every single test would significantly slow down the runner. -
These assertions could be simplified by simply grabbing a complete mock beer object and checking if the array contains it or not.
-
Would be good to test the error message that comes back here as well.
25 points: (40 possible points) 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 code is doing. Some improvements can be made with naming conventions to improve readability.
- A simpler way to do this check is by assigning the token variable right away and falling back through each possible option. If none of the values stick, it will just be undefined. e.g.:
let token = request.headers.authorization || request.body.token || request.query.token;-
If you're going to leave comments in your code, you should make sure they accurately reflect what's happening. This is checking for
appNameandemail, not just appName. Your code should generally be written in an English-enough way that you don't need comments like this. -
Using 'it' in a variable name is a poor naming convention. On it's own, without any context, I can't decipher what 'it' represents. I'd rename this to
emailBelongsToTuring. That reads a little more like English when you're doing conditionals and provides some extra context about what the value represents. -
This conditional is a little difficult to read. Could you use a
.contains()on the string instead? -
Is the Abv specific to an actual user? Or just a trait of each beer that you can filter on? Prefixing a variable name with 'user' when it's not a value that's actually tied to a user is a little bizarre. 'MyDatabase' is also a poopy variable name.
-
This conditional could be combined with an
&&to avoid some nestiness. -
I know filtering by more than one query param wasn't a part of the spec, no points off for this, but just FYI you could make this more flexible and dynamic by doing blah blah blah. I bet there are a lot of beer characteristics people would be interested in filtering on, rather than just ABV.
-
I don't necessarily agree with returning a 404 here. A 404 means nothing exists at that particular endpoint, and usually signifies that someone entered an incorrect URL. In this case, the endpoint is correct, and a resource does happen to exist there, it's just an empty array.
-
Again, make sure your comments accurately reflect the functionality. You don't want to be coopy and pasting examples and leaving evidents/artifacts behind.
-
Missing a .catch for this .then
15 points: Developer(s) make many small, atomic commits that document the evolution of the application but sometimes contain irrelevant changesets and inconsistent commit messages. Developer(s) 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(s) 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.
-
Nice use of issues and pull requests, but would like to see some actual code review and conversation around the PRs -- do you both understand all the logic that's being added? Are you both equally responsible for it now?
-
Similar inconsistencies in commit message formats and lots of areas where commits can be squashed, though you didn't learn about that until after this project was due.
- Link to Post Grad 30 Day Plan:
https://gist.github.com/EndlessHypnosis/9312cade9857d5a6f7debe566526d448
- Link to Turing portfolio:
- Link to Trello Board with companies that are being tracked:
- Link to Calendar with time blocked out for 40 day work week:
I found these 2 sessions to be very helpful, and of course enjoyable due to Jeff's teaching style. The Chipotle Challenge was really interesting to think about, especially how it can grow in complexity fast with the relationship rules between items. The other session reviewing intervew concepts was helpful to see what Jeff thought the priority should be.
I found the experience overall helpful in getting over the public speaking fears, and organizing activities to keep a group entertainined and engaged for an hour will surely be helpful in the real world, if not only for understanding the point of view of the presenter, and how as someone in the audience, you can best participate and help them achieve their session goals. Our specific gear-up went rather well, although we are still waiting on the feedback to come in. We planned our time very well, and even had a couple minutes at the end for some reflection and summary on the session. Overall, great experience!
In this mod, it was important for me to ensure that I was keeping myself as healthy as possible, mentally and physically. For this reason, I felt that I needed to focus on my own learning and transition out of Turing. But at the same time, I wanted to make sure that I was still suppporting the community, primarily my cohortmates. For this reason, I kept up my routine of sharing information and resources with the group, jumping into bug solving discussions, and working 1-on-1 for some code reviews.