I’ve been looking for a good Rails host recently, one that’s running Apache/Mongrel or something business class.  Apache mod_ruby was a terrible at best, FastCGI was better at handling threads and serving content, but now that we’ve got a native Ruby solution, that seems the best way to go.

But it’s so expensive (at least for a personal blog).  I’ve looked at MediaTemple, which looks like a great option, but the basic Ruby package is $20/month.  In the days of cheap hosts that seems quite a high monthly price.

Then there’s HostingRails which has a basic Ruby package starting at $3.79/month, but if you want the Mongrel package, that’ll cost you $9.79/month.  That’s obviously a better deal, but they claim to be RoR developers since 2005 and their website would suggest otherwise.  It’s not too badly designed, but I typically expect a much better look from a Rails developer.  It’s just not the kinda place that I feel like I could trust with my credit card number.

So have I missed something?  What’s the cheapest Mongrel-running host I can find out there?  Does HostMonster support Mongrel?  I know Bluehost doesn’t.  Does anybody have experience with lunarpages,  MidPhase, or An?  Please help me out in the comments below.

Now originally I followed this tutorial and installed the necessary gems in order to cache the ActiveRecord objects into memcached. I followed all instructions exactly as instructed, but starting the memcached server in verbose mode, revealed no object calls to and from the cache. If I loaded up the application console, I could access the cache directly and put things in on my own, but the functionality provided by cached_model was not working on my machine for whatever reason.

Being somewhat of a nuby anyway when it comes to Rails, I turned to an alternate solution rather than hopelessly debugging the current problem. I found another tutorial that had instructions on how to cache sessions into memcached.  I used the memcache-client client rather than the Ruby-memcache client going for the speed and the ease of setup.  It works like a charm.

Now rather than just leaving it there, I’ll tell you what I’v discovered over and above what Elliott discovered over at townx.  The ongoing development of memcache-client has apparently made some advancements to the point where it matches the application stability of Ruby-memcache when the memcache server is turned off.

At the time of the post, Elliott observed that when using memcache-client the whole application fell over when the connection to the memcache server was lost, while Ruby-memcache kept the application running with irretrievably broken sessions.  He then wrote a plug-in that monitored the memcache servers and when they came back online would begin using them again (rather than having to restart the application).  My observation as of today is that memcache-client now has both of those functionalities built in.

When the connection to the memcache server is lost, then the sessions are broken, any data stored is inaccessible, however when the memcache servers some back online, the application recognizes that and begins using the sessions again.  If the memcache server was turned off, then any data in them is gone as well, but if the memcache server itself was still running and it was just the connection lost, then the session data should still be available in the memcache servers.

As a sidenote, over at Nuby on Rails, they noted that the the memcached server available on Macs through Darwinports is broken.  I verified this; the calls I made to the cache directly from the console did indeed take 5 seconds to  push through.  However,when running it from my Ubuntu box even over the internet (Sundance to Orem) the application response was pretty snappy.  Not to shabby considering the quality of the internet in Sundance.

The Background
For my Information Architecture class, we’ve got to create a web service provider and a web service requester, this provided the initial impetus for my recent push into web services and the last few posts dedicated to the topic. Now our professor has published a web service that basically dumps his database out into an array of complex data types.

His database is a weather reporting database that has zip code, temperature, humidity, etc. The databse is small (currently 3 entries) and populated with completely fabricated data, this is a learning experience not an accurate forecaster.

Our task is to subscribe to his web service, and publish our own that will accept a string parameter as the zip code and return the single weather report for just that zip code. I decided that I’d just subscribe to his web service in my controller, find the appropriate weather report, create my own Struct for my web service, and push it out to my subscribers.

The Problem
Once I had received my professor’s SOAP object back, I stepped into it to retrieve the zip codes from each entry. When I found the matching zip code, I mapped his keys and values to my own with a line of code like this:

return WeatherReport.new(:cityzip => row.cityzip, :temperature => row.temperature, :etc => ad naseum)

There are ten different attributes that my object must return to my subscribers, so it was slightly tedious to put all these things together. I prevailed.

When subscribing to my own web service via WSDL, however, I received the following exception:

Exception: Cannot map WeatherReport to SOAP/OM

WeatherReport is the name of the Struct that I was using as my return type. I began meticulously checking all my code. I had already written code to subscribe directly to my professor’s web service, so I checked the SOAP object coming back from that. I used a copy of the same code to subscribe in my own web service and could not figure out what was going on (hours pass).

I finally ran across this email archive that had a fix, but not an answer.

The Fix
I had to change my code to this:

return WeatherReport.new(:cityzip => "#{row.cityzip}", :temperature => "#{row.temperature}", :etc => "#{ad naseum}")

The “#{row.cityzip}” means that the object inside the {} should be interpreted as a variable and it’s value should appear in the string instead of the variable name. It’s just a shorthand way of concatenating strings with the values stored in string variables (and in case you were wondering, yes, you must use double quotes or it won’t work).

Now the most interesting thing about this error is that row.cityzip == "#{row.cityzip}", meaning that the expression evalutates to true. For all intents and purposes, these two strings are exactly the same.

Peter (the guy with the fix) speculates on what might be the cause, but he was also using the a Struct (via SOAP4R), so I assume that the problem’s source may lie in that class. Given the dearth of readily available information on the topic, I hope you find this useful.

