Migrating an existing App to Heroku Celadon Cedar Stack

It’s currently not possible to do an automated migration from or to the Heroku Celadon Cedar Stack which started in May. The only help that you get from Heroku is this:

Migrating From Bamboo to Cedar

Before migrating to Bamboo, you should make sure your app runs on Ruby 1.9.2. If your app is not already deployed successfully to bamboo-mri-1.9.2, you should do that first, and then come back and try Cedar.

Once you’re sure your app is fully compatible with Ruby 1.9.2, create an app on the Cedar stack and push to it. Currently, stack:migrate does not work for moving apps to Cedar.

Since there seem to be no blogposts of how to do all the stuff with an existing application I will try to cover everything that I did to do the migration manually in this article.

Cedar is different

If you are looking at the new stack you will notice that a lot has changed with Cedar. Most of the Heroku CLI has changed to reflect the new possibilites that come with the Cedar stack. Since Cedar introduces a new way of handling processes on Heroku, most of the commands are now streamlined with this:

# old
heroku console
heroku rake db:migrate
# new 
heroku run console
heroku run rake db:migrate

# have a look at running processes
heroku ps

# look at logs of different processes and tail the output
heroku logs --ps web -t

Preparing the Migration

I started by cloning my current app from Heroku into another directory and creating a new Cedar app on Heroku:

git clone git@heroku.com:hamburg-on-ruby.git legacy
cd legacy
heroku create --stack cedar

Adapting Cedar changes

The docs for creating a Rails 3 app on Cedar reflect some of the changes that have been introduced with Cedar.

One of those is that PostgreSQL is now recommended for local development and you need to have the pg-gem in your Gemfile. Otherwise you will get errors while running rake commands:

heroku run rake db:migrate

  Running rake db:migrate attached to terminal... up, run.1
  (in /app)
  rake aborted!
  no such file to load -- pg

Since I developed my app with SQLite3 and I don’t want to learn, install and manage ANOTHER Database I split up the database stuff for development, test and production:

# Gemfile
group :production do
  gem "pg"
end

group :development, :test do
  gem "sqlite3-ruby", :require => "sqlite3"
end

and exclude production dependencies from my local environment:

# put this into your .profile
alias bd="bundle --without=production"

It’s also recommended to serve Rails through thin webserver and manage the application with the Procfile manager foreman:

# Gemfile
gem "foreman"
gem "thin"
# Procfile
web: bundle exec rails server thin -p $PORT
foreman start

After going through those chages you should be able to see your application on localhost:

open http://localhost:5000

The migration process

If the application is running on your development machine you can start the core migration process by putting your legacy application into maintenance mode, so that no database changes will be made:

heroku maintenance:on
# stop worker, crons or whatever might be changing the db

Database Migration

After you completely halted everything on your dyno, you can start dumping the database to your development machine (I thought it would be neat to do a direct migration from the legacy database to the new Cedar database, but I did not get it working). You need to install the taps-gem in order to do any dumping. Taps will dump the database into your development database unless you provide an connection string to another database:

# use sqlite for dumping and do it into a separate file
heroku db:pull sqlite://dump.db

# mv the file to your Cedar application and push it
heroku db:push sqlite://dump.db

Config variables

If you have custom config variables in your application it’s pretty easy to move them into the new environment:

# list all config values of the legacy app in console format
heroku config -s

# replace the newlines with whitespaces and
# append all the configuration variables of 
# your new Cedar app at the end or remove the
# ones that you do not want to migrate!

# add the list of values to your Cedar app
heroku config:add KEY=VALUE KEY2=VALUE2 [...]

Installing addons

It’s also most likely that you want to use the same addons than in your legacy application:

# list your addons in the legacy app
heroku addons

# install all addons separately in the Cedar app
heroku addons:add apigee:basic
heroku addons:add cron:daily
[...]

Sendgrid

If you are using the Sendgrid Addon you should be aware that the automatic configuration is not working anymore the Cedar Stack! You need to configure it in your app:

  # config/environments/production.rb
  config.action_mailer.raise_delivery_errors = true
  config.action_mailer.smtp_settings = {
    :address        => "smtp.sendgrid.net",
    :port           => "25",
    :authentication => :plain,
    :user_name      => ENV['SENDGRID_USERNAME'],
    :password       => ENV['SENDGRID_PASSWORD'],
    :domain         => ENV['SENDGRID_DOMAIN']
  }

Switching domains

Before you do the last step, you should have a look if everything is up and running:

heroku open

If everything is fine, you can move all the domains from the legacy application to your new and shiny Cedar Stack application:

# list domains in legacy app
heroku domains

# and remove them
heroku domains:remove hamburg.onruby.de
heroku domains:remove onruby.de
[...]

# re-add them to Cedar application
heroku domains:add hamburg.onruby.de
heroku domains:add onruby.de
[...]

Looking at the result is quite disappointing, because nothing has changed for the user, but everything is new and shiny from the inside!

If you have any other pointers of what you need to do for migrating your application please feel free to add a comment!

Developing ANDROID sucks!

DISCLAIMER: you guessed it, this is a rant!

I am very interested in doing mobile development as a hobby. I started iOS development about a year ago but i stopped after publishing my first iPhone app dzone mobile because i thought that all those AppStore™ and iTunes Connect™ stuff was a pain in the ass and distracting me from beeing productive.

So I began developing this same app for the ANDROID platform, in order to get a feeling for it. I’ve been doing Java for about 7 years now, so developing on ANDROID should be rather familiar to me instead of learning all this verbose Objective-C nerdy pointer stuff. I am very well known to Eclipse, so working with the ANDROID Plugin should be easy, right?

I started the app in November of 2010, when I had some spare time between jobs, but somehow I stopped in the middle of the project and just recently started all over. I was wondering why I had not worked on the app for about half a year?

The answer is simple: Developing ANDROID sucks!

Eclipse

I stopped working with Java in the middle of last year, switching to Ruby development with TextMate and MacVim. Coming back to Eclipse is like getting hit by a truck! This IDE is so overwhelming, but instead of giving you what you need it hides the most common features, so that you have to search for it on stackoverflow.

Is it really necessary for me to do Open-Clean-Refresh-Close-Open-Refresh cycles on my project to let Eclipse realize that everything is fine besides Eclipse itself?

Why do people, building Eclipse plugins, make the same errors again and again? Swallow errors, so that you need to have the Error Log View open all the time? Show build failures without any hints? Are you serious about that LogCat stuff? WTF?

I am using the debugger all the time when I am new to some Framework in order to better understand what is going on. But this is not very usefull unless you can see the source code of where you currently are… Guess what, it’s reeeeally hard to get it going!

Emulator

The ANDROID Emulator is really slow on the Mac. I don’t know if it’s much faster on other systems, but i think it sucks. The startup time takes even more than eclipse, you need to fiddle around with runtime settings in order to adjust it to your needs and why is it so difficult to put all the options you have in the menu bar instead of hiding it somewhere in the function keys?

But the best thing is, that the emulator is just not working right in the beginning.

It does not properly respond to mouse gestures or the keyboard and ah yeah, I forgott, it’s ugly!

Desing-Flaws

Developing for iOS is a tough choice if one is coming from a language like Java that has a decent Runtime with garbage collection. I spent most of my development time with allocation/deallocation problems. This is something you really need to get into if you want to have fun working with Objective-C even though they just released ARC (automatic reference counting) on iOS 5. Besides that, I really think that iOS does a better job in designing an architecture that is developer friendly.

The thing that I just can’t get over on ANDROID devices is that the application (the activity to be precise) is going to be reloaded if you rotate your device and you need to take care of a lot of things in order to let your app respond to that interaction. Just have a look at your future self

It’s really sad to me, that the ANDROID designers decided to repeat the bad design decisions that had been established in Java Enterprise™ all over again! It took the Java community about a decade to step back and come to frameworks where developer productivity is THE thing to focus on. All the rookies that start their “Java career” with ANDROID will be doomed to go through this same process again! Poor bastards…

XML

Finally! Let’s define everything in XML! I am getting bored at bashing on XML…

$ find . -name "*.xml"
./AndroidManifest.xml
./res/layout/details.xml
./res/menu/options.xml
./res/values/strings.xml
./res/xml/preferences.xml

iOS is also using XML for their interfaces, but they hide all that shit behind a really decent InterfaceBuilder!

The Builder and XML Tools in the Eclipse Plugin are so ugly that i rather write the whole shit by hand, BITCHES!

Tight coupling

Why, for gods sake, did they come up with the idea to use inheritance for everything in ANDROID? It’s even worse than in J2EE because you are not bound to Interfaces but Classes! Hello dear ANDROID designers, there is no such thing as Mixins or Multi-Inheritance in Java?! How am I supposed to write clean code with that? Answer: You are not going to write clean code anyway, because you have to do premature optimization on your code so that it can run on all the shitty ANDROID devices! YEAH!

Just forget everything you learned form state of the art frameworks like MVC or DI. It’s just not possible! BY DESIGN!

Just put state, lifecycle, business and view logic in one class; also helps reducing your package size, HOORAY!

Checked Exceptions

Do we really need more Checked Exceptions? Really?

Testing

Writing tests for iOS was nearly impossible at the time I was doing it. Even the guys at the Cocoaheads Hamburg did not know how to get it running. But this situation has improved over the last months. Special thanks to XING for doing a lot of research there and presenting it on the Usergroup!

I thought that testing for ANDROID would be really cool, because the Java community has a really strong background on TDD and Testing is even a Topic on the Dev Guide, even though it is the LAST one…

Let me make it clear to you: Testing ANDROID sucks!

Because of all the tight coupling and multithreaded environment it is nearly impossible to test something. Even simple tasks like testing your Utility-Methods needs to be done in the Emulator! Just have a look at this multiscreen setup guide of how to get it running with JUnit (Hello?! JUnit 3 is deprecated for YEARS!).

Despite all this crap, I finally did it! So please test my dzone application, because I do not own an ANDROID phone myself…