You will need to have access to both a Windows workstation and a Linux workstation with X windows installed, to proceed with this tutorial.  If you do not have a Linux machine handy then download a copy of Virtual Box and build yourself a virtual machine that runs your favorite flavor of Linux. I personally like Fedora, CentOS, and Ubuntu in that order, but ultimately it doesn’t matter which distro you choose.

To get started, first download and install Xming.  If you don’t already have a SSH client installed, then also download and install PuTTY.

Now open up Xlaunch from start, all programs, Xming. Choose multiple windows for this test and click next. Start no client, then click next. Leave clipboard checked and click next. If you want to save this config then click Save configuration, then click finish.

Now open PuTTY. Type the host name or IP address into the top space provided.  Make sure SSH is selected if not select it. Under Saved sessions type a name to lable this connection, and click save. Now in the menu on the left click SSH. Check Enable compression.  Now click the plus sign next to SSH in the left hand menu. Click X11, and check mark Enable X11 forwarding. On the menu scroll back up to the top and click Session. Click Save once more to keep the settings we just made changes to. Now click Open and log into your linux machine with your user name and password.

After you have successfully logged into your linux machine, type the name of a graphical program you like to use. Examples of such are “firefox”, “kwrite”, and “konqueror”.  If you are unsure what the command is for your app I recommend doing a google search for it.

here are some more gui apps that can be launched.

startkde – opens a full view of the desktop with menus and desktop items. (this one has proved unstable in my tests)

firefox – opens the firefox browser.

ktorrent – opens the ktorrent bittorrent app

konqueror – opens the konqueror web / file browser

most gui apps will open by simply typing the name of the app and pressing enter.

# yum install subversion

Setting up Install Process
Setting up repositories
update 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package subversion.i386 0:1.1.4-2.ent set to be updated
--> Running transaction check
--> Processing Dependency: libneon.so.24 for package: subversion
--> Processing Dependency: libswigpy.so.0 for package: subversion
--> Processing Dependency: perl(URI) >= 1.17 for package: subversion
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package neon.i386 0:0.24.7-4 set to be updated
---> Package swig.i386 0:1.3.21-6 set to be updated
--> Running transaction check
--> Processing Dependency: perl(URI) >= 1.17 for package: subversion
--> Processing Dependency: libqthreads.so.12 for package: swig
--> Processing Dependency: libguile.so.12 for package: swig
--> Processing Dependency: libguile-ltdl.so.1 for package: swig
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package guile.i386 5:1.6.4-14 set to be updated
--> Running transaction check
--> Processing Dependency: perl(URI) >= 1.17 for package: subversion
--> Processing Dependency: umb-scheme >= 3.2-21 for package: guile
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package umb-scheme.i386 0:3.2-36.EL4 set to be updated
--> Running transaction check
--> Processing Dependency: perl(URI) >= 1.17 for package: subversion
--> Finished Dependency Resolution
Error: Missing Dependency: perl(URI) >= 1.17 is needed by package subversion

And instead of yum being smart enough to find that dependency, it just ends. That’s it. There ain’t no more. And no search, upgrade or gentle persuasion will change it’s mind. So, first we get the annoying dependency that it refuses to get:

# wget http://rpmfind.net/linux/fedora/releases/7/Everything/x86_64/os/Fedora/perl-URI-1.35-3.noarch.rpm
--10:20:17--  http://rpmfind.net/linux/fedora/releases/7/Everything/x86_64/os/Fedora/perl-URI-1.35-3.noarch.rpm
Resolving rpmfind.net... 194.199.20.114, 195.220.108.108
Connecting to rpmfind.net|194.199.20.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 118607 (116K) [application/x-rpm]
Saving to: `perl-URI-1.35-3.noarch.rpm'

100%[= ... ============================>] 118,607      214K/s   in 0.5s   

10:20:18 (214 KB/s) - `perl-URI-1.35-3.noarch.rpm' saved [118607/118607]

That version works for CentOS 5, which is what we use. If you have another version, just find the RPM from rpmfind.net. Once that’s downloaded, you just rpm install it:

# rpm -i perl-URI-1.35-3.noarch.rpm
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found/.*.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/\.journal.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/lost\+found.
warning: perl-URI-1.35-3.noarch.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2

The warning doesn’t affect anything that I can tell, so it’s installed and we are now ready to install subversion through yum again!

