• Music Ontology Specification
  Good to see this project getting its own domain and a wiki. Wish I had more time to follow things like this.
  (tags: music musicontology rdf)
• hCalendar profile for hKit
  I need to parse some microformats in PHP, and obviously wanted to use Drew’s hkit. Unfortunately all the links I could find to this hcalendar profile were broken, but I managed to track it down. It doesn’t (yet) support hcard nested within hcal
  (tags: hcalendar hkit microformats profile)
• Google Code - Summer of Code - Atom Publishing Protocol for Ruby + Rails
  Glad to see someone working on an APP server for rails
  (tags: atom atompub rubyonrails summerofcode)
• cookin’/relaxin’: Find Listen Label (a.k.a. Annotatable Audio)
  Tristan’s write up of a recently launched BBC prototype allowing listeners to annotate radio programmes to add metadata.
  (tags: annotation audio bbc radio)
• Gyre: Debugging, the Rails Way
  In-browser rails debugger. Looks interesting.
  (tags: debugging gyre rubyonrails)
• Softies on Rails: REST 101: Part 1 - Understanding Resources
  The first part of a great series on REST in Rails
  (tags: resources rest rubyonrails tutorials)
• Last.tv: streaming music videos based on last.fm profile
  Last.fm has to be one of the most interesting examples of the web as a platform around at the moment. Not only are they nicely layering their own services, but they provide initial data for all sorts of other services
  (tags: api lastfm mashup music tv video)
• Google Maps: America’s Highway - Oral Histories of Route 66
  Nice use of Google’s My Maps for storytelling (via Strange Attractor)
  (tags: googlemaps maps mashups storytelling)
• Gluttonous : On Twitter, Rails, and Community
  A good attempt to calm down yet another set of crossed wires and controversy seeking
  (tags: rubyonrails twitter)

Recommend this post:

Within a large project that uses a lot of partials to load in page components, there are a lot of potential points of failure. Add in a developer new to the project, or a front-end developer pressed into service working directly on your views, and the chances of someone editing a partial without realising it’s used in several more places than they’d noticed are fairly high. And if the partial hits an error, the exception will roll all the way up the chain and the end-user will see your 500 page.

Now there are several things that should prevent this from being a problem. Your test coverage should be high enough and run often enough that a page throwing an exception will be noticed very quickly. The partials should be self-contained enough that it doesn’t really matter what context they’re called in. And the project should be well enough documented that a developer can quickly see what dependencies any given piece of code might have.

Every now and again that’s still not enough, or time doesn’t allow you to be quite as consistent as you might want. I’ve run into this particular problem a couple of times, and have just added a solution to one project that I hope will give us a little more protection should the worst happen and a problematic partial makes it into the live environment.

By adding the following code in a file that is loaded from config/environments/production.rb I’m able to trap any exceptions that might occur in a partial, log them, and ensure the worst that happens to a page is a blank space that should have contained content:

module ActionView
  module Partials
 
    private
    def render_and_rescue_partial(partial_path, local_assigns = nil, deprecated_local_assigns = nil) #:nodoc:
      unrescued_render_partial(partial_path, local_assigns, deprecated_local_assigns)
    rescue => err
      # This is where we handle the exception, logging it, emailing, or whatever
      return ''
    end
 
    alias_method :unrescued_render_partial, :render_partial
    alias_method :render_partial, :render_and_rescue_partial
 
  end
end

Basically, it wraps itself around the standard render_partial method, captures any exceptions, handles them, and then returns an empty string. It wouldn’t be hard to extend it to be a little more refined and only capture errors from a certain subset of contexts.

This sort of error handling is a bad idea in a development environment, where you want to see errors as they happen to ensure you’re motivated to fix them. In production, this might help us look a little less foolish if something slips through the net, and let the user see the page they requested.

Recommend this post:

• What Highrise has meant to Rails (Loud Thinking)
  Interesting to hear where some of the innovations in rails are coming from and how they’re being used.
  (tags: 37signals rubyonrails)
• ActiveScaffold :: Welcome
  The successor to ajaxscaffold, for generating admin UIs, which we’re using fairly heavily in GOOD. Not yet sure what the differences are.
  (tags: activescaffold ajaxscaffold cms rubyonrails)

Recommend this post:

I’ve been casually following updates over at NetSquared (”remixing the web for social change”) for a while but hadn’t really focussed on their Innovation Award, which is seeking projects that use the web to make a social impact. The 20 top projects selected by their readers will be invited to a conference in San Jose at the end of May, and a lucky few will receive funding from the NetSquared Technology Innovation Fund.

You can see the proposal list here and anyone who signs up to the site can join in the voting. The projects run the gamut of media awareness, geographical tools like Open Street Map, websites to help people make a difference “in 5 minutes a day” (an approach I have very mixed feelings about, as I think we have enough of such strategies and need to be looking for deeper integration), and a lot more.

My favourites tend to be those which are looking to build infrastructure for the rest of us to use, mainly because I’d love to have that there to play with. But regardless of which projects win it’s good to see such a range of approaches and goals, and the impact that “Web 2.0″ tools are having in the non-profit world.

Recommend this post:

In the process of catching up with some neglected tasks, I’ve pushed out new releases of both of my PEAR packages.

Services_Technorati receives a version number bump, and little else. The alpha release was never meant to last quite this long given that it’s merely a port of a very stable package, and it’s finally marked beta. My hope is that the beta release will pick up a few more users to put it through its paces.

I had wondered about adding in some extra classes to encapsulate responses, but at the end of the day simplexml does a decent job, is well documented, and doesn’t add any overhead, so I’m happy just returning its objects and letting people work with them.

There are also a couple of bug fixes for the stable release of XML_Feed_Parser, kindly contributed by users. There are still a couple of outstanding tickets, but they’re issues which require more thought so I’m postponing them for 1.0.3 or 1.1.0.

Recommend this post: