We’ve turned our subversion server off

As we announced quite a while ago we moved all of our plugins to github. Since then, we’ve moved all of our client work (where we provide the source code repo) to github as well.

We had kept our subversion server online, with nothing being updated on it (all updates were in git), but earlier today we shut it down completely. If, for some reason, you were still using the subversion instance of one of our plugins, you’ll want to get it from git now (you would have been using an outdated one anyway).

You can see all of the plugins on the thoughtbot github page, but here are some of the most popular.

• Shoulda
• Paperclip
• factory_girl
• hoptoad_notifier
• Squirrel
• Jester
• suspenders

While we’re on the subject of git and github, I’d like to mention that paperclip is the 18th most watched project on github, while paperclip and shoulda are the 21st and 22nd most forked projects. Congrats to everyone involved in those projects, and thanks for making them successful.

Happy forking.

Paperclip Tips and Updates

So there’s been a bit of activity on the Paperclip front. I’ve added Amazon S3 support using the RightAWS gem. Some fellow githubbers have contributed some patches to fix up said S3 support, as well as to add more (and better) validations for content type, etc. We’ve brought it up to a nice, round v2.1.2 as of yesterday. Give yourselves a round of applause.

I highly encourage you to give it a whirl if you haven’t already. It’s very easy to both get and to use!

An interesting note!

Ken Robertson has gone to great lengths to port Paperclip to DataMapper, which should be great news for all you Merbers out there. He’s kept it quite up-to-date, and it’s right alongside the 2.1.2 current release. Hopefully we’ll be able to merge codebases in the future, though right now there’s enough of a difference between DM and AR to make that not terribly feasible.

Here’s a handy tip!

One of the most frequently asked questions is how to use data from your instances in the path and/or URL. The answer is the interpolations hash, which is quite user-extensible. Let’s say you had a song that played in the background of each User’s profile (making this exercise purely hypothetical, of course), and you wanted its name to be the same as the User’s username.

One really good way of allowing this functionality would be to add the following to your config/initializers/paperclip.rb file:

Paperclip::Attachment.interpolations[:username] = proc do |attachment, style|
  attachment.instance.login # or whatever you've named your User's login/username/etc. attribute
end

The #instance method is the instance of the model that this attachment is attached to. You can access any of the model’s attributes, methods, associations, and so on from that object just like normal. Also note that you don’t have to name your interpolation the same thing as the attribute you’re interpolating (though it helps clarity).

Now you can add this to your :path and :url parameters like so:

class User < ActiveRecord::Base
  has_attached_file :song,
                    :path => ":rails_root/public/system/:attachment/:username.:extension",
                    :url  => "/:attachment/:username.:extension"
end

When you call #url or #path on your attachment, Paperclip will run through the interpolations hash, find strings that match its keys, and replace them with the return values of the procs. In this case, you’d produce a lovely url of ”/songs/jyurek.mp3”

It’s a very easy way to add flexibility to your files’ names without having to modify any code yourself.

Another handy tip!

S3 support is now baked in! The updated has_attached_file call looks kinda like this one does:

class House < ActiveRecord::Base
  has_attached_file :blueprint,
                    :styles => { :thumbnail => "150x150" },
                    :path => ":attachment/:id/:style.:extension",
                    :storage => :s3,
                    :s3_credentials => "#{RAILS_ROOT}/config/s3.yml",
                    :bucket => "bucket-of-holding"
end

Please note the additional options, including:

• :storage: Specify :s3 here to use S3. Strictly speaking you could specify :filesystem here if you’re using the filesystem, but it’s the default so don’t bother.
• :s3_credentials: You should give this a Hash, a path to a file, or a File object. The File should contain a YAML-ized Hash, and the contents of the Hash should be the access_key_id and secret_access_key used to access your S3 account. You can also “environment-space” these inside the hash, just like your database.yml file.
• :bucket: The name of the S3 bucket that will be holding your data.

Note that there’s no :url option. That’s because the S3 URLs are generated from the bucket and the path name, so you don’t have to worry about them. You can also specify permissions for your files, in case you don’t want the default “public-read”, by using :s3_permissions.

You can find more about the S3 Storage options and the Filesystem Storage options at their RDocs.

Keep up to date!

Remember, there’s always the Paperclip Google Group and the Paperclip Lighthouse Account in case you have problems, questions, or feature requests.

Moving to Github

We’re moving our plugins, gems, and other open source projects to github. I know, it’s a shock. We’re going to keep the SVN versions of them going for a while, but the “official” repositories for each of these is now what’s hosted on github. So get busy with the hot forking action.

We’ve got:

• Jester
• Shoulda (and its gem)
• Paperclip
• Squirrel
• Quiet Backtrace
• MileMarker
• When
• What

By-and-large, we’ve resisted the move to git, despite the searing heat it’s been putting off in the Ruby community recently. We’re still a centralized development house, and so our internal development will still be SVN-based. It’s just how we roll. Though I imagine a few of the guys here will start picking up git-svn.

Hiding Visor

An excellent little plugin, Visor is. You can have a Quake-style console that pops up whenever you want, in any app. Only trouble is that I wanted to be able to close Terminal.app and still have the Visor accessible. I found these directions linked off the Visor wiki to get rid of Terminal.app from the process list, which is a set in the right direction, but not perfect. There were some quirks that made the experience… iffy.

Here’s how to get Visor as it’s own, invisible, app, and still keep Terminal.app around like it always has been:

1. Get SIMBL
2. Get Visor
3. Optionally, get TerminalColors, because the default blue in Terminal.app is horrible
4. Install each.
5. Make a copy of Terminal.app (I called mine VisorTerminal.app)
6. Right click on it and “Show Package Contents”
7. Open Contents/Info.plist with the Property List Editor
8. Change CFBundleIdentifier from “com.apple.Terminal” to “com.apple.VisorTerminal”
9. Add the key LSUIElement with a value of 0
10. Save
11. Find the Visor and TerminalColors plugins (they should be in /Library/Application Support/SIMBL/Plugins)
12. Open Visor’s Info.plist (Right-click > “Show Package Contents” > Contents > Info.plist)
13. Change the “SIMBLTargetApplications/0/BundleIdentifier” value to “com.apple.VisorTerminal” and Save
14. Open the Info.plist for TerminalColors (same as above)
15. Select “SIMBLTargetApplications” and click “New Child”, change the type to Dictionary
16. Add new children so that the keys and values mimic the existing one
17. Make sure that one BundleIdentifier is com.apple.Terminal and the other is com.apple.VisorTerminal, and Save
18. Get this app, unzip it and put it wherever you’d like (I have mine in /Applications/Utilities).
19. Open Script Editor
20. Open the VisorStarter app in the Script Editor
21. Change “Terminal” to “VisorTerminal”
22. Save
23. Add VisorStarter to your startup items

Ok! That takes care of that. It’s a bit more involved than the other instructions, but will completely separate Terminal and the Visor. Trouble is, they’re completely separate. You’ll have to set up the fonts and colors all over again, but it shouldn’t be that big a problem. If you have trouble getting the window settings to appear, open the Visor preferences from the Visor menu and the Window Settings should come right along. And the best part is that if everything worked correctly (you may need to log out and back in or reboot) the ANSI Colors option should still be in both Terminal’s and Visor’s settings.