Gregg Kellogg

Gregg's personal blog

Ruby

RdfContext gem released

I've released version 0.4.4 of the RdfContext gem. As the name implies, RdfContext supports contextual data-stores bound to graphs, along with a ConjunctiveGraph providing the union of contexts within a given data-store.

  • Parses RDF/XML, RDFa and N3. RDF/XML and RDFa both pass all relevant W3C test cases (may be run through specs).
  • Graph and ConjunctiveGraph with pluggable data-stores. MemoryStore and SQLite3Store both support contexts as well as quoted-graphs and formulae, although no appropriate graph classes yet exist.
  • Graphs serialize to N-Triples and RDF/XML.
  • An RDF distiller runs on this site to test out different parsers. This is also useful for running automated RDFa Test Harness. 

RdfContext is based, in part on Tom Morris' Reddy gem. See the readme on GitHub for more information. MemoryStore, SQLite3Store and ConjunctiveGraph are largely ports of Python RDFLib.

Published on Mon, 04 Jan 2010 01:40:00 GMT under . Tags , , , ,

RSpec soft failure for pending test cases

 Recently, I've been playing with RSpec to run RDFa test cases. The suite has accepted and unreviewed test cases. My general way of testing is to parse the suite, and run each test through a generated spec as follows:

test_cases.each do |tc|
  specify "test #{tc.name}" do
    tc.run_test do |input|
      RdfaParser::RdfaParser.new.parse(input, tc.informationResourceInput)
    end
  end
end

The problem is, some tests are pending, so that a failure should be soft, and not hard. The way to do this is to catch Spec::Expectations::ExpectationNotMetError. This this, we can modify the above test as follows:

test_cases.each do |tc|
  specify "test #{tc.name}" do
    tc.run_test do |input|
      begin
        RdfaParser::RdfaParser.new.parse(input, tc.informationResourceInput)
      rescue Spec::Expectations::ExpectationNotMetError => e
        if tc.status == "unreviewed
          pending(e.message) {  raise }
        else
          raise
        end
      end
    end
  end
end

Published on Mon, 26 Oct 2009 20:40:00 GMT under .

rdfa_parser gem released

I just released version 0.1.0 of the rdfa_parser_gem. This parser is written in pure Ruby and uses Nokogiri XML parsing. It passes all XHTML1 test cases and most of the existing test cases for HTML4 and HTML5.

The gem is based on previous work done by Ben Adida and some libraries borrowed from the Reddy Gem.

The project is hosted on GitHub, feel free to clone. You can try out the parser through a distiller.

Published on Sun, 18 Oct 2009 22:11:00 GMT under . Tags , , , ,

Restful action caching

Caching actions without layout can be complicated when multiple request formats are used. In particular, an HTML response may use a dynamic layout, in which case you want to use the :layout => false option. However, other formats (such as XML) don't use a layout, but the :layout => false option to _caches_action_ does not properly cache the body in this case. To solve the problem, create two caches action statements:

caches_action :show,
              :if => lambda { |c| c.request.format == :html },
              :cache_path => lambda { |c| c.cache_key },
              :layout => false   caches_action :show,
              :unless => lambda{ |c| c.request.format == :html },
              :cache_path => lambda { |c| c.cache_key },
              :layout => true

Also, relying on the accept header may not cause the action caching module to detect the appropriate format. Try this in your application_controller:

before_filter :set_explicit_request_format
def set_explicit_request_format
  # Set format explicitly from accept header, unless it's already set
  request.format = :html if request.format == :any
  params[:format] ||= request.format.to_sym.to_s
end

Published on Sun, 30 Aug 2009 01:35:00 GMT under . Tags , , ,

Detecting action caching within controller

Rails offers three forms of caching within your controller: page, action and fragment. Page caching results in the fastest access times, as the results of the first call to an action are saved in a file so that subsequent accesses never even hit rails. However, for most applications, this isn't useful, as there may be dynamic content on a page, and this does not allow for authentication. Fragment caching is the most detailed, and allows different parts of a page to be cached and allows you to check for the presence of a cached fragment within your controller (or view), but it requires the most maintenance of cache keys. Action caching is a nice compromise between the two. It allows the controller to get into the action but takes care of cache key creation. It also allows for a dynamic layout using the :layout option. However, in some actions, the amount of work done by the controller may be non-trivial, so it would be nice to check for the presence of the cache within the body of the controller action. This can be solved by borrowing some code from within ActionController::Cachine::Actions.

def index
  cache_path = ActionCachePath.new(self, cache_key)
  return if self.read_fragment(cache_path.path)
  # body of action
end

Controlling your own cache keys is also useful, particularly for actions that may take a number of parameters:

def cache_key
  key = "#{params[:controller]}/#{params[:action]}"
  params.each_pair {|k, v| key += ":#{k}=#{v.gsub(/\s/, "_")}
  key
end

Published on Sun, 30 Aug 2009 01:12:00 GMT under . Tags , ,

ButtonLabels updated for Rails 2.3

The ButtonLabels plugin described in another post has been updated for Rails 2.3.

Published on Mon, 09 Mar 2009 05:18:00 GMT under . Tags ,

HTTP Digest Authentication in Rails 2.3

After a fair amount of work, I'm happy to report that HTTP Digest Authentication is now a part of Rails 2.3. Although I put the finishing touches to get this into the release, it is based on work done by Dan Manges and Xavier Shay . Also, thanks to Don Parish for bug fixes and improvements after original acceptance.

Read more about HTTP Digest Authentication in Rails 2.3 Ryan's Scraps. Relevant Lighthouse entries: 1230, 1848, and 2000. The last one includes a change, not yet approved for 2.3, which allows for using the HA1 part of the digest to store a hash of the password, rather than the cleartext of the original version. Hopefully, we'll get a version of that in soon. Also, the current implementation depends on using a session secret when computing the nonce. 2000 proposes a way to avoid this so no session is required.

Hopefully. we'll see the open issues resolved and get this into a 2.3.1 update.

Gregg

Published on Sun, 08 Mar 2009 23:30:00 GMT under . Tags , , , ,

Automatically generate in_place_editor_for

Recently, I was creating some in_place_editors for a polymorphic controller I’m working on. Although the problems not particular to polymorphic controllers, I didn’t want to embed too much model information within the controller. I came up with a way to use meathod_missing to define the in_place_editor_for on demand:

class ResourcesController << ApplicationController
  def method_missing(method_id, *args)
    if method_id.to_s.match(/set_resource_(.*)$/) && @resource.respond_to?($1)
      property = $1

      # Defines "set_resource_#{property}" on the fly
      self.class.in_place_edit_for(:resource, property)

      # Call the newly defined method
      self.send("set_resource_#{property}", args)
    else
      super
    end
  end
end

Published on Thu, 22 Jan 2009 06:21:00 GMT under .

ActiveWarehouse

Related to the interesting talk at a recent NBRug meeting on Ruport, I’ve been looking at doing data warehousing in Ruby. Fortunately, Anthony Eden has beaten me to the punch with ActiveWarehouse.

For those unfamiliar with Data Warehousing, the concepts are basically to create a series of facts that are indexed buy multiple dimensions. A fact is typically an integer (eg, sales amount) with data relating to the fact expressed in dimensions. (Note that in some cases, you can have a Factless Fact table where the information is entirely in the dimensions). Dimensions provide different types of data relating to the fact (e.g., date & time of entry, user, product, location, etc.), so a fact table has a column for each ’’dimension’’ with a column for the fact scalar value itself.

The ’’dimension’’ tables contain an id index column, a column for the fact value (e.g., timestamp for date & time) and columns for each ’’summary’’ to be associated with the dimension (e.g., day of week, day of month, month, year, hour minute, …).

At this point, queries can be performed by joining the dimension and fact tables and summarizing (or counting) the scalar fact value against conditions against the dimension tables (e.g., sales per year by person and region).

Typically, this data is pre-summarized in ’’cubes’’ with summary tables that contain the results of these summary queries.

The ActiveWarehouse plugin contains everything necessary to define, populate and report on this data.

I expect to be using this to hold information on user listening habits for MP3 files.

Gregg Kellogg

Published on Sun, 20 May 2007 01:10:00 GMT under .

RailsConf Sessions

Here are the sessions Ill be attending at RailsConf. Hope to see you there.

Gregg

Published on Thu, 26 Apr 2007 22:05:00 GMT under .

Powered by Typo – Thème Frédéric de Villamil | Photo Glenn