Instead of hacking plugin code directly use the evil twin method.

Nesting resources more than 1 level deep can cause headaches.

Test methods must start with “test”, but making them start with “test_should” is even better.

If your tests are failing for what seems like no good reason, drop your test database and recreate it.

Hyper-sensitive about security? Stop putting your production password in your database.yml file. Instead generate the file during deployment.

What is it? I would call it an online RoR IDE with a hosting component. Once you sign up for an account, you are given the option to create a new project. As far as I can tell, there is no limit to the number of projects currently. From there, you can import an existing RoR project or start building one from scratch in Heroku’s IDE. Things like console access, testing, database migrations, logs, etc. are all there too. Logs are available via a tab in the IDE and you can always pull up the files in the IDE too. You are also given access to run any rake tasks and to open a Rails console to test your apps out in.The hosting component is automatically available to every project. A quick click from the IDE screen will take you to your hosted project which is stored at subdomain you select (project_name.heroku.com for example). It is hosted on Mongrel running in development mode which means any changes to the project are automatically reloaded.I admit, an online IDE sounds like a bad idea. We have much better tools on our own machines.

After using it, I would still say the same, however that doesn’t diminish the coolness of Heroku. The real value of Heroku is the hosting. With a couple of clicks your Rails app is hosted and publicly available. It is perfect for those little personal projects, one-off apps that will only exist for a short time, and quick demo sites.It also appears that Heroku is in beta and I can only expect they will be charging for this stuff eventually. My hope is I get grandfathered in for free as a beta tester.