Now, Acer was/is the first Laptop I bought about one and half year ago. I had various issues with notebook. One of them was overheating, other was rebooting without any reasons ( perhaps because of issue#1). Acer never fixed them. I live in Chennai and their service center is in one obscure place ( only one in Chennai ), where you are supposed to take your notebook and ask them to fix. They will take 4 to 5 days if you are lucky enough and after that you are supposed to go there and collect your notebook. Each day, getting your notebook repaired will take almost half of your day. But anyways, they never actually fixed.

Last time I took my notebook to them, my warranty period was over and their repair charges were almost same as cost of their brand new laptop with almost same configuration. Whats sad is, that was my first laptop and I bought it with Prize money obtained from here .

Needless to say, I left hope. But just for anyone else out there, please don’t buy Acer laptops.

• 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:

1 2 3 4 5 6 7

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:

    Root
    |__ bin
    |__ lib
    |__ lib/packet.rb
    |__ lib/packet/other files go here

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

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  $:.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 VERSION='0.1.4' end

  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.

Its not, “Freedom is Slavery”.

Its You. Its the tangled webs that you have woven, and lo! Who is hanging and smiling from
webs of Shelob. No its not him, its you most likely.

A memory of never happening bliss and if it happens you wouldn’t know most likely.

That there
Thats not me
I go
Where I please
I walk through walls
I float down the liffey
Im not here
This isnt happening
Im not here
Im not here

I wish no questions!