First of all, starting a large application can seem daunting. To paraphrase Rumsfeld, we don’t know what we don’t know half the time - so many different features, so much complexity in the way domain objects interract, and the coder inevitably drops a ball juggling all this in his head. Add to this uncertainty the inevitable course corrections by the client, and it’s no wonder we lose a lot of sleep during the big pushes to get the foundations of our applications written.

By starting out writing specifications - and not as “business analysts” per se, but rather as programmers who are taking a moment to analyze what real world problems we’re trying to solve - we give ourselves a sort of technical permission to begin with a 10,000 foot view and build a structured path down to the ground level, step by behavior driven step. The way the application gets used really should only be considered at whatever level of detail makes sense at a particular stage in the development cycle (the insight of the agile school).

Throughout my “spec’ed” apps I have lots of “pending” specification cases. These are just placeholders to allow me to talk about future functionality I don’t yet want to implement. It’s remarkably freeing to be able to simply record what you want the code to do in plain English, worrying about the implementation later. You’re basically giving yourself a “plan of attack” without being slowed down by how the attack will actually take place - remember, we’re worried at this point about simply defining what behavior we should expect, not how that behavior will come about (also see the comments - you can simply omit the block altogether).

describe Bulletin, "when being composed" do
 
  it "should be valid with all fields filled in" do
    pending
  end
 
  it "should require a title" do
    pending
  end
 
  it "should require a body" do
    pending
  end
 
  it "should require an author" do
    pending
  end
 
  it "should require a valid author" do
    pending
  end
end

Once I’ve worked out a plan about how this code will behave, I can write a test inside each individual specification block. By writing the test first, seeing the test fail, then implementing the code that makes the test pass, I break a big problem into bite size chunks. I’m also being forced to “think ahead” about what I want to accomplish - thereby discovering edge cases that might complicate my original plan of attack. I cannot overstate the utility of thinking about what your code does in terms of tests.

describe Bulletin, "when being composed" do
 
  fixtures :volunteers
 
  before(:each) do
    @bulletin = Bulletin.new( :body => "Random body text",
                              :title => "the title of the post",
                              :author_id => volunteers(:quentin).id)
  end
 
  it "should be valid with all fields filled in" do
    @bulletin.should be_valid
  end
 
  it "should require a title" do
    @bulletin.title = nil
    @bulletin.should_not be_valid
  end

The nested describe blocks redefined my whole approach to rspec. As you’ve seen, before blocks allow you do shared setup for a group of tests. Well, you can share these before blocks among several different types of describe blocks, and the description texts just build on one another. This allows you to organize the spec in a readable and DRY form, factoring out mere setup steps to expose the more readable business logic.

  describe "when attempting to edit a comment" do
 
    before(:each) do
      @bulletin = bulletins(:the_first_one)
      @try_to_get_an_edit_form = lambda { get :edit, 
                                              :member_id => @author_of_the_note.member_url, 
                                              :trade_note_id => @the_note.id, 
                                              :id => @comment.id }
    end
 
    describe "by somebody other than the comment's author or an administrator" do          
      before(:each) do
        login_as(:some_other_guy)
        @try_to_get_an_edit_form
      end
 
      it "should not successfully load the edit page" do 
        response.should_not be_success
      end
 
      it "should display an error message" do
        puts flash.inspect
        flash[:warning].should == "Unauthorized action."
      end
    end
 
    describe "by an administrator" do
      before(:each) do
        login_as(:admin)
        @try_to_get_an_edit_form
      end
...

The next step from that was getting to shared example groups. This feature allows you to define an example group containing specified behavior that can be shared by multiple subsequent specifications. Take the example of a feature that allows certain user roles to edit a post, but not others. Instead of repeating the expectation for each role’s specification, you can define a set of expectations that apply to a certain class of behavior:

describe "an allowable edit", :shared => true do
 
  it "should render the edit template" do
    response.should render_template('edit')
  end
end

Then just reference that each role should behave like that example group:

describe "by an administrator" do
  before(:each) do
    login_as(:admin)
      @try_to_get_an_edit_form
    end
 
  it_should_behave_like "an allowable edit"
end

Now, it took me a long time to get RSpec to play nice with shared example groups, because I had gotten so used to heavily nested describe blocks that I wanted to include the shared example groups in these blocks. That will not work. You need to put all your shared example groups outside of any describe blocks. They also need to be run before they can be used, so I put them at the top

I know there’s a way to load shared examples from separate file, allowing you to bounce behaviors throughout your specs, but I haven’t gotten there yet (I hope to discover RSpec Stories soon as well, which promise an even more natural language way to specify behavior). Suffice to say, this is power enough for me now. As somebody who gets easily overwhelmed and distracted, the focus that behavior driven development gives me is priceless. I also appreciate being able to have an intermediate layer between the technical implementation frame of mind and the human-useable functionality frame-of-mind. It’s about a process that manages the monster you’re creating, and I know few programmers who wouldn’t benefit from the type of programming RSpec encourages.

