AmethystRSS Blog

AuthLogic 3.1.0 doesn’t play nice with Sinatra 1.3.2. The error message is;

`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)

It is tempting to do some substantial rewrites during migration to a new platform. Experience has shown that it is rarely a good idea. Just the migration itself is enough disruption – ActiveRecord (AR) and ActiveSupport 2.3 to 3.1, Rails controller syntax to Padrino/Sinatra, Ruby 1.8.7 to 1.9.2 and the string encoding issues.

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.

I ported a very minimal part of AmethystRSS.net to Padrino. It looks good. Before I really start full-time, I tried out a few alternatives. Amethyst has an inherent responsiveness problem, e.g. rendering 300 partials with 5 links and a couple of bits of text while the user waits. Caching helps, the second time they access the list. And the list ages rapidly, 50-70 new items a day. Wait three days to check your RSS feeds and all 300 are new.

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.

Exceptions were occasionally occurring in Padrino: Encoding::CompatibilityError - incompatible character encodings: UTF-8 and ASCII-8BIT:. This is with Ruby 1.9.2. Googling the error message turned up plenty of hits, none of them helpful. Trying the same thing in the Padrino Framework Google Group was more helpful, but a key piece of information was missing. Or since the posts were a year and a half ago, things changed. The mysql gem encodes all strings as 8BIT ASCII! Even if the database is UTF-8. Switching to the msyql2 gem and setting the adapter to mysql2 in config/database.yml solved the problem. If your don’t set the adapter correctly, Padrino complains about stack too deep. I encountered the same stack overflow with ruby-mysql.

All timestamps in Amethyst’s database are in UTC.  Out of the box, Padrino and ActiveRecord assume they are in the local timezone. There may be a better way (i.e., ORM agnostic), but this works for ActiveRecord.  In config/boot.rb:

##
# Add your before load hooks here
#
Padrino.before_load do
I18n.locale = :en
ActiveRecord::Base.time_zone_aware_attributes = true
ActiveRecord::Base.default_timezone = :utc
end


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.

Rails 3 has outgrown my needs.  I spent a day and a half trying to migrate Amethyst from Rails 2.3 to Rails 3.0 and didn’t appear to be any closer to being done.  And I encountered a number of Rails3 bugs and/or incompatibilities that had no obvious fix.

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.