Heroku API Update

The Heroku API gets a major update today; you can now view and manage all of your application’s settings straight from the command line. New in this version:

  • Manage sharing (add/remove/list collaborators)
  • Manage multiple ssh keys for your user (add/remove/list keys)
  • Update settings (public true/false, mode production/development)
  • Rename an app
  • Run rake tasks remotely

A taste of the new command-line goodness:

adam@kvasir:~$ heroku create gagetron
Created http://gagetron.heroku.com/ | git@heroku.com:gagetron.git
adam@kvasir:~$ heroku info gagetron
=== gagetron
Web URL:        http://gagetron.heroku.com/
Git Repo:       git@heroku.com:gagetron.git
Mode:           development
Public:         false
Collaborators:  adam@example.com (edit)
adam@kvasir:~$ heroku sharing gagetron --add joe@example.com
joe@example.com added as a view-only collaborator on gagetron.
adam@kvasir:~$ heroku rake gagetron routes
(in /mnt/home/userapps/27934)
  /:controller/:action/:id         
  /:controller/:action/:id.:format 

There’s a new screencast which shows managing sharing from the command line. We’ve also updated the screencasts which show how to use the API and Git to edit locally, then deploy to Heroku.

Grab the new gem from Rubyforge with gem install heroku, read the docs, or browse the source.

API and External Git Access

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.

API and External Git Access

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.

Easy Authentication

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 →

Easy Authentication

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 →

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