FeedBurner Auto-Discovery Links in Typo

Posted by shane
on Sunday, August 27

Damien Tanner has a nice article on how to migrate Typo feeds to FeedBurner. However, to make it more complete, I added the following steps:

Too many options are a bad thing. When you give your readers a multiple range of choices such as RSS, RSS 2.0, Atom, etc., you will get chunks of readers using each format, making it hard to track subscriptions. Damien suggests redirecting these URLs to your FeedBurner URL. If you have FeedBurner’s SmartFeed option enabled, then any RSS reader supporting any format should be able to parse your feed. However, it would be better to take it one step further and only allow your readers one feed option. To do this in Typo, edit the file app/helpers/articles_helper.rb and change your auto-discovery URLs (around line 60):

feedburner_url = "http://feeds.feedburner.com/YOUR_FEED" 
. . . 

Then go to the Admin console and empty your cache. Hit your main blog page to make sure it worked:

$ curl http://yourblog.tld | grep "link rel"
You should see something like this:

Be DRY and combine your redirects into one line. For Apache:

RedirectMatch permanent ^/xml/(rss|rss20|atom)/feed.xml http://feeds.feedburner.com/YOUR_FEED
suggests this line for Lighttpd in a comment on a post by Robby Russell:
url.redirect = (”/xml/(atom|rss|rss20)/feed.xml” => “http://feeds.feedburner.com/YOUR_FEED”)

For Apache, you need to have mod\_alias loaded, and mod\_redirect for Lighttpd.

Someone should submit a patch to Typo that enables FeedBurner integration. An option can be added to the Admin site to get the FeedBurner URL. Then all the auto-discovery links can be made to point to it. I’d do it if I had more time.

Prototyping and Test Driven Development

Posted by shane
on Sunday, August 27

Test-driven development is probably the hardest of the Agile methods to get used to doing. Since Rails makes web development so easy, it is not hard to be tempted into rushing into code. But you know you feel guilty for doing it. Especially since Rails generates all those test harness files that you never touch. You know you have trouble sleeping at night because of those empty files. Is there a shortcut? The short answer: No. Write your tests. But there is a way to alleviate this burden. I think of code I write that don’t have tests as prototype code. If you want to develop that killer Web 2.0 app in no time without worrying about tests, you can do it, as long as you think of the test-free version as a prototype. Then you can always go back and re-write the entire thing from scratch with tests. I believe with the productivity gains of Rails, this is totally possible.

In terms of iterative development, the prototype can be iteration n-1. Then iteration n_ would be a complete test-driven re-write. You will learn from your mistakes in iteration _n-1 and end up with much cleaner code. Once you get used to writing tests, you will find that you are actually more productive when you write tests than when you don’t. You tend to spend less time trying to figure out one-liner bugs since good tests will help flush these out before they are a problem.

You don’t always have to get it right the first time. Artists and sculptors often go through many iterations of their work before finishing the final product. Why would software development be any different?

Have a real world job where you have to come up with an estimate and project plan? Instead of coming up with a haphazard estimate, include the prototype in the estimation phase. In many cases, your client or boss wouldn’t mind giving you a little extra time to come up with a more accurate estimate. You will end up with a better idea about the pitfalls of your project.

Acts As Most Popular Rails Plugin

Posted by shane
on Friday, August 04

Make your models feel like they are in high school again. This plugin retrieves the most frequently occurring values for each column. It adds methods of the form most\popular\[pluralized\_column\_name]. You can control how many results you get with the :limit option. The default limit is 5.

For example, lets say you have a Person model that has a name, age, and city.

class Person < ActiveRecord::Base
  acts_as_most_popular
end

This will give you the methods:

  • most\_popular_names
  • most\_popular_ages
  • most\_popular_cities
For example, lets say you have six people in your database. Three are from Chicago, two from New York, and one from Hartford. Then, most\_popular_cities will give you:
Person.most_popular_cities
=> ["chicago", "new york", "hartford"]

Each most\_popular method returns an array of the type of the column. Check out this unit test for more examples.

Install with:
script/plugin install http://shanesbrain.net/svn/rails/plugins/acts_as_most_popular

Feedback appreciated.

Update: I can’t take credit for the name of this plugin. Someone on the #rubyonrails channel came up with it.

Update: The author of Ruby Inside suggests that this could be used as some sort of Calculation. I think it could easily be made a mode Calculation instead of an Acts As plugin, since popularity is basically the mode in decreasing order. What do you guys think?