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.
Updates
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:
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:
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.
If you like what you see, vote for us!
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.
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.
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.