watch this  

Since when does Gmail prohibit sending email with a .bat file attached? It won’t even send a Zip file that includes a .bat file.

Of course, executable shell scripts for other platforms can still be attached and sent. Apparently, even legitimate users require protection from the scourge of Windows batch files.

If you’re in Tulsa or the surrounding area and want to learn more about Ruby (or just meet other Tulsa Rubyists) please attend the Tulsa Ruby Workshop Saturday April 26th from 10am to 4pm.

Hope to see you there.

In the case where your application is deployed on the same server as your Subversion repository, it can be helpful to access the repository via the file system rather than over the network.

set :repository, "file:///path/to/repository" 

However your workstation (from which you’ll run Capistrano) will need to access the repository over the network. This is accomplished by setting that local_respository parameter. “local”, in this case, meaning your local workstation.

set :local_repository, "http://host/svn/repository" 

Thanks to an article on my host, Slicehost, for pointing this out.

It’s all about the Rewrite Condition.

Rails page caching is great and REST is great, but together they can be confusing. Considering a resource “Posts”, Rails gives you the following routes:

  GET    /posts     {:controller=>"posts", :action=>"index"}
 POST    /posts     {:controller=>"posts", :action=>"create"}
  PUT    /posts/:id {:controller=>"posts", :action=>"update"}

If you have Apache configured with mod_rewrite to serve your cached pages (instead of sending them to mongrel, e.g.), then all of those routes appear to be requests for “posts.html”. The end result is that you can’t create or update the “Posts” resource. The solution, let Apache handle the GET requests and mongrel handle everything else:

RewriteEngine On
RewriteRule ^/$ /index.html [QSA]

RewriteCond %{REQUEST_METHOD} ^GET$
RewriteRule ^([^.]+)$ $1.html [QSA]

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

Boot your Mac using the “Mac OS X Install Disc”, then select “Utilities > Terminal…” to get a command prompt. With an external drive attached, run the following command substituting the name of the disk you want to clone (source) and the name of the partition onto which you want to place the clone (target):

asr —source /Volumes/Macintosh\\ HD —target /Volumes/Clone —erase

This will do a fast, block-level bootable clone of your Mac. I use this all the time before doing any major upgrades or changes to the partition table.

After upgrading to Leopard and reading about how readline support was included for irb (among other things), I was frustrated to find that my vi bindings were not working. vi bindings worked fine for bash, but irb, python, mysql, etc. reverted to the default emacs bindings. Well, it turns out that Leopard actually uses libedit, a “non-GPL replacement for readline library”.

Apparently, libedit uses .editrc instead of .inputrc and has a different syntax. So, in order to get vi bindings in Leopard, create the file .editrc with the following contents: bind -v

When I first heard about Rails, I was using the Java Framework Tapestry for most of my projects. My first complaint about Rails was that one had to mix code, albeit concise, into the HTML view. Whereas, in Tapestry, you add an HTML identifier and the dynamic content is mixed-in during rendering.

In fact, I posted my thoughts on DHH’s blog and subsequently had a short conversation with the Rails creator on my site.

Well, it looks like someone has finally implemented Tapestry-style, HTML-only views for Rails: Lilu.

I’ve updated my Growl plugin for Firefox to remove the dependency on “growlnotify”. I submitted an update for the Official Mozilla page.

Download from mrchucho.net.

Thanks to reader “Alex P”, it looks like I’ll be able to remove the dependency on “growlnotify” from the Growl plugin for Firefox. Stay tuned!

So the problem I wrote about in Part One involved passing the organization_id of the current_user into just about every Model method. I quickly set off looking for the most complex solution: filters, overriding the base find_ methods, meta-programming, monkey-patching, you name it!

Well, too bad the answer was staring me right in the face: make the calls to each model relative to the current_user! There’s a reason :has_one, :has_many and :belongs_to exist!

So, instead of writing:

Attendance.find_by_organization_id_and_room(
    current_user.organization_id, room)

I should write:

current_user.organization.attendances.find_by_room(room)

Now, that doesn’t seem like a big difference, but it saves me from having either add a “by_organization_id_and” to every find method or adding some “with_organization_scope” code. It also feels more like Rails.

I have one concern, though. The call to “current_user.organization.” will result in a database call versus just passing “current_user.organization_id”. While this doesn’t seem like a big deal, it seems a little unnecessary. Since the current user’s organization won’t change—I should be able to cache it.

Update: /sigh. I shoulda known. This was covered on a recent Rails Way post.