Heroku now has an API (accessible from the command line, a Ruby library, or REST calls), revision control on all apps with Git, and remote access to the Git repository.

The combination of these new features means that you can now work on your apps using the local tools you love – like TextMate, vi, or emacs – and still get the benefit of zero-configuration deployment to Heroku.

How does it work? Grab the Heroku gem with “gem install heroku”. A sample work session looks like this:

heroku clone myapp
cd myapp
ruby script/server
...edit locally...
git add .
git commit -m "local changes" 
git push

The final step will deploy the app to Heroku, including running the migrations on the database and restarting the server. Watch the screencast to see it in action, or just grab the gem and give it a try yourself. RDocs here.

Combine your local tools and the Heroku in-the-cloud development tools in any combination you like. Perhaps you want to work locally while at home, but use the web editor when traveling. Every commit to the repository is available from both.

Heroku now has a mailing list on Google Groups. Stop by and introduce yourself, but first read the welcome post.

Last night we noticed a flood of .jp email addresses appearing on the waiting list – several hundred over the course of just a few hours. Turns out someone posted a comprehensive and flattering review of Heroku in Japanese (translation). I just couldn’t resist using the opportunity to post this image:

Actually, it’s not just Japan: the international response to Heroku has astonished us. Denmark, New Zealand, France, Russia, Brazil – over half of our users are from outside the US. We chalk this up more to the universal appeal of Ruby and Rails than anything we’ve done, but either way it’s pretty cool.

By the way, we know news on the Heroku front has been a little quiet lately. That’s because we’ve got some big stuff brewing. Stay tuned – the best is still yet to come.

Backstory: A Fiery Debate

Writing a user model and the standard login authentication code seems like busywork to a lot of coders. In fact, many people expected a next-generation app framework such as Rails to handle this for you. After all, Django does. Initially the login engine for Rails seemed to fill this slot, but following a fair amount of controversy over best practices, the login engine was killed by its creator.

With our BDfL having forever cursed prebuilt login systems, the Rails community mostly stopped trying to make them. Yet, this puts us back at square one: developers are annoyed at the amount of boilerplate busywork that is necessary for almost every web app they write.

acts_as_authencated is the halfway solution that is now popular: it's a generator, not a drop-in component, so it spits out the boilerplate for you, and then you can modify it. And then of course there's the idea that logins shouldn't be maintained by individual sites at all, but stored someplace in the ownership of users. OpenID is the great hope here, but while we wait for this technology to mature (and gain acceptance with less technical audiences), maintaining user logins will continue to be a part of building web apps.

The debate over how to create login authentication will continue to smoulder for some time yet. But in the meantime, Heroku now offers a user login solution that will be handy for apps shared with a small number of people, and requires almost no code.

Heroku Users

Apps created on Heroku are already shared with some number of users, specified by their email addresses (this works the same as other types of collaborative editing apps, such as Google Docs). Since these users are already logging in to access the app, wouldn't it be handy if you could find out from the Heroku backend who was logged into your app?

We thought so too. Which why we've created the heroku_user helper object. It's a small feature, but a surprisingly convenient one. I've already found it quite useful in some of my own personal apps. Our company wiki, for example, uses this method. So how does it work?

Read more...

Yesterday, DHH said:

“I’d love for Rails to be easy as pie to run in a shared hosting environment, though. I’d love for Rails to be easy as pie to run in any environment. In that ‘more people could have fun learning Rails and deploying their first hobby application’ kind of way.”

We humbly suggest that Heroku is one possible solution to the latter part of statement. Our vision for the long term is much grander than just a learning/hobby tool; but our beta product, as it stands today, can already fill this need quite nicely.

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.

Rails 1.2 is now officially deprecated for Heroku apps. Starting January 3 (that’s tomorrow), new features we are developing will not be available on apps still configured to use Rails 1.2. Then, on January 21, we will automatically upgrade any remaining 1.2 apps.

We know it’s only been a month since Rails 2 came out, so we hope this doesn’t come across as overly harsh. By taking this approach we can spend less time backporting, which means more time for new features. Since Heroku is still in early beta we feel that this is reasonable. Rest assured that when the next major Rails release comes around, we’ll be committed to supporting 2.0 for a much longer time window.

In most cases, upgrading should be as easy as changing your `config/environment.rb` to contain 2.0.2 instead of 1.2.x, and adding a block that looks like this to your initializer:


config.action_controller.session = {
:session_key => '_my_app_session',
:secret => '241b740a2f480d9776e6ce0c36b51f9df46ecf1d25814cd03b4d14dbb6ba7cd92'
}


If you find that you have breakage after the upgrade, read this post by Steve Ross which covers potential areas of incompatibility in detail.

And if you’re still having difficulty with the upgrade, just send us an email with the name of your app and we’ll be happy to help.

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.

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.

Rails 2 is now the default for all newly created Heroku apps.

Existing apps will continue to run on 1.2 unless you edit config/environment.rb and change the version number manually. Importing an app will try to guess the Rails version from your environment.rb, but you should double-check after the import to make sure the version is set to what you wanted.

We’ll leave a 1.2 gem available for a while, but we’re going to take advantage of our beta status here and keep the time window on this relatively short – perhaps a month or two. (Don’t worry, by the time the next major Rails release goes around, we’ll have a plan for longer-term support of legacy versions in place.)

It’s quite painless to upgrade, especially if you don’t have any deprecation warnings in your logs. Here’s a list of the major features and changes, and here’s some notes to help you upgrade.

