So here you go: I am for hire. If you are interested in working together, please do contact me regarding your project and timeline.

• Curriculum Vitae
• GitHub Profile

This is mostly on Git, which Heroku uses for source control and deploy triggers. This also assumes that the heroku gem is all installed and set up.

Separate Source Hosting

Starting off with the most common scenario: Your source is hosted somewhere else (GitHub, for example) and you deploy on Heroku.

If you have not done so yet, clone your application:

$ git clone git@github.com:me/myapp.git myapp

Besides making a copy of the code in the myapp directory, this also takes care of adding the repository as the default remote "origin". This means that, by default, doing:

$ git push

from the directory would already be equivalent to doing:

$ git push origin

which should push your changes up to the source host.

Next let us add the repository on Heroku as a different remote:

$ cd myapp
$ git remote add heroku git@heroku.com:myapp.git
$ git fetch heroku # Download objects and refs

At this point, you should be able to start deploying with:

$ git push heroku

and run heroku gem commands like such:

$ heroku console
$ heroku info

Multiple Environments

Elijah Miller wrote a great guide Deploying Multiple Environments on Heroku. If you are looking into setting up the multiple environments, head to that article instead. The rest of this section is for collaborating on already set up application environments.

So let us say we want to work with the following scenario:

The procedure is pretty much the same as above. First, you need to clone your source repository:

$ git clone git@github.com:me/myapp.git myapp

The next step is adding the Heroku repositories as remotes. You will have to come up with remote names better than “heroku” since you will be working with more than one Heroku application this time. The most obvious decent naming scheme is, of course, naming them after the environments:

$ cd myapp
$ git remote add production git://heroku.com/myapp.git
$ git remote add staging git://heroku.com/myapp-staging.git
$ git fetch production # Download objects and refs
$ git fetch staging # Download objects and refs

Since the source repository has been added as the “origin” remote, pushing changes for regular updates even pre-deploy would still be as simple as:

$ git push

Deploying is also straightforward:

$ git push production production-branch-name:master
$ git push staging staging-branch-name:master

Since there will be more than one Heroku repository in your Git configuration, the heroku gem will not be able to automatically determine the application you want to run application commands for. You will need to specify the application name like this:

$ heroku console --app myapp
$ heroku rake db:migrate --app myapp-staging

These four days are for:

1. Jogging,
2. Setting up Debian with development environment on the MacBook,
3. Some progress on work project #1,
4. Some progress on work project #2,
5. Prototype for toy web application (integrated with Facebook),
6. More park time,
7. Further planning for some things I realized still matter to me, and
8. Savoring a good cups of coffee.

Hello again, lovely world! Keep me excited.

I was looking into performance issues in one of our projects, and noticed some bit of association loading within a loop. I realized it is actually quite deceiving if we don’t remember some things.

Consider the following scenario:

persons = Person.find(:all)
persons.each do |person|
  books = persons.books
  # ... And then say a bunch of rendering goes here.
end

Whatever the reason, let us say there are on the average 50 books associated to each person, and we need a list of all books associated to each of 50 persons in a single go. That could grow a pretty large data set.

Sure, the books for each person record are assigned to a variable within the scope of the each block and would normally be garbage collected as soon as the loop ends an iteration, but we might be ignoring that these books have been stored for the :books association of each person record. Each person record then is still referenced in the persons array, so there will be no garbage collection happening there either.

In goes the reset() function. The reset() function on associations simply clears the association data @target and updates the boolean tracker @loaded to put things back how they are before association data is loaded.

persons = Person.find(:all)
persons.each do |person|
  persons.books
  # ... And then say a bunch of rendering goes here.
  person.books.reset
end

This did not help the particular area I was looking at as we are dealing with a harmlessly small collection there. Large index pages and sitemaps should employ memory-efficient tricks too, like combinations of pre-loading record IDs and paginated fetching, so this might not exactly be useful knowledge. It really is something to watch out for, though, and it could contribute much in memory optimization.

My second sister and I flew over to Maryland on the 13th so we could spend the holidays with the rest of the family. We are just about to end our fifth day here.

So far everything is good. We have been around Washington D.C. this weekend, have driven through Maryland a bit, and will be in New York City tomorrow til Friday (Hopefully, I can drop by MET this time.). The company is great, of course. A different range of shops, the Wii, HD on demand, and GPS also deserve so much more than a bit of mentioning. I’m especially looking forward to possible skiing and eat-all-you-can cheesecake feast.

Hmm, what else to say. I’m starting colds because of the cold and some lack of sleep, but I’m just about to pwn it. So forget about that.

I got some books earlier today. I wonder what else I’ll end up bringing home.