Lab 1

Lab 1

Environment Setup, Browser vs. Server, Local vs. Remote, GitHub

Overview

The goal of this lab is to setup our development environments, to understand the difference between web browsers and web servers, and to understand the more general concept of local vs. remote in web development.

This is an individual lab. Since individual environments must be configured, you will not have a partner. You will work with a partner starting next week.


Part 1: Important Details

Please use Google's Chrome in this course

Consider making Chrome your default web browser. And, consider downloading and installing Chrome on your own laptop or desktop computer.

While Firefox is a good web browser, it's code inspector is different than Chrome's. We will be using Chrome's code inspector often and you may become frustrated if your inspector is different.

Safari and Edge have improved greatly over the years, but these browsers do not yet have proven developer tools available.

Never use Internet Explorer; It is an outdated, buggy browser that does not follow standard conventions.

For file and folder names, avoid using spaces and follow a consistent convention in using upper-case letters.

The conventions below help reduce broken links and "file not found" errors. Please read below and follow a consistent convention.

  • Most files systems and web servers are case-sensitive. Thus, the files   MyPage.html,   Mypage.html,   mypage.html   and   myPage.html   all have different names. You can avoid many broken links and "file not found" errors, by following a strict convention. I recommend strictly using lower case letters for all folder and file names.
  • In processing URLs, web browsers and servers will replace spaces with special symbols (%20 or +), which can cause many problems. If you feel the urge to use a space in a file or folder name, please fight that urge. I recommend using a dash (-) or an underscore (_) in place of a space.

Part 2: Lab Setup

Make sure you can view file extensions in Windows

By default, Windows will hide file extensions, which makes it difficult to tell the difference between files with the same name that are actually different files with different file types, i.e., home.html and home.php. The following instructions will enable you to see all file extensions.

Display hidden files, folders, and filename extensions

Create lab folders and use them

You will be creating a lot of files in this course, it is important to keep them organized and to put them on your user drive (Z:) so you can access them from other computers.

  1. Create a folder on your user drive (Z:) for storing your course work called csis390/.
  2. Inside your csis390 folder, create a folder for storing your lab work, i.e., csis390/labs.
  3. Inside of your labs folder, create sub-folders for all 12 labs, i.e., lab2, lab2, ..., lab12.
  4. Inside your csis390 folder, create a folder for storing your project work, i.e., csis390/projects.
  5. Inside of your projects folder, create sub-folders for all 4 projects, i.e., project1, project2, ..., project4.

IMPORTANT DETAIL

Your z: drive is considered Local

While the files on your z: drive are stored on a remote file server at Siena, your z: drive is "mapped" locally when you login.


Part 3: Viewing Web Pages Locally vs. Remotely

Make a webpage and view it locally

  1. Open the Brackets text editor
  2. Create a new file and add the following minimal HTML document:
    <!DOCTYPE html>
    <html lang="en">
    
    <head>
      <meta charset="utf-8">
      <title>Web Page Title</title>
    </head>
    
    <body>
      <h1>Level 1 Heading</h1>
      <p>A sample paragraph</p>
    </body>
    
    </html>  
    
  3. Save the file as starter.html in z:/csis390/labs/lab1/
  4. Click on the preview button (lightning bolt icon on the right) to view the page in a web browser.
  5. Note the URL.
  6. Close Brackets.
  7. Use Windows File Explorer to locate your lab1 folder.
  8. Double-click on starter.html to open the file in your default web browser. If Chrome is not your default browser, consider making Chrome your default web browser.
  9. Note the URL.
  10. In Windows File Explorer, right-click on starter.html and look for an option to open the file in Brackets.

IMPORTANT DETAIL

Locating your files locally and opening them properly is important

Be sure to store all of your lab and project work in the correct folders, so you can easily locate files.

HTML documents (files with .html file extension) can be opened in two ways:

  • They can be opened for viewing/testing in a web browser (preferably Chrome), and
  • They can be opened for editing in any text editor: Notepad, Notepad++, Brackets, etc.

