New to Ruby? Tips for the new Rubyist.
jasimabasheer.comI'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.
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.
Alternatively, I have almost no web experience and come from an embedded consumer electronics background. Similar problem... :)
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 :(
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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
One Rails project that provides pretty thorough installation instructions is this: https://github.com/dserban/censormenot
I would like to get some advice from experienced Ruby hackers. Currently I am picking up Ruby through rails, which I am assuming is fairly common. I want to know the downsides to this and what people did to supplement their ruby knowledge beyond Rails. I eventually would like to write my own gems, contribute to open source, and so forth. I am absolutely not satisfied with just consuming Rails.
I'd highly recommend The Well Grounded Rubyist by David Black http://www.manning.com/black2/ if you want a good intro to Ruby, I found it a much better intro than the Pickaxe
I work with David and he is totally awesome. He's giving a talk at the NYC.rb meetup on June 12 called "The Well-Grounded Nuby" which is an intro tour to Ruby. Here's the meetup link. http://www.meetup.com/NYC-rb/events/57344932/
His previous book Ruby for Rails is just as good an introduction to Ruby.
In fact, "The Well Grounded Rubyist" is a "reworking" of "Ruby for Rails". The author mentions this relationship between the books in his "about this book" section at the beginning of "The Well Grounded Rubyist".
I found Ruby for Rails very helpful when I was getting started. It helped separate Rails "magic" from the underlying language aspects in a way that most other books did not.
I can't recommend The Well-Grounded Rubyist higher myself and totally agree regarding it's accessibility in comparison to the Pickaxe. This is the book that taught me programming.
The best advice I can give is get to know Ruby well - don't just focus on Rails in the beginning. Eloquent Ruby by Russ Olsen is a great read and will give you a deeper understanding if you've got the basics down. Also, the PragProg book Metaprogramming in Ruby is a great intro to metaprogramming.
I can't recommend Eloquent Ruby at all: http://news.ycombinator.com/item?id=3803016
Really? Eloquent Ruby is one of the best Ruby books I've read - Russ Olsen is one of the best and most well respected technical writers out there. Design Patterns in Ruby is also excellent.
Agreed, Eloquent Ruby is a smashing book and I recommend it to all of my own Ruby students. I don't use it as an official textbook but I might as well do. Superb book.
I had this discussion already (see the link). Maybe it's a matter of taste but I think this book has some severe weaknesses and thus, I wouldn't recommend it.
No offence but perhaps you bought the wrong book? Eloquent Ruby is about style and design patterns, it's almost about the philosophy of Ruby code, best practises, aesthetics and the author's experiences.
Books like that are fundamentally about taste and style and technique; they can't really be "wrong". You might disagree with the author and think you have a superior approach but to say that randomly googling the topic led you to a "better" explanation tells me that perhaps you were looking at the wrong book in the first place.
Again the same discussion. I did not buy the wrong book. I knew exactly what I wanted
Don't get me wrong, your reply is kind of abstract and philosophical. I explained why this book just failed and should not be recommended (mainly the style and really, really awkward, wacky examples) and I face abstract replies. Sometimes I think these comments and Amazon reviews are all faked by SEO/Webspam people driving the book's sale (no offence, but because of guys like you recommending a totally weak book over and over without the slightest criticism I bought this crappy book and it's a really bad and frustrating experience). And again: I am not dumb or do not know what I wanted or bought (btw this is bad discussion style to implicitly question the buyer intent or skills, it was very indirect but still there).
Good grief, did you just accuse us all of being spambots?
Never mind that everyone here has been an HN member longer than you, but that is a very poor perspective to take. A rational person would note that a number of fairly successful programmers in their field are endorsing a book they had a bad opinion of and, at the least, go back and re-examine the foundations of that opinion. It's called humility and learning from those around you. But not you, oh no, you are absolutely right and everyone else is absolutely wrong and if they don't admit it they must be paid shills!
> Again the same discussion
The reason for that is that what you say is totally unconvincing, when it makes sense, which is not often. It is quite obvious, for example, that you bought the wrong kind of book, despite your inexplicable denials. You needed some kind of reference book or cookbook or something. You come across like this: "I bought Jamie Oliver's autobiography and it SUCKED! I needed a recipe for pancakes and I could find thousands on Google in seconds so why do I need that book!? That book is a stupid waste of money and anyone who says otherwise is a spammer! I did not buy the wrong book. I knew exactly what I wanted. I am not dumb"
> I am not dumb
The fact you feel the need to point this out doesn't speak well to how you come across in these discussions, does it?
You need to think about your attitude. Maybe instead of replying with some new inanity you should close the window, go outside, sit in the park or something, and think about some of the assumptions you are making when you cheerfully and thoughtlessly dismiss the advice and opinions of anyone who happens to disagree with yourself, especially the kind of talent who likes to hang out here. You might have an unpleasant realisation or two coming your way.
"You needed some kind of reference book or cookbook or something. You come across like this: "I bought Jamie Oliver's autobiography and it SUCKED!"
Great analogy!
Don't know the author, have only moderate Ruby experience, and I loved the book.
Spend a week just learning Ruby before doing anything with Rails. There's a huge learning curve to Rails - learning the language simultaneously will just make you frustrated.
Probably the biggest downside is that you'll incorrectly assume that some parts of Rails are actually part of Ruby. Then you'll miss them when they're not there and possibly feel a small amount of sadness. Oh the humanity! :)
The big one is ActiveSupport. There are many extensions to common Ruby objects like String, Enumerable, Hash, etc. For example. In Rails, you'll use something like this quite frequently:
The parameterize method is part of ActiveSupport::Inflector. As you start to write Ruby outside of Rails, you'll come across occasions where you'd really like to use ActiveSupport methods like these, but fortunately, RubyGems and Bundler make that easy.some_string_var.parameterizeEDIT: My last paragraph isn't clear enough that you can use ActiveSupport outside of Rails by simply adding the gem to your Gemfile and requiring it in the relevant location. The downside is that you create a dependency. If you are writing ad hoc scripts, this can be an annoyance, but if you package all your scripts as a Gem using something like Thor, dependencies won't be a problem.
Thanks. I was expecting somebody to mention this. What I am currently doing is investigating most of the code I use, be it methods, classes, and so on. It takes me off of the main task, but I think based on what you experienced its a good thing. I have a folder for rails source code in my editor and I usually just hang out there. ;) Hopefully this will mitigate the problem.
Any gem can use ActiveSupport as a dependency, just like Rails does
Added a clarification edit. Thanks!
I'd recommend reading Eloquent Ruby by Russ Olsen. It's a great after-Rails intro to Ruby and uses a lot of specific examples from the framework to highlight how Ruby features make some of the magic happen in Rails.
I wonder if this can be read hand in hand with Ruby Best Practices. After all Matz wrote the preface to this one so I have to give it a go.
I came up the ranks like you, and actually abandoned Rails but stuck with Ruby for a while longer. I supplemented my Ruby skills the same way I do with most programming languages - I had an end-state in mind, and I coded towards it. In my case, this was a script and wrapper based around the MediaWiki API, but that doesn't matter. It just needs to be something doable. At that point, it's just a 10,000 hour play - code until you get it. I spend a lot of time with the docs open, but eventually that goes down, which is when you know you're getting it.
If you have a choice in framework, I'd actually recommend not learning Ruby through Rails. I'd learn it through Sinatra. Sinatra is a lightweight web framework (Rails is a heavyweight), and it has a lot less "magic", so it's more plain Ruby and less connecting framework components together.
Not knocking Rails, it's just that you'll get a really narrow and somewhat skewed perception of Ruby if you learn it through Rails (you'll have no way of easily separating the Rails magic from plain Ruby as you learn things).
I've put together a list of some of the better learning resources all in one place if anyone's interested: http://news.ycombinator.com/item?id=4070379
I've also heard good things about the PragProg Ruby course - its $199 but is supposed to be excellent, though I have no direct personal experience with the course.
Read everything from Gregory Brown.
I really enjoyed working through the Ruby Koans (http://rubykoans.com/). They're especially nice because you can work on them offline, so I finished them while on a flight to the U.K. I'm considering writing up some "advanced ruby koans," with more in depth examples delving deeper into the standard library and whatnot.
I think it's wrong to judge Zed's Learn Ruby the Hard Way too harshly as the OP does...yes, it's a straight port from the Python version, but both versions focus on teaching programming to non-programmers, which is a concept that can be largely language and idiom agnostic...at least between Python and Ruby.
His summary of the object hierarchy of Ruby is probably more confusing than elucidating to most Ruby beginners, since he doesn't make it very clear that he's dealing with the distinction between instances and classes (which are themselves instances of Class).
From the description it seems like he doesn't quite get the distinction himself, and one of the later examples is broken:
"Array.new.methods - Object.methods" should read "Array.new.methods - Object.new.methods". Otherwise he's in fact subtracting the methods available on an error instance from the methods available on an instance of Class, not the methods available on a generic object..
> "Array.new.methods - Object.methods" should read "Array.new.methods - Object.new.methods". Otherwise he's in fact subtracting the methods available on an error instance from the methods available on an instance of Class, not the methods available on a generic object..
You are wrong, classes are objects :)
1.9.3p194 :084 > Object.new.methods - Object.methods => []Actually, the author is inaccurate, comparing apples to oranges. Consider the opposite subtraction than you proposed:
That means doing "Array.new.methods - Object.methods" is subtracting things that may potentially be methods of an Array instance that should not be subtracted. It just so happens to work in this case because Array has none of those methods. But it doesn't work in the general case.irb(0main):001:0> Object.methods - Object.new.methods => [:allocate, :new, ...]Consider for example, a "Person" class with a single instance method "name". In this case, "Person.new.methods - Object.methods" will not include "name", because this happens to be a method that applies both to Person instances and the object Object. The correct comparison is what vidarh said, "Array.new.methods - Object.new.methods".
The author's main point, however, was that you can write code like "Array.new.methods" and "Object.methods" at all, and that you can write code to subtract them. And this example shows that nicely.
Its great to see metaprogramming listed here - it is a term that tends to frighten beginners a lot more than it should. Understanding some of the basic metaprogramming concepts and features early will go a long way to helping you become a better Rubyist.
Shameless plug: I collected a bunch of resources for learning Ruby, Rails, and general programming on Rake Routes a couple months ago: http://rakeroutes.com/blog/learning-ruby-rails-and-programmi...
On the article, I strongly disagree that vim requires plugins to be viable for Ruby development. The Janus plugin should especially be carefully considered as it wraps up a lot of magic that could prevent the new vim user from effectively learning vim itself.
Also material like Ruby Rogues podcast ( http://rubyrogues.com/ ) contain great episodes to give a newcomer a tour of the ecosystem.
> (infinite loops are almost always written using the loop do..end construct though. but how often do you write infinite loops anyway?)
`while true` usually does it for me.
Empty string is true. Who here hasn't banged their head over that one?
It's probably better to think "everything that isn't nil or false is true".
0 is true too. I think that's actually brilliant.
[1,2,3].index(1) # => 0 [1,2,3].index(4) # => nil
Uh, another good post on sharing the joy/pain of learning Ruby. Thanks for sharing.
I have spent the past three weeks getting my head into Ruby (on the hopeful way to understanding Rails). With so many different languages and stacks, it makes the early stages extremely daunting for a beginner.
I have found comfort in the following resources:
1) The only website I found that actually visualized how everything sits together: http://techiferous.com/2010/07/roadmap-for-learning-rails/
2) I persevered with a Ruby programming book: Beginning Ruby: From Novice to Professional (by Peter Cooper)
3) Spent a few days on a zero install Ruby tutorial: http://tryruby.org
I plan to write some blog posts on the journey however may wait until I get passed the basics before sharing too much.
Learning Ruby is not the same as learning Rails...
OT and hijacking this thread:
1. Who is actually new to Ruby?
(After Ruby or rather the popular RoR is there almost for a decade everyone should have made some experiences with Ruby, so I am wondering if there are many new Rubiest)
2. What new language/stack did you start to learn recently?
(for me: Node.js)
As a Python guy I never had any reason to need to learn Ruby. And even now that I'm playing around with it it's purely out of professional curiosity.
For what it's worth, Ruby has always been more about "want" than "need" for me. When I really need to get something done, fast, I'll choose Python; Python always seems to have an esoteric-but-very-necessary lib for every situation. But Ruby is where I want to spend my fun time.
Opinions will differ, of course. Both languages are tops.
> Who is actually new to Ruby?
I suspect your comment is being buried for the pretentiousness of that question. Plenty of people are still new to Ruby, because you absolutely do not need Ruby to have a successful development career. Not to mention the population of individuals who are completely new to programming.
As a heavy Ruby user who is also regularly hiring:
In my experience it is still vastly harder to hire someone with any degree of Ruby exposure vs. PHP developers, for example.
Ruby is still a niche language.
That was narrow minded. You know it's possible to be a developer and never touch a web app stack professionally, right? Let alone the One True Language that is Ruby.