Articles tagged with Rails Community


Top 12 contributors to Ruby on Rails since 2004

Posted by Jordan on 05/26/2011 in Rails History and Rails Community.

We are Ruby on Rails enthusiasts. So we want to offer some love to the Ruby on Rails community, and give credit where credit is due. To the hard working folks who have brought this amazing programming framework to life, we salute you. We’re going to take a look at the top Ruby on Rails contributors since 1994. The list is sorted by the amount of commits they have contributed, not how well known they are. Without further adiu, here's our list:

Read more »

Heroku is Not for Beginners

Posted by Jim on 08/27/2012 in Rails Hosting Information, Rails Community, and Heroku.

Sure, like a drug dealer, they give you a little bit for free. But, how good is the stuff?

Heroku's main appeal is to take away the DevOps hassles and allow developers to "git push production" and not worry about what happens after the (insanely slow) deploy process. But, like most things in life, if it's too good to be true, then...yep, it's not true.

Heroku: The good, the bad, and the ugly

The Good:

  • See your app live on the Net for free.
  • Easily "heroku ps:scale web=10" to scale out your web tier or workers
  • Don't have to worry about log rotations, updating server software, creating your own deploy scripts, etc...
  • The Bad:

  • Once you get up and running a few dynos and workers, with a reasonable database, it's NOT cheap (i.e. you are spilling hundreds at this point).
  • Connectivity issues between dynos and third party services (e.g. Amazon S3) is too often unreliable.
  • Meet Virginia. Your web servers are forced into Amazon's Virginia datacenter, which is a serious problem if you need to target a specific area of the world to get faster speeds.
  • The Ugly:

  • TIMEOUT ERROR (And connection refused) HELL. Too many H12s and H18s for comfort. It's a nightmare for some apps.
  • CPU LIMITING. Heroku packs a gazllion of their dynos, presumably, onto large Amazon virtual server instances. When you are virtualizing an already-virtualized environment, you are going to run into CPU issues. We have seen requests that take 6 seconds only because they were allotted a total of 1 second of CPU time, over spurts, in that interval.
  • TOO MANY BLACK BOXES. You loose waaaaay to much customizability (and thus performance) when too many parts of your DevOps are behind the scenes.
  • Read more »