Midnight Oil

Update (2007/07/11): It seems that I was pretty far off on this one. I have been suspicious for a while, and should have updated the post with some of my thoughts, but I didn’t. Lucky for me, Zoom, in the comments, took me to task.

Apparently, at some point about two years ago, Google decided to stop refreshing the Google Directory and updated the PageRank algorithm to discount any gains from DMOZ. However, this seems only to affect sites listed after they did this. The end result is that getting listed on DMOZ now seems to have no effect on your score.

Part of the reason my findings were so skewed is that the categories I was looking in were pretty static. They had not changed much in the two years that Google was not updating. So, I never checked the PageRank of a DMOZ listed site of less than two years. In my defense, there seems to be no direct way to see when a site was listed on DMOZ. However, using a more dynamic category might have helped.

Bottom line: DMOZ seems to have absolutely no effect on your PageRank score for newly listed sites. Unless you have a time-machine, it won’t do anything for you. I’d still submit your link, as someone might just stumble upon it by browsing DMOZ, but definitely don’t stress over getting in. There are more important things to worry about.

Original (and flawed) article follows:

---

While looking for ways to promote our Dungeons and Dragons website, I stumbled upon the Open Directory Project, also known as DMOZ. I had heard from an SEO expert (see my earlier post on Atlanta Web Entrepreneurs) about submitting a link to DMOZ. However, he just sort of mentioned it in passing. Luckily, I happened to jot down the 4 letters. I guess he just assumed we all already knew about it.

While following up on those notes, I went to the DMOZ site and started browsing around their Roleplaying section. Most of the links are good, and some are excellent. On the other hand, there is a sprinkling of sites that are just plain dumb. Not that I’m in any position to judge anyone else, but seriously folks, an entire site devoted to discussion of how to roll a d3? Funny? Yes. An unbeatable resource for RPG players worldwide? Um, no.

On a whim, I decided to run these sites through a PageRank checker. Imagine my surprise when they all turned up a PageRank of 6! This is equal to the score for The Wizards of the Coast homepage. Sit back a moment and process this: a single page with an ugly background and a crappy poll devoted to how to roll a d3 has the same PageRank as the homepage for the publisher of Dungeons and Dragons, the most popular tabletop RPG ever.

Don’t believe me? Then check it out for yourself:
PageRank Checker
How do u D3?
Wizards of the Coast

For fun, I decided to compare the sites in Alexa. Now, Alexa is totally separate from PageRank, and there is no reason to expect any sort of direct correlation. However, it’s reasonable to expect an indirect correlation. After all, high traffic probably implies that there are a lot of links pointing to you, and the more traffic you receive, the more likely you are to receive new links. Reasonable, right?

Anyways, according to Alexa, wizards.com has a reach of 0.03%, meaning that of all the users measured by Alexa, 0.03% of them visited wizards.com. If you think about it, that’s a perfectly respectable number. Predictably, the d3 poll site was not even ranked. Basically, they are orders of magnitude apart in actual traffic. A candle against the sun.

So, what’s the catch? How can they have the same PageRank? The PageRank algorithm is based on the number of incoming links and their respective PageRank scores. If you have highly ranked incoming links, then you are blessed with some of the value of those links. The more you have and the better they are, the higher ranked you are. So, maximizing PageRank is a fairly simple process (in theory): get popular people to link to you.

DMOZ matches up perfectly with this, for one main reason: a single link on DMOZ translates to dozens, perhaps hundreds of links elsewhere. This is due to the fact that DMOZ publishes their directory freely as an RDF feed. Websites are encouraged to pick up the feed and repackage or republish it as desired, with very few restrictions. So, get a link on DMOZ, and you automatically (with patience) get a link on all the sites that pick up their feed.

I checked the d3 website’s incoming links according to Google. To do this, just go to Google and type in link:www.somesite.com. Looking at the results, it’s easy to see that pretty much all of the highly ranked incoming links are repackaged feeds from DMOZ.

