Pragmatic Programming
Recently I’ve been thinking a lot about the importance of being a pragmatic programmer. No, I don’t mean one of those guys who writes very helpful books on programming. Instead, I mean just that: a programmer who is pragmatic. The New Oxford American Dictionary defines pragmatic as "dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations". So by that understanding a pragmatic programmer is one who takes a sensible and practical approach and doesn’t get stuck on theoretical endeavors. Now don’t get me wrong, theory is all well and good, and I’ve had lots of great theoretical discussions on all sorts of issues, but at the end of the day the work needs to get done. And for the work to be done, one needs to be pragmatic.
Regexp.new with Multiple Modifier
This may be a no brainer, but I was working with Regexp.new and ran into and wanted to make a regexp with multiple modifiers. It’s easy enough to make one, the docs show you how to:
r = Regexp.new('dog', Regexp::EXTENDED) #=> /dog/xBut what if you want more than one modifier? The docs say they should be “or-ed” together. This is as simple as:
r = Regexp.new('test', Regexp::IGNORECASE | Regexp::MULTILINE)
#=> /test/miYou can even use all three as such:
r = Regexp.new('test', Regexp::IGNORECASE | Regexp::MULTILINE | Regexp::EXTENDED)
#=> /dog/mixSort of a no-brainer once you realize what it means.
Get a Backtrace for Debugging Without Throwing an Exception
In one of my current projects, I ran into a very annoying situation where an object attribute was getting set to an incorrect value. The problem was that I didn’t know where this was happening. Furthermore, as far as I could tell, it was being set in a method that had a complex series of alias_method_chains and callbacks. After spending far too long debugging what turned out to be a simple issue, I realized I needed a better solution for the future.
What I really wanted was a backtrace showing what method chain had led to setting the attribute incorrectly. However, as far as I could tell, there was no easy way to get a backtrace outside of raising an Exception. So I came up with a little helper to make this process easier:
Stop Hash.from_xml from Killing XML Attributes 1
UPDATE: I’ve submitted a patch for this to core. Check it out here.
Before I get into the solution, I should probably begin by explaining the problem. Consider the following line of code:
Hash.from_xml('<variable type="integer">5</variable>')
#=> { "variable" => 5 }There are two important things to notice here. First, the 5 is parsed as an integer, second, we lose the “type” attribute. What’s going on behind the scenes is that Rails is looking for a "type" attribute to determine how to typecast the element contents. Now under most circumstances, this is all well and good, but what if you run into a situation where the “type” attribute doesn’t match up with ones known to Rails?
Hash.from_xml('<variable type="product_code">5</variable>')
#=> { "variable" => 5 }Reading PDF Properties with Ruby
So off the bat I’ll admit that this is not the most interesting topic that I could write about. However, I did have to do some PDF Processing Recently in which I had to read some custom properties from a PDF. It took me a little while to stumble on to a solution so this may serve as a useful fast track.
What I eventually found was PDF::Reader, available over on github. In the README, he gives instructions for extracting metadata, which was exactly what I wanted. Unfortunately, the setup is a bit awkward, requiring an additional receiver.