# yum install subversion
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
 * base: mirror.trouble-free.net
 * updates: www.gtlib.gatech.edu
 * addons: mirror.trouble-free.net
 * extras: mirror.trouble-free.net
Excluding Packages in global exclude list
Finished
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package subversion.i386 0:1.4.2-2.el5 set to be updated
--> Processing Dependency: libneon.so.25 for package: subversion
--> Processing Dependency: libapr-1.so.0 for package: subversion
--> Processing Dependency: libaprutil-1.so.0 for package: subversion
--> Running transaction check
---> Package apr-util.i386 0:1.2.7-7.el5 set to be updated
--> Processing Dependency: libpq.so.4 for package: apr-util
---> Package neon.i386 0:0.25.5-5.1 set to be updated
---> Package apr.i386 0:1.2.7-11 set to be updated
--> Running transaction check
---> Package postgresql-libs.i386 0:8.1.11-1.el5_1.1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 subversion              i386       1.4.2-2.el5      base              2.3 M
Installing for dependencies:
 apr                     i386       1.2.7-11         base              122 k
 apr-util                i386       1.2.7-7.el5      base               76 k
 neon                    i386       0.25.5-5.1       base               95 k
 postgresql-libs         i386       8.1.11-1.el5_1.1  base              196 k

Transaction Summary
=============================================================================
Install      5 Package(s)
Update       0 Package(s)
Remove       0 Package(s)         

Total download size: 2.8 M
Is this ok [y/N]: y
Downloading Packages:
(1/5): apr-1.2.7-11.i386. 100% |=========================| 122 kB    00:00
(2/5): neon-0.25.5-5.1.i3 100% |=========================|  95 kB    00:00
(3/5): apr-util-1.2.7-7.e 100% |=========================|  76 kB    00:00
(4/5): subversion-1.4.2-2 100% |=========================| 2.3 MB    00:01
(5/5): postgresql-libs-8. 100% |=========================| 196 kB    00:00
...
  Installing: apr                          ######################### [1/5]
  Installing: neon                         ######################### [2/5]
  Installing: postgresql-libs              ######################### [3/5]
  Installing: apr-util                     ######################### [4/5]
  Installing: subversion                   ######################### [5/5] 

Installed: subversion.i386 0:1.4.2-2.el5
...
Complete!

And we are done! subversion is installed in spite of yum’s inability to find the appropriate rpms!

If you look through the package, you will see that it already has quite a bit of functionality built in. In fact, it really has most everything you would need to automate the web hosting process. However that’s not enough for us, we want more!

The first thing we are going to want to edit is the new subroutine in the Accounting package. You can see it is stubbed out already:

sub new {
    my ($host);
    my ($user);
    my ($accesshash);
    my ($error);
    my ($usessl);
    my ($timeout) = 300;
    my $self = {};

    bless($self);

    return ($self);
}

This function is going to need to establish 4 things that we will use for the API calls. First, a host name. Simple enough. Second, a user. Generally, this is root, though it can be just about anyone with WHM access. Third, an accesshash. This can be found in the user we specified’s home directory in a text file called .accesshash. If one doesn’t exist, login to WHM through the web interface (https://yoursever:2087/ and goto the remote access hash link and it will generate and create said text document. Finally, we need to know whether or not to use SSL to communicate. There are very few times when you want that to be no.

My changed new subroutine looks something like this:

sub new {
    my $class = shift;
    my $name = shift;
    my $user = shift;
    my $accesshash = shift;
    my $usessl = shift;
    my $self = {
       host => $name,
       user => $user,
       accesshash => $accesshash,
       error => "",
       usessl => $usessl,
       timeout => 300
    };
    bless($self, $class);
    return ($self);
}

This is an overly simplified example of a possible solution. In my production code, I use a Class::DBI based class to pull the info I need from a database and pass it into here where this subroutine extracts the information it needs. Pretty easy, isn’t it?

Next we create a stub program to use the package we just edited.

#! /usr/bin/perl -w

use lib "/usr/local/hsw/libs/";
use C::Accounting;
use Data::Dump;

my $name = shift @ARGV || "server1";
my $func = shift @ARGV || "listxmlapps";

open(AHASH, "/root/.accesshash");
my @access = ;
close AHASH;
my $accesshash = join("\n", @access);

my $whm = C::Accounting($name.".mydomain.com", "root", $accesshash, 1);
print "Running ".$func." on ".$name." with ".join(" ", @ARGV)."\n";
my $t;
eval '$t = $whm->'.$func.'(@ARGV)'; # If you have a better way of doing
                                    # this, please let me know!
if($@) { print "ERROR : ".$@."\n"; }
if($s->{error} ne "") { print "ERROR : ".$s->{error}."\n"; }
Data::Dump->dump([[$t]]);

So here we take the first two arguments passed in on ARGV, and assign them to the host and a function for us to run on it. We get the access hash from root’s home directory then we create an Accounting object. I use eval to run the function that was passed in on Accounting object and pass it in what is left in ARGV, if anything. We do some error checking and display them if they exist, then I used Data::Dump to result to the screen. Simple, but it gives us what we need to see the API at work.

If we run this from the commandline, we get something like this:

-bash-3.2# ./testnsclient
Running listxmlapps on server1 with
(
  "C::Dump",
  [
    [
      {
        app => [
                 "adddns",
                 "addip",
                 "applist",
                 "delip",
                 "dumpzone",
                 "fetchsslinfo",
                 "gethostname",
                 "getlanglist",
                 "killdns",
                 "listacls",
                 "listcrts",
                 "listips",
                 "listzones",
                 "loadavg",
                 "lookupnsip",
                 "myprivs",
                 "nvget",
                 "nvset",
                 "passwd",
                 "reboot",
                 "restartservice",
                 "sethostname",
                 "setresolvers",
                 "version",
               ],
      },
    ],
  ],
)

By throwing in a few arguments, we run a different function:

-bash-3.2# ./testnsclient server1 loadavg
Running loadavg on server1 with
(
  "C::Dump",
  [[{ fifteen => "0.14", five => "0.18", one => "0.17" }]],
)

So awesome! Now what if we want to expand on this to do something cPanel doesn’t natively do? Suppose we wanted more information than what the loadavg command just gave us? Well, we need to goto the cPanel server itself. We navigate to /usr/local/cpanel/whostmgr/docroot and create a directory in there for our functions. We could create files directly in the docroot, but we don’t want our stuff interfering with cPanel’s, nor vice versa. I called mine hsw. In there, let’s create a file called load.cgi and put this inside:

#! /usr/bin/perl -w

use strict;
use CGI;

my $q = new CGI;
print $q->header();
open(ME, "|-", "cat /proc/loadavg");
while()
{
  print $_;
}

Chmod the file to be 755 and run it, it gives this:

-bash-3.2# ./load.cgi
Content-Type: text/html; charset=ISO-8859-1

0.28 0.18 0.15 2/96 12631

Great! So that works. Now we head back to our C::Accounting package and we add a function to handle this new functionality.

sub load
{
    my ($self) = @_;
    my (%PKGS);

    my (@PAGE) = $self->whmreq("/hsw/load.cgi");

    if ( $self->{error} ne "" ) { return (); }

    foreach $_ (@PAGE) {
        s/\n//g;
        my @contents = split(/\s/, $_);
        $PKGS{"1min"}    = $contents[0];
        $PKGS{"5min"}    = $contents[1];
        $PKGS{"15min"}   = $contents[2];
        my @procs = split(/\//, $contents[3]);
        $PKGS{"running"} = $procs[0];
        $PKGS{"total"}   = $procs[1];
        $PKGS{"lastPID"} = $contents[4];
    }
    return \%PKGS;
}

So we run the subroutine whmreq with the path to our script as an argument. We are given back an array of lines that were returned. We simply parse that out and assign the information to appropriate indexes in a hash table. We then pass the reference of the hash back. By running our stub-app, we get the following:

-bash-3.2# ./testnsclient server1 load
Running load on server1 with
(
  "C::Dump",
  [
    [
      {
        "15min" => "0.10",
        "1min"  => "0.07",
        "5min"  => "0.13",
        lastPID => 21897,
        running => 1,
        total   => 89,
      },
    ],
  ],
)

Well, that gives you the basics you need to expand the capability of cPanel/WHM’s API to include your own functionality and subroutines. Now you can get your cpanel/WHM boxes, even the DNS Only versions, to do anything that perl can do… remotely and programmatically.

This is a very powerful tool, use it wisely.

print "This is line one!\n";
print "This is line two!\n";
__END__
print "This is like three but is never executed\n";
this doesn't even have to be code cause
it never gets interpreted as code.

Run that and you will get:

% ./test.pl
This is line one!
This is line two!
%

As you can see, the __END__ directive must be alone on its own line, with nothing before it. It’s picky that way. Don’t upset the __END__ or it won’t do it’s job.

The most obvious usage for the __END__ is cutting execution short so as to debug the top portions of the script before adding in the lower half. It doesn’t matter, either, if there are syntax errors in the lower portion since it won’t be parsed as code. How cool is that!?

The second use for __END__ is to include data within the code file. Though not generally a best practice, it has it’s uses in times and in seasons. You access the data under the __END__ directive through the file handler, like so:

#!/usr/bin/perl -w
$words = 0;
$chars = 0;
while()
{
$words += split;
$chars += length;
}
print "Characters : $chars\n";
print "Words : $words\n";
print "Lines : $.\n";
__END__
This is a bit of text designed to show
the concept of data underneath
the code in Perl using the __END__
directive and the DATA file handler.

And when you run this you get:

% ./test.pl
Characters : 142
Words : 27
Lines : 4
%

So there you have it! Now you too can use the __END__ to justify your means!

Approximately 30% of all netbooks shipped have Linux installed on them. That’s great, there’s many good reasons to put Linux on a netbook. The biggest is Linux runs much smoother with less hardware than windows does. Linux can also do anything windows can do (for the most part), but here’s the difference – there’s a learning curve. Sure some ‘average consumer’ might be willing to try Linux on a netbook, but that does not equate to a full OS rebuild on a desk-top. It may convert some, but it may also remind a few why they have Windows installed in the first place – they’re already comfortable with what they know.

Windows 7 will not kill off Linux. Nor will server 2008. Nor will any other distribution of Windows. Most Linux distributions are free, stable, and secure which keep costs down and everything running smoothly. Gone (for the most part here) are the days of searching for drivers all day. Heck, sometimes it’s harder to find drivers for Vista. While Linux isn’t for everyone, it’s definitely not going anywhere anytime soon and it’s definitely not going to loose much, if any, of its server footing.

I, personally, use both. Linux more-so, especially with the addition of a linux workstation at my home, than Windows – but they both have their places/faults/features.

First things first – you’ll need a copy of Gparted! That’s the iso version, burn it to a cd. Make sure you have the drive you want to clone and an empty drive connected to the same machine (the size of the drive does not matter, unless the data you’re cloning is larger than the space of the disc) and boot to your gparted cd. Before Gparted starts, you’ll need to choose a few options, I’ve personally found the defaults to work just fine every time I’ve used Gparted. Follow the on-screen directions. Once Gparted launches, you’ll see your master drive. Select it and choose the copy option. Switch to your secondary drive choose paste. You’ll be greeted with two warnings, click Ok through those and choose paste again. Apply your action. Once the data is copied over, you’ll need to mark the flag to ‘bootable’ (right click option). Bada-boom, bada-bing, you just cloned your drive. Remove the secondary drive and place it in another machine and watch it boot right up! Pat yourself on the back for saving a few hundred dollars! Now, of course, if you’re doing this with windows, you’ll need to use the same hardware if possible, to avoid a repair and you may need to re-register your copy with Microsoft. If you have a volume license key, and the same hardware, you’ll have no issues with ghosting the drive using gparted. All updates, accounts, settings, etc, etc will be copied over – it’s a true clone. Linux, as always, doesn’t really care, as long as the new hardware is supported.

Graphics

Photoshop – If you have dealt with graphics at all, you have heard of photoshop. Everyone uses it. Everyone loves it. There are tons and tons of tutorials online for photoshop. There are also tons and tons of downloads for it like plugins and brushes. If you can afford it, buy it and skip to the next section. Can’t afford it? Try ebay or craigslist for an older copy. Still can’t? Read on.

Paint Shop Pro – This is where I first started when I began messing around with graphics. It’s a fun program, but at the time, lacked the depth and breadth that photoshop has. That may have changed, I don’t know, but another thing to consider is the amount of tutorials for photoshop as opposed to paint shop pro. Also the amount of tools, brushes, vector graphics and such. But paint shop pro is a might bit cheaper, so if you have the money, but not enough for an old copy of photoshop, here is a good place to start.

The Gimp – For the truly poor and those who wish to “stick it to the ‘man’”, there is, as always, the free and open source version. The Gimp, when I first used it, was as annoying to work with as it was awkward to learn. To be fair, I ran across it after I was well into my Photoshop 7 days, so it didn’t stand much of a chance. Also, the open source community has come a long way since then and in general they have become MUCH more user friendly. The Gimp is worth giving a day in court for those who can’t do one of the other two options.

Code editors

Visual Studio 2008 – The main feature I like about Visual Studio 2008 is intellisense, Microsoft’s intelligent guess-what-you-are-typing feature. It is actually remarkably helpful since it can be tough remembering all the exact syntax for all HTML, CSS, and javascript. At the time I started using it, no other product had that, though I am sure someone somewhere has picked it up. Another reason I use it is because I do C# and Windows development as well and so for the sake of space and tools consolidation, I use it for my html and CSS design too. However, it carries a HEFTY price tag (Bill Gates needs his money) and so I generally do not recommend it unless you REALLY need it. You are probably better off saving the money and going with one of the cheaper options below.

Dreamweaver – Ah, Adobe’s Dreamweaver… This I would definitely recommend and it’s what I used before I started doing Windows development as well. Definitely worth the money Adobe asks for it (which isn’t much, really). It has great features, solid design, and easy to learn. I loved it. And now, with the recent flash integrations they put in, I find myself using it for some of my fast-dirty flash tasks too, particularly video integration. Always very solid, like everything Adobe.

XSite Pro – This one really surprised me when I first tried it out. I thought it would be fairly novice oriented, and it is, and that I would have no use for it. Come to find out, it does a lot of the SEO things and mundane linking, sitemaps, and things that I would rather not waste my time on. It’s great for doing small sites fast! Recently, our company has started offering 5 page sites for $500 and they have become quite popular. Well, since I don’t do crap work, even a 5 page site once I design the look and feel, create the template, generate keywords for all the pages, etc takes a day or two at least, if I can JUST work on that one project. Once I got this program, I whipped out three such sites in an afternoon. Paid for itself right there. So if you don’t like to stress the mundane parts of building small sites, get this.

Notepad! – Believe it or not, for FAST quick changes, nothing beats notepad to date. When you just need to change something simple and stupid, notepad it! I guess vi would be the unix commandline equivalent. I use both regularly. Sometimes simplicity and speed beats the fancy features.

Frontpage – I mention frontpage here not as a recommendation, but as a warning. USE NOT FRONTPAGE! Why?

1. Microsoft discontinued it.
2. They did so because it is more of a pain than it’s worth.
   • Frontpage extensions fail OFTEN.
   • Frontpage uses syntax that, often times, are ONLY compatible with Internet Explorer (doesn’t that sound like Microsoft?)
   • It’s not nearly as good as Dreamweaver and is not much different in price

Microsoft has come out with Web Expressions as Frontpage’s successor, and honestly, I haven’t messed with it much. Maybe someone who has can let us know if it is any good, but in my opinion, Microsoft really dropped the ball with Frontpage. Avoid it.

Test Server

In order to really do development, you must have a test server to play with. No two ways about it. Don’t cry because you looked at the prices of dedicated servers around the net, you don’t have to be THAT fancy. There are other options.

Your Own Home Server – This is how I started out. Take that old P3 you have stashed in the closet, you know… the one you have been holding onto cause you just KNOW it will come in handy sometime… well it’s day has come! Throw a flavor of linux on it (I prefer CentOS since it better mimics most real-world server environments), setup apache, php, and mysql and BAM! You have a test server!

Get a Cheap VPS – Setting up your server sound too hard? Or maybe you need to develop for several flavors of linux or even windows and don’t want to setup multiple test boxes each time you need to switch? VPS (Virtual Private Servers) are dirt cheap these days. For the price, it’s worth grabbing one or two.

Free Hosting Accounts – Certainly not ideal, but workable, are free web hosting accounts. Usually they aggregate headers and/or footers, but what the heck, it’s free! And if you are just starting out, it can be a way to cut some costs while you pound out a few sites.

Browsers

Unlike the other categories, this one you will need ALL of the below items at least. And also unlike the other categories, all these are free. It is essential in this day and age to be cross-browser compatible in your coding. To be sure you are, you will need … the browsers that will render your code… at least the most popular ones.

Internet Explorer – Unfortunately, you can’t ignore the fact that most of your viewers will probably be using IE. Get it. If only to check compatibility with it. IE has some quirks about some of the newer XHTML syntaxes so it really needs to be looked at before going live on a site.

Firefox – Firefox has some quirks to how it displays certain things as well, so don’t pass it up either. Also, there are some EXCELLENT firefox plugins that in invaluable when debugging javascript, cookies, and CSS. Get it, download the Web Developer Toolbar, the Google toolbar, the StumbleUpon toolbar (for Marketing [trust me, it works]), and firebug at least. They will save you tons of time and headache once you start getting into the fine points of web development.

Google Chrome – Honestly, I haven’t yet found an instance where a site displays well in firefox and IE and NOT in chrome. However, that’s not to say that it won’t. Chrome is built of the same engine as Safari, the main Macintosh browser. Mostly though, I have it for the speed. It’s faster than IE and firefox at blunt browsing. Check it out.

Optionally, Flash

Flash is increasingly becoming important in the realm of web development. It’s a great tool and should be used when it can enhance the site. There are really only two tools that come to mind for flash.

Adobe Flash – This is what I use and what I recommend, provided again that you can afford the price tag. It’s fairly simple to use, very powerful and flexible, and there are, again, TONS of online resources available to help you out along the way.

Swish Animation – Swish does quite a few things fast and dirty. It started out as more of a “do a few canned things fast” piece of software and from there evolved. So it does certain things that would take a while to do in Flash quickly. The down side is that, last I checked, the two weren’t compatible at all. You stick with one. But if Swish will do what you need, check it out.

Well, that is about it for the main tools of the trade for a web developer. Now, armed with the right tools, you can start tinkering around with concepts and ideas. The more you do so, the better you will get. The world is never going to run out of the demand for developers, so keep at it!

I am going to assume you have already installed ruby, gems, and rails. If you have not, Google would be overjoyed to provide you with a plethora of commands, download locations, and configuration instructions for any architecture you wish to run ruby and rails on. I am furthermore going to assume you are using a database. I myself am doing this on CentOS 5 with MySQL 4.1.22 and Ruby 1.8.6 running Rails 2.1.0. I don’t imagine that that would be too far from the “norm” in the Ruby community. Well, so much for the preliminaries, now on to the main event

Installing a skeleton rails application is really quite simple. Using the rails command is quite simple and fairly straight forward. You can see the help for it by typing

# rails --help

Basically, you type in rails [path to wherever you want your rails app to be] –[whatever options you want]. My demo was created like so:

rails /home/jay/railstest --database=mysql

So I put the gave it the path to where I wanted my rails app to be (/home/jay/railstest) and told it which database I wanted to use (–database=mysql). There are some other options, take a look at rails –help to see them. But really, there aren’t many. It’s pretty simple, very straight forward, as it should be.

The Rails command creates the directory that you specified if it doesn’t already exist and fills it with a bunch of stuff, the framework skeleton. The structure therein is as follows:

• app – The app directory is where most of the fun is. It is where you will put most all your code specific to your application. So get used to the idea. This directory contains several sub directories of note.
  • controllers – Here you put all the controller classes you create to control your models. They need to be named [modelname]_controller.rb since there is some automatic URL mapping that goes on and it follows that naming convention. All Controller classes inherit from ActionController::Base.
  • models – Here you put all the model class definitions and code. Most of the time, these classes inherit from ActiveRecord::Base
  • views – The template files for whatever views you have. You should also put stylesheets, images, etc here and if need be sym-link them to your public areas.
  • helpers – Here you put view helpers, and they need to be named [viewname]_helper.rb
  • apis – Here you put API classes for web services and such
• config – This folder holds, surprisingly, configuration files for the Rails Environment, routing maps, database configs, and other like materials.
• components – Here are the components that really self-contained mini-apps that are used to link controllers, models and views together.
• db – This folder has a file called schema.rb that holds your database schema and also migrations for your schema
• lib – As most developers would assume, this folder holds any code or libraries that are don’t fit into the other categories (models, controllers, views) that need to be included.
• public – This is where the web server looks to. It has images, stylesheets, javascript files, static HTML pages, etc (or symlinks thereto).
• script – Here we have some helper scripts for automation, generation, etc.

And there you have your default app. Next time we’ll start playing with setting up the database.