While a bunch of free links is already a great thing, there is one massive cherry sitting on top of the pie: Google itself republishes the DMOZ feed as Google Directory! As you can probably imagine, a link from Google to you is a massive PageRank boost, due to Google’s own maximized PageRank value. It’s like getting Batman as a character witness at your trial. His word carries a lot of weight.

Unfortunately (or luckily, depending on which side of the fence you’re on), getting a link in DMOZ is not exactly easy. It’s not hard, either, but it seems to take a while. As of writing this, I have yet to actually get Obsidian Portal listed. Still, if you’re looking for a way to get your site noticed, I can think of no better way to spend the next half hour than by browsing DMOZ, finding the perfect category., and submitting your site. If you’ve got quality content and your site is truly worthwhile, then all you have to do at that point is wait.

Good luck getting listed

Update (2007/05/29): From what I’ve been reading, expect a very long wait to get listed. Apparently it can take months or even years to finally appear in the DMOZ listings, mainly due to a huge backlog of submissions and very few editors. Still, there are worse ways to spend a half hour of your time than taking a long-shot at what could end up being the perfect link for your site.

Update 2 (2007/05/31): I have been accepted as the editor for the Games - Roleplaying - Software category! My first order of business was to list Obsidian Portal along with the other two sites that were included as part of my application. I had to apply twice in order to be accepted, but the entire process took under a week. So, if you have a site that you want listed, and the correct category has no editor, then your first order of business should be to apply for that category. Otherwise, it will probably take several months in order for someone to get around to actually reviewing your site.

Note: I was completely honest about my affiliations, as well as my intentions, and they apparently did not penalize me for it. So, be honest, be sincere, and good luck!

As we have mentioned numerous times, we here at Aisle Ten prefer vendor branches for installing our plugins. We have found that most plugins require some tweaking or modification in order to put them use exactly as we want. Rather than being a strike against the plugin architecture, I count this as one of its greatest strengths. Plugins are usually simple enough that it is an easy task to understand what they do, and then modify them to support exactly what you need.

In my previous post, I gave directions on how to create a vendor branch for a plugin. What was missing was a good explanation of how to actually upgrade when a new release version comes from the vendor. Today I’ll cover that, using the real-life example of moving from acts_as_solr 0.7 to 0.8.5. All examples will relate to acts_as_solr where the version we currently have is 0.7 and the new version we want is 0.8.5.

Update:Thanks to Chris in the comments, there may be a way to do all of this “the correct way” Skip down to the bottom to see.

What the SVN book recommends

The definitive source for info regarding subversion is the book, Version Control with Subversion. It’s available online for free. If you haven’t skimmed through it, now’s the time.

In the section on vendor branches, they give a very terse explanation of how to go about this:

To perform this upgrade, we checkout a copy of our vendor branch, and replace the code in the current directory with the new libcomplex 1.1 source code. We quite literally copy new files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atop our existing files and directories. The goal here is to make our current directory contain only the libcomplex 1.1 code, and to ensure that all that code is under version control. Oh, and we want to do this with as little version control history disturbance as possible.

After replacing the 1.0 code with 1.1 code, svn status will show files with local modifications as well as, perhaps, some unversioned or missing files. If we did what we were supposed to do, the unversioned files are only those new files introduced in the 1.1 release of libcomplex–we run svn add on those to get them under version control. The missing files are files that were in 1.0 but not in 1.1, and on those paths we run svn delete. Finally, once our current working copy contains only the libcomplex 1.1 code, we commit the changes we made to get it looking that way.

Why it doesn’t work

The main problem with this approach has to do with files and directories that are deleted between versions. At the end of the branch upgrade process, two things you want to have are:

• current contains all and only the code from 0.8.5. In other words, current is an identical copy of 0.8.5 from the acts_as_solr repository
• Our repository contains the history of the transition from 0.7 to 0.8.5.

Getting the second one is a little tough, and getting them both together is very tricky. From the subversion book:

We quite literally copy new files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atop our existing files and directories. The goal here is to make our current directory contain only the libcomplex 1.1 code

