So instead of this:

delegate :first_name, :to => :profile
delegate :last_name, :to => :profile
delegate :some_other_attribute, :to => :profile


side note: I’m not sure but I don’t believe delegate can take multiple attributes (I tried to look this up but for some reason couldn’t find the documentation for this method and didn’t have time to dig in the code)

You could do the following:

include the Ruby Extension Forwardable in the parent model class


include Forwardable


and then add this line:

def_delegators :profile, :first_name, :last_name, :some_other_attribute


So yeah that was my little ah ha moment. I am sure there are even better ways than this but this was better than what we were looking at doing to begin with.

We were unable to get an official room for a BoF but I have decided we will just take over some area of the convention center. Lets meet outside Exhibit Hall E at 7:30 on Saturday night. We can discuss whatever we want to. We are also planning appetizers and cocktails after the BoF. Hashrocket Inc, the company I work for is sponsoring the evening. Thanks Hashrocket!

Please either come to the BoF for more information or find one of the ladies with a DevChix logo on their badges for more information. I will also have stickers to give out (until they run out).

We would love to meet ALL the women developers at the conference so please come out and get to know us.

Cheers
Desi

Place the following code snippet in your application.rb file

 session :mobile => true, :if => proc { |request| Utility.mobile?(request.user_agent) }

  class Utility

    def self.mobile?(user_agent)
      user_agent =~/(iPhone)/i
    end
  end

Then in your view or your presenter code put a check for the session variable and if it is set then display the clickable phone number with the tel protocol in the href like so

"tel:#{contact.phone}"

and if its not set then just do things normally. Make sure you have the check there because if you don’t then when someone clicks the link in the browser it will complain about not understanding the tel protocol.

And my brand spankin new, made-from-scratch stab at programming. It’s going to be a bumpy ride: bumpy like fun-old-rollercoaster-bumpy not trainwreck-bumpy (universe willing).

Please allow me to rattle off some quick background facts so you know what planet I’m coming from. I’m a 26 year old retired bartender. I did that for more years than I care to say (ok fine, 8). I fancy myself an amateur artist; basically, I paint for therapy and fun. I’ve always liked things of a nerdy nature (i.e. writing very basic html in a webshell on angelfire when I was 13, Magic the Gathering, guys who majored in Astrophysics, etc). I consider myself very confident and intelligent, and it’s a shame that went to waste for so many years. That being said, years of bartending with no substantial plans for the future wore me out and made me feel quite desperate for awhile.

Then something changed. I got beat down so much by the universe’s way of telling me to stop f’ing around, that I got fed up with being fed up. Well, Desi McAdam happens to be one of my favorite people on the planet and a very close friend, and she had always offered to teach me programming…intensively. She and my other longtime friend/ROR evangelist Obie Fernandez had always told me they thought I’d be a great programmer. I didn’t know what they were talking about. So I called up my dear Desi and said “I’ll do whatever it takes. Let’s do this thing.”

I thought I was going to be learning in my off time while still bartending and getting tutored whenever Desi was in town. I knew this would take a very, very, very long time, but I felt ready for the challenge.

As it turned out, she and Obie were down here in Florida on the beach working with this fabulous guy Mark Smith. I had met him some weeks before, and we all had a great time together. They wanted to bring an apprentice on to the small team, so voila! Here I am. I am now in full on training starting with nothing but my instinctual and intellectual abilities and no experience. I am extremely grateful for the opportunity I have, and I intend to give back to Desi and Obie by trying hard to be a bad ass programmer.

Desi is putting alot of effort into being my personal, full-time tutor, and I think she rocks socks for it.

So I’m offering up myself, my victories, and my many future foibles here for your musing and amusement.

Cheers and enjoy

I read recently that RSpec got support for Test::Unit interoperability. Obviously now is the time to make the switch from Test::Unit to RSpec. You can do it without a mass exodus from Test::Unit. Use your existing tests inside the RSpec test harness.

So here’s how I converted all out legacy tests to rspec.

Step One: update RSpec

This is fairly self-explanatory and written up elsewhere. However, in short, I updated both our rspec and rspec_on_rails plugins, remembering to rerun

