Frictionless Floor

edit

Fictiverse: Part I - Setup

Posted by David Harris Wed, 24 May 2006 11:53:00 GMT

(Quick note: If you were looking for a post entitled “Solving the Password Problem”, it accidentally got deleted when I tried to use a new blog editor. Performancing is great, but be careful.)

Ok, so this will be the first part in many on the journey of a rails app called Fictiverse. For this post, I’m not going to detail what the app is going to be yet, but I will explain some initial setup things I’ve learned. These are all things that can (and should) be done before you even think about application design. I will be creating Fictiverse on a shared host using linux, so you’ll have to adapt this for your own purposes. Be forewarned, I’m going to be very detailed on each point. I believe there are a lot of resources out there, but few have managed to detail every part of things; I’m going to attempt to explain everything I can in this process. If you’re comfortable with certain parts, skip them please! I imagine most of my audience can safely skip the first section.

1. Getting a domain and setting it up

I’m going to assume that you already have a domain and web hosting. If you’re looking for an excellent host that allows Rails and Subversion (for purposes of this series), I highly recommend the host for this domain, A Small Orange for their awesome support and great price. I host about 10 domains on the $5/month package and have not even used 20% of the space or bandwidth yet. Definitely the only host I’ve had no major problems with yet. Once your domain is purchased and you have a hosting plan, be sure to add your domain to that plan (follow the instructions of your host, or ask them how). Now, you’re pretty much set for this portion.

2. Setting up your Subversion repository

For those that have never used a source or revision control system, you’re missing out! I can’t tell you how many times I’ve screwed something up and had to revert to older code to see where it went wrong. Source control basically means that after you make changes to your code, you commit the new code to a server where it keeps track of the evolution of your code over time. If something ever screws up, this is like a backup system for oh-so-important code. Luckily with Rails we’re not going to have to write a lot of code, but this will still be important. Also, this allows you to easily work on the same code from two locations, and have both be a local copy. Our “production” copy will simply be checked out from the repository from time to time.

To set up your own subversion repository, issue the following commands. In my server’s home directory (~), I have two subfolders I use for my rails work; one to hold subversion repositories and one to hold the actual rails code. The following series of commands will set up that structure and your repository (note that for the simplicity of this tutorial, I will not be using the branches/tags/trunk structure of most repositories):

 [~]# mkdir rails
 [~]# mkdir svnrepo
 [~]# svnadmin create ~/svnrepo/fictiverse
 [~]# cd rails
 [~/rails]# svn co file:///HOME/svnrepo/fictiverse fictiverse

Note that HOME should be replaced with wherever your home is (such as /home/davidh for me). Now, your repository is set up and you have a home for your rails app. Next, we will create the rails application structure and update the repository.

 [~/rails]# rails fictiverse
 [~/rails]# cd fictiverse
 [~/rails/fictiverse]# svn add . --force
 [~/rails/fictiverse]# svn ci -m "Added Rails Structure" 
 [~/rails/fictiverse]# svn up

Now, we will set subversion up to ignore our log files for versioning. If you wish, you can adapt this set of commands to ignore the Rails cache (tmp/*) and database.yml file (in config/) if you want to have seperate ones on each place you develop. For now, we’ll just ignore the logs. We will get around the database.yml issue by using the same login/pass/db wherever we are.

 [~/rails/fictiverse]# svn remove log/*
 [~/rails/fictiverse]# svn propset svn:ignore "*.*" log/
 [~/rails/fictiverse]# svn ci -m "set up log file ignoring" 
 [~/rails/fictiverse]# svn up

Ok, so currently we have a working Rails directory, and have set it up inside version control to use from home, work, or wherever we wish to work on our application! For details on how to access this from home, this will be covered when we start coding.

3. Going public

Thus far, all our work has been behind the scenes. It’s time to take it to the world. This section really depends on how your host is set up, so I’m obviously going to assume ASO, my host. First, you need to explore where your host redirects request for your domain. For example, I type in fictiverse.com, it takes me to a directory listing, since I have nothing in there. So where is it actually looking? Well, I check out my server’s log files and I see the request was looking for /users/davidh/www/fictiverse/. So now, I know where to look. Sure enough, fictiverse is a directory inside www (a symbolic link to the public_html directory). So how do we connect this to rails? Easy, we switch the directory for a symbolic link to our rails/fictiverse/public directory.

 [~]# cd ~/www
 [~/www]# rm -rf fictiverse
 [~/www]# ln -s ~/rails/fictiverse/public fictiverse

And that’s all there is to it! Check it out, “http://www.fictiverse.com”http://www.fictiverse.com . The default Rails page comes up, telling us to welcome aboard. Not a whole lot of work to arrive at this point, and not a whole heck of a lot got accomplished, but we have a domain hosted somewhere, have the shell of a Rails application up and running, and it is all version controlled. Not bad for a few minutes of work, and utterly necessary for any rails app you wish to create. Thanks for reading Part 1, and Part 2 will come in the next few days, where we begin actually designing the application and defining constraints.

Edit: I’m very sorry, but I completely screwed up and forgot that I have database information previously set up. I think only a few people have started this so far, from emails, so I’m sorry you’re all getting 500 errors! Until database information is set up it will not work. So, you might have to wait until part 3 for me to explain setting that up. But if you wish to browse the Rails Wiki you can find how to set this part up on your own.

Digg this!