Ruby is a very expressive programming language, whose design was influenced by some of the best bits of Perl, Smalltalk, Eiffel, Ada and Lisp. Ruby occupies a similar niche to Python – both languages are dynamically typed, support garbage collection and provide great libraries of re-usable code.
If you're new to programming I'd recommend the Pragmatic Programmer's Learn to Program book.
If you've programmed before but are new to Ruby you could do worse things with your time than to read Why's Poignant Guide to Ruby (as technical books go it's not to everybody's taste, but it's hugely entertaining and very well written -- it might just get you hooked). More experienced programmers may find Programming Ruby and The Ruby Way by Hal Fulton more suitable.
Do you sometimes find yourself wanting to read the code of a method in one of the gems that your project is using? Wouldn't it be good if you could put your cursor on the method or class in question, and press a key to jump straight to the definition within the gem's source code? With the
ctagsprogram you can, and with the
guard-ctags-bundlergem your tag files will be automatically updated when you add new gems to your bundle.
Ruby programmers need to be able to read the source code of the libraries (gems) that they use. Bundler makes it easy to load the source of a gem into your editor, with the
bundle opencommand, but it'd be useful if it changed your current directory before launching Vim.
Bundler is a great way to control the versions of the gems that are used in your Ruby application, but it requires you to run Ruby scripts and tools (such as
heroku) by prefixing them with an extra command (e.g.
bundle exec rake). This is a pain, can be easy to forget, and can cause no end of subtle bugs if the script that you're running can be found outside of the bundled application, in your shell's PATH.
Ruby Manor is one of those alternative conferences. It's not run for a profit. It doesn't cost a lot of money to attend (at £8 per head you pay just enough to cover the cost of the room and equipment), and the quality of the talks is consistently high. I wrote them all up.
Which is better, handling an exception or explicitly checking to see whether or not your code is going to break? The answer is "it depends". On the one hand exception handling allows us to write more legible code (often summed up by the saying "it's easier to ask forgiveness than permission"). On the other, handling an exception is often a costly operation; it can be faster to "look before you leap".
Tonight's LRUG meeting consisted of 8 quick 20x20 format presentations (20 slides, 20 seconds per slide) on a range of Ruby related topics. The speakers covered packaging gems for Debian, sending IM messages with XMPP, a quick intro to ruby-debug, RubyGame, smoke testing, Twitter bots and statistics in Ruby via the power of R.
In which I talk about how to find chocolate biscuits with DataMapper...
How often do you find yourself wanting to check the source code of a locally installed Ruby gem? Do you find it painful digging around your filesystem to locate the gems directory? With
mategemI just type