GAE comes complete with auto-app-versioning, your choice of runtime environment (Python only for now, but they say there’s more coming) and automatic scaling. In fact, GAE lets us forget all about scaling and reliability: it just works. And that’s the future: complete platforms, not ad-hoc components. Google has definitely hit the nail on the head with GAE and I can’t wait until it’s out of beta. Stay tuned for more on GAE soon.

• Negligible overhead. All OpenVZ virtual servers share the same kernel. This makes for such little overhead that it goes unnoticed.
• Flexible resource allocation. We can share resources among our virtual servers much more flexibly than we could with Xen. For example, our Level 3 hosting plan has 1GB RAM. But we don’t really cap it at 1GB, that’s just what we guarantee. In reality, we’re fine with a customer’s virtual server temporarily using more than that. If it becomes permanent, we’ll just ask them to upgrade. Our servers have a ton of RAM, and there’s always GBs to spare, so no sense in letting them go to waste. If we were using Xen, we’d have to cap the customer at 1GB and they’d need to upgrade to increase that, even if only temporarily. The same deal applies to CPU and disk space.
• Extremely quick upgrades and downgrades. We can upgrade or downgrade a customer’s resources in a matter of seconds and usually with zero downtime. How’s that for cool. Even disk quota’s can be altered in seconds – something that’s usually a painful operation with Xen.
• Stability. OpenVZ is the core of a commercial product, Virtuozzo. Virtuozzo has been through several years of production usage, and it’s rock-solid. We’ve not had a single problem with OpenVZ. What’s more, should we ever need commercial support we can always contact Virtuozzo.
• Performance. I can’t provide you with any benchmarks right now, but compared to some of the Xen solutions we’ve used in the past, OpenVZ seems a lot faster. Read into that what you will, but that’s our experience.

If you’ve also used both OpenVZ and Xen, I’d love to hear your experiences. What made the most sense for you? Why?

To get the most out of the filter you need to train it. When using Ticketish, you’ll see some new items in the drop-down for managing multiple tickets: Spam and Train Not Spam. Start by selecting a whole group of tickets that aren’t spam, and train them so. Then, make sure you mark all spam tickets as spam instead of just deleting them. Over time, Ticketish will become very accurate at determining what’s spam and what’s ham.

Every Ticketish account is trained separately. This is important because what’s spam for some might be ham for others. All accounts start with a clean slate, so it’s up to you to train appropriately. We’ve developed the spam filter as a RESTful web service, so expect to see it pop up in our other applications as well.

We’re running God for all our managed hosting clients to make sure their mongrels don’t pass out from exhaustion. Here’s our init script and a sample global config for your enjoyment.

• /etc/init.d/god
• /etc/god.conf

The God configuration file should be self explanatory. It’s just Ruby code, nothing magic going on there. I’ve just wrapped the core God.watch code around some loops to enable support for monitoring an unlimited number of applications. One small note about the init.d script: it first launches God, and then loads the config file via the ‘god load’ command. I’m aware that you can send god the -c parameter when launching it, but I’ve found that sometimes (seemingly randomly) that won’t load the config.

The init.d script should work fine on any RHEL/CentOS system. Once you add the file to /etc/init.d/god just do:

Now you’re good to go. Let those misbehaving K-9 devils do their best – they’re no match for God.

Each project in Ticketish receives its own email address. The email address is in the format “[project.permalink]@[account.subdomain].ticketi.sh”. Sending an email to the project’s email address creates a new ticket. Once a new ticket is created, a notification email is sent. Replying to the notification email (or any further emails regarding the ticket) adds a comment to the ticket. Further, the user can add attachments to any emails and have them show up as attachments to a comment.

So, how does it work? Let’s start with the big picture. The mail transfer agent Postfix runs on the same server as the Ticketish mongrels. Postfix receives mail for all ticketi.sh subdomains. When Postfix receives a new message, it fires up script/runner for Ticketish and passes the message in via STDIN. At this point we don’t care if the project exists or not, that’s for Rails to figure out. Postfix just needs to send any emails addressed to *.ticketi.sh to script/runner.

Let’s dig a little deeper, and see how to accomplish this behavior with Postfix.

The first Postfix configuration file we’ll look at is main.cf. I won’t paste the whole file, just the interesting parts that differ from the default main.cf file Postfix comes with.

