Overview

CSE2WDC – CSE5WDC
Web Development on the Cloud
31/07/2019

Reading: subject guide – available from LMS

‹#›
 Introduction
1. Lectures and Labs
2. Resources
3. Assessment
4. Topics Covered
5. Outline

‹#›
 Lectures and Lecturer
Lectures (Semester 2, 2019 – 12 weeks):
• Wednesday 8:00am – 10:00pm in PW-215 of Peribolos West building

Lecturer
• Lianhua Chi
• Office: TC 314
• Email: [email protected]
• Consultation Time: Wednesday 12:00pm – 2:00pm

‹#›
 Lab Class
● It is very important to come to labs.
● 11 normal labs starting from week 2.
● 1 take home lab on the topic of HTML/CSS
● For each lab:
● One mark for attempting but not completing lab
● Two marks for attempting and completing lab

● Lab time: Tue 2pm – 4pm BG 139

Wed 10am – 12pm BG 139
Wed 2pm – 4pm BG 116

● Sign up for labs using Allocate+

● https://allocate.latrobe.edu.au/allocate/student

● Tutor: Alex Tomy and Wenjin Yu

‹#›
 Introduction
1. Lectures and Labs
2. Resources
3. Assessment
4. Topics Covered
5. Outline

‹#›
 Resources
Subject Website:
• URL: https://lms.latrobe.edu.au/course/view.php?id=69077
You use your student online username and password to log in to
the Learning Management System (LMS)

Lecture Slides:
• Available on the above URL

Textbook:
• Phil Ballard. 2018. Sams Teach Yourself JavaScript in 24 Hours -
Seventh Edition, SAMS.
• Cory Gachenheimer. 2015. Introduction to React, APress
‹#›
 Introduction
1. Lectures and Labs
2. Resources
3. Assessment
4. Topics Covered
5. Outline

‹#›
 CSE2WDC Assessment
● One 3-hour end of semester examination 70 %

● One programming assignment 20 %

● Normal Labs 8%

● 1 Take home lab 2%

● Assignment Due Date: 21/10/19

‹#›
 CSE5WDC Assessment
● One 3-hour end of semester examination 60 %

● One programming assignment 30 %

● Normal Labs 8%

● 1 Take home lab 2%

● Assignment Due Date: 21/10/18

‹#›
 How to pass this subject

• Attend lectures
• Complete lab classes
• Submit assignment (Do not COPY)
• Attend exam

‹#›
 How to pass this subject

PRACTISE

PRACTISE

PRACTISE

‹#›
 Introduction
1. Lectures and Labs
2. Resources
3. Assessment
4. Topics Covered
5. Outline

‹#›
 Course Outline
● Lecture 1
● Introduction to cloud, version control (Git) and virtual

machines
● Lecture 2
● Docker and Front end (HTML / CSS)

● Lecture 3
● Front end (continued) and Javascript programming

● Lecture 4
● Front end: The React Javascript library for building

user interfaces

‹#›
 Course Outline
● Lecture 5
● Front end: The Redux predictable state container for

JavaScript apps
● Lecture 6
● Back end: Node.js and the sequelize object relational

mapping
● Lecture 7
● Back end: Testing, server side rendering and

connecting back end and front end

● Lecture 8
● Continuous integration and Introduction to Amazon

Web Services
‹#›
 Course Outline
● Lecture 9
● Cloud Computing and AWS Cloud Services

● Lecture 10
● (Continued) AWS Cloud Services: RDS, ELB, Auto

scaler, elastic ip, etc.

● Lecture 11
● No SQL

● Lecture 12
● Exam Revision

‹#›
 SUBJECT INTENDED LEARNING
OUTCOMES (SILOs)
Upon successful completion of this subject, you
should be able to:
● Identify the best cloud based web services to use to build a given
scalable web site.
● The ability to design and build a stateless web server based on
cloud technologies.
● Ability to use modern software engineering tools to build and
deploy robust code for scalable web sites.
● Identify the best storage technologies to use when building a
particular given web site. ‹#›
 Introduction
1. Lectures and Labs
2. Resources
3. Assessment
4. Topics Covered
5. Outline

‹#›
 Lecture and Lab Class Outline

• Please refer to the CSE2WDC/CSE4WDC subject

learning guide.

• Note:
Lab Classes will be held in BG level 1 labs. You only
need to attend 2 hours lab each week.

‹#›
 END
Overview
Any questions?

‹#›
 CSE2WDC/CSE5WDC
Web Development on the Cloud

Lecturer: Lianhua (Lina) Chi

Lecture 1
Semester 2 - 2019

‹#›
Introduction to Cloud Computing

‹#›
 What is Cloud Computing?
