project-3

Project 3

Overview

You’ve already worked in small groups to accomplish various labs and exercises, but this time we’re going to challenge you to work on a whole project with a small team.

Not only will you be asked to exercise additional creativity in designing your own project, your instructors will partner you with other classmates to architect, design, and collaboratively build an application of your own design.

This is meant to push you both technically and collaboratively. It’s a lot harder to work in a team than to work by yourself, but that's most likely what you'll be doing in your first development job after SEI, and it's important to learn how to work together.

Make it work, and make it awesome.

Technical Requirements

Your app must:

• Build a full-stack application by making your own backend and your own front-end using the technologies we have studied this unit
• Have an interactive front-end, using a modern front-end framework
• Be a complete product, which most likely means multiple relationships and CRUD functionality for at least a couple models. However, this is ultimately up to your discretion.
• Implement thoughtful user stories that are significant enough to help you know which features to build and which to scrap
• Have a visually impressive design to kick your portfolio up a notch and have something to wow future clients & employers
• Be deployed online so it's publicly accessible -- we will have a deploy jam lesson together

Necessary Deliverables

• A working app, built by the whole team, hosted somewhere on the internet
• A link to your hosted working app in the URL section of your Github repo
• A team git repository hosted on Github, with a link to your hosted project, and frequent commits from every team member dating back to the very beginning of the project.
• A readme.md file with:
  • Include a screenshot of the site in repo's README
  • Explanations of the technologies used
  • A couple paragraphs about the general approach you took
  • 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
  • A RESTful routing chart that describes every route in your application and their CRUD functionality
  • Descriptions of any unsolved problems or major hurdles your team had to overcome

Project Feedback + Evaluation

• Project Workflow: Did you complete the user stories, wireframes, task tracking, and/or ERDs, as specified above? Did you use source control as expected for the phase of the program you’re in (detailed above)?
• 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? Did you deliver something of value to the end user (not just a login button and an index page)?
• 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 as we have in class?
• Problem Solving: Are you able to defend why you implemented your solution in a certain way? Can you demonstrated that you thought through alternative implementations? (Note that this part of your feedback evaluation will take place during your one-on-one code review with your instructors, after you've completed the project.)
• Total: Your instructors will give you a total score on your project between:

This project will be graded on a Pass/Fail basis

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!

Pitch Requirements

Pitches will be a readme in the project repo that includes the following:

• Project Idea and descriptions
• if your group is using an API
  • choice of API you are going to use and a proof of concept (API keys -- hitting the api)
• If your group is using additional technologies/npm packages
  • proof of concept with the new teachnology
• ERDs
• Restful Routing Chart
• Wireframes of all user views
• User Stories
• MVP goals/Stretch Goals

Suggested Ways to Get Started

• Find techs and APIs that look interesting -- how can you use them in your project?
• Are there any node packages you could use?
• what about frameworks for UI?
• explore the techs you would like to use and most importantly -- work with them!
  • get node packages up and running
  • get api keys and explore the responses
• Explore Collaboration tools that you would like to use
  • Hackmd is great for sharing and collaborating on markdown files
  • Trello Boards Can help teams manage sprints and tasks
  • Miro Canvases Are great for collaboration spaces to house everything your team needs to communicate and work together

• Don’t hesitate to write throwaway code to solve short term problems.
• Read the docs for whatever technologies / frameworks / APIs you use In fact, you should most likely tackle your APIs first.
• Write your code DRY and build your app to be RESTful.
• Be consistent with your code style. You're working in teams, but you're only making one app per team. Make sure it looks like a unified effort.
• Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
• Keep user stories small and well-defined, and remember – user stories focus on what a user needs, not what development tasks need accomplishing.
• Write code another developer wouldn't have to ask you about. Do your naming conventions make sense? Would another developer be able to look at your app and understand what everything is?
• Make it all well-formatted. Are you indenting, consistently? Can we find the start and end of every div, curly brace, etc?
• Comment your code. Will someone understand what is going on in each block or function? Even if it's obvious, explaining the what & why means someone else can pick it up and get it.
• Write pseudocode before you write actual code. Thinking through the logic of something helps.

Need Some Inspiration?

You can make an app about anything you and your team wants! However sometimes it is difficult to come up with something without a specific prompt.

For those that want to use it, here are some sample prompts.