What about deleted files? Copying the new files in or exploding the tarball will cover changed and added files, but any files or directories that were deleted will show up in svn as unmodified Using this method as described, it is impossible to know whether a file listed as unmodified is actually present in 0.8.5 without manually verifying its existence. For acts_as_solr this would be an annoyance. For a project with thousands of files, it would be a nightmare, and the human operator would surely make mistakes, meaning what you have in your repository would not be an exact copy of the vendor’s release. That’s about the worst possible outcome.

Solution 1: Strip out all except directories and .svn

One possible solution is to “clean” your working copy before exploding the tarball. In this case, you write a script that walks your working copy deleting everything except the directories and their .svn subdirectories. Now, when you explode the tarball and get a list of changes, it will tell you all the files that are now missing (and therefore are not part of the release). Then it’s easy to follow the book’s instructions and remove them from svn.

Why it doesn’t work

Besides the fact that I have not been able to find a script that does what I’m describing, it doesn’t solve the problem of deleted directories. If, during the change in versions, entire directories have been deleted, this method will not detect that. After running the script, you’re left with an empty skeleton of your current version. Exploding the tarball will overlay the directory structure of the new version, but any deleted directories will still be present. They’ll be empty, but they’ll still be there. Again, it is impossible, without manual intervention, to determine if any particular empty directory still belongs. This is a much better situation than before, where we had to check every unmodified file, but it’s still an annoyance, and allows for human error. On to the next solution…

Solution 2: Merge against the vendor’s repository

When I thought of this one, I was very excited. It should conceivably allow me to use svn to handle all the dirty work, which is what it does best. If your vendor allows you read access to their svn repository, you should be able to do a merge (diff) between your current version, and their newest version, and apply that to the current. It’s a standard merge operation saying “What do I have to do to make my copy look like theirs?”

Why it doesn’t work

Simply enough, svn does not allow you to merge between two different repositories. Why this is, I have no idea, but they must have their reasons. So, this idea takes a bullet to the head.

Solution 3: Import, then merge against your repository

When I realized that Solution 2 would not work, it occurred to me that I could just import the newest release into my repository and then merge with that.

Step by step:

1. Do an export from the vendor’s repository (or explode the tarball) of the latest version to somewhere local (let’s say temp_latest)
2. Import this code into your repository: svn import temp_latest http://your/repo/here/vendor/some_package/latest
3. Check out current to somewhere: svn co http://your/repo/here/vendor/some_package/current temp_current
4. Merge and apply: svn merge http://your/repo/here/vendor/some_package/current http://your/repo/here/vendor/some_package/latest temp_current
5. Commit the changes: svn ci temp_current
6. Bonus points - verify the integrity: svn diff http://your/repo/here/vendor/some_package/current http://your/repo/here/vendor/some_package/latest If there are no differences, then current now contains an exact copy of the new release. Good job!
7. Tag the new current: svn copy http://your/repo/here/vendor/some_package/current http://your/repo/here/vendor/some_package/2.0

At this point, you can copy the new tag to your trunk and deal with any conflicts. This is all covered in the SVN book.

Why it works…but kind of sucks

This is my preferred solution, but it’s not perfect. My main issue is that each time it’s done, you have to import a brand new copy of the code into your repository in order to do the merge. This is pretty wasteful from a storage perspective, and can be prohibitive if the import is sizeable and/or the vendor puts out new releases on a fast schedule. It won’t be a problem for (most) plugins, but for larger projects it is probably impractical.

Update: In hindsight, I don’t think this actually works the way I intended. When you import the new files, svn does not realize that they’re in any way related to the files in current. Therefore, when you do the merge, rather than applying changes to the old files, it simply deletes them and adds the new ones. In other words, the merge simply replaces all the old files with the new ones, rather than inspecting and recording the changes that occurred. This process will discard any changes that you’ve made, making the whole process fairly worthless.

Going from 0.7 to 0.8.5

