|
|
#  Project #3: Building Your Own API with AJAX
|
|
|
|
|
|
### 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 API of your own design.
|
|
|
|
|
|
While your last project taught you how to get started with Ruby, SQL, & Ruby on Rails, this project you'll be building something exciting with **Express & Mongo & AJAX**
|
|
|
|
|
|
**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 you’re going to find yourself doing in your first development job after WDI, and **it's important to learn how to work together.**
|
|
|
|
|
|
Make it work, and make it awesome.
|
|
|
|
|
|
---
|
|
|
|
|
|
### Before you start coding
|
|
|
|
|
|
* Have your project idea approved by an instructor
|
|
|
|
|
|
---
|
|
|
|
|
|
### Technical Requirements
|
|
|
|
|
|
Your app must:
|
|
|
|
|
|
* **Use Mongo & Express** to build an API and a front-end that consumes it
|
|
|
* **Create an API using at least 2 related models**, one of which should be a user
|
|
|
* Include **all major CRUD functions** in a **RESTful API** for at least one of those models
|
|
|
* **Consume your own API** by making your front-end with HTML, Javascript, & jQuery
|
|
|
* **Add authentication to your API** to restrict access to appropriate users
|
|
|
* **Craft thoughtful user stories together**, as a team
|
|
|
* **Manage team contributions and collaboration** using a standard Git flow on Github
|
|
|
* Layout and style your front-end with **clean & well-formatted CSS**
|
|
|
* **Deploy your application online** so it's publically accessible
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
### Necessary Deliverables
|
|
|
|
|
|
* A **working API**, hosted somewhere on the internet
|
|
|
* A handmade front-end **that consumes your own API**, 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:
|
|
|
* 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
|
|
|
* Descriptions of any **unsolved problems** or **major hurdles** your team had to overcome
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
### Git Collaboration
|
|
|
|
|
|
* Your group will elect a **Git Czar** to handle merging all pull requests. This person will be making sure any mergable commits are safe and able to be merged into the master branch.
|
|
|
* When you are done working on a feature, a pull request will be submitted. The person making the pull request is responsible (in collaboration with others if neccessary) for making sure that the PR is mergable.
|
|
|
* Don't make your feature branches too large or leave them out of master for too long, ideally you should be creating and merging a feature branch within a couple of days.
|
|
|
* Refer to the [git branching lesson notes if helpful](https://github.com/ga-students/wdi_lettuce_students/blob/master/w08/d04/INSTRUCTOR/branching.md)
|
|
|
|
|
|
---
|
|
|
|
|
|
### Standup / Trello
|
|
|
|
|
|
* Your trello board should have individual tasks that are assigned to each person, tagged with a given feature.
|
|
|
* Standup should happen for every day you agree to work, or everyday someone is working.
|
|
|
* It should include 3 things: What I got done yesterday, what I am doing today, what my blockers are. (blockers are anything that you are waiting on that's not in your control)
|
|
|
|
|
|
---
|
|
|
|
|
|
### Suggested Ways to Get Started
|
|
|
|
|
|
* **Don’t hesitate to write throwaway code** to solve short term problems.
|
|
|
* **Read the docs for whatever technologies / frameworks / API’s you use**.
|
|
|
* **Write your code DRY** and **build your APIs 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.
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
### Potential Project Ideas
|
|
|
|
|
|
For this project, we want you to work with your team to build a creative product that you actually think someone will want to use. We won't have time to do tons of customer research, but take some time to brainstorm. If you're struggling for ideas, the ones below could help get you started.
|
|
|
|
|
|
##### Bucketli.st
|
|
|
Besides finishing WDI, you surely have one or two things you'd love to do with your life. Let's get 'em on paper! You could integrate with a third-party location-based API to allow users to search for a location or venue to add to their bucket list items.
|
|
|
|
|
|
##### Survey App
|
|
|
Imagine sending out a survey to everyone in the class – what should we eat for lunch today? Or 1-5, how well did you understand what we just learned? It would be even more awesome if it were realtime, so you could see answers pouring in as they're submitted.
|
|
|
|
|
|
##### Hello, Comments
|
|
|
Imagine the benefits of having an API where you could embed comments into any website you want. They could even update in realtime if you wanted, so that you'd never have to refresh the page. CMS providers across the world could quit writing code from scratch and just embed your widget instead.
|
|
|
|
|
|
---
|
|
|
|
|
|
### Useful Resources
|
|
|
|
|
|
* **[MongoDB](https://www.mongodb.org/)**
|
|
|
* **[Express JS](http://expressjs.com/)**
|
|
|
* **[Getting Starts with Node.js on Heroku](https://devcenter.heroku.com/articles/getting-started-with-nodejs)**
|
|
|
|
|
|
---
|
|
|
|
|
|
### 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.)_
|
|
|
|
|
|
|
|
|
##### Mid Project Retro Schedule
|
|
|
|
|
|
| | Joe | Akira | Thom | Jason |
|
|
|
|:----- | :----- |:----- |:----- |:----- |
|
|
|
| tuesday 11/24 1:30 - 2:00 | Stannis | Danaerys | Eddard | Drogon |
|
|
|
| tuesday 11/24 2:00 - 2:30 | Oberyn | Arya | Cersei | Tyrion |
|
|
|
|
|
|
https://github.com/ga-students/wdi_lettuce_students/blob/master/projects/midretro.md
|
|
|
|
|
|
#### Post-project retro one-on-one:
|
|
|
* we will have some scheduled time to talk about your project and yur code.
|
|
|
* please have the questionaire filled out before your scheduled time.
|
|
|
* each team member should fill out a retro **individually**, and discussion will happen as a group
|
|
|
|
|
|
##### Post Project Retro Schedule
|
|
|
|
|
|
| | Joe | Akira | Thom | Kristyn |
|
|
|
|:----- | :----- |:----- |:----- |:----- |
|
|
|
| thursday 12/3 4:00 - 4:30 | Stannis | Danaerys | Eddard | Drogon |
|
|
|
| thursday 12/3 4:30 - 5:00 | Oberyn | Arya | Cersei | Tyrion |
|
|
|
|
|
|
https://github.com/ga-students/wdi_lettuce_students/blob/master/projects/postretro.md
|
|
|
|
|
|
|
|
|
|
