But sometimes it may be tricky or inconvenient to perform some operations using Sphinx, and you want to mix in some regular SQL. Here’s a very easy way to combine Thinking Sphinx searches with named scope:

  named_scope :sphinx, lambda {|*args| {
    :conditions => { :id => search_for_ids(*args) }
  }}

named_scope :random_five, :order => "RANDOM()", :limit => 5

The only problem with this is, if you’re using SQLite for testing and local development, and MySQL for deployment, your code is going to break because MySQL does not use the same random syntax that SQLite does. You can’t entirely blame the frequently-standards-incompliant MySQL here though, because ordering by random isn’t a part of standard SQL and is added as a stored procedure or vendor extension in most RDBMS’s.

To solve this problem, I’ve created a small monkey-patch to Rails which allows you to use code like the following:

named_scope :random_five, :order => :random, :limit => 5

You can access the code here.

What do you think? If you find this useful, let me know and I’ll submit it as a patch to Rails.

http://pastie.org/249500

It’s not pretty, but lets you create a simple in place editor that works with RESTful controllers. Ideally, this should be done unobtrusively, but if you need to pass in a lot of options (for example, to change language used in the controls), then doing this unobtrusive can become a bit of a PITA.

The only “weird” thing you need to do is make your show method have a block that responds to requests for JSON if you want to use the loadTextURL option.

I’ll see about doing this up as a simple plugin if anyone is interested.

If you want to see a nice rails plugin that does some of this in a more unobtrusive manner, check out Pat Nakajima’s better_edit_in_place plugin. It’s still being actively developed but looks like it will soon be an excellent resource.

It is, by design, very simplistic: It only supports using a filesystem for storage, and only supports MiniMagick as an image processor. However, its code is very small, clean and hackable, so adding support for other backends or processors should be fairly easy.

HasImage works best for sites that want to show image galleries with fixed-size thumbnails. It uses ImageMagick’s crop and center gravity functions to produce thumbnails that generally look acceptable, unless the image is a panorama, or the subject matter is close to one of the margins, etc. For most sites where people upload pictures of themselves or their pets the generated thumbnails will look good almost all the time.

It’s pretty easy to change the image processing / resizing code; you can just override HasImage::Processor#resize_image to do what you wish:

  module HasImage::
    class Processor
      def resize_image(size)
        @image.combine_options do |commands|
          commands.my_custom_resizing_goes_here
        end
      end
    end
  end

Another image attachment library? Why?

The three chief virtues of a programmer are: Laziness, Impatience and Hubris. - Larry Wall

Attachment_fu is too large and general for some of the places I want to use images. I sometimes found myself writing more code to hack attachment_fu than it took to create this gem. In fact, most of the code here has been plucked from my various projects that use attachment_fu.

The other image attachment libraries I found fell short of my needs for various other reasons, so I decided to roll my own.

Examples

Point-and-drool use case:

It’s probably not what you want, but it may be useful for bootstrapping.

  class Member < ActiveRecord::Base
    has_image
  end

Single image, no thumbnails, with some size limits:

  class Picture < ActiveRecord::Base
    has_image :resize_to => "200x200",
      :max_size => 3.megabytes,
      :min_size => 4.kilobytes
  end

Image with some thumbnails:

  class Photo < ActiveRecord::Base
    has_image :resize_to => "640x480",
      :thumbnails => {
        :square => "200x200",
        :medium => "320x240"
      },
      :max_size => 3.megabytes,
      :min_size => 4.kilobytes
  end

HasImage also provides a view helper to make displaying the images extremely simple:

<%= image_tag_for(@photo, :thumb => :square) %>

Getting it

Has image can be installed as a gem, or as a Rails plugin. Gem installation is easiest, and recommended:

gem install has_image

and add

require ‘has_image’

to your environment.rb file.

Alternatively, you can install it as a Rails plugin:

./script plugin install git://github.com/norman/has_image.git

Rails versions before 2.1 do not support plugin installation using Git, so if you’re on 2.0 (or earlier), then please install the gem rather than the plugin.

Then, make sure the model has a column named “has_image_file.”

Git repository:

git://github.com/norman/has_image.git

Hacking it

Don’t like the way it makes images? Want to pipe the images through some crazy fast seam carving library written in OCaml, or watermark them with your corporate logo? Happiness is just a monkey-patch away:

  module HasImage
    class Processor
      def resize_image(size)
        # your new-and-improved thumbnailer code goes here.
      end
    end
  end

HasImage follows a philosophy of “skinny model, fat plugin.” This means that it tries to pollute your ActiveRecord model with as little functionality as possible, so that in a sense, the model is acts like a “controller” and the plugin like a “model” as regards the image handling functionality. This makes it easier to test, hack, and reuse, because the storage and processing functionality is largely independent of your model, and of Rails.

