COMP 120: Web Engineering

Spring 2017 Semester Project

Scenario

Yours truly has become the interim Vice President of Campus Services at a major university. I am looking for your help to bring Campus Services at the school to the 21st century with regards to technology.

Responses to Your Questions

Q: Is there a target audience in mind?

A: Campus Services serve the student, faculty, staff, alumni, guests, and affiliates

Q: What type of solutions: web or mobile?

A: Both. You cannot ignore mobile. To illustrate the importance of mobile, over 50% of the traffic to our website now come from mobile devices.

Q: How many students, faculty, and staff?

A: There is well over 50,000 active student, faculty, and staff in total. This may / may not include affiliates.

Q: Are there services, resources that we can use?

A: We currently have a website which is largely brochureware.

Q: What data should be made public? What data should be made private?

A: Data on personnel and anything inventory related (e.g., location and size of water tanks, boilers, devices containing refrigerants) must be made private. There is also a federal law, Family Educational Rights and Privacy Act (FERPA), that protects student data privacy.

Q: Is there an Single-Sign On (SSO) system used at the University?

A: Yes, but I do not know much information about it.

Q: Do you want a portal for everything or a tool or web apps for specific task?

A: As I mentioned earlier, we currently have a website which is largely brochureware. Incremental improvements over a massive system make more sense --and less overwhelming for people to deal with. Lots of people do not need everything.

Q: What are the different departments under Campus Services?

A:

Q: Are there are immediate deficiencies you can think of?

A: Process. We have lots of overhead. My goal in the next three years is to make Campus Services more efficient and leaner.

Q: Can you give me an idea of the budget?

A: We are looking to hire at least 3 more people to support the mission of bringing Campus Services at the school to the 21st century with regards to technology.


Leg 1: Your Job Is Not to Write Code

Overview

For the next few weeks, your team will build a minimal viable product of your team's project idea. A Minimum Viable Product (MVP) "is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html). Future builds will include user authentication and API design.

Preliminaries

Read Your Job Is Not to Write Code. The point of this reading is to make you think about the value of your work now and in the future.

Instruction

For Thursday, February 2nd, your team shall prepare and create:

  1. A short description of your team's project idea.
  2. A data schema for your team's project idea. While the data schema does not have to be thorough, it should not restrict potential expansion.
  3. A wireframe of the most important views of your team's project idea (i.e., the front end).
  4. An explanation of your team's design rationales.

Submission

The first entry of your engineering notebook shall be about your project. The entry shall contain pictures of data schema and wireframes. The entry shall also elaborate on the design rationales.

The notebook can be in form of a blog (e.g., Tumblr, GitHub, WordPress). An example of a good engineering notebook from the Mobile Development class in fall 2016: https://lunaandchris.wordpress.com/. Social media (e.g., via Twitter, Facebook, Snapchat) is not acceptable as your engineering notebook.

Email me link to your engineering notebook.

Presentation

In class on Thursday, February 2nd, 5 teams, chosen at random at least 24 hours before class, will present their data schema and wireframe to the class. A selected team will have 5 minutes to explain their design rationale to the class, and 5 minutes for questions and answers from the class.

Restrictions

