I still prefer Amethyst. Linkrdr shows the most promise of any other RSS reader I’ve tried.

Faraday is a library by Mislav, the author of mislav-will_paginate, a gem I (and many others) use for pagination in Ruby on Rails. It is a very nice package. Faraday is middleware for making HTTP request, the flip side of Rack, middleware for handling HTTP requests. This is an intriguing idea. I don’t think I can replace all my ugly RSS fetch code, but it looks like I can replace a lot of it and break the remainder up into smaller, more understandable bits.

I mentioned creating a Domain Specific Language (DSL) for this situation. But there is already something like this, YACC (Yet Another Compiler Compiler). It has been around for decades in the Unix world. YACC handles LALR(1) languages. Regular expressions are a subset of LALR(1) languages.

Bison is an open source version of YACC with some additional features. Rbison claims to merge Ruby and Bison to produce a Ruby callable YACC parser (in C) with actions written in Ruby. A great solution, except it has been abandoned by it creator and his repository taken down. Rbison 0.0.7 is in a number of FreeBSD repositories. I looked at it and it shows some work was done, but it is a long way from being usable. The goal may be too ambitious or even impossible.

Racc is YACC written entirely in Ruby. It is usable and I am working on using it speed up the RSS and OPML parsers described in the article. The OPML parser is working – it passes the test suite and doesn’t blow up running the examples. I haven’t pushed it to github yet. I haven’t run any benchmarks yet, but my current thinking is that it will not be faster. It is pure Ruby, while the Ruby regex library routines is in C. I expect it can match a bunch of regex faster than a single Racc parser.

I expect to have the RSS parser converted to use Racc in the next few days. I’ll post the benchmark results when complete, which ever way they turn out.

class Item < ActiveRecord::Base
  def before_create
    # whatever
  end
end

By ActiveRecord 3.1.3 (used in Padrino 0.10.5), instance callback method support is gone. The supported way to do the above is:

class Item < ActiveRecord::Base
  before_create :set_defaults

  def set_defaults
    # whatever
  end
end

ActiveRecord (AR) had two or more incompatible ways to specify callbacks: instance methods (1st example) and callback queues (2nd example). If you have inherited AR classes (e.g. AdminUser is a child class of User, which is an AR) the instance method of the parent class is overridden and never called from child class instances. With callback queues, all callbacks are called. Current practice is described in ActiveRecord::Callbacks

In the Rails version of AmethystRSS.net, I'm using Rails 2.3.14 with instance callback methods, but not seeing any deprecation warnings. Not sure why.

`included': undefined method `before' for Sinatra::Request:Class (NoMethodError)

The solution is to patch the last line of authlogic-3.1.0/lib/authlogic/controller_adapters/sinatra_adapter.rb from:

Sinatra::Request.send(:include, Authlogic::ControllerAdapters::SinatraAdapter::Adapter::Implementation)

to:

Sinatra::Base.send(:include, Authlogic::ControllerAdapters::SinatraAdapter::Adapter::Implementation)

Thank you to the post here (Google translation here)

As mentioned in a previous post, I did benchmark some of the alternatives. ERB to Erubis is a minor change. I have already migrated from the Prototype Javascript library to jQuery’s compatibility mode. As templates are edited, I’ll move to jQuery native mode and make use of jQuery Unobtrusive JavaScript (UJS).

I’m tempted to move to more or all rendering and some data caching on the browser with the server just rendering JSON. That will wait until after the migration to Padrino.

So I benchmarked some of the alternatives – 300 items, each with 2 links and a couple of bits of text in a zebra-striped table (CSS courtesy of Twitter’s Bootstrap project), MySQL (w/ mysql2 adapter), 2700+ items in the DB. Response times are measured in Firebug, i.e. end to end as seen from the browser, both it and the server on the same laptop. HAML is 8% slower than ERB. ERB is 2% slower than Erubis. DataMapper is 7% slower than ActiveRecord 3.1. This last one is a bit surprising. I’m going to dig into it a little more. Plus figuring out how to store all times in UTC and display them in the user’s local time in DataMapper.

None of the performance differences are deal killers. My templates are ERB, I’ll leave them that way. My models are written for ActiveRecord 2.3.x. I’ll stick with it unless I find out how to achieve a lot more speed with DataMapper.

If you select HAML during project generation, ERB is available too. This suggests the possibility of fast prototyping in HAML and converting frequently used templates to ERB when stable.

The first assignment sets the default locale (found this in the Padrino Localization guide).  The next two are ActiveRecord specific.  I dug into the Rails lib/initializer.rb code to find them.

Watching Rails 3 development, I see it creeping down the slope of being all things to all Web developers with lots of new, shiny thrown in for good measure.  There are a lot of moving parts.  (I need to install a Javascript interpreter?  Really?)  Rails3 was supposed to be much more modularized and configurable, cherry picking just the pieces I need, but I may have to install everything and then try and back out unneeded pieces.

Rails was originally developed by someone writing lots of Websites.  They climb the initial, steep learning curve once and then can crank out product at a ferocious rate.  The Website part of Amethyst is relatively straight forward.  It’s the scoring and the backend (i.e., non-Rails parts) that are the secret sauce.  And much of the Rails2 and Rails3 magic costs too much in terms of user response times (i.e. the routing magic – I’ve reverted to string interpolation for URLs).

I’m investigating migrating to Padrino, a Web framework built on top of Sinatra.  Padrino claims to be 3-5 times faster than Rails.  My first cut using the simplest usable piece of Amethyst (viewing the articles in a whitelisted subset of the RSS feeds subscribed to) is appropriately twice as fast.  But it doesn’t yet have pagination or caching.  I expect the former to slightly slow it down and the former to significantly speed it up.  I’ll be blogging on my progress, the problems I encounted (and solutions when I find them), and how satisfactory I find Padrino.