An open API service indexing awesome lists of open source software.

https://github.com/oakmac/phase1-final-project-requirements

Final Project Requirements for Phase 1 - DigitalCrafts Flex coding bootcamp
https://github.com/oakmac/phase1-final-project-requirements

Last synced: 9 months ago
JSON representation

Final Project Requirements for Phase 1 - DigitalCrafts Flex coding bootcamp

Awesome Lists containing this project

README

          

# Final Phase 1 Group Project Requirements

This is the final project for "Phase 1" of the Flex course for [DigitalCrafts]
Houston.

> NOTE: You must complete this project in accordance with the requirements laid out
below in order to fulfill Texas state requirements for credit for the course. If
you have any questions or concerns about the requirements, please see an
instructor.

[DigitalCrafts]:https://www.digitalcrafts.com/

## Project Description

Your task is to build an awesome web application as a group! Mix and match
libraries and APIs to build a useful front-end web application.

You will be using the front-end skills you have developed throughout Phase 1:
HTML, CSS, JavaScript, AJAX, Bootstrap, APIs, etc.

## Technical Requirements

Your application **must**:

- Use at least one JavaScript library that is not jQuery. Examples:
- [Moment.js](https://momentjs.com/)
- [Marked](https://marked.js.org/)
- [jQuery UI](https://jqueryui.com/)
- [chessboard.js](http://chessboardjs.com/)
- [Additional List](./additional-libraries.md)

- Use a CSS framework. Examples:
- [Bootstrap](http://getbootstrap.com/)
- [Bulma](https://bulma.io/)
- [Foundation](https://foundation.zurb.com/)

- Access at least two remote APIs using AJAX. Examples:
- [Firebase](https://firebase.google.com/)
- [TheCatAPI](https://thecatapi.com/)
- [Google Maps](https://developers.google.com/maps/documentation/)
- [Big List of Public APIs](https://github.com/toddmotto/public-apis)
- [Another Big List of Public APIs](https://github.com/abhishekbanthia/Public-APIs)
- Note that loading a JavaScript or CSS library from a CDN does not fulfill this requirement.
You must use AJAX.

- Your project must have a `README.md` file written using [Markdown] with at least the following:
- Explanation of what the project is / what it does.
- What technologies you used.
- List of team members.

- Deployment of your application to somewhere other than GitHub Pages. Examples:
- [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html)
- [Google Cloud](https://cloud.google.com/storage/docs/hosting-static-website)
- [Netlify](https://www.netlify.com/)
- [Neocities](https://neocities.org/)
- [Surge](https://surge.sh/)
- Note that you do not need to purchase a domain name for your project. But it
should be reachable via a public URL somewhere.

- Your repo must be connected to [Travis CI](https://travis-ci.org/):
- You must run at least one test in your Travis CI build (hint: test for [StandardJS])
- Put a build status badge in your `README.md` that links to your latest build

- Code must follow some organization scheme.
- Everything cannot be in one super long file.
- Break different parts of the code into different files / modules.
- No "spaghetti code".
- Bonus / optional: consider using a build system with [npm scripts], [browserify], or [webpack]

[Markdown]:https://guides.github.com/features/mastering-markdown/
[StandardJS]:https://standardjs.com/
[npm scripts]:https://deliciousbrains.com/npm-build-script/
[browserify]:http://browserify.org/
[webpack]:https://webpack.js.org/

## Workflow Requirements

- Teams will be groups of 3-5 students and assigned by instructors.

- Create one GitHub repo and add all group members as collaborators.

- Collaborate using Pull Requests (PRs):
- No one should commit to the master branch directly.
- Every PR should be reviewed and approved by at least one team member (not the person who originated the PR).
- PRs should not be merged by the person who opened it (no self-merging).
- See below for [suggested PR rejection criteria](#suggested-pr-rejection-criteria)

- Project features and bugs must be tracked using a [scrum]-like system:
- Every PR should be associated with a GitHub Issue (or similar).
- Consider using a tool like [GitHub Project Board] or [Trello].
- Every class day teams will have a "stand up meeting" with a TA or Instructor.

[scrum]:https://en.wikipedia.org/wiki/Scrum_(software_development)
[GitHub Project Board]:https://help.github.com/articles/about-project-boards/
[Trello]:https://trello.com/

## Suggested PR Rejection Criteria

It's ok to reject a PR or have a PR rejected - that is what the PR process is
for! Remember if your PR is rejected that doesn't mean you are a bad person and
stink at life. It just means that your teammate(s) see something that could be
improved. The PR process is more about sharing knowledge than "you did something
wrong".

Any of the following are valid reasons to reject a PR:

- Breaks the build (Travis CI breaks)
- Does not fulfill feature
- Breaks other feature
- Does not follow team coding style / standards
- Too much to review / large code diff (ie: should be broken up into smaller PRs)
- Code in the PR does not match up with commit message
- Commit message is vague

## Learning Objectives

By the end of Phase 1 you should have most of the skills necessary to understand
much of the world of web development (HTML, CSS, JavaScript). The intent with
these requirements is for each student in the group to use these skills to learn
something new and use it in a "real world" way. Searching for external resources
and being able to understand and apply documentation is a big part of software
development. Whether it is an API, a new JavaScript library, deployment,
testing, etc. Go learn something new and put those web development skills to
work!

Another goal of this project is polish / thoroughness. A thorough `README.md`,
testing via Travis CI, deploying to a public web server, thoughtful commit
messages, following a PR review process, good code organization, etc are all
signals of quality software development. The end result of this project should
be a portfolio piece that you are excited to put on your resume and share with
friends and family: "Hey - look at this cool thing I built!" Look for
opportunities to polish and show the world what you can do!

--------------------------------------------------------------------------------

This requirements document is licensed as [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/):

> You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.