CS130: Software Engineering

Lecture 1
Check in!

Overview
Development Environments
Source Control

(link)
We're full!

If you are not enrolled:

The class is full. Total enrollment will not

increase beyond 80 100 120 150 200.

Enrollment in this class was done by the CS

department undergraduate counselor to make
sure that those students who need it most
urgently are enrolled.

2
Introduction
Who are we?

Michael Burns Philo Juang Alex Monroe Eric Hennigan

(guest)

4
Alex Monroe Fun facts

● Used to work at Google

● Cousin goes here

(keep an eye out for any Michelenas on campus)

● Grew up going to the Rose Bowl for

football games

● Favorite band: Muse

● Has never met Taylor Swift

● 4th time teaching this class

5
Eric Hennigan Fun facts

● Works at Google on Health AI

● UCLA alumni

● Loves bow ties

● Has never met Taylor Swift

● 4th time teaching this course

6
Michael Burns Fun facts

● Works at YouTube on Trend

Recommendations

● Recent graduate of UCLA

● Grew up in SoCal

● Loves UCLA basketball, football, Google

Sheets

● Once sold a kidney for drug money

● Has never met Taylor Swift

● 7th time teaching this class

7
Philo Juang Fun facts

● Works at YouTube on Subscriptions

● Responsible for most profanity in

YouTube codebase

● Plays soccer

● Flying back from Paris

● Has never met Taylor Swift

● 2nd time teaching this class

8
 Proprietary + Confidential

What is software engineering?

Software engineering is public class LinkedList<T> {
not (just) programming private T elem;
private LinkedList<T> next;

You need to know how to program and use public LinkedList(T el) {
basic data structures. elem = el;
}

public LinkedList<T> add (T el) {

next = new LinkedList<T>(el);
return next;
}

public LinkedList<T> next() {

return next;
}

public T get() { return elem; }

} 10
Software engineering is
not (just) programming
It's programming that's valuable to other
people

11
Software engineering is
not (just) programming
It's programming that's valuable to other
people

● The person who paid you to write it

● The person who paid you to use it

● Someone you gave it to

● Future-you, who doesn't have to

rewrite it.

12
A small program

● Uses compiler and a few libraries

● Developed alone

● Run a few times

● No obvious bugs

● I know how it works

● Useful to me

13
A small program vs. a big program
● Uses large framework or platform
● Developed by a team
● Uses compiler and a few libraries ● Run many times
● Well-tested
● Developed alone ● Documentation
● Useful to many people
Which means:
● Run a few times
● Debugging
● Unit, integration, regression tests
● No obvious bugs ● Bug tracking
● Build process
● I know how it works ● Release process
● Monitoring
● Useful to me ● Performance testing
● Adding new features
● Updating documentation
● Programmer turnover
● Updates to the framework
● ...
14
BigTable

Prototype ~20 years later...

● ~8 months ● Still going strong

● <10 people ● More people (team varies in size)

● Internal users ● Commercialized as Cloud Bigtable

● Same basic features

● Almost everything else different

15
Valuable software
projects have risk

Showing how valuable software projects

have risk
16
Valuable software
projects have risk

17
Software engineering is about managing risk

● Revision control
● Code reviews
● Coding style
● Refactoring
● Testable code
● Unit testing
● API design
● Design reviews
● Integration testing
● Build automation

18
Learning Software Engineering

● Hearing about tools, procedures, and techniques for writing valuable code.

● Putting it into practice

● Watching each other practice

● Hearing from people who have practiced

● Building something valuable!

19
Project / Assignments
Project: Web server

Diagrammatic approach to showing how a

web server works
21
What are the goals? What are NOT the goals?

● Learn how to develop scalable, ● Learn how to build a web server

maintainable, professional-quality
software ● Build something incredibly useful

● Learn how to design robust APIs ● Make a project for your resume

● Learn how to test, deploy, and

monitor software

● Learn modern technologies

● Learn how to work with other

software engineers on a team

22
Assignments Late Policy

● Assigned on Tuesday by noon ● Each team starts with 100 hours of

late time budget for the quarter
● Due following Tuesday by noon
● After exhausting, the budget an
● Submit by online form assignment receives a 1% penalty per
hour

● Each week, the team’s tardiness

depends on when their TL submits
the team form

23
Late Policy (Exception)

● Partway through the course, you will be asked to work in another team’s
codebase
● For this assignment, we will cap the number of late hours you will be able to use
so that other teams

24
Assignment logistics

Each week you should:

● Read the assignment

● Meet as a team, where you:
○ Discuss a plan of action
○ Split the assignment into tasks
○ Assign tasks to individuals
○ Keep notes in a doc
● Write code for your assigned task(s)
● Send code out for review
● Reply to review comments
● Submit code

25
This is a team endeavor!

● Teams of 4 TLs must:

● Same discussion section ● Lead the weekly meeting

● Don't flake! ● Keep notes of the weekly meeting

● Each week 1 person is the Tech Lead ● Review ALL code

(TL), on a rotating basis
● Ensure the quality of the code and
health of the project

● NOT write any code (!)

26
Software Engineering is a team endeavor

● Using and learning from publically available code is encouraged in this class, and
will be useful in your career.

○ Always follow license restrictions.

○ In this class, you must cite your source in a comment in the form of a URL.

● Make an honest effort to figure things out, but don't spend hours on some tough
problem—look at what someone else did. Most problems have already been
solved.

● Goes both ways: share what you've learned with teammates.

27
Suggestions...

● Learn from each other.

● Start early, get help where needed! Make use of the discussion section and office
hours.

28
Suggestions...

● Learn from each other.

● Start early, get help where needed! Make use of the discussion section and office
hours.

● Assignments build on each other!!!

29
Suggestions...

● Learn from each other.

● Start early, get help where needed! Make use of the discussion section and office
hours.

● Assignments build on each other!!!

30
Suggestions...

● Learn from each other.

● Start early, get help where needed! Make use of the discussion section and office
hours.

● Assignments build on each other!!!

● Assignment 7 is a doozy – make sure your code is in good shape before then!

31
Suggestions...

● Learn from each other.

● Start early, get help where needed! Make use of the discussion section and office
hours.

● Assignments build on each other!!!

● Assignment 7 is a doozy – make sure your code is in good shape before then!

● Pay attention to participation requirements

32
Don't let this be you!

33
Technology we assume you know

● C++

● Basic data structures and algorithms

● Linux

● Basic Git, or walk yourself through learngitbranching.js.org

● Basic networking and concurrency

(Or a healthy relationship with stackoverflow.com, ChatGPT, etc.)

34
An aside on GenAI

● GenAI can be very helpful to programmers

● Consider it a tool

● Use all the tools at your disposal

● You are still responsible for how you use tools

35
Technology we will help you learn along the way

● Shared code repositories (more advanced Git)

● Containerization (Docker)

● Make / build systems (CMake)

● Remote deployment (Google Cloud Platform)

36
Piazza – For students

● We have a Piazza class for us to use

● Should be mostly used for knowledge sharing among teams
○ Instructors will not be crawling through Piazza helping to debug your code
● How to ask a good question:
○ Specifications in this course may be left intentionally ambiguous
○ Do not ask what you should do; lay out your options and explain which option you
think is best and why

37
Piazza – For students

● Bad questions lead to bad answers

Student: How should we handle double slashes in URL paths?

Us: How do you think we should handle double slashes?

38
Piazza – For students

● Bad questions lead to bad answers

Student: How should we handle double slashes in URL paths? Should we fail or
should we accept them in a path?

Us: Which do you think makes more sense?

39
Timeline

~2 weeks ~3 weeks

● Assembling teams ● Refactoring

● Development environment ● Documentation

● Deployment ● Working with someone else’s code

~3-4 weeks ~1-2 weeks

● Initial implementation of the project ● Feature of your choice

● API selection ● Demos!

● Midterm
40
Evaluation (Grading)

Assignments - 70%

● Implementation, tests, code reviews, documentation

● Presentations, written assignments

Midterm - 15%

Final - 15%

41
Standardization:
Development Environment
Student Development
Environments
● Identity
○ Who knows?
● Platform
○ Linux/MacOS/Windows?
● IDE
○ Visual Studio/XCode/CLion/VS Code?
● Compiler
○ Clang/GCC/ICC/Visual C++?
● File / directory structure
○ Monolithic or separated?
● Code style
○ Opening brace? Indentation?
● Source control system
○ CVS/SVN/Perforce/Git/None?

43
Corporate Development
Environments
Standardized:

● Identity

● Platform

● IDE

● Compiler

● File / directory structure

● Code style

● Source control system

44
CS 130 Development
Environment
● Identity Identity:
○ @g.ucla.edu
● Platform Account is [email protected]
○ Linux
● IDE User is joebruin
○ Recommending VS Code
● Compiler
○ GCC
● File / directory structure
○ Not monolithic
● Code style
○ Make some decisions
● Source control system
○ Git

45
Demo

● Host is MacBook
○ clang compiler
○ missing gcloud
○ has docker
● Start devel env
○ SSH key
○ gcc compiler
○ has gcloud
○ has docker
○ git using cs130.org
user

46
Docker what?

● Container: lightweight VM-like

environment

● Defined by a series of commands in

Dockerfile

● Runs on all major host platforms

● Useful for standardization

● Useful for deployment

