Background

I write code on 2 different machines: my (aging) MacBook Pro and a 24″ iMac.  Looking back, I should have replaced the MacBook and added a 24″ monitor instead of buying the iMac, but that’s hindsight…

Anyway, I was actually keeping certain Ruby on Rails projects in git in folders in Dropbox.  Yes, I know this is slightly redundant when using a version control system, and I caught some flak for this from a colleague.  But the convenience was amazing. I often get up from my iMac mid-coding session and end up plopping down someplace else with the laptop and resuming.  It is so nice not to have to commit, push, and pull every time this happens.  In fact, sometimes I don’t even completely plan it; I’ll leave the house for an errand, and end up staying out and coding from a coffee shop.  Since I rarely leave home without my laptop (which I’m beginning to think is a character flaw) this works well for me.

Syncing a git repo through Dropbox

Up until now, I’ve had very few problems syncing a git repository through Dropbox.  The only real issue I ever encountered was that the file permissions would change on executable files. Newly created files with 755 permissions would sometimes turn to 644 when synced to the other machine.  Doing a fresh git checkout on just these files would restore the permissions and they would stay correct.  (I never bothered trying to solve this problem permanently).

Once, I actually ended up with a conflict in the git index, but it was easily resolved since Dropbox doesn’t blow away any files in this case (it just appends the name with “(conflicted copy)”.

Enter Autospec

The other day, I begin using autospec combined with spork (highly recommended by the way) in my testing.  Something about this process generates lots of log files (temporary or otherwise, I haven’t checked).  While this was going on, the Dropbox cache files on the other computer where silently growing HUGE.

By the time I realized it, the cache files for a 4 day period had grown in size from something normal to 26GB!!!

I surrender

I probably should take the time to figure out exactly what’s going on, maybe even give the Dropbox guys some pointers on how to replicate this situation.  I still might – I still love Dropbox and it has its place in my computing.

But for now, I’m going to take my git repos out my Dropbox.  I was feeling guilty about it anway – it felt like I was doing something dirty – so this was the straw that broke the camel’s back.

As for reclaiming the space?  Its safe to delete your Dropbox cache files.  Just shut down Dropbox, delete the cache files (individual folders or the while ~/.dropbox/cache folder) and then restart Dropbox.

My solution is to use an around filter on my controller and a custom class. This way, I can set how form validation errors are displayed on entire controllers or certain actions.

I created a new file called field_error_proc_changer.rb in my lib directory as follows:

class FieldErrorProcChanger
  def initialize(proc)
    @new_proc = proc
  end

  # This will run before the action. Returning false
  # aborts the action.
  def before(controller)
    @old_proc = ActionView::Base.field_error_proc
    ActionView::Base.field_error_proc = @new_proc
    true
  end

  # This will run after the action if and only if
  # before returned true.
  def after(controller)
    ActionView::Base.field_error_proc = @old_proc
  end
end

Now, you can replace the existing field_error_proc using a normal around_filter

class RandomController < ApplicationController

  around_filter FieldErrorProcChanger.new(
    Proc.new {|html_tag, instance| "#{html_tag}"}
  )

  def index
    foo = bar
  end
end

Or on only certain actions like

  around_filter FieldErrorProcChanger.new(
    Proc.new {|html_tag, instance| "#{html_tag}"}
  ),  nly => [:index]

The value for field_error_proc I’m showing actually doesn’t add anything to the field with validation errors (I’m using a custom form builder that adds special classes to fields with errors, so I don’t need any html added). But, you could add a fancier proc too:

around_filter FieldErrorProcChanger.new(
  Proc.new  do |html_tag, instance|
    html = “”
    html << %{<div class="ridiculous_construct">}
    html << %{<span>There&#8217;s an error over here!</span>}
    html << %{#{html_tag}</div>}
  end
)

Why would you want to do this? In my case, I’m adding an extension to the Radiant CMS. My extension has an administrative interface, and my forms aren’t exactly like the default Radiant forms. Radiant sets its own field_error_proc, which I don’t want in my controllers, but I don’t want to change the way the native Radiant admin works or looks.

Net::SMTPAuthenticationError (535 Incorrect authentication data)

The Rails app needs to be restarted to pick up the configuration settings. This was on a Locomotive environment with Rails 1.2.3.