Rails Envy

Jason and I are currently in Chicago for Rails Edge where today we just premiered a new Rails commercial produced by Jason Hawkins. We will be releasing 5 commercials over the next month, 2 .NET, 1 PHP, 1 Cold Fusion, and 1 DJango. Don't worry, after these few we're all done, so don't spam us about how you're sick of mac ad parodies.

If you don't get the "OOPS" reference you should really watch Creating a Weblog in 15 minutes, a screencast by DHH which will give you a glimpse at the power of Ruby on Rails. Stay tuned, we'll be releasing one more during RailsEdge tomorrow.

Here we are with the third commercial in the series(Part 1, Part 2) where we continue with the PHP guy. Apologies to all 3 of you who were hoping for Fortan.

Gregg Pollack and Jason Seifer from RailsEnvy present:

Ruby on Rails vs PHP - Organization - ad #3 of 4

We just wanted to say thanks again to Jason over at Make. Film. Work. for the great video work.

We're also really sorry but we had to turn on moderation for comments because of all the trolling. We're just having fun, guys, try not to take it too seriously. Except for the part where we say that Ruby on Rails can beat up your dad, because it can.

On a serious note, though, we're not trying to bash any frameworks or languages... We know PHP has frameworks that allow for organization like Rails as well as database abstraction and OR mapping. We believe in using the best tool for the job, what ever that may be. These videos are for FUN and are not intended to start language or framework wars. Which is why our next ones are going to be vi vs emacs. Totally kidding.

Last week I attended the web 2.0 expo. I went to learn as much as I could about good UI & Webpage design, and ended up with many tidbits of wisdom I’d like to pass on.

These are all in regards to building social websites:

1. You can’t build a community, you have to grow one. Don’t assume that if you build it, they will come. Social websites have become over saturated on the Internet. If you want to create a successful community the social aspect should be the second reason people come to your website, not the first.

2. The worst mistake you can make is assume you know what your community wants. Only they know what they want, and it’s your job to listen to them, and give them what they want.

3. Create a clear path for website contributers, and always reward people for good contributions.

4. Push the best or most popular content to the front pages of your website. Good content not only attracts more people to your website, but encourages people to create their own content (in the hopes of becoming popular).

However, just because something is popular doesn’t mean it’s good. Publishing content based on popularity isn’t always the best idea. Moderate where needed.

5. Most healthy online communities follow the 80% 20% principle. Only about 20% of the community will create new content, while 80% are consuming the content. This is not a bad thing. If everyone was talking at once there would be no one left to listen.

6. Every time a user comes into your website, they should make the site better for the next user.

7. The average user is typically below average. Anything you ask a user to do will require skill. Your typical user always feels like an idiot. In any design, you need to ensure users feel competent from the get go.

8. Nobody reads the manual. Most console game controllers have 16-18 controls/buttons, but are so simple that you can play through the entire game without reading the manual at all. Games make heavy use of affordances, meaning that activities should do what you expect them to do. In other words, make sure things are intuitive.

9. Create cozy rooms. Humans aren’t fans of giant expanses of anything, they prefer cozy rooms. The most popular spaces are the ones with distinctive small locals, designed for a small number of people. Design for the right size, not for the biggest side; bigger is not better.

10. Stay consistent. When users interact with software, they’re building a mental model of how it works. If you have a widget in two different places and it doesn’t do the same thing, it will get reported as a bug.

11. Allow people to show their personality. If someone is able to personalize their profile or avatar, they are going to be more emotionally connected to the website.

12. If you have any sort of ranking system or ladder system on your website, be sure to reset it every month. No one likes systems where the “Rich get Richer.”

13. When releasing a new website, keep statistical information on what path users are taking through the site. If there’s a core page people aren’t using, try something different to get them involved. If there is a page where many people end up leaving the site from, figure out how to keep them engaged.

Feel free to add to this list with comments, if you have any other pearls of wisdom to share with the rest of us.

I also did a presentation on Ruby on Rails while I was at the conference. Didn’t get any video, but you can view the slides here if you’re interested. You’ll notice a similar theme if you watched the previous video.

This article is the second part of my series about Ruby on Rails Caching. If you have not yet read Part 1 you may be left clueless, so please do so.

In the last article we went over Page Caching, which involves taking the entire content of a page, and storing it in a static html file that gets read outside of the rails application itself. Page Caching is a great fit for the first page of your site or for your new member application form, but what if you need to ensure someone is authenticated or only cache part of a webpage?

This tutorial is going to address Action Caching, Fragment Caching, and even ActiveRecord Caching (only available in Edge Rails) which will complete our tutorial of caching in Rails.

Update: This article is now about reinventing the wheel and showing you how easy it is to use the ruby language to accomplish your tasks. As robert pointed out in the comments, rails comes with the reverse merge method which you could call instead.

In this article, I'm going to show you how to have the params keep their state on your page in a very easy, concise manner. In most Rails pages you're only going to be changing the params for one object, possibly two. Conventionally, it's done like this:

<%= link_to 'Previous page', { :page => @post_pages.current.previous } %>

But that becomes a problem if you want to have anything other than the page variable in your query string. A solution to that:

<%= link_to 'Previous page', { :page => @post_pages.current.previous }.merge(params.reject{|k,v| k=="page"}) %>

Not so bad if you only have a couple of links. But I'm lazy and strive for minimalist code. Try throwing something like this in your application_helper

1
2
3

def params_merge(opts={})
  opts.merge(params.reject{|k,v| opts.keys.include?(k)})
end

And you can now do this:

<%= link_to 'Previous page', params_merge(:page => @post_pages.current.previous) %>

You might be working with a RESTful application, in which case you may have some routes that are defined like this:

1
2
3
4
5
6

map.with_options :controller => 'surf_reports', :action => 'worldwide' do |worldwide|
  worldwide.global_news     '/news',     :category => 'news'
  worldwide.global_events   '/events',   :category => 'events'  
  worldwide.global_latest   '/latest',   :category => 'latest'
  worldwide.global_location '/location', :category => 'location'
end

Now you know your route for global_news_path already has a category set. Let's say you want to link to that with seven other params. You can't just do global_news_path(params) because you might be in /events at the time, which already has the category set. Just like above, you could do something like this:

<%= link_to "News", global_news_path(params.reject{|k,v| k=="category"}) %>

But this quickly becomes tedious. Try this in your application_helper:

1
2
3

def params_without(name)
  params.reject{|k,v| k==name}
end

And now you can do an easy link_to:

<%= link_to "News", global_news_path(params_without :category) %>

Now you have some view code that's concise and pretty.

Update!
Duncan Beevers posted the following in the comments if you want something to work on all of your hashes. Thanks, Duncan!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Hash

  # lets through the keys in the argument
  # >> {:one => 1, :two => 2, :three => 3}.pass(:one)
  # => {:one=>1}
  def pass(*keys)
    tmp = self.clone
    tmp.delete_if {|k,v| ! keys.include?(k) }
    tmp
  end

  # blocks the keys in the arguments
  # >> {:one => 1, :two => 2, :three => 3}.block(:one)
  # => {:two=>2, :three=>3}
  def block(*keys)
    tmp = self.clone
    tmp.delete_if {|k,v| keys.include?(k) }
    tmp
  end

end