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.
Tyrant is a "meta" Rails application designed to run other Rails applications.
Tyrant was born out of our need to have non-developers work alongside us without requiring a full Rails stack running on their local machines.
Ideally, Tyrant runs (via mongrel) on a development server with multiple user directories that contain SVN working directories with Rails applications. Upon startup, these applications are listed in a user's dashboard and Tyrant provides the interface to start and stop each one. The configuration settings dictate the available port range, and as a new application is started it will grab the next one available.
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.
Recent Comments
Tony,
I understand and agree that the back-end shouldn’t output code (html code), and only content. The templates (aka views) should do the trick, but instead of having lot’s of if/else conditionals inside the view, you may just output the following content.
No information available
The template would loop in an array and put all the <li>’s inside the <ul>.
I don’t see anything wrong, nor...