The first step is figuring out which image manipulation library to use. I used RMagick just because I had the directions for compiling it handy, but ImageScience and minimagick are also supported. Installation instructions abound, so google around to find something that works for you (it may or may not be painful, and I take no responsibility for it either way).

Next, download and install attachment_fu. From your application root:

script/plugin install http://svn.techno-weenie.net/projects/plugins/attachment_fu/

But there's more to do in vendor/plugins. Since attachment_fu doesn’t have any ready-made helpers for pulling images out of the database, I rolled my own. This a hack, and I follow err's discipline of hacking plugins. Read his post for details, but essentially you create a directory called "attachment_fu_hacks" in vendor/plugins with a single file called "init.rb" In that file, paste the following:

Technoweenie::AttachmentFu::Backends::DbFileBackend.module_eval do
  def image_data(thumb_flag = false)
    if thumb_flag and the_thumb = thumbnails.first
      the_thumb.current_data
    else
      current_data
    end
  end
end

This is a tweaked version of Ron's method. Essentially, it gives you a way to pull the binary data directly, which we'll need (since we don't have a "file" to serve).

Now scaffold your asset resource:

script/generate scaffold_resource asset filename:string content_type:string size:integer width:integer height:integer parent_id:integer thumbnail:string created_at:datetime db_file_id:integer

class CreateAssets < ActiveRecord::Migration
  def self.up
    create_table :assets do |t|
      t.column :filename, :string
      t.column :type, :string
      t.column :content_type, :string
      t.column :size, :integer
      t.column :width, :integer
      t.column :height, :integer
      t.column :parent_id, :integer
      t.column :thumbnail, :string
      t.column :created_at, :datetime
      t.column :db_file_id, :integer
    end
    create_table :db_files
    execute 'ALTER TABLE db_files ADD COLUMN data LONGBLOB'
  end
  def self.down
    drop_table :assets
    drop_table :db_files
  end
end

Now, your model file will look something like this (see Mike Clark’s post or the attachment_fu readme for more details):

class Asset < ActiveRecord::Base
  has_attachment  :storage => :db_file,
                  :content_type => :image,
                  :max_size => 1.megabytes,
                  :thumbnails => { :thumb => "100×100>" }
  validates_as_attachment
end

Note the thumbnail line, which instructs attachment_fu to create a thumbnail of the image.

Your controller will look normal (except you may not want to support the edit / update functions, since that has little meaning to the asset). However, in "show" we need to be able to not only serve an HTML page with the image, but also serve the image itself. This requires us to include the mime type in environment.rb:

Mime::Type.register "image/jpeg", :jpg
Mime::Type.register "image/gif",  :gif
Mime::Type.register "image/png",  :png

and do something strange in the controller:

  def show
    @asset = Asset.find(params[:id])
    show_thumbnail = (params[:thumb] == "true")
    respond_to do |format|
      format.html { render :action => 'show', :layout => false }
      format.jpg  { send_data(@asset.image_data(show_thumbnail),
                              :type  => 'image/jpeg',
                              :filename => @asset.create_temp_file,
                              :disposition => 'inline') }
      format.gif  { send_data(@asset.image_data(show_thumbnail),
                              :type  => 'image/gif',
                              :filename => @asset.create_temp_file,
                              :disposition => 'inline') }
      format.png  { send_data(@asset.image_data(show_thumbnail),
                              :type  => 'image/png',
                              :filename => @asset.create_temp_file,
                              :disposition => 'inline') }
    end
  rescue
    flash[:warning] = 'Could not find image.'
    redirect_to home_url
  end

I'm sure there's a way to DRY up the handling of each image type, but I couldn't figure it out.

Notice how I'm handling the possibility of a thumbnail image. In attachment_fu, any thumbnails automatically created are stuck in the "db_files" table along with the normal image. No real distinction is made at that level. However, an original image model will have a “thumbnails” collection including all the thumbnails associated with it. That’s what the method we hacked into attachment_fu does. So in the controller, I just keep an eye out for the “thumb” parameter.

I'm also serving the binary image data directly if the request is for a jpg, gif, or png instead of an html file with the image rendered in it. This allows you to use the image elsewhere in the application like so:

<%= image_tag "/assets/1.jpg" %>

To get the thumbnail, it's easy:

<%= image_tag "/assets/1.jpg?thumb=true" %>

I'm sure you can roll some helpers that will be suited to how you use images (you might want to even have one that would look up the image based on the filename instead of the id).

One thing to keep in mind is that the asset model definition is not the only limit on the size of file you can upload. If you upload something too large, you may get a MySQL error about the max_packet_size. This is a MySQL setting that you may need to tweak for your purposes.

Well, that's it. Let me know if I forgot anything important.

git is a source code management system designed to make branching easy. It doesn’t enforce a “HEAD” like CVS and Subversion, so you can organize your project (or not) any way you want and fork to your heart’s content. It was written by Linus Torvalds and company to help them develop the linux kernel, so it’s all about lots of people hacking on code and figuring out a way to diff between versions without making full copies of the source. GitHub tracks, hosts, and manages all the distributed goodness: think MySpace for programmers. It also has profiles, update feeds, requests, and more. It’s perfect for starting your own, decentralized, self-organizing coding community.

Let me know if you want a beta invite. I’m jeremy6d if you want to find me.

has_many :unapproved_posts,
:class_name => "Post",
:finder_sql => 'SELECT posts.* from posts INNER JOIN users ON posts.user_id = users.id INNER JOIN groups ON users.group_id = groups.id WHERE (groups.id = #{id}) and (posts.approved is NULL)'

Yeah, it’s a little clunky, but I needed a quick fix.

Perhaps I should have spent the time on a refactor, because this code put me in Rails hell. When displaying unapproved posts in my controller, my code iterated over a collection of Post objects. When I’d first start the server, the action would grab the association with no problems. However, every subsequent time the action runs, the Post objects I got back were missing the methods I defined in the Post model. All the attributes were there and accessible, but any methods had disappeared. Note that this only happened when accessing the posts via the association helper through the controller; doing the exact same stuff in script/console gave me no problem.

After a few hours of troubleshooting and abject frustration, I came across this ticket which seems to describe the behavior I was seeing. Note that this is a 1.2.6 application I’m working on, so the lack of resolution makes some sense. However, I needed a fix, and my friend Jon suggested I just write a method that returns the collection rather than using the helper. So running the same query with Post.find_by_sql worked fine, and since I merely needed a read-only collection, this serves my purposes.

Just wanted to drop a line in case anybody in the future runs into this. Watch out using finder_sql; it does not appear reliable. Also, if you experience this behavior in a Rails 2.0 app, let me know (less important) and reopen the ticket (very important).

1. Is there / why isn’t there a version of mod_ruby that doesn’t have the “class sharing” issue? What is the technical impediment?
2. Is there any immutable reason that Ruby apps couldn’t, in the future, be deployed in a PHP-esque fashion?

The ensuing discussion in the comments is very instructive, and I’ve even been giving Cooper’s Switchpipe project a bit of attention lately. But Ezra Zygmuntowicz chimed in with quite welcome news:

I’m just going to say that Rubinius has support (as of today!) for running multiple instances of it’s VM within one process, each VM on it’s own *native* thread, each VM running many ruby green threads. Each VM has it’s own heap and so each VM could load different apps that wouldn’t interfere with each other. We have plans for a mod_rubinius for apache that takes full advantage of this feature. Stay tuned

I certainly will!

The busyness won’t last; stay tuned for real blogging.

The answer is that not only is it possible, but it’s also rather easy. I made a modification to my wp-config.php file that appends a host name prefix to every WP table in the database. So I run everything in one database, and the wordpress PHP code just chooses the tables to run off of based on the requested host. Pretty slick, because it also means I can keep all my themes, plugins, etc. in one place and just turn them on and off in the different tables. And I’m using Subversion to run updates, which means it doesn’t overwrite files I’ve modified, while still letting me do updates with one command.

So I guess now that I’ve found such a convenient solution to my problem, I’m wondering if it’s vulnerable at all how vulnerable it is. I suppose I’m advertising any security holes, but I’m a pretty transparent internet user, and all the data’s backed up anyway - plus, I keep a pretty good eye on the server, and it’s locked up rather tight for anything that would be terribly damaging. But all you WordPress gurus: what do I need to know about this approach? Is it insecure? Are there performance issues with which I need to concern myself? This is running everything from my personal blog to a moderate traffic aggregator. I’d appreciate any insight or warnings or sharp tongue lashings you could provide.

And of course, this is only the first step. I still want to do a full reengineering of my stylesheet and clean up loose ends in the design. And I’m gonna implement some long-overdue social networking upgrades… you’ll see. So stay tuned for more wordpress-y goodness.

Also, in case you didn’t hear, Rails 2.0 was released last month. ‘Tis hot. And I finally figured out that scaffolding has NOT been gutted; I had lamented the fact that the scaffolded views no longer generated HTML input fields based on the database table fields. But now it’s much more consistent: you name the fields at generation time and it creates the views and the migration for you. Kids, it pays to read the docs.