Tips for budding Ruby hacker

I am no expert in Ruby, but overtime I have accumulated some thoughts that may help you in writing better Ruby code.

  • Always create a directory hierarchy for your library/application. Such as:
       |__ bin
       |__ lib
       |__ tests
       |__ yaml_specs
  • If you are not writing a library and rather an executable application. Then, have a separate file that loads/requires required libraries and does some basic stuff. For example, I have a boot.rb in my Comet server that looks like:

    require "rubygems"
    require "eventmachine"
    require "buftok"
    require "sequel/mysql"
    PUSH_SERVER_PATH = File.expand_path(File.join(File.dirname(__FILE__),'..'))
    ["lib","channels"].each {|x| $:.unshift(File.join(PUSH_SERVER_PATH,x)) }
    require "push_server"

    Why? Because such a file can come handy when you are writing test_helper for your applications. There, you can simply require above boot.rb, so as you don’t have to copy stuff back and forth if your required libs change.

  • If your project hierarchy is like above and you are writing an library not an application, don’t make the mistake of putting all your files in lib directory straightaway. Rather have a setup like:
      |__ bin
      |__ lib
      |__ lib/packet.rb
      |__ lib/packet/other files go here

    And use relative requires in “packet.rb” file, like:

    $:.unshift(File.dirname(__FILE__)) unless
      $:.include?(File.dirname(__FILE__)) || $:.include?(File.expand_path(File.dirname(__FILE__)))
    require "packet/packet_parser"
    require "packet/packet_meta_pimp"
    require "packet/packet_core"
    require "packet/packet_master"
    require "packet/packet_connection"
    require "packet/packet_worker"
    PACKET_APP = File.expand_path'../' unless defined?(PACKET_APP)
    module Packet

    It would be helpful in avoiding package name collisions that otherwise your users will report.

  • Once chris2 mentioned on #ruby-lang, you shouldn’t be overly clever with test cases. Don’t try to be too DRY in your test cases.
  • Write code that can be easilly tested. What the fuck that means? When I started with Ruby and was doing Network programming. I used to write methods like ughh, that always manipulated state through instance variables. I either used threads or EventMachine. One of the issues with EventMachine is, code written usually relies on state machine and hence it can be notoriously difficult to unit test, because most of the time your methods are working according to the state of instance of variables. That was bad. Try to write code in more functional way, where methods take some parameters and return some values based on arguments. You should minimize methods with side effects as much as possible. This will make your code more readable and easily testable
  • Read code of some good libraries, such as Ramaze , Rake, standard library.
  • Use FastRi rather than Ri. If possible, generate your set of documentation using rdoc on Ruby source code. I spend time just looking through methods, classes just for fun. However, I don’t like the default default RDoc template, use Jamis RDoc template, if you like Rails documentation. Often for gems installed on your machine, you can use gem server or gem_server to view their documentation.
  • #ruby-lang on freenode is generally a good place to shoot general Ruby questions. Be polite, don’t repeat and you will get your answers
  • Avoid monkey patching core classes if your code is a library and will go with third party code.

2 thoughts on “Tips for budding Ruby hacker

  1. Pingback: links for 2008-02-27 « Bloggitation

Leave a Reply

Your email address will not be published. Required fields are marked *