We chose solution 3, import and merge, for handling the move from 0.7 to 0.8.5 of acts_as_solr. I am happy with the result, as I noticed during the process that the plugin had been seriously re-organized, resulting in the deleting and moving of many files and directories. Had we tried any of the other solutions, it would have been a painstaking process figuring out where things had moved. With the route we took, svn handled all of that.

Once I decided to go that route, the entire process took about 15 minutes. There were no conflicts to deal with when merging to trunk, but that is probably due to the fact that the only changes I made resulted in patches that were accepted back into the acts_as_solr trunk.

Think you can do better?

These are the only solutions I could come up with. Some flat-out don’t work, while others have their plusses and minuses. If you have a suggestion for a better way, please post a comment and I’ll try to include your idea into the list.

Update: svn_load_dirs

What I haven’t mentioned up until now was svn_load_dirs. This is a perl script that is supposed to help manage vendor branches. I have fumbled with it in the past and simply gotten frustrated. I just couldn’t find good documentation.

However, Chris in the comments has posted a link to an excellent post detailing svn_load_dirs, and I recommend everyone check it out. The next time I have to do a vendor branch update, I will try following these directions.

So you’ve got the Ajax CSS Star Rating System with acts_as_rateable (A MUST READ). Now you want to list the top rated objects and how many votes they’ve received. Fortunately Ruby on Rails and ActiveRecord makes this fairly easy by using an object’s find method.

Code

@TopRatedCampaigns = Campaign.find(:all, :select => "campaigns.*, avg(ratings.rating) AS rating, count(ratings.rating) AS votes", :joins => "LEFT JOIN ratings ON campaigns.id = ratings.rateable_id", :conditions => "ratings.rateable_type = 'Campaign'", :group => "ratings.rateable_id", :order => "rating DESC, votes DESC", :limit => 5)

Next in your view you will simply want to loop through each item and display it as a list:

< % unless @TopRatedCampaigns.nil? -%> <b>Top Rated Campaigns</b><br /> <ol> < % @TopRatedCampaigns.each do |x| -%> <li>< %= link_to h(x.name), campaign_url(:id => x._id) -%> (< %= number_with_precision(x.rating, 1) -%>)</li> < % end -%> </ol> < % end -%>

Note: the campaign_url is defined in the config\routes.rb. This is optional, but I like using named routes in case you ever decide to change from using Rails standard routing. It’s also less code and a little cleaner than listing out the controller, action, and id.

map.campaign 'campaign/:id', :controller => 'campaigns', :action => 'show'

Results

Based on today’s stats here are the top rated campaigns from Obsidian Portal:

Top Rated Campaigns

1. Kensing (5.0)
2. Arkanopolis (5.0)
3. Hoarding Knowledge (5.0)
4. Marvel 1984 (4.3)
5. Beeropia (3.0)

Issues

The issue with this current example is if someone sets up a new campaign and rates it a 5 it will be at the top of the list even though a campaign with a 4.8 rating and 20 votes should probably be at the top of the list.

One solution would only allow campaigns with more that 5 votes to be displayed. This would be accomplished by changing the conditions in the find method. Another solution would be to somehow normalize the ratings per vote. I have not implemented either of these yet, but any feedback would be greatly appreciated.

References

Props to Patrick Crowley at moko.labs for his help with the setting up the find method.

If you’re here, then you’re trying to figure out how to serve out an RSS or Atom feed from your Ruby on Rails application. You’ve probably already read a post by Ryan Daigle covering the basics of using resource_feeder to do exactly what you want. After all, Ryan’s post is the #1 hit on Google for resource_feeder.

Unfortunately, there are a few extremely important points that are curiously absent from the posting regarding polymorphic URLs. For those that don’t know, polymorphic URLs are…well I don’t know either. All I know is that it has something to do with the routes.rb file and named routes. For my rails project, I luckily (by accident) had one set up for the first RSS feed I tried to create. For the second, no such polymorphic URL existed, causing it all to come crashing down.

