Ruby

Rails 3 has good TimeZone support built in, but you have to use the right Date and Time classes to get full support. If you have this set in your application.rb config.active_record.default_timezone = :local, then you really need to use Time so that it properly identifies itself as being in the local timezone and not in UTC when passing to the database insert. ree-1.8.7-2011.03 :001 > DateTime.parse('2011-11-27 12:00:00 +0000') => Sun, 27 Nov 2011 12:00:00 +0000 ree-1.8.7-2011.03 :002 > DateTime.parse('2011-11-27 12:00:00') => Sun, 27 Nov 2011 12:00:00 +0000 ree-1.8.7-2011.03 :003 > Time.parse('2011-11-27 12:00:00 +0000') => Sun Nov 27 06:00:00 -0600 2011 ree-1.8.7-2011.03 :004 > Time.parse('2011-11-27 12:00:00') => Sun Nov 27 12:00:00 -0600 2011 So basically, Time.parse always returns the value in the local timezone, DateTime.parse always returns the value in UTC. To get complete compatibility, always use Time.parse. Trust me, I learned the hard way :)

Taken from Code Kata’s by Dave Thomas The basic premise of this Kata is asking how you would model super market pricing. What is the price of an item? What is the cost? How do you handle price-per-pound? Buy 2 get one free? What’s the value of stock? It’s interesting, and I thought I’d take the time to blog through my thought process. I’d like to iterate over the design and see where it takes me. First task is to represent a product. ...

Let’s take this basic class: class TestClass attr_accessor :one def my_method(branch=true) if branch puts "Do nothing to modify `one`" else puts "Modify `one` but it's a local variable" one = "test" end one # local variable end def my_non_modifying_method(branch=true) if branch puts "Do nothing to modify `one`" else puts "Do nothing to modify `one` either" end one #method call end end o = TestClass.new o.one = "Value" puts o.my_method => nil #might expect 'Value' if you're not paying attention puts o.my_non_modifying_method #expects "Value" => "Value" puts o.my_method(false) => "test" puts o.my_non_modifying_method(false) #expects "Value" => "Value" So remember, if you create any local variables anywhere in your method, even if they’re not called, they override the accessor methods and will give you results you’re not expecting. To get around it, make sure you always use self.accessor= to assign values when there is ambiguity.

I had a process where I wanted users to fill out a survey which had hierarchal categories AND be able to specify some additional data for specific capabilities that the user had. Now, you could easily do this for a small subset and hand-code every item, but I wanted a flexible survey system that allowed true hierarchy and generalized code. Let’s start off with the basic survey and capabilities models and relationships: ...

When you’re discussing efficiency, a lot of what comes up is the details. There is something to be said for the “beauty” of limitation and the “efficiency” of beautiful things–especially the efficiency of our brains processing it. A talk about the Zen of Python, monkey patching (several times), the Ruby community's reckless hastiness, the syntax of RSpec and cucumber, beauty and ugliness in languages and testing tools, the complexity of the languages' grammars, syntactic vs. semantic complexity, the relative taste of grasshoppers and tree bark, etc., etc. Python vs. Ruby: A Battle to The Death from Gary Bernhardt on Vimeo. ...

As long as we’re talking about efficiency here, one of the ways to be more efficient is to use the right tool for the job. I’ve done PDF generation on 3 different projects but the PDF generation I did yesterday was by far the easiest. What I thought would take me 2 days ended up taking about 3 hours (with research, etc). If you’re not using Ruby to automate some part of your job or life, I feel sad for you (at least a little). The next time you need to generate PDFs, why not try out the excellent Prawn library? Not familiar, you say? Well, let’s dive right in, shall we? ...

While the Python version may not be quite as pretty, nothing about them screams “Ruby has much stronger capabilities here”. Instead, by using examples like Sinatra, Rubyists trade in an argument about great semantic power for one about superficial beauty. Rubyists, Pythonistas and others working on web development share a common language in JavaScript. When describing blocks to “outsiders” who share a common knowledge of JavaScript, we tend to point at JavaScript functions as a close analogue. Unfortunately, this only furthers the confusion. ...