● Cloud computing includes the following
● Software as a service (SaaS)

● Applications delivered as services over the Internet and the

hardware
● Utility computing

● in which a service provider makes computing resources and

infrastructure management available to the customer as
needed, and charges them for specific usage rather than a
flat rate.

A view of Cloud Computing, Michael Armbrust, Armando Fox, Rean ‹#›

Griffith, at el. Communications of the ACM, 2010.
 What is Cloud Computing?
● Old idea: Software as a Service (SaaS)
● Def: delivering applications over the Internet

● Utility Computing: pay-as-you-go computing

● Illusion of infinite resources

● No up-front cost

● Fine-grained billing (e.g. hourly)

‹#›
 Good paper
● A very good paper you should read
● A view of Cloud Computing, Michael Armbrust,

Armando Fox, Rean Griffith, at el.

Communications of the ACM, 2010.

‹#›
 More Contents about
Cloud Computing will be
introduced
in Lecture 9

‹#›
 Version Control
Introduction to Git

‹#›
 Version Control: Why Use
it?
● Working on a shared project

‹#›
 Why Use a Version Control System (VCS)?
● Collaboration
● Imagine a team of people are working on the same set

of files.
● If two people change the same file at the same time,

then there will be inconsistencies.

● People will be overwriting each others changes.

● Using a VCS everybody on the team can work

absolutely freely on any file at any time.

● The VCS will later allow you to merge all the

changes into a common version

● There is no question where the latest version of a

file or the whole project is. It is in a common, central

place; your VCS. ‹#›
 Why Use a Version Control System (VCS)?
● Going back to an old version
● Imagine you have a good initial working project. Then you want

to make some further changes. You can commit your initial

working project into the VCS and continue working on your
changes.
● If you mess things up, you can easily go back to the

originally committed version.

● Using a VCS you can just store the updated files when

committing a project into the VCS. The system will automatically

find the updated files.
● Using a VCS you can easily find out what is different between

the different versions.

● A VCS acknowledges that there is only one project. Therefore,
there’s only the one version on your disk and that you’re currently
working on. Everything else (all previous versions) are neatly
packed up inside the VCS. ‹#›
Why Use a Version Control System (VCS)?
● Understanding What Happened
● Every time you save a new version of your project,

your VCS requires you to provide a short description of

what was changed. In addition you can see exactly
what changes have been made to the file contents.
This helps you understand how your project evolved
between versions.
● Backup
● In the case of distributed VCS such as Git, every team

member has a full-blown version of the project on his

disk including the project’s complete history.
● So even if your central server breaks down you can

still get a copy from your teammates local Git

repository. ‹#›
Local Version Control

‹#›
 Local Version Control
● Even for a single developer having a version control
system is good since it allows a person to keep track all
the different versions of his/her files.
● The repository or version database stores all the different
versions of all the files.
● In order to use or modify a file from the repository a user
checks it out of the repository. He or she can then modify
the file and then check it into the repository again.
● The newly checked in file becomes a new version of

the file.

‹#›
 Version Control System
Architectures
● Centralized Version Control
● e.g CVS, Subversion (SVN), Perforce

● Distributed Version Control

● Git, Mercurial

‹#›
Centralized Version Control

‹#›
 Centralized Version Control

● For a centralized version control system there is one

single repository that all developers share.
● When a developer wants to work on a file he/she checks
it out from the central repository.
● What happens when two developers work on the same
file? Two ways to handle this:
● Locking - The first person to check out the file has a

lock on the file. That way prevents a later person from

modifying the file at the same time
● Merging – The second person who checks in the file

needs to merge his/her changes with the changes

checked in by the previous person.
‹#›
Centralized Version Control

‹#›
 Centralized Version Control

● The changes to the files are added as deltas into the

repository.
● Storing just the changes (deltas) is more space

efficient compared to storing entire new files.

● Each set of changes checked into the repository forms a
new version of the repository.

‹#›
 What is wrong with Centralized Version
Control?
● The entire project is stored only at the central server.
● If the central server dies you lose everything

● You can not work when there is no connection to the

central server
● You cannot create different versions of your files

without contacting the server.

‹#›
 Distributed Version Control
● Distributed Teams
● As software development has become more team-

based, and teams have become more distributed, the

need for distributed version control systems has
emerged.
● No centralized repository
● In distributed version control, there is no centralized

repository, team members don’t check out individual

files from these systems, they check out the entire
repository.

‹#›
 Distributed Version Control
● The repository is not locked
● other team members can also download the current

version of a project.
● Different snapshots over time
● Later, when a team member check the project back in,

it is marked as a different version in the repository.

Thus, you can think of distributed version control
systems as storing different snapshots of a project over
time.
● Owner determines what and how to merge
● It is up to the owner of the repository to merge different

