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.
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?
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.
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.
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.
For Thursday, February 2nd, your team shall prepare and create:
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.
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.
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).
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.
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.
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.
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.
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.
Some reads to learn more about the idea of an MVP of a product:
masterbranch on Git repository. Create and work off of a different branch (e.g.,
localhost. Static content such as photos and videos shall be stored in a folder on
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.
README.mdand Entry In Your Engineering Notebook
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:
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.
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."
For this leg and for the next two weeks, your team shall make at least three entries in your engineering blog:
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.
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
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:
There is a plethora of tools that you can use to measure the performance of your product before and after optimizations made:
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.
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.
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.
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.
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)