Sometimes, it’s the little things. A few niceties deployed recently:

• The code editor UI now has a liquid layout. If you’re a life hacking / GTD type like me, you’ll especially enjoy this in combination with Firefox’s fullscreen mode. (FF for OS X doesn’t have fullscreen, unfortunately; try this instead.)
• Download files from the context menu. You can use this in conjunction with upload to edit in your local editor, load an image into your photopaint program, etc.
• Speaking of images, if you click on an image, it will display it in the editor pane.
• There’s a link to update your account password on the My Apps page. (Shocked this wasn’t there before? We’re in beta, dammit, we’re allowed to slack off on stuff like this.)
• More bugfixes than you can shake a ticket-tracker at.

We’ve been working our tails off over the past few weeks to process all the feedback you guys have been sending (or that we’ve gleaned from the system logs). I think that this photo of the trashcan under Orion’s desk tells the story pretty well:

He bought that case of Rockstar at Costco last week, and consumed it all as part of our mad dash to squash bugs exposed by our sudden surge of users. Bad for Orion’s health, but good for Heroku’s backend stability. :)

One major area we’ve been dealing with in this past week is the issue of failed mongrel starts. That is, exceptions that occur while the Rails framework is booting, rather than on a page request. These sorts of exceptions often happen with imported apps, because certain types of plugins or gem dependencies may not work out of the box with Heroku yet, or you might just have some odd stuff in your environment.rb that isn’t compatible with the version of Rails we’re running.

Up until recently, this was producing an unhelpful HTTP 502 bad gateway page. Now, you’ll see the contents of your mongrel.log so that you can diagnose the issue.

If you were paying close attention, you might have noticed a “Restart” button that existed for a few days. We’ve removed that in favor of automatically restarting whenever you save a file that needs a restart (like routes.rb or environment.rb). So far this seems to work pretty well – but as always, let us know if you find a case where it doesn’t work as expected.

One of the many benefits of Rails is database independence. Migrations are particularly nice in this regard; and the easy-to-read / Rubyified display of your schema (via rake db:schema:dump) in schema.rb is icing on the cake.

But what about data? For import and export of the actual data, we’re stuck with mysqldump (or pg_dump, if you’re so inclined). Further, these dump formats are not terribly readable, contain lots of information you may or may not want to copy (like permissions, schema settings, views, triggers…you know, database features that Rails users are supposed to avoid).

Worst of all, ddata dumps are vendor specific, so you can’t move data between databases (e.g., SQLite, MySQL, PostgreSQL). Rails is database-independent, but you’re pretty much stuck with whatever you picked at the start of the project. That’s hardly agile.

Realizing this problem was going to affect us in a pretty direct way with the import/export features of Heroku, Orion and I threw together a plugin yesterday which we’ve given the (rather uninspired) name YamlDb. Once you’ve installed it:

script/plugin install http://opensource.heroku.com/svn/rails_plugins/yaml_db

...you’ll have the additional rake tasks db:data:dump and db:data:load, which access a file data.yml. This is a simple dump of your database’s tables, which along with schema.rb, describe everything you need to make a complete copy of your database. (db:dump and db:load are shortcuts to do both schema and data together.)

What’s awesome about this is that you can switch databases in the blink of an eye. Got a SQLite3 database that’s gotten too big for its britches? rake db:dump, create a MySQL database, update your config/database.yml, and rake db:load. Presto, your app is now running in MySQL. Want to give PostgreSQL a try? Same process. Run it for a week, and decided you miss mysqladmin too much? Reverse the process, bringing the data which was stored in Postgres during that week back into MySQL.

Caveats: it’s much slower than dumping and restoring with your database’s native tool, and probably will stop working altogether with a database that is larger than RAM. But for most apps it should work fine. In the future we will most likely write database-specific extensions to make dump/restore process happen in chunks, and thus be more scalable.

As for Heroku, it now uses yaml_db as its native import/export format. So when you export an app from Heroku, you’ll always see a db/data.yml with your current data. It also makes it easy to import data into your Heroku app, at the same time you’re importing the code, or later on. Just install yaml_db in your app locally and run db:dump. Include data.yml with the import (or run and upload it separately), and then run db:load at the rake console.

Unless you're a big company with lots of marketing dollars, rarely does a product launch start with a bang. It's a gradual process - first you show a few close friends and family members, then some coworkers from your previous job, then some friends of friends. The word starts to spread as you and your partners furiously hack away, trying to make the product stable enough to stand up to a pummeling from the general public. So there's no big kickoff; just a quiet emergence. And if your product offers something of real value, awareness in your target market will grow steadily and strongly over time.

So it is with Heroku. James, Orion, and I have spent the last several months developing what we think fills an important niche in the Rails world: a hosted development environment that is dead-simple to get started with. How many people have gotten excited about learning Rails, only to be stymied by the complexity of installing local development tools - before they even get the chance to write a "Hello, World" program? Or how often have you thrown together a small app for personal use, something that would be really useful to a few friends - but it's too much bother to deploy it onto a public-facing webserver? These are some of the problems that Heroku will be able to solve in the very near future. (We have grander plans for the long term, but we'll save that discussion for another day.)

This blog will serve as a changelog for our product. As we deploy new features and other changes we'll post here. Incidentally, this is as much to coordinate between ourselves as it is to communicate with our users.

If you don't have an account on Heroku yet (as of this writing, only a handful of people do), sign up on our waiting list. We hope to be able to start slowly sending out invitations within the next week or two.