This page is an overview and introduction to basic Web programming concepts. Before diving in, please read Web Development first.

More Web programming topics are available at Web Client Programming and Web Server Programming.

First steps[edit]

To get started with basic Web programming, all that is needed is a Web browser and a text editor. Since it's possible to implement an editor within the browser (I'm using one now), technically all you need is the browser.

Try this on for size:

Open up your text editor.
Make a New File.
Type in (or paste) the code in the box below.
Save the file, giving it a name ending in ".html" Remember where you saved the file (that is, the path to the file.)
Open the browser.
In the browser's address bar, type: 'file://[path-to-your-file]' - replacing the stuff in brackets with the path and name of your .html file.
You have now successfully written and run a program! Congratulations!

Once you have written your program and seen it run, you might want to make some changes. Just edit the text file, save it, and hit Refresh in your browser, and you will see the changes you've made.

 <!DOCTYPE html>
 <html>
 <head>
 <script language="javascript">
      alert("Hello World! I'm an annoying Alert Box!");
 </script>
 <body>
 <p>I promise not to use alert() any more in these examples. It's terrible!</p>
 </body>
 </html>

That's a pretty basic program- it doesn't do much. To do more sophisticated programming, it's useful to have a collection of further tools.

Programming Tools[edit]

Editor[edit]

While a basic text editor is enough to get the job done, more powerful ones offer useful features. I like Bluefish Editor. Beyond the simple programmer's editor is a large program or suite of programs called an Integrated Development Environment or IDE. Emacs and Eclipse are examples.

Shell[edit]

The shell is where you give commands to the OS. Windows started out as a shell for DOS; now it's a shell for an OS also called Windows. GNU/Linux has lots of shells. sh, tcsh, ash, Bourne, csh, bash, dash are all command-line shells. fvwm, twm, xmonad, GNOME, KDE, et al. are all graphical shells. This is drastically oversimplified but it doesn't matter- You don't have to install this, just know how to use it. For programming purposes the important thing about the shell is that it should:

Be scriptable;
Be able to background or multiplex tasks.

Scriptability is good but technically optional; it's mostly possible to do all your scripting in PHP or whichever language you are using.

Interpreter / Compiler[edit]

An interpreter is a program that reads your code and executes it.

Javascript is interpreted by your Web browser. A compiler takes your code and turns it into a stand-alone executable.

Compiled code runs faster but takes longer to write, due to the additional steps of linking and compilation between writing the program and running it. C and c++ are compiled languages, along with Pascal, Ada and Fortran. All of these are supported by gcc, the Gnu Compiler Collection. Web development is rarely done in compiled languages, although there are instances where pre-compiled libraries are linked or an entire site is done in a compiled language for speed.

Working in Groups: Other useful tools[edit]

Communication[edit]

Maillists, IRC, wiki, etc

Avoid meetings. They will eat your soul and sap your will to live.

Version Control[edit]

If you are working with just one or two other programmers you can get away with just using diff and patch. These tools are important to know in any case. If you are working with a larger group than that, you need version control.

Version control is a means of tracking changes to your code as they are made. A good VCS lets you know who made any given change and when it was made, as well as allowing you to roll back arbitrary changes. There are two main types.

Centralized VCS (AKA SCCM)

CVS is the granddaddy. It and it's descendants provide a centralized 'repository' where the code lives. When you want to work on a module, you 'check it out', which locks that part of the code so others can't make changes to it. When you are done you check it back in. Other centralized VCS include svn and Bazaar.

Distributed

Distributed VCS allow each developer to set up its own repository and tracks changes not only within the local repo but against other non-local ones. Decentralized VCS include Mercurial and git. Git is my favorite :^)

Infrastructure[edit]

Database[edit]

httpd[edit]

Connects via module or CGI to...

Language interpreter[edit]

Holy Cats, that's a lot to set up![edit]

Linux metapackages, i.e. 'ubuntu-lampserver'[edit]

XAMPP[edit]

Basics of programming[edit]

Best Practices. Learn them, know them, practice them.

For example: Separate data, logic and presentation!

Modularity is good, spaghetti code is bad.

DATA IS KING.

Most programs are about data. Think carefully about your data and its representation before you start coding. This will save you time and headaches in the long run. Make sure your data is well-structured before you start building logic to manipulate it.

Copious comments create comprehension.

Comment your code. When you start out in programming, make sure you over-comment. You'll feel foolish doing this. That is OK. Soon you will get a feel for what and where to put comments. Feeling foolish for over-commenting is much better than the feeling you get from looking over 2-month old code and realizing you have no idea what it does. Ask me how I know... What comments look like:

/*This is
  a multi-line comment.
  some people prefer to put
  the comment delimiters on a separate line like so:
*/

//This is a single line comment.
//Lots of short comments are a Good Thing.
//If you use a lot of them in a row, you might consider using the multi-line style...
//Or not. It's up to you.

Self-documenting code

Apart from comments there are other techniques to use to keep your code easy to read and understand.

Descriptive variable names. If you have a variable that tracks the number of computers you have on the shelf, don't call it 'x'; call it 'computersOnTheShelf' or something. A good programmer's editor will pick up on the variable names you use and autocomplete them for you, so there's no need to be a lazy typist. The exception here is 'i' for iterators- that's a convention, everyone knows what it means. If you want to use a descriptive name for your iterators, go ahead- there's no reason not to.
Descriptive module names. By "modules" I mean functions, classes, objects, attributes and methods. Each should represent or do something specific and well-defined, and its name and the names of any arguments should reflect that.
Docstrings. A docstring is a little 'manual' embedded in your program, callable by one of its methods. Write it first and you can use it to keep track of what this particular module does. If you find yourself changing the docstring to reflect features you want to add, consider putting those features in a different module instead.

Ba da bing, the whole #![edit]

Folks call it "shebang" Used in scripts that will be executed by the shell, indicates path to interpreter like so:

#!/usr/bin/python

Some languages are interpreted, some compiled. All languages covered in this class are interpreted.

Anyone care about the difference?

Mostly we won't care about shell scripts in this class. Client-side scripts are embedded in or called from webpages via <script> tag, server-side ones sometimes use different tags or invoked by server.