Development Blog: Viget Labs

Patrick Reagan, Development Director, June 05, 2007 1

We had a great time at RailsConf this year. Ben’s presentation went well and got a great response from the crowd that attended. I had a chance to chat with some people (both from our local group and elsewhere) about the content of the presentation, and the responses were pretty consistent.

For the developers who had faced the same issue of building a dynamic site with a large amount of static content, the solution met their needs. I ran into a lot of people who had just been creating a single controller (e.g. GeneralController) to handle all the static content for their sites. This approach works for a while, but as the static content grows – which was the case when we built the ACVA site – things quickly become cumbersome.

I also talked with others who were misled by the title and wondered “why would you use Rails to build a static site?” The answer to that is… “you don’t.” If you’re building a truly static site, Apache, Lighttpd, or Tux are your friends and will serve up static files faster than Rails can. In fact, Ben’s solution relies on a front-end web server to serve up the cached pages generated from the static site framework.

So for those that missed out, here’s what the framework allows you to do (implemented as a plugin-app):

• Upload or create content files – In typical CMS CRUD fashion you can add content directly to the ‘pages’ table through a web front-end either using a textarea or a standard file upload control. From there, the content is then immediately available in your application.


• Generate site maps – Because the page content is stored in the database and the Page model uses acts_as_tree, we’re able to traverse from the root and generate a site map for display. This design decision, along with providing modification timestamps, also helps when you need to generate the XML for use with Google Webmaster Tools and other search engines that use this site map standard.


• Provide customized page-specific variables – Again, because of acts_as_tree in the Page model, we can provide a hierarchical inheritance model for page-specific variables. Setting a variable at the parent level makes it available to all the children with the ability for each child to override the parent’s default setting.


• Search for terms in your “static” content – The framework plays well with your current search solution. If you’re using Ferret, Solr, or Hyper Estraier you can search both your existing CRUDified content and your new static content.

If you want to test it out, you can download the plugin and view the slides from the Viget site. In the near future, we’ll be pulling the code into a public SVN repository – stay tuned.

Ben Scofield, Development Director, November 30, 2006 0

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!

Patrick Reagan, Development Director, November 22, 2006 0 One of the features of Rails that makes it a great framework for building the next generation of "Web 2.0" applications is its tight integration with the script.aculo.us JavaScript library. What this means for your application is the ability to dynamically update the display based on the results of an action (in this case '/task/mark_complete'):

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:

   
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 %>

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.

Continue reading "Getting Started With RJS in Rails"

Ben Scofield, Development Director, November 21, 2006 7

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.

The Problem

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.

Continue reading "Tagging Text Automatically"

Ben Scofield, Development Director, November 01, 2006 0

Whenever you accept user-generated content, you run the risk of opening your system up to spammers. This is most well-known as a problem for blogs that allow comments; but, every relatively open site faces this challenge.

There are many potential solutions to this problem—you could write your own Bayesian filter, manually delete and blacklist IPs, or rely on an external service, for instance. For speed of development and ease of use, making use of an external service is by far the best way to go. For this post, we’re going to take a quick look at Akismet.

Continue reading "Blocking Spam in Rails Applications"