For the practical, I installed Locomotive and we ran through a quick session of getting started with a rails application, building a model and putting up some scaffolding on top of that. There were only five macs, so people had to work together, which probably helped. I have to issue a huge thanks to lighthouse for the opportunity to use the fantastic venue.

I did actually have further slides and handouts, which progressed the practical, but it was already getting on for 20:30, so it seemed wiser to halt whilst things were still going well.

Like all live things, not all went to plan. The main annoyance was the fact that Locomotive-generated projects (well, Rails really) default to using MySQL. A quick switch to SQLite made things work a lot better. Servers can be a pain when you’re trying to get things running.

The slides and handout are available for download.

• Introduction to Rails (Keynote, 1.5Mb)
• Introduction to Rails (PDF, 776Kb)
• Introduction to Rails Handout (PDF, 68Kb)
• Introduction to Rails Handout (Pages, 36Kb)

Also many thanks to Jane for the kind words.

Thankfully, I’m proxying to mongrel via Apache. So correcting the situation turned out to be as simple as adding this to my VirtualHost config.

  AddDefaultCharset UTF-8

I was actually not sure that this would work, because Apache is proxying rather than serving files directly. But it does work. I suspect that it may not work un der Apache 1.3, but that would need to be confirmed.

But now the error is corrected and I’m Unicode happy once more. Hurrah!

1
2
3
4
5

  class FooController < ActionController::Base
    def hello
      render :text => 'hello world'
    end
  end

1
2

  module FooHelper
  end

But there’s still a serious problem. It only works on the first request. After much mucking around in routing.rb, I’ve found out why. It turns out that when a request is finished, dispatcher.rb clears out all the controllers, so that routing.rb will reload them on the next request (only in development mode). The problem is, that the controller in the plugin doesn’t live in one of the “trusted” paths¹, so can’t be reloaded. So, on the second and subsequent requests, you get a routing failure.

There’s a quick and easy way around this.

1
2
3
4
5
6
7

  class FooController < ActionController::Base
    class << self
      def reloadable?
        false
      end
    end
  end

But that means that you have to restart the web server each time that you change your plugin, which certainly isn’t ideal. At this point, I started thinking about monkey-patching how the reloading works, but a gag reflex caused me to take a step back and think differently.

One minor tip: running rake rails:freeze:gems makes it much easier to dig into the rails source code. Mostly because it all becomes immediately accessible from within textmate’s “Go To File” command.

Looking around the web, I can’t find much information about controllers in plugins. One answer appears to be the rails engines plugins. But it appears to be more heavyweight than I’d like.

However, nuby on rails mentions an interesting alternative.

You can’t directly write a controller plugin, but you can write a generator that copies a controller to your app/controllers directory.

The more that I think about this, the more it makes sense to me. It ensures that magic URL namespaces don’t just “appear” in your application. It also provides a point for overriding aspects of the actions I wish to provide. In addition to all that, it’s just plain better separated so easier to test.

And I haven’t even begin to think about how the views are going to work…

¹ app/, lib/ and components/ according to safe_load_paths.

We’re almost ready with a new version of Julik’s ‘Unicode Hacks’ that’s now called ‘ActiveSupport::Multibyte’. You can find more information and code on the ‘Multibyte for Rails’ project site.

I’m particularly pleased to see that: “We hope to get ActiveSupport::Multibyte accepted as a new core extension in the 1.2 release of Ruby on Rails”. That would be a real boon. Check out the FAQ too.

• (pdcawley)++
• (svk)++

I now have the fixed version of typo (soon to be 4.0.2), around an hour after it was committed.

As to the whole “full disclosure” thing by the rails team? They handled it pretty badly. As somebody else commented, it didn’t work for OpenBSD a while back and if anybody could do that, OpenBSD could.

Now I have to write the thing. This is going to be interesting. I have only a few weeks to go, and most of those weekends are already taken…

  ActionController::Base.fragment_cache_store =
    TimedFileStore.new("#{RAILS_ROOT}/tmp/cache", :atime => 15.minutes)

And now any fragments which haven’t been accessed in the last 15 minutes will be removed the next time that they’re accessed.

This is rather coarse—it applies to all fragments. But it’s also pretty simple and does what I need for now.

  <% cache do %>
    <%=h `top` %>
  <% end %>

The trouble is expiry (as it always is with caching). By default, Rails offers you things like expire_fragment and Sweeping, but these are very much tied in to the Model classes.

What I really need is to know the timestamp of each entry in the cache, so I can make judgements based on that. Unfortunately, at present, ActionController seems to treat each cache entry as little more than a blob of data. I need to store metadata with it, like when it was last accessed and when it was put in the cache. I’m not sure that I can do that in the current framework.

It looks like I’m not the only one who wants this: see also Time-based fragment caching in Rails. I’m not 100% sure I like that solution, but it does look like it would work. Perhaps I’m too institutionalized towards cron? I’d definitely rather avoid using cron if I can possibly help it (lesson from work: system dependencies are bad).

Normally, I track bits of software I might want to hack on in a vendor branch in subversion, and use svn_load_dirs.pl to update to new releases. This works extremely well with wordpress at work, for instance.

Sadly, svn_load_dirs.pl couldn’t cope with the typo trunk, as a directory got replaced by a symlink. Ooops. I tried working around it, but eventually, it was easier to give up and start afresh, redoing the changes I’d already made in subversion. I suppose it would have been a lot easier with SVK.

Unfortunately, a number of things haven’t caught up with the latest typo changes. In particular, the origami theme that I was using needs some loving attention. So it’s back to the default theme, “azure” for the moment, until I can spend some time on it.

Also, I couldn’t figure out how to make the google sitemaps patch work, so that’s another “gone for now” feature.

Please let me know if you spot anything else…

Update: Comments now enabled. Sorry about that.

Update#2: I’ve now fixed the comments feed a bit. It turns out that one of the migrations missed out on creating guids for all the comments…

  % ruby script/console production
  >> comments = Comment.find_all
  >> comments.reject { |c| c.guid }.each { |c| c.create_guid; c.save }