version together if he/she so chooses.

‹#›
Distributed Version Control

‹#›
 Distributed Version Control

● Although each developer has his/her own copy of the

repository. There is the idea of one person who is the
owner of the repository.
● The owner is responsible for merging all the changes
from all the different developers.
● A developer can push his/her changes to another
developers repository.
● A developer can also pull in changes from another
developers repository.

‹#›
 Distributed Version Control

● Each version of the repository is an entire snapshot of all

the files of a repository.

‹#›
 Centralized versus Distributed Version
Control
● The key benefit of distributed version control over central version control is that a
developer can work on the repository (check in and check out files) without
internet access.
● Using central version control if you have no internet access and want to
make a new version of a file you will need to manually make a new copy of
the file.
● Central version control does allow local version control if the server is
another machine.
● One important benefit for a distributed version control system is that every
developer has a copy of the entire repository. So if the data from one machine is
lost we can always get it back from repositories stored by one of the developers.
● In contrast for centralized version control if the central repository is lost then
all is lost. No developer would have a complete copy of the repository with all
its versions.
● The downside is that distributed version control is more complex to learn than
central version control.

● Many of the points for this side is taken from

‹#›
http://stackoverflow.com/questions/871/why-is-git-better-than-subversion
Git

‹#›
 Git
● In this subject we will learn and use the popular
distributed version control system called Git.

● Git is a popular open source distributed version control

system created in 2005 by the Linux development
community.

● Git provides means for comparing the differences

between the various versions of a project (think of them
as project snapshots), and for merging them accordingly.

‹#›
 Local Git
● Lets start by first focusing on using Git in a local machine.
● Therefore for the next set of slides we will learn to use Git
on a single machine.

‹#›
A local Git project has three areas Working directory
●

● This is the current directory

with the files you are working
on.
● Staging area
● Here is where you create an
index of the files that you
want to commit later.
● You can add a file to the
staging area as follows:
● git add animation.java

● You can select the files you

want to add one at a time
and put them into the staging
area.
● Git directory (repository)
● Once you are ready you can
commit all files in the staging
area into the repository
● git commit -m “changed
animation code”
‹#›
Committing all files in a directory at once

● There are two ways of committing the entire directory

● Using staging area

● git add .

● git commit -m “made big change”

● Directly commit into repository bypassing the staging area

● git commit -a -m “made big change”

‹#›
 Basic Workflow
● Modify files in your working directory.
● Stage files, adding snapshots of them to your staging area.
● Do a commit, which takes the files as they are in the staging
area and stores that snapshot permanently to your Git directory.

● If a particular version of a file is in the git directory, it’s considered

committed.
● If it’s modified but has been added to the staging area, it is
staged.
● If it was changed since it was checked out but has not been
staged, it is modified.

‹#›
 Setting up Git
● Set the name and email for Git to use when you commit:
$ git config --global user.name “Bugs Bunny”
$ git config --global user.email [email protected]

● You can call git config –list to verify these are set.
● These will be set globally for all Git projects you work with.
● You can also set variables on a project-only basis by not using the
--global flag.

‹#›
 Creating and Using a Repository
● To create a Git repo in your current directory:
● git init

● This will create a .git directory in your current directory.

● Then you can commit files in that directory into the repo by first
adding to the staging area and then committing into the repo:
● git add file1.java

● git commit –m “initial project version”

● You can use the following to unstage a file

● git reset HEAD file1.java

● You can get back the original version of a file that you have
modified using the following
● git checkout file1.java

‹#›
 Creating New Branches
● Git allows you to diverge from the main line of
development.
● Allows you to work without messing up the main line of
code.
● Better than creating a new copy of your source code
directory for each new branch.
● Main development branch = master.
● New versions may be created along the master branch,
or new branches can be created off of it.
● The changes to the new branches will be tracked
independently.
● The branches can possibly be merged back into the
master branch.
‹#›
 Git Branching
● In this example there is a
master branch which only
contains production versions of
the code
● Production code is code

that is actually used to

serve customers. It is
usually heavily tested code.
● The other branch is the
develop branch that is used by
the developer to work on
development version of the
code
● When the code is of production
quality it is merged into the
master branch.
● The owner controls what goes‹#›
into the master branch.
Checkout and merging a
branch

‹#›
 Branching
● To create a branch called develop
● git branch develop

● To list all branches (* shows which one you are currently

on)
● git branch

● To switch to the develop branch

● git checkout develop

● To switch back to the master branch and then merge the

changes from the develop branch do the following
● git checkout master

● git merge develop

‹#›
 Forking
