[tseabrooks]

I'm in the middle of picking up Ruby primarily because there was a GitHub project I wanted to fork and modify for my purposes that happened to be written in Ruby.The biggest problem I found is that the Ruby (or maybe the Rails?) community by and large provides shit instructions on how to get something running. I checked out a handful of projects and they all said things like, "Just deploy the normal what you deploy a rails app" and the like. Likewise, googling had almost universally bad / outdated information. Eventually I ended up with Passenger who had awesome instructions.

I finally pushed through but I suspect just getting things running is a big enough PITA to deter new people from participating in Ruby land. Even if Hannson says it's a myth.

[bradleyland]

I think the genesis if this problem is due mostly to the fact that programmers from a PHP background are used to not thinking about their server stack. That is changing though.

In languages like PHP, it's possible (again, this is becoming less common) to run an ad-hoc PHP application by simply requesting the URL to the file. For example:

* Drop myapp.php in to your httpd doc root

* Request http://myserver.tld/myapp.php

* Great success!

Rails doesn't work this way at all, and I don't know of an equivalent in the Ruby ecosystem. There is ERB, but no one runs a bare server that just maps myapp.rb to a URL; e.g., http://myserver.tld/myapp.rb. There's always some sort of router in between. Sinatra is probably the most basic Ruby app framework in common use and it still has a router. There are good reasons for this. In Ruby, everything is an object, so if you're writing good Ruby code, you need a way to map URLs to your objects.

Rails is somewhere between Java and mod_php in terms of application infrastructure complexity. The most important distinction is that you have an app server that is separate from your web server, and you have to do, at least, some basic configuration (even with Passenger). Many PHP devs never put any thought in to their server stack. PHP is part of their base Apache install on whatever shared host they're using, and everything "just works".

I'm trying really hard not to paint PHP devs in a bad light. All of this arrises from the circumstances you "grow up" in. There are plenty of PHP stacks that distinguish app worker processes from the web server, so please understand I'm not claiming some kind of superiority. To the contrary, the Ruby community recognizes the complexity penalty taken here, and is making efforts to develop easier ways to jump in to Ruby on Rails development.

This seems like a good topic for a blog post. I might write something up.

[tseabrooks]

Alternatively, I have almost no web experience and come from an embedded consumer electronics background. Similar problem... :)

[anuraj]

Are you saying Java deployment is complex? WAR files have been easiest to hot deploy for at least a decade - that too directly from your IDE with the click of a button. PHP deployment simplicity definitely beats everything - and Ruby will come last :(

[bradleyland]

No. I'm saying that the infrastructure that comes along with Java is more complicated than what many PHP devs are used to (mod_php under Apache).

It's almost like you're intentionally missing the point just so you can talk about Java infrastructure. I'm not here to throw rocks at Java. I'm a big fan of the TorqueBox project, which brings a lot of the power and flexibility enjoyed by Java devs to Ruby. "Complexity" isn't necessarily a bad word. More options means more complex, but sometimes you need those options.

[anuraj]

If you don't want too much infrastructure complexity in Java - go for Tomcat or Jetty - If you want advanced enterprise functionality go for JBOSS or another J2EE server. If you want asynchronous io, go for netty. Javaland is full of options that offer best performance.

[nascro]

Michael Hartl's Rails Tutorial addresses this right away. The first chapter is called From Zero to Deploy, where he demonstrates how to set up a Ruby/Rails programming environment and deploy rails apps to Github and Heroku.

[jboggan]

I cannot recommend this enough. Even this lowly darkside Perl hacker was able to make sense of it and use Hartl's example to construct a useful app.

[jswanson]

Link for Michael Hartl's Rails Tutorial: http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

Available for free online, though you can also pay for it if you'd like.

[rjsamson]

I've actually found the documentation for projects in the Ruby community, on the whole, to be quite excellent. That being said, I can sympathize with the confusion getting things deployed, if only because there are so many options. The best bet for a beginning, IMHO, is to give Heroku a try when getting your first app deployed - they have some really excellent documentation.

As a beginner, trying to deploying a rails app to production from scratch is likely to drive you a bit crazy.

[6ren]

I had difficulties getting heroku installed, even though I'm using ubuntu 10.04 LTS (as they are). It took many hours over several days, and several attempts.

One problem is that their deb package doesn't specify ruby as a dependency. Another problem is that you have to examine their inlined bash install script to get to the .deb package to diagnose that. Another problem was that ubuntu's standard package repositories didn't include the version of ruby they needed (ruby1.9.1 - though I just checked now, and it seems to be available again). So I installed rvm, suggested by www.ruby-lang.org as an easy route, which needed me to install a whole bunch of other stuff, and finally installed the latest version of ruby - but this was too recent for their package to accept. sigh Eventually I found an old, undocumented gem of theirs that would install their command-line tool (well, half of it anyway). Maybe it's seamless if you already have ruby installed - but it's a terrible way to start ruby, in my experience anyway. Possibly it's more streamlined on Windows/Mac.

Then... all three versions of ruby that I tried (1.8, 1.9.1, 1.9.3) had changes that broke my tiny toy code. So astonishing, I'm not even mad.

Look at Python, with 5-year support for Python 2 before breaking compatibility with Python 3. And Java, well, I've never heard of code being broken (assert could have, but never heard it happen).

Ruby is labour-intensive - that's the price of constant (incompatible) improvement. Part of that price is documentation that goes out of date, instructions that go out of date, code that goes out of date. It becomes unrealistic to invest in Ruby - unless you plan to be working intensively on it anyway. Which I think does make sense for its original professional users, who are constantly iterating anyway. But it's not good for people who missed the early wave, when ruby was friendly.

It's a shame, because there's a lot of cool ideas in ruby and cool projects using it. I guess that's the trade-off. But, well, it took so much effort to get heroku installed that I haven't used ruby since.

[jeltz]

> Then... all three versions of ruby that I tried (1.8, 1.9.1, 1.9.3) had changes that broke my tiny toy code. So astonishing, I'm not even mad.

I think you confuse your releases. Neither 1.8.7 nor 1.9.3 did break anything major. The only two releases with major breakage that should have affected you in recent years are 1.9.1 and 1.9.2.

The changes in ruby that break compatibility are listed in the release notes of every release.

> Look at Python, with 5-year support for Python 2 before breaking compatibility with Python 3. And Java, well, I've never heard of code being broken (assert could have, but never heard it happen).

Not sure what you mean about Python. Python has roughly the same policy as Ruby about API breaking changes.

The changes between Python 2.X and 3.X are also way larger than between Ruby 1.8.X and 1.9.X. Porting our code from 1.8 to 1.9 was not much work.

[6ren]

Does it make sense to you that if there is a breaking change between 1.9.1 and 1.9.2, then there is a breaking change between 1.9.1 and 1.9.3?

I'm just stating my (local) experience; I don't have a global god's-eye view of ruby. I'm not an expert in ruby; I'm just trying to get started. You seem to expect a beginner to know exactly which versions introduce a breaking change, and to read the release notes in detail - and understand them, which is difficult for someone who has not yet learnt ruby or its terminology.

When you start to have categories of breakage, as "major" or not, and defend porting code between versions as "not much work", it means you accept some breakage as normal. To me, a breaking change is one that causes code to stop working, and require extra labour. Python and Java don't do this (nor Windows, x86 or ARM).

Note that from 1.9.1 to 1.9.2 is not a major release. It's not even a point release. It's a point-point release with "major" breaking changes (according to you).

As I carefully said, this is a consequence of constant improvement (contrast with Java, c#, x86). (guessing: do you think it's partly due to the power of ruby making security harder?). The trade-off doesn't suit beginners. Note that back-compatibility is a "successful programming language problem" - no one complains if a toy language breaks. I'm just drawing attention to the downsides, because if uncorrected, in the long-term, it may lose the next generation of coders.

Look, I'm not out to attack Ruby; I like ruby. But this is a real problem. Disregarding it is a disservice to ruby.

[prask7]

If the project you are dealing with is a Rails project, please go through http://guides.rubyonrails.org/ , it gives simple instructions to get started

[Toshio]

One Rails project that provides pretty thorough installation instructions is this: https://github.com/dserban/censormenot