The Chronic files

Although 20.days.ago is a very nice syntax and caused so many non-rails programmers to pass out almost naturally after seeing it work, it still ain't enough.

The Chronic gem enables parsing for date-description strings.
such "yesterday morning" or "sunday next month", Chronic will parse these strings into actual Time objects.

Read more...

Site Mapping

One of the basic elements for each medium sized web-sites and above, is the site map.
when using rails, mapping in not so easy because the object oriented routing which makes it hard to distinct between regular actions and some "maintenance" actions.

I decided to prepare a small library (for now, extensions will be welcomed) which contains 3 basic mapping functions.

The first 2 are pretty custom made for my current project and will be irrelevant for the most of you, but the third is brought to you straight from the oven.

def site_map(path = RAILS_ROOT + "/app/controllers/")
collector = Hash.new
tree = Dir.entries(path).delete_if {|entry| entry.slice(0,1) == "."}
tree = tree.delete_if {|entry| entry.include?('application_controller.rb')}
unless tree.empty?
for element in tree
element = element.gsub('_controller', '')
if element.include?('.rb')
element = element.gsub('.rb', '')
collector['File-' + element] = element.camelize
else
collector['Dir-' + element] = site_map(path + '/' + element)
end
end
end
return collector
end


as you probably noticed, the site_map method returns a Hash.
regular controllers are returned with a key in this format. 'File-', so ClientsController for example will be issued a 'File-Clients' key.
Sub folders will be hashed as well and the same, except that the directory element's key will be in the format of 'Dir-'

Enjoy.

Consult the Console

Day to day life-shortening experiences
My current project is the biggest thing i had ever did, concerning web applications of course (i leave out my origami career).
We have two dedicated servers, 95 models, 45 high powered DRY controllers , a half-operational BackgroundDRb actions, a whole galaxy of multi-asserted tests, test-cases and a functional hell.
A pack of gems, half a dozen plugins and pack of nead to death programmers.
Not that we needed all that for the project, but once you get into a serious programming frenzy, the tendency is to push it as far as you can.

The only thing worrying me was the debugging part, there is nothing in the world more helpless, irresponsible and depraved than a men in the depth of a debugging binge. I noticed that most of my guys aren't using the real powers of the IRB god, and even more, they are not even aware to the hell that can be unleashed when using...

the script/console..


Ok Ok, how?
The console is a simple, command lined interface to your application on any desired environment (specified as a parameter). Using the console you can try your relation in a less pre-defined way then the Testing mechanisem.
simply run script/console in your application root, you will get a very innocent looking command line entry marker, just waiting for you to unleash the beast within... so... why keep it waiting?

Tough love
One thing about the console, it's output is simply readable once used right. Example.

>> first = "i like"
"i like"
>> second = "bananas!"
"bananas!"
>> first + " " + second
"i like bananas!"

gee, this was fun... no?
never mind, the console is primarily used (by me at least) on Models, it enables you to play with your smelly database creatures, without hitting the refresh button on your browser like some kind of a disordered coffee machine... do i smell an example again?

>> elad = SuperHero.find(:first, :conditions => "very_hansom is TRUE")
#"elad", "IQ"=>"7"}>
>> elad.respond_to?(:fly_to) # Just checking if our superhero can fly
true # alright! my very own flying superhero!
>> elad.fly_to("Liverpool") # Mercy-side here i come!
>> elad.location
"Liverpool"

ok, you got the idea.
I Consider myself to be rather a lazy programmer and in fact a person. I found a few other situations where the Rails console might come handy.

Going on a date!

i wanted to check when will one of my packages arrives to it's destination, the nice clerk told me that it will take about 3 weeks before it will get there.
damn, my mathematical skills are weaker even when being compared to my x-ray vision skills. so i immediatly called my favorite problem solver... the console

>> when will my package arrive to destination? # it will never work, just trying :)
SyntaxError: compile error
(irb):1: syntax error, unexpected kWHEN
when will my package arrive to destination?
^
from (irb):1 # Damn :)
>> 3.weeks.from_now
Thu Apr 05 17:54:22 IDT 2007

yippie!, i immediatly called my Samoan clients and to wait for their next gun shipment on april 5th.

Just kidding :), but isn't it beautiful?

The Boolean connection

Few people understand the true mentality of dealing with a Boolean variable.
The normal programmer will panic, and immediately attempt to compare it to a Boolean constant.

when using Rails, This is wrong.

When migrating a boolean typed column using Rails, the actual column type created is "tinyint(1)" (a single digit number presentation which means that the actual value being saved is 0's or 1's.
Where is the problem? in Ruby for a change.
In Ruby, everything except nil and false is considered to a true value. In C, Python and many other languages, 0 and possibly other values, such as empty lists, are considered as false.

which brings us to the inevitable conclusion, that simplay comparing boolean values to true or false will not do.

Rails solves this tiny issue for us, for each boolean attribute, Rails implements a "query method" as i prefer to call them. These query methods are simply called by issuing the boolean attribute name with a "?" suffix.

for example, the @mail_message instance object has a is_important boolean attribute, so instead of doing:


@mail_message.is_important == true

or whatever, we can simply ask rails by:

@mail_message.is_important?


beautiful... isn't it?