The problem is due to the fact that each item in the feed is expected to have a URL. If you’re lucky enough to have set up your routes correctly, the URL will be automagically determined. If not, then you get a cryptic error about polymorphic URLs. There may be a way to create a URL to each item in the feed, but resource_feeder simply cannot figure it out automagically.

Luckily, resource_feeder was designed to allow you to skip polymorphic URLs until you can figure out what the heck they are and how they work. If that’s the boat you’re in, then read on and I’ll explain.

1. Read the howto on Ryan’s Scraps

Ryan does a great job of explaining the main concept of resource_feeder. I even borrowed his example model object, Post. What I cover here are just the frustratingly absent portions that bugged me.

2. Get the plugins

script/plugin install http://dev.rubyonrails.org/svn/rails/plugins/simply_helpful/ script/plugin install http://dev.rubyonrails.org/svn/rails/plugins/resource_feeder/

Of course, we here at Midnight Oil always prefer explicit vendor branches over the basic plugin installation. Spend 10 minutes today and save countless tomorrow.

3. Add the action to your controller

Using the standard blog post example for this howto, here’s how you would add an RSS feed for your blog postings:

class PostsController < ApplicationController def rss render_rss_feed_for Post.find(:all, :order => 'created_at DESC', :limit => 10) end end

However, this assumes that you’ve got a title and description field in your model, and you also have a polymorphic URL for Post objects in your routes.rb file. If you’re like me, you might have one or two of these, but not all, and especially not the route. It’s something on my list to add tomorrow

3.5 Add the real action to your controller

class PostsController < ApplicationController def rss render_rss_feed_for Post.find(:all, :order => 'created_at DESC', :limit => 10), { :feed => { :title => 'Recent Posts', :link => url_for(:controller => 'posts', :action => 'list', :only_path => false), :pub_date => :updated_at }, :item => { :title => :name, :description => :tagline, :link => Proc.new {|post| url_for(:controller => 'post', :action => 'show', :id => post.id)} } } end end

Note that it’s not too different from the original example, but it has fleshed out a few key points. The true magic happens in the :link part of the :item hash. resource_feeder will accept a Proc object as the value for :link. This Proc object is passed the “resource” in question when it is called. The resource passed is the model object being rendered as the item for the RSS feed, in other words, the items in the list passed as the first argument to render_rss_feed_for. In our example, each “resource” is a Post object. With our Post object in hand, it’s quite easy to create a URL using url_for.

As to the other items, this example assumes that you have :name instead of :title and :tagline instead of :description for your Post objects.

4. Have fun!

At this point, you should be able to create your RSS feed without worrying about polymorphic URLs or any such business. They’re probably super-easy to create, much easier than what I’ve described, but I just don’t know.

Also, this should all be applicable to the Atom feeds as well. I just used RSS as my example, since Ryan already covered the overlap between RSS and Atom as far as resource_feeder is concerned.

CSS Star Rating Systems are all the rage now. Komodo Media brought this idea to the web’s attention with their post CSS Star Rating Redux. This tutorial will show you how to bring this rating system to Ruby on Rails

Example

Several other websites have taken similar approaches:

• Jluvip.com
• Masuga Design
• MODx plugin
• Wordpress Plugin

So how do I get this to work with Rails?

I tried implementing David Naffis’ post “Ruby on Rails, Ajax & CSS Star Rating System”; however, I ran into several issues.

1. Limited to one rating per page
2. Limted to one type of object
3. RJS didn’t seem to work
4. Didn’t work with objects that were subclassed

Lets get started!

Note: where ever you see the text “Myobject“, you will want to replace this with the class name of the object that you are rating.

1. Install the acts_as_rateable plugin

piston import http://juixe.com/svn/acts_as_rateable/ vendor/plugins/acts_as_rateable

Note: We use vendor branches for plugins, not script/plugin install so that we can make modifications to the plugin (if needed) and easily update the plugin to the latest revision while keeping the patches that we have created.

2. Create the Migration

script/generate migration add_acts_as_rateable_plugin

file:db\migrate\xxx_add_acts_as_rating_plugin.rb

