Basic Web sites

You’ve read about what makes a Web site good. You know how clients and servers exchange data.

Now let’s see how a simple Web site works. You’ll:

Where Web pages come from

This lesson’s goals

When someone looks at a Web page, s/he sees a display on a computer screen.

A Web page

Figure 1. A Web page

There are photos and drawings, text, different colors, boxes to type in, buttons, and other things.

But what makes all that? What actually puts the text on the screen, in the right fonts and the right colors?

The user experience

To the user, a Web site is a bunch of pages. Here’s a site with two simple pages.

A Web site

Figure 2. A Web site

You can try it.

The site has two pages. Each page has two things:

  • Information it displays, like photos and text.
  • Behavior, like clicking a link to go to another page.

The user’s experience of the site is made up of both information and behavior.

The Web browser creates this experience for the user. Browsers like Firefox, Chrome, Safari, Opera, and Internet Explorer. It’s the browser that draws the text, shows the photos, and executes the behaviors.

Firefox is CoreDogs’ official browser.

But how does the browser know what information to show, and what behavior to execute? Here’s how:

  • The browser gets files from a Web server. (Recall that a Web server is a computer on the Internet that waits for browsers to ask for files, and then sends them.)
  • The files contain instructions on what displays to make.

Here’s how it works.

Fetch a page

Figure 3. Getting a Web page

Say the user is looking at cow.html (see Figure 1). S/he clicks on the link to pig.html (1 in Figure 3). The browser executes a behavior, that is, show the Web page pig.html.

Renata
Renata

How does the browser know to show pig.html and not some other page?

Kieran
Kieran

Because of this code in cow.html:

<a href="pig.html">pig</a>

This makes the browser show the word “pig” and underline it. When the user clicks on “pig,” the browser loads pig.html.

You’ll learn more about this later.

The browser asks the server for some files (2 in Figure 3). The server reads the files from its disk drive, and sends them back to the browser (3 in Figure 3).

In step 4, the Web browser renders the files, creating the display the user sees.

Rendering

Here’s part of the file pig.html. It’s a file that the browser got from the server.

<p>
  I am a pig. I know a <a href="cow.html">cow</a>.
</p>

Figure 4. What the server sent

It’s some instructions on what to show on the user’s computer screen.

The browser follows those instructions. It creates a display like this.

From the pig screen

Figure 5. From the pig screen

When a browser renders a page, it follows some instructions and creates a display for the user.

Different types of files contain different types of instructions. The data in Figure 4 are in the file pig.html. They’re instructions in the HTML language.

The data that make the photo of the pig are in a different file. The name of that file is eunice.jpg. eunice.jpg is a bunch o’ numbers, just like every file. The numbers follow the JPEG standard, created by the Joint Photographic Experts Group.

The Weber’s job

Where are we?

  • The browser gets files from a Web server. The files contain instructions on how to make displays.
  • When a browser renders these files, it follows the instructions in the files to make a display.

So, these files on the server. How do they get created?

A Weber (someone who makes Web pages) decides on a page’s:

  • Content – the text and images.
  • Formatting – what the content looks like (colors, fonts, etc.).
  • Behavior – e.g., what happens when a user clicks on a link.

Often the Weber makes a rough drawing:

Page sketch

Figure 6. Page sketch

Then the Weber creates files that will make the browser render a page like that.

The Weber types in some of the files, like the HTML in pig.html (see Figure 4). Typity typity, type, type, type, type.

For photos, the Weber won’t type in color codes. S/he will get a photo from somewhere, and maybe change it a little. I got the pig photo from the US Department of Agriculture.

Finally, the Weber uploads all of the files to the Web server, where Web browsers can get to them.

What you will learn

The second book in CoreDogs – ClientCore – will help you learn how to create a Web experience for the user.

You’ll learn how to make the files that the browser will render the way you want. You’ll learn how to write code like this…

<p>
  I am a pig. I know a <a href="cow.html">cow</a>.
</p>

Figure 4 (again). Code that the browser rendered

... that a browser will render like this:

From the pig screen

Figure 5 (again). From the pig screen

And you’ll learn how to put the files on a Web server.

You’ll need a Web server to put your files on. Soon, you’ll learn how to get your own server space.

Summary

  • Web pages have content, format, and behavior.
  • The Web browser creates the user’s experience of a Web page.
  • The browser grabs files from a Web server.
  • The browser renders the files it gets from the server, that is, it follows instructions in the files to create displays.
  • The Weber creates the files that the server sends.

What now?

URLs are key to how Web browsers and servers work together. The next two lessons are about URLs. Let’s start by talking about what URLs are.

What URLs are

Where are we?

Browsers ask servers for files. How do browsers know which files to ask for? They use URLs.

This lesson’s goals

