Schneems

I’ve been quite lately, thats because we’ve been working on something amazing over at Heroku. So check out:

• Run JRuby on Heroku Right Now
• Move and Existing Rails app to use JRuby

I had a ton of fun working with JRuby, and Heroku made it super easy. If you’ve never thought of using JRuby in Production, maybe you can give it a whirrl.

If you’re in the Ruby world, you’ve likely heard about mruby, Matz’s latest experimental Ruby implementation. What I bet you didn’t know is that you can run mruby on Heroku right now. As a matter of fact you can run just anything on Heroku, as long as it can compile it into a binary on a Linux box.

If you’re new to mruby, or to compiling binaries take a look at my last article Try mruby Today. I cover getting mruby up and running on your local machine. If you are already up to speed then follow along as we use vulcan to package mruby as binary, wrap it up in a custom buildpack and then launch an app to use mruby on the Heroku cloud.

Continue Reading …

Yesterday

If you missed it yesterday we announced official support for Ruby 2.0.0 Preview1, and announced the dates for our developer conference, Waza 2013, including the Waza call for Speakers.

Software erosion is what happens to your app without your knowledge or consent: it was working at one point, and then doesn’t work anymore. When this happens you have to invest energy diagnosing and resolving the problem. Over a year ago Heroku’s CTO, Adam Wiggins, first wrote about erosion-resistance on Heroku. Part of erosion-resistance is communication, and knowing what to expect moving into the future. This post will clarify what we mean by erosion-resistance, and help you understand what to expect when one of our features is deprecated or is sunset.

This is a repost of the blog I wrote at Heroku http://blog.heroku.com/archives/2012/9/24/sunsetting-and-deprecation/

Erosion Resistance

Erosion-resistance means that your apps are protected against accidental or unannounced changes because there is an explicit contract between your app and the platform. Heroku insulates you from erosion by providing a transparent, managed service. We give you early visibility and full details on what’s happening with your app, and options for how to respond to any changes. In many cases we can take care of system changes for you automatically, but when we can’t, we tell you what your options are, how to proceed, and how much time you have.

To keep your application stable Heroku applies fixes and improvements, such as backwards-compatible updates released by maintainers, to the software on our platform. This protects applications on our platform without interrupting them. Occasionally security patches are introduced to operating systems and sometimes to programming languages. By using the Heroku platform, you can be confident that the underlying software you are using is safe and stable.

If a backwards-incompatible change needs to be applied to our platform we will always communicate the change ahead of time and provide sufficient information so that you can take the necessary steps to fix any incompatibilities. These changes are communicated through our deprecation and sunsetting process.

Deprecation Notices

When Heroku deprecates a product or service, we are actively suggesting that you no longer use that feature. Deprecations may be communicated through notices coming from the Heroku CLI, banners in our devcenter, or messages on our website. These notices may be accompanied by blog posts, changelog entries, official tweets, or direct emails when appropriate. Deprecation of a product will typically suggest using a more recent, stable, or feature rich product, so you can have the best experience using Heroku. These notices will not affect currently running apps. If, however, only a few applications are using a feature in production, Heroku may choose to sunset the feature.

Sunsetting a Product

As a product is sunset, it will be gradually phased out until it can be deactivated or removed from our system. We will only sunset products that have seen significantly decreased usage, and we will not deactivate heavily used features. Any product being sunset will have been deprecated for some time and will begin with an announcement similar to the deprecation but including additional information such as the date of the product’s deactivation.

If possible, we will migrate any affected users to a comparable product. A good example of this is the Cron add-on. Cron was deprecated in April of 2012, and after a majority of its users transitioned away from the product it was sunset. Any users left using Cron were automatically migrated to the superior Scheduler add-on.

If we sunset a product you are using, and we cannot automatically migrate, there are several things you can expect from Heroku. You will receive communication of the changes along with a plan moving forward. This will include a time-line with enough time to make any changes needed. Our goal is always to provide the best experience, to our developers, and to give the highest level of support possible.

Conclusion

At Heroku, we seek to be the most powerful platform to the largest number of users. By providing a strong contract with our platform, you can be confident using Heroku, and be prepared for when change happens. To stay up to date with our current erosion-resistance policies, you can always check our erosion-resistance documentation on the devcenter.

Starting today Heroku will allow you to specify a version of Ruby in your production app. As one of the most requested features we have been asked for time and time again, we’re happy to announce that it’s now live. To get started you’ll want to update your version of Bundler locally to version 1.2.0, or above.

This is a re-post of an Article I wrote for the Heroku Blog

$ gem install bundler --pre

Then you’ll want to specify the version of Ruby you want to use in your application inside of your Gemfile. For example if we wanted to use Ruby 1.9.3 in our production application you would want to include ruby '1.9.3' inside of your Gemfile. In a rails Gemfile it might look something like this:

source 'http://rubygems.org'

ruby '1.9.3'
gem  'rails', '3.2.3'

Once you’ve added ruby to your Gemfile, commit it to git

$ git add Gemfile
$ git commit -m 'use Ruby 1.9.3 on Heroku'

Then you’ll want to deploy your app

$ git push heroku master

Once your application is done deploying you will be able see the version of Ruby you are using is 1.9.3.

$ heroku run bash
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

It’s that simple!

With this new feature you can also use this process to call a specific version of Ruby other than 1.9.3, however, if it is not installed on the Heroku system you’ll receive an error.

Production and Development Parity

At Heroku, we strongly believe that there should always be a strong parity between development and production environments in order to minimize any surprises. When the tooling of your development environment most closely matches your production environment, there is far less room for error. Another good example of keeping parity between dev and production environments would be running PostgreSQL locally in the development environment instead of SQLite since you’re production system is running Postgres on Heroku.

While there are other reasons you may want to use different versions of Ruby in certain scenarios including performance issues or to access version-specific Ruby features, developers should overall strive to use the same tools and versions of software for development as are used for production.

Patch Versions

While you can now specify the version of Ruby you would like your web application to use, at this time we do not support that ability to request a specific patch version to be called, such as Ruby 1.9.2-p290. Ruby patches often include important bug and security fixes and are extremely compatible. While you can specify the version of Ruby you wish to use, Heroku will provide the most secure patch level of that version.

Debugging

If you’ve followed all the steps above and you’re still seeing a different version of Ruby than you need, please recheck your path.

$ heroku config
PATH     => vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin:bin
RACK_ENV => production
# ...

You need to ensure that bin is in front of your path so you could change the above to

$ heroku config:add PATH=bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin

As a tip, It is a good idea to use the free releases feature whenever you are modifying your ‘config’ in case you need to roll back to a previous version of Ruby.

Thanks

Thanks to Terence Lee Heroku Ruby team member and bundler maintainer for the additional support of ruby versions to the Heroku Ruby Buildpack and orchestrated the release of Bundler 1.2.0. Also thanks to Yehuda Katz and the entire Bundler team for helping get this release out the door.

Give this feature a try and let me know what you think @schneems!

Heroku just announced their support of hstore in their dedicated Postgres 9.1 instances. Hstore is a schema less key value store inside of PostgreSQL that allows us to store data like hashes directly inside of a column. It’s great for when you don’t know exactly what types of attributes you need to store on a model, or if you need to support many different attributes for the same model.

Update: You can now use Hstore with development databases on Heroku

A good example is storing attributes for a Product model. We might start out only selling books, which have an author, number of pages, but then transition over to selling laptops which have cpu speed and display resolution. Using Hstore allows us to easily store all these values without having to make a bunch mostly blank columns.

To get started with Rails and hstore you can watch the screencast below or visit the hstore example app running on Heroku.

More on Hstore

Hstore in Rails functions much like serializing hashes, except that we can query our data much faster since hstore is a native data type. It is supported natively in Rails 4, but until then we’ll need to use the activerecord-postgres-hstore gem.

Getting Started

You will need a version of PostgreSQL locally that supports the hstore extension. I recommend installing postgres using homebrew on OS X. Once you’ve done that you can enable hstore usage by running this in Postgres

CREATE EXTENSION hstore;

You can put this in a migration if you prefer

class SetupHstore < ActiveRecord::Migration
  def self.up
    execute "CREATE EXTENSION hstore"
  end

  def self.down
    execute "DROP EXTENSION hstore"
  end
end

Once that is done you will need to create a column with a type of hstore, here we are giving our Product model a column called data with hstore type.

class CreateProducts < ActiveRecord::Migration
  def change
    create_table :products do |t|
      t.string  :name
      t.hstore  :data
      t.timestamps
    end
  end
end

Once we’ve done that we can now store any type of attributes in the data column.

Product.create(:name => "Geek Love: A Novel", :data => {'author' => 'Katherine Dunn', 'pages' => 368, 'category' => 'fiction'})
Product.last.data['category']  # => 'fiction'

Querying

Not only does hstore allow us to store arbitrary keys and values it allows us to quickly query them.

  # Find all products that have a key of 'author' in data
  Product.where("data ? :key", :key => 'author')

  # Find all products that have a 'pages' and '368' key value pair in data
  Product.where("data @> (:key => :value)", :key => 'pages', :value => '368')

  # Find all products that don't have a key value pair 'pages' and '999' in data
  Product.where("not data @> (:key => :value)", :key => 'pages', :value => '999')

  # Find all products having key 'author' and value like 'ba' in data
  Product.where("data -> :key LIKE :value",     :key => 'author, :value => "%Kat%")

More information available in the Postgres hstore docs. Though like a normal column if you query it frequently, you can get even more speed by adding an index. You can do this using one of two indexes that also speed up full text searches. They’re GiST (Generalized Search Tree) or GIN (Generalized Inverted iNdex). Which sill speed up queries using the @> and ? postgres operators.

class Index < ActiveRecord::Migration
  def up
    execute "CREATE INDEX products_gin_data ON products USING GIN(data)"
  end

  def down
    execute "DROP INDEX products_gin_data"
  end
end

Use It

Try out the hstore example app, clone the Github repo, and let me know what cool things you build on twitter @schneems.

Thanks

Special thanks to Aaron Patterson and Joel Hoffman for their work with hstore & Rails4, to the team at Softa for writing this gem, & and the team at Heroku for their contributions to Postgres, and supporting this feature.

I thought I was spoiled when I worked for Gowalla, but Heroku appeals to my true inner Geek. The people, the building, and the oh-so-delicious food have blown my mind. It’s impossible to turn the corner without bumping into some of the best minds in the community. Where else are you going to find yourself walking to work with @hone02, a maintainer of Bundler, and playing pingpong after lunch with @bmizerany, the creator of Sinatra. The knowledge isn’t just Ruby, there’s all sorts of Java, Python, and even a little Erlang getting thrown around. You can tell everyone loves working on the Heroku platform by the way they talk about it, and the passion they have for their jobs. I haven’t run into Matz, the creator of Ruby, since he joined heroku, but I can’t wait to give him the super-secret Heroku staff handshake (it’s just a regular handshake).

While I’ve been working for Heroku for a week now, today was my first day working out of SF. The offices are great: fully stocked fridges, catered lunch, a games room, and Mac power adapters all over the place. It almost makes me wish I wasn’t working out of Austin (almost).

The building is old fashioned brick, with massive steel girders and origami all over the place. Seeing how intimate and friendly the lunches are it’s hard to remember just how many people work here. Getting to put faces to names has been great, and it’s one of the reasons I enjoy going out to events and attending conferences.

Before I flew out to the office, I got to attend my first event as a Heroku employee. On Saturday I helped out with APIHackDay Austin. It was a great reminder of why I started programming and took this job in the first place. Seeing a small team or lone developer toiling on some crazy app is really a thing of beauty. I can’t wait to help out with more events.

We have a ton of great things coming out of Heroku in the future that I can’t wait to talk about. If you catch me at a user group or conference, say “hi” and you might just get a sneak preview. If not, I’m at least good for a cup of coffee or a cold pint.

^_^