class ActsAsRateable < ActiveRecord::Migration def self.up create_table "ratings", :force => true do |t| t.column "rating", :integer, :default => 0 t.column "created_at", :datetime, :null => false t.column "rateable_type", :string, :limit => 15, :default => "", :null => false t.column "rateable_id", :integer, :default => 0, :null => false t.column "user_id", :integer, :default => 0, :null => false end add_index "ratings", ["user_id"], :name => "fk_ratings_user" end def self.down drop_table :ratings end end

3. Update your existing Model

You will need to include the acts_as_rateable at the top of your class file.

class Myobject < ActiveRecord::Base acts_as_rateable ... end

Note: if you are using this with models that are subclassed you will want to put the acts_as_rateable in the parent class only.

4. Create the Ratings Controller

David Naffis’ post Ruby on Rails, Ajax & CSS Star Rating System started me off in the right direction; however, the ratings were not working for classes that were subclassed. Notice the function def get_class_by_name. This function allows the rating controller to find the base class and set the rating at the base class level.

Also note the before_filter :login_required. This verifies that the user is logged in before it runs the rate function. The function login_required is part of the acts_as_authenticated plugin and must be patched in order to work properly with the Ajax request. The patch for acts_as_authenticated is explained in step 8.

script/generate controller ratings rate

file: app\controller\ratings_controller.rb

class RatingsController < ApplicationController before_filter :get_class_by_name before_filter :login_required def rate return unless logged_in? rateable = @rateable_class.find(params[:id]) # Delete the old ratings for current user Rating.delete_all(["rateable_type = ? AND rateable_id = ? AND user_id = ?", @rateable_class.base_class.to_s, params[:id], @current_user.id]) rateable.add_rating Rating.new(:rating => params[:rating], :user_id => @current_user.id) render :update do |page| page.replace_html "star-ratings-block-#{rateable.id}", :partial => "rate", :locals => { :asset => rateable } page.visual_effect :highlight, "star-ratings-block-#{rateable.id}" end end protected # Gets the rateable class based on the params[:rateable_type] def get_class_by_name bad_class = false begin @rateable_class = Module.const_get(params[:rateable_type]) rescue NameError # The user is messing with the content_class... bad_class = true end # This means the user is doing something funky...naughty naughty... if bad_class redirect_to home_url return false end true end end

5. Create the Rate Partial

Again David Naffis’ post Ruby on Rails, Ajax & CSS Star Rating System started my off in the right direction and Igvita’s post Rails 4-State Ajax & CSS Star Rating helped demonstrate out to keep this partial DRY. As usual, I have expanded on both.

file: app\views\rating\_rate.rhtml

< % @convert = %w[one two three four five] %> <div id="star-ratings-block-<%= asset.id %>" class="star-ratings-block"> < %= number_with_precision(asset.rating, 1) %>/5 Stars (< %= asset.ratings.size %> votes)<br /> <ul class='star-rating'> <li class='current-rating' style='width:<%= (asset.rating * 30).to_i -%>px;'> Currently < %= number_with_precision(asset.rating, 1) %>/5 Stars. </li> < % 1.upto(5) do |x| -%> <li> < %= link_to_remote( "#{x}", { :url => { :controller => "ratings", :action => "rate", :id => asset.id, :rating => x, :rateable_type => asset.class.to_s } }, { :class => "#{@convert[x-1]}-stars", :name => "#{pluralize(x,'star')} out of 5", :title => "Rate this a #{x} out of 5" } ) %> </li> < % end -%> </ul> </div>

Notice: the div is unique ids based on the object’s id (ex: star-ratings-block-1, star-ratings-block-2, …) so that you can include the partial multiple times on a page for multiple objects (currently must be of the same class). This works specifically for the “list” view.

6. Including the Partial

Now that you’ve created the partial, you can simply include it in the view of the object that you will be rating.

< %= render :partial => "rating/rate", :locals => { :asset => myobject } %>

7. Make it pretty with CSS