This lesson is about URLs. You’ll learn:

  • What a URL is.
  • How browsers work out how to render data they get from a URL.
  • That clickable links on Web pages have URLs embedded in them.

URLs are addresses

Every file on the Web has a URL (uniform resource locator). Whether it’s an HTML file, a photo file, whatever, it has a URL.

A file’s URL is its unique address on the Web. Just as a cell phone has a unique telephone number, a file has a unique URL.

It’s a little more complex in some cases, but let’s ignore those cases for now.

Here’s an example of a URL:

http://www.blm.gov/wo/st/en/bpd.html

The URL has several parts. You’ll learn how the pieces work in the next lesson.

How URLs get into browsers

To get a URL into your browser, you usually either:

  • Put the URL into a browser’s address field.
  • Click on a link to the page.

Try both for the URL above. Copy the link and paste it into your browser’s address field:

Address bar

Figure 1. Address bar

Now for the second method. You can click here to visit the URL.

Extensions

That URL again is http://www.blm.gov/wo/st/en/bpd.html. It’s a URL for a page, not a photo or some other thing.

How do I know it’s a URL for a page?

The part of the file name after the last period (.) is the file’s extension. It tells the browser what type of data is in the file. Then the browser can decide how to render the file.

Every browser has a table like this:

Extension Render as...
html Web page
jpg Image
png Image
... ...

Figure 2. File extensions and types

So:

  • Every file on the Web has a unique URL.
  • The file’s extension tells the browser what type of file it is.

The cow page

Here’s the cow page again.

Cow page

Figure 3. Cow page

You can try the page.

The URL of the page is http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/cow.html.

There are three things on the page:

  • Some text, like “I am a cow.”
  • An image.
  • A link to the pig page.

Here’s some code from cow.html. The browser renders it to make the three things.

<p>
  <img src="bessie.jpg" alt="Bessie">
</p>
<p>
  I am a cow. I know a <a href="pig.html">pig</a>.
</p>

Figure 4. Code from cow.html

Don’t worry about the details. We’ll cover them later. Just a couple of things to note for now.

First, the text “I am a cow” is in the file. You can see it in line 5.

But the cow photo is not in cow.html. So how did the photo get into the page? Look at line 2:

<img src="bessie.jpg" alt="Bessie">

The photo is in a separate file, called bessie.jpg.

The photo file has its own URL. bessie.jpg is shorthand for the full URL, http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/bessie.jpg.

Copy and paste the URL into a browser. You’ll see the photo by itself, without the rest of the page.

So when you tell your browser to go to cow.html, your browser asks the server for two files:

  • cow.html
  • bessie.jpg

cow.html has instructions on how to draw the text and the link to the pig page. The instructions follow the HTML standard. bessie.jpg has data on how to make the photo. The data follow the JPEG standard.

OK, so there are three things that make the cow screen:

  • Some text.
  • An image.
  • A link to a pig page.

Let’s talk about the link.

This code makes a link:

<a href="pig.html">pig</a>

When the browser renders this, it does two things:

  • It shows something on the display.
  • It gets ready to execute a behavior.

The display is like this:

The pig link display

Figure 5. The pig link display

The browser draws the word “pig” in blue, and underlines it. That’s the display part.

The behavior? When the user clicks on the link, the browser asks the server for a new file. The link gives the URL of that file. The URL is usually for a Web page (ending in .html), but it could be for any type of file.

The full URL of the file is http://coredogs.com/content_media/lessons/corecore/simple-web-pages/animals/pig.html. pig.html in <a href="pig.html">pig</a> is shorthand for that full URL.

Summary

  • Every file on the Web has a URL. A file’s URL is its address on the Web.
  • The file’s extension tells the browser what type of data is in the file.
  • Photos are stored in separate files from HTML pages.
  • Links contain URLs.

What now?

You can see that URLs are important things. Let’s learn a little about what a Web server does when it gets a URL.

How URLs work

Where are we?

You learned that a URL is the address of a file. Could be a page, could be a photo, could be something else.

Let’s dig a little deeper. What do servers do when they get a URL request from a browser?

This lesson’s goals

By the end of this lesson, you should know:

  • When a browser asks for the contents of a URL, it usually gets back the contents of a file on a server.
  • How a URL is mapped to a server file.

Suppose that a browser shows this.

Link rendered in a browser

Figure 1. Link rendered in a browser

It comes from this HTML.

<a href="http://doomdogs.com/products/ball.html">Bouncing ball</a>

There are two parts to the link. First, there’s the text shown to the user. That’s “Bouncing ball.” Second, there’s a URL: http://doomdogs.com/products/ball.html. That’s where the browser will go if the link is clicked.

GETting a page

A user clicks the “Bouncing ball” link. What does the browser do?

First, it creates an HTTP GET request. We looked at HTTP earlier, in the lesson on the services layer. The request looks something like this:

GET /products/ball.html HTTP/1.1

The message is sent to a server. Which server? The one given in the URL.

The URL of the desired page is http://doomdogs.com/products/ball.html. The first part – http – is the service-layer communication protocol to use. The second part – doomdogs.com – is the domain name of the server. So that’s where the message is sent: to the server at doomdogs.com.

The rest of the URL (/products/ball.html) tells the server what data to return to the browser. That part of the URL matches a file on the server. A server might have 50,000 files that it can send to a browser. /products/ball.html is the particular file it should send.

URL paths and file paths

Let’s look at this more closely.

As you know, the files on the computer you’re using right now – PC, Mac, whatever – are organized into a directory tree. Windows calls directories “folders,” but they’re the same thing. Webers usually talk about directories rather than folders.

Here’s part of the tree on my Windows hard drive.

Directory tree

Figure 2. Directory tree

The Windows file path to the file renata.jpg is:

C:\dogs\mydogs\renata.jpg

This means:

Start at the root of the C: drive.
Then go down into the dogs directory.
Then go down into the mydogs directory.
There you will find the file renata.jpg.

I can use this path in Windows programs. For instance, I could type the path into the Open File box of a Windows editor:

Windows file path

Figure 3. Windows file path

Other operating systems have different rules for file paths. A path on a Unix machine might look like this:

/dogs/mydogs/renata.jpg

Unix (and Linux and similar things) don’t have drive letters, like C: or D:. And they use a / rather than a \ to separate subdirectory names.

Another difference is that Windows file names are not case sensitive, while Unix file names are case sensitive. So, in Windows:

C:\awah\ajer\kyam.txt

and

C:\awah\ajer\Kyam.txt

refer to the same file. But in Unix:

/awah/ajer/kyam.txt

and

/awah/ajer/Kyam.txt

refer to different files.

Beginners often forget this. Suppose you create a site on a Windows PC. You type the file name DepressedDoom.html in some places, and depresseddoom.html in others. It works fine on your computer, because Windows thinks that DepressedDoom.html and depresseddoom.html are the same file.

You upload the site to a Unix server (most Web servers run Unix of some sort), and the site breaks. Unix thinks that DepressedDoom.html and depresseddoom.html are different files.

Here’s the rule we follow throughout CoreDogs:

Always use lowercase for file names.

Mapping URL paths and file paths

OK. So we have URLs. They’re Web addresses for files. Like:

http://doomdogs.com/products/ball.html

And we have file paths, like:

C:\dogs\mydogs\renata.jpg

They look similar, don’t they? They both have slashes, things that look like directory names, file names, and extensions.

There’s a reason they look similar: they are different versions of the same thing!

A URL is really a file path, with some networkish stuff added.

On simple sites. Some advanced tech is different. Let’s ignore it for now.

How can a URL and a file path both refer to the same thing? By taking a directory on a Web server, and making it the root of a Web site.

An example

Here’s Jake, looking at a Web page on doomdogs.com.

Jake finds a ball

Figure 1 (again). Link rendered in a browser

Why is Jake’s browser showing him a link? Because of this HTML:

<a href="http://doomdogs.com/products/ball.html">Bouncing ball</a>

This link says to show the text “Bouncing ball.” If Jake clicks on it, his Web browser will jump to the page http://doomdogs.com/products/ball.html.

Let’s look at what happens when Jake clicks.

Serving a file

Figure 4. Serving a file

Jake clicks on the link (1 in Figure 4). The browser looks at the code that created the link. The code is:

<a href="http://doomdogs.com/products/ball.html">Bouncing ball</a>

So the browser knows it should show the page http://doomdogs.com/products/ball.html.

The browser creates an HTTP message to doomdogs.com: GET /products/ball.html (2). The Internet sends the message to the Web server.

The server at doomdogs.com is a computer, with a hard disk spinning away. It runs the Unix operating system.

If you looked on the server’s disk drive, you would see a file with the path /sites/dd/products/ball.html.

Server files

Figure 5. Server files

This is the file with information on the bouncing ball.

Somehow, we want the Web server to use the URL the browser sent, to fetch the right file from its disk drive. It needs to convert the URL into a file path, then use the file path to read the file.

Translate URL into file path

Figure 6. Translate URL into file path

Suppose the server is running the Apache Web server software (it’s the most popular in the world). Apache has a configuration file, created by the DoomDog’s Web master. The file tells Apache how to run.

One of the settings in the file is DocumentRoot. The setting tells Apache where on the computer’s disk drive the files for the Web site are stored.

The Web master put all the data for the doomdogs.com Web site in the directory /sites/dd. Then s/he set DocumentRoot to /sites/dd, so that Apache would know where to get the files.

The server takes its DocumentRoot setting (/sites/dd) and appends the URL path (/products/ball.html), giving /sites/dd/products/ball.html.

Computing the file path

Figure 7. Computing the file path

Now Apache knows where to get the file the browser asked for.

Here’s the process again.

Serving a file

Figure 4 (again). Serving a file

We’re at step 3. Apache has translated the URL to a file path on the server computer’s disk drive.

Apache reads the file (4), and sends its contents back to the browser (5). The browser renders the content for Jake (6). Recall that rendering is the process of making a display from code in a file.

Hooray! Jake is happy, and runs around and barks.

Renata
Renata

So for a URL like http://thing.com/what.html, thing.com is the server name, and /what.html is a file path?

Kieran
Kieran

Yes, that’s a good way to think about it.

Renata
Renata

But when I want to Google something, I don’t type http://www.google.com/search.html. I type http://www.google.com. There’s no file path in that URL. What does the Google server do?

Kieran
Kieran

Good question!

The server needs to get a file name from the path. If there isn’t a file name there, it adds one. That is, it uses a default file name.

Every server could use a different default, but in practice most use index.html. So, the URL http://doomdogs.com/ maps to http://doomdogs.com/index.html.

Renata
Renata

So when I make a home page, I should call the file index.html? So if someone just types the domain name, they’ll get the home page?

Kieran
Kieran

Yes! That’s it! You are one smart puppy.

Servers actually have a list of default names, like index.html, index.php, default.htm, and so on. The server will grab the first file in the list that it finds.

For now, let’s assume it’s always index.html.

Summary

In this lesson, you learned:

  • That many Web page requests are actually requests for files.
  • How a URL is mapped to a server file.

What now?

Let’s put some of this knowledge into action. Time to buy a Web hosting account, and get real!

Buy hosting. Now!

Where are we?

You’ve learned how Web browsers and servers interact. Time to start putting your knowledge into practice. But first, you need your own home on the Web.

This lesson’s goals

By the end of this lesson, you should:

  • Know what “buying hosting” means.
  • Know about some different kinds of hosting.
  • Know what features to look for from a shared hosting plan.
  • Be ready to buy hosting.

You need a home on the Web

You need your own Web site. Yes, you do. A place for your own eMe. Really, you need your own Web site. With your own domain name and everything.

CC
CC

I know we talked about this before. I have a Facebook page. Remind me why I need a Web site.

Kieran
Kieran

Facebook’s great. But there are a few issues with it.

First, Facebook pages have Facebook’s logos, format, and ads. In other words, Facebook’s branding.

You want your site to be about you, or your company, or whatever you choose to promote. You don’t want people to be distracted by other stuff. Take the page you’re looking at now. It’s all CoreDogs.

With your own site, you have complete control. Choose the fonts, colors, images, you name it.

Second, Facebook limits what you can do. Say you’re an expert on zombies. You can make a site on how to survive the coming Zombie Apocalypse. You can put ads on your site, sell stuff through it, run events (“Come to the Spring Zombie Hunt!”), make some moolah. Dosh, cash, bread, simoleans.

You can do some of that on Facebook. But not everything you want.

Third, when you have your own site, you tell the world that you can do Web work. It’s a valuable skill that not everyone has.

Fourth, having your own site teaches you a lot about the Web. In fact, most of the exercises in the ClientCore and ServerCore books ask you to upload your solutions to your own site. You can’t do that if you don’t have a site!

One last thing. Suppose your name is Rover Blakenshot. You could register blakenshot.com, and give yourself a cool email address, like rover@blakenshot.com. You could give email addresses to your family and friends. Your brother could be billy@blakenshot.com. You get to decide. Oh, the power! The power!

Renata
Renata

You forgot something.

Kieran
Kieran

What’s that?

Renata
Renata

Having your own site is so freakin’ cool!

Three things

You need to do three things to get your own Web site:

  • Get a domain name. The first part of the URL of all your Web pages. You and only you have that domain.
  • Get a hosting account on a Web server. This is a computer you put files on, that’s accessible over the Internet. Someone else runs the server for you. Recall that every server has an IP address, like 123.234.123.234.
  • Tie them together. For example, suppose you register the name blakenshot.com. You get an account on a Web server that has the IP address 123.234.123.234. You tie the two together. So when someone types blakenshot.com into a browser, that gets translated into 123.234.123.234.

Most domain names end in .com, .org, .edu, or .gov. These are called “top-level domain names.” There are other options, including .info, .biz, and .name. Wikipedia has a complete list.

Countries have their own top-level domain names. Like .au for Australia, and .uk for the United Kingdom.

Domain names are unique. You must choose one that nobody else is using.

There are two ways to figure out whether a domain name is available. The first way is to type it into your browser, and see if you get anything back. If you do, the domain is taken.

A more reliable way is to look up the domain database. There are Web sites that will do this for you.

A warning: be careful of the lookup service you choose. Some of the them might register the domain while you’re thinking about it. (I think this has happened to me, though it’s hard to be sure.)

One service that’s probably safe is Network Solutions. It will tell you whether a name you’re thinking about is available.

If you can’t get yourname.com, don’t despair. Try yourname.org, yourname.net, and yourname.info. You’ll come up with something.

Exercise: Choose a domain name

Choose a domain name that’s easy for people to associate with you. It could be your name, though if you have a common name, domain names based on it might be taken.

Think of at least three options. Talk it over with your friends. See if they can come up with some good names.

If you have some advice for choosing domain names, please share it.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

What you get when you buy hosting

You get a bunch o’ stuff, but here are the main things:

  • Disk space on a server. This is where you’ll store your Web pages. Each server has an IP address. The hosting company will tell you what it is.
  • Some way to upload files to the server from your computer.
  • The right to associate your domain name with the IP address of your host.

More on what you get in a moment, but these are the basics.

A domain name is a separate purchase, but hosting companies make it easy to register a domain name during account sign up.

Types of hosting

There are lots of hosting plans, but they fall into a few main types.

Free hosting

Some companies will give you free server space, and insert ads in your pages. Avoid this type of hosting.

First, you usually don’t control the ads on your pages. You give your URL to a potential employer, and the first thing s/he sees is a flashing ad for “Hot Bondage Boys! Click NOW!” Think you’ll get that job?

Second, you don’t fully control your pages. The ads interfere, and sometimes even break your pages. The hosting company can change the size and placement of your ads, whenever it likes.

Third, the company doesn’t have much incentive to look after your content. If the disk drive with your site crashes, they might not be in a hurry to restore it from their backups. If they have backups.

Shared hosting

Cheap, and what you’ll use to begin with. With shared hosting, you share a server with other people. So you might have, say, fifty Web sites on the server, along with your own.

This usually works fine. Reputable hosting companies make sure that none of the individual sites uses too much of the server’s processing time.

The hosting company does most of the server management for you. They take care of basic software updates and such. They back up your files, in case something goes wrong. You can just worry about your Web site.

Most shared hosting accounts run on Unix machines. Some run on Windows machines.

CC
CC

I don’t know how to use Unix. So I should get a Windows server?

Kieran
Kieran

No! You should get a Unix account.

You interact with servers differently from the way you interact with your PC. For a Windows user, a Windows server is not easier to work with than a Unix server. They’re about the same.

But a Unix server will run more free software than a Windows server. All sorts of goodies, at your fingertips.

And remember that most Web servers run Unix. That means most employers use Unix servers.

Finally, Unix hosting accounts are often cheaper than Windows hosting accounts. Why? Because there are lots of free versions of Unix. Not so for Windows.

Shared hosting runs from about $5 USD to $10 USD per month. We’ll talk about some specific services later. But that’s about what you can expect to pay.

Renata
Renata

Do I have to spend the money?

Kieran
Kieran

You should. You get to create your own eMe, showing the world what you can do. That can get you a better job, at the very least.

You will stand out if employers see that you run your own Web site with your own domain. The proof is right there in front of them.

You’ll also learn more about the Web. You can add “manage Web sites” to your résumé, along with “create Web pages.”

Here are some approximate price comparisons:

  • One month of Web hosting = a meal at McDonalds.
  • One month of Web hosting = a pack of cigarettes.
  • One month of Web hosting = a movie rental.
  • One month of Web hosting = a coffee at Starbucks. No cookie, though.
  • One month of Web hosting = a magazine.
Renata
Renata

OK, now that you put it that way. I guess I can skip a small vanilla latté now and then.

Dedicated hosting

Web sites that need lots of power run on dedicated servers. That is, the site has its own computer. The hosting company maintains the computer – connects it to the Internet, keeps it running, backs up the data, etc.

The main difference between shared and dedicated is that dedicated hosts can support many more concurrent users without slowing down. “Concurrent” means “using the server at the same time.” Further, since you’re the only site on the computer, no other sites can interfere with yours.

Dedicated hosting starts around $200 USD per month, depending on the options you buy. For example, the more memory on your server, the more it will cost you (but the faster your Web site can run).

Virtual dedicated hosting

This is a hybrid of the two previous options. You share a host, but your account is configured so that it acts like a separate computer. You’re usually guaranteed to get certain performance from your server. Such-and-such processing speed, such-and-so memory, and so on. These services start around $40 USD per month.

If shared hosting is too slow, but dedicated hosting is too expensive, consider virtual dedicated hosting.

