In the last tutorial you set up your development environment.  Now it's time to actually start coding.  The first thing you need to know to build a website is how websites actually work.  I'll start with an overview, then I'll give a brief summary of some important HTML tags, and then we'll dive into the actual code.

In this tutorial, we're just going to deal with HTML.  We'll get to the other ones in future posts, but HTML is the programming language that defines the most basic and important aspects of a website: the content.

So what is HTML?  It stands for "Hypertext Markup Language" and it's really just a system that lets you tell a web browser what should be included in a web page.  HTML is made up of "tags" which are basically reserved words that mean special things to a web browser.  I'll go over the most common tags later on.

Probably the biggest misunderstanding about HTML (and websites in general) is where the code is actually running.  HTML is really just text that is sent to a web browser.  So when you go to www.yahoo.com, yahoo sends you back a file with plain text.  That file uses HTML tags to tell your browser what the website should look like.  The main takeaway here is that HTML does not run on the server.  It's nothing more than text that your computer interprets to create a webpage.

There's a lot to learn about HTML, but there's no better way to learn than getting your hands dirty.  Keep in mind though that I'm not really giving you an complete lesson here, so there will be holes that you'll have to fill later as you come across new problems.

Ok, so like I said, HTML uses tags.  A tag starts with a "less than" sign (<) and ends with a "greater than" sign (>).  For example, a paragraph tag looks like this: "<p>".  Most tags need to be closed with a similar tag starting with "</".  So to write a paragraph of text, you'd type:

<p>This is the sample text</p>

This same format is used for any HTML element that can contain other things inside.  This might be confusing, but it will make sense soon enough.

Tags can also have attributes.  Attributes are included in the opening tag.  There are lots of different types of attributes, but just as an example, here's what a paragraph tag looks like if you want to use the "style" attribute to make the text color red, and the "align" attribute to center the text:

One more thing about tags.  Some tags don't need to be closed.  The reason you need to close a paragraph tag is because there is text inside and the browser needs to know when the paragraph is finished.  Some tags don't have any content inside, so you treat them a little different.  For example, the line break tag goes to a new line (like hitting "enter" in a text editor).  Because it just goes to the next line and that's the end of it, line break tags are written like this: "<br />".

Notice that instead of having a closing tag, there's a "/" at the end.  That tells the web browser not to look for a closing tag.  That slash isn't actually required, but it's considered good practice to use it.

Ok, so that might not have made any sense, but keep reading anyway.  Here are some of the common tags.  Once again, this won't make sense until we get to the code, but you'll want to refer to this list when you forget something:

• <p></p> - create a paragraph of text
• <h1></h1> - this is the headline tag.  Text inside will be very large.  There's also h2 through h5 tags for smaller headline text. 
• <br /> - this starts a new line of text.
• <div></div> - This is a pretty complicated element, but for now, think of it as a generic wrapper to put around things.  I'll explain this more in some other tutorial.
• <table></table> - If you need to make a grid, use a table just like you would in Word
• <tr></tr> - "Table Row" - this tag opens rows inside of a table
• <th></th> - "Table Header" - this tag opens a cell which will be the header of a column in a table
• <td></td> - "Table Data" - this is just a normal cell in the table
• <img /> - This includes an image file in your html
• <a></a> - The "anchor" tag is how you create hyperlinks to other pages and websites.

Ok, so how do we set up the table?  Tables are defined one row at a time, so you'll need to first make the table open and close tags.  Then add seven opening and closing "tr" tags.  This creates the seven rows.  The first row will be headers, which are defined with the "th" tag.  So inside the first "<tr></tr>", put seven "<th></th>" tags with the day of the week inside.

I'm going to stop here because I think this tutorial is already too long.  This calendar is obviously very basic, but we'll improve on it later.  In the meantime, feel free to play around with the HTML on your own.  Try to use online resources to figure out how you can use attributes to change how this calendar looks.

As always, post questions in the comments and I'll do what I can to help.

If I stop working on my fantasy football site and start working on the calendar, I would change this line to:

Then I'd restart all WAMP services.  You can also use an ".htaccess" file to set the include path so you don't have to ever go into php.ini, but I don't bother doing that.  Do a Google search if you want more info on that technique.

So to summarize, here's what we just did:

• Declare the URL for each project in the hosts file
• Create a folder for each project in C:\wamp
• Create a configuration file in C:\wamp\alias and enter Virtual Host information for each project
• Set the include_path variable in php.ini to point to whichever project folder you're currently working on.

As you know, one reason that I really like web applications is because they can be updated without the end user's involvement.  Even though desktop apps are inherently disadvantaged in this regard, that doesn't mean that the developers should just give up and accept a negative user experience when updates are required.

Mozilla Firefox is the second most popular web browser out there.  There are a lot of great things about Firefox, but a few really poor decisions make using it seem like a chore.  I hate to say it, but I sometimes find myself using Internet Explorer instead of Firefox if I'm in a hurry.  The worst decision they made has to do with installing updates.

If you had to pick the worst time imaginable to download and/or install updates, what would that be?  It seems obvious to me that it's when the user first launches a program.  If I don't have a program open, and then I open it, I think it goes without saying that I want to use it for something.  This is the only moment in the entire user experience where you're guaranteed that I want to actually use the software.  This is the wrong time to bug me about updates.

So why is this the time that Firefox installs all the updates?  Why not when I close the program? Why not have a helper program like many newer apps (like chrome) that installs updates behind the scenes?  I am almost afraid of starting Firefox because I know there will be an update waiting for me which will require me to install the update and restart the browser before I can do whatever it is that I actually want to do.

This problem is made even worse by the extensions.  I realize that I chose to install all of my Firefox plugins, but can't they let me start my browser without prompting me about a foxmarks update every single time?  I just want to go to a website.  That's what web browsers are for.

And then the cherry on top of all that is how Firefox takes me to a different home page after every update to tell me about the update.  Why in the world would I care?  I opened Firefox to go to a website, not to spend 5 minutes installing updates and then feeling proud about my accomplishment with a special confirmation page.

So here's a new design principle for you.  If you need to make a decision, think about the worst possible solution, and make sure you do something other than that.  Firefox might still be my browser of choice if they followed that basic advice with the timing of their updates.

I'm not the type of person to care too much about titles.  If someone tells me they're the director of national accounts at a five person company, I'm not particularly impressed.  However, titles are a useful way to quickly summarize one's job, so I have some interest in getting them right.

That said, one of my main job roles is "web developer".  This should be a pretty accurate way for me to describe myself when others ask what I do.  The problem is that 10 years ago, web developers made websites with pictures of their cats and lots of flashing, scrolling, comic sans text.

Despite the widespread adoption of web applications like gmail, people still think that "real" programs aren't online.  Good programmers don't make websites, they make boring old windows applications.  If I majored in computer science and now I build online applications, I must be the most pathetic CS major ever.

When someone asks me what I do and I say I'm a web developer, they respond with something like, "oh yeah, my cousin has Dreamweaver and made her own website.  Cool".  So instead I have to say something needlessly vague like "application developer" or "software engineer" or just boring old "programmer".

These titles aren't nearly as useful as "Web Developer" but they communicate to people that I actually write real code which I guess is more informative than only communicating that I deal with websites.

So in case you didn't already know, the times they are a-changing and there are real applications hosted online these days.  If someone develops web applications, there's no reason to believe that they are any less of a programmer than someone working on a more traditional desktop app.  And if you ask me what I do and I say I'm a web developer, please don't assume that I spend all day making celebrity-themed Myspace templates.

/end rant

I've mentioned this before, but I want to really focus on this entrepreneurial dream of "The Perfect Idea".  I know a lot of people that think they may one day start their own companies but they're waiting to have a great idea to build the company around.  Here are some core beliefs that I have regarding this:

Very few cool tech start-ups were founded on a great business idea.  The great ideas like Google Adwords, social networking, etc. all evolved out of stupid (or at least misguided) ideas.  Why?  Because it's nearly impossible to have a good idea about something that you're not familiar with, and you can't get familiar with an industry without starting to work in it.

Even if you do have a once in a lifetime idea, you're going to botch the implementation if you're waiting to become and entrepreneur.  If you spend the first ten years after college working at a giant corporation and then you have a brilliant idea, you'll have to learn how start-up companies work as you're trying to execute the idea.  It would be a shame to waste such a brilliant business model on your practice round.

Even if there is a perfect idea out there, and even if you do think of it yourself, there are people out there already working in that industry.  They're building infrastructure, learning about the market, and gaining valuable experience.  Those people will almost always beat the people that are sitting around waiting for an idea.

Blogging offers a great example of this.  Sometimes I sit around for hours trying to figure out what to write about.  Eventually I give up and start working on an old idea that I'm not wild about (like this post, to be honest).  The second I start typing, I come up with tons of new topics.  In the time I've been writing this post, I added six new documents to my "drafts" folder with topics way more interesting than this one.  But if I hadn't started this post, I never would have thought of the new ideas.