Posted: August 25th, 2009 | Author: gabe | Filed under: Uncategorized | 1 Comment »
If you’re using Dropbox (affiliate link), and you should be, because it’s awesome, you might have noticed that Dropbox will only backup/sync files inside your drop box folder; you can’t tell Dropbox to also sync with other folders.
Now, if you’re on a Mac or Linux system, just add a symlink inside your dropbox folder that points to the other folder you’d like to sync.
On Windows, if you want Dropbox to sync folders outside of your “My Dropbox” folder, you’ll want to use the mklink command to create a directory junction pointing to the other folder you want synced. For example, if you want Dropbox to sync c:\source_code, open a command prompt, navigate to your dropbox directory (cd “My Dropbox”) and type:
(Assuming you’ve already navigated to your “My Dropbox” folder)
mklink /J source_code c:\source_code
Bam. That’s it. Dropbox is now following the link inside the “My Dropbox” directory and it’s syncing c:\source_code because it thinks it’s just another folder in the dropbox. Enjoy!
Posted: April 23rd, 2009 | Author: gabe | Filed under: Rails | Tags: active record, activerecord, caching, Rails, tips | 2 Comments »
ActiveRecord will cache the results of association method calls by default, unless you tell it not to.
(This applies to Rails 2.3.2 and perhaps earlier versions.)
From the documentation:
project.milestones # fetches milestones from the database
project.milestones.size # uses the milestone cache
project.milestones.empty? # uses the milestone cache
project.milestones(true).size # fetches milestones from the database
Normally, this is great. However, if you’re not aware of this default caching, you might see some strange behavior in your app or tests and have no idea what’s going on. This default caching behavior had me and Abel stumped until we read about it in the docs.
Working with the same concept as the example in the documentation, where a Project has many Milestones, here’s a more explicit example of the caching behavior in action:
project_1 = Project.find_by_id(1)
project_2 = Project.find_by_id(1)
# Load the same Project into two variables
project_1.milestones.length
# - Hits the db's Milestones table.
# - Caches milestones object on project_1.
# - Returns 0.
Milestone.create(:project_id => 1, :name => 'New Milestone')
# Adds a milestone to the project.
# But we don't do it through the project_1.milestones association
# because that _would_ update project_1.milestones's cached value
project_1.milestones.length
# Returns 0 (not 1, like you'd expect)
# because project_1.milestones was cached when
# previously requested above.
project_2.milestones.length
# Returns 1, because project_2.milestones
# hasn't been requested/cached yet.
# Note: project_2.milestones is
# a COMPLETELY DIFFERENT IN-MEMORY OBJECT
# than project_1.milestones.
# Taking this point further, here's an explicit example:
project_2.milestones << Milestone.create(:name => 'Another Milestone')
# Put another milestone on the project through
# project_2's milestones association.
project_1.milestones.length
# Still returns 0, because project_1 already cached it's copy of
# the milestones association back when there were 0.
project_2.milestones.length
# Now returns 2, because only project_2 knows about the new milestone.
project_1.milestones(true).length
# Returns 2, because ActiveRecord updates the cache
# when association(true) is present.
Another funny something to note about the association caching behavior is that even when ActiveRecord uses a cached value, it still emits SQL to the log file. So, don’t let that trip you up either.
Posted: March 1st, 2009 | Author: gabe | Filed under: Rails, Testing | Tags: assert_select, invalid selector | Comments Off
Problem: assert_select 'input[name=model_name[field_name]]' gives ArgumentError: Invalid selector: ]
Solution: assert_select 'input[name=?]', 'model_name[field_name]'
Thanks to the Boston Ruby Group thread for the answer.
Bonus: Here’s a helpful assert_select cheat sheet.
Posted: March 1st, 2009 | Author: gabe | Filed under: HTML, Rails | Tags: forms, invalidauthenticitytoken, tables | 3 Comments »
Recently, while pairing with Abel as we hacked on some code for his budget tracking app, we came across an interesting problem while trying to acomplish what seems like a pretty straightforward task.
Read the rest of this entry »
Posted: December 22nd, 2008 | Author: gabe | Filed under: Rails | Tags: named scope, Rails, search | No Comments »
When it comes writing elegant search code in a Rails app, Named Scopes immediately come to mind. And for good reason: they’re a fantastic way to express, well, scopes, for your searches. In your Person model, you might have named scopes like by_last_name, by_age, and by_sex. But, what do you do when you want to give your users a search form and let them find people by any combination of last name, age, and sex?
Read the rest of this entry »
Posted: December 13th, 2008 | Author: gabe | Filed under: iPhone | Tags: xcode codesign | 2 Comments »
Quick tip: if you’re just getting started with iPhone app development and trying to build and run an iPhone app project using the iPhone simulator in Xcode and you’re getting an error that looks like:
CodeSign error: Code Signing Identity ‘iPhone Developer’ does not match any code-signing certificate in your keychain. Once added to the keychain, touch a file or clean the project to continue.
The fix is pretty simple. In the Build Results window (which you probably got to by clicking the error icon in the lower right corner of your project window), change the pulldown menu from ‘Device – iPhone xxx’ to ‘Simulator – iPhone xxx’.

Posted: November 17th, 2008 | Author: gabe | Filed under: Rails | Tags: activerecord, mysql, sanitization, sql, sqlite | Comments Off
When you’re writing conditions for a finder in ActiveRecord, and you want to use an array of values for a sql in() statement, you might think to help ActiveRecord out and comma-separate the array values like this:
type_ids = [1, 2, 3]
Something.find(
:all,
:conditions => ['type_id in (?)', type_ids.join(',') ] )
Which will generate a sql fragment that looks like this:
[...] where events.status_id in (‘1,2,3′) [...]
Well, this will work just fine if you’re using MySQL, but not so fine (read ‘at all’) if you’re using SQLite. So, if you’re using MySQL for your development environment and SQLite for your test environment, like me, it will work fine in dev and fail in your tests.
So, instead, just let ActiveRecord’s sanitizers do their job and write:
Something.find(
:all,
:conditions => ['type_id in (?)', type_ids])
Your sanity will thank you.