UPDATE: May 24th, 2007
This post is now woefully out of date; since it was written, several excellent mocking libraries have been released, and some testing frameworks include mocking functionality of their own. Watch the Four Labs blog for an updated version of this, coming soon!
Earlier this week I wrote about LiteSpeed. Besides potentially being expensive, it also requires having your own server or VPS.
Another option, great for traffic-moderate sites, is Media Temple’s Grid Server (GS). The basic set up costs $20/month and there is an option to add a 64 MB Rails container. All users appear confined to a chrooted environment, which is great because other users have no way of accessing your files, especially those hard-coded database passwords. For additional money, you can allocate more memory to the Rails container: $25/month for 256 MB and $75/month for 1 GB.
Creating a GS account is pretty fast and easy. About thirty minutes after entering my contact and billing information, I received my GS login information. The following outline describes how to deploy your Rails application.
# cd into the rails container
cd $HOME/../../containers/rails/
# All files should be readable
find . -type f -exec chmod a+r {} ;
# All directories should be executable and readable
find . -type d -exec chmod a+rx {} ;
In the long run, it may be more flexible and cost-effective to go the VPS route if you have, or want to learn, the Linux side of things; but, if that isn’t your thing, the Grid Server is a good deal.
References
As RoR becomes more mainstream, hosting a Rails application in a production environment becomes increasingly important. There are numerous tutorials explaining how to cobble together mongrel, apache, lighttpd, fastcgi, and friends, but the amount of configuration can be daunting.
Why go to that much trouble when LiteSpeed “Just Works"™? For a basic “Hello World” application, performance compares very well to the cobbled together systems, and installing it takes less than five minutes. To summarize the screencast, here are the ten essential steps for implementing a name-based virtual host running on an Ubuntu server, although this will work on any OS supported by LiteSpeed:
The downside is there are two versions of LiteSpeed: free as in beer and enterprise. As you know, anything with the word “enterprise” associated with it is generally expensive and LiteSpeed is no different. However, for most medium traffic sites the free version should work well, and if it is a high traffic site you can probably afford the cost or use multiple servers.
Punch it, Chewie!
References
def mark_complete
begin
@task = Task.find(params[:id])
@task.task_status_id = TaskStatus::COMPLETE
@task.save
rescue ActiveRecord::RecordNotFound
render :nothing => true
return
end
render_text @task.status.description
end
Adding this code in a view template is all we need to have our display automatically update:
This works great for those times when we only need to update a single DOM element on a page. What about when we need to update multiple pieces of content on the same page? One solution that has worked quite well for us is the use of RJS templates in Rails.Status: <%= @task.status.description %>
<%= link_to_remote 'Mark as Complete', :update =>, 'task-status-' + @task.id.to_s, :url => {:controller => 'task', :action => 'mark_complete', :id => @task %>
Classifications are important; we do better as users when we can use a well-structured classification scheme to find information we’re looking for. In the web 1.0 world, that played out in a hierarchy imposed by site designers (typified in the eternal sitemap) that the audience was forced to work with. Web 2.0 saw a move away from this predefined architecture and towards audience-defined taxonomies (sometimes called folksonomies) built on tags - end users associate tags with pieces of content, and use various mechanisms to navigate between similarly-tagged items.
Tagging is a great strategy in certain circumstances, but it has a few important drawbacks. The one we’ll talk about here is the blank-state problem: if you’re relying entirely upon the audience to generate your tags, then new content in a system suffers an inherent disadvantage. When a browser comes to the site, they’ll explore the existing tag architecture, but they won’t find the new content (since it hasn’t been tagged yet). They may still be able to find it via some other mechanism (search, for example), but unless they then tag it the content will stay buried. It’s a rich-get-richer situation - well-tagged content will be found and tagged more often, while under-tagged content will not be found and will remain under-tagged.
at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.
We host all of our open source projects on GitHub, at http://github.com/vigetlabs
We are Viget Labs and we plan, design, build, and market web sites that we're proud of. Terms & Conditions
Recent Comments
For translating strings you can use Rails I18n backend instead of using inflectors.
The `typus_human_name` is a patch to fix a problem in `human_name` [1].
[1] https://rails.lighthouseapp.com/projects/8994/tickets/2120-humanize-and-human_name-dont-separate-words