At this point you will have a list of numbers that you can click on to set the rating. Using the star_rating.gif image and css from Komodo Media

.star-rating, .star-rating a:hover, .star-rating a:active, .star-rating a:focus, .star-rating .current-rating{ background: url('/images/star_rating.gif') left -1000px repeat-x; } .star-rating{ position: relative; width: 150px; height: 30px; overflow: hidden; list-style: none; margin: 0; padding: 0; background-position: top left; } .star-rating li{ display: inline; } .star-rating a, .star-rating .current-rating{ position: absolute; top: 0; left: 0; text-indent: -1000em; height: 30px; line-height: 30px; outline: none; overflow: hidden; border: none; } .star-rating a:hover, .star-rating a:active, .star-rating a:focus{ background-position: center left; } .star-rating a.one-stars{ width: 20%; z-index: 6; } .star-rating a.two-stars{ width: 40%; z-index: 5; } .star-rating a.three-stars{ width: 60%; z-index: 4; } .star-rating a.four-stars{ width: 80%; z-index: 3; } .star-rating a.five-stars{ width: 100%; z-index: 2; } .star-rating .current-rating{ z-index: 1; background-position: bottom left; } .star-ratings-block { font-size: .75em; text-align: center; width: 100%; }

8. Patch for acts_as_authenticated

As mentioned in Step 4 the acts_as_authenticated plugin must be patched to work with Ajax requests.

If you have already installed the acts_as_authenticated plugin you will need to patch it in 2 locations because the acts_as_authenticated plugin is a code generating plugin.

8A. First we’ll patch the plugin itself

The following code is inserted at line 70 into the access_denied method

file: vendor\plugins\acts_as_authenticated\generators\authenticated\templates\authenticated_system.rb

... accepts.js do render(:update) { |page| page.redirect_to(:controller => '/account', :action => 'login') } end ...

I have made a patch available for download: acts_as_authenticated Ajax Patch

8B. Second we’ll patch the lib file that the plugin generated

This is were we add the same patch to the existing lib file that was created by the acts_as_authenticated plugin if you have already installed it into your rails app. This is the exact same code as shown in 8A. In this case I will show you the whole code for the access_denied method.

file: lib\authenticated_system.rb

def access_denied respond_to do |accepts| accepts.html do store_location redirect_to :controller => '/account', :action => 'login' end accepts.js do render(:update) { |page| page.redirect_to(:controller => '/account', :action => 'login') } end accepts.xml do headers["Status"] = "Unauthorized" headers["WWW-Authenticate"] = %(Basic realm="Web Password") render :text => "Could't authenticate you", :status => '401 Unauthorized' end end false end

9. Test Cases

Finally it wouldn’t be a rails app if you didn’t include the test. Below you’ll find two test to confirm that the rating system works and that the user must be logged in to rate an object.

# Test campaign rate def test_campaign_rate @request.env['HTTP_REFERER'] = '/myobject/list' login_as(:jdoe) post :rate, {:id => 1, :rateable_type => "Myobject", :rating => 5 } assert_equal 5, Myobject.find(1).rating end # Test campaign rate - make sure you must be logged in def test_campaign_rate_unsuccessful_if_not_logged_in @request.env['HTTP_REFERER'] = '/myobject/list' post :rate, {:id => 1, :rateable_type => "Myobject", :rating => 5 } assert_equal 0, Myobject.find(1).rating end

Out in the wild

Here’s where you can go check it out on the website Obsidian Portal http://www.obsidianportal.com/campaigns/list.

Note: As mentioned above the rating table uses a user_id to make sure that there is only one rating per user per object.

References

http://komodomedia.com/blog/index.php/2006/01/09/css-star-rating-part-deux/

http://komodomedia.com/blog/index.php/2007/01/20/css-star-rating-redux/

http://swik.net/Rails/Dave+Naffis+-+Rails,+Ruby,+Randomness/Ruby+on+Rails,+Ajax+&+CSS+Star+Rating+System/kqn0

