联系方式

  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-23:00
  • 微信:codinghelp2

您当前位置:首页 >> Web作业Web作业

日期:2019-03-14 10:56

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.


版权所有:留学生编程辅导网 2020 All Rights Reserved 联系方式:QQ:99515681 微信:codinghelp 电子信箱:99515681@qq.com
免责声明:本站部分内容从网络整理而来,只供参考!如有版权问题可联系本站删除。 站长地图

python代写
微信客服:codinghelp