System Build辅导、讲解web/css编程、讲解web/HTML语言、辅导PHP留学生 辅导Database|讲解留学生Process
- 首页 >> OS编程 Foundation System Build
Also known as “Iteration 0”
Introduction
Before you leap into the business of coding your project, it is important that you do some
pre-work to ensure that your infrastructure is sound. You need be familiar with the process of
making changes to a website, deploying those changes to a web server, and be confident with
documenting procedures. These skills will all serve you well for the rest of the year (and
indeed your career).
The idea is to make sure that every student has experience with writing a small amount of
documentation, and deploying a minimal website to a live server. In the process, it also
provides confidence that the infrastructure works, and to check this in the absence of any
custom code that could break things. The objective is to ensure you have a working
installation of PHP, and you have confidence and experience deploying new versions of your
application without experiencing implementation issues. Iteration 0 can provide the baseline
for future implementations and is the basis for the deployment plans for each iteration.
There output from completing iteration 0 is:
1. A bare-bones CakePHP application, which you’ve made minor customizations to,
committed the changes to a git repository, and then deployed to a live web server.
2. A document explaining the procedure in a clear and concise manner. This is
important because this process of making minor changes, sharing those changes,
and then publishing them is going to be repeated countless times in any IT project.
Iteration 0 is an iterative activity that you should repeat until the deployment process is
flawless. Monash mentors should be able to ask you to repeat the procedure in front of them
in studio, and you should have the skill and confidence to follow the procedure.
You can see the original web application deployed on the IE server, and the code is available
on the Monash GitLab server.
This practice is not trivial, therefore it’s highly recommended that you read this
document, along with all linked materials, in its entirety before start working on the
build. Making notes along the way is also helpful for both backtracking your actions and for
future references when you deploy your project on servers later on, and when you document
the procedure.
Version 1.0 (2019-02-26)Goals
The original website can be viewed online and looks like this:
When you click on the “Details” link for any of the properties, you will see (a very detailed but
also helpful) error:
Version 1.0 (2019-02-26)For this build, you will need to implement the details page, so that each property can have its
own details page showing relevant information about the property. The database schema for
the properties can be found here.
The above property listing screenshot is taken from the url “/properties”. However, if you
visit the homepage of the application, it will provide a small amount of insight into the
CakePHP framework being used and the MVC architecture in general:
Documenting the procedure
In addition to changing the website and deploying it, you are required to document the
procedure required for somebody else to follow your steps. This procedure should include:
● Where to obtain your code (i.e. your fork of the repository).
● How to get the code onto your laptop.
● How to commit changes and push them to your repository.
● How to deploy the updated code to the IE server.
Do not include any passwords in this particular documentation.
A good rule is that any IT professional should be able to read your procedure, and understand
it clearly enough to be able to make changes and deploy them without having to ask you any
questions.
Version 1.0 (2019-02-26)The documentation should not be particularly long. Realistically it should only need to be
about 1-2 pages (may be longer if you make use of images). It should be easy to read, well
formatted, and consistent. This will eventually form the basis for all future deployments for the
rest of the year, so you may as well try and get it right at the beginning.
This documentation is to be uploaded via Moodle.
Outcomes
At the end of iteration 0, you will be graded on the following:
N P <...> HD
Documentation
(content)
You’ve only
provided a
checklist / dot
points
describing the
procedure, or
you haven’t
described the
procedure at all.
It would be difficult
to be able to follow
the instructions
without asking
questions of you
first. Perhaps the
procedure misses
some important
steps, or it is far
longer than it
needs to be. The
formatting is poor,
English hard to
understand.
<...> Any IT professional
would be able to pick up
your procedure and
perform the steps
required only by reading
your document. The
procedure is written in a
clear and concise
manner. It isn’t too long,
but includes all of the
important aspects. If
required, you’ve included
visual aids to help
document the relevant
procedure. The
document is formatted
professionally and
consistently, and correct
English is used
throughout.
Documentation
(formatting)
No use of
structure
(headings,
paragraphs,
etc), no visual
aids, no
headers or
footers, etc.
Formatting is
inconsistent,
different fonts,
sizes, colours
used throughout.
Some visual aids
were used but they
are pixelated or of
low quality.
<...> Report looks
professional. Formatting
is consistent. Good use
of headings to break
content up, visual aids
are of high quality,
captions are used for any
images. Proper use of
headers and footers.
Version 1.0 (2019-02-26)Version control
(git)
The code is not
available in
source control
at all. Or, you
haven’t
imported the
project into your
own repository
(e.g. you copied
and pasted
individual files
from the original
repository,
losing the git
history in the
process).
Your git repository
is forked from the
original repository.
It includes the
history from the
original repository.
However, your
commit messages
are poorly worded,
too short,
undescriptive.
<...> Your git repository
contains clear and
concise commits, the
messages are well
formatted, easy to
understand, and
descriptive. You don’t
have too many changes
included in each commit
- multiple features result
in multiple commit
messages.
Details page
(content)
You haven’t
added the
details page
You’ve added the
details page, but it
doesn’t read any
data from the
database or the
data is not shown
correctly.
<...> You’ve thought critically
about what information to
display, how to format it,
and how potential users
would expect it to look. It
is professional,
consistent.
Details page
(code)
The code is
hard to read,
buggy,
inconsistently
formatted,
incomplete, and
there is lots of
commented out
code present.
No comments
or incorrect
comments.
The code is hard
to ready,
inconsistently
formatted, but it is
good enough to
get the job done.
No comments or
incorrect
comments.
<...> Your code almost reads
like prose. There is
proper use of variables,
functions and variables
are named properly,
everything is consistently
and appropriately
formatted, good use of
white space and
comments to make the
code more readable (but
no excessive
comments).
Uploading to
the server
Your website
(with changes)
is not available
on the live
website, and
you can’t show
it to us on your
laptop either.
You are able to
show the website
to us using a local
webserver on your
laptop (e.g. the
built in CakePHP
server, or a local
Apache
installation).
<...> The website is
accessible at
http://ie.infotech
.monash.edu/founda
tion-system-build/
submission/YOUR_AU
THCATE/app (where
YOUR-AUTHCATE is
replaced with your
authenticate username).
Version 1.0 (2019-02-26)What to do
We have endeavoured to provide some useful information below about each step we expect
you to complete. However, please remember that this is a capstone unit, which means that
you should already have many of the skills, and if not, you have the confidence and ability to
search for solutions by asking your peers, searching the internet, looking up your past units in
Moodle, etc.
As you are performing these steps, make sure to take notes so that you can write accurate
documentation about what steps you took. This will be important for documenting the
procedure, otherwise you may miss out important steps in your resulting documentation.
Install and setup PHP and associated tools
The framework you will be using in this unit is called CakePHP 3. It is a well supported, well
documented framework, for which there is a lot of information available on Google. It requires
PHP to be installed on your local development machine (i.e. your laptop), as well as some
other tools including Composer. We have prepared a guide on the Monash Alexandria
repository to help you set this up.
Install git
Git is the version control software that most IT teams use to track changes to their source
code. IE is no exception. A tutorial on how to use git is available at https://try.github.io.
Login to the Monash GitLab server
Information on accessing the Monash GitLab server is on Moodle under Unit Resources.
Fork the original repository
Once you are logged in to the Monash GitLab server, you should be able to visit
UGIE/UGIE-2018/foundation-system-build and “fork” the repository with your own account (i.e.
create a copy of it, including all of its history). Again, more information on this is available on
Moodle, and there is plenty of resources on the internet for how to use GitLab.
Clone your repository
After forking the repository, you have your own private copy you can modify however you like.
Your next job is to clone your copy of the repository to your laptop, so that you can make
changes to it. The git documentation explains how to clone a repository as does the GitLab
documentation (though this documentation isn’t very friendly to Windows users).
Version 1.0 (2019-02-26)Update website dependencies using Composer
Almost all modern web applications uses a tool called “composer” to manage dependencies.
Web applications are complex, and being able to ease your workload by leveraging high
quality, well tested code written by others is important. Composer lets you specify what to
depend on, and also to download and make those dependencies available to your application.
Again, there are countless resources on the internet about what composer is, how to use it,
and how to install it. After cloning, you will need to run “composer install” from the
repository directory to fill the “vendor” directory with PHP libraries your app depends on.
Setup a connection to the database
CakePHP requires you to copy the config/app.default.php file into config/app.php.
Once copied, edit config/app.php and change the “Datasources” section to connect to the
following database:
● Host: 130.194.7.82
● Username: fit3047_fsb
● Password: fit3047_fsb_password
● Database: fit3047_foundation_system_build
You will need to be connected to the Monash VPN (or eduroam) in order for your
website to be able to connect to this database!
Run website locally
When working in a web development team, it is important to be able to run the entire website
from your laptop. This means that you can make a change, and test it right away without
having to first deploy to a server somewhere, resulting in much faster development and less
bugs.
To do this, you can use the server built into CakePHP (additional documentation on the server
can be found here). Alternatively, you can install an Apache server (e.g. using XAMPP) and
then clone your repository into the htdocs directory of the XAMPP installation. The Apache
server will then be able to run your website locally. However, we recommend using the built in
CakePHP server.
Version 1.0 (2019-02-26)Make changes
The original website can be viewed
online and looks like this ->
For this build, you will need to
implement the details page, so that
each property can have its own
details page showing relevant
information about the property. The
database schema for the properties
can be found here.
Using PHPStorm
Although PHP code can be edited
in anything (e.g. Notepad++,
Notepad, Sublime Text, etc), it is recommended that you install PHPStorm. This provides you
with many benefits which make development easier, faster, less error prone, etc.
Commit and push
Once you have made the relevant changes in your local clone of the repository, you will need
to commit those changes and push them to your GitLab fork. The resources at
https://try.github.io will be helpful with this, as will Google or time spent with peers.
Deploy to IE server
Help on how to deploy your website to the IE web server (where you will also be deploying
your client websites throughout the year) is available on Moodle under Unit Resources.
Also known as “Iteration 0”
Introduction
Before you leap into the business of coding your project, it is important that you do some
pre-work to ensure that your infrastructure is sound. You need be familiar with the process of
making changes to a website, deploying those changes to a web server, and be confident with
documenting procedures. These skills will all serve you well for the rest of the year (and
indeed your career).
The idea is to make sure that every student has experience with writing a small amount of
documentation, and deploying a minimal website to a live server. In the process, it also
provides confidence that the infrastructure works, and to check this in the absence of any
custom code that could break things. The objective is to ensure you have a working
installation of PHP, and you have confidence and experience deploying new versions of your
application without experiencing implementation issues. Iteration 0 can provide the baseline
for future implementations and is the basis for the deployment plans for each iteration.
There output from completing iteration 0 is:
1. A bare-bones CakePHP application, which you’ve made minor customizations to,
committed the changes to a git repository, and then deployed to a live web server.
2. A document explaining the procedure in a clear and concise manner. This is
important because this process of making minor changes, sharing those changes,
and then publishing them is going to be repeated countless times in any IT project.
Iteration 0 is an iterative activity that you should repeat until the deployment process is
flawless. Monash mentors should be able to ask you to repeat the procedure in front of them
in studio, and you should have the skill and confidence to follow the procedure.
You can see the original web application deployed on the IE server, and the code is available
on the Monash GitLab server.
This practice is not trivial, therefore it’s highly recommended that you read this
document, along with all linked materials, in its entirety before start working on the
build. Making notes along the way is also helpful for both backtracking your actions and for
future references when you deploy your project on servers later on, and when you document
the procedure.
Version 1.0 (2019-02-26)Goals
The original website can be viewed online and looks like this:
When you click on the “Details” link for any of the properties, you will see (a very detailed but
also helpful) error:
Version 1.0 (2019-02-26)For this build, you will need to implement the details page, so that each property can have its
own details page showing relevant information about the property. The database schema for
the properties can be found here.
The above property listing screenshot is taken from the url “/properties”. However, if you
visit the homepage of the application, it will provide a small amount of insight into the
CakePHP framework being used and the MVC architecture in general:
Documenting the procedure
In addition to changing the website and deploying it, you are required to document the
procedure required for somebody else to follow your steps. This procedure should include:
● Where to obtain your code (i.e. your fork of the repository).
● How to get the code onto your laptop.
● How to commit changes and push them to your repository.
● How to deploy the updated code to the IE server.
Do not include any passwords in this particular documentation.
A good rule is that any IT professional should be able to read your procedure, and understand
it clearly enough to be able to make changes and deploy them without having to ask you any
questions.
Version 1.0 (2019-02-26)The documentation should not be particularly long. Realistically it should only need to be
about 1-2 pages (may be longer if you make use of images). It should be easy to read, well
formatted, and consistent. This will eventually form the basis for all future deployments for the
rest of the year, so you may as well try and get it right at the beginning.
This documentation is to be uploaded via Moodle.
Outcomes
At the end of iteration 0, you will be graded on the following:
N P <...> HD
Documentation
(content)
You’ve only
provided a
checklist / dot
points
describing the
procedure, or
you haven’t
described the
procedure at all.
It would be difficult
to be able to follow
the instructions
without asking
questions of you
first. Perhaps the
procedure misses
some important
steps, or it is far
longer than it
needs to be. The
formatting is poor,
English hard to
understand.
<...> Any IT professional
would be able to pick up
your procedure and
perform the steps
required only by reading
your document. The
procedure is written in a
clear and concise
manner. It isn’t too long,
but includes all of the
important aspects. If
required, you’ve included
visual aids to help
document the relevant
procedure. The
document is formatted
professionally and
consistently, and correct
English is used
throughout.
Documentation
(formatting)
No use of
structure
(headings,
paragraphs,
etc), no visual
aids, no
headers or
footers, etc.
Formatting is
inconsistent,
different fonts,
sizes, colours
used throughout.
Some visual aids
were used but they
are pixelated or of
low quality.
<...> Report looks
professional. Formatting
is consistent. Good use
of headings to break
content up, visual aids
are of high quality,
captions are used for any
images. Proper use of
headers and footers.
Version 1.0 (2019-02-26)Version control
(git)
The code is not
available in
source control
at all. Or, you
haven’t
imported the
project into your
own repository
(e.g. you copied
and pasted
individual files
from the original
repository,
losing the git
history in the
process).
Your git repository
is forked from the
original repository.
It includes the
history from the
original repository.
However, your
commit messages
are poorly worded,
too short,
undescriptive.
<...> Your git repository
contains clear and
concise commits, the
messages are well
formatted, easy to
understand, and
descriptive. You don’t
have too many changes
included in each commit
- multiple features result
in multiple commit
messages.
Details page
(content)
You haven’t
added the
details page
You’ve added the
details page, but it
doesn’t read any
data from the
database or the
data is not shown
correctly.
<...> You’ve thought critically
about what information to
display, how to format it,
and how potential users
would expect it to look. It
is professional,
consistent.
Details page
(code)
The code is
hard to read,
buggy,
inconsistently
formatted,
incomplete, and
there is lots of
commented out
code present.
No comments
or incorrect
comments.
The code is hard
to ready,
inconsistently
formatted, but it is
good enough to
get the job done.
No comments or
incorrect
comments.
<...> Your code almost reads
like prose. There is
proper use of variables,
functions and variables
are named properly,
everything is consistently
and appropriately
formatted, good use of
white space and
comments to make the
code more readable (but
no excessive
comments).
Uploading to
the server
Your website
(with changes)
is not available
on the live
website, and
you can’t show
it to us on your
laptop either.
You are able to
show the website
to us using a local
webserver on your
laptop (e.g. the
built in CakePHP
server, or a local
Apache
installation).
<...> The website is
accessible at
http://ie.infotech
.monash.edu/founda
tion-system-build/
submission/YOUR_AU
THCATE/app (where
YOUR-AUTHCATE is
replaced with your
authenticate username).
Version 1.0 (2019-02-26)What to do
We have endeavoured to provide some useful information below about each step we expect
you to complete. However, please remember that this is a capstone unit, which means that
you should already have many of the skills, and if not, you have the confidence and ability to
search for solutions by asking your peers, searching the internet, looking up your past units in
Moodle, etc.
As you are performing these steps, make sure to take notes so that you can write accurate
documentation about what steps you took. This will be important for documenting the
procedure, otherwise you may miss out important steps in your resulting documentation.
Install and setup PHP and associated tools
The framework you will be using in this unit is called CakePHP 3. It is a well supported, well
documented framework, for which there is a lot of information available on Google. It requires
PHP to be installed on your local development machine (i.e. your laptop), as well as some
other tools including Composer. We have prepared a guide on the Monash Alexandria
repository to help you set this up.
Install git
Git is the version control software that most IT teams use to track changes to their source
code. IE is no exception. A tutorial on how to use git is available at https://try.github.io.
Login to the Monash GitLab server
Information on accessing the Monash GitLab server is on Moodle under Unit Resources.
Fork the original repository
Once you are logged in to the Monash GitLab server, you should be able to visit
UGIE/UGIE-2018/foundation-system-build and “fork” the repository with your own account (i.e.
create a copy of it, including all of its history). Again, more information on this is available on
Moodle, and there is plenty of resources on the internet for how to use GitLab.
Clone your repository
After forking the repository, you have your own private copy you can modify however you like.
Your next job is to clone your copy of the repository to your laptop, so that you can make
changes to it. The git documentation explains how to clone a repository as does the GitLab
documentation (though this documentation isn’t very friendly to Windows users).
Version 1.0 (2019-02-26)Update website dependencies using Composer
Almost all modern web applications uses a tool called “composer” to manage dependencies.
Web applications are complex, and being able to ease your workload by leveraging high
quality, well tested code written by others is important. Composer lets you specify what to
depend on, and also to download and make those dependencies available to your application.
Again, there are countless resources on the internet about what composer is, how to use it,
and how to install it. After cloning, you will need to run “composer install” from the
repository directory to fill the “vendor” directory with PHP libraries your app depends on.
Setup a connection to the database
CakePHP requires you to copy the config/app.default.php file into config/app.php.
Once copied, edit config/app.php and change the “Datasources” section to connect to the
following database:
● Host: 130.194.7.82
● Username: fit3047_fsb
● Password: fit3047_fsb_password
● Database: fit3047_foundation_system_build
You will need to be connected to the Monash VPN (or eduroam) in order for your
website to be able to connect to this database!
Run website locally
When working in a web development team, it is important to be able to run the entire website
from your laptop. This means that you can make a change, and test it right away without
having to first deploy to a server somewhere, resulting in much faster development and less
bugs.
To do this, you can use the server built into CakePHP (additional documentation on the server
can be found here). Alternatively, you can install an Apache server (e.g. using XAMPP) and
then clone your repository into the htdocs directory of the XAMPP installation. The Apache
server will then be able to run your website locally. However, we recommend using the built in
CakePHP server.
Version 1.0 (2019-02-26)Make changes
The original website can be viewed
online and looks like this ->
For this build, you will need to
implement the details page, so that
each property can have its own
details page showing relevant
information about the property. The
database schema for the properties
can be found here.
Using PHPStorm
Although PHP code can be edited
in anything (e.g. Notepad++,
Notepad, Sublime Text, etc), it is recommended that you install PHPStorm. This provides you
with many benefits which make development easier, faster, less error prone, etc.
Commit and push
Once you have made the relevant changes in your local clone of the repository, you will need
to commit those changes and push them to your GitLab fork. The resources at
https://try.github.io will be helpful with this, as will Google or time spent with peers.
Deploy to IE server
Help on how to deploy your website to the IE web server (where you will also be deploying
your client websites throughout the year) is available on Moodle under Unit Resources.