module 1
Client-Server Interaction: Request, Response, and the Web Behind the Scenes
When you enter a URL like www.google.com or www.amazon, your browser (the client) sends a request to the server hosting that page.
The server responds by delivering the requested page (the HTTP response).
There is a handshake process that sets up the connection and the data exchange (e.g., TLS/SSL handshake for secure connections). The transcript notes this handshake but treats it as beyond the current class scope.
A lot of data exchange happens behind the scenes beyond the simple request/response model.
This interaction is governed by several core Internet technologies and protocols:
TCP/IP: the foundational transport and internet protocol suite used for data exchange.
DNS (Domain Name System): resolves human-readable domain names to IP addresses.
HTTP (Hypertext Transfer Protocol): the application protocol that governs the communication between the client and the server.
The transcript mentions a misnamed term as "Hypotest Transfer Protocol"; the correct term is Hypertext Transfer Protocol (HTTP).
Reading recommended: explore literature on basic web concepts and how the client-server model underpins everyday web usage.
Core Concepts: Web Standards, Open Standards, and the Evolution of the Web
Web standards define how technologies should work together to ensure interoperability across different systems and vendors.
Open standards are described as non-proprietary and contributed to by multiple people or organizations, not owned by a single company.
Bodies responsible for web standards and the evolution of the web include standards organizations and consortiums (the transcript emphasizes “bodies responsible” and “open standards”).
The Open Web emphasizes accessibility and operability across devices and platforms.
Practical note: develop familiarity with web standards, best practices, and how the web is published and accessed across different environments.
Client-Side vs Server-Side Perspectives
Client side: the web browser acts as the user’s interface to request and render pages.
Server side: the infrastructure that serves pages, runs the application logic, and handles data processing.
The transcript mentions that server-side development is broader and more complex than client-side development, which focuses on the browser and front-end code.
Encourage reading about web standards and server-side technologies to build a holistic understanding.
Files and Folders: Understanding Files, Extensions, and Storage Structure
A file is a storage unit for information/data in a computer system.
File extensions indicate the file type, e.g.,
".jpg" indicates an image file
".doc" or ".docx" indicates a Microsoft Word document
".exe" indicates an executable program
".html" indicates a HyperText Markup Language document (HTML)
Example with a filename and extension:
The transcript mentions a filename like:
"two million twenty two thousand one hundred twelve point zero .jpg"
Interpreted as the file name with extension .jpg. The numeric portion can be represented as if written in mathematical notation.
A folder (directory) is a container that can hold files and subfolders, potentially forming a tree structure:
Root folder (e.g., the C drive) contains subfolders like My Documents, My Videos, My Pictures, etc.
Each folder can contain files and further subfolders, forming a hierarchical structure.
Example structure in the transcript:
Root: C:\
Subfolders: Mark, English, Computer Science, etc.
Files inside folders: PrimaryNumber.txt, x.a.doc, hello_world.py, timetable.doc, etc.
Visual concept: a tree-like representation with levels (root, subfolders, files).
Local vs Remote Files: Definitions, Access, and Implications
Local files:
Stored on your own computer (e.g., in C:\Users\YourName\Documents).
Accessible only when you are on that computer or when you transfer/copy them elsewhere (e.g., via email, flash drive, or network transfer).
Remote files:
Stored in the cloud or on remote servers/data centers managed by cloud providers or organizational hosting.
Accessible over the Internet; you retrieve them by addressing a URL.
Cloud and data centers:
Providers like Amazon (AWS), Google (GCP), Microsoft Azure, etc., operate data centers worldwide.
Data is replicated across multiple centers to ensure availability and resilience: if one data center fails, others can serve traffic.
Data residency rules may require hosting data within certain geographic boundaries, depending on policy and regulation.
The implication: the same page you access via a URL might be served from different data centers around the world, giving seamless access even during failures.
The transcript emphasizes the difference between accessing a local file path (e.g., via file explorer) and accessing a remote file via the Internet (via HTTPS), including the different user experiences and URL-based access.
Publishing Your First HTML File: The Practical Workflow (High-Level Overview)
The main task is to publish an HTML file so that others can access it via a URL.
Five core steps are outlined:
1) Set up your workspace.
2) Review your file locally.
3) Validate your HTML code.
4) Publish to GitHub (remote repository).
5) View your published file on the web.The workflow is designed to be iterative: develop locally, test, validate, push to GitHub, and then deploy via GitHub Pages.
Step 1: Set Up
Create a workspace folder structure, typically under a course-specific directory, e.g., CSIT folder with a subfolder named practice.
Use a code editor (e.g., Visual Studio Code) to manage files:
Open the project folder in the editor.
Download the demo HTML file provided for practice and place it in the practice folder.
Log in to the course's student portal or identity provider (e.g., CCBC student account) to access course materials and demo files.
Ensure you have a GitHub account and a public repository to host your pages.
Step 2: Local Review
Preview the HTML file locally in a web browser to verify rendering before online publishing.
How to preview locally (typical workflow):
In the file explorer, navigate to the HTML file (e.g., C:\Users\YourName\csit121\practice\demo.html).
Right-click and choose to open with a browser (e.g., Edge, Chrome, Firefox).
The local path example from the transcript is: C:\Users\YourName\csit121\practice\demo.html (path shown in the lecture).
Step 3: Validation
Use a validator to check HTML syntax and catch errors before publishing:
W3C HTML Validator: paste or upload the file and run the check.
Aim for a successful validation that yields a green message indicating no errors.
Reasons to validate:
Ensures accessible, standards-compliant markup.
Reduces submission errors in automated grading.
If issues arise, common fixes include correcting typos, fixing tag nesting, and closing tags properly.
Step 4: Publish to GitHub
Prerequisites: a GitHub account and at least one public repository
Create a GitHub repository for the course work (e.g., CSIT121).
Upload your demo.html (and any associated files) to the repository:
You can drag-and-drop the file into the repository in the GitHub UI or add files via the web interface and commit.
Ensure the repository is public so others can access the content.
Common workflow supports both Windows and macOS; interface may vary slightly but the core steps are the same.
After committing, the file exists in the remote repository (GitHub).
Step 5: Deploy with GitHub Pages
Enable GitHub Pages for the repository to publish the site:
Go to Settings > Pages in the repository.
Under Branches, select the main branch as the source and save.
After a short delay, GitHub Pages will provide a unique live URL for your site.
Example URL pattern:
The transcript’s example uses a GitHub user page like: https://natriungo.github.io/csit121/
The live URL lets anyone on the Internet access your published page.
Key concept: this is a public web page hosted by GitHub Pages, leveraging your repository contents.
Step 6: Understanding the URL and Access
Break down of a deployed URL example:
Protocol: https
Domain: .github.io
Repository:
Path: //… (e.g., /practice/demo.html)
You can share this URL with others; they can access the page from any device with Internet access.
Distinction between local access (file path on your computer) and remote access (HTTPS URL from GitHub Pages).
Important note: remote access is not the same as accessing your local files; remote access requires the file to be hosted online.
Step 7: Validation of the Process and Next Steps
After deployment, verify that the live page loads correctly via the GitHub Pages URL.
You may see the content of the repository’s root (often a readme) first; ensure your demo.html is reachable via the published path.
If you need to adjust content, update the local files, push changes to GitHub, and GitHub Pages will update the live site after a short propagation delay.
The transcript emphasizes testing in multiple browsers and ensuring the published page is accessible globally.
Practical Tips and Common Scenarios
Create a single, consistent repository for the course (e.g., CSIT121) to avoid confusion about multiple repositories.
Use meaningful folder structures (e.g., practice/demo.html) and keep the file names simple and descriptive.
Always test locally before publishing to minimize grading issues.
If you encounter interface changes in GitHub (which can happen), the underlying steps remain the same: create repository, upload files, commit, enable GitHub Pages, and copy the live URL.
Nine hours of practice is recommended for this course to achieve fluency with HTML, Git, and GitHub Pages; more for advanced courses.
Quick Reference: Key Terminology from the Lecture
Client: the user’s browser requesting web content.
Server: the host delivering requested content.
DNS: resolves domain names to IP addresses.
TCP/IP: foundational transport/internet protocol suite.
HTTP: application-layer protocol for web traffic (note the correction from the transcript’s misnaming).
HTML: HyperText Markup Language, used to structure web pages.
CSS/JavaScript: mentioned as common server-side/side technologies you might encounter later.
Local vs Remote files: local files live on your machine; remote files live in cloud/data centers and are accessed via URLs.
GitHub: a platform for hosting Git repositories and, via GitHub Pages, hosting static websites.
GitHub Pages: a service to publish static sites directly from a Git repository.
URL structure: protocol:////
Validator: a tool (e.g., W3C Validator) to check HTML validity and markup quality.
Encouragement for Next Steps
Revisit the steps to set up your workspace, publish the demo.html, validate the code, and deploy to GitHub Pages.
Practice by repeating the workflow with your own files (e.g., an About Me page) to reinforce concepts.
Review the course schedule and plan to participate in Thursday online sessions for help.
Remember: practice is essential; aim for the recommended hours to build confidence and reduce errors in submissions.
Appendix: About Me HTML and Optional Exercises
The instructor mentioned that an About Me HTML file is optional; you can start with the provided demo.html and modify as you like.
If you choose to create an About Me page, you can incorporate the same structure and practices used for demo.html.
Summary of the Practical Workflow (One-Page Recap)
Set up a CSIT workspace and a practice folder.
Use VS Code to manage files and open the demo.html.
Preview locally in a browser using the local file path.
Validate HTML with the W3C Validator and fix any issues.
Create a public GitHub repository; upload demo.html; commit changes.
Enable GitHub Pages on main branch; copy the live URL and test accessibility.
Understand the URL components and ensure your page is accessible to others over the Internet.
Continue practicing with additional HTML files to build familiarity with the publishing workflow.