Hello! Here is a long overdue update to Asset Packager, which now makes the main branch Rails 3 and Ruby 1.9 compatible. Thanks to all those on Github who sent me patches with these fixes.

• Fix thread safety issue.
• JSMin compatibility fix for Ruby 1.9.1 – Fixnum#ord
• Rails >= 2.3 test compatibility
• Rails 3 deprecations – change RAILS_ROOT to Rails.root, change RAILS_ENV to Rails.env, move tasks to lib dir

A couple weeks ago, I gave a talk at the Open Source Bridge conference in Portland Oregon on Agile JavaScript Testing.

In this presentation, I first gave an overview of Test Driven Development for those front-end JS developers who might not have heard of it yet (!) and then the difference of TDD vs. Behavior Driven Development.

I then walked through some tools:

• Screw.Unit, a nice BDD framework for JS that is quite similar to RSpec in Ruby land.

• Blue Ridge, a plugin for rails that integrates Screw-Unit with Rhino and Env.js and some rake tasks to create a command-line driven headless (no-browser == fast) testing workflow.

• JS Test Driver, a project that mounts one or more browsers as slaves, and a command-line tool which notifies all the listening browsers to run tests and aggregates the results. Very cool!

In the actual presentation I even did some live coding examples of Blue Ridge and JS Test Driver, and they worked perfectly. Here are the slides from the talk:

If you’re working on a project with a couple years of code under it’s belt, you may have moments of desire to completely throw the whole thing out and start anew. But, if you’re working for someone else, you know that your boss or client probably won’t like that. After all, he’s paying you to finish feature A! But, you lament, feature A builds on top of feature B that already exists but is written in a terribly unidiomatic, pre-TDD, pre-REST way, way before you or someone else learned the dark arts of coding mastery. Legacy code, argh!

So what should you do? What are your options? A) Ignore the problem and build the new feature on top of the existing badly written code. Watch things get even worse. B) Try to quickly fix the badly written code in-place so you can get on with it. Trigger cascading test failures, and palm your face. C) Start over and rewrite the entire project, get fired for being 6 months late on your estimate. None of these sound any good!

I think I may have found a solution that works for me, especially with Rails.

Start a fresh Rails project. Boom! It’s fresh and clean. Now you have room to work. The beauty of Rails is how quick it is to get started. Choose the aspect of the project you want to work on. Got some legacy code thats bugging you? TDD/BDD it from scratch, the Right Way. The idiomatic, Rails Way. Once you get it to the point where it’s working correctly and passing all tests, you can merge the new code into the main project, replacing the older, ugly, what-were-they-thinking legacy code that was getting in the way.

Now you can work in a clean environment and just focus on the problem at hand. This allows you to make progress quickly, and get rid of the old crap without having to completely start from scratch.

A long overdue update of AssetPackager is finally here:

• Rails 2.2 compatibility fixes
• Packages generated on demand in production mode. Running the asset:packager:build_all rake task no longer necessary.
• Now compatible with Git, and any other revision control system since revision numbers are no longer used.
• No more mucking with internal Rails functions, which means:
  • Return to use of query-string timestamps. Greatly simplifies things.
  • Multiple asset-hosts supported
  • Filenames with ”.”’s in them, such as “jquery-x.x.x” are supported.

Get the latest at http://github.com/sbecker/asset_packager

Thanks to the many forkers for ideas and solutions.

Asset Packager now has a tracker where you can submit tickets. You can find it here.

If you have a bug to report, and/or a patch for Asset Packager, this is the place.

My company WeoGeo made it to the final round of the Amazon Web Services Startup Challenge. In the top 7 out of around 1000 entrants, not too shabby.

Check out the videos for the finalists, and vote for WeoGeo!

Just wanted to mention our Rails Rumble project, RubyBrigade.org. Jason Perry, James Seaman and I worked through the weekend to build RubyBrigade.org – a geographically aware database of Ruby User groups.

Big thanks to James for the killer hand drawn illustrations and interface. Big thanks to Jason & Katie for letting us take over their house for the weekend.

Features:

• Google Maps Integration
• Sub-domains for each group
• Geocoding: either by the search box or by sub-domain!
• RSS and iCal feed parsing
• Display latest user groups
• Display upcoming events across all groups
• Display blog posts & upcoming events for individual groups
• ReCAPTCHA for spam prevention
• No authentication required

More Screenshots

View a Brigade

Edit a Brigade

Delete a Brigade

404 Message

If you like what you see, vote for us!

I’m part of a small team tossing around ideas for a RailsForge.

Surveying the community

Jason Perry chose to survey the community and get some discussion going before anything was built. That’s been interesting. We’ve already received a lot of feedback – tons of positive, some negative, and some generous offers of help.

Since there’s nothing to see yet, and 90% of stuff produced these days is crap, some people automatically assume you too will build crap and yell “NO!” Some of it is along the lines of “don’t duplicate RubyForge” or “don’t fragment the community.” And we’ve all pretty much agreed we don’t want to. We’re not going to host source code or gems on RailsForge. Although its still a question on the survey, because Jason still wants to know what you think.

The big idea

Think of RailsForge as a view of the ruby community that’s central to rails development, with the hope of making things easier to find, learn, and discuss. More like a Technorati for Rails projects, but not so much svn/trac/tickets. We’ll leave that to existing facilities like RubyForge. We want to keep that and build a community focused site on top of it. We’re still letting the ideas percolate for a few more days. Feel free to contribute.

We’ll then go quiet for a month or so and build something. ;)

RubyForge

What about RubyForge? It could use some love too! More on that in another post.

In Scott Raymond’s excellent book Ajax on Rails I came across a cool (non-ajax related) pattern for insuring a request’s method is POST and showing a confirmation form if not.

This is really useful in situations such as confirmation links in emails, where a form can’t be displayed and javascript won’t work, yet we don’t want a destructive action occurring through a GET request.

Here’s an example:

def unsubscribe
  if request.post?
    @user = User.find(params[:id])
    @user.update_attributes :subscribed => false
    redirect_to home_url
  else
    render :inline => %Q(
      <% form_tag do %>
        <%= submit_tag 'Confirm' %>
      <% end %>
    )
  end
end

One other piece of code you’ll need to get this to work, assumming you’re using RESTful routes, in config/routes.rb

map.resources :users, :member => {:subscribe   => :any, 
                                  :unsubscribe => :any}

This states that we have a couple extra actions in our controller, and we’re not going to mandate a specific HTTP method to get there. This way we can handle it within the action if the HTTP method is wrong.

Now if your user comes to your page from a straight GET request, he’ll get prompted to confirm the big destructive action he’s about to commit.

(In a real app we’d make this form look a bit nicer.)

Wouldn’t it be nice if we could re-use this pattern, without writing out the inline form code every time? Seems generic enough.

DRY it up!

We could abstract that out, and also support any HTTP method we want. Lets follow Rails / RESTful conventions , and require PUT for updating a model. Using some handy ruby block syntax, we could write something like, say:

def unsubscribe
  confirm_unless :put do
    @user = User.find(params[:id])
    @user.update_attribute :subscribed, false
    flash[:notice] = "User is now unsubscribed"
    redirect_to users_url
  end
end

Much better. But how?! Keep reading.

Get one for yourself!

To get the confirm_unless method for yourself, slap the following code into app/controllers/application.rb:

def confirm_unless(method)
  if request.method == method
    yield
  else
    render :inline => %Q(
      <% form_tag({}, :method => :#{method}) do %>
        <%= submit_tag "Confirm" %>
      <% end %>
    )
  end
end

We could take it one step further and make it a before_filter, but I’ll leave that for a possible future post.

A while back someone posted on rubyonrails-talk asking how to export to CSV from Rails. I posted a solution, and people seemed to dig it, so I’ll share it again here.

Use FasterCSV

Get the FasterCSV gem. Why? It’s faster, and easier to use. Once you’ve got it, require it in environment.rb. Here’s an abbreviated version of my working controller method. Copy/paste/modify. And you’re done!

def export_to_csv
  @users = User.find(:all)

  csv_string = FasterCSV.generate do |csv|
    # header row
    csv << ["id", "first_name", "last_name"]

    # data rows
    @users.each do |user|
      csv << [user.id, user.first_name, user.last_name]
    end
  end

  # send it to the browsah
  send_data csv_string,
            :type => 'text/csv; charset=iso-8859-1; header=present',
            :disposition => "attachment; filename=users.csv"
end

HTML or CSV, have it your way

Now, if we wanted to get all clever about it, we could go further and serve both html and CSV data with only one action, using respond_to. This also requires that you add a RESTful route (map.resources :users) to your routes.rb file:

def index
  @users = User.find(:all)

  respond_to do |wants|
    wants.html
    wants.csv do
      csv_string = FasterCSV.generate do |csv|
        # header row
        csv << ["id", "first_name", "last_name"]

        # data rows
        @users.each do |user|
          csv << [user.id, user.first_name, user.last_name]
        end
      end

      # send it to the browsah
      send_data csv_string,
                :type => 'text/csv; charset=iso-8859-1; header=present',
                :disposition => "attachment; filename=users.csv"
    end
  end

end

Now if the user requests:

/users 

she’ll get HTML. If she requests:

/users.csv

You get the point.