Read this entire document before writing a line of code.
- Overview: What is this project?
- Big Goals: What should I focus on?
- Technical Requirements: What technologies will I be using?
- Further Exploration: What if I want to do more?
- Planning & Deliverables: What will I be turning in?
- Deadlines: When is the project due?
- Submission: How do I turn in the project?
- Presentation Guidelines: What should I cover during my presentation?
You’ve come a long way, and it's time to show it. This will be your most advanced project to date, and it'll hopefully be the shining beacon in your portfolio as you make your way out into the world of web development.
You get to call the shots and invent your own idea, choosing a framework & tools that are appropriate for what you want to build. Pull from everything you've learned so far, and tackle something that'll push you a little outside of your comfort zone.
Make sure it's something you can accomplish in the limited time we have, and make sure it's something that will be visually impressive. For better or worse, sometimes people do judge a book by its cover – or an app by its design.
- Discover or invent an idea, preferably one with some group of users that would jump at the chance to really use your product.
- Design a product you want to build, and choose appropriate technologies to build it.
- Pitch your idea to your classmates and instructors, and incorporate their feedback.
- Make productive use of your time, and balance responsibilities to make a complete, functional, and impressive-looking project.
- Focus on writing solid code that is well-documented and DRY.
Your app must meet the following technical requirements:
- Use a database, whether it's one we've covered in class or one you want to learn.
- Build a full-stack application by making your own back-end and your own front-end.
- Create a complete product, which most likely means multiple related models and CRUD functionality for each.
- Create a focused product. Know which features are essential to build for your MVP and which to set aside for later.
- Implement thoughtful user stories that that are clear and enough to help you know which features to build and which to scrap; and also are well-designed enough to help you ensure a pleasing and logical user experience.
- Handle errors gracefully, and provide useful feedback to users when errors or validation failures do occur.
- Make a product that's impressive-looking; up your design and style game to kick your portfolio up a notch.
- Deploy your application online so it's publicly accessible.
- Incorporate an external API to add data and functionality to your application.
- Use a data visualization library to help users understand your core data.
- Implement third-party log in to allow users to access data from other services.
- Build something you can really launch, and recruit an actual user-base.
- Test critical components of your code to ensure that it works.
- Research web accessibility (e.g., for blind users), and apply accessibility principles to your app.
You should review the following with your instructional team BEFORE you start to code.
- Scope: What are you planning to build? What do you reasonably think you can implement in the time period?
- User Stories: Who is your user? What features will your app have? Set up your project and user stories using Trello or another system/tool that works for you.
- Wireframes: Sketch out what your core pages will look like and how they will work. Consider making a paper prototype to demonstrate and/or test key user interactions.
- Data Models: Draw out the models and any associations for your project in an entity relationship diagram (ERD).
- Milestones: Divide your work into parts - the most essential features for your MVP, features that are important but not essential, and features that can be saved for a later iteration. Create 3-5 major milestones with dates outlining when you expect essential features will be done.
- Feasibility Study: If you're using an external API or scraping a website, make sure right away that you can actually get that data. If you're using a new language, framework, or tool, go through its getting started tutorial. We will ask to see your results.
- A working API, hosted somewhere on the internet
- A working front-end, hosted somewhere on the internet
- A git repository hosted on Github, with frequent commits dating back to the beginning of the project.
- A link to your hosted working client app in the URL section of your Github repo.
- A link to your hosted working API app in the URL section of your Github repo.
- A
README.mdfile in your front end repo with:- A link to your hosted working app.
- A paragraph-long description (elevator pitch) of your project.
- A list of the technologies used.
- A list of installation steps for the app itself and any dependencies - how would another developer run your site locally?
- 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.
- Link to your entity relationship diagrams – plan out your data relationships before coding.
- Descriptions of any unsolved problems or future features.
- A
README.mdfile in your API, if applicable, with a description of what the API is, how to access it, and each endpoint you expose.
-
TUESDAY, NOVEMBER 27 - Project planning deliverables due! Before beginning work on your project, your idea, project scope, and other planning deliverables must be approved by an instructor.
-
WEDNESDAY, DECEMBER 5 - You've reached a stopping point. App deployed without non-functional parts or errors. Wednesday afternoon and evening you will be focusing solely on putting together an engaging presentation. This is the presentation to make count.
-
THURSDAY MORNING, DECEMBER 6 - Completed project deliverables due and presentations!
- As you make code changes, frequently commit and push to GitHub.
- You will be required to submit the GitHub URL and the URL to the live site for both the front end and the API.
At the end of this project, you'll present a formal presentation THURSDAY MORNING, DECEMBER 6.
Each presentation should be 10-12 minutes, and should be positive, meaning, it focuses entirely on the things you did manage to get complete.
It should cover the following:
- Who are you?
- What is your project?
- What problem or pain point does it solve/address?
- Why were you motivated to make it.
- Demo of your project's core functionality. Take us through the website with a compelling demonstration of all the functionality you've implemented. (this should be the bulk of your presentation)
- What is one feature you're particularly proud of? (show code)
- What's one challenge you crushed and feel good about? (show code)
- Forthcoming features (be brief and positive)
- Q + A (save a few minutes for this)
- Shout-outs for your fellow classmates and those who have helped you!
- Parting shot: Knowing what you know now, what would you tell your 3-months-ago self? What advice would you give to students starting the next cohort?
Presentations should not include the following:
- Discussion about how some library or API was difficult to wrangle and how that screwed you up
- Discussion of all the things that don't work and should be there but aren't
- Design/Brainstorm/Enjoy this greenfield opportunity. Solidifying user stories & wireframes before writing code means you won't get distracted changing your mind – you'll know what to build, and you can spend your time wisely by just building it.
- Don’t get too caught up in too many awesome features – simple is always better. Build something impressive that does one thing well.
- Read the docs for whatever technologies / frameworks / API’s you use. Then read them again. Then do the basic tutorials of them. Focus on assessment and whether it will help you build your idea. You should choose the tool that suits the job.
- Write pseudocode before you write actual code. Thinking through the logic of something helps.
- Write throwaway code to solve short term problems or as intermediate steps towards solving larger ones. All developers do this all the time
- Write your code DRY
- KISS: Make sure your functions/routes/components focus on doing one thing well.
- Make it all perfectly-formatted. Are you indenting, consistently? Can you find the start and end of every div, curly brace, etc? As trivial as it seems when you're crunching on an idea, people considering hiring you will absolutely look at this, and debugging and refactoring are demonstrably easier when indentation/formatting is consistent.
- Be consistent with your code style. Choose patterns that make sense for reasons that you can defend and stick to them.
- 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, including yourself in a few weeks or months.
- 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? Are your method, class, and variable names semantic?
- 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.
In certain circumstances, which you should discuss with your instructor, you may continue/extend a previous project. If doing this, you must lay out in your Project Planning materials for the two weeks worth of work you plan on doing. The purpose of this Project continuation alternative is to give you an opportunity to both get out of your comfort zone and expand a bit into uncharted territory for you and still leave with a functioning, beautiful portfolio project with its loose ends tied up.
If you're interested in this, you will need to discuss it with your instructor, and your plan will need to be reasonably involved and exceptionally clearly planned considering the 10 days you have to work on it.
-
Project Workflow: Did you complete the required user stories, wireframes, task tracking, ERDs, and READMEs 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 add 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?
-
Deployment and Functionality: Is your application deployed and functional at a public URL? Is your application free of errors and incomplete functionality? Does it run both in production, and when cloned onto a local machine?
-
Presentation: Can you discuss your project and your coding decisions in an confident and compelling way? Were you prepared? Did you focus on what you did and will get done and avoid rambling about what didn't work out or how hard some tool you tried to use is to get working? Is your presentation meaningful for someone who isn't a developer?
-
Problem Solving: Are you able to defend why you implemented your solution in a certain way? Can you demonstrate that you thought through alternative implementations? (Note that this part of your feedback evaluation will depend on your interactions with your instructor throughout the project phases. As such, it will not factor into your total score, and will be very subjective, or minimal for some students.)
-
Total: Your instructors will give you a total score on your project between:
Score Expectations 0 Incomplete. 1 Does not meet expectations. 2 Meets expectations, good job! 3 Exceeds expectations, great job!
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.