Do not create a slide deck (e.g., a PowerPoint or Google Docs presentation). It is not a good use of our time. You also need to develop the skill of giving short verbal pitches (in this case, explaining what your team's project idea is).


Leg 2: Exploring Your Options

Overview

In previous years, a specific programming language and web framework were chosen for the semester project. (can you guess why?) This year, there will be no technology constraints for the semester project: your team can use any web framework, programming language, or database for the semester project. While given enormous flexibility this semester, it comes at the expense of understanding risks and limitations. Your team's goals for this leg are to explore possible options and to weigh the pros and cons of each possible option. IMPORTANT: your team's job is not to make any decisions until you hear thoughts and comments from other teams in the class.

I've realized that selecting a specific programming language and web framework for the semester project is not necessarily a good thing. While it forces students to learn perhaps a new programming language or web framework, new programming languages and web frameworks spawn (and change) constantly. Thus, pigeonholing into specific technologies is a disservice for the long-term.

Instructions

As an entry in your team's engineering notebook, select at least two web frameworks, at least two databases, at least two front-end frameworks (if any), and at least two hosting infrastructures that your team may want to use. For each option, list the pros and cons. Cons can include cost, lack of knowledge (e.g., members of team have no knowledge of programming language X). Statements containing little substance such as: "Person A absolutely despises technology Y" are not acceptable.

Purposes of This Leg

The main purpose of this leg is to eventually build a good story to tell on why certain technologies are being used. A good example is Instagram: read https://engineering.instagram.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad#.slz0w5q5m. The other purpose of this leg is to lead each team build competency in new areas.

Presentation

In class on Tuesday, February 14th, 5 teams, chosen at random at least 24 hours before class, will present their options to the class. A selected team will have 5 minutes to explain their options and risk analysis to the class, and 5 minutes for questions and answers from the class.


Leg 3: Implementing the Minimum Viable Product

Overview

Your team must now implement a minimum viable product (MVP) using the data schema, wireframe, and technology decisions made previously. The idea of a minimum viable product is to get something to market as soon as possible, get real people using it, and then iterate or add features based on user feedback instead of assumptions.

Doing an MVP

Some reads to learn more about the idea of an MVP of a product:

Requirements and Constraints

  1. Your team is required to implement the one or two most critical features of the web application. Each feature must follow RESTful patterns.
  2. Your team is required to make the MVP "pretty." That is, use a number of (e.g., more than 1) JavaScript files and stylesheets.
  3. Do not push any code to the master branch on Git repository. Create and work off of a different branch (e.g., alpha, experimental).
  4. Do not deploy this MVP to production (e.g., using Heroku). For this leg, this MVP shall run on localhost. Static content such as photos and videos shall be stored in a folder on localhost for now.
  5. Do not do more than the above requirements. Do not go above-and-beyond the requirements (e.g., implement the entire product)!

Submission and Structuring Your Private GitHub Repository

The code shall reside at the top-level of your private GitHub repository. For example if you are Team 1, the directory structure shall look something like the following in a non-master branch:

comp20-s2017-team1 
|
| - - README.md
|
| - - Web framework stuff

The reason for this is for easier deployment of your work in the near future.

The README.md and Entry In Your Engineering Notebook

In the README.md file at the root of your team's private repository, list all packages, APIs, and dependencies that are used --and link to each dependency's developer documentation

In your weekly entry in your team's engineering notebook, be sure to mention:

  1. Approximate number of hours your team spent learning the technology stack
  2. Approximate number of hours your team spent implementing the MVP
  3. The challenges your team faced working on this leg

Presentation

In class on Tuesday, March 7th, 4 teams will present their MVP to the class. Each selected team will have 5 minutes to show their MVP and 5 minutes for questions and answers from the class.


Leg 4: Production, Unit Testing, Code Review, and Static Content Optimizations

Overview

Imagine: your product could receive as many as 15,000 unique visits per day once it is in production. Your team is about to go there. It is time to "go live" --deploy your Minimum Viable Product (MVP) to production. The world of production is very different than development or testing environments as production is very unforgiving. There was a recent article: "You can’t have a rollback button. The Internet is a big truck. It’s really hard to drive it backwards."

Deliverables

For this leg and for the next two weeks, your team shall make at least three entries in your engineering blog:

  1. In one post, announce the live URL of your team's MVP and explain why your team chose the test framework(s) that are being used.
  2. In a second post, your team shall review the source code of another team's project. The team will be randomly assigned to you --see below. NOTE: please provide constructive comments. Destructive and uninformative comments will be not be tolerated. Your job is to make other team's apps better.
  3. In a third post, prove to everyone that the performance of your product has vastly improved compared to what you originally wrote (or hacked). Specifically, you must answer the following questions:
    1. What optimization techniques did you use?
    2. What tools did you use to test the performance of your product before and after optimizations made? Using no tools for this leg is not acceptable! More below.
    3. What performance aspects have been improved (e.g., loading time, file size)? Please provide numbers, percentages, or letter grades.
    4. Are there any lingering potential performance issues?

Code Review Lottery

Each team has been randomly assigned another team's source code to review. Each team has been given read access to each team's repository on GitHub.

  1. Team 1 shall review Team 8's source code
  2. Team 2 shall review Team 13's source code
  3. Team 3 shall review Team 5's source code
  4. Team 4 shall review Team 1's source code
  5. Team 5 shall review Team 14's source code
  6. Team 6 shall review Team 2's source code
  7. Team 7 shall review Team 9's source code
  8. Team 8 shall review Team 12's source code
  9. Team 9 shall review Team 6's source code
  10. Team 10 shall review Team 7's source code
  11. Team 12 shall review Team 3's source code
  12. Team 13 shall review Team 4's source code
  13. Team 14 shall review Team 10's source code

Instructions

Your team is free to deploy the MVP however you want, including using hosting services such as Digital Ocean, Linode, Amazon Web Services (AWS), Heroku, or a combination of many hosting or cloud services. You shall no longer user localhost for demonstrations; localhost shall only be used for development purposes.

Your team must also learn and utilize a unit testing framework(s) and provide tests for the MVP. The scope of the tests shall be limited to only to the models, controllers, and views. Make sure tests are provided in the source code repository (generally in a folder named test).

Your team must make as many optimizations to your existing web application as possible to your product using the techniques that we have discussed. At the very least, your team must use at least four (4) techniques to optimize your product:

Performance Tools

There is a plethora of tools that you can use to measure the performance of your product before and after optimizations made:

Code Review References

Presentation

In class on Thursday, March 16th, 4 teams will be chosen at random to present their implementation to the class. Selected teams will have 5 minutes to explain their plan, concerns, and findings to the class, and 5 minutes for questions and answers from the class.


Leg 5: The Technical Writing Seminar and Memory Caching

Overview

In this leg, your team will write a public Application Program Interface (API) for your product. Your team is also expected to use memory caching in some capacity.

Requirements

  1. A RESTful endpoint that allows for all possible modifications to your project. If a user can both create new content and edit old ones, you should have at least one endpoint to enable these.
  2. A RESTful endpoint that allows for user creation. This may mean that it's finally time to add users to your application.
  3. Documentation for everything. This is the most important part of this. I, or any other team, should be able to use your team's API without looking at how you implemented it. Be sure to specify any headers that are necessary to use.
  4. Specify a plan for which endpoints will need authentication and authorization, and what kinds. You should NOT implement..
  5. Feel free to use API builders such as Grape (Ruby) or Sandman (Python) but you will need to understand how they architect the API and why they do it the way they do. The purpose of this assignment is that you understand RESTful interfaces.

A big part of the assessment will be the thoroughness of the API and documentation. When you're done, you should be able to transition your project to rely entirely on this API and not have any full page reloads (though you should NOT do this transition yet). Consider security -- should I be able to POST to every endpoint? Should certain users only receive certain resources when they do a GET call?

Anything have to do with user permissions should be carefully considered but not to be implemented. You will do authorization and authentication in a later leg.

Submission

  1. Please make your API and documentation publicly availably on your web application. It can be a link at the footer of the home page or on each page.
  2. An engineering describing all of the choices you made in implementing the API. Did you end up using an API generator? Why? Why didn't you? What did you memory caching for? Did memory caching improve performance? There are no right answers, but there should be a thought process.

Presentation

In class on Thursday, April 6th, 4 teams will be chosen at random to present their implementation to the class. A selected team will have 5 minutes to demonstrate API and documentation to the class, and 5 minutes for questions and answers from the class.

References

Teams

Team 1 (Presented Leg 1)

Team 2 (Presented Leg 2)

Team 3 (Presenting Leg 3)

Team 4 (Presented Leg 2)

Team 5 (Presented Leg 1)

Team 6 (Presenting Leg 3)

Team 7 (Presented Leg 1)

Team 8 (Presented Leg 2)

Team 9 (Presented Leg 1)

Team 10 (Presented Leg 1)

Team 12 (Presented Leg 2)

Team 13 (Presenting Leg 3)

Team 14 (Presenting Leg 3)