Search this site
Lab attendence next week is mandatory! Please join the Collaborate Ultra session for your assigned lab.
Welcome!
Waiting List
Calendar
Slide Decks & Videos
Learning Outcomes
No Copying Policy
Grading
Project
Labs
AutoTest
Specification
Checkpoint 0
Checkpoint 1
Resources
Exam Practice
UBC CPSC310-20W1: Intro to SE
SPECIFICATION
Please see Project Grading for all grading details.
Deadlines appear on the Deadlines page.
OVERVIEW: PROJECT: INSIGHTUBC
UBC is a big place, and involves a large number of people doing a variety of tasks. The goal of this project is to provide a way to perform some of the tasks required to run the university and to enable effective querying of the metadata from around campus. This will involve working with courses, prerequisites, past course averages, room scheduling, and timetable creation.
This will be a full stack web development project split into four sprints. The first three sprints are server-side development using Node. The fourth sprint is client-side development. A fifth deliverable will also happen, but does not have dedicated time allocated to it because it is an aggregation of the first three sprints.
Development will be done with TypeScript and the packages and libraries you use will be strictly limited (for the first three sprints). If you do not know TypeScript, you are encouraged to start investigating the language soon. Its syntax is extremely similar to Java so it should be relatively easy to transition to given your prior experience. It is important to note we will spend very little time in lecture and lab teaching this language; you will be expected to learn it on your own time.
All checkpoints will be marked using an automated test suite. The feedback you will receive from this suite will be limited. To succeed at the project you will need to create your own private test suite to further validate each deliverable. Additional details will be available on the AutoTest page.
TEAMS
The vast majority of software is written by development teams. Even within large organisations, ‘feature teams’ usually comprise of a small set of developers within a larger team context. You will work in pairs for this project. Your partner must be in the same lab section as you; if you want to work with someone who is in another section, one of you will have to transfer lab sections.
Your partner selection is extremely important; be sure to make this choice carefully, as you will be responsible for working as a team for the remainder of the term. You must use the same partner for the duration of the project, no changes will be permitted. If do not have a team organised by the Checkpoint 0 deadline, please go to your lab and find a partner there. Everyone should have partners by the end of their first lab following the Checkpoint 0 deadline (the third week of the course).
PROJECT RESTRICTIONS
Language and environment
Your project will have to be written in TypeScript. While it might seem daunting to learn a new language on your own, the fluid nature of software systems requires that you get used to quickly learning new languages, frameworks, and tools. The syntax of TypeScript is extremely similar to Java itself, which you should have used in 210. Google will be your friend for this project, as there are thousands of free tutorials and videos that can help you with this technology stack. TypeScript has many great resources, but the TypeScript Handbook or the TypeScript Deep Dive would be good places to start. If you are starting from scratch, it is really important that you do not just read a bunch of code but actually write some. Consider using TypeScript or JavaScript REPLs as a lightweight way to do this.
All development will take place on GitHub. You will need a GitHub account (but feel free to create a throw away or anonymous account for this course, if that makes you more comfortable); we will create the repository for your group after the first week of labs have finished. You will not be able to change your GitHub id during the term, so when you register your account, be sure to use the right one. Instructions on how to register your account with us will be given in lab. Being familiar with Git is essential; please take a look at the ‘getting started’ part of the Atlassian Git Introduction before the first lab if you are not familiar with Git. A shorter, less formal, guide is also available.
ESLint
Your project will be subject to a linter to ensure that your code adheres to a standard of maintainability. From ESLint’s official documentation: “ESLint statically analyzes your code to quickly find problems.” i.e.: it’s for protecting you from yourself. If your code has common readability, maintainability, or functionality errors in it, the project will not build. This ensures that common errors easily caught before runtime by a linter don’t send you into hours of debugging later.
Allowable packages
The packages and external libraries (aka all of the code you did not write yourself) you can use for the project are limited and have all been included for you in your package.json. You cannot install any additional packages. It is notable that a database is NOT permitted to be used; the data in this course is sufficiently simple for in-memory manipulation using the features built into the programming language. Essentially if you are typing something like npm install
Promise Handling
The async/await syntax, while a great addition to JavaScript and TypeScript, is not to be used in the project. It serves to abstract away Promise asynchrony, which undermines the technical learning objectives of the course (as in how Promises are used and handled in asynchronous programming).
REPOSITORIES
All development will take place in GitHub repositories that we will create for you in a private organisation for the course. You will be automatically added to your repo after you have specified your groups in your lab section in the first week. Repositories will only be created for teams where both students are registered in the course; this list will finalize after the add/drop deadline.
FAQ
A series of FAQ items has been collected here; this is in no way exhaustive, but addresses several of the consistent questions we have received for this project.
FAQ: Failing Tests
If you are failing one of AutoTest’s tests, it means that your own test suite is insufficient. The tests AutoTest runs are exactly the same as the ones you can write yourself. If a test is failing, it means your suite is not strong enough and should be strengthened. NOTE: this does not mean randomly writing more tests, but contentiously strengthening your test suite by examining the deliverable specification.
Another testing anti-pattern is to only have integration tests (e.g., tests that directly evaluate addDataset, removeDataset, listDatasets and performQuery). A much more robust testing strategy that makes it easier to implement new features and isolate failures is to write unit tests against the individual methods in your implementation.
FAQ: Coverage Not Right
The most common issue for this case is that you did not commit a zip file that was referenced in your test files and so it was unable to be loaded.
FAQ: Using Branches:
Using version control branches is a great way to make it easier to work with your partner, but it is important that you merge your branches with master periodically (preferably with pull requests). Having > 3 branches is an anti-pattern, and stale branches should be deleted. In Checkpoints 1-3 you will have to use branches as prescribed by the deliverables.
Page updated
Google Sites
Report abuse