If you’ve stuck with me this far you’ve probably figured out that I’m discovering things on my own shortly before I spew them all out here. In Howto: Put WSDL on Rails we built a simple web service that would accept a string parameter, modify it, and send the modified version back to the user. In Part 2, we subscribed to (and used) that same web service using only the WSDL. At the time I thought I was done, but as I’ve played around a bit more, I realized that there was another major part of web services. So now we’ll cover dealing with complex data types.

I began by wondering what kinds of things besides [:string] you could pass as parameters to and from a web service. I finally happened upon the Ruby on Rails manual that somehow I had not discovered up to this point. Why don’t these pages come up higher in the Google search results? Rails uses ActionWebService to interact with web services of all kinds and you can find the beginning of the manual here. You can find the specific answers to my questions here and here.

After reading this and mulling it over a bit, everything was pretty clear except for the so-called Structured Type parameters. I set out to gain a better understanding of this, and this is what I accomplished. First off, you’ll want to read up an something called a Struct. In essence an ActionWebService::Struct is a special kind of object that can be used for web services, but doesn’t have any ties to a database like an ActiveRecord::Base object.

I first defined a new struct in app/models/weather_report.rb of my WebServiceProvider.

class WeatherReport < ActionWebService::Struct
member :zip, :int
member :temp, :int
member :wind_speed, :int
member :wind_direction, :string
end


I then created the proper method in my API at app/apis/weather_api.rb:

api_method :get_weather, :expects => [:string], :returns => [WeatherReport]

And since I was really just curious to see how this works, I defined a very dynamic method in app/controllers/weather_controller.rb:

def get_weather(zip_code)
return WeatherReport.new(:zip => 84097, :temp => 55, :wind_speed => 5, :wind_direction => 'SW')
end

And that’s really all there is to it. If you’ve got a database driven application you could simply pass in one of the models that corresponds to a table on your database. So instead of an ActionWebService::Struct you could just pass in an ActiveRecord::Base object with the exact same syntax.

Now to see what comes out on the other end. In another application, I subscribed to my web service and in my view put <%= debug @result %> with @result being the result of my GetWeather call to the web service.

The debugged results came out like this.

#<soap::mapping::object:0x14868c6 {}zip="84097" {}wind_direction="SW" {}wind_speed="5" {}temp="55">

Carrying this logical line one step further, if a web service required a complex data type as input, we could build an ActionWebService::Struct object or use an appropriate ActiveRecord::Base object to pass into a third party web service. I see the struct option being much more useful ona day to day basis, but in a B2B environment, you can start to see a place for some real hard-core service interactions passing full-blown database-drive object types around between systems.

As I began to play around with web services, I thought they were pretty neat, but I’m beginning to see the how powerful they could be given the right set of circumstances.

1. Fire up the old WebServiceProvider application that we created in Part 1

From the application root directory type ./script/server

2. Create a new WebServiceConsumer application

In a new terminal window type rails WebServiceConsumer

3. Create a controller for your service consumer

cd WebServiceConsumer
./script/generate controller consumer

4. Subscribe to your WebServiceProvider using its WSDL

Open up your consumer_controller.rb in app/controllers. It will be empty and it needs to look like this:

class ConsumerController < ApplicationController

require 'soap/wsdlDriver'

def subscribe
if params[:terms] == nil
@service_output = ""
else
url = "http://localhost:3000/subscription/service.wsdl"
factory = SOAP::WSDLDriverFactory.new(url)
service = factory.create_rpc_driver
@service_output = service.Subscribe(params[:terms])
end
end
end

This is where the magic happens. The line require 'soap/wsdlDriver' brings in the needed Ruby library. The subscribe method is simply an action like any other in your application. We’re going to create a form that accepts some user input and then we’ll pass them on to our WebServiceProvider. The url, factory, and service lines could all be done in one line, but I’ve broken them out here to demonstrate.

If the box is left blank, we don’t do anything. If the user inputs some data, then we have a little bit of work to do. We create a new service object based on the WebServiceProvider’s description of itself as defined by its WSDL. Then our local service object acts as a proxy and any method calls we make on the local object are simply passed on to it the actual WebServiceProvider.

We can then define our @service_output as a variable we can then call in our view. Now for testing.

5. Create two views for testing

In app/views/consumer create an index.rhtml file as follows:

<html>
<head>
<title>WebServiceConsumer</title>
</head>
<body>
<h1>WebServiceConsumer</h1>
<p>
Enter your terms below. They will be passed on to our web service and you'll be able to see the response.
</p>

<%= start_form_tag :action=> 'subscribe' %>
<p><label>Terms</label><br/>
<%= text_field 'terms', '' %></p>
<%= submit_tag "Subscribe" %>
<%= end_form_tag %>
</body>
</html>

Also in app/views/consumer create subscribe.rhtml as follows:

<html>
<head>
<title>WebServiceConsumer</title>
</head>
<body>
<h1>WebServiceConsumer</h1>
<p>
The web service returned: <br /><br />
<%= @service_output %>
</p>
</body>
</html>

6. Now fire up your WebServiceConsumer app on a different port

Depending on your particular setup this may be different. I use lighttpd, so you’ll need to open app/config/lighttpd.conf and change the server.port = 3000 to say something like server.port = 3100. Then you can run ./script/server to fire up your app on port 3100.

Now point your browser to http://localhost:3100/consumer

Enter your terms into the text box, click Subscribe, and pat yourself on the back. You’ve just subscribed to a web service.

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.

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 (update 1/3/2009: I’ve removed the links since they no longer point to Rails content, apologies for the inconvenience).

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.

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!

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.

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.