RSpec Bundle for TextMate
Just a quick follow up to my post last night, Sharing Custom TextMate Bundles with Subversion. It appears that I missed the RSpec bundle for TextMate, which is listed on the RSpec webpage.
Install the RSpec Bundle
Installation is quite simple, just change directories to your TextMate bundle directory.
$ cd ~/Library/Application\ Support/TextMate/Bundles/
Check out the RSpec bundle from the subversion repository.
$ svn co svn://rubyforge.org/var/svn/rspec/trunk/RSpec.tmbundle
# lots of files...
A RSpec.tmbundle/Support/spec/fixtures/example_failing_spec.rb
A RSpec.tmbundle/Support/spec/fixtures/example_passing_spec.rb
A RSpec.tmbundle/Support/spec/spec_mate_spec.rb
Checked out revision 1489.
Now, just reload your bundles in TextMate and you’re good to go!
Bundles > Bundle Editor > Reload Bundles
I’d like to thank Aslak Hellesøy for pointing me to this and for also providing me with the correct subversion URL, which is currently outdated on the RSpec page until the next release.
Sharing Custom TextMate Bundles with Subversion
Early last year, I began to start creating a bunch of snippets and such for TextMate, all of which were lost several months ago due to Hurricane iSight. I recently decided to start building some again, especially some that sped up my RSpec writing. After creating a few, I wondered, “would anybody else on my team want to help me write some?” So, I thought that it was time to figure out how to share my bundle with others and allow them to add stuff to it… which seems like a good job for Ms. Subversion.
I couldn’t find a quick walk-through online and found myself in the #textmate
IRC channel getting proper instructions. (thank you Allan!)
Create Your Bundle
In TextMate, you can open up the Bundle Editor and create a new bundle. Let’s call our custom bundle, RSpec. Go ahead and begin adding some snippets, commands, etc to your new custom bundle. Once you have something in your Bundle, you’ll want to reload your bundles, by going to Bundles > Bundle Editor > Reload Bundles. This will write your new bundle to disk to ~/Library/Application\ Support/TextMate/Bundles/
.
$ ls -al ~/Library/Application\ Support/TextMate/Bundles/
total 0
drwxr-xr-x 5 robbyrus robbyrus 170 Feb 11 21:10 .
drwxr-xr-x 4 robbyrus robbyrus 136 Feb 11 20:11 ..
drwxr-xr-x 5 robbyrus robbyrus 170 Jan 12 16:58 PLANET ARGON.tmbundle
drwxr-xr-x 3 robbyrus robbyrus 102 Feb 11 21:10 RSpec.tmbundle
drwxr-xr-x 4 robbyrus robbyrus 136 Oct 21 13:38 Robby Russell???s Bundle.tmbundle
Importing your Bundle into Subversion
You’ll want to first import your new bundle into Subversion.
$ cd ~/Library/Application\ Support/TextMate/Bundles/
$ svn import RSpec.tmbundle/ -m "Initial import of RSpec (test) bundle" http://{respository_url}/{repository_name}/RSpec.tmbundle/
Adding RSpec.tmbundle/info.plist
Adding RSpec.tmbundle/Snippets
Adding RSpec.tmbundle/Snippets/new specification.tmSnippet
Great, now it’s in Subversion. Now, you’ll want to check it back out so that TextMate is running off of the version from Subversion.
The simplest way to do this is to delete your local copy and checkout the latest from Subversion.
$ rm -rf RSpec.tmbundle/; svn co http://{respository_url}/{repository_name}/RSpec.tmbundle/
A RSpec.tmbundle/Snippets
A RSpec.tmbundle/Snippets/new specification.tmSnippet
A RSpec.tmbundle/info.plist
Checked out revision 5.
All that you need to do now, is relaod your bundles again. Now that you know where the bundle files are stored, you can commit any changes as they are made.
Committing Bundle Changes
When you make changes to your TextMate bundle, you can do the following to commit your updates to the Subversion repository.
See Your Pending Changes
You can change directories to your custom bundle and run svn status
.
$ cd ~/Library/Application\ Support/TextMate/Bundles/RSpec.tmbundle/
$ svn status
? Snippets/new context.tmSnippet
You’ll see that the new snippet that I created needs to be added to Subversion.
$ svn add Snippets/new\ context.tmSnippet
A Snippets/new context.tmSnippet
Now, let’s commit it to the repository.
$ svn ci -m "Adding new context snippet"
Adding Snippets/new context.tmSnippet
Transmitting file data .
Committed revision 6.
At this point, all Subversion tips and tricks apply… so… it’s time to leave it to you to figure out the rest. :-)
TIP: Always reload your bundles before and after running svn update or svn commit
...and there you have it! You and your friends can (with a little work) share and develop your own custom bundles for TextMate. I’m hoping to get my teammates at PLANET ARGON to help me build a bunch for RSpec, which I’ll try to release into the wild soon. If anybody is already working on RSpec snippets and other TextMate hacks, please let me know.
UPDATE
Aslak kindly commented on this post and has pointed me to bundle available in the RSpec subversion repository, which I blogged about.) :-)
Happy hacking!
Every Second Counts with a Piston in your Trunk
Recently, I wrote about using RSpec and autotest (...which I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which I’m happy to hear about. :-)
It’s not the only thing that I’m happy about though.
I recently came across another gem. Several of my comrades in #caboose are using piston to manage external plugins for Ruby on Rails. Wait! Isn’t this what Subversion externals is meant for? Well, yes… but externals also eat away at productivity. For example, each day, we may have anywhere from 4-6 designers and developers working on one client project. When we’re in crunch mode, this could account for quite a few subversion commits throughout the day. We all know that we should run svn up
on a regular basis to make sure that we’re keeping things in sync… especially when designers and developers are working really closely and fine tuning something specific in the application. Well, the one downside to this process is that each svn up
not only checks our repository, but it also checks external repositories.
“But wait! Can’t you just ignore externals on an update?”
Of course, but who wants to type out --ignore-externals
each time they run an update? ...or perhaps you could make an alias for this in your shell. In any event, everyone on the team is then left to be responsible for doing this… and an extra 30-60 seconds (if not longer) per svn update times x number of people on project… well… time wasted if you’re closely watching the svn updates. Also, TextMate doesn’t have an option currently (that I could find) to ignore externals, so for those who manage subversion through it… they’re waiting on externals within their primary workspace.
Another issue with svn externals is that when a repository goes down, it really starts to slow stuff down your updates. This is always fun when you go to deploy your application with Capistrano and realize that you can’t finish the update because it can’t connect it to http://svn.lazyatom.com/public/plugins/acts_as_hasselhoff/
to make sure that your application has the latest version of the best plugins available for Rails.
Then there is the whole issue of wanting to make changes to the plugin that you’re including as an external. How does that fit into the whole mix?
There is Hope!
Piston encourages you to keep your external plugins in your local repository. Don’t worry, it remembers where it retrieved the code from so that you can update from the external repository at any time.
Installing Piston
Again, this is really simple like most gems.
$ sudo gem install -y piston
Password:
...
Successfully installed piston-1.2.1
Great, that’s all that you have to do to get started with Piston. Now, let’s get on with the show.
If you don’t have any existing Subversion externals, feel free to skip this section.
Converting existing externals
Okay, so let’s say that you’re working on a Ruby on Rails project and are relying on several external repsitories. For example, a project that I’m working on… currently looks like this.
$ svn proplist --verbose vendor/plugins/
Properties on 'vendor/plugins':
svn:externals :
authorization http://svn.writertopia.com/svn/plugins/authorization
svn_tools http://svn.planetargon.org/rails/plugins/svn_tools
simply_helpful http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful
exception_notification http://dev.rubyonrails.com/svn/rails/plugins/exception_notification
asset_field http://svn.planetargon.org/rails/plugins/asset_field
rspec_on_rails svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails
rspec_autotest http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
Piston is smart enough to know how to convert these Subversion externals into Piston-friendly plugins. This can be done by passing the piston
command the convert option
from within your Rails application directory.
Go ahead and run the following.
$ piston convert
Importing 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to vendor/rails (-r 5619)
Exported r5619 from 'http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-0_RC1' to 'vendor/rails'
Importing 'http://svn.writertopia.com/svn/plugins/authorization' to vendor/plugins/authorization (-r 83)
Exported r83 from 'http://svn.writertopia.com/svn/plugins/authorization' to 'vendor/plugins/authorization'
Importing 'http://svn.planetargon.org/rails/plugins/svn_tools' to vendor/plugins/svn_tools (-r 119)
Exported r119 from 'http://svn.planetargon.org/rails/plugins/svn_tools' to 'vendor/plugins/svn_tools'
Importing 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to vendor/plugins/simply_helpful (-r 5700)
Exported r5700 from 'http://dev.rubyonrails.com/svn/rails/plugins/simply_helpful' to 'vendor/plugins/simply_helpful'
Importing 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to vendor/plugins/exception_notification (-r 3900)
Exported r3900 from 'http://dev.rubyonrails.com/svn/rails/plugins/exception_notification' to 'vendor/plugins/exception_notification'
Importing 'http://svn.planetargon.org/rails/plugins/asset_field' to vendor/plugins/asset_field (-r 50)
Exported r50 from 'http://svn.planetargon.org/rails/plugins/asset_field' to 'vendor/plugins/asset_field'
Importing 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to vendor/plugins/rspec_on_rails (-r 1330)
Exported r1330 from 'svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5/rspec_on_rails/vendor/plugins/rspec_on_rails' to 'vendor/plugins/rspec_on_rails'
Importing 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to vendor/plugins/rspec_autotest (-r 48)
Exported r48 from 'http://svn.caldersphere.net/svn/main/plugins/rspec_autotest' to 'vendor/plugins/rspec_autotest'
Done converting existing svn:externals to Piston
All we have to do now is checkin our changes to subversion and we’re golden.
svn ci -m "updating repository to use piston instead of those lame-o externals..."
If you find this interesting and want to learn more, be sure to check out this post on Ruby Inside for a detailed introduction to Piston.
update
the following morning I saw this come across our development team channel…
< argonbot> svn.commit( project_name, { :author => 'brian.ford', :rev => 83, :log => 'converted svn:externals to piston for product, cus I can.' }
:-)
The Zen of Auto Rspec
Several months ago, I heard that people were using a program called autotest to have their tests continue to run as you made changes to your code base, which comes with ZenTest. It’s a really nice tool written by Ryan Davis and I hadn’t gotten a chance to play with it as of yet. Well, our team isn’t spending too much time in the test/
directory these days as we jumped ship near the end of last summer and found ourselves hanging out on the Isle of BDD. The locals are quite thoughtful about these sorts of things.
I just started working on a project that has been under development for several months and as I’m getting to learn the ins/outs of the system, I find myself having to rerun the specs, which can take quite a bit of time watching. Watching your specs or tests run sometimes is as productive as watching your code compile. Oddly enough, this is as close to compilation as we really get when working with Ruby on Rails… and it’s a productivity killer for me.
There Must Be a Better Way!
So, I did a quick google search and found an announcement for Rails that ran specs through ZenTest. This was exactly what I was searching for!
Some requirements
Please makes sure that you have the following gems installed in your development environment as they are dependencies to make this all work.
- zentest
- diff-lcs
$ sudo gem install zentest diff-lcs
note I’m going to assume that you have rspec and rspec for rails installed… if not… tsk. ;-)
Install RSpec autotest
$ script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
If you’re using subversion, you might consider installing it as an external.
$ script/plugin install -x http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
Running RSpec autotest
This is where it gets tricky. ;-)
$ rake spec:autotest
Now, you can keep a terminal window open and autotest will watch your application and detect when files change. When they change, it’ll attempt to rerun your specs (specifically those that changed). This helps save you the time of having to rerun all your specs throughout the development process and keep your spec:all sanity checks for when you’re about to commit code to your repository.
I’ll post another entry in the next few days to show you how you can use Growl with RSpec Autotest to keep you from having to look at your terminal all the time.
Until then… have fun!
the bizarre love triangle of rbot, subversion, and drb
In our pursuit to get stuff ready for the PDX.rb hackfest this weekend, Ben Bleything and I decided that it would be a cool idea to get rbot to monitor the groups subversion repositories.
We asked around a few IRC channels and people had different ways of handling this. The easy route looked to be to parse a RSS feed from Trac. (boring!)
So, in an effort to make it interesting and allow for a little creativity with rbot-and potentially open the doors to other ideas-we opted to build 2 pieces. One would be a post-commit
script that would run after a svn commit
and the other would be a new plugin in rbot, which started an instance of DRb.
The basic idea…
rbot starts drb on start
svn commit calls drb client, sends notifcation
Yes! I managed to sneak DRb somewhere else that it probably didn’t need to be. It was actually a good way to figure out how to properly tame the crazy lion that is DRb. It’s so sexy, but I am so afraid that it will scratch me if I get too close. It scratched a little tonight, but then the kind folks in #ruby-lang gave me a band-aid and I was on my way. Guess what? I tamed the lion!
The sad part is that I got the thing to properly work about 25 seconds after Ben logged off of IRC and here I am a few horus later amusing myself with test svn commits and telling the whole world. That’s right… he’s sleeping… and dreaming about how the lion is still out to attack him and you all know that the lion is nicely tucked away.
Thread.new {
# the lion is here
}
We couldn’t have the lion holding the rbot in a headlock the whole time.
So, the lion is nice and it is our new friend. We now have instant notifications of when our repositories get commits in #pdx.rb.
Once we get it to format everything nice and pretty (color-wise), we’ll make it available for all of you rbot and subversion folks.
Older posts: 1 2