[PLUG] Ready for website creation tutorials

[Jon Scully]

CGI -- Common Gateway Interface is largely what it's name says: It's a
gateway between the server and the remote browser -- ok it's a common
way to interface a server with a browser.  In reality it's a
communication protocol, like, B: "hello?" S: "hi" B: "hey, can I get a
file?" S: "what's the secret password?" B: "I don't know!" S: "just
kidding... what file do you want?" etc.

GET sends the request (the answer to "what file do you want" at the
end of the URL. Ever notice [www.site.com], then
[www.site.com?file=42]? The '?' part is followed by one or more
key=value pairs, sent to the server.

POST -- does virtually the same as GET, but uses FORM fields, such as
<input type="text" name="file" value="42" />, etc.

Apache is one of the more common web 'servers'.  When you install
Windows or a Linux distribution on some hardware, you don't always get
a web server with the package.  To get a web server going you can
install Apache (or any number of others).  You know what a web browser
is.  So it's a lot like some Unix/Unix-like distribution that don't
have a browser, when first installed.  You have to pick one (Firefox,
Opera, lynx) and install it.  The diference is, a server (like Apache)
is often configured by changing text files, instead of clicking
buttons in an 'Options' window, like with a browser.

PHP / JavaSript -- correct.

Ruby is an interpreted language, similar to PHP.  It's the 'framework'
(Rails) that has probably caused a lot of the hype around the
language.  The 'framework' really consists of just software.  It
auto-creates code (RUby code) in very convenient ways, taking much of
the drudgery out of developing a web site.  If you learn just the
framework and don't leran the language, two things will happen: First,
it will be a very exciting trip, to begin with.  You'll wonder how you
created so much, so fast -- especially if you're used to using, say
PHP and haven't used one of its miriad 'frameworks'.  Next, you'll run
into many limitations; some small; some not so small.  Then you'll
realize (eventually) that you really need to learn more about Ruby so
you can get into the guts of Rails and make your web site what you
intended it to be.

What did Mark Twain say? "The longest distance between two points is a
shortcut."  I think it was he.

If you're a seasoned programmer, you'll appreciate Rails (because you
know you can drop down to the Ruby level at any time and start
tweaking code).  If you're a beginner, you'll appreciate Rails a lot
-- but the honeymoon will be over pretty quickly.

Server based is unavaoidable.  Web pages get 'serveed' from a server.
What is also meant by 'server based', however is if there's any logic
happening on your web site.  Any forms being filled out?  You can
checkl the validity of an e-mail address, for example, when the form
contents are submitted (server-based) using, say, PHP or before it is
submitted (browser-based) using JavaScript.  If you're going to store
any of the information in a database (even in a file), that's also
considered 'server-based'.  Look at www.tiddlywiki.com for an example
of a 100% browser-based application (no server-based code required).

Then there's AJAX.  It's about as perfect a tool for creating dynamic
content as it is difficult to get "right" -- whatever that is.  But
it's really a matter of bringing 'server-based' and 'browser-based'
closer together.  Instead of loading a web page and re-loading web
pages for every button pushed or link clicked, AJAX ficilitates
providing just the information the end-user need, just when they need
it -- without a whole-page re-load.

Sounds like the first and second pages may benefit from some of the
problems AJAX can solve.

OK, back to work I go...  Haven't answered all your questions, but
should be a good start.

Oh, and a final thought. "I have no intention of changing careers and
becoming a web designer."  Ha!  [thinks back, fondly, of a simpler time] ;-)

HTH