http://www.igvita.com/blog/2006/09/02/4-state-rails-ajax-css-rating/

Alternatives Ideas

http://www.robarov.be/rate/

http://www.robarov.be/rate2/

Update 2007-11-30: All code corrections from the comments have been integrated into this article..

Recently, I went to a meeting of the Atlanta Web Entrepreneurs. They sponsored a presentation by John Sherrod of Primedia regarding Search Engine Optimization (SEO).

All in all, it was a good talk, and I didn’t feel too sleazy for being there. I was worried that an SEO talk would devolve into discussions of how to fool Googlebot into putting you at the top of the list for keywords like ’stud’ and ‘teen.’ Luckily, John stressed one main point on how to best climb the charts: provide high quality, original content that has value to your readers.

Beyond that, he gave many good tips that are applicable across a wide variety of sites. I’ll list off the ones that I was quick enough to write down.

John’s Tips

Make sure your links are spider-friendly

When the search engine spiders reach your page, they will rely on you to navigate them around. The only way they can find their way to all your pages is if there are links providing navigation to the each page. Also important, these links should be text links, not flash. The text of the link helps the spider identify the keywords to associate with the material on the page. Further, some links are incomprehensible, such as Flash or Javascript links. The more plain text you have, the friendlier it is to the spider.

Avoid URLs with lots of query string variables

I can’t say much to this one, since I don’t know how the spiders work. John, however, claims that they do not like URLs with lots of query string variables. In any case, these URLs are definitely not friendly to users, and they look ugly in a search result. Instead, allow the URL to express some sort of organization of your site. For example, compare the following two URLs:

http://mysite.com/products/jewelry/gold/diamond-tennis-bracelet

http://mysite.com?cat=44&subcat=92&prodId=2412145

Which one is more descriptive? They could be talking about the same thing, but it’s impossible to tell from the URL.

In the Rails world, URLs like this are fairly easy to achieve, thanks to routing. By implementing a few routes, you are able to clean up your URLs and make them look nice and pretty. Take a quick look at the official manual on routing and you’ll see just how easy it is.

On Obsidian Portal, we are trying to use nice, easy to read URLs for as much as we can. Currently, we’re not doing as well as we could, but that’s mainly because we have so many features we’re trying to implement. Making URLs look pretty is not exactly at the top of the list. However, we have had some success with campaigns and game content. For example, http://www.obsidianportal.com/campaign/kensing takes you directly to my campaign, called Kensing. In another example, http://www.obsidianportal.com/game_contents/show/memory-steel, takes you to an item I created called memory steel. That URL could use some cleanup, but you get the idea.

Unique <title> tag on every page

The search engines place a lot of weight on the words they find inside the title tag. So, make sure every page has keywords in the title. Personally, I am not a big fan of long, jumbled titles that are just a mish-mash of keywords. Instead, give each page a meaningful title that happens to contain 1 or 2 keywords related to the material presented on the page. This will give it a nice appearance in the search engine result pages.

Establish a baseline for your current stats

Before you can get better at anything, you need to know where you currently are. For search engines and page views, you need to establish your current baseline and then track your stats over time. Probably the easiest way to do this is by setting up a Google Analytics account. It provides a nice graphical view of how you are doing over time.

use link: on your competition

This is an excellent strategy for finding out why your competition ranks better than you. Go to Google and enter:

link:your.competitors.site.com

This will return a list of all the links (that Google knows about) to your competitor’s site. You may discover that they have several high-ranking incoming links that could also apply to you. Track these places down and see if you can get yourself listed there as well.

New friends and plans for next month

Besides listening to the SEO presentation, I also met a few Ruby on Rails developers here in Atlanta. Calvin Yu and Neil Green are members of the ATLRUG (Atlanta Ruby Users Group) and they’re working on a new site, but they asked me not to discuss their project just yet, so I’ll keep it under wraps.

Next month’s meeting will be a round-table discussion of various web technologies (such as RoR). I cornered the organizer after the meeting and offered to sit in as a RoR “expert.” Just don’t tell him how little I know