My goal for HasImage is to keep it very small. If you need a lot of functionality that’s not here, instead of patching this code, you will likely be better off using attachment_fu, which is much more powerful, but also more complex.

Bugs

Please report them on Lighthouse.

At the time of writing (July 2008), HasImage is in its infancy. Your patches, bug reports and withering criticism are more than welcome.

For now, all development is being committed to Git, and then patched into the svn repository. So, if you’re using the svn repository don’t worry, it will remain current for a while.

I remember first hearing about Git during the Linux/Bitkeeper contoversy, and recall thinking Linus Torvalds was odd for not using CVS or Subversion over Bitkeeper, and then thinking he was certifiably insane for deciding to roll his own version tracking system once Bitkeeper didn’t work out.

Of course, Linus Torvalds is (a) a better programmer than me and (b) smarter than me, so there you go. Git has evolved into a very nice tracking system; for me everything that was slow and annoying in SVN (namely, comparing revisions and branching) is fast and easy using Git. If you haven’t yet taken a look at it, you should.

You can take a peek at the shiny new friendly_id repository here.

If you’d like to see a quick introduction to Git, take a peek at Sebastian Delmont’s presentation below.

GIT Talk (nyc.rb) from Sebastian Delmont on Vimeo.

The solution is to use Mocha to mock an instance of ActionController::Flash::FlashHash and capture the value being set. Here was my solution:

def test_create_with_empty_email_sets_error_in_flash
  hash = {}
  ActionController::Flash::FlashHash.any_instance.expects(:now).returns(
    hash
  )
  post :create
  assert_not_nil hash[:error]
end

Don’t you ever feel really dumb when you realize that what you’ve been trying to do for days is actually so easy? I haven’t worked as a sysadmin for 4 years now and find my skills have really atrophied… but anyway… thanks to the Google gods I have managed once more to get away with it.

Just because Rails is good is not an excuse to avoid using quality software written in another programming language. I know a lot of Rails developers dislike PHP but I’m happy to work with good software - especially free software - no matter what language it’s written our in. And this blog was never meant to be a “Rails blog,” we here at Randomba also work with C++, Java, PHP, Perl, Objective C, Cocoa and a lot of other languages/frameworks. Yes, we CAN all get along. We just happen to be doing a lot of Rails stuff lately.

Anyway… this means that I need to apologize to the thousands hundreds several people that left comments on the previous blog; it was a little complicated to port them over, and I got lazy and decided to leave them. This should be the last time it happens, I promise.

However the current release, Etch, comes with Ruby 1.8.5, which is a bit old and has some problems running Mongrel. It’s very easy to download and compile Ruby, installing it in /usr/local, but this bypasses Debian’s packaging system. But it’s easy to do better; using Ruby’s package manager to install Ruby and maintaining all the benefits of having your installed software under package management.

Note that you’ll need to be root to run these commands.

Make sure you haven’t installed ruby in your package manager yet.

Or, if you have, uninstall it before proceeding to avoid package conflicts. Read the comments on the post below for more details.

1) Update your /etc/apt/sources.list, to use Debian’s “unstable” source packages:

deb-src ftp://debian.mirrors.tds.net/debian/ unstable main non-free contrib

2) Update your list of available packages:

apt-get update

3) Install Ruby’s build dependencies:

apt-get build-dep ruby1.8

4) Install Debian’s package management development programs:

apt-get install dpkg-dev

5) Download the Ruby source package and build it:

apt-get source -b ruby1.8

This took about 5 minutes on my system with SATA disks and a 2 gig P4. It creates the following packages:

• irb1.81.8.6.111-4all.deb
• libdbm-ruby1.81.8.6.111-4i386.deb
• libgdbm-ruby1.81.8.6.111-4i386.deb
• libopenssl-ruby1.81.8.6.111-4i386.deb
• libreadline-ruby1.81.8.6.111-4i386.deb
• libruby1.81.8.6.111-4i386.deb
• libruby1.8-dbg1.8.6.111-4i386.deb
• libtcltk-ruby1.81.8.6.111-4i386.deb
• rdoc1.81.8.6.111-4all.deb
• ri1.81.8.6.111-4all.deb
• ruby1.81.8.6.111-4i386.deb
• ruby1.8-dev1.8.6.111-4i386.deb
• ruby1.8-elisp1.8.6.111-4all.deb
• ruby1.8-examples1.8.6.111-4all.deb

6) Install the packages:

dpkg -i *.deb

You can also just install the ones you think you’ll need; at very least you’ll want ruby1.81.8.6.111-4i386.deb, and the ri, rdoc and irb packages.

7) Bask in the Ruby 1.8.6 goodness:

norman@randomba:$ ruby -v

ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]