Heroku Loves RSpec

RSpec 1.1 is now a part of the default plugin kit for Heroku apps.

We’ve been fans of RSpec for a while now, and feel that it represents the future of TDD/BDD for the Rails world. If you’re not familiar with RSpec, read up and then give it a try.

You don’t need to install anything to use RSpec in your Heroku app, but you do need to initialize the spec/ and stories/ directories by running the rspec generator. Just open the Generate dialog, type in rspec, and click Run.

Once you’ve written some specs, you can run them the usual way: open a rake console and type spec. You can still run your Test::Unit tests with the test command, or you can run tests followed by spec with default.

Don’t worry, support for Test::Unit won’t be going away any time soon – but we do encourage you to consider RSpec the next time you create a new model. Use the generate command rspec_model instead of the usual model to get a blank spec created for you. Or, use rspec_model <model_name> against an existing model and it will generate the spec (in spec/models) without overwriting the existing model or migration.

Heroku Loves RSpec

RSpec 1.1 is now a part of the default plugin kit for Heroku apps.

We’ve been fans of RSpec for a while now, and feel that it represents the future of TDD/BDD for the Rails world. If you’re not familiar with RSpec, read up and then give it a try.

You don’t need to install anything to use RSpec in your Heroku app, but you do need to initialize the spec/ and stories/ directories by running the rspec generator. Just open the Generate dialog, type in rspec, and click Run.

Once you’ve written some specs, you can run them the usual way: open a rake console and type spec. You can still run your Test::Unit tests with the test command, or you can run tests followed by spec with default.

Don’t worry, support for Test::Unit won’t be going away any time soon – but we do encourage you to consider RSpec the next time you create a new model. Use the generate command rspec_model instead of the usual model to get a blank spec created for you. Or, use rspec_model <model_name> against an existing model and it will generate the spec (in spec/models) without overwriting the existing model or migration.

View-Only Users

There are now two access levels for collaborators on Heroku apps:

  • Full edit access, which allows access to everything: editing code, importing or exporting the database, changing the settings, etc.
  • View-only access, which allows the user to view the app only. That is, they can visit the app url (myapp.heroku.com) but not any of the settings pages or the edit url (edit.myapp.heroku.com).

For example, a client who wants to use the app but neither needs nor wants access to the code could be set as a view-only user.

If your app sharing is set to public, the view-only access level has no use.

Do note that these settings have no effect on users changing your app’s data through the normal web front-end. For example, if you have a scaffold page that doesn’t perform any authentication, a view-only user can create, update, and delete records. When we say “full edit access” we’re referring to editing code. What happens when the user views your app is up to you.

View-Only Users

There are now two access levels for collaborators on Heroku apps:

  • Full edit access, which allows access to everything: editing code, importing or exporting the database, changing the settings, etc.
  • View-only access, which allows the user to view the app only. That is, they can visit the app url (myapp.heroku.com) but not any of the settings pages or the edit url (edit.myapp.heroku.com).

For example, a client who wants to use the app but neither needs nor wants access to the code could be set as a view-only user.

If your app sharing is set to public, the view-only access level has no use.

Do note that these settings have no effect on users changing your app’s data through the normal web front-end. For example, if you have a scaffold page that doesn’t perform any authentication, a view-only user can create, update, and delete records. When we say “full edit access” we’re referring to editing code. What happens when the user views your app is up to you.

Gems & Plugins Manager

Behold: the Heroku gems/plugins manager.

This has been one of our most requested features to date, and we’re glad to finally get this released. Although you could manually upload plugins previously, this will make the process a lot smoother. (You can still manually manipulate the files in your vendor directory if you prefer.)

To get to the manager, open your vendor directory in the lefthand filenav, and click the link that appears at the top:

You can search by name, or browse the list of 2500+ gems and 1000+ plugins. Once you find what you’re looking for, click on Install in the righthand column to install it into your app. Click Remove to remove it if it’s no longer needed.

You can also upload your own plugin as a tarball or a .gem file. Just click the Upload link at the bottom. Once it’s installed, you’ll see it listed alongside your other installed gems and plugins, and you can remove it in the same way. (Though you’ll need to upload it again if you decide you want it back.)

The data for plugins comes from the Agile Web Development plugin directory. Thanks to Ben Curtis, the site’s author and maintainer, for adding some extra fields to the XML API for us. The data for gems comes from the relative newcomer Gemtacular.

Note that gems with binary dependencies are unlikely to work. If you’re trying to install a gem and it doesn’t work, email us and we’ll see what we can do. Additionally, there are quite a lot of gems that don’t make any sense in the context of Heroku – for example, the 3rd party ActiveRecord database adapters, or GUI toolkits like the GTK bindings. In iteration 2 of this component we hope to flag gems and plugins as Heroku-friendly or not.

We made the design decision to mix gems and plugins together in the same view. This will probably cause at least a few folks to protest “But gems and plugins are nothing alike!” Make no mistake, we know the difference quite well. In building the interface, however, it occurred to us that the process of managing them was very similar. And from a high-level point of view, they are two forks of the same tree: add-ons to extend or modify the behavior of the programming environment of your app.

Browse the blog archives or subscribe to the full-text feed.