Project 4 Feedback

Code Quality - Performing

Criteria: Is the code well-formatted? Are variable and function names semantic and sensible? Is the code easy to read and understand?

Strengths:

Code is well-formatted in both repos, with sensible and semantic variable and function names.
Indentations, spacing and conventions are consistent throughout both repos.
Code is overall easy to read and understand, with no useless or spaghetti code (other than user-auth related components that I think you're working on incorporating!).

Areas for Growth:

Make sure you remove all console.logs from a deployed version of your application! Specifically, the Map.js component seems to console.log all the data points it retrieves on line 86. EditUser.js also appears to console.log the user's email address. Check both repos for any more and remove them from the master branch.
Any sensitive data such as access tokens should be hidden in an environmental variable and not pushed to GitHub.

Technical Requirements - Performing

Criteria: How does the project stack up to the requirements for this project? Are the developers making use of the material we've covered in a way that makes sense?

Strengths:

Nice job meeting the technical requirements of this project! Your application is a complete product, deployed, and uses technology we did not cover in class.
Congratulations on learning and implementing Mapbox-gl ... it looks like you did a great job, and that map is such an impressive feature for your app! I love how you can scroll to zoom in and out, and getting those nodes to populate must have been challenging!
Good history of Git commits on both repos, with concise yet descriptive commit messages.

Areas for Growth:

I know you are planning to finish out the user authentication feature, and I think that's super important to finish it rather than leave a half-implemented feature. Right now the login/logout/edit/delete user feature appears to be more decorative than anything, which is a great start. I would suggest using bcrypt or passport.js to finish out that functionality.
Consider working on features on a separate branch other than master, so that your deployed application is production worthy without any incomplete features. When the feature is ready, you can merge the branches to incorporate your new code into your master branch, then redeploy to Heroku.
Try to format Git messages like this: singular present tense verb + what you did. For example, instead of 'mobile responsiveness', 'add mobile responsive styles', or something like that. More about good Git commit messages here.

Creativity and Interface - Performing

Criteria: Is the application easy to navigate? Does it work well in every major browser? Is it responsive? Does it incorporate modern UI Themes?

Strengths:

The application design is simple, straightforward, and modern. Fits the concept and user profile you've planned it for!
The app looks great on a desktop and a small screen as well! Kudos for implementing mobile responsiveness, which is such an important feature these days. The map feature is a bit too zoomed in on a small screen but that can be easily adjusted I'm sure.

Areas for Growth

Customize the header and the favicon of your application so that it doesn't look like an out-of-the-box React app.

Functionality - Performing

Criteria: Does the application work without errors or bugs? Does it present a complete app, where every feature is fully implemented in a way that makes sense?

Strengths:

The map and pricing features work as intended. Pricing data refreshes every five minutes.
No errors or bugs observed in either browser or console while using the application.

Areas for Growth:

As mentioned previously, keep building out the user authentication feature so that it does not feel half-implemented.

Presentation - Progressing

Criteria: Is there adequate documentation? Is the repository well-organized and free of clutter?

Strengths:

Frontend and backend repos are well-organized and free of clutter. No extraneous files noted.
Planning directory is included in the frontend repo.
Both READMEs are a great start, with an overview of your application, link to deployed version, features, technologies used, installation instructions and contribution guidelines. Way to also include known bugs and future updates.

Areas for Growth:

Add the deployed URLs to the descriptions tab at the top of both your repos.
The backend repo looks like it was a bit rushed ... be sure to revisit and apply your Markdown formatting to it like you did on the frontend!
Keep building out your README on both frontend and backend to meet the specifications noted below. Your README is the first point of contact with your application for visitors to your GitHub, so make sure that it highlights all the great code that you wrote and the awesomeness of the app you created!
Your planning folder includes a PowerPoint file, which is not great for GitHub as users would have to download it to view your amazing planning process. Instead try exporting the PowerPoint to a PDF or even better, images (.jpegs or .pngs) and uploading that instead. That will make your planning process MUCH more accessible to visitors.
In the React frontend, make sure to get rid of any files that automatically came with create-react-app.

Hard Requirements - (Mostly) Complete:

Technical Requirements:

[x] Be a complete product.
[x] Implement thoughtful user stories
[x] Be deployed online
[x] Use something we didn't teach in class

Repo Should Include:

[x] A working project (built by you) that meets the technical requirements above.
[x] Frequent commits dating back to the very beginning of the project.
[x] A readme.md file in the root of your repo that follows good standards of documentation (i.e. explanations of the technologies used, the approach taken, features, installation instructions, unsolved problems, etc.)
[x] A planning/ directory in the root of your repo containing a diagram mapping out your project domain. You are welcome to include other planning documents (e.g., wireframes, user stories). -- make sure to change this from a .pptx file to a .pdf or images.
[ ] A link to your hosted, working project in the URL section of your Github repo ❌

Pre-Deployment Checklist:

[ ] Add the deployed URL to repo settings ❌
[x] Add a readme with:
- [ ] An embedded screenshot of the app ❌
  - [x] Explanations of the technologies used
  - [x] Installation instructions for any dependencies
  - [ ] Link to your user stories – who are your users, what do they want and why? ❌
  - [ ] Link to your wireframes – sketches of major views / interfaces in your application ❌
  - [ ] Descriptions of any unsolved problems or major hurdles you had to overcome ❌

Grade: Pass! 🎉🎉🎉😎😎😎

Teresa, congratulations on passing Project 4 and graduating from SEIR! This project is such a great testament to the technical skills that you learned in our course as well as the softer project management skills that you learned. I know it was hard to cut back on your MVP features, but I'm proud of you for doing so and delivering a complete product. I can see that you're excited to dig in and keep working on features, including the user authentication piece, which I think will really help showcase all your technical chops.

Please continue to build out the README according to the checklist above. Having a screenshot of your app will help visually engage visitors -- it might also be good to have a site map, req/res cycle, and API endpoints illustrated. It will also really help if you export that PowerPoint planning file to images and link those in your planning repo for others to see ALL the incredible planning that went into your project. Unfortunately GitHub doesn't do a great job of hosting PowerPoints. The README is the first point of contact for technical visitors to your GitHub and projects, and having documentation that highlights the great planning and code that went into both the frontend and backend of this project will help others see all of your skills.

Congratulations again on finishing, and thank you for all the hard work you put into this project and this course. Wishing you all the best. Let me know if you have any questions!

Thanks, Essin for your recommendations.

I will improve it for sure and finished my golden project when I have a chance. I took this week off because I am overwhelmed with worries. My kids got exposed to the virus and now they are on quarantine, waiting for the symptoms to appear and praying. Keep safe in Austin and Please DO No go out. Stay home.

Today I have a job interview

On Wed, Mar 18, 2020 at 4:29 PM Esin Saribudak notifications@github.com wrote:

Project 4 Feedback Code Quality - Performing

Criteria: Is the code well-formatted? Are variable and function names semantic and sensible? Is the code easy to read and understand? Strengths:

Code is well-formatted in both repos, with sensible and semantic variable and function names.

Indentations, spacing and conventions are consistent throughout both repos.

Code is overall easy to read and understand, with no useless or spaghetti code (other than user-auth related components that I think you're working on incorporating!).

Areas for Growth:

Make sure you remove all console.logs from a deployed version of your application! Specifically, the Map.js component seems to console.log all the data points it retrieves on line 86. EditUser.js also appears to console.log the user's email address. Check both repos for any more and remove them from the master branch.

Any sensitive data such as access tokens should be hidden in an environmental variable and not pushed to GitHub.

Technical Requirements - Performing

Criteria: How does the project stack up to the requirements for this project? Are the developers making use of the material we've covered in a way that makes sense? Strengths:

Nice job meeting the technical requirements of this project! Your application is a complete product, deployed, and uses technology we did not cover in class.

Congratulations on learning and implementing Mapbox-gl ... it looks like you did a great job, and that map is such an impressive feature for your app! I love how you can scroll to zoom in and out, and getting those nodes to populate must have been challenging!

Good history of Git commits on both repos, with concise yet descriptive commit messages.

Areas for Growth:

I know you are planning to finish out the user authentication feature, and I think that's super important to finish it rather than leave a half-implemented feature. Right now the login/logout/edit/delete user feature appears to be more decorative than anything, which is a great start. I would suggest using bcrypt or passport.js to finish out that functionality.

Consider working on features on a separate branch other than master, so that your deployed application is production worthy without any incomplete features. When the feature is ready, you can merge the branches to incorporate your new code into your master branch, then redeploy to Heroku.

Try to format Git messages like this: singular present tense verb + what you did. For example, instead of 'mobile responsiveness', 'add mobile responsive styles', or something like that. More about good Git commit messages here https://chris.beams.io/posts/git-commit/.

Creativity and Interface - Performing

Criteria: Is the application easy to navigate? Does it work well in every major browser? Is it responsive? Does it incorporate modern UI Themes? Strengths:

The application design is simple, straightforward, and modern. Fits the concept and user profile you've planned it for!

The app looks great on a desktop and a small screen as well! Kudos for implementing mobile responsiveness, which is such an important feature these days. The map feature is a bit too zoomed in on a small screen but that can be easily adjusted I'm sure.

Areas for Growth

Customize the header and the favicon of your application so that it doesn't look like an out-of-the-box React app.

Functionality - Performing

Criteria: Does the application work without errors or bugs? Does it present a complete app, where every feature is fully implemented in a way that makes sense? Strengths:

The map and pricing features work as intended. Pricing data refreshes every five minutes.

No errors or bugs observed in either browser or console while using the application.

Areas for Growth:

As mentioned previously, keep building out the user authentication feature so that it does not feel half-implemented.

Presentation - Progressing

Criteria: Is there adequate documentation? Is the repository well-organized and free of clutter? Strengths:

Frontend and backend repos are well-organized and free of clutter. No extraneous files noted.

Planning directory is included in the frontend repo.

Both READMEs are a great start, with an overview of your application, link to deployed version, features, technologies used, installation instructions and contribution guidelines. Way to also include known bugs and future updates.

Areas for Growth:

Add the deployed URLs to the descriptions tab at the top of both your repos.

The backend repo looks like it was a bit rushed ... be sure to revisit and apply your Markdown formatting to it like you did on the frontend!

Keep building out your README on both frontend and backend to meet the specifications noted below. Your README is the first point of contact with your application for visitors to your GitHub, so make sure that it highlights all the great code that you wrote and the awesomeness of the app you created!

Your planning folder includes a PowerPoint file, which is not great for GitHub as users would have to download it to view your amazing planning process. Instead try exporting the PowerPoint to a PDF or even better, images (.jpegs or .pngs) and uploading that instead. That will make your planning process MUCH more accessible to visitors.

In the React frontend, make sure to get rid of any files that automatically came with create-react-app.

Hard Requirements - (Mostly) Complete:

Technical Requirements:

Be a complete product.

Implement thoughtful user stories

Be deployed online

Use something we didn't teach in class

Repo Should Include:

A working project (built by you) that meets the technical requirements above.

Frequent commits dating back to the very beginning of the project.

A readme.md file in the root of your repo that follows good standards of documentation (i.e. explanations of the technologies used, the approach taken, features, installation instructions, unsolved problems, etc.)

A planning/ directory in the root of your repo containing a diagram mapping out your project domain. You are welcome to include other planning documents (e.g., wireframes, user stories). -- make sure to change this from a .pptx file to a .pdf or images.

A link to your hosted, working project in the URL section of your Github repo ❌

Pre-Deployment Checklist:

Add the deployed URL to repo settings ❌

Add a readme with:

An embedded screenshot of the app ❌

Explanations of the technologies used

Installation instructions for any dependencies

Link to your user stories – who are your users, what do they want and why? ❌

Link to your wireframes – sketches of major views / interfaces in your application ❌

Descriptions of any unsolved problems or major hurdles you had to overcome ❌

Grade: Pass! 🎉🎉🎉😎😎😎

Teresa, congratulations on passing Project 4 and graduating from SEIR! This project is such a great testament to the technical skills that you learned in our course as well as the softer project management skills that you learned. I know it was hard to cut back on your MVP features, but I'm proud of you for doing so and delivering a complete product. I can see that you're excited to dig in and keep working on features, including the user authentication piece, which I think will really help showcase all your technical chops.

Please continue to build out the README according to the checklist above. Having a screenshot of your app will help visually engage visitors -- it might also be good to have a site map, req/res cycle, and API endpoints illustrated. It will also really help if you export that PowerPoint planning file to images and link those in your planning repo for others to see ALL the incredible planning that went into your project. Unfortunately GitHub doesn't do a great job of hosting PowerPoints. The README is the first point of contact for technical visitors to your GitHub and projects, and having documentation that highlights the great planning and code that went into both the frontend and backend of this project will help others see all of your skills.

Congratulations again on finishing, and thank you for all the hard work you put into this project and this course. Wishing you all the best. Let me know if you have any questions!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tfitzge134/wholeSaleprice-frontend/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANJPYBKITBXFYAPQQMAU7Y3RIEVMLANCNFSM4LOZ6S7Q .

Teresa Fitzgerald

tfitzge134 / wholeSaleprice-frontend