47
Code file/directory my_project/
- build/
structure
- bin/
- [more build files]
Guidelines:
- include/
● Use .cc file extension - server.h
● One file per C++ class - session.h
implementation - src/
● Separate _main.cc file for main() - server.cc
- server_main.cc
● Separate directories for headers and
tests - session.cc
- tests/
- server_test.cc
- session_test.cc

48
Source Control

Proprietary + Confidential
One rule

All valuable source code

resides in source control!

50
Why?

● Reproducible state

● Backing up work

● Documenting progress

● Post-mortems

● Make collaboration possible

● Legal pedigree

51
Source control tradeoffs

● Adds complexity
○ can't just edit files willy-nilly
○ have to check them in, check them out
○ have to figure out how to size changelists
○ more thinking
● ... but reduces risk
○ of losing progress
○ of not being able to solve user problems
○ of legal liability
● ... and is more scalable
○ more people can contribute sensibly
○ allows specialization

52
Source control tools

● Git

● Subversion

● Mercurial

● CVS

● Perforce

● SourceSafe

● BitKeeper

53
Repository diagram

54
Changelists and filesets

● Files in source control organized by the logic of the project and build system.
● Different source control systems treat files differently
○ Git treats the entire repository at once, and references the whole fileset by a hash
● Changelists are determined by development logic
○ Chosen to advance the goals of the project
○ Use changelists to make sense internally as a project state transition.
○ Ideally they are:
■ self-contained
■ small
■ single-function
○ Can be part of a larger group of changelists
○ Larger sequences can be arranged as branches

55
Git source control: Basic idea

What we want:

v1 v2 v3 v4 v5

README.txt README.txt README.txt README.txt README.txt

— — — — —
Today is Monday Today is Tuesday Today is Today is Thursday Today is Friday
— — Wednesday — —
—

56
Git source control: Basic idea

What we want:

v1 v2 v3 v4 v5

README.txt README.txt README.txt README.txt README.txt

— — — — —
Today is Monday Today is Tuesday Today is Today is Thursday Today is Friday
— — Wednesday — —
—

Anybody see any problems with this?

57
Git source control: Basic idea

What we want:

v1 v2 v3 v4 v5

README.txt README.txt README.txt README.txt README.txt

— — — — —
Today is Monday Today is Tuesday Today is Today is Thursday Today is Friday
— — Wednesday — —
—

With this paradigm, need an entire copy of the whole repository for every version

What if your repository contains 1GB? What if you have 100 developers submitting
code so there are 100 new versions a day?

58
Git source control: Diffs

Solution: Instead of storing a copy of the repo at each version, store only a “diff” that
tells you how to modify each version to get to the next incremental version

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

What does git store?

v1 + Diff 1, Diff 2, Diff 3, Diff 4

59
Git source control: Diffs

Example:

README.txt Diff 1 README.txt Diff 2 README.txt Diff 3 README.txt Diff 4 README.txt

v1 v2 v3 v4 v5

1: Today is 2: Mon -> 1: Today is 2: Tues-> 1: Today is 2: Wednes -> 1: Today is 2: Thurs-> 1: Today is
2: Monday Tues 2: Tuesday Wednes 2: Wednesday Thurs 2: Thursday Friday 2: Friday
3: +TGIF 3: TGIF!

(Git stores the green boxes only)

60
Git source control: Glossary
● Commit: A snapshot of the repository at a given point in time (think “node”)
○ e.g. v3
● Changelist: A diff that represents how the repository is changed between
commits (think “edge”)
○ e.g. Diff 2

Diff 1 Diff 2 Diff 3

v1 v2 v3 v4

61
Git source control: Making new commits

● In order to commit, edit your files locally, add them to potential commit, and then
call `git commit`.
● Git will automatically collapse your changes into a diff and store those changes
● Git will also give your commit a name (hash of fileset)
$ git add .
$ git commit -m “Adding more docs”

Diff 1 Diff 2 Diff 3

v1 v2 v3 v4

62
Git source control: Glossary

● In order to commit, edit your files locally, add them to potential commit, and then
call `git commit`.
● Git will automatically collapse your changes into a diff and store those changes
● Git will also give your commit a name (hash of fileset)
$ git add .
$ git commit -m “Adding more docs”

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

63
Git source control: Glossary

How do I look at versions of the repository?

● Branch: A pointer to a specific commit

main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

64
Git source control: Making a new branch

● “Making a new branch” means “create a new pointer that points at the same place
I’m currently pointed at”

$ git checkout -b new-feature

main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

65
Git source control: Making a new branch

● “Making a new branch” means “create a new pointer that points at the same place
I’m currently pointed at”

$ git checkout -b new-feature

main new-feature

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

66
Git source control: Making a new branch

● More terminology: “HEAD” – the commit where I am currently working

HEAD

main new-feature

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

67
Git source control: Making a new branch

● More terminology: “HEAD” – the commit where I am currently working

● Most of the time, HEAD points to a particular branch, so I’ll omit it from the
diagrams and instead annotate where HEAD is pointing with asterisks

main *new-feature*

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

68
Git source control: Moving around

● How do I move my pointer around?

$ git checkout v3

*main*

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

69
Git source control: Moving around

● How do I move my pointer around?

$ git checkout v3

HEAD main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

70
Git source control: Moving around

● How do I move my pointer around?

$ git checkout v3

In reality, more complicated. (commit names, relative refs, go do the tutorial!)

HEAD main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

71
Git source control: List turns into Tree

$ git checkout -b new_feature

HEAD main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

72
Git source control: List turns into Tree

$ git checkout -b new_feature

*new_feature* main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

73
Git source control: List turns into Tree

$ git commit -m “Adding a new feature”

*new_feature* main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

74
Git source control: List turns into Tree

$ git commit -m “Adding a new feature”

Uh oh. We committed on top of v3 with a diff that wasn’t the same as the one that
already created v4 *new_feature*

v6
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

75
Git source control: List turns into Tree

This is not the ideal state of the repository.

How do I know what the most up-to-date version is to start building on?
*new_feature*

v6
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

Side note: “branch” still means pointer to a commit! Can be confusing to

conflate the branch of the tree a particular git branch is pointing to

76
Git source control: Tree turns into graph

Terminology: “Merge” create a commit with 2 parents

$ git merge main
*new_feature*

v6
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

77
Git source control: Tree turns into graph

Terminology: “Merge” create a commit with 2 parents

$ git merge main
*new_feature*

v6 v7
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

78
Git source control: Tree turns into graph

What’s in v7?
[v5 plus Diff 5] OR
[v6 plus Diff 3 plus Diff 4] *new_feature*

(both are equivalent)

v6 v7
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

79
Git source control: Pruning the tree

This feels a bit awkward. Can we keep things as having one parent each?

*new_feature*

v6 v7
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

80
Git source control: Pruning the tree

Yes! This is where rebase comes in

$ git rebase main
*new_feature*

v6
Diff 5 main

Diff 1 Diff 2 Diff 3 Diff 4

v1 v2 v3 v4 v5

81
Git source control: Pruning the tree

Yes! This is where rebase comes in

$ git rebase main

v6
Diff 5 main *new_feature*

Diff 1 Diff 2 Diff 3 Diff 4 Diff 5

v1 v2 v3 v4 v5 v6’

82
Git source control: Pruning the tree

Copies the diff on top of the commit you are rebasing onto
Leaves an orphan commit (v6)

v6
Diff 5 main *new_feature*

Diff 1 Diff 2 Diff 3 Diff 4 Diff 5

v1 v2 v3 v4 v5 v6’

83
Recommended tutorial

● https://learngitbranching.js.org/
● We’ll show usage and concepts in this lecture, but this tutorial is highly
recommended if you have not used git on a large project before
● Git can feel very complicated when first starting out
a. It’s easy to get lost in the terminology, and
b. git does not surface any graph diagrams like the one shown in the prior slides, so it
can be tough to figure out exactly what is happening in your live repository

84
Git source control:
Basic usage (local)
git init
● Creates a blank repository locally, with
data in a hidden .git directory.

echo "Hello world!" > hello.txt

● The files currently in the directory with
the .git subdirectory can be edited at
any time. The state of these files is the
"working directory" state.

git status
● Output will show hello.txt is
"untracked".
85
Git source control:
Basic usage (local)
git add hello.txt
● Add a file to the "stage" (or "index")
repository state.

git status
● Output will show hello.txt is
staged for commit.

git commit
● Create a named historical state of the
repository with staged changes.
Note: every commit requires a message that describes its
contents (see the -m flag)
86
Git with Gerrit (remote)

git clone ssh://code.cs130...

● Downloads a git repository from
Gerrit.

echo "Hello world!" > hello.txt

● The files currently in the directory
with the .git subdirectory can be
edited at any time. The state of these
files is the "working directory" state.

git add hello.txt; git commit

● Add the file. Commit the file.

87
Git with Gerrit (remote)

git push
● This step fails. Code must be
reviewed!

git review
● Submit code for review.

git pull --rebase

● Pull new changes from the remote
repository.

88
Submitting in Gerrit 89
Git with Gerrit (remote)

git push
● This step fails. Code must be
reviewed!

git review
● Submit code for review.

git pull --rebase

● Pull new changes from the remote
repository.

90
Git source control: Advice

● Keep branch structure simple

● Develop in branches (don't touch main)

● Locally, use branches to do incremental development

● Get familiar with merge and rebase. Use them to manage how your commits to
the main branch look.

○ Hint, prefer rebase

● For class: Always send code for review, and submit in Gerrit web UI

91
Coming up

Assignment 1

● Assigned tomorrow, due next

Tuesday

Lecture 2

● Testing

92