Of these options – shared hosting, dedicated hosting, and virtual dedicated hosting – you want to go with shared hosting to start with. It’s cheap, and Cheap is Good.

Choosing a hosting company

Choose a hosting company based on:

Price

Make this low, but not necessarily the lowest. You usually get a discount if you pay yearly.

Reputation

I’ve been burned by a company that went out of business. I ended up losing a domain name. Not fun.

I also had a site that stopped working because of a hardware failure. It took the hosting company more than a week to fix it. I wasn’t pleased with that company, either.

Choose a hosting company with a good reputation. Particularly for customer service. The company should have support people available around the clock.

One place to read hosting company reviews is ClickFire. They seem to be honest. In fact, Joe Eitel wrote an article Is Clickfire the Only Honest Web Host Review Site?.

Features

Most companies offer more-or-less the same features on their shared accounts. They differ in the limits on their accounts. Look for:

  • Lots of server disk space. At least 200 megabytes (MB).
  • Lots of transfer. This is the amount of data that people can download from your site, without you being charged extra. A few gigabytes (GB) per month is good.
  • Email accounts. Make sure you can have twice as many as you think you’ll ever need.
  • PHP and Perl. Server-side programming languages.
  • Database server. MySQL is the most common. Make sure you get to create at least 10 databases.
  • Multiple sites per account. This means you could run several Web sites on the same account without paying extra. Each site will have its own domain name. Maybe one for you, one for your human, and one for your Webcomic. Look for at least three at no extra cost.

What does CoreDogs use?

CoreDogs runs on Hostgator. Their customer service is good. Security, backup, and other things are also done well.

You can buy a Hostgator account by clicking here:

Buy hosting

If you buy hosting using this link, CoreDogs gets a referral fee.

Either the Hatchling or Baby plans would work. The Hatchling plan is cheaper, but it only gives you one site per account. You will need to upgrade if you want more than one.

At the time I’m writing this, you can get a Hatchling plan for under $5 USD per month. Come on! That’s really cheap! How can you afford not to do this?

You can register a domain name during the buying process. Hostgator will set it up and link it to your account. Choose a domain name before you sign up, with a backup in case the one you want is taken. They’ll send you information on uploading files to your account. More on how to do that in the next lesson.

You don’t have to use Hostgator. An account with any reputable company should work fine. But make sure you check out the hosting company before buying. Really! It’s worth a little research.

What are you waiting for?

Well? What are you waiting for?

Get out your credit card. Or use your PayPal account. Buy a hosting account. Now!

Many, many, many people have their own Web sites. Thousands of regular, non-geek people have their own Web sites.

Now it’s your turn. If so many people can do it, so can you. And you have CoreDogs to help.

It’s the best investment you can make in your Web future.

Summary

In this lesson, you learned:

  • You need your own domain name and Web presence.
  • What you get when you “buy hosting.”
  • That there are different kinds of hosting.
  • What features to look for from a shared hosting plan.

Most important of all, you bought your own hosting account, and your own domain name.

You did, right?

What now?

In the next lesson, you’ll create a simple Web page about yourself. It will live on your own computer to start with. But then you’ll upload it to your server. This is the start of your eMe site.

eMe: Your first home page

Where are we?

You bought a hosting account. Now it’s time to add a home page.

This lesson’s goals

By the end of this lesson, you should:

  • Understand the information your hosting company sent you.
  • Be able to copy-and-paste HTML for your home page, and change it (a little) for your needs.
  • Be able to upload the home page to your server.
  • Be able to access your home page with your browser.
  • Be able to set up an email account on your domain.

Understanding your hosting account

When you bought your hosting account, you entered your email address. You got emails from your hosting company, telling you how to use your account. So let’s start doing some stuff.

Er, you did get a hosting account, right? If not, click this:

Buy hosting

If you buy hosting using this link, CoreDogs gets a referral fee.

OK, I’ll stop nagging now.

Here’s part of the email I got when I signed up with Hostgator:

Email from hosting company

Figure 1. Email from hosting company

(1) is the domain, like doomdogs.com. Remember that the domain name is really an alias to the IP address of your server, shown in (4). As we discussed earlier, DNS servers, also called name servers, help Web browsers make the connection between domain names and IP addresses. It can take a few days for new domain registrations to “propagate,” or reach all of the Internet’s DNS servers. Until that happens, you can still reach your Web site using the IP address directly. That’s what (6) and (7) are all about.

Your primary name servers are shown in (5). You might need this information if you want to move your server to another host.

Have a look at the home page of your Web site. Use your domain name or, if you just set up your account and your DNS entry hasn’t propagated yet, use the link at (7).

What you see isn’t exactly what you want. Let’s fix that.

Making a home page

You first home page will just be plain HTML, with some CSS to add a little color. You’ll follow these steps:

  • Start up a text editor with a blank file.
  • Copy-and-paste some code I’ll give you.
  • Edit it to add your name and some other things.
  • Test the file in a browser.

OK, let’s get started. I’ll be doing everything with Windows. The steps are the same for another OS, but you’ll have a different editor and FTP client.

Starting a text editor

An HTML file is just plain text. You can create it with any editor that lets you create plain text.

Which one to use for this project? You could use Notepad, the editor that comes with Windows. But it’s…, well, not very good. Let’s try something else.

Download and install Notepad++. It’s free, and fairly good. When you really start learning HTML, I recommend you use something more powerful, like Netbeans (get the PHP bundle). But use Notepad++ for now. It’s easier to get started with.

The Notepad++ Web site can be a little confusing. Here’s a direct link to the download page. As I’m writing this, there’s a big green button with Download on it. Download the installer (the program that will install Notepad++), and run it.

CC
CC

Can I just use Microsoft Word?

Kieran
Kieran

No! No! A thousand times no!

HTML files are plain text. Word files are not plain text. Word inserts strange characters that can break Web pages.

Some programs do a decent job of converting Word text into plain text. But if you’re starting a Web page from scratch, you’re better off using a plain text editor.

Start by creating a directory for your project on your home computer.

You’ll be doing lots of CoreDogs projects. It’s best to create a separate directory for each one. This keeps all the related files together, and stops them interfering with each other.

On your PC, make a directory inside your home folder (e.g., My documents, or Documents) and call it coredogs. Inside the coredogs directory, create a directory called first-home-page.

Notice the names I suggested. We’re going to follow two rules for directory and file names in CoreDogs:

  • Lowercase
  • Separate parts of names with dashes

Remember that directory and file names on Unix servers are case-sensitive. Unix thinks that Myfiles and myfiles are different directories, and X.html and x.html are different files. Standard practice is to use all lowercase to avoid confusion.

Although you’re probably working on a Windows PC now, eventually you’ll upload everything to your server, which probably runs Unix. It’s best to prepare for that step now, by making directory and file names lowercase. Then you won’t have to go back and change things.

It helps readability to have names like first-home-page rather than firsthomepage. Spaces are allowed in file names (like first home page), but sometimes you have to follow special rules to handle them. It’s easiest to avoid the issue all together, and use dashes instead of spaces.

Many people use underscores (_) instead of dashes (-) in Web work. So why do I recommend dashes in directory and file names? Because Google prefers it. This might make your pages easier for people to find.

Start Notepad++. Type “Hi!” and save your work into the file index.html in your project directory. This isn’t HTML yet, but it will be.

Hi!

Figure 2. Hi!

index.html is the default file name servers use when a URL doesn’t include one. That makes it the best name for a home page. We talked about this earlier.

Now open the file in a browser. How? The way I normally do it is to double-click the HTML file.

Open the file

Figure 3. Open the file in a browser

My PC uses Firefox as its default Web browser. You should download Firefox and install it. I recommend making Firefox your default browser, though you don’t have to.

Another way to open a file in your browser is to use File | Open in your browser’s menu.

When you’ve loaded the file into your browser, you should see something like this:

Hi from the browser

Figure 4. Hi from the browser

Now let’s change that to real HTML.

Adding the HTML

In Notepad++, delete “Hi!” Then copy the code below into your file.

<!DOCTYPE HTML PUBLIC 
    "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" 
        content="text/html; charset=utf-8">
    <title>[Full Name]'s Home Page</title>
    <style type="text/css">
      body {
        font-size: 14px;
        font-family: Verdana, sans-serif;
        background-color: #FFFFFA;
      }
      h1 {
        color: #660000;
      }
    </style>
  </head>
  <body>
    <h1>Welcome</h1>
    <p>I'm [Full Name]. I'm a [student, mother, cook, and dog lover].</p>
    <p>I'm learning to be a Weber. A Weber is someone who gets paid
    to work on Web sites. I'm a beginner, but learning fast.</p>
    <p>There's not much on this page right now. But as I learn more, 
    this site will have some cool stuff on it.</p>
    <p>I'm learning with <a href="http://coredogs.com/">CoreDogs</a>.</p>
  </body>
</html>

Figure 5. Code for your page

To copy the code, put your mouse anywhere on the code, and a toolbar will appear in the upper right:

Figure toolbar

Figure 6. Toolbar

Then choose the copy icon.

Copy code

Figure 7. Copy code

Paste into Notepad++.

You need to make a few changes. Replace the text [Full Name] with your name. Replace the description list ([student, mother, ...]) with whatever applies to you.

You can keep or delete the CoreDogs link. If you want to get rid of it, delete line 27.

Save the file, and look at it in your browser.

W00f!

