Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

RSpec Bundle for TextMate

Posted by Mon, 12 Feb 2007 12:58:00 GMT

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

Posted by Mon, 12 Feb 2007 04:35:00 GMT

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

Posted by Tue, 16 Jan 2007 06:15:00 GMT

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.

acts_as_hasselhoff

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

Posted by Wed, 10 Jan 2007 16:08:00 GMT

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

Posted by Thu, 15 Sep 2005 05:27:00 GMT

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