$ ruby script/generate rspec

Make a back-up copy of the spec_helper if you’ve customized it. Compare it to the one generated for the new rspec version to see if there’s been any significant changes, and if so, merge them into your helper.

Step Two: move your files from test/ to spec/

This is what I did: I copied test/unit/* to spec/models/, renaming them appropriately:

  ## current_path is a hash where :tu => test::unit path and :s => spec path
  def make_tests_specs(current_path)
    current_path[:tu].each do |file|
      unless file == “.” or file == “..”
        full_file = File.join(current_path[:tu].path, file)
        if File.directory? full_file
          spec_file = full_file.gsub(/test/, “spec”)
          spec_file.gsub!(/unit/, “models”)
          spec_file.gsub!(/functional/, “controllers”)
          FileUtils.mkdir_p(spec_file) unless File.exists? spec_file
          make_tests_specs({:tu => Dir.new(full_file), :s => Dir.new(spec_file)})
        else
          new_spec = File.join(current_path[:s].path, file.gsub(/_test/, “_spec”))
          puts “converting TestCase #{full_file} to ExampleGroup #{new_spec}\n”
          File.copy(full_file, new_spec)
        end
      end
    end
  end

Step Three: change your assertions

While that would move all my tests over to the specs directory and rename them, I figured, why should I stop there? I realized I could probably do a lot of the Test::Unit to RSpec syntax conversions programmatically. Here are the regular expressions I used to do the substitutions - while these worked great for our codebase at StreetEasy, your mileage may vary, so be sure to use caution before running this against your code base (and hey, you do use source control, don’t you?):

if line =~ %r@require.*?test_helper@
  new_file.puts "require '#{RAILS_ROOT}/test/test_helper'"
  new_file.puts "require '#{RAILS_ROOT}/spec/spec_helper'"
elsif line =~ %r@class.*?TestCase@ and line !~ %r@Controller@
  new_file.puts "describe 'transitioning from TestCase to ExampleGroup' do"
elsif line =~ %r@class\s*(.*?)Test@
  new_file.puts "describe #{$1}, 'transitioning from TestCase to ExampleGroup' do"
  new_file.puts "integrate_views"
elsif line =~ %r@def setup@
  new_file.puts "before do"
elsif line =~ %r@def test_(.*?)\n@
  new_file.puts "it \"should #{$1.humanize.downcase}\" do"
elsif line =~ %r@assert_response :success@
  new_file.puts "response.should be_success"
elsif line =~ %r@assert_response :redirect@
  new_file.puts "response.should be_redirect"
elsif line =~ %r@assert_redirected_to (.*?)\n@
  new_file.puts "response.should redirect_to(#{$1})"
elsif line =~ %r@assert_equal (.*?),\s(.*?)\n@
  m1 = $1
  m2 = $2
  unless m1.nil? or m2.nil?
    unless m1.match(/nil/) or m2.match(/nil/)
      new_file.puts "#{m1}.should == #{m2}"
    end
  end
elsif line =~ %r@assert assigns\(:(.*?)\)$@
  new_file.puts "assigns[:#{$1}].should be_true”
else
  unless line =~ /^class.*?Controller.*?rescue_action.*?end$/i or line =~ /require ‘.*?_controller’/i or line =~ /^#/
    new_file.puts line
  end
end

The above block of code will convert any response (:success, :redirect, redirect_to), assigns, and equality assertions. It will change your method declarations to “it ’should…’ do/end” block syntax. It will require both the test_helper and spec_helper. It will integrate_views by default on your functional (controller) tests; you might want to go through those by hand later and separate out the front-end stuff into a set of view tests, depending on how you feel about them.

You could definitely write more substitutions - there are more assertions in Test::Unit, of course. If your code base makes extensive use of other assertions you’ll probably want to add to the regexes above. In our case, however, I found the above satisfied converting the most straight-forward Test::Unit assertions, leaving me with the slightly more complicated examples to convert by hand, which brings me to the next step.

FYI, you can find a table of Test::Unit assertions and their RSpec equivalents here on the RSpec documentation site.

Step Four: run rake:spec and see what happens

You might as well see what situation any automated conversion process left you in. I had a few errors during this phase - mostly due to the fact that I forgot to move my fixtures, woops - but it didn’t take me very long to resolve them.

Step Five: go through each sparkling new spec and convert any remaining Test::Unit-based assertions into RSpec syntax.

The good news: you can take your time on this step since RSpec now plays nice with Test::Unit. I was in a particularly motivated and productive mood after finding myself with a big directory full of specs (and an amazingly empty test/ directory) so I just went through them all right then and there. It took me most of the afternoon, but when I left work that day I was able to see this, which is just awesome:


$ rake spec
........................................................................................................................................................................................................................................................................................................................................................................................................................................................

440 examples, 0 failures


As you can see from the amount of time it took all 440 examples to run, we could definitely benefit from a greater use of mocks and stubs in our controller tests. 70 seconds is a tad bit long. That’s next on the to do list - mock and stub wherever I can in our controller tests, followed by integration/big picture testing using Story Runner, and then, if there’s time*, refactor our specs to be better organized and efficient - I can think of several places where I had wished for nested examples, or could have used shared examples, had I been aware they existed at the time.

I’ll be writing up my experience with Story Runner in the next couple of weeks. Til then, though, best of luck in your specs!

* always a compromise when you’re trying to do things the right way and add business value simultaneously.

For more information Behavior Driven Development, check out Dan North’s article, “Introducing BDD.”

You can find the documentation for RSpec at http://rspec.info.

Many thanks to Joshua Sierles, Paul Marsh, and Josh Knowles for their time in reviewing this!

I didn’t get to see many of the sessions because I was busy preparing for my talk but I was able to catch Obie’s presentation - Advanced ActiveRecord which was really good (and I am not just saying that because he is my boyfriend). I also caught the ending Keynote where Nap (I actually don’t know his real name) announced the Rails Rumble winners. There were several screencasts and it made me wish that Obie, Clay, Nick and I would have had time to get the video that was shot of us over the weekend edited and ready for prime time. We had a blast doing the competition and while we didn’t win (we got honorable mention) we learned a lot and I think we all grew closer in those 48 hours. The teams that did win did a tremendous job on their apps and well deserved the loot. Take a look at the winners there really are some great apps. Rails Rumble Winners

Friday evening a bunch of people got together after the conference and played several games of Werewolf which is a really fun game to play. I got to know a lot of people during that game and it was a great way to wind down.

Couple of other thoughts before I end the post. ShesGeeky (un)Conference sounds like it is going to kick major ass so any of you ladies out there who can attend make sure you get registered. Additionally, ladies if you want to talk during the conference please contact the organizers.

GrrrlCamp seems to be getting a good footing. I was lucky enough to meet THE Gloria this past Friday and I look forward to being a part of GrrlCamp.

I have taken on an apprentice and she will soon be posting to the blog about her experiences. I am in the process of trying to see if creating an apprenticeship type program run by DevChix is possible because after speaking with Sonia (one of the women on DevChix) she helped me figure out that I would really like to have a program that fits the apprenticeship model rather than a mentoring program. Look for more to come on this in the future.

If you can picture an office of harried administrators dealing with ever-changing AMA requirements — “This brochure needs to go with this program!”, “This xray picture needs to go with Question 7″, “This program needs to sing ‘Missing You’ while showing you diagrams of a root canal”.. (OK, maybe not the second item), you’ll see why I wanted to build a system that could expand easily. I did not want to find myself in the position of trying to look tough while shamefacedly muttering, “I’m sorry, PDFs can only go with *Programs*, as you initially specified” and watching these not-so-gentle administrative souls stare at me with fully warranted incredulity. Blaming the client is like [fill-in-the-blank]: weirdly fun for about 10 minutes before the hangover sets in.

This project turned into a tour of attachment_fu, single table inheritance, polymorphism and functional testing of uploads. Thanks to input from friends, blogs and the usual Internet suspects, I got it up and running in its first form and decided to write it up. Hopefully what I’ve learned can help someone else. “Link-outs”, the reclusive programmer’s form of the “Shout Out” (aka a list of great resources), can be found at the bottom of the article.

Goal

To implement a system that would allow for many types of files to be uploaded and attached to many types of resources.

Requirements

1. Many types of assets (image, pdf, etc.)
2. Assets belong to many types of resources (program, question, etc)
3. Assets upload to the file system
4. Assets validate in the context of their parent resource [you upload the pdf in the program form; the image in the question form, etc]
5. All functional tests pass for uploads

Design

Rather than have database tables for each attachment type (PDFs and images, then eventually MP3s) I made one table called Assets. Listening to my requirements, a friend suggested setting up my Assets model using polymorphism and single table inheritance and that I look into attachment_fu for the uploads. For this exercise I will only be focusing on the PDF upload. Readers can extrapolate from there for image or other media types. This article does not address image resizing, or anything related to uploading images. There are some great links at the bottom that deal with these topics in depth.

Modeling the domain:

Assets (the table) has a field called type that is be [PDF, Image (etc)]; a field called resource_type which is the name of the class it belongs to, [Program, Question, etc.] and resource_id which is the id of the resource it belongs to.

The Asset class will inherit from ActiveRecord. PDF and Image (and any future file types we add to the system) inherit from Asset. Line items from Assets (the table) will look like this (leaving out the other fields for now)

type   | resource_type | resource_id

Pdf      | Program         | 82
Image  | Question         | 79

For my assets, I created the following models:
asset.rb, image.rb and pdf.rb. The latter two inherit from Asset.

# [Asset.rb]
class Asset < ActiveRecord::Base
  belongs_to :resource, :polymorphic=>true
end

# [Pdf.rb]
class Pdf < Asset
  belongs_to :program
  has_attachment  :content_type=>‘application/pdf’,
                         :storage=>:file_system,
                         :path_prefix=>’public/uploads/pdfs/’,
                         :size => 1.megabyte..3.megabytes
  validates_presence_of   :content_type, :filename

   def validate
     if filename &&  /pdf$/.match(filename).nil?
         errors.add(:filename, “must be a PDF “)
     end
  end

end

Because I am using attachment_fu, I need to have a set of basic fields in my table that will handle image and file uploads. The migration I created looks like this:

t.column :parent_id,  :integer     # for the thumbnails of resized images, required for plugin
t.column :type, :string               # for STI on this table (curent types are image, PDF)
t.column :resource_type, :string  # for polymorphism on this table (current types are Program, Question)
t.column :resource_id, :integer    # for polymorphism, (program_id, question_id, etc)
t.column :content_type, :string    # Fields here [content_type] and below all attachment_fu requirements
t.column :filename, :string
t.column :thumbnail, :string
t.column :size, :integer
t.column :width, :integer
t.column :height, :integer

To create the relationship for my parent models (question and program) I set up the polymorphic relationship like so:

# [program.rb]
class Program < ActiveRecord::Base
   has_many    :pdfs, :as=>:resource,  :dependent => :destroy
end

# [question.rb]
class Question < ActiveRecord::Base
  has_many      :images, :as=>:resource, :dependent => :destroy
end

Note the difference between delete and destroy. Destroy will remove the entry from the database and the file from the filesystem. Delete will only delete the database entry.

Once this is set up, you can test it in the console and see the magic of Rails at work. Through the column names and relationships we’ve built, entries in Assets are automatically created. It’s one of the things that’s great about Rails. It doesn’t simply describe different modeling patterns: it implements them if you set up your code correctly. It’s a beautiful thing.

Uploading

Without moving files to the server, the system is not complete. So, onto attachment_fu. The attachment_fu tutorials I found online all made the assumption that the attachment you are uploading is an entity of its own, in its own form: a mugshot, for instance. My case was different: I needed to embed the attachment in the forms for their parent resources (pdf in the program form; image in the question form, etc) rather than independently. So I needed to validate a form for more than one model. In my _form.rhtml partial for program I have the pdf field like so:

# [views/program/_form.rhtml]

< label for="program_notes" >Notes

<%= f.text_area :notes  %>

# … more fields …
< label for="program_status" >Add Brochure? [PDF Files only]< /label >
<%= file_field("pdf", "uploaded_data") %>

This means that both a pdf object and a program object are being passed back to the program controller. Since we know that a program has_many pdfs, we can use program.pdfs.build in order to create — then validate and ultimately save — pdf objects.

Validating in context of parent resource:

I needed to check for errors with my program fields and my pdf field. This snippet is what I ended up with. The second line, validate_and_build_pdf is just a result of refactoring: it allows the validation methods to be run if you select a file through the upload file field (so if you try to upload a gif, the validation in Pdf.rb will squak) — but not if you just leave that field empty.

#[programs_controller.rb]
def create
  @program = Program.new(params[:program])
   validate_and_build_pdf(params[:pdf],params[:pdf][:uploaded_data])
   if @program.save
      flash[:notice] = ‘Program was successfully created.’
      redirect_to :action => ‘list’ and return
   else
      render :action => ‘new’
   end
end

# this method stops program from saving the asset if the field is blank,
# and returns type-errors if relevant (files not PDF)
def validate_and_build_pdf(fileParams,file)
  if Asset.is_valid_file?(file)
     @pdf = @program.pdfs.build(fileParams)
  end
end

The reason for the Asset.is_valid_file? method was the same: if no file was uploaded an entry was still being made in the assets table due to the polymorphic relationship. So I had to make sure I was dealing with an actual fileobject, not an empty field. Since this would be used across the application for all types of file uploads, I made this a class method of Asset.

[Asset.rb]
# Checks that the object is one of the following types before running validation on it
def self.is_valid_file?(fileObj)
  if fileObj.is_a?(Tempfile)|| fileObj.is_a?(StringIO)
     || (defined?(ActionController::TestUploadedFile) && fileObj.instance_of?(ActionController::TestUploadedFile))
     true
  else
     false
  end
end

You may be wondering what’s up with the ActionController::TestUploadedFile condition — it’s because when you run functional tests of uploaded assets, that is what they are — they are not instances of fileObj.

Once it’s determined that you’re dealing with a valid file and you hit custom validation methods (such as informing the user that the file needs to be a pdf), you can include them with your program error messages so you only get one messages box at the top of your form, not two:

<%= error_messages_for :program, :pdf %>

Pass Functional Tests

This part is where you test all your uploads from your functional tests. To test uploaded files, you need to put files in your fixtures/files directory then build your tests.

# [programs_controller_test.rb]
def test_create_with_pdf
  fdata = fixture_file_upload(’/files/semi.pdf’, ‘application/pdf’)
  num_programs = Program.count
  post :create,   :multipart => true,
  :pdf=>{”uploaded_data”=>fdata},
  :program => {:name=>”Newest Created Program”,
                    :is_ongoing=>1,
                    :status=>”Edit”}
  assert_response :redirect
  assert_redirected_to :action => ‘list’
  assert_equal num_programs + 1, Program.count
end

I had a gotcha here — I realized that I has to have the pdf array separate from the program array (since in the form it’s field_for pdf). I fixed it by submitting two objects, program and pdf, to the controller, seen above.

Finally, running the functional testing leaves files on the file system and they should be deleted at the end of all tests. So I added a destroy method in the teardown, which removes them.

def teardown
  Pdf.find(:all).each { |p| p.destroy }
end

Failing Upload Tests
Just to check that only Pdfs can be uploaded for programs, I added a handful of other file types to my directory and created an array of invalid file types in my setup:

# [programs_controller_test.rb]
def setup
 # other stuff….
 @invalid_files = [['lipsum.doc',"application/doc"],['lipsum.rtf',"application/rtf"],
             ['lipsum.txt',"text/plain"],['squiggle.gif','image/gif' ],
             ['squiggle.jpg','image/jpg' ], ['squiggle.png','image/png' ],
             ['squiggle.psd',"image/x-photoshop"],['squiggle.zip', 'application/zip']
             ]
end

and created a test to check these uploads will fail:

  def test_create_with_invalid_file_types
    @invalid_files.each do |name, type|
      fdata = fixture_file_upload('/files/' + name, type)
      post :create,   :multipart => true,
                      :pdf=>{"uploaded_data"=>fdata},
                      :program => {:name=>"Newerest Created Program",
                             :is_ongoing=>1,
                             :status=>"Edit",
                             :start_date=>Time.now.tomorrow,
                             :end_date=>''}
      assert_response 200
    end
  end

This gave me peace of mind that my files are being uploaded, only the right types are accepted, and all is good in the land of PDFs and Programs. And voila, we are done and on to the next task.

Link Outs

Here’s a listing of various online resources on the topics covered in this post. This should be enough for a good start. Happy Uploading!

• Attachment Fu itself
• Significant Bits fu tutorial:
• Almost Effortless’ Fu-tutorial
• Mike Clark’s tutorial
• Changing upload location tutorial
• Testing file uploads: A broad overview (not using fu)
• Jonathan Leighton (who created the fixture_file_upload patch)
• More functional testing of attachment-fu
• An overview of Single Table Inheritance

So let’s quickly kick the tires to see how this all works:

1. Install the Twitter4R v0.2.4 (or above) Ruby Gem: sudo gem install twitter4r
2. Create a new rails application: rails twitter4rails
3. After setting up your config/database.yml to your personal tastes and tweaking the Rails configuration settings in environment.rb, scroll to the bottom of environment.rb and add the following:
   

   gem(’twitter4r’, ‘>=0.2.4′)
   require(’twitter’) # loads core library
   require(’twitter/console’) # loads a helper method we will use
   require(’twitter/rails’) # added Rails extensions for Twitter4R

   module YourAppNamespace
   ENV["RAILS_ENV"] ||= “test” # assume test environment if no RAILS_ENV set.
   ClientContext = Twitter::Client.from_config(”#{RAILS_ROOT}/config/twitter.yml”, ENV["RAILS_ENV"])
   end

4. Now in your controllers you can access YourAppNamespace::ClientContext object as you need to or any other part of the Twitter4R API.

If you still want more, feel free to check out the following links:

• TweetApp: Twitter4R on Rails sample application (>=0.2.4)
• Twitter4R RDoc
• Twitter4R on Rails Screencast (low res. currently, higher res coming)

class Array
  def paginate(page=1, per_page=15)
    pagination_array = WillPaginate::Collection.new(page, per_page, self.size)
    start_index = pagination_array.offset
    end_index = start_index + (per_page - 1)
    array_to_concat = self[start_index..end_index]
    array_to_concat.nil? ? [] : pagination_array.concat(array_to_concat)
  end
end

Before folks say anything about the above code.. yes I know it could be more concise if I didn’t use all the local variables but I wanted it to be really clear what I was doing here so.. leave it alone.

Now basically you can say

myarray.paginate(params[:page], per_page)

If you want to see it work yourself feel free to run this spec.

require File.dirname(__FILE__) + ‘/../spec_helper’

describe ‘Given we call paginate on an array’ do
  it ’should return an array containing the first 3 elements of the org array when page = 1 and per_page_count = 3′ do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 3
    expected_array = ["a", "b", "c"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an array containing the last 2 elements of the org array when page = 2 and per_page_count = 3′ do
    array = ["a","b","c","d","e"]
    current_page = 2
    show_per_page = 3
    expected_array = ["d", "e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an array containing all the elements of the org array when page = 1 and per_page_count = 5′ do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 5
    expected_array = ["a","b","c","d","e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an array containing all the elements of the org array when page = 1 and per_page_count greater than org number of elements i.e = 6′ do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = 6
    expected_array = ["a","b","c","d","e"]
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an empty array if you ask for a page that does not exist’ do
    array = ["a","b","c","d","e"]
    current_page = 3
    show_per_page = 5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an empty array if you ask for a negative page number’ do
    array = ["a","b","c","d","e"]
    current_page = -1
    show_per_page = 5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end

  it ’should return an empty array if you ask for a negative per_page number’ do
    array = ["a","b","c","d","e"]
    current_page = 1
    show_per_page = -5
    expected_array = []
    (array.paginate(current_page, show_per_page)).should == expected_array
  end
end