● You may really like an open source Git project and want
to make a lot of changes to it.
● Also your changes may not be wanted by other people.
Therefore the owner of the original Git repository may not
want to merge your changes to the open source project.
● In this case you can fork the project.
● This will clone the entire project into a new project.

● You can then have full control of the forked project.

● From here on if you want to push changes back to

the original repository that will be hard.

‹#›
 Remote Git Repository

● In order to have multiple developers working on the same

repository we need to create a remote git repository.
● Developers push their change to the remote repository
● We can clone or pull the data from a remote repository into our ‹#›
working directory.
 Create and Push to Remote Repository
● Lets assume you have already created a local git repository.
● Now here is how you can add the remote repository
● git remote add origin <Remote URL>

● Here origin is the name you give to the remote repository.

After this command every where you use origin it will refer to
the remote repository located at the URL specified by
<Remote URL>.
● <Remote URL> is the URL where the remote repository is

located.
● Once you add the remote repository you can now push your local
repository into the remote repository using the following
● git push –u origin master

● This pushes the master branch to the remote repository

named origin.

‹#›
 Getting files from Remote Repository (fetch,
pull and clone)
● The fetch command can be used to grab all the data from a remote
repository
● git fetch <remote-name>

● To use the above command you need to first add the remote repository
into your local repository.
● If you want git to create a local repository and also grab all the data
from the remote repository in one command you can use clone instead
● git clone <remote URL>

● This will clone the repository stored at <remote URL>

● If you already have a copy of the remote repository but just want to
update it with the latest version you can use pull
● git pull <remote-name>

● This will update the current local git with the remote repository

specified by <remote-name>
‹#›
 Git commands
command description
git clone url [dir] copy a git repository so you can add to it
git add files adds file contents to the staging area
git commit records a snapshot of the staging area
git status view the status of your files in the working
directory and staging area
git diff shows diff of what is staged and what is
modified but unstaged
git help [command] get help info about a particular command
git pull fetch from a remote repo and try to merge
into the current branch
git push push your new branches and data to a
remote repository
others: init, reset, branch, checkout, merge, log, tag
‹#›
 Public versus Private Repositories
● If you have code that you want to make publicly available
for everyone to use. Use GitHub
● GitHub is the most popular public repository

● GitHub also allows users to host private repositories.

Private repositories can only be accessed by people you
allow access to
● However, private repositories on GitHub costs money.

● Another popular Git repository is BitBucket

● BitBucket offers a limited number of free private

repositories.
● In this subject we will be using BitBucket for our

remote repositories.

‹#›
Virtual Machines

‹#›
What are Virtual Machines?

‹#›
 What are virtual
machines?
● At the base is the host, underlying hardware
● Virtual machine manager (VMM)
● Also known as the hypervisor

● Creates and runs virtual machines

● Provides an interface that is identical to the host

(except in the case of paravirtualization)

● Usually guest is an operating system

● Configure resources available to each guest

operating system E.g. two virtual CPUs, 4GB of

RAM, 10GB of disk, etc.
‹#›
 Why Virtual Machines are Useful on the
Cloud?
● Protection due to isolation
● Host systems is protected against virus, security breaches and

bugs in guest operating system applications

● One guest operating system is protected from another guest

operating system
● E.g. Two guest operating systems can run on the same

hardware yet not be able to read information from the each

other. Thereby achieving security.

● Flexibility
● Suspend and resume virtual machine

● Snapshot of virtual machine state

● Can be used to allow restoring to previous state

● Allow virtual machine to be cloned.

‹#›
 Why Virtual Machines are Useful on the
Cloud?
● Consolidation of resources
● Many lightly used systems can be combined to create one more

heavily used system

● Cheaper to manage
● E.g. 100 physical servers running 20 virtual servers equals 2000 virtual

servers.
● Many people needed to administer 2000 real servers but one or two

can manage 2000 virtual servers

● A useful tool is templating

● One standard virtual machine image is used for multiple virtual

machines

‹#›
 Why Virtual Machines are Useful on
the Cloud?
● Live migration
● Moves a running guest from one physical machine to

another.
● Useful when system is overloaded for load balancing

● Useful when hardware is to be upgraded or repaired

● Install all software and configuration settings on a virtual

machine image.
● Makes redeployment of operating system and environment

much faster.

‹#›
 More Detail on Virtual Machines

● If you want to learn more about virtual machines

take the operating systems and computer
architecture class
● CSE3OSA

‹#›
 Conclusion
● Cloud computing is taking over the world.
● It is considered essential knowledge for any IT

or computer science professional

● Version control is really useful for being able to
keep track of different versions of your code.
● Git has many features that allow you work more
effectively with other people on programming
projects.
● Virtual machines are really useful for cloud
computing.
‹#›