Uploading to your server

There are various ways to get files from your computer to your server. The most common is to use FTP. FTP stands for file transfer protocol.

Let’s think back a moment. Recall that when you use the Web, you use the HTTP protocol. You have an HTTP client (a Web browser, usually) that works with an HTTP server (like Apache).

HTTP client and server

Figure 8. HTTP client and server

FTP is similar. There’s an FTP client running on your computer, that interacts with an FTP server.

FTP client and server

Figure 9. FTP client and server

Usually, the FTP server software is on the same computer as the Web server software. So when you use FTP to upload a file to the server computer’s disk, it’s available to your Web server.

FTP and Web server on the same computer

Figure 10. FTP and Web server on the same computer

There are other protocols that do the same job as FTP. The most common are SCP and SFTP. They work more-or-less the same as FTP.

So, here’s how a Weber publishes a page to a site.

Publishing a page

Figure 11. Publishing a page

The Weber creates a file on his/her computer, and uploads it to the server (1). The server stores the file on its disk drive (2).

Later, a user clicks on a URL that maps to the file. The server grabs the file (3), and sends it to the user (4).

Get an FTP client

Time to install an FTP client program. Let’s use WinSCP. It’s good, and free.

Download and run the WinSCP installer program. If it asks you what type of interface to use, select the Commander interface.

Start up WinSCP. You’ll need to establish a connection to your FTP server before you can upload anything. Start a new session, and let’s fill in the connection information.

FTP login

Figure 12. FTP login

Type the address of your host in (1). For Hostgator, that is usually just you domain name. For other hosts, it might be ftp. and your domain name, like ftp.mysite.com.

Type your user name and password in (3) and (4). They’re from your welcome email, the one we saw in Figure 1. Here it is again. (The user name and password are items 2 and 3 in this figure.)

Email from hosting company

Figure 1 (again). Email from hosting company

The protocol in (5) should be FTP. Leave the port (2) alone, unless you have instructions otherwise. You can save your connection information at this point, if you want to make it easier to connect later. But don’t do this on a public machine! Only on one that’s physically secure.

Click Login when you’re ready to connect.

You’ll get a split screen:

FTP client

Figure 13. FTP client

Drag files from left to right to upload (from your local computer to your server). Drag from right to left to download (from your server to your local computer). You can drag entire directories, if you want.

Remember the concept of a Web site’s root? That’s the directory on a server’s disk drive that corresponds to the root of a Web site. So the Web root for doomdogs.com might be /sites/dd/. If you want to make a Web page available on the Internet as http://doomdogs.com/firefly.html, you would copy it to /sites/dd/firefly.html.

When the FTP client first connects, it usually doesn’t show you your Web root. It shows the files one level above the Web root (or maybe some other location entirely). Hostgator and most other hosting accounts work this way.

FTP root versus Web root

Figure 14. FTP root versus Web root

Now, you want to put your files into the Web root, which is public_html. The www in the figure is a shortcut to public_html, called a “symbolic link” in Unix. They both point to the same place.

Double-click on public_html or www. This will show the contents of that directory in the right-hand pane.

Now, in the left-hand pane, navigate to where you stored the file you created on your computer (index.html).

Then upload the file index.html to your server. Drag from the left and drop on the right.

Look at your home page in your browser

Type your domain name into your browser, like http://a.com. You should see your home page. In fact, everyone can now look at your home page.

Major w00f, with w00f sprinkles!

Set up an email account

Let’s do one more thing before we end the lesson: set up an email account.

This doesn’t involve FTP, so you can close WinSCP. Instead, we’ll use your Web site’s control panel.

The control panel is a Web page that makes it easier to manage your Web site. The URL of your control panel came in the welcome email from your hosting company. It might be something like http://doomdogs.com/cpanel. Go to the URL, and enter your user name and password.

There are about a bazillion buttons on a typical control panel. They’re organized into groups. One of the groups is about email. Here’s a typical one.

Email control panel

Figure 15. Email control panel

Click the icon “Email accounts.” You’ll see a form to add an email account.

Add an email account

Figure 16. Add an email account

You can create email accounts for your friends, family (including humans), even for your Evil Twin.

Your account includes Web mail applications that let users read and send mail. How users do it will depend on your hosting company. For Hostgator, if your domain is evilplatypus.com, your email users can check their accounts at http://evilplatypus.com/webmail. They will need to use their fully qualified email addresses to log in, that is, “bill@evilplatypus.com” and not just “bill.”

Again, this is for Hostgator. Other companies do things differently.

Summary

In this lesson, you:

  • Learned how to use the information your hosting company sent you.
  • Created your first home page by copy-and-paste.
  • Uploaded your home page to your server.
  • Accessed it through a browser.
  • Saw how to set up an email account.