Apples and Rubies
March 14th, 2005
Lately I’ve been really busy at work, so I havn’t posted anything. Hell I’m writing this as I burn the midnight oil right now at the office (11:30 pm). I plan to take some time off once the current project is done, we’re migrating all of our clients between servers, and that isn’t very fun, especialy if its to be done seamlessly.
Anyways, enough about work .. today I decided to write about Apples and Rubies .. Apples, because I work on a G5 at work, and Rubies, because I prety much exclusively code in Ruby now-a-days.
Apples .. if you were to ask me a year ago .. I’d say I could never work on an Apple. Well I am now, and its not too bad.
A lot of help is a neat editor called TextMate by macromates. Its a prety simple editor, but it packs a lot of power once you get used to it, I find the most powerfull feature that I play with, it “commands”. With commands in TextMate, I can write a snippet of code, (in this case ruby, just as my preference), and run it .. and replace the selected code with the output. For example: “print(’#’*80)” would display a line of hashes, 80 characters long. This has tremendous power, especialy reformatting data.
My other lifesaver app on a Mac is QuickSilver. It is an application launcher, but to leave it at that would be not giving it enough credit. It is so much more, I use it for everything from starting programs, doing simple calulcations, controlling my iTunes, looking things up in my address book, the works.
I’m starting to like apples to the point of seriously considering buying a PowerBook .. I’ll see .. maybe one day I’ll be blogging from a powerbook.
Rubies … again .. if you were to ask me a year ago, what programming language I like above all, I’d say PHP but now, I’m converted, I swear by Ruby.
Along with Ruby, comes an excellent web framework, its called Ruby on Rails. I learned ruby on rails at the same time, and neither really got in the way of learning a brand new language.
.. but well .. I’m not that great at evangelizing .. so I’ll leave it at that ..
Ruby class variable scope
January 23rd, 2005
I’ve come across something interesting in Ruby to watch out for. The short version is: be carefull using @@name variables, because they may not be what you think.
Let’s look a sample scenario. You have a User class, and you extend it with diffrent privilages, for example AdminUser, GuestUser.
Since the privilages are static to a class, you simply want to drop them into a variable on the class and not have to worry about it. So let’s write some sample code:
class User
@@privilages = {}
def self.set_privilage(key, value)
@@privilages[key] = value
end
def self.get_privilage(key)
@@privilages[key]
end
end
class GuestUser < User
set_privilage :everything, :read
end
class AdminUser < User
set_privilage :everything, :write
end
And some test code
puts "GuestUser: #{GuestUser.get_privilage(:everything)}"
puts "AdminUser: #{AdminUser.get_privilage(:everything)}"
I don’t know about you, but I didn’t expect what I saw. Here is the result of the test code:
GuestUser: write
AdminUser: write
<!-nextpage->
I wondered what went wrong for a while. It wasn’t the fact that the variable was getting set somewhere high, like on Class or something.
class Test1
def self.get_test
@@privilages
end
end
Test1.get_test
> NameError: uninitialized class variable @@privilages in Test1
> from (irb):25:in `get_test'
> from (irb):28
> from (irb):19
It seems that @name variables are completely local to the class they are defined in, so a child class can never access (and doesn't get its own copy of) its parent's @name variables.
The workaround for this is even more interesting, it appears that there is such a thing as @name variables on the class itself, that work in a fashon much more predictable (ie a function defied in a parent accesses the child’s copy of the variable).
This is the modified code:
class User
def self.set_privilage(key, value)
@privilages ||= {}
@privilages[key] = value
end
def self.get_privilage(key)
@privilages[key]
end
end
class GuestUser < User
set_privilage :everything, :read
end
class AdminUser < User
set_privilage :everything, :write
end
And this time, the test code runs just fine:
GuestUser: read
AdminUser: write
Moral of the story, @@name variables are tricky in the least to deal with and tests should be written to make sure you’re getting what you’re expecting, especialy when using inheritance.