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.
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.
Your application must:
-
Use at least one JavaScript library that is not jQuery. Examples:
-
Use a CSS framework. Examples:
-
Access at least two remote APIs using AJAX. Examples:
- Firebase
- TheCatAPI
- Google Maps
- Big List of Public APIs
- Another Big List of 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
- Google Cloud
- Netlify
- Neocities
- Surge
- 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:
- 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
-
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
-
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.
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
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:
You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.