Web Programming

Setting Up

What You Need: A Programming Environment

Shell

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:

1. Be scriptable;
2. 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.

If you MUST use Windows

Install Cygwin or PowerShell. Steep learning curve, but well worth the effort.

Interpreter / Compiler

An interpreter runs when you run your code and executes it. A compiler takes your code and turns it into a stand-alone executable. Compiled code runs faster but takes longer to write. Hardly anyone does web development in compiled languages. This class will use PHP, a popular interpreted language originally developed for web programming, for all examples.

Editor

• Basic: gedit, kate, nano
• Full-featured: Bluefish, PHPEdit, or fancy IDEs like Eclipse
• Advanced: vim or Emacs

If you MUST use Windows

• DO NOT USE Notepad, it is broken. Notepad++ is free and better and should ship w/Windows (part of Sysinternals Suite)

Strongly recommended to install Sysinternals Suite (provided free by Microsoft) and Cygwin for development in Windows (among other things Cygwin provides a working SSH client. PuTTY is for masochists.)

HOLY WARS ARE BAD M'KAY

Working in Groups: Other useful tools

Communication

Maillists, IRC, wiki, etc

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

Version Control

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 :^)

What a Web Application Needs: Infrastructure

httpd

Connects via module or CGI to...

A quick look at programming

Why I made a big deal out of what HTML, CSS, JS are for

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.

1. 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.
2. 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.
3. 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 #!

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.

Client-server architecture

Client is usually a Web browser (but can be other program) Server will be called htppd (it's a daemon that serves HTTP requests)

• What's a daemon?

1. User invokes client, interacts with document, clicks something (i.e., fills out form, clicks Submit)
2. Client sends HTTPRequest containing client data to server (via GET or POST)
3. Server passes client data to scripting engine
4. Script engine opens connection to database, sends CRUD instructions and data
5. Database sends response to script engine
6. Script engine uses data to construct HTML document, sends same to server
7. Server sends HTML document via HTTPResponse to client
8. Client formats and displays document

Ta-da!