Upload the webpage and view it on the server

Use WinSCP to connect to our remote server.

Details about your specific server, userid and password were emailed to you. Here is the general information:

  • Hostname: ftp.sienasellbacks.com   or   ftp.breimer.net
  • Username: userid@sienasellbacks.com   or   userid@breimer.net
  • Password: Sent via email
  • Port: 21
  • Use FTP; Do not use SFTP or SCM

Be sure to replace userid with your actual Siena userid; But, do not add @siena.edu

  1. Upload your entire labs folder to your remote server by dragging the folder from left to right
  2. View starter.html on the web server by typing the URL   http://www.sienasellbacks.com/userid   or   http://www.breimer.net/userid   into Chrome.
  3. In Chrome, click on your lab1 folder and then click on starter.html to view the HTML document.
  4. Note the URL
  5. In Brackets, add another paragraph of text and save the file.
  6. in WinSCP, navigate to your lab1 folder on both your local and remote side.
  7. Upload your starter.html file by dragging it from the left to the right.
  8. In Chrome, hold the SHIFT key and press the reload button.
  9. Make sure you can see the paragraph you added in the webpage loaded from the remote server.

KEY CONCEPTS:

Your local lab computer is not a web server

While this may seem trivial, many students struggle to understand the following concepts:

  • Web applications are typically developed by creating and editing files locally on the hard drive of your computer or on a remote drive that is mapped locally.
  • Your local hard drive and your mapped drive may not be accessible to others. Thus, to collaborate with others or to deploy a web application, you must copy/upload your code to a remote server. This is typically done using Git, File Transfer Protocol (FTP), Secure FTP (SFTP) or Secure Copy Protocol (SCP)
  • While is it common to install a web server locally on your computer, Siena ITS will not give us sufficient permission to properly run local web servers. Thus, our local lab computers cannot easily act as web servers.
  • While web pages can be viewed locally, scripts and remote connections may not work when a page is loaded locally. Thus, to properly test web applications, we must copy/upload our files to a remote web server.

When testing always Save, Upload and SHIFT-Reload

When testing a web application on a remote server, saving your file is only the first step. You must also upload all the changed files to the remote server and then re-load/refresh the web browser.

Hard refresh / SHIFT-Reload

Web browsers will stored web pages and web application data locally in cache to improve performance. To ensure that your newly changed code is properly loaded, you should always do a "HARD" refresh by holding down the SHIFT key while pressing the re-load button of the browser. This forces the browser to fetch the updated files from the remote server.

KEY CONCEPT:

Web servers are remote and in the real world you will work with more than one

For commercial web applications, developers often use two or more remote servers. A development server is often used to test new code and a production server is used to make the web application accessible to customers and clients.

Some companies and organization also use a staging server and/or a system test server before moving applications from development to production.

In this course, we will only use one server and it will act as a development server. While your files will be publicly accessible, people will not be able to easily find your web applications unless they know the specific URL.

Because development and production web servers often have different domain names or IP addresses, it is important to always use relative hyperlinks for source files and references. You'll learn more about this in lecture.


Part 4: Intro to Git and GitHub

Motivation and basic concepts

If you are completely unfamiliar with Git or GitHub, you should have watched these videos.

Create a GitHub account

Skip to the next part if you already have a GitHub account.

  1. Go to https://github.com/join
  2. Use either your Siena email or an email you can check during this lab
  3. Be sure to remember your user name. Usernames (not emails) are used when sharing and collaborating on GitHub.

What is your GitHub username?

  1. Fill out this Google Form
  2. Be sure to use enter you GitHub username, not your email address

Collaborating with GitHub

Please read this introduction while you wait for your instructor to add you as a collaborator to his GitHub repository.

Please read the following to understand what you are doing at a high level:

You will clone a remote repository call csis390 which is stored on GitHub.com. This will copy the remote repository locally. Then, you will "checkout" the repository and make a branch. Then, you will add a new file and add a link to that file in the index page. Finally, you will commit your changes to your local repository and then push your branch to the remote repository (called "origin").

Pushing your branch will initiate a pull request so the repository owner can merge your branch into the repository. After the repository owner has merged several pull requests to the remote repository, you will update your local repository by pulling the remote repository. This will copy all the changes other students have made from the remote repository to your local copy.

To summarize more briefly, every student will create a file called userid.html, where userid is the student's GitHub userid. Every student will also modify index.html to link to their unique file.

  1. Open Git Bash and type the following
  2. cd z:
    This changes directories to your z: drive
  3. cd csis390/labs/lab1/
    This changes directories to your lab1 folder
  4. git clone https://github.com/ericbreimer/csis390
    This copies the csis390 repository to your lab1 folder
  5. cd csis390
    This changes to your local csis390 repository
  6. ls
    This lists all the files and folders in the repository
  7. Be sure to replace userid with your GitHub userid
    git checkout -b userid-additions
    This creates a branch that describes what you are doing. You are going to make additions to the repository.
  8. Open student1.html in Brackets
  9. Be sure to replace userid with your GitHub userid
    Save the file as userid.html, where userid is your GitHub userid.
  10. In the file you just saved, replace "Test Student" with your name.
  11. Change Major, Year, Hometown, etc. to reflect your information.
  12. Add another tr, th and td group indicating something else about you, i.e., Minor, Favorite Food, etc.
  13. Save the file.
  14. Open index.html and locate the div for your correct lab, i.e., Tuesday or Wednesday.
  15. Be sure to replace userid with your GitHub userid
    Change one of the hyperlinks student1.html, student3.html, etc. to userid.html, where userid is your GitHub userid.
  16. Replace "Test Student 1", "Test Student 3", etc. with your name.
  17. Save the file.
  18. In Git Bash, type the following:
    git add .
    This adds /stages all the files you modified
  19. git commit -m "added new file and changed index.html"
    This commits your changes to your local repository and adds a very descriptive comment
  20. Be sure to replace userid with your GitHub userid
    git push origin userid-additions
    This pushes the branch you made to the remote repository (called origin).
    This also creates a pull request enabling collaborators to pull and merge your branch into the master remote repository.

Pulling the latest origin repository

  1. Wait for the instructor to merge several of the branches

    You can read this introduction again while you wait for your instructor to merge some branches.

  2. In Git Bash, type the following:
    git pull origin master
    This pulls all the merged changes into your current branch
  3. Note that this doesn't always work if the origin repository has significantly changed. This may require you to manually merge the changes and your instructor can help.
  4. In Git Bash, type the following:
    ls
    Note that there are many more files
  5. Open index.html and note that there are many more links.

KEY CONCEPT:

GIT is a superior way to collaborate

If everything worked correctly, many different people just contributed to a shared repository that represents the class website. This website can be collaboratively developed using GIT, which is superior than using FTP. Unlike FTP, which just copies files, GIT keeps track of revisions and who made them.

KEY CONCEPT:

GitHub is remote; A cloned repository is local

The origin repository on GitHub is remote, i.e, you can access it from anywhere; Cloned repositories are local, i.e, they are stored on your local hard drive, which could be a mapped drive. Git is a client-server application and protocol that allows your local computer to communicate with a remote Git server. GitHub is the most popular Git server/service. Another popular Git service is called BitBucket

DELIVERABLES

  1. Your starter.html file must be modified (additional paragraph) and uploaded to the remote server.
  2. You must share you GitHub userid using the Google Form (see above)
  3. You must push your branch to the remote origin csis390 repository. Your branch must include a file called userid.html, where userid is your GitHub userid. This file should contain your name and your information. Your branch will also modify index.html to link to the file you created.

Not finished?

The deliverables must be "submitted" by midnight on the Monday before your next scheduled lab meeting.