So You Want To Be A Ruby Dev
kevingisi.com
kevingisi.com
I develop more for fun .. i develop in ruby 1.9 and test to see it works in 1.8.7 also. No big deal!
I use "gem" for installing gems. Not bundler. No need to confuse someone new with RVM and ask him to play with all versions of ruby till he finds the one that suits him.
Its like asking a Java developer to try out all versions of Java starting with the 1.0 version, or asking a python developer to try jython and IronPython in addition to the 2 or 3 current versions.
What about perl. Should a new developer try out perl 4 and perl 6 too first ?
It would be silly to throw all of these items at a new developer, and no teacher in their right mind would ever do that.
But if you're trying to pick up the language on your own...that's what you'll see.
> but do consider that if you're a new developer and you go
> a'Googling, you're going to encounter JRuby, and Rubinius, and
> Macruby.
1. Forcibly prevent people from developing new Ruby interpreters, Ruby frameworks, and alternatives to popular Ruby tools.
-- or --
2. Force Google to adopt a old-style Yahoo / DMoz approach to internet search so that a Google employee can sort/categorize all of these things manually for presentation to the user.
The crux of the article seems to be that too many choices can be overwhelming to a newbie, so we should restrict everyone's ability to choose so that inexperienced, new developers don't hurt themselves (or run screaming due to information overload / confusion).
Yes, the number of choices in Rails has proliferated, but a new user can easily ignore these choices. I don't think the situation is at all equivalent to the Java stack (which is the only other one I can comment on).
To use Java, you probably want to use Maven, Spring for dependency injection, an MVC framework (Struts 2, Spring, Tapestry, etc...), an ORM framework (probably Hibernate, probably with JPA?), though there are other choices.
This blog lists a bunch or Rails/Ruby choices. However, it's important to keep in mind that essentially all of the things a newbie needs to get started with Rails are in a single, self contained framework that is (in my opinion) incredibly easy to use.
I had well over five years of Java experience when I took on the latest in Java-based web framework. A book on Struts 2 covered Spring, but not Maven. A book on Maven covered MVC, but used Spring's MVC. A book on Spring MVC used Ant for the build, not Maven. Ultimately, I had to spend a great deal of time researching these technologies to just get my first simple app up and running. You should spend some time getting to know your framework and not just rely on magic. But should you have to do this for weeks or even months before you can write a simple webapp?
For rails... well, there's absolutely no need to worry about JRuby, IronRuby, or Ruby Enterprise, and whatever tutorial you're doing on Rails will tell you what version of Ruby you need. You don't need to download any of that windows crap mentioned here. You can ignore Sinatra for the time being. Gems are utterly simple to use (try adding a Maven dependency some time, especially one that doesn't have a public repo). You don't have to download any database to get started with rails, but you will have to spend a lot of time figuring out how to configure applicationContext.xml in Spring (or however you decided to go about it).
In fact, I think you can be a successful web apps developer with Rails and never bother with anything other than the basic defaults (ok, you'll want to use a different database).
Ok, I realize I've been ranting. But there's a huge difference between a proliferation of choices that can be ignored, and a proliferation of choices that have to be understood and dealt with before you can write your first app.
I answer questions from people new to Ruby a lot (given that I wrote one of the few and the earliest introductory books for Ruby that's free) and they are VERY often the exact questions he mentions here. Maybe people are too lazy to find the answers. Maybe they're utterly immobilized by a new tech stack that has a lot of choices. Maybe they just aren't as smart as you are. Whatever it is, we really need to find a simple way to address these questions. I think a lot of them are already addresses through blog posts, and as you mentioned, through the tutorial you're following, but a lot of them aren't (and sometimes they're answered incorrectly due to the age of the content or simple ignorance on the author's part).
Let's not pretend these people don't exist just because you aren't one of them. Many people do have to deal with this stuff up front due to the nature of the work they plan to do with it, and if the information isn't accessible, they'll just move on to somewhere it is.
I assure you that I am one of them. I'm probably one of the people whose questions you helped answer on a discussion forum.
The part where I am, as you said, painting everyone's experience with my own is comparing Rails to a Java based web programming stack. Someone coming from PHP, for instance, might find it kind of difficult to use a framework that (essentially) can't be used without some knowledge of OOP, MVC, and so forth (as opposed to just putting some things up on a page). Sure, there's a learning curve.
But the "immobilization" you mentioned happens in degrees. Yes, it always takes some work to get up in running, because programming isn't easy. However, I don't think that the range of choices immobilizes a new programmer in Rails to anywhere near the degree that it does in the Java world.
So while I would agree that I have a particular angle that isn't necessarily shared by everyone struggling with rails, I don't think that my experiences are unusual for a programmer with experience in Java who has gone through the learning curve on web app development in Java and Rails.
Really? Java is worse in this regard! C# even worse since you have to use mono if you aren't on windows and mono isn't 100% up to date with C# from MS. Python is very similar to ruby on this front, lot's of choices. PHP is well PHP.
I still think ruby in the best in this regard. install 1.8.7, gem install rails, but the agile rails book, start coding. A lot of the stuff in this article is just noise that no one needs to think about. In fact, there is a giant 'getting started' link on the rails site which answers this question pretty well.
http://rubyonrails.org/download
I'd still like an example of where else some one would go to find a greener pasture.
Really this article was designed to point out that an overabundance of choice - even though they're great choices - can be harmful to new developers. And people should consider joining things like RailsMentors.org right now. Because more than ever, this is a time where one-on-one mentoring is all but necessary.
As far as greener pastures...I'd hate to see the day when any community measures itself by comparison to other communities, rather than on its own accomplishments.
most value judgements can only be made relative to other like things.
Back in 2005/2006, it was easier to install Rails. There were less choices which made configuration and setup easier (but which also meant you could do less).
Now Rails has matured and has a large community. There are more features, more Rails-related gems, and the architecture has more choices and moving parts. As a result, you can do more with Rails now, but the learning curve and setup costs are stiffer.
Back in 2005/2006, Rails had a reputation of being easy to set up and dive into. Even though that's no longer true in 2010, the reputation for being easy to pick up has stuck.
Here's a glimpse of how it was "back in the day": http://www.garbett.org/blog/?p=88
Almost entirely based on DHH's 15-minute scaffolding/TextMate blog demo. It was a brilliant marketing move that arguably put Rails on the map, but the problem was that it gave the impression that Rails was somehow "easy" like PHP and suitable for casual web tinkerers.
The fact that things are more complex now tells a truer story: if you want to do any serious work with Rails you need to be prepared to dive deep into Ruby. When a meta-programming bug strikes you can't hide behind even the most elegant DSL.
Want to try model airplanes ? Get ready to spend a couple of days just to figure out the various materials, radios etc
Want to try computer assisted music ? Which plugin ? Which host ? How do I write music with this, etc ?
You could even rewrite the article for Java a few years back at least (should I go WebLogic ? WebSphere ? TomCat ? Struts or something else ?).
I also choose to use Arch and not Debian on my computers. Such is life.
That said the article was a bit of a stretch both in the example it used, and in particular the fact that the Ruby world is currently undergoing a big shift. I would imagine one year from now a lot of those choices will be gone (e.g. Ruby 1.9.1 or even 1.8.x, Rails 2.x and maybe some of the less popular Ruby implementations).
But the general principle is correct: the Ruby community likes to try, change, play with new frameworks and ideas. If you hate the principle, then maybe Ruby is not for you. Or maybe in true Open source philosophy, you can make a simpler installer, or get someone else to do it. Then you'd have made the Ruby world a better place, and we'd all thank you for it. :)
Personally, I tried to spend time on what was stable (Ruby 1.8.7 and Sinatra). This allowed me to focus much more on the language yet still feel productive.
Once you get past getting started, the decision on what to use (or who to ask) become much clearer.
Work with the cutting edge _later_.
I want my first app to be:
puts "<h1>Hello world</h1>"
Any good tutorials or docs?
Really, you should just check out Sinatra. The whole 'framework' is like a thousand lines (or maybe two) of Ruby, and it's a pretty thin wrapper over Rack.
... any particular reason I'm at 0? Rack is the absolute minimum you're going to need to get Ruby to serve up dynamic pages, and Sinatra is an extremely minimal framework, to the point where it almost doesn't really deserve the term.
Then go dig into Ramaze. Strong helpful community around a durable, lightweight web framework that works as well for single-file web apps as it does for anything large and sophisticated.
There are many many ruby projects on the rubyforge site that have never released code. They still exist after years! and they come up in searches. There are those that are obsolete, broken, or with not one line of documentation that one has to download, go through source code to figure out what it does, and if it does anything at all.
When a person comes in to ruby he needs a starting page on ruby-lang.org that tells him the popular gems or frameworks for major uses: such as CLI programs, web dev, scientific computing etc. What some call a list of "blessed" gems/projects.
However, we cannot criticize ruby if everyone is writing his own framework, parser, templating engine etc. Its also hard to be critical that so much documentation and tutorials online are outdated/broken due to the constant rate of change. Either devs are not updating tutorials/articles, or google is bringing up older documents first.
When we see a high download count for a gem that still does not indicate that people are using it. It only means people have downloaded it to check out. DOwnload counts are deceiving. Gems that offer a very sketchy description and have NO webpage often get a high download count since that's the only hope of figuring out what it does.
You bring up some very good suggestions - we need a better metric for whether things are stable, supported, etc. And you're absolutely right, Google won't work, and download counts won't work. I would be interested in seeing something like you've suggested though, essentially coming up with a "trust" system for different libraries.
At the same time, you have the experience available to test whether a gem runs on 1.8 or 1.9, where a new developer doesn't know how to read stack traces yet. Providing one-on-one support helps tackle this issue (RailsMentors.org), as would increased tutorials that try and _limit_ the range of choice, rather than overload the developer with too much.
Of course, these are just my own thoughts on how we can address the problem. I'm hopeful that by discussing it, people can come up with some additional solutions.
I still love Ruby, but now I use it almost exclusively for sysadmin/build type stuff with Rake.
I admit it's pretty dicey with Windows, but between Linux/OS X things are usually pretty manageable.
But then you begin to peel the onion and you start to realize -- that onion looks kinda similar to this other onion I was using.
Don't get me wrong, RoR is good technology. The community oversells it, and the most outspoken are kind of jerks (for some reason the Java, Python, C#, C++, Haskell, Scala, Clojure communities don't seem to have the rudeness or jerkness).
And while I can say that Rails is fantastic, and in my opinion, the best framework out there, I'm also going to tell you: unless someone's willing to sit down and show you, don't listen to them. That said, there are many people who _aren't_ jerks, and are more than willing to help you reimplement Google Maps. A lot of them can be found at RailsMentors.org
As a born Rubyist (That is I started programming with Ruby) hopefully this article will get enough traction to make people start looking into having Ruby be as easy as it should be to start with.
Ruby is transitioning to 1.9. Rails is transitioning to version 3. These things are always painful. Some platforms try to rip off the band aid; others try to step slowly and carefully from one version to another. Then there are the platforms that just stop shipping new versions for a decade or so.
It's not unique to Ruby. The Drupal community is struggling to transition to Drupal 7, while legacy sites must negotiate the transition from Drupal 5 or Drupal 4.x, as well as the PHP 5.2/5.3 transition (or even a transition from PHP4), and the MySQL 5.0/5.1 transition -- or maybe the future of MySQL is MariaDB or Drizzle, or maybe we should pay more attention to good old Postgres, and then there's the team that insists that MongoDB is the future.
The web evolves. It is barely old enough to vote. It is unlike anything we have had before. If you don't like negotiating a blizzard of loosely-connected impermanent pieces you need to work on something else.
Or you need a better strategy. Many of the complaints in this rant are self-inflicted. Pick one text editor and stick with it. Pick one database and stick with it. Pick the Ruby version that DHH uses and stick with it. Don't agonize over every option. There are lots of ways to build a web page, and almost all of them work.
Perl's mistake was not releasing another Camel Book for a decade. The Perl 5.x language and libraries have done just fine.
The publisher's problem became the community's problem, which in turn became the language's problem.
The greatest opportunity for improvement is in the documentation arena, since blog posts are a huge part of the Rails documentation ecosystem, and because they tend to go stale and clog up Google with misinformation. Rails Guides are a really nice addition, but a meta-source that provided staleness information and list of preferred resources for various things would go a long way towards guiding newbies to a sane stating point (hmm, wheels turning in head).
I just spent way too much time getting passenger and rvm and rails 2 and 3 to (all) play nice together in a deployment environment, though, so I'm biased.
Just shut up and learn/do stuff. Learn/do the way you like it. This is how everything evolve!