Week One of Ruby on Rails: Step Backwards

gistfile1.md

I am taking a step back in my Ruby on Rails journey, as it seems that my initial goals may have been a bit too ambitious.

As I said in a previous post, this is not my first foray into web applications. I've been working with Python and its associated frameworks for some time. When I was asked by a friend to work with Ruby, I thought that there would be a fair amount of similarities between Rails and Django given the structural similarities between Ruby and Python. I could not have been more wrong.

The Ruby and Python communities have taken their languages in completely different directions, and that's just fine. Ruby has no Benevolent Dictator for Life like Guido van Rossum, and 37signals has rejected any implications that their organization can be the sole deciders for Rails. That leaves a community free to evolve however it chooses to do so. There are pros and cons to this. Ruby (and consequently, Rails) has the ability to change and grow into its users' needs far more quickly than Python. That comes with its own set of growing pains, which I encountered in my first efforts in building a demo application.

Ruby makes heavy use of gems, which appear to be like more complex Python libraries. I say "more complex" because they appear to bolt onto each other far more heavily than Python libraries. If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important. I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04 as its creator had placed some dependencies on OS X. I went debugging and fiddled with the gem to redirect it to its new home in Ubuntu, only to find that my debugging had caused problems with Rails. At this point, I decided that I should probably get a firmer understanding of the core of Rails before I started messing with gems.

So, ye Rubyists, who were so helpful last time with my RSpec gaffes - how do you manage dependencies like this? Are these gem heartburns a common problem in Ruby/Rails or is this mostly due to my ineptitude with the language?

I'm assuming you are using bundler which manages dependencies about as well as you could expect a tool to? Otherwise, it is important to be wary of the gems you use; take a look at the dependencies and how it's implemented before, as Rich Hickey once said, "Gem install hairball" :) That said, I find the open source community behind ruby to be amazing, there are many more gems available, particularly for all aspects of web development, than I found in python (spent two years building a web app in python). I'd rather have a few gems as options to consider than none at all. Once example is for asset management - I ended up needing to roll my own system in python, and in ruby found good choices available in jammit and sprockets.

Were talking about something(Rails) that does print all outputs in color, however doesn't have any "-no-colo" option like the ls command. This single thing shows the minds behind Rails. Not for me.

I had the same experience moving from Django to Rails about 3 years ago. We had an application with a messy set of dependencies and it took me over 3 weeks to figure out how to setup the application on Ubuntu. A coworker bought a new iMac and I watched him set up the site in under 2 hours. I'm not going to lie, you will spend significantly more time troubleshooting on Ubuntu than OSX simply because a lot of tools for Rails are built with OSX in mind first. I don't want to argue whether that's good or bad, it's just the experience I've had.

That said, take a look at your dependencies. Are there alternatives? I don't think this is a problem with the framework, the language, or even the dependencies you are using. It's a problem of whether those dependencies are causing trouble with what you're trying to accomplish. I wouldn't immediately that the dependencies that are currently there are the best ones for the job. Do some research for alternatives that are potentially better suited.

The other thing to ask is if this application is already deployed to a server, are you developing in the same environment? If it hasn't been deployed, this is a sign of problems to come when you do deploy it to a Linux box.

Yes, some gems have dependences that have very specific requirements but if it's going to do anything important, it's going to work on Ubuntu because the developer knows that at some point, this has to get deployed and 9/10 it'll be on Ubuntu or some flavor of linux. If you hit a snag like this, your two options are to either fix it or find something else. I develop on OSX and deploy to Ubuntu and I hit the compatibility problem very rarely. With that said, I could see how you might find more problems with gems that help with development and are not meant to be used in production.

hey,

there are some gems that only work on a Linux or Windows or OSX.
Ruby i based on C so you can hack it into ruby.

so if you use a GEM pls first read if it fits for you!

This is no problem of rails/ruby or the OS just a lazy developer that not commented that a specific gem dosent work on a other OS.

and a error message or something like that would be nice !

As @krosaen pointed, are you using bundler? Also, are you using ruby version manager like https://github.com/sstephenson/rbenv or https://github.com/wayneeseguin/rvm. I highly recommend using either one of them. I personally use rbenv only because its simple (and easy to understand, if you want to know how it works). And lastly, make sure you are using the latest version of Ruby (1.9.3).

Also, this tutorial http://ruby.railstutorial.org/ruby-on-rails-tutorial-book really helped me get going with Rails. And do check out http://railscasts.com. It has lots of videos explaining various gems, rails internals etc.

as @sujithrs says, use rbenv or rvm (they are like virtualenv in python) - 90% of your problems are caused by using the system ruby and using gems from ubuntu repositories.

I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04 as its creator had placed some dependencies on OS X.

Yeah, programmers are incredibly ignorant. Even the post docs in Haskell put absolute paths in the Perl shebang used to build Haskell. Surprise, surprise when Haskell fails to build on Haiku OS, where Perl isn't installed there.

Well, this was total linkbait. If the application template you were following was so outdated it didn't discuss Bundler, you need to find a new application template. Am I really supposed to believe that Python libraries never have C modules with OS-specific behaviour? Or that their interfaces never change to the point something like bundler isn't a must? I'd rather specify my exact versions than hope whatever is installed on the system happens to have the API version I want to use.

again, as @sujithrs and @r4vi said, always use rvm .. ruby, python have a lot of dependencies that some times requires c, c++ libs that I compiled for your system, so it is really easy to mess around when u install everything in a system context.
One think that I found out when I moved from python/django to ruby on rails was that for my python project I kind of had to create a virtual box in order to have system as close as production, but in my ruby on rails environment I dont need to do so, I run everything in my local MacOS and our prod environment(ubuntu) always worked just fine.

Interesting that you've run in to OS X specific dependencies in the Rails ecosystem. I don't know anyone who deploys Rails apps to OS X in production. Xen based VPS is so incredibly popular, that pretty much everyone deploys to some kind of Linux.

Bundler and RVM (specifically, it's gemset features) are my tools of choice for managing my Ruby environment in development. For web apps, my production environments are usually virtualized, so I don't need RVM there. I use ruby-build to compile Ruby from source on servers, rather than relying on the system packages, which are always out of date and often broken. You can get almost all of RVM's gemset functionality with Bundler, but I like the utility of commands like rvm gemset empty (this command will completely wipe out any gems in the current gemset) when I'm developing. It's handy for building from zero, and feeling confident about what gems are available in the current environment.

I used to be a rails developer about 4 years ago before switching jobs... This was before RVM, Bundler, etc... Back then, you just installed ruby, whatever gems, and then you were done. Now it seems like RVM is needed to "manage the ruby environment" and then Bundler is needed to manage sets of gems. What the heck? Whatever happened to just "Install ruby, Go". No wonder people are getting upset with it. It seems ridiculous

I'm not crazy of any language or toolchain that has a deep and version specific dependency try.