ben robison

Howto: Make a Rails Environment in Ubuntu

In class today, there was a demonstration on how to get Apache/Axis/Tomcat running to demo some SOAP web services written in Java. As I plug Rails again, I was again amazed at the simplicity with which Rails handles all this. I began to think that there might be some interest in Rails web services for those other members in my class, so in an attempt to help them out, I decided to provide instructions on setting up a Ruby on Rails environment.

Now I’m running mine inside a virtual machine with VMWare Server on my Windows Server 2003 box. I won’t get into all the reasons here, but these intructions would work for any VM or for a real install as a host operating system. There are only one or two differences and I’ll point them out as we go along.

1. Start with Ubuntu Server distro. I’m using Ubuntu 6.10 Edgy Eft.
Find the mirror you want, then click the Other Installation Options and find the server. If you must have a graphical environment, you can get the desktop version, but know that youll have to install apache2 and mysql on your own. If you choose the server option, you’ll be asked what kind of install you want to do. Pick the LAMP option. Do all appropriate setup, naming, networks, etc., and I’ll meet you again at the shell after you login.

2. Edit your sources list.

sudo vi /etc/apt/sources.list

Once you get inside, you’ll want to uncomment 4 lines, which will enable the universe repository along with the security universe repository. I typically comment out the cdrom: repository as well. For those unfamiliar with vi, the letter x will delete a single character. Pushing the letter i will put you in insert mode to comment our the cdrom line. Pushing Esc will get you out of edit mode. Pushing :, then wq, and finally Enter will put you back at shell with an edited sources list.

3. Get SSH running
For me this is essential. The interface through VMWare isn’t the speediest thing, and when you’re running over a Remote Desktop connection, things start to feel like molasses. A few things will fix us right up, because through SSH everything runs beautifully.

sudo apt-get install openssh-server

This will install and start the SSH server. Now you may need to configure port-forwarding through port 22 in order to connect to your Rails/Ubuntu server. In addition if you need to forward traffic to your VM, then at your router point port 22 at the host OS and follow my other instructions on port forwarding to a virtual machine.

If you’re happy where you’re at, then you can skip step 3. If you want to do it, then SSH to your new server and continue to Step 4.

4. Update all your packages

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install saidar

Saidar is optional, it’s a neat little monitoring utility that runs at the command line, but tells you about your CPU usage, memory usage, disk usage, and everything else you’d expect from your Task Manager or Activity Monitor. Now it’s time to get down to business.

5. Install Ruby

sudo apt-get install ruby ruby1.8 ruby1.8-dev ri rdoc irb libmysql-ruby libmysqlclient15-dev

If you didn’t choose the LAMP option earlier (or picked a desktop distro) you’ll want to add Apache2 and mysql-server to this list:

sudo apt-get install ruby ruby1.8 ruby1.8-dev ri rdoc irb libmysql-ruby libmysqlclient15-dev apache2 mysql-server

6. Install RubyGems
RubyGems is like the apt-get utility for strictly Ruby packages. This series of commands at the shell will download, install, and clean up the RubyGems package.

wget http://rubyforge.org/frs/download.php/11289/rubygems-0.9.0.tgz
tar -xvzf rubygems-0.9.0.tgz
cd rubygems-0.9.0
sudo ruby setup.rb
cd ~
rm -rf rubygems-0.9.0
rm rubygems-0.9.0.tgz

7. Install Rails

sudo gem install rails --include-dependencies

This will show some errors while installing documentation, but never fear. All is well. We both know that you weren’t planning on reading the documentation anyway.

8. Install Lighttpd with FastCGI

sudo apt-get install lighttpd libfcgi-dev libfcgi-ruby1.8 build-essential


This will show an error that it tried to bind to port 80 and failed. That’s ok, because we have apache running there. What we’ve done is simply install it so that our Rails apps will use Lighttpd rather than the built-in WEBRick.

If like me you really just don’t like errors you can edit the lighttpd.conf file so that it binds to a different port. This is not necessary at this point, but if you plan on running Rails apps in production you’ll have to play with the lighttpd config file at some point anyway.

vi /etc/lighttpd/lighttpd.conf

Find and uncomment the line that says

# server.port = 81

Now we’ll run Stop just to make sure and then Start it up again.

sudo /etc/init.d/lighttpd stop
sudo /etc/init.d/lighttpd start

Now install the fcgi RubyGem:

sudo gem install fcgi

9. Make sure that your FastCGI bindings and MySQL bindings are working properly.
Now to make sure that our fastcgi and mysql libraries are working properly, we’ll fire up IRB. IRB stands for Interactive Ruby. It basically gives us a functional, yet empty ruby environment to play around.

irb
irb(main):001:0> require 'mysql'
=> true
irb(main):002:0> require 'fcgi'
=> true

Now, unless you want to do all your mysql configuration from the command line, you’ll need to be able to connect as root to your mysql database from a remote host. See my instructions on how to do that. You may need to set up port forwarding through port 3306 in order to get this to work.

Howto: Put WSDL on Rails

Why do I love Rails so much? Because there is so much to love! Who ever dreamed that creating web services could be so simple? Where other frameworks can consume them very simply, Rails defines simplicity when it comes to creating them. Consuming them is easy as well, but it’s on the creation side that Rails really stands out from the competition. So how do you do it?

First off, let me say that my inexperience in web services means that I’m far from a subject matter expert. I can however follow simple instructions, and I found a beautiful set over at the SOA Ranch. This is a 3 part series, though more are supposedly coming. I hope these articles continue to be published, but I have my doubts as the most recent articles are nearly 6 months old now. The first one I found was part 3 part 2.5 in the series, and you can follow the links back to part 1 & part 2.

