Deep Thought has recently given me some info on servers that Kerm suggested I share. Anyways, here it is.

DeepThought wrote:

Web design is absolutely the funnest thing I've ever done (it's blasphemy, but it's more fun than calculator game design because of the graphics involved).
LincolnB wrote:

So I have a couple questions for you: How do I get started? I've made a couple simple websites, and I'm familiar with HTML and a tiny bit of CSS and JavaScript. Everything I've made like that, however has been on a free hosting site like heliohost.org or something.

All right. In terms of importance, remember that HTML > CSS > JS. JS is an incredibly useful tool in a growing variety of places (GNOME even uses it as a basis for desktop scripting), but HTML and CSS should be at least 95% of your efforts. Just a tip.
LincolnB wrote:

What we want to do is host our own, with something like Apache and Ruby? I don't know a thing about either Apache or Ruby, I've just heard the terms used and I know Apache is a piece of server software and Ruby is programming language I've never heard anything bad about.

Here's the crash course on how the whole thing works.

You know how the Internet is basically a ginormous network of physically separated computers, right? Well, when a person (the "client") wants to access a webpage (which is really the same as any other text file, just prettied up by the browser), his browser sends an HTTP request (basically a text string that acts as a command) to the server where the site is hosted on.

First, it looks for the address of the server. That's the DNS's job; you don't need to know how it does it, but just know that it asks some server (called the "nameserver") what IP corresponds to the particular host. For example, if you're looking for http://clrhome.org/resources/, it would look up the address of "clrhome.org." (Since you've used a host before, I'll assume you know how nameservers work, but feel free to ask if you want more info.)

When it gets the address, it sends the request (for example, "GET /resources/"). Apache (a popular and free webserver program, available here) recognizes the request, interprets it, and figures out which file it points to (in this case, in %WEBROOT%/resources/index.php where %WEBROOT% is where the folder where that particular site is stored).

If that file is just an ordinary file (like an image or text file), Apache simply sends the content over the HTTP stream back to the client's browser. But if it's a script like a file for PHP, Ruby-on-Rails, JSP, or ASP, Apache runs it through the appropriate interpreter first. PHP and Ruby-on-Rails are both interpreted languages (like TI-BASIC, to draw an analogy) that are designed specifically for web applications. They allow you to manipulate the HTML first before sending it off—basically, they make possible dynamic content, form submission, site membership, and so on. (Of the vast array of webserver languages, by far the most popular is PHP).

In any case, the client doesn't know what goes on back there (someone could have take the HTTP request, fed it to the dog, and read letters out of the dog's feces for all the browser cares), but he gets a result and he sees it on his browser screen.

Anyway, that's how the thing works. What you would need to set up a website from scratch would be:
a domain name;
a DNS service (this is usually packaged with the domain name, but you can always use FreeDNS);
a server (any reasonably powerful computer running 24/7 would work);
a webserver management software (I recommend Apache running on some GNU/Linux distro); and
a web framework language (ASP, JSP, PHP, Ruby-on-Rails, and so on, but I recommend PHP even though it's an absolutely awful language simply because it's already pretty much standard).


Cheers
~ Deep Thought


So there ya go. I have a question too - if I want to program for my newly set-up server in Perl or Ruby, is using CGI scripts the only way to go, or is there a better option?
For certain definitions of 'CGI scripts', sure. Traditional CGI just involves the web server running a program, and redirecting its output to the client. This approach is pretty easy to set up, but it tends to be slow because every request to the server requires it to spawn a new process.

Newer approaches like FastCGI or WSGI involve the web server communicating with another long-running process that does substantially the same thing, but avoids the overhead of spawning a new process for every request.

Rails is a common framework choice for Ruby, and I'm not familiar with any for Perl, but they probably exist. What approach you take in terms of libraries/frameworks is usually determined by what you're trying to make.

I'm partial to Django and Flask for my web work, which are both Python frameworks.
I introduced second level quotes into the original post so it's easier to see the questions among the explanations. I was not able to add any missing links.
Phusion Passenger is what I use to deploy rails apps with Apache.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement