Got another quick presentation for ya. I discovered Sammy yesterday. I gave a quick talk about it today. That’s how easy it is to understand!

Sammy is a tiny, client-side JavaScript framework, created by the obviously brilliant Aaron Quint, built on jQuery, and inspired by the server-side Ruby framework Sinatra. It’s the minimalist’s framework for RIAs. You know, those uber rich internet applications. Single page, no refresh apps. Like Gmail. Except without all those kilobytes you may or may not ever need. Sammy is 7kb, minified. And gzipped? You won’t even know you downloaded it.

Watch the preso for more…

If you want to learn more about Sammy, check out Aaron’s blog post which has a nice introduction and screencast.

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:

Here are the slides for the presentation I gave the other week at the Portland JavaScript Admirers meeting: SproutCore – A Next Generation JavaScript Framework. It is an overview of some of the key features I think make SproutCore unique and very useful. There was also video recorded which should hopefully appear online soon. I plan to do another SproutCore focused talk with a walkthrough of a full backend-connected application.

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.

UPDATE: The url to the old tracker died and never came back, so the tracker has been moved. The above link has been changed to the new tracker URL.

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.