So let’s get down to business. I’ll make the assumption that you’ve got a working Rails environment. For Mac users, the latest version of Locomotive has everything you need for creating web services. For everyone else you’ll have to make your Rails environment the old fashioned way, although you can look forward to Rubuntu soon. We’re going to create a very simple web service that accepts a string, changes it a bit and returns a string.

First create yourself a new application

rails WebServiceProvider

Then you’ll want to open your application in your favorite Rails editor. Then we need to generate your web service.

./script/generate web_service Manipulation manipulate

This will create an API file for us to define our web service’s interface. It also creates a controller for us to use, and then a test file for us to use later (we won’t get to scripted testing in this article, although we will test it manually to prove that it works).

Now open up your manipulation_api.rb file in app/apis. You’ll see the following line of code that is the beginnings of our string manipulating web service.

api_method :manipulate

We’ll need to define parameters and data types for our method like so:

api_method :manipulate, :expects => [:string], :returns => [:string]

There are many data types that can be used here, but we’re keeping things easy for now. Now we’ll go look at the ManipulationController at app/controllers/manipulation_controller.rb. Because we followed the standard Rails naming conventions the mapping of the web service to the controller is already done, but if we hadn’t, this mapping can be done explicitly by adding the following to our controller.

web_service_api ManipulationApi

We can also give our web service a different name with the wsdl_service_name directive

wsdl_service_name 'Manipulation'

Notice also that in the controller is where we define all our logic for what happens with the parameters being passed in by our web service consumer. the manipulate method has already been created for us, so we simply need to tell our method to accept a string, perform our logic, and return another string.

Again we’ll keep things simple.

def manipulate(terms)
return "Yeah! " + terms + "!"
end


Now for all intents and purposes, our web service has been coded. We’ll add one more line to our controller that will generate a web front-end for the service so we can go see how it looks on the browser end. Just add the following line to your controller.

web_service_scaffold :invoke

Now let’s turn on the server and see how things look. Back at the terminal type

./script/server

Open your browser and point it to http://localhost:3000/Manipulation/invoke. This shows us the web view of our API. Follow the manipulate link to see the auto-generated web form that will show us what our service looks like. Type your message into Param0 box and click the invoke button to see all your beautiful web service XML. Another important point for those wishing to consume your web service is that Rails is automatically generating your wsdl for you. You can see how this works by checking the routes.rb file in app/config but just know that visiting http://localhost:3000/Manipulation/service.wsdl you can see the WSDL file that others will need to use your web service. You can use something besides service.wsdl by editing your routes.rb file appropriately.

Now this is obviously a simple example, but it illustrates the basic steps and important points. You probably wouldn’t have much use for a web service that adds the word “Yeah” and a few exclamation points to some user-input, but if we were doing this in the context of a real web application, you can start to imagine the possibilities available in your controller if you’ve got a dynamic database-driven application to work with. You can add other methods to your API, define the param and return types there, then define the logic in the controller in the appropriate method. Once you get the basics down, you’re on your way and the sky is the limit. Good luck developing your first piece of the Web 2.0.

Convert Line Breaks in Rails

This may not be news to anyone else, but it was a surprise to me when I ran into it, so I thought perhaps someone else might find it helpful. Let’s imagine that you’ve got a form with a textarea that allows for a decent amount of user input, like, say a blog post or a news item on your family website.

When you push the “Enter” key it goes down to the next line. Behind the scenes, this is stored in your database as a new line character which is represented by “\n”. The problem is that “\n” has no meaning to a web browser. In web browser language, what you really need is a line break represented by the “<br />” tag. So how do you get all your new lines to turn into line breaks? The answer is one simple method added to your application_helper.rb file in your Rails project.

def line_break(string)
    string.gsub("\n", '<br/>')
end


Then in your view, you simply call the line_break method around the appropriate block of text

<%= line_break(@news.body) %>


and that’s all there is to it!

Now Powered By Typo

If you’ve been viewing my blog recently, you’ll now notice that the theme has changed and everything looks rather differently. There’s a good reason for this. I’ve now switched to Typo, a RubyOnRails powered blogging engine.

I spent quite a bit of time evaluating a few different options, compared features, etc. I’ll post the results of that later, because I figure it might save many other folks hours of work, but for now, the important things is that for me the benefits of switching outweighed sticking with WordPress. I’ve no complaints about Wordpress, just love the extensibility of Rails and I know much more about Rails than I do about PHP. I even compared a few different Rails engines, but finally settled on Typo for many different reasons.

This is really my first real migration from a development environment to a production environment on a web-host. I’ve done a lot of the programming for other sites, but the migration was always handled by someone more experienced than I. So after struggling with cross-platform database migrations, Apache setup, .htaccess files, config files, and many another unforeseeable issue, I’m ready to declare this one a success.

As you poke around on the new site, you’ll probably notice a few strange looking things. “Double-quotes” and other things didn’t handle the migration as well, so it’ll take a little while to fix all those things, but it’ll get cleaned up before too long. For now, enjoy the new site.

Rails Flash Helpers

Rails allows for the posting of errors through use of flashes. Calling something like

flash[:notice] = “Login Successful”

in your controller will allow you to display it in your view by calling the following code in your view.

<%= flash[:notice] %>

The types of flashes you can use are not pre-defined so if you wanted to use

flash[:pearl_jam]

you could. That being said, there are some generally recognized types of flashes that folks are standardizing around. The most common flashes that I’ve seen are:

flash[:notice]
flash[:message]
flash[:warning]
flash[:error]

I found some code at http://www.bigbold.com/snippets/posts/show/2348 that helped me out. You can edit it to suit your own needs. All you need to do is put thes code in your application_helper.rb file. It will allow you to call

<%= display_standard_flashes %>

in any of your views to display all flash types. This code also adds CSS class definitions that match the flash name, which will allow you to define a different look for your different flash types.