/etc/postfix/main.cf
myhostname = ticketi.sh
mydomain   = ticketi.sh
mydestination = $myhostname, localhost.$mydomain, localhost, regexp:/etc/postfix/mydestination

This is mostly straight-forward. We set the hostname and domain to “ticketi.sh”. The interesting part is that we’re using a regular expression lookup table with mydestination. The mydestination setting means “this is the final destination for the following domains”. Obviously, we want to be the final destination for all Ticketi.sh domains, so we use a regular expression.

/etc/postfix/mydestination
/.*\.ticketi\.sh/       OK

Pretty simple. You need to make sure you generate the database file from that lookup table by running postalias:

# postalias /etc/postfix/mydestination
# ls /etc/postfix/mydestination.db
/etc/postfix/mydestination.db

Now that Postfix knows to receive mail for *.ticketi.sh, we need to tell it where to send that mail. First, we’ll create a wrapper around script/runner that can receive incoming emails from Postfix.

/etc/postfix/ticketish_agent.sh
#!/bin/bash
HOME=/home/lsws /usr/bin/ruby /home/lsws/apps/ticketish/current/script/runner 'data = STDIN.read; CommentHandler.receive(data) || TicketHandler.receive(data)' 2>> /home/lsws/ticketish_agent.log

The actual Rails code in runner is pretty simple. We assign the incoming email to the data variable, and then do ‘CommentHandler.receive(data) || TicketHandler.receive(data)’. This code tries to add the message as a comment first, but if the comment handler returns nil (as it will if the message isn’t a comment) it’ll create it as a new ticket instead.

Now we need to add a service to Postfix by adding a few lines at the bottom of master.cf.

/etc/postfix/master.cf
mailman   unix  -       n       n       -       -       pipe
flags= user=lsws argv=/etc/postfix/ticketish_agent.sh

We’ve just called the service “mailman” and it pipes the message through to the wrapper we just created. Note the user= field. As you might guess, this is the user the process runs as. Be sure to use the user your Rails application runs under.

Finally, we need to tell Postfix to deliver all local mail to this new service (all local mail, since Postfix is entirely dedicated to Ticketish). We do this by defining the local_transport in main.cf.

/etc/postfix/main.cf
local_transport = mailman

Creating the CommentHandler and TicketHandler is pretty simple. We just use the following structure:

ticketish/app/models/comment_handler.rb
class CommentHandler < ActionMailer::Base 
def receive(email)
# ...
end
end

You can do whatever you like once you have the email. For example, to extract the project name and domain name from the recipient address of the email:

project_name, domain_name = email.to.first.split("@")

So there you have it. Easy email integration with Postfix and Rails. If you haven’t already heard of Ticketish, take a look. It’s our new simple ticketing application, currently in beta. We’re still sending out beta invites, so feel free to add your name.

After installing the ARes plugin, the first thing you want to do is create a parent class for your resources to inherit from. The parent class looks something like this:

billing_resource.rb:

Here, we’re simply creating a BillingResource that acts as a parent to our resources such as CreditCard, Invoice and Subscription. You set the location of the remote application in the self.site variable in this class, so that you don’t have to set it for every other resource. You can also add any other common methods here.

Now, let’s create a Subscription resource:

subscription.rb:

First off, you will notice our Subscription resource inherits from the parent BillingResource. You’ll also notice that we’re defining methods for the associations, such as credit_card and invoices. ActiveResource doesn’t automatically do this for you. It’s up to you to implement it.

ActiveResource provides a basic find() method for your resources. You can do Invoice.find(id) but you can’t do Invoice.find_all_by_subscription_id(x). If you try, you just get a NoMethodError:

This isn’t a big deal. We can use the connection object to contact the remote resource at the correct RESTful URL to retrieve the data we need. The relevant line from the code snippet above is:

What’s happening here? We’re requesting, from the remote application, the XML version of the index action on the invoices controller for the subscription ‘id’. The XML version knows to just do a select => :id on the invoices, so the return payload is just a bunch of invoice id’s. In this example, I’m then iterating through each invoice id and loading the full invoice; you could do something more efficient if you need to. This all gets cached in the @invoices variable so that repeat hits to subscription.invoices don’t need to fetch the data again.

Your’re probably wondering what the invoices index action in the remote application looks like. It’s very simple:

The credit_card method is a lot simpler than the invoices method, because it’s just a belongs_to relationship. We’ve already got the credit_card_id available, so we can just do a simple CreditCard.find(credit_card_id). Again, we’re caching it in the @credit_card variable to minimize repeat trips over the network.

Finally, you’ll notice the generate_and_pay_next_invoice method. This is actually a method on the Subscription model in the remote application, but because ARes doesn’t let you call methods remotely, we need to define it again. We won’t, however, repeat the logic of the method. Instead, we’ll do a connection.post to the generate_and_pay_next_invoice action in the remote subscriptions controller. The action in the remote application is pretty simple:

If the remote action is successful, it will return the location of the new invoice resource. We can use that to make the method return true or false depending on its success:

I’m returning head :ok in this method instead of a 422 or 500 error status. That’s because it’s not supposed to raise any exceptions if there’s nothing for generate_and_pay_next_invoice to do. You could, however, easily return an error status:

In summary:

• ARes does not let you call remote methods directly, you need to implement them.
• ARes does not provide methods for associations, you need to implement them.

If you keep these points in mind, working with ARes becomes a lot more straight-forward.

There may be better ways to implement some of these items. The above has worked well for me, but if you know of better practices please leave a comment and I’ll keep the post alive by integrating the new information.

Recommended Reading

• http://ryandaigle.com/articles/2006/06/30/whats-new-in-edge-rails-activeresource-is-here
• http://blog.mauricecodik.com/2006/06/instant-rest-on-rails-activeresource.html
• http://www.eribium.org/?p=71

CurrentResource is a Ruby on Rails plugin which creates some nice convenience methods to access the current resource being referenced in the request URI when you follow common RESTful conventions.

So What’s It Do?

Let’s get the basics out of the way first. Make sure you install the plugin and restart your application:

The easiest way to explain this is with an example. Let’s use the ever-so-popular example of a blog:

What About Nested Resources?

The main reason why I wrote this plugin was to create an easy way to access the parent resource being referenced with nested resources. This is what I mean:

Use of method_missing

One important item to note is that CurrentResource utilizes method_missing to dynamically add the current_resource method. What this means is that if methods with this format already exist, those will take precedence. For example, if you have a current_user method defined as part of your authentication system, that is the method that will called.

If you liked this article, feel free to digg it

Recently, I setup some generous memory limits on our servers to catch any out of control applications from gobbling up the servers memory and bringing everything down. I thought 200MB per Rails process was quite generous, and for the most part it has been.

Today I found out that one of our client’s was having some trouble uploading images in their application. I quickly found the culprit:

Huh? These weren’t big images the client was uploading. Just tiny, less than 100KB PNG’s. But something must have went terribly wrong to hit that memory limit. To find out just how bad it was I removed the memory limit and watched the Rails process in top. Within a few seconds it was over 400MB and growing. Needless to say, I quickly killed it.

Since we’re already using attachment_fu I solved the problem without changing a single line of code. I headed over to the ImageScience website, followed the instructions to install and restarted the application. Uploading now works perfectly, and memory usage barely moves.

Unfortunately (or maybe fortunately), ImageScience is pretty slim on what it can do. It generates thumbnails. What we need now is something with the power of RMagick+ImageMagick that’s quick, light on memory and relatively bug-free. Any ideas?

Rails gives us a few pieces of magic which really help us cut down on our code. Both migrations and RJS templates are perfect examples of this. They help you to write boring, repetitive code in a fun and easy syntax. As a designer, I particularly feel there are two area that have received the short end of the “innovation stick”: XHTML and CSS. HAML looks to bring the XHTML side of things up to speed.

The Good

Overall, I have to say I’ve been thoroughly impressed with HAML. The syntax took a whole 10 minutes to pick up (although, I am very familiar with CSS, which probably helped). I decided to take one of our applications and convert all the views to HAML and it went of without a hitch.

Minimalist Syntax

The syntax is about as minimalist as you can get. To convert an RHTML template to HAML, you pretty much delete every repetitive or unnecessary character in your RHTML template, and there you go! Now you have HAML. Here’s a sample:

Here’s the same snippet in HAML:

Whitespace Active

HAML is “whitespace active.” This enables you to cut down on a significant portion of your code because you don’t have to close your tags. HAML closes your tags for you based on your indentation.

Beautiful XHTML

This has got to be one of my favorite part about HAML. The final output of your XHTML is always perfectly formatted with proper indentation, even across your partials! Aside from appeasing the OCD in us all, this makes it much easier when you’re scanning through your source trying to find a particular section. HAML is even smart enough to automatically lines at 50 characters for the ultimate in XHTML-viewing pleasure.

The Not-So-Good

Maybe I just haven’t put enough miles on HAML yet, but it was difficult to find negatives to using it. Nonetheless, there were a few.

Inline Tags

HAML doesn’t really have great support for code with a lot of inline tags such as <em> or <strong>. Let’s say you want to generate this code:

You can either type out the html tags, or do this:

Not really ideal. On a positive note, HAML will soon enable “filters.” This feature is currently available in trunk. Using the textile filter, you could do this:

Whitespace Active

There’s also a slight negative to the whitespace active aspect of HAML. It’s because this will probably be the biggest change for most Rails developers. None of the languages currently used in Rails utilize the whitespace. Just be careful, that’s all. Be sure to set your editor up properly (soft tabs, 2 spaces). Showing invisibles helps a lot to make sure you don’t have any “tabs” sneaking in there.

Conclusion

I’m probably only 3-4 hours into my HAML experience so far (not including writing this blog post), but I don’t see myself turning back. If you want to give it a shot, just install the plugin into your Rails application:

The great thing about it is you can mix your HAML templates and your RHTML templates, so just start off with one RHTML view template and convert it to HAML. Happy coding!

nginx (pronounced: “engine x”) is an HTTP-server that is under active development by Igor Sysoev. It runs on any nix platform, including OSX (which we’ll be using in this tutorial), Solaris, Linux, and FreeBSD. For Rails applications, it’s meant to be used to serve your static and cached files inside your rails application. The rest is handled by a mongrel_cluster. Think of it as a replacement for either of the two current popular solutions, Apache 2.2 w/mod_proxy_balancer, or Lighttpd. Both sit in front of that mongrel_cluster and serve static content.

Setup:

Install mongrel:
sudo gem install mongrel
Install mongrel_cluster:
sudo gem install mongrel_cluster
Install nginx:
curl -O http://sysoev.ru/nginx/nginx-0.3.60.tar.gz tar -xzvf nginx-0.3.60.tar.gz cd nginx-0.3.60 ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module make sudo make install sudo chmod +x /usr/local/sbin/nginx
Nginx will install to /usr/local/nginx and in there you will find the conf directory containing the nginx.conf file, the logs directory with the error and access logs, as well as the PID for the nginx process.

Once you’ve got everything installed, create a new Rails application wherever you’d like.
rails demo
Then, create a mongrel_cluster for your application. I’m going to use ports 8000 & 8001, but you can use whatever you’d like. I’ve also set the environment to production, but again, you can set that to whatever you’d like. This will create a config file located at demo/config/mongrel_cluster.yml. You can create as many mongrel instances as you would like.

Start the mongrel cluster

This can be stopped or restarted just as easily by typing:

So now your app should have it’s mongrel cluster running fine. You can test by loading up either http://localhost:8000/ or http://localhost:8001/.

Now go ahead and open up the nginx.conf file located at /usr/local/nginx/conf/nginx.conf in TextMate or your favorite editor. There is a default conf file there, but it wouldn’t hurt to back up the old one.

Paste in the following code or download a .conf file with the same info here:
worker_processes 2; error_log logs/error.log notice; pid logs/nginx.pid; events { worker_connections 1024; } http { include conf/mime.types; default_type application/octet-stream; # no sendfile on OSX uncomment #this if your on linux or bsd #sendfile on; tcp_nopush on; keepalive_timeout 65; tcp_nodelay on; upstream mongrel { server 127.0.0.1:8000; server 127.0.0.1:8001; } gzip on; gzip_min_length 1100; gzip_buffers 4 8k; gzip_types text/plain; server { listen 80; #server_name localhost; root /path_to/rails/public; access_log off; rewrite_log on; # / -> first search for local index.html then go to mongrel location ~ ^/$ { if (-f /index.html){ rewrite (.*) /index.html last; } proxy_pass http://mongrel; } # rail caching: searching first for $action.html local pages location / { if (!-f $request_filename.html) { proxy_pass http://mongrel; } rewrite (.*) $1.html last; } # serve static files directly location ~ .html { root /path_to/rails/public; } location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov)$ { root /path_to/rails/public; } # resend everything else to mongrel location / { proxy_pass http://mongrel; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }
Set /path_to/rails/public to whatever the path to your rails app is.

Once you’ve gotten your nginx.conf file saved, fire up nginx and let it rip. You start nginx by calling that executable that was created when you built from source earlier. In the example above it would be:

Sidenote: make sure Apache is turned off, it’s most likely been turned on in Personal Web Sharing under System Preferences → Sharing. Load up http://localhost, and you should see a blank Rails app from there.

Nginx is managed by sending UNIX signals to that process, similar to apache. For more info on that, visit Zhesto’s notes.

Nginx has a lot of buzz right now about being a potential solution for being the lightweight front end for mongrel_clusters. Whether or not that happens remains to be seen, but hopefully now you can help make that decision.

All credit for this article goes to Ezra Zygmuntowicz and Alexy Kovyrin for posting enough info to get started, as well as Bradley Taylor for the mongrel_cluster plugin. Please check out those blogs for more information.

Right now it’s experimental, and probably more useful in a
development environment. However, if you use it in production please
be sure to let me know of your success (or lack thereof).

Installation

Configuration

The goal was to keep the configuration as simple as possible. You
can start sending mail by adding one line to environment.rb:

However, you should probably also add a second line which sets
the value for the “HELO” command when connecting to the remote
SMTP host. The value should be your domain name.

Reverse DNS

This isn’t specific to Integral Mailer, but you should also make sure you have reverse DNS setup properly for the IP address you’re running this on. Otherwise, some mail servers will refuse to accept your mail (or give you a high spam score). Setting up reverse DNS usually involves sending an email request to your hosting provider.

Let’s assume you have a form which collects data on people, but the questions you ask on the form are dynamic. The person who fills out the form is stored in one model, while the responses are stored out in another. Your migration might look something like this:

So each person would have their responses stored in the responses table. Initially, your models would look something like this:

The Problem

The issue here is we want to add any responses belonging to a Person to its attribute hash. Lets take our above example and decide we want to have a form which asks for
name, email, and phone number. Not only would you be able to do this:

but the name, email, and phone_number attributes would actually show up in the @person.attributes hash.

The Solution

Here’s how I handled this problem. I created a method which would find all of a person’s responses. It would then add each response to the person’s attribute hash, using an underscored version of the question as the key, and the answer as the value. I then use the after_find callback to add in those attributes on the fly. Pretty simple right? Here’s the code:

The Aftermath

So there’s probably a few disclaimers I should throw in here. First of all, this obviously isn’t going to work very well for wordy questions. This isn’t very pretty:

Another big disclaimer I’d like to throw out there, is you can take some significant performance hits using after_find coupled with ActiveRecord’s associations spitting out some messy SQL queries. Think of it this way: If ActiveRecord generates 20 SQL queries to find your responses that you want (not in the above example, but perhaps in an example with more complex associations), and you pull up a collection of 1,0000 ActiveRecord objects… well, you do the math. All I’m saying is you may get to the point where you need to just write a custom SQL statement for your responses_to_attributes method to try to minimize the pain.

Why?

So why go to all this trouble of pre-loading all these attributes. Why can’t we just call each attribute individually and load it at that time. It’d be a lot less stressful on the system, sure. Different people may have particular needs for the attributes hash specifically. In my case, the ToCSV plugin uses the attributes hash to generate a CSV. By loading these dynamic attributes onto the model object, I can easily export those custom questions along with their responses to a CSV file.

If you have any ideas of your own where you think this might be useful (or if you have a better way of doing this), be sure to let me know.

Digg this article

I’ve always liked acts_as_authenticated for my authentication needs. restful_authentication is simply a more “RESTful” version of this plugin. When I realized I could continue using this same authentication system for all my authentication needs, I knew I had a winner.

Enough talking, let’s jump in! Start off by installing the simply_restful plugin:

Follow the README to get the plugin up and running. We’ll start off with an easy one. Let’s look at adding authentication to our REST API. Be sure to require authentication your controller:

That’s more or less it. Here’s where the magic happens (you’ll find this in lib/authenticated_system.rb):

What this does have your login_required before_filter re-grab your login/password if its available via HTTP Basic Auth. If you try to login through XML and you’re denied, it’ll return the proper 401 Unauthorized status.

Adding the same authentication functionality to your RSS feeds is pretty simple. The only change you need to make is to make sure that the proper status is returned for your RSS requests if the login fails. Just modify the access_denied method:

There you go, that takes care of it. Simple Basic HTTP Auth for your API and feed, all mixed in with the authentication goodness the rest of your app gets with restful_authentication.

Installation

Really simple. First install the plugin:

./script/plugin install -x http://svn.integralserver.com/plugins/simple_rcss

Then, just add this to your config/routes.rb:

map.rcss 'stylesheets/:rcss.css', :controller => 'stylesheets', :action => 'rcss'

Usage

RCSS files are placed in:

$app_root
views/
stylesheets/
stylesheet_1.rcss
stylesheet_2.rcss

While in production mode, this plugin will automatically cache your stylesheets into public/stylesheets. If you would like to pre-cache your stylesheets, you can do so with the included rake task:
rake rcss:create_cache

There are a few other rake tasks available to you as well:

rcss:remove_cache
rcss:update_cache

If you have any files in public/stylesheets/ which do not originate from app/views/stylesheets, you will lose them if you use rcss_remove_cache and rcss_update_cache. The safest thing to do is manage all your stylesheets in app/views/stylesheets. You can migrate over existing stylesheets using:

rake rcss:from_css

There is also a generator task to generate stylesheets for you:
./script/generate stylesheet Application

which will create:

$app_root
app/
views/
stylesheets/
application.rcss

You can also call certain stylesheets using :defaults from within the stylesheet_link_tag helper:
stylesheet_link_tag :defaults
This will automatically include an application.rcss as well as #{controller.controller_name}.rcss if they exist.

That pretty much covers the basics. I’ve used this on a few projects so far and it’s been working out just fine. My next step is to begin to extract commonly used code from my stylesheets and make those available through helper methods. If you have any suggestions for these, feel free to send them my way.

The problem I was having is it would redirect to the https:// protocol, but be received as http:// in the logs. This would cause an infinite loop of redirects until it finally got tired and broke.

SSL on Apache vs. Lighttpd

When you have Apache set up as a proxy to lighttpd, you have 2 options for SSL. You can either set up SSL on Apache, or Lighttpd. Others have already done a good job of explaining this, so I won’t get into it. Just know that our SSL is setup on Apache.

The problem is that in this scenario, lighttpd is completely unaware of the SSL request and handles everything as a standard request with the http:// protocol.

The Solution

What I needed was a way for Apache somehow tell Rails that the request was indeed an SSL request. Turns out that’s very easy to do. All you have to do is add the following line to Apache’s vhost entry:

RequestHeader set X_FORWARDED_PROTO 'https'

That’s it! The magic happens automatically (as I’m finding to be common with Rails) thanks to this little snippet in request.rb:

First of all, it seems like spawner/reaper are now using pid files found in tmp/pids to reference the fcgi/mongrel (yes mongrel too, more on that in a bit…) processes.

While I prefer this, things get a little tricky when using Capistrano. The challenge is that you want your PID files to persist accross releases. The trick is to setup the PID’s as a shared resource across all releases. Add these tasks to your Capistrano deploy recipe:

The next issue that I ran into was when Capistrano went to restart my app, it tried to start a Mongrel process rather than my normal FCGI process. According to the changelog, spawner now prefers Mongrel by default.

I have yet to switch over to Mongrel like all the cool kids, so I had to figure out a way to get spawner back to FCGI. Here are the examples straight from the documentation:

That pretty much wraps it up. Once I figured out what was going on, and made a few slight adjustments, everything was back up and running as it should be.

Installation

Usage

You can simply take a collection of ActiveRecord objects and apply the to_csv method to them:

Here are some different options:

For a more RESTful way of exporting a CSV, do something like this in your controller:

Go forth

That wasn’t too difficult now was it? I wrote this plugin for a very specific purpose and it fits my needs just fine. However, feel free to make suggestions. I’m open to adding additional functionality where its both reasonable and appropriate.

Digg this article