WDI Project Two
Build a web-based, CRUD application.
Presentations will be Tuesday Jan 23 after Lunch
Build confidence as a developer by building a full stack app your own.
- Manage yourself (your time and your emotions) when given a large amount of unstructured work. Managing stress is one of the main skills of coding.
- Gain experience building a complex application.
- Document your work and share it with the public in an effective and articulate manner.
- Learn new technologies by reading documentation and experimenting.
You will be expected to use the following technologies to implement this project:
HTML / EJS: Your HTML should be semantic and valid. Your app uses EJS to render information on the page.
Node and Express: Your app will need to have its own server, built using Express.
MVC Pattern: Your app uses Models, Views, Controllers pattern we have gone over in class.
Mongo + Mongoose: Your app will need to persist data. Your app should have at least two database tables. The second DB table can be post-MVP.
CSS & Design: Your app should be pleasing to look at. Your design should take usability into account.
At least 2 Resources: Relationship optional, but recommended. Most projects require one One-to-Many relationship to function properly :)
One of these:
- Using a third party API like Twilio, or OMBD, Google Maps, etc.
Here's a description of an example project: Forum
Project 2 Proposals
The following are requirements for your Project 2 Proposal
- Database ERD- draw out the tables & columns you plan to use in your database. Here's a resource on creating an ERD (an Entity Relationship Diagram, or database diagram).
- Wireframes - detail the flow of your app through simple wireframes
- You can choose whether you want to whiteboard the wireframes or use some program.
- Routes - design the HTTP route architecture of your app. This should look something like this
- For this project we want you to use Trello. Give us a link to a trello board with all of your User Stories as items on the Trello board. Your collumns should be Todo, In Progress, and Complete. Here's a good resource on using Trello for Kanban
- A full CRUD app, with create, edit, and delete functionality, hosted on Heroku
- A public repository on Github.com with your code for this project & a thorough commit history dating back to the beginning of the project
- A thorough
README.mdfile that contains the following:
- The project's name and description
- Your wireframes and user stories
- The technologies, APIs, and modules you used and a description of each
- A code snippet of a part of the app you're particularly proud of
- Any things you plan to fix or features you plan to add
- Instructions for downloading the code and running it on localhost
- A presentation in class that:
- Is 5 minutes in length
- Shows off the features of the app you're most proud of
- Explains one or two technical details
- Explains one or two technical challenges
- Explains which improvements you might make
Reach out to your peers! Collaborate! Help your fellow students! If you've done that, and still have been stuck for more than an hour, reach out to your instructors!
Keep in Mind
You are going to encounter a ton of unexpected errors and problems.
Expect to come up against a lot of what can seem like roadblocks. Resist the urge to get frustrated. These are amazing learning opportunities. A lot of students treat errors during projects as just getting in the way of "finishing". The point of this project is not to finish everything; the point is to integrate your knowledge and deepen your understanding of how to put apps together.
Errors often provide the most valuable source of information about what we don't yet understand. Seeing an error as "it's not working" and randomly changing code until "it works" won't teach you anything. Spending time thoughtfully debugging issues is a fantastic investment that will lead to greater mastery and understanding.
If you feel yourself getting frustrated or mad, take a walk! Get some tea! Go outside for 10 minutes. No one can think clearly when they are frustrated, and it will all be there for you when you get back. Its seriously better to take too many breaks than too few.
Project Feedback + Evaluation
Project Workflow: Did you complete the user stories, wireframes as specified above? Did you use source control (Git) as expected for the phase of the program you’re in (detailed above)? Did you submit your project via an issue ticket on GHE?
Technical Requirements: Did you deliver a project that met all the technical requirements? Given what the class has covered so far, did you build something that was reasonably complex?
Creativity: Did you added a personal spin or creative element into your project submission?
Code Quality: Did you follow code style guidance and best practices covered in class, such as spacing, modularity, and semantic naming? Did you comment your code as your instructors have in class?
Deployment: Did you deploy your application to a public url using Heroku?
Presentation: Note: this is not graded, but part of the project. Did you present your app, your code, and your project-making experience clearly and effectively to the class?
Total: Your instructors will give you a score for each section between:
|1||Does not meet expectations.|
|2||Meets expectations, good job!|
|3||Exceeds expectations, you wonderful creature, you!|
This will serve as a helpful overall gauge of whether you met the project goals, but the more important scores are the individual ones above, which can help you identify where to focus your efforts for the next project!
A Note on Plagiarism
Plagiarism is a serious offense and grounds for expulsion. Our entire policy can be found in the wiki.
You are encouraged to ask others, including students, instructors, and stackoverflow, for help. However, it is NOT ACCEPTABLE TO COPY another person's code and submit it as your own. More importantly, it is detrimental to your learning and growth.
Small snipits of code that solve small problems taken from Stack Overflow are generally an exception to this rule. If you aren't sure, it is your responsibility to ASK. To be on the safe side, why not credit the person/ resource you got the code from in a comment, and let an instructor take a look at it.
All of the following are considered plagiarism or cheating:
- Turning in work that is not your own.
- Turning in someone else's work as your own.
- Hiring, or paying someone to do your work for you.
- Copying words or code without giving credit.
- Building or copying someone else’s idea without their knowledge or giving credit.
- Changing words, variable names, etc. but copying the code or files of a source without giving credit.
- Copying so many ideas or code blocks from a source that it makes up the majority of your work, whether you give credit or not.
In an effort to not plagiarize, credit for this content goes to:
- Plagiarism.org, specifically the “plagiarism 101” section. Content was adapted for code. For more information, please see:
- How do I safely write code in my own 'words' and not plagiarize?
- Avoiding Plagiarism: Writing Computer Code