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.
In version 1.9 Ruby introduced new syntax for hash literals whose keys are symbols. If you no longer need to support Ruby 1.8 it's worth updating your code, as the new syntax is more succinct. Doing it by hand would be painful, but with the Unix command line and a quick regular expression we can make the computer do the hard work.
As is often the case after a Mac OS X upgrade, installing Ruby gems that depend on compiled C code can require a bit of fiddling about. I've just upgraded my laptop to Mavericks, and lo and behold, the nokogiri Ruby gem won't install.
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".
Nokogiri complains that the version of libxml2 installed on Mac OS X Leopard is over 4 years out of date. Well we can't have that now can we!
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