rpheath.com

Rails' StringInquirer

Ryan Heath | filed under Programming — Fri, 27 Jun 2008 11:27:05 -0400

A recent commit to Rails. When the last method of a method chain ends with a question mark, the entire chain reads like a question.

$> Rails.env == 'production'
$> # => true

$> Rails.env.production?
$> # => true

The latter is much better. I love these smart little additions. Any string wrapped up in a StringInquirer has this functionality.

Rails plugin: has_params

Ryan Heath | filed under Programming — Wed, 18 Jun 2008 18:06:13 -0400

This is yet another edition of pointless programming. Ready. Set. Go!

To me, checking if parameters exist via the params hash is ugly. My fingers start to quiver when I type params[:whatever] more than once on the same line. Sometimes I’ll add a private method to simply check if parameters exist. It just reads better, IMHO.

if using_open_id?
  # process OpenID authentication
end

private
  def using_open_id?
    !params[:openid_url].blank?
  end

Maybe you’ve done something similar, maybe you haven’t. Being the pointless programmer that I am, I wrote a plugin to take care of this for any and all parameters. I called it, has_params. You can find it on GitHub.

Example(s)

I suppose there’s no harm in duplicating the README, huh? Anyway, here’s how it works:

# the "old" way
Project.new(params[:project]) unless params[:project].blank?
Project.new(params[:project]) if params[:project]

# the "has_params" way
Project.new(params[:project]) unless blank_project_params?
Project.new(params[:project]) if has_project_params?
Project.new(params[:project]) if project_params?

You basically just plug the key that you’d otherwise use for params into the standard “has_params” format. So, for params[xxx] you’d have one of the following to choose from:

blank_xxx_params?
has_xxx_params?
xxx_params?

Personally, I think it cleans up controller code a little. Brick-by-brick my friends, brick-by-brick.

Gotcha!

If you’re using method_missing in your controller(s), make sure you call super at some point. This plugin also uses method_missing and at a higher point in the inheritance chain (unless you’re also mixing into ActionController::Base), so if super isn’t called, Rails will be perfectly satisfied with your version of method_missing, ignoring the has_params’ version. At least, I’m pretty sure that’s what would happen. Consider yourself warned.

Installation

I can only imagine how excited you are to install this sucker. Here’s how:

>> cd project_root/vendor/plugins
>> git clone git://github.com/rpheath/has_params.git

And that concludes this edition of pointless programming. I hope you’ve enjoyed it :-)

Rails plugin: EasySearch

Ryan Heath | filed under Programming — Tue, 20 May 2008 23:04:42 -0400

Have you ever written a plugin or a piece of code that was more fun to write than it was actually worth? I seem to do that a lot—I enjoy experimenting with Ruby. Recently, I needed to search ActiveRecord models individually, and was in the mood to write a simple DSL. It’s now in plugin form, called EasySearch, and can be found on GitHub.

It doesn’t support joins or shared indexes or anything else you might come to expect from a search plugin. I’m posting about it not because I think you should use it, but because I think it’s a pretty cool API for searching.

So, install the plugin and do something like this:

class Search
  include RPH::EasySearch
end

(I originally had a nice acts_as_easy_search class method that hooked up the behavior, but I didn’t feel right about mixing that into Object. I wanted this plugin to work without the need of an ActiveRecord superclass. Plus, AR would then be expecting a corresponding table in the database, which is another unnecessary need. So, manual inclusion is the answer until I come to terms with a better alternative. Continuing…)

The Search class now has the means to easily search any ActiveRecord model within an application. Let’s say I want to find all of the users who mention ‘ruby’. Let’s reword that: search users with the term ‘ruby’.

$> Search.users.with('ruby')
$> # => [<#User ...>, <#User ...>, ...]

Makes sense, huh?

I have a confession to make: I lied about only having to include the module. Before anything will actually work, I’ll need to tell EasySearch about the tables I want to easily search.

EasySearch Configuration

For any generic search plugin to work, there needs to be a way to specify which database columns the search terms should be matched against. Here’s an example of how it works:

# in Rails 2.0+ you could put this in 
# config/initializers/easy_search_setup.rb
# (otherwise just use config/environment.rb)

RPH::EasySearch::Setup.config do
  setup_tables do
    users    :first_name, :last_name, :email, :bio
    projects :title, :description
    groups   :name
  end
end

There, that’s it (for real this time).

If you notice, it looks like there are “users”, “projects”, and “groups” methods that are called from within the block. And actually, that’s correct. The only difference is those methods don’t exist until they’re called, and even then they don’t “exist” (which is kind of weird, I know, but incredibly awesome nonetheless). Don’t worry about how it works (read through the code if you’re interested), just follow the pattern (use the table names instead of the model names).

After this one-time configuration is done, I can do things like:

$> Search.users.with('ryan')
$> # => [<#User ...>]
$> Search.projects.with('design')
$> # => [<#Project ...>]
$> Search.groups.with('friends')
$> # => [<#Group ...>]

If you try to search a model that hasn’t been configured, EasySearch will let you know. After all, how else would it know which columns to look in? It’s not that magical.

And getting a hold of the current table configuration is easy:

$> RPH::EasySearch::Setup.table_settings
$> # => {"users" => [:first_name, :last_name, :email, :bio], "projects" => ...}

How it Works

Really, all EasySearch is doing is building a WHERE clause and using conventions to pass that on to the appropriate finder. So Search.users is really doing User.find with a custom conditions clause.

Let’s say I want to search my User model for “ryan heath ruby”.

Search.users.with('ryan heath ruby')

This would not only compare “ryan heath ruby” with each of the specified columns (you know, from the configuration), but it’d compare “ryan”, “heath”, and “ruby” individually against each of the specified columns, providing more accurate results.

This, however, is an incredible performance limitation and is why this plugin is not meant for those gigantic applications with tons and tons of database records. It builds a potentially large WHERE clause using LIKE, which is quite slow in the computer world. For those large applications, it’s far better to use a full text solution. But again, this is all (more-or-less) for fun with little profit. I had a need to search individual models separately in a small application, so there you go. I can always go back and rework the back-end to operate differently/more efficient.

Oh, and since a rather large WHERE clause is being constructed, checking each term individually, I want to ignore meaningless words to avoid the extra overhead. For example, let’s say I tweak my search to be:

Search.users.with('ryan heath is a ruby')

EasySearch would still only search “ryan”, “heath”, and “ruby”, ignoring the “is” and “a” (because they’re dull). You can easily see what keywords are considered “dull” by doing:

$> RPH::EasySearch::Setup.dull_keywords
$> # => ['the', 'a', ...]

Now I know what you’re thinking, “Who gets to decide what keywords are dull keywords?” The programmer, of course! By default, EasySearch has a predefined list of keywords that it thinks are meaningless. But you can add to that list quite easily. Using the same Setup.config block:

RPH::EasySearch::Setup.config do
  setup_tables do
    # ...
  end

  strip_keywords do
    ['other', 'words', 'you', 'do', 'not', 'want', 'to', 'search']
  end
end

That will append those keywords to the default list (and will only count a dull keyword once, so don’t worry about duplication). If I wanted to ignore the default list completely (instead of appending to it), I’d just have to pass true to the strip_keywords method, like so:

strip_keywords(true) do
  ['other', 'words', 'you', 'do', 'not', 'want', 'to', 'search']
end

So that’s about it. It’s a fun plugin to play with, and like I said, it was more fun to write than it’s probably worth. But honestly, I think this sort of experimentation is nothing but good for programmer experience. And besides, every now and then, an “experiment” turns into something awesome (see Ambition for a prime example).

Ruby conditions

Ryan Heath | filed under Programming — Mon, 05 May 2008 22:58:27 -0400

Often the conditions of an if statement are dependent on more than one thing, and sometimes it’s of the form, “if A is true and B is false”.

Avoiding the details, let’s say I wanted to do something like this:

user.cache! if user.needs_cached? && !API.local?

Essentially that’s saying “cache the user if the user needs cached (A is true) and the API is NOT a local request (B is false). The && ! is fine and all, and it’s actually quite readable to most programmers, but were you aware that you could do this?

user.cache! if user.needs_cached? unless API.local?

Maybe I’m flying solo on this one, but I wasn’t aware that you could use if and unless to chain conditions together. And I’m sure this is one of those Ruby moments where I just need to take a step back and find the right perspective. Sometimes things aren’t always what they seem (like how 1+3 is actually 1.+(3)).

Railscasts Contest: 5 Rails Tips

Ryan Heath | filed under Programming — Mon, 05 May 2008 00:12:46 -0400

There’s a contest on Railscasts that has me feeling compelled to participate. So I am. To enter, the contest requires 5 tips concerning Rails, all in one post. So, this post will more than likely be one of the longest I’ve written in a while, but hopefully it will serve as a good resource/reference for other Rails developers. Without further ado, here are my five tips:

Note: I haven’t wrapped my View code examples in the ERB <%= -%> tags, as it currently makes the syntax highlighting terribly hard to read. I just wanted to make new comers aware until I can get this issue fixed.

Tip 1: Navigation Helper Plugin

Nearly every web application has some sort of navigation. Albeit tabs, menus, plain links, whatever, there needs to be a way to click through the application. And more often than not, keeping track of the current section/tab is a desired feature. Well, I wrote a Rails plugin called navigation_helper to assist with these needs.

Basic Usage

Once installed, here’s how the plugin works:

# somewhere in your view (typically your layout)
navigation [:home, :about, :contact]

# HTML output:
#   <ul class="nav_bar">
#     <li class="current"><a href="/home">Home</a></li>
#     <li><a href="/about">About</a></li>
#     <li><a href="/contact">Contact</a></li>
#   </ul>

You pass an array of symbols representing the sections that the links will navigate to. The link text will be a capitalized version of the symbol passed in. So :home becomes ‘Home’; :contact_me becomes ‘Contact Me’; and so on.

An important thing to be aware of: the helper will be expecting a named route mapped to the section passed in the array. For instance, for the :home section, the navigation helper will use home_path to build the link. And for :about, it will look for about_path. And so on. You need to make sure those routes are defined in your routes.rb file (it’s good practice to use named routes, this plugin just enforces that practice).

And as you can see, the markup is very extensible (in terms of CSS) with the use of an unordered list. The list item that holds the current section will get a CSS class of “current”. And the unordered list itself gets a CSS class rather than an ID, so that it can be used multiple times on the same page and not break your strict XHTML markup :-)

Adding Subtitles

Sometimes it’s a nice touch to add subtitles to your navigation (see my portfolio for example). This plugin has support for that. All you have to do is pass a string of the subtitle right after the section that the subtitle should be associated with. For example:

navigation [:home, 'Start Here', :about, 'Learn More', :contact, 'Get In Touch']

# HTML output:
#  <ul class="nav_bar">
#    <li class="current">
#      <a href="/home">Home</a>
#      <span>Start Here</span>
#    </li>
#    <li>
#      <a href="/about">About</a>
#      <span>Learn More</span>
#    </li>
#    <li>
#      <a href="/contact">Contact</a>
#      <span>Get In Touch</span>
#    </li>
#  </ul>

As you can see, the markup generated is clean and is ready for some CSS love. Now, what if you would rather those subtitles just be hover text on the link instead of full-blown span elements? No problem, just let the navigation helper know with the :hover_text => true option:

navigation [:home, 'Start Here', :about, 'Learn More', :contact, 'Get In Touch'], :hover_text => true

# HTML output:
#  <ul class="nav_bar">
#    <li class="current"><a href="/home" title="Start Here">Home</a></li>
#    <li><a href="/about" title="Learn More">About</a></li>
#    <li><a href="/contact" title="Get In Touch">Contact</a></li>
#  </ul>

The span elements will transform into title attributes on the links, so the text will only show up on hover.

Authorized Sections

Now, a definite need (for me at least) is to have certain tabs show up depending on some condition, such as a user being logged in. For instance, on this very site, the public sees ‘Portfolio’, ‘Words’, ‘Archives’, and ‘About’ tabs. But if I’m logged in, there’s also an ‘Admin’ tab, which allows me to access the area to post new entries, add categories, edit/delete comments, etc. But I only want that tab visible based on me being logged in. Well, I’ve added support for that, too. Just specify which sections should be “authorized” sections, like so:

navigation [:home, :about, :admin, :reports], :authorize => [:admin, :reports]

# HTML output:
#   <ul class="nav_bar">
#     <li class="current"><a href="/home">Home</a></li>
#     <li><a href="/about">About</a></li>
#     <li class="authorized_nav_link"><a href="/admin">Admin</a></li>
#     <li class="authorized_nav_link"><a href="/reports">Reports</a></li>
#   </ul>

By default, the link will be “authorized” by checking a logged_in? method. If you don’t have a logged_in? method, or need some other means of authorization (such as checking if the current_user has the admin role), then you can specify which method you’d like the navigation helper to check against by using the :with option:

navigation [:home, :about, :admin, :reports], :authorize => [:admin, :reports], :with => :administrator?

Now the plugin will only show the ‘Admin’ and ‘Reports’ tabs if the administrator? method exists and returns true. (Note: if the authorization method doesn’t exist, the helper won’t crash, it will simply not show the authorized tabs)

Also notice how the admin links get a special “authorized_nav_link” CSS class. That’s because sometimes you want your “admin” tabs to appear differently, and this gives you the power to do so. For instance, you may have your common tabs to the left, but your admin tabs floating to the right. And just to be clear, if an authorized link happens to be the current section, it will simply append the CSS classes (i.e. class=”authorized_nav_link current”).

I’ll admit, the “authorized_nav_link” isn’t the best CSS class name, but it’s best to keep defaults such as that awkward so they don’t interfere with your current CSS classes. However, you can pass another option to override that class, like so:

navigation [:home, :about, :contact, :admin], :authorize => [:admin], :authorize_css => 'custom_css'

There’s one more thing to mention about authorized links. Let’s say you’re using this for an admin menu, where all of the links are to be “authorized”. Rather than list out all of the authorized links again, you can pass an :all to the :authorize option, like so:

navigation [:users, :reports, :logs], :authorize => [:all]

Now all tabs will be authorized. Pretty simple, huh?

Setting Current Tab

Up to this point, you may be wondering how the helper knows which tab/section is the “current” tab/section. Well, it’s simple. By default the plugin uses the controller’s name to determine the current tab (or link or section) you’re on. But as we all know, that’s not always feasible. Just because you have a PublicController doesn’t mean you want your link to be “Public” in the navigation menu. To fix that issue, you can specify the current tab for any controller by doing:

class PublicController < ApplicationController
  current_tab :home
end

Now something like this will work as intended:

navigation [:home, :about, :contact]

The PublicController will be seen as :home to the navigation helper, and will choose the current tab accordingly. This is also very handy for namespaced controllers.

Install via Git

You can find this plugin on GitHub (and see the README for more/better examples), and can be installed by doing:

$> cd path/to/your/rails/project/vendor/plugins
$> git clone git://github.com/rpheath/navigation_helper.git

You can download a tarball if you don’t have Git installed. And for completeness, here’s the original announcement of the navigation_helper plugin.

Tip 2: Input CSS Plugin

This next tip is more for designers who work with Rails applications. As any designer would know, designing Forms can be somewhat of a pain, as there are many different types of INPUT tags (text boxes, password fields, submit buttons, file fields, etc). Obviously, you would not want to apply the same text box styling to a submit button, which means it requires extra work on every form to make sure you’re styling the correct INPUT tag.

Since I personally design and develop Rails applications, I’ve decided that it was time to attack this problem at its core. I wrote a plugin that will automatically add a CSS class based on the “type” attribute of any INPUT tag. And I’ve called it, input_css.

How it Works

Just install it. Then your standard form helpers will automatically have a class assigned to them. For example:

f.text_field :name
# => <input type="text" class="text" name="user[name]" value="" />

submit_tag 'Create', :class => 'button'
# => <input name="commit" type="submit" class="button submit" value="Create" />

f.check_box :is_preview
# => <input type="checkbox" class="checkbox" name="article[is_preview]" value="" />

So once the plugin is installed, the CSS to style your INPUT tags is simple:

input.text     { ... }
input.submit   { ... }
input.file     { ... }
input.checkbox { ... }
input.radio    { ... }
...

Install via Git

This plugin can be found on GitHub, and you can install it by doing:

$> cd path/to/your/rails/project/vendor/plugins
$> git clone git://github.com/rpheath/input_css.git

Once installed, you’re good to go. There’s no setup, customization, etc. It taps directly into the existing Rails tag helper, so all of your existing form elements will be updated! Now you have an easy and consistent way to style your forms.

Remember, if you don’t have Git installed, you can download a tarball. Just put the source in your vendor/plugins directory.

Tip 3: Acts As Lookup Plugin

Maybe I’m alone on this one, but do you find it a pain to deal with select (i.e. drop down) lists? If you’re like me, I don’t always remember the proper Rails syntax, or I want to add a default nil option to the list, etc. They always just feel awkward to me. Here’s a typical select field you might find in one of my forms. It’s simply a lookup to choose a category:

f.select :category_id, [['--', nil]] + Category.find(:all).collect { |m| [m.name, m.id] }

Yikes! That’s sort of nasty to have that right in your views. At least, to me it is. So I wrote a plugin that assists with this “lookup table” issue. I’ve so cleverly called it, acts_as_lookup.

How it Works

Once installed, you need to tell your model(s) that they should be acting as a lookup table. This is pretty straightforward, though:

class Category < ActiveRecord::Base
  acts_as_lookup :name
end

You have to pass it the field/column name you want to show up in your drop down list. So in the example above, I want to be able to choose from a list of category names, hence the :name parameter.

From there, you get two things: 1) a lookup_for helper (used in your views) and 2) an options_for_select class method for any model that is “acting as a lookup table”. Here’s how you use both:

Using options_for_select

This is a clean way to get rid of that collect nonsense I showed previously. So, redoing my above example using this plugin (and using options_for_select), we have:

f.select :category_id, Category.options_for_select

That’s much cleaner. And it automatically adds the nil ”- -” option as the default in your list. Arguably, though, there’s even a better way: the lookup_for helper.

Using lookup_for

The lookup_for helper automatically generates the above, but it’s a little cleaner:

lookup_for :product, :category_id

And if you’re using a FormBuilder (read: “f.” in front of your form helpers), it’s even better. You only have to give it the foreign key to the lookup:

f.lookup_for :category_id

Viola! The above example(s) will automagically generate something similar to (of course depending on the real data):

<select>
  <option value="" selected="selected">--</option>
  <option value="1">Appliances</option>
  <option value="2">Furniture</option>
</select>

One thing to note, though: the foreign key must follow the traditional Rails convention for foreign keys. Meaning, for a Category, you’d have category_id foreign key reference; for a Task, you’d have task_id foreign key reference; and so on. The reason is because the plugin uses that foreign key to get at the Model in which it represents. But since that’s pretty standard to most Rails developers, I don’t think it bears too much constraint :-)

Customization

Now, you may be asking “what if I don’t want ’- -’ as my default option?” or “what if I don’t want every category to show up?” or “what if I have a category order, other than alphabetical?”. Not a problem. This plugin supports that sort of customization.

Changing the Default Text

class Category < ActiveRecord::Base
  acts_as_lookup :name, :default_text => "- Choose Category -" 
end

And if you don’t want a default nil option at all, just set the :default_text option to :first (meaning, the first option of your data returned):

class Category < ActiveRecord::Base
  acts_as_lookup :name, :default_text => :first
end

Now there will be no default option in your drop down (in this example, it would be set to the first category of the collection instead).

Limiting the Options

# only show categories from within the last 4 months
class Category < ActiveRecord::Base
  acts_as_lookup :name, :conditions => ["created_at > ?", 4.months.ago]
end

Displaying in a Different Order

By default, the plugin will sort your options alphabetically, but you can change that, too:

class Category < ActiveRecord::Base
  acts_as_lookup :name, :order => 'category_order ASC'
end

And of course, you can combine the options and pass all three at once, I’ve just shown them separately to emphasize each point.

Install via Git

You can find this plugin on GitHub, and it can be installed by doing:

$> cd path/to/your/rails/project/vendor/plugins
$> git clone git://github.com/rpheath/acts_as_lookup.git

Remember, if you don’t have Git installed, you can download a tarball. Just put the source in your vendor/plugins directory.

Tip 4: Automatic Fading Flash Messages

This next tip is rather minor, but I think it adds a nice touch, and I seem to use it in all of my Rails applications. Basically, the idea is to show a flash message for a predetermined amount of time, then slowly fade the message out. (I personally think it’s tacky to leave it there, waiting on the user to navigate away from that area)

So, using a tip from a prior Railscast, we put this somewhere in our layout:

<% flash.each do |key, msg| -%>
  <%= content_tag :p, msg, :id => key -%>
<% end -%>

This will create a  tag with an id of the flash type. Meaning, flash[:notice] = '...' will give ... and flash[:error] = '...' will give ... and so on. Now, what we want to do is fade this  element out. We’ll use JavaScript to do this, and we’ll want to put that JavaScript in public/javascripts/application.js of our main Rails project root.

Fading Messages using jQuery

$(document).ready(function() {
  setTimeout(hideFlashMessages, 10000);
});

function hideFlashMessages() {
  $('p#notice, p#warning, p#error').fadeOut(5000)
}

Fading Messages using Prototype/Scriptaculous

document.observe("dom:loaded", function() {
  setTimeout(hideFlashMessages, 10000);
});

function hideFlashMessages() {
  $$('p#notice, p#warning, p#error').each(function(e) { 
    if (e) Effect.Fade(e, { duration: 5.0 });
  });
}

(Note: the above examples were based on jQuery 1.2.3 and Prototype 1.6)

The above functions will allow the message to be shown for 10 seconds (10000 milliseconds) in full, then begin to fade the message out over a 5 second duration. Of course, just change the values to fit your needs/desires.

Tip 5: Interfacing with SOAP Web Services

This tip might actually target a small niche of Rails developers, but it’s something that I couldn’t find too much about when “Googling” for some help. So I eventually just came up with my own solution. It deals with creating an interface for legacy .NET SOAP web services. Rather than go into the explanation, I’m going to provide an example skeleton class that you can tailor to your needs:

require 'digest/sha1'
require 'soap/wsdlDriver'

module WebServices
  class SOAPInterface
    attr_accessor :endpoint, :service

    def initialize(endpoint='www.yoursite.com', service='YourWebServices', options={})
      @endpoint = endpoint
      @service  = service
    end

    # --
    # your methods go here
    # -- 

    private
      def wsdl
        SOAP::WSDLDriverFactory.new("http://#{@endpoint}/services/#{@service}.asmx?WSDL")    
      end    
  end

  # pulls out the diffgram of SOAP::Mapping::Object's into an array
  class DataSetParser
    def initialize(soap_response, data_set)
      @response = soap_response
      @data_set = data_set
    end

    # allows for @obj['CourseListing'] to be @obj.course_listing
    def method_missing(name, *args)
      @response.send(:diffgram).send(@data_set.to_sym).send(:[], name.to_s.camelize)
    end
  end
end

We’ll talk about about what goes in “your methods go here” in just a second. I wanted to mention what the DataSetParser is all about. Firstly, it’s specific to the .NET framework, so if you’re wanting to use this for SOAP services coming from something other than .NET, you can wipe out the DataSetParser class entirely. Now, onto what it does.

.NET returns it’s data collections as a DataSet, which then gets wrapped in a DiffGram. I know, goofy. From the Microsoft site:

A DiffGram is an XML format that is used to identify current and original versions of data elements. The DataSet uses the DiffGram format to load and persist its contents, and to serialize its contents for transport across a network connection.

What does that mean to us? It means that it’s another level of tedious parsing that we need to deal with when getting a SOAP response. If your API is returning a DataSet, then you can pass the result to the DataSetParser class, and it will return the collection as an array of SOAP::Mapping::Object. It also will allow you to access the data via an underscored method based on the camelized name of the DataSet returned. If that’s confusing, see the comment above the method_missing definition in the DataSetParser class.

Now, here’s an example of how you might use this skeleton module. Here, we’ll be replacing the “your methods go here” comment.

# returns a user in the form of a SOAP object
def authenticate(username, password)
  soap = wsdl.create_rpc_driver
  response = soap.Authenticate(:username => username, :password => password)
  result = response.authenticateResult
  soap.reset_stream
  DataSetParser.new(result, 'user').user
rescue
  # do your graceful error catching/logging stuff
end

This would allow you to do something like:

$> api = WebServices::SOAPInterface.new('www.mysite.com', 'MyWebServices')
$> api.authenticate('login', 'password')
$> # => <#SOAP::Mapping::Object ... >

The Authenticate and authenticateResult is dependent on the WSDL of the SOAP service, but the rest is pretty close to what each of your methods might look like. For more info, you can visit an earlier post of mine which discusses the same issues, and provides a more Rails-esque example.

Again, I realize that this is for a rather niche group of Rails developers, but like I said, I had a hard time finding any information on this, so maybe someone else will find my solution to this problem useful.

Conclusion

That concludes my 5 tips related to Rails. Hopefully they’ve proven to be worthwhile. Let me know if you have any trouble implementing any of these tips, as I’d be glad to help you make use of them. Thanks for reading my first novel :-)

Hulu: Online Movies and TV Shows

Ryan Heath | filed under Entertainment — Sun, 04 May 2008 00:05:56 -0400

I just came across an awesome site for streaming TV shows and movies. It’s called Hulu. Apparently it’s a site supported (or built?) by NBC/Fox, so the videos are all of incredible quality. I came across it while looking at a list of high-traffic Rails applications (and it’s one of them).

So if you’re looking for another way to be distracted, check out Hulu. Here’s one to get you started: 2008 Tostitos Fiesta Bowl.

Testing block helpers with Rspec

Ryan Heath | filed under Programming — Wed, 23 Apr 2008 08:42:15 -0400

One of the many great things about Rspec is that it allows you to test helper methods. Helpers can be complex at times. And when it matters, they definitely need some testing love.

An example of a typical helper may be something like:

def h1(text)
  "<h1 class='heading'>#{text}</h1>"
end

Then you can do <%=h1 'Text Here' -%> in your views. That’s trivial to test, so I won’t go into that. The tricky tests (I think) deal with block helpers. Block helpers are extremely useful and can improve the readability of what’s going on in your view(s). Probably the most useful case is when you have <% if current_user.admin? %> scattered all over the place. Wouldn’t it be better (and DRYer) to wrap that “admin condition” up in one place?

def content_for_admin(&block)
  yield if current_user.admin?
end

Pretty simple. But, how would you test that? Initially, I had somewhat of a hard time writing tests to see if the block was actually yielded or not. Here’s what I do now, but I’m open to (and seeking more) alternatives. Using the content_for_admin helper as the guinea pig:

describe ApplicationHelper do
  attr_accessor :_erbout
  fixtures :users

  before(:each) do
    self._erbout = ''
    @block = "This is the block content"
    @current_user = users(:admin)
  end

  # current_user.admin? # => true
  it "should yield block for an admin" do
    should_receive(:current_user).and_return(@current_user)
    @current_user.should_receive(:admin?).and_return(true)

    html = content_for_admin do
      self._erbout << "<div>#{@block}</div>"
    end
    html.should have_tag('div', @block)
  end

  # current_user.admin? # => false
  it "should not yield block for a non-admin" do
    should_receive(:current_user).and_return(@current_user)
    @current_user.should_receive(:admin?).and_return(false)

    html = content_for_admin do
      self._erbout << "<div>#{@block}</div>"
    end
    html.should_not have_tag('div', @block)
  end
end

Another, similar, approach is to use eval_erb, which let’s you actually write out the ERB as a string (or heredoc) and evaluate the output. I think that’s a little messy, but then again, I’ve never actually tried it.

But other than that, this is the only way I know to test the yielded output of a block helper with Rspec. Do you know of a better way? Or at least, a different way?

Navigation Helper on GitHub

Ryan Heath | filed under Random — Thu, 17 Apr 2008 07:45:32 -0400

For those who are interested, I’ve moved my navigation helper Rails plugin over to GitHub.

http://github.com/rpheath/navigation_helper/tree/master

You can follow the changes there if you’d like. To install (from your project root):

git clone git://github.com/rpheath/navigation_helper.git vendor/plugins/navigation_helper

I doubt I’ll be pushing changes to the subversion repo anymore, so use the above method if you want the latest and greatest.

Flickr Developer Site

Ryan Heath | filed under Web — Thu, 17 Apr 2008 00:15:45 -0400

Flickr launched a developer site recently (code.flickr). Dev sites intrigue me, especially those belonging to well-known companies. And for some reason, statements like this always seem to draw me in:

In the last week we deployed new code to Flickr 50 times, including 546 changes by 16 people. We issued over 2,000 new API keys, and third party developers made an average of 704 API calls per second, across 109 public API methods. We added 1 new API method, and updated 7 others. There are approximately 10,000 lines of open source code in our public subversion repository.

Sheesh, 704 API calls per second!? To interface with an API requires a slight bit of knowledge (and actual skill to do properly); I mean, it’s not something cousin Elroy could just “throw together” real quick. So to think there are that many people making that many requests per second is kind of crazy.

You can find running totals for those types of stats at the bottom of the main code.flickr page. Pretty cool.

Git and GitHub: Wow.

Ryan Heath | filed under Technology — Tue, 15 Apr 2008 17:24:52 -0400

I’m just getting my feet wet with Git, but it’s starting to amaze me more and more. At first, I thought, “Yeah, Git sounds pretty cool, but I can’t see learning a new VCS. I know SVN and it’s fine.” Wrong. Wrong. Wrong. Learn it and LOVE it.

Git is Distributed

Git is a distributed VCS as opposed to a centralized one. And what exactly does that mean? It means it’s faster, safer, and far better for collaboration.

It’s faster because all changes are committed locally, then pushed to the server at once. So there’s no need to have access to a ~~SVN~~ server at all times. You can imagine the performance gains you get from this. And subconsciously, having those somewhat expensive operations become nearly instantaneous makes you think/work a different way. A better way.

It’s safer because for each user who works with the code, there are multiple versions of the repository (each user essentially has his/her own copy (or branch) of the code). With a centralized VCS (i.e. Subversion), if the server hosting the single repository were to die, you had better hope there’s a backup somewhere. Otherwise, all is lost.

For a lot of (maybe most?) people using Git, collaboration is where its distributed nature shines. You can commit to your hearts content without disturbing anyone else. There aren’t any permissions issues because it’s all local to your machine. You can fork any project, change it however you see fit, then others can pull from your forked repo and merge with their own. And then that person can modify your already modified code, improve it, then tell their friends and they can fork the doubly modified repo, and, well, you see how this “network effect” can make projects blossom. This is entirely different from requiring commit rights to the one-and-only, centralized, repository. It’s a hard model to grasp at first, but it’s incredibly cool once you do.

Branching and Merging

Aside from being distributed, another thing that attracts me to Git is how branches work. Git encourages you to work from a branch, which is great because in concept a branch is ideal for experimenting with a feature. They remove the worry of “screwing up” existing code. And in Git, each “checkout” is actually a branch of the main repo, anyway. So naturally, merging branches works much better than that of many other systems. I think the creator of Git himself said he merges (on a 22,000 file project—the Linux Kernel) on average 4.5 times per day. That’s a lot.

Another cool thing, if you’ve branched (or forked) a repo that you don’t own, you can tell the owner about it (send a pull request) and he/she can merge it with the master branch if it’s worthy. And even if it’s not worthy, someone else might have the same need as you, and fork your forked repo instead of the master.

Learn it. Love it.

At first, I thought having to explicitly add files to the “staging area” was tedious and annoying. Now I think it’s brilliant. It provides more control. I add the ~~files~~ content of my choosing to the index for the next commit, so the commit messages are always meaningful, and it doesn’t hold back my work flow at all. Which brings me to another wonderful thing about Git: it tracks content not files. With Subversion, you know those .svn folders littered all throughout every folder in your entire project? Git just has one .git folder in the project root. And better yet, you remember having to tell Subversion you were deleting/moving each and every file (svn mv and svn rm)? No more. Git doesn’t care what you do. It’s smart enough to figure it out when the time comes.

Not sold yet? A great article called, The Thing About Git shows some advanced usage of Git, and in particular, the infamous Tangled Working Copy Problem that every developer using source control has dealt with. Go read it if you haven’t already.

So, I agree with everyone else who already realizes Git is awesome, because, well, Git is awesome.

GitHub

And then there’s GitHub, a place to host your Git repositories. It was built by the guys at err free, so you know it’s slick. GitHub really wraps a nice interface around the inherent benefits of Git itself. It’s said to be a “social network for programmers”.

They just launched publicly the other day. (I got in early as one of the beta users) With the launch, they’ve released two new features: commit comments and the network graph visualizer. Both incredibly useful and impressive, as expected.

The commit comments are similar to those of the Django Book. But since we’re dealing with commits, the comments can be per line of source code or per commit. Very cool.

And the network graph visualizer is cool because it exposes how Git actually works. If you read the post about the network visualizer, you’ll get to a part that says “think of this as a to-do list,” which at first, I didn’t get. Now I do. As I said earlier, with Git, you can fork a repository and make your own changes separate of the master branch. That’s just awesome in itself, and what’s even cooler is you can choose to pull changes from a forked repo back into yours. What the network graph does is show you what things others have been up to in relation to your code. But it only shows code that you have not yet pulled into your repo. Once (if) you do, it goes away, hence the comparison to a to-do list. And try clicking a user to the left, they become the root and the graph changes. Nice.

Conclusion

Overall I’ve got a long way to go with Git, but it’s exciting to keep learning it. Even as a beginner, I’m finding that I’m able to do more with Git than if I were using a centralized VCS.