Tag: rails


Skillswap: Intro to Rails

Last night I presented a skillswap, “Introduction to Rails”. This was meant to be a fairly quick overview for people who’ve done some web development before, but are completely new to Rails (and Ruby). The event was presented in two parts. First, a set of slides about what Rails is, why it works and a brief overview of Ruby. Then, a practical session.

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.

Also many thanks to Jane for the kind words. 🙂

Mongrel's Default Charset

I suddenly noticed that my last entry had Unicode problems. How embarrassing. It turns out that mongrel doesn’t set a default charset, so the usual caveats apply. Looking through the mongrel docs, you can do something with the -m option, but it still seems difficult to apply a default universally.

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!

Unicode in Rails

Unicode in Rails takes a step further today, as ActiveSupport::MultiByte is committed to the edge (r5223). More information is available over at fingertips, including a neat demo video. This should really help people who need proper Unicode support. There’s no excuse to not use UTF-8 now!

Controller Plugins in Rails

I want to write a Rails plugin, which adds a controller to a rails app. It seems like it should be easy, plugins are fairly flexible after all. After a couple of experiments, I concluded that you need at least the following defined in your plugin:

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

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” paths1, 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.

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

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…

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

Unicode in Rails

I’m really happy to see that Thijs has just pointed out that the unicode_hacks plugin is undergoing further development:

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.

Rails Security Hole

Working round the Rails showstopper.

  • (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.

Unicode for Rails — accepted

I had a little note today to say that my talk on “Unicode for Rails” has been accepted for RailsConf Europe 2006. Yay!

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…

TimedFileStore Plugin 0.1

My first rails plugin: timed_file_store is now available. It lets you expire fragments based upon the time of the cached file. It’s fairly easy to use; just bung this into config/environments.rb:

  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.

Rails Fragment Cache Expiry

I’ve been looking at Rails’ fragment caching recently. I want to cache some stuff in my view that’s more or less independent of my model (eg: output from some slow command like top). That’s fine, and easily done.

  <% 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).

Typo Upgrade

I’ve finally bit the bullet and upgraded Typo to the trunk, so I can get everything up to Rails 1